Link: https://easandbox.wordpress.com/2021/03/05/user-rights-in-architecture/
Last week I was asked for a standard definition of what administrative users are in our company. I wanted to talk a bit about user rights because admin or not admin as a way of thinking is dangerous.
I wanted to share my thoughts on it, and an approach for defining user rights in architecture. I want to start by recommending a read – Modelling Identity In Enterprise Architecture. When it comes to designing role based access control (RBAC) I think this is a good starting point. This blog is thinking more in terms of systems access than designing full RBAC.
Most organizations have a need to adhere to standards such as ISO27k, or even more fully defined security baselines. Its clear that there is a need for segregation of duties, and that security principles should in some way cover the need for least privileged access.
Thinking in terms of administrative usage by itself is dangerous, because its binary – you are asserting that either a user has privilege to administer, or does not. When I started writing this blog that’s all I wanted to point out but in creating the fictitious example below I realized there’s a lot more I could say around my flow of thought.
As with other blogs, the point here is not to design a complete service, more its to explain my approaches. There are a few things I would change if I was going to build a real thing. I would look at my Identity Access Management and fit that in a lot better.
Lets make something up. Our fake example is a backup service.
Backing up a system
In order to fully back up a system it stands to reason you need to have access to everything in it. A non privileged user could not back up files they do not have access to. If we were asking the question should that user be privileged or not, the answer would be yes, that user needs privileges to read all data on that system. In fact all users need privilege’s in a system, the question is normally how much.
Does this mean that user is an admin user?
Here’s where you need to be careful. On a windows or UNIX operating system – assigning admin rights out of the box gives a specific scope of control to a user. people tend to talk in terms of admin rights and non admin rights because of this. if I tell someone they will get admin rights on a windows server they know what they get.
When you do not do architecture, or think about your systems security architecture the exact needs are not designed. I have seen many times in my career people writing code to elevate permissions to admin just because code didn’t work in the current user, and elevating privilege’s solved it. Whilst it made the code work it gave code dangerous levels of access to the systems that could be exploited
When people use the term elevated privilege’s they do not necessarily mean administrative access, they mean they require more than they would have had otherwise.
Using Admin Users For Elevated privilege
In general I would say using admin users for anything is a bad idea – because if you share admin credentials around you are increasing the probability those credentials can be compromised – and you are also making it hard to trace who actually made changes to a system
Giving users admin rights would be a better approach when it comes to identifying change, but still this is generally considered not good enough; A common security principle that you will see in many standards is “only provide needed rights” – so if an account does become compromised the damage is limited.
In the case of our backup example, admin rights may be too much. to perform a backup, I need read access to a system; in specific cases I may need to also be able to write to specific areas, for things like logging.
Designing Backup Scenarios
When designing a system I should be thinking about specific use cases. This example is a simplified one just for demonstration purposes at the top level, if i was providing a backup service, I may have thought of four basic user stories:
- As a backup technical specialist i want to back up all the files from my server in order to prevent data loss
- As a backup technical specialist i want to be able to restore individual back to a system in order to recover from a data loss
- As a backup technical specialist i want to be able to test my backups in order to ensure they work
- As a quality controller i need to see that backups, restores and tests are happening correctly to ensure the quality of my service
I am not providing a full set of use cases, because we would need to cover things such as restore time and point objectives, and would need to deal with complexities such as single file restore vs entire system snapshots, and I want to try and keep this blog short!
A quick service realization
Off the back of those 4 use cases I drew my first attempt at a service realization. It looks like this:
A full service realization would cover more around the process; our motivation models and user stories would develop this view further, but our focus here is to look at users and their interactions. There are a couple of thoughts that went into the design of figure 1.
- From the use cases its clear that there were two business roles i was working with, each needing different levels of access.
- In doing this design I know my security principles & control needs, so in the back of my head i am already designing for them. sometimes we may do this in several iterations – especially when i start to do my requirements realizations. It is way faster to develop things if you are familiar with the standards and controls you need to adhere to.
- I deliberately separated out logs from actual server data to meet some security principles.
- As a principle I already think what is the flow of information and the minimum level of access I need
User vs System Permission
Its important to understand the differences here. In our example our backup technical specialist would need to be able to backup, restore and test. He is a single user, and would probably be authenticated for access to a backup system portal with his own credentials. I didn’t model it here but he would probably be given roles in a backup application which would enable him to run different application processes. Its standard role based access control.
At a systems level things are more complex, and should be designed to be secure.
From looking at the access relations on figure 1 I can quite clearly see where I need to apply different levels of permissions. in our case we have 3 business processes – they are core processes, which make perfect sense to be accessing the systems with their own permission. From the service realization I could easily cut it into pieces to have a sensible scheme for permissions – it might look like in figure 2:
Our view here is telling us
- Our restore user needs to read backup storage, and read write to our server data & restore logs
- Our backup user needs to be able to write to backup storage, write backup logs, and read server
- Our test user needs to be able to read and write test server data, read the backup storage and write test server logs
- Our backup log reader user needs to be able to read backup logs, restore logs, and test server logs.
Figure 2 – is really just figure 1 organized into different users.
So what’s missing?
I didn’t show that I had specific reasons for creating the user access the way I have done. My thoughts would be lost if I didn’t document them some how. I could easily extend figure 2 to show this. Take a look at figure 3:
Figure 3 tells a story as to why we organized things this way, and like any architecture it is iterative. We would have arrived at our requirements when motivation modelling – we could also choose to show our principle on this requirements realization view in figure 3. I speak about motivation modelling in other blogs. Whatever makes sense to tell our story. Bear in mind we can also document any element and any relationship between elements. on the view i chose to label the relations in some places, but additional information could be stored in the documentation for the relations. Understanding why something is related to something else is something that’s easy to document in most modelling tools.
Note I added some users as application data objects there. From a systems perspective all a user is, is data. different applications use that data to authenticate using there own application process mechanism. I did this because i want to refer to these standard users and their standard permissions in the final part of this story:
I knew already when I was creating figure 3 that rules around information segregation would also need to be considered at a server level and that this would likely mean that the user structures I was creating at an application level would have to be split so i could ensure that compromising a single country does not compromise my entire solution. Figure 4 shows that each country we are operating in needs a data center in order to ensure that backups do not leave the host country. In our case we have allowed log files to leave the country so we can centralize our log management but we have a clear idea of the major data flows.
Summing it up
Designing this way is going to help when it comes to doing things like ensuring we have GDPR compliance, and making sure we follow security principles. At this point I may also chose to do either a basic risk analysis or maybe model some threat scenarios to look at different ways this design may be compromised. That’s a story for another day.
