Snowflake follows the role-based access control (RBAC) paradigm. Best practice for RBAC is, to have functional and access roles managing either user and clients or access privileges. This creates in worst-case a variety of roles that inherits permissions from and to each other. By nature, one can easily lose sight.
In snowflake, grants to roles and users are stored in ACCESS_USAGE.GRANTS_TO_ROLES and ACCESS_USAGE.GRANTS_TO_USERS. What is a proper approach to identify the data stewards/owner of a role automatically (if not labeled explicitly in a 3rd party tooling)?
Options I thought of:
recursive lookup of OWNERSHIP privileges of roles of roles (will generate a lot of false positives)
recursive discovery of a service account that has advanced permission to a role and lookup the service account owner
lookup over usage pattern of executed queries (might be actually more consumers than producers)
A couple of options:
Populate the role’s comment field with the relevant Data Steward information
Use Tags (in public preview)
Related
I have an app that will have many users at various levels of privileges on what they can "See/Select".
The users form a hierarchy. Level1--> Level2--Level3 etc. Level1 users may have many level2 users, similarly Level2 users may have many level3 users . Each user can see anything that belongs to them or anyone directly below them. For example: A level 2 user can see all level 3 users information that rolls up to her but cannot see , any level 3 users that rolls up to other level 2 users.... You get the idea.
All userids are unique.
I am thinking of implementing Row Level Security with policies to restrict based on the userid. This is working at the database level by implementing Row level security and policies.
However, I would like to know how this can be achieved with IAM roles and IAM based authentication?
I read the documentation. It states, that while I can create a IAM roles and assign them privileges at the db level, and individual users can be assigned to these IAM roles to access the database using authtokens, it does not state how I can track each of the users at the database level to ensure that they can only see their data?
Any insights appreciated.
S
If you google "SaaS Multi-tenant Storage Isolation" You'll find a number of resources on this topic. The short answer is that you can achieve what you are trying to do (pool isolation enforced by IAM policies) with DynamoDB. But with RDS you have to rely on database users and PostgeSQL RLS features.
If you look at the IAM documentation for DyanmoDB and RDS condition keys, you'll see that with DynamoDB you can filter actions based on things like "dynamodb:LeadingKeys" or "dynamodb:Attributes". Where as RDS you do not have filters that get as granular as individual indicies or attributes.
https://docs.aws.amazon.com/service-authorization/latest/reference/list_amazonrds.html#amazonrds-policy-keys
https://docs.aws.amazon.com/service-authorization/latest/reference/list_amazondynamodb.html#amazondynamodb-policy-keys
Here's some addtional material on the topic worth looking at:
https://www.youtube.com/watch?v=fuDZq-EspNA (includes examples at ~35mins)
https://d1.awsstatic.com/whitepapers/Multi_Tenant_SaaS_Storage_Strategies.pdf
https://aws.amazon.com/blogs/database/multi-tenant-data-isolation-with-postgresql-row-level-security/
I want to know if is it possible define in FHIR a strategy about read / write specific resource field.
i.e. I have a ServiceRequest resource.
I want to grant for a specific profile / role write on authoredOn field and I want to prevent the write for another profile / role.
I try to read CapabilitySystem resource but I think it don't fit my aim.
In FHIR, in which part of it, I can define profiles and roles?
In general, updates are to the whole resource, not to individual fields. You're free to define business rules that reject an update on the grounds that a field has changed that a user isn't authorized to manipulate, but there's no standard way to express this limitation in the CapabilityStatement. (You could define an extension though.)
Would it be viable to use an embedded document roles field for a user table if at most there can be 5 different roles? The reason I ask this is because I believe using an array type for that field would do the same thing. The only time I'd be using the roles field is for checking if the user has the ability to access certain pages/functionality on the website. Am I missing something here? Thanks
I don't really think either approach is incorrect and I think it's more relevant to how you want your models to look than how your data will be stored. It really just depends on what (if any) information aside from the role type that you want to persist and how you plan to check the user's role.
If you're looking to simply store a list of roles (admin, user, moderator, etc) then a serialized array attribute is probably fine. On the other hand, if your roles have more information stored within them (ex. granted actions or privileges for each role) it might be beneficial to build out a UserRole model separately and embed that in your User model.
There is actually another, pretty good option if you're simply storing a list of roles where each user can be a member of one or more roles. You can actually us a bitmask. Using this approach your user roles would be stored as a simple integer and you'd use some of ruby's bitwise operators to map that value to a set of roles.
http://railscasts.com/episodes/189-embedded-association?view=asciicast
From the PostgreSQL docs:
The concept of roles subsumes the concepts of "users" and "groups". In
PostgreSQL versions before 8.1, users and groups were distinct kinds
of entities, but now there are only roles. Any role can act as a user,
a group, or both.
Why did they make this change in 8.1?
Perhaps it's easier from the C coders point of view, with a single Role class (struct)?
More details:
CREATE USER is equivalent to CREATE ROLE except that CREATE USER gives the LOGIN permission to the user/role.
(I'm about to design a permission system for my webapp, hence I'm interested in this.)
The merge has many advantages and no disadvantages. For instance, you can now seamlessly convert a "user" to a "group" and vice versa by adding / removing the LOGIN privilege.
ALTER ROLE myrole LOGIN;
ALTER ROLE myrole NOLOGIN;
Or you can GRANT membership in any other login ("user") or non-login role ("group") to a role:
GRANT joe TO sue;
You can still:
CREATE USER james;
That's just a role with login privilege now. Or:
CREATE GROUP workers;
That's effectively the same as CREATE ROLE now.
The manual has it all.
I found this thread in the PostgreSQL-Hackers list, from June 6, 2003, that in the end suggests that users and groups and roles be consolidated. (Thanks Craig Ringer for suggesting that I check the pgsql-hackers list archives.)
Here are some benefits mentioned (those that I found).
allow groups to have groups as members
the ACL code would be simplified
the GRANT/REVOKE syntax and the display format for ACL lists could be
simplified, since there'd be no need for a syntactic marker as to
whether a given name is a user or a group.
In some circumstances I could see it making sense to allow logging in
directly as a group/role/whatchacallit
This would also solve the problem that information_schema views will
show only owned objects
[makes it easier to] representing privileges granted to groups [since
you'd simply reuse the role related code?]
From the manual:
The SQL standard defines the concepts of users and roles, but it
regards them as distinct concepts and leaves all commands defining
users to be specified by each database implementation. In PostgreSQL
we have chosen to unify users and roles into a single kind of entity.
Roles therefore have many more optional attributes than they do in the
standard.
Having a distinction between users and groups doesn't gain you anything.
AFAIK the motivation for changing it was to simplify uses like:
One user masquerading as another, eg a superuser simulating a reduced permissions user. With unified roles this becomes just another change of current role, no different to changing primary group.
Groups that are members of other groups to implement granular access permissions.
If you want the details, though, you're best off checking out the archives of the pgsql-hackers list for the period, and the git history (converted from CVS).
What is the differences beween roles and users.
A role can have many users. An example might be an Admin role, which could mean someone who's assigned and their backup. Both would have the same rights, which are embodied in the role. Individuals can come and go, but roles remain.
A role typically defines a business function (or set of functions) performed by one or more users. Examples would be 'customer service agent' or 'business analyst'. A user is an individual person who is included in the role - Bob, Nancy, and Steve might be assigned to the customer service agent role.
This makes is easier to assign permissions to database objects. You can assign permissions to the role, and any user who belongs to that role inherits the same set of permissions.
On a technical level, see other answers. On a practical level, when you have large user set with fluid permissioning needs due to changing roles, the difference is that assigning per-user permissions means any change in user responsibilities necessitates permissions changes on MULTIPLE database objects that user needs to be added to/removed from perms.
Whereas if the perms are assigned to the roles, the only change is in the role membership.
The latter is both significantly less resource taxing on DBAs, and due to less work needed, significantly less likely to suffer from operator error (e.g. less work to do => less chance to screw it up) and thus more secure.