Hi,
I also think these are all valuable ideas. But iiuc I think there's
nothing in 17501 incompatible to them. Also it seems to me like a
sensible self-contained first step improvement in the right direction.
Regards
On 30/3/22 17:06, J. D. Jordan wrote:
I think these are very interesting ideas for another new feature. Would one of
you like to write it up as a JIRA and start a new thread to discuss details? I
think it would be good to keep this thread about the simpler proposal from
CASSANDRA-17501 unless you all are against implementing that without the new
abilities you are proposing? This “requires N grants” idea seems to me to be
orthogonal to the original ticket.
On Mar 30, 2022, at 10:00 AM, Stefan Miklosovic
<stefan.mikloso...@instaclustr.com> wrote:
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.
