So I'm in the process of working on part of our new role based site security system and have come up to the "nuclear missile" condition.

The system is based around the idea of grouping, with the ability for users to be implied to be in groups based on current groups, like so:

  • Tom is a master Cake Maker

  • by putting him in the Cake Maker group, it also implies that he is in the baker group, thus he doesn't need to be physically put in that group.

  • By implication of being in the baker group, he could be put into any other baking sub group.

  • If tom became CEO of his bakery, he would be taken out of the baking group and be put in the CEO group, which then implies he has access to all groups (baking, cake making, etc).

The "nuclear missile" condition is thus: I am a web developer, thus i need to have access to all groups so i can test for various conditions and bugs that may occur during the lifecycle. But there also might be sensitive data that I shouldn't be looking at, this might belong to the HR group or the Finance group. By implementing the nuclear missile system it would mean for me to get access to the live pages, someone from the HR group or Finance group would have to provide their password at the same time as mine.. 2 password fields on a page.

This is quite a fun solution, but i'm not convinced altogether practical. How do you generally protect rogue system developers against sensitive data? do you hash anything sensitive and only reveal if the person is actually a member of the group that belongs to the data.

do you even care?


A similar solution is used for emergency cases, often called a 'break-glass' solution and it typically requires a separate administrator level account, with a password split into two halves, and documentation on these passwords held in safes (usually IT's and an executive safe)

I don't think your use case qualifies as emergency, as it could happen pretty often, so what you find is much more common are controls implemented at the personnel level, including:

  • more stringent vetting
  • logging of everything privileged users do

This allows work to carry on as normal without being impacted by intrusive security controls, while also protecting the company.

Of course the above holds for developers with access to live. For developers running BAU tasks, the preferred method is for them to only have sanitised data. They would take the customer account database, generate replacement names and addresses and use these in Dev, UAT, OAT and Pre-Prod environments so Devs never got access to the live environment.

Over the last 16 years I can probably count the number of organisations that do that on the fingers of one hand, so go back up and use vetting and logging. Sorry, but that's the way it tends to work.

|improve this answer|||||

The solution I most encountered consisted in a single layer of groups, and as such no group inheritance. The problem arises when a person belongs to two or more groups with conflicting rights. Then you have the choice to either go one way (example: granted access > denied access) or the opposite way.

This is I think the most easier way because otherwise you may run into trouble with group inheritance (and I suspect you would have to provide a complex interface for mamaging user groups, right?)

Now, one thing struck me in your question:

But there also might be sensitive data that I shouldn't be looking at, this might belong to the HR group or the Finance group

Regardless of your solution, you should work on anonymized data, not on real data. If you are working on an exact copy of a production database the first step for you or (if you are lucky to have one) for your database administrator to provide you with an anonymized copy of the database. Numbers may be randomized, names too (there are name databases available online for free), etc.

That way, you are not to worry in which group you are, you may be in all possible groups, or in a super group inheriting from all groups, you can safely test your web application knowing it will not be possible to learn how much your boss is paid ;-)

|improve this answer|||||
  • I fully agree about anonymized data. however there might be times when I want access to the live site to see an issues because maybe my codebase is out of step or something freaky has gone on... – Jarede Jan 24 '12 at 9:58
  • 1
    @Jarede I can understand that and in some hard-to-find bug cases I agree it is annoying to not have direct production access. However, you should be able to reproduce the problem on anonymous data... if not, well, you could request a blurred screenshot ? I'm sorry I can't see how you could avoid seeing sensitive data otherwise. – Jalayn Jan 24 '12 at 10:08

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.