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 still reflect that.
On 30/3/22 15:22, J. D. Jordan wrote:
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 prevent that. With this type
of restriction + audit logs of all user management you can show that
an admin has not accessed data through their admin account.
The ability to have an even more restrictive mode would be a nice
future add on.
-Jeremiah
On Mar 30, 2022, at 8:13 AM, 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 createdhttps://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.
