Systems 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:

Figure 1 – A service realization

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.

  1. From the use cases its clear that there were two business roles i was working with, each needing different levels of access.
  2. 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.
  3. I deliberately separated out logs from actual server data to meet some security principles.
  4. 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:

Figure 2 – Breaking down into users

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 – Requirements Realization

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:

Figure 4 – considering technology and locale

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.

Requirements Realization Views

One of the most essential but often overlooked views to have on architecture is requirements realization. This blog explores this subject and one way we can work with them.

I show one way of working with Requirements Realization Views – Its not the only way. Doing this can save huge amounts of time and money by avoiding a need to redo things.

If you have read ISO 42010 the International standard for architecture description, you will know that every architecture view is intended to frame the concerns of its stakeholders.

Architecture isn’t about drawing pictures. Whist defining a view of technology is important, it is more important is understanding the reason why. We learn this in math class as children. The answer to a math question gives you points, but you also get points for showing work.

The Requirements realization view is one way to show how a solution meets the needs of its stakeholders.

I show below some example views and one way of working that can be used with BiZZdesign’s Enterprise Studio. Its the tool I use most often, so I leverage some of its benefits in my workflow. All the things I show can be done with other tools, some tools make this easier than others.

An Example View

Figure 1 – Requirements Realization View

The example above is a basic requirements realization view. Its at a high level – its showing that a product is meeting several requirements. The level of detail we go to depends very much on the benefit it would provide. The view in figure 1 – may serve as a good introduction to anyone wishing to understand the design from the Web Hosting Product. For the purposes of a high level introduction to business stakeholders that might be enough, but how do we know what is above is true?

The next level of detail

Each of the requirements in figure 1 is obviously a collection of other requirements – I might define them in architect, or I might just reference another source. For example – business unit requirements may exist and be managed in a system like Confluence. This might be a more accessible place for stakeholders to manage them if we do not want to go though the trouble of teaching everyone ArchiMate.

The next level of detail in ArchiMate

Personally, I do not always ask for everyone to go to the next level of detail in ArchiMate, because in a complex project with many moving parts it doesn’t always make sense, especially when you have different architects at different levels of maturity, especially when you have several thousands of requirements in a project

That said, there are advantages to mapping your requirements in Archimate. I know one or two architects that do it.

Using Enterprise Studio

Here tools can set you apart. Importing requirements from excel into an architecture model can be fairly easy in some tools. I am using BiZZdesigns Enterprise Studio (BES). – which makes it easy to import and update requirements if I create them using New > Multiple – I can then copy and paste in from excel. I could have done this other ways too and its probably worth the time taken to do that.. You end up with a lot of requirements on a view like this:

Figure 2 – Requirements

You might think in this case that this isn’t very helpful – its just a bunch of numbers – but what i did was import the requirement ID’s as names and I put the actual descriptions in the description or documentation field. In this way when I have many requirements I can make them smaller and more manageable on screen.

To actually see detail of each requirement I can switch on tooltips – so the documentation pops up when I mouse-over the requirement, or I can use labels.

Figure 3 – A requirement labelled.

So why bother?

Once I have the requirements on my canvas i can group them together – to organised them in different ways for different stakeholders. Something like in figure 4:

Figure 4 – Grouping Requirements

When I have done the above in big projects I have sometimes identified requirements that are not managed at all. In the example above you can easily see uncategorized requirements. They are not connected to anything and can easily be forgotten. Just by itself it makes the pain of the exercise worth while. I can also at this point prioritize them and then I normally take these requirements and connect them into a series of implementation and migration views.

Every requirement needs to be realized some how. I can pretty easily either script, or create a property table in Enterprise Studio to see requirements that are not realizing things as an extra level of validation. If we have mapped our requirements into groups, and created views for each group, then we should easily be able to see things that are not realized anyway. Back in figure 4 we did our mapping, and as a result of the mapping for example we may have decided to have 5 realization views:

  • Customer Requirements Realization View
  • Architecture NFR Realization View
  • Security NFR Realization View
  • Business Unit Requirements Realization View
  • Orphaned Requirements Realization View

Mapping Requirements to the Realization

Now with the prep work completed we get to the important part. Our Customer Requirements Realization View might look like something in figure 5.

Figure 5 – Customer Requirements Realization

Lets look closer at figure 5.

The standard web hosting solution

I make use of the grouping element in ArchiMate to represent architecture building blocks. Its enables me to keep things neat – I could have course have hidden this level of detail in another view & just connected in the Web Hosting Product. In this case I felt the services create value. I do not need the detail to know exactly which servers are being used but I can tell that this will be an Azure hosted solution, running on Linux. If you read my blog on services, you should at this point start to see the value of hiding architecture behind the externally facing services.

Standard Services Contract

Some requirements are covered by our standard products and some by our standard agreements. To use the ISO 42010 language again – Its important to see that concerns are all framed within one or more viewpoints. This means even if its obvious to us that something is covered in the standard contract we should state it. What is obvious to me is not necessarily obvious to a coworker.

Customer CRM

Of course I could put as much or as little detail as I need into this view. I am telling a story, which I talk about in my Improving Archimate Modelling Blog. The important thing to remember is that all requirements need to be realized in a view, but again not always the same view. Because we are telling a story we need to be consistent with the level of detail.

Locking Down Requirements

Before starting requirements realization its important to have requirements management under control. Its a separate subject, but you need to ensure that requirements are not significantly changing during a project, or the workload significantly increases.Going through the process of redrafting your realization view will provide benefit and avoid confusion.

Some Common Challenges

I have sometimes seen requirements realization being missed as a step. Sometimes people just create a technical solution, and say “yes” that meets the requirements after a first read through, Then later they realize it doesn’t because they didn’t look to this level of detail and are forced to go through a very expensive exercise of fixing things.

I have also seen things mess up because requirements management is seen as being a project managers job. Yes, those guys are responsible to ensure requirements are met, but not how they are met. I see the job of organizing requirements in a way that makes sense to the solution as being an essential part of an architects job. If you look at the TOGAF ADM for example you will see requirements management at the heart of everything..Its partly a separate conversation but I would also encourage architects to work with project managers to organize requirements in a way that makes sense, because it makes requirements realization a lot easier and reduces risk,

Another common issue if focusing too much on customer requirements. Its really common for organizations to have a customer first approach – but this doesn’t mean we should not consider our own needs. Business requirements are important, as are the architecture and security ones for example. If we do not consider them, issues will occur later – because they are there to mitigate risk. Some non functional requirements will relate to documentation and I can easily create a view for architecture deliverable requirements realization. In projects architects should ensure time is given to manage non customer requirements.

Summing It Up

I cannot stress the importance of doing requirements realization. In this article i focused mostly on doing requirements realization in ArchiMate, but we can actually do it in other ways. I wrote about the challenges of Designing Architecture Through Document Templates before – I personally try to avoid that for the reasons I state in that blog.

Requirements show us “what” needs to be done by “who”, and “when”. Requirements Realization shows us “how”. This is a message I think all architects should take to heart and communicate out to other stakeholders.

Yes, running through thousands of requirements can be boring but taking the time to properly manage and realize them can result in very high quality work. Requirements Realization can be cool.