May 13, 2016 at 7:32 pm
For most sytems, i would expect roles to be the right way to go. But there can be exceptions.
The most obvious case where roles don't do the whole job is the case where each user with access other than read only has a specific table to which he and no-one else has input permission (but he doesn't have update or delete permission), for him to comment on what he sees happening or on what he has done that may seem unusual. Other people may have read permission (which may be handled by roles - but then some of those roles probably have to be updated whenever a user is created) and members of the security auditor role (but no-one else) may have delete permissions on all such tables.
Maybe all the other permissions fit into roles, but that particular insert permisson has to be granted individually to an individual user when the user and his/her personal comment table are created.
Mostly you won't want such individual comment tables. But very high security systems sometimes will.
Another case is when you are trying to conform, within the database, to old-style coloured book security (not the database-specific security nonsense in the coloured books, but the system security stuff). Since the classification of what a user writes may depend upon the classifications of what he has already read in the curent session neither roles nor individual permissions really work at all. It's a real pain in the wherever you fancy, as anyone who ever attempted to get B2 or higher certification in database or indeed in anything else will tell you. I was once slightly involved on the fringes of an OS that went there, but made damned sure that (a) I was never involved with a database that might want to go there and (b) no OS for which I held any responsability for security design ever tried to go there. I can't imagine how to apply it to a relational database, but maybe NSA or GCHQ have people who can - they have to more intelligent than their (fairly rare and usually ambiguous or vague) public pronouncements suggest. I've never met anyone who could imagine it, so maybe ittt's just too difficuly and that's why database security was in a different coloured book with much less stringent requirements.
Tom
May 16, 2016 at 7:00 am
The use of roles is fine. We do the same. The problem we have is with the coding that has been done by various programmers. We didn't keep a good handle on how it was all implemented, access that is. Some code uses roles, some uses other things making the addition of new roles a bit more complex. We even had some code that said as long as no one was explicitly granted this role then everyone had access. The moment we explicitly added the role to someone, everyone else was denied access. That mistake made it to production.
Viewing 2 posts - 16 through 16 (of 16 total)
You must be logged in to reply to this topic. Login to reply