Hi all,
As extension to the |N-man| rule, I would like to propose a
self-evolving policy-based approval mechanism.
_*Policies*_
I am defining the following policies for illustration purpose. In
practical implementation, we can implement more complex policies.
_*
*_
*Super User Add Policy: *The number of approvals required to add
another super user
*Super User Remove Policy:* The number of approvals required to remove
an existing super user
*User Role Assignment Policy:* The number of approvals required to add
a role assignment to the user
*User Role Removal Policy:* The number of approvals required to remove
a role assignment from the user
_*Bootstrapping*_
When the administrator boots up Cassandra, he defines the set of super
users and super user approval policies.
In case of a development instance, the instance will be self-managed
and there will be only one super user. The policy for such instances
can be like the following:
/superUsers: [A]/
/policies:/
/ superUserAddPolicy: 1/
/ superUserRemovePolicy: 2
/
/ userRoleAssignmentPolicy: 1/
/ userRoleRemovelPolicy: 1/
In case of a production instances, the policies should be strong
enough to prevent ad-hoc operations. Also, some good set of super
users should be aware of the changes. The policy will be something
similar to the following:
/superUsers: [A,B,C,D,E]/
/policies:/
/ superUserAddPolicy: ALL
/
/ superUserRemovePolicy: ALL-1
/
/ userRoleAssignmentPolicy: MAJORITY/
/ userRoleRemovelPolicy: ONE
/
The above policy mean the following:
1. To add another super user (let's say F), we need approval of all
the existing super users
2. To remove an existing super user (let's say E), we need approval
of all existing super users except one
3. To add a role assignment to an user, majority of the super users
should approve
4. To remove a role assignment from an user, approval of only one
super user is good enough
Let's assume we have user X and he requires database_reader role. This
new role assignment has to be proposed by one of the super users;
let's assume A proposes the new role assignment. Since he proposes, he
implicitly approves the same. According to the policy, we need two
more approvals to reach majority. If two more super users (say C & E)
approve the user role assignment, the role assignment becomes effective.
This shows the flexibility of policy-based approval flow.
_*Evolvability*_
Let's assume that for any change in policies, we need approval of all
super users.
The dev instance where the user A is the only super user needs to be
upgraded to a prod instance. This means, we have to evolve our
policies to that of the prod instance.
The initial policy can be like this:
/superUsers: [A]/
/policies:/
/ superUserAddPolicy: 1/
/ superUserRemovePolicy: 2
/
/ userRoleAssignmentPolicy: 1/
/ userRoleRemovelPolicy: 1/
Now he can change the last three policies to ALL-1, MAJORITY and ONE
respectively. As he is the only one super user, no other users'
approval is required for policy change. After this change, the policy
looks like:
/
/
/superUsers: [A]/
/policies:/
/ superUserAddPolicy: 1/
/ superUserRemovePolicy: ALL-1
/
/ userRoleAssignmentPolicy: MAJORITY
/
/ userRoleRemovelPolicy: ONE/
/
/
Now A can add other super users. He doesn't need any approval as the
superUserAddPolicy is ONE. After this change, the policy will look like:
/superUsers: [A,B,C,D,E]/
/policies:/
/ superUserAddPolicy: 1/
/ superUserRemovePolicy: ALL-1
/
/ userRoleAssignmentPolicy: MAJORITY
/
/ userRoleRemovelPolicy: ONE/
/
/
Now we need to make superUserAddPolicy to 'ALL'. For changes in
policies, we need approval of all super users. So, A can propose the
policy change and B,C,D & E can approve the policy change. Now the
policy becomes same as the prod policy that we described in previous
section:
/
//superUsers: [A,B,C,D,E]/
/policies:/
/ superUserAddPolicy: ALL/
/ superUserRemovePolicy: ALL-1
/
/ userRoleAssignmentPolicy: MAJORITY
/
/ userRoleRemovelPolicy: ONE/
This shows the evolvability of the policy based approach.
With this approach, we can make sure the customers can fine tune the
policy that are required for their company's compliance policies and
they can evolve as the requirements change.
References:
The above mentioned approach is inspired by policies in Hyperledger
Fabric:
https://hyperledger-fabric.readthedocs.io/en/release-2.2/policies/policies.html
Thanks,
Sathyanarayanan S
------------------------------------------------------------------------
*From:* Tibor Répási <tibor.rep...@anzix.org>
*Sent:* Wednesday, March 30, 2022 10:46 PM
*To:* dev@cassandra.apache.org <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 <jeremiah.jor...@gmail.com>
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.
>>>>>
>>>>>
>>>>
>>>>
