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> 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. >
