btw there is also an opposite problem, you HAVE TO have two guys (out of two) to grant access. What if one of them is not available because he went on holiday? So it might be wise to say "if three out of five admins grants access that is enough", how would you implement it?
On Wed, 30 Mar 2022 at 16:56, Stefan Miklosovic <stefan.mikloso...@instaclustr.com> wrote: > > Why not N guys instead of two? Where does this stop? "2" seems to be > an arbitrary number. This starts to remind me of Shamir's shared > secrets. > > https://en.wikipedia.org/wiki/Shamir%27s_Secret_Sharing > > On Wed, 30 Mar 2022 at 16:36, Tibor Répási <tibor.rep...@anzix.org> wrote: > > > > … 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> 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. > >> > >> > > > >
