Infrastructures are the foundations used to provide services: since services are subjected to confidentiality and availability requirements, infrastructures must be designed so to provide several confidentiality and availability tiers. This way a service can be placed on the part of the infrastructure that meets the availability and confidentiality requirements for its use case. This means that one of the very first things to do when designing infrastructures is defining the corporate's standard tiers.


Defining corporate standards provide a lot of benefits:

    • avoid reinventing the wheel each time, and so also avoiding  the risk of having several similar wheels that actually differ a little bit one another.
    • it is easier to express requisites, since it can be avoided to provide a detailed description of a requisite that has already been standardized
    • there is a lower risk of misunderstandings, both when designing and implementing as well as when operating on systems and services, since these should be tagged with the tiers they belong to.
    • it eases communication from business to technician, providing some well understood words that make senses on both fields

Availability tiers

Availability level means how available a component is: for example there are business cases that require 24hx5 availability, others that require 24x7. Some business cases may require an availability of 99.999% - that means only 5 minutes down per year.

Defining availability tiers is no mandatory - you may already have 99.999% infrastructure that let you provide any kind of service, but from the business perspectives probably you are wasting moneys: by defining availability tiers you can limit the high costs of fully redundant components and instead use more cheaper components for the less business-critical services.

Examples of availability tiers can be:

  • B1 – collateral system that does not directly affect the business
  • B2 – business bound system not so critical to the business
  • B3 – business bound system critical to the business
  • B4 – business bound system mission critical to the business


This is a very important concept you must get acquainted with: it is a best practice to define a few confidentiality tiers along with describing what they apply to.

Examples of confidentiality tiers can be:

  • S0 - publicly available
  • S1 - internal use
  • S2 - confidential
  • S3 - strictly confidential / business secrets

These confidentiality tiers must be used to tag both roles and the object (the asset) a role is granted access to; the access rule then is straightforward: a role can grant access to assets belonging to the same confidentiality tier of the role itself. Of course this requires to create multiple instances of the same role, one per confidentiality tier.

Do not assign confidentiality tiers directly to users! Besides being in contrast with the RBAC framework, his approach is not granular enough: a user may be entitled to access assets classified as confidentiality tier 3 for some purposes, and other assets classified as confidentiality tier 2 for other purposes. Confidentiality tier should be assigned only to assets and roles.


Designing infrastructures is more an art that a science. However there are best practices and guidelines that should be followed to avoid common pitfalls: defining availability and security tiers is certainly one of the very first thing to do, ... although I often see people underestimate this, maybe because they seem not so important at first. But as time passes by they will become more and more important. The identifier assigned to the tiers must be added only to the security objects that are used to grant an access level to configuration items: for example when designing  the corporate naming convention for the RBAC. But this will be the topic of another post.

Writing posts on this blog takes a lot of hours. I'm doing it for the only pleasure of sharing knowledge and thoughts, but all of this does not come for free: it is a time consuming volunteering task. This blog is not affiliated to anybody, does not show advertisements nor sells data of visitors. The only goal of this blog is to make ideas flow. So please, if you liked this post, spend a little of your time to share it on Linkedin or Twitter using the buttons below: seeing that posts are actually read is the only way I have to understand if I'm really sharing thought or if I'm just wasting time and I'd better give up.

Leave a Reply

Your email address will not be published.

You may use these HTML tags and attributes:

<a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>