I think this is an important step in the authorization model of C*.  It brings 
parity with many other databases.

While further restrictions might make such restrictions less likely to be 
worked around, in most places I have heard of using audit logging of user 
management statements is how you prevent that.  With this type of restriction + 
audit logs of all user management you can show that an admin has not accessed 
data through their admin account.

The ability to have an even more restrictive mode would be a nice future add on.

-Jeremiah

> On Mar 30, 2022, at 8:13 AM, Benjamin Lerer <ble...@apache.org> wrote:
> 
> 
>> What would prevent the security_admin from self-authorizing himself?
> 
> It is a valid point. :-) The idea is to have some mechanisms in place to 
> prevent that kind of behavior.
> Of course people might still be able to collaborate to get access to some 
> data but a single person should not be able to do that all by himself. 
> 
> 
>> Le mer. 30 mars 2022 à 14:52, Tibor Répási <tibor.rep...@anzix.org> a écrit :
>> I like the idea of separation of duties. But, wouldn’t be a security_admin 
>> role not just a select and modify permission on system_auth? What would 
>> prevent the security_admin from self-authorizing himself?
>> 
>> Would it be possible to add some sort of two-man rule?
>> 
>>> On 30. Mar 2022, at 10:44, Berenguer Blasi <berenguerbl...@gmail.com> wrote:
>>> 
>>> Hi all,
>>> 
>>> I would like to propose to add support for a sort of a security role that 
>>> can grant/revoke 
>>> permissions to a user to a resource (KS, table,...) but _not_ access the 
>>> data in that resource itself. Data may be sensitive,
>>> have legal constrains, etc but this separation of duties should enable 
>>> that. Think of a hospital where
>>> IT can grant/revoke permissions to doctors but IT should _not_ have access 
>>> to the data itself.
>>> 
>>> I have created https://issues.apache.org/jira/browse/CASSANDRA-17501 with 
>>> more details. If anybody has 
>>> any concerns or questions with this functionality I will be happy to 
>>> discuss them.
>>> 
>>> Thx in advance.
>> 

Reply via email to