… TWO_MAN_RULE could probably be poor naming and a boolean option not flexible enough, let’s change that to an integer option like GRANTORS defaulting 1 and could be any higher defining the number of grantors needed for the role to become active.
> On 30. Mar 2022, at 16:11, Tibor Répási <tibor.rep...@anzix.org> wrote: > > Having two-man rules in place for authorizing access to highly sensitive data > is not uncommon. I think about something like: > > As superuser: > > CREATE KEYSPACE patientdata …; > CREATE ROLE patientdata_access WITH TWO_MAN_RULE=true; > GRANT SELECT, MODIFY ON patientdata TO patientdata_access; > CREATE ROLE security_admin; > GRANT AUTHORIZE patientdata_access TO security_admin; > GRANT security_admin TO admin_guy1; > GRANT security_admin TO admin_guy2; > As admin_guy1: > > GRANT patientdata_access TO doctor_house; > at this point doctor_house doesn’t have access to patientdata, it needs > admin_guy2 to: > > GRANT patientdata_access TO doctor_house; > > > >> On 30. Mar 2022, at 15:13, Benjamin Lerer <ble...@apache.org >> <mailto: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 >> <mailto: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 >>> <mailto: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 >>> <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. >> >
