0:46 PM
*To:* dev@cassandra.apache.org
*Subject:* Re: Adding a security role to grant/revoke with no access
to the data itself
I think both ideas are worth the discussion. I’ve opened
CASSANDRA-17502 to summarise the idea of the-man rule.
> On 30. Mar 2022, at 17:06, J. D. Jordan
wrote:
&g
om: Tibor Répási
Sent: Wednesday, March 30, 2022 10:46 PM
To: dev@cassandra.apache.org
Subject: Re: Adding a security role to grant/revoke with no access to the data
itself
I think both ideas are worth the discussion. I’ve opened CASSANDRA-17502 to
summarise the idea of the-man rule.
> On 3
I think both ideas are worth the discussion. I’ve opened CASSANDRA-17502 to
summarise the idea of the-man rule.
> On 30. Mar 2022, at 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 ne
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 i
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 w
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
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 wrote:
>
> … TWO_MAN_RULE could probably be poor namin
… 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 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
Hi thanks for the reply,
IIUC If you look in the ticket an evil security_admin would be under a
'RESTRICT' for that keyspace i.e. That would take precedence over GRANTs
so he couldn't self-auth to see that data. But having said that yes, if
enough people collude... but then the audit logs will
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 p
>
> 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
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, Bereng
13 matches
Mail list logo
