7 level security classification model

Posted by in Devops, Technology

When you start building your infrastructure, your servers cross communicate with each other which brings in lot of security risk. To reduce this risk you should have some way to organize/classify your servers. The idea behind this model is to define how critical is the server from the security point of view. Hence, this level model works very well.

Server Class Level Description Example
Public + Subnets behind Level 0 Any server in our infrastructure which is accessible from public, and which is a hop for other services NAT Gateway, VPN
Auditing | Monitoring Level 1 Any server which has capability to log into other services Deploy Server
Production | Third Party Services Level 2 Any server running in production environment, dealing with production environment Application, Data Science
Public + Isolated Level 3 Any server in our infrastructure which is accessible from public, but working in isolation. Blog Server
PreProd | Staging Level 4 Any server not running in production mode, but bearing production-grade data. PreProd DB
Feature Server Level 5 Any server which runs on feature environment and bears code crucial to our system Feature Environment
Other Servers Level 6 Any other server running some other service. Testing/Experimentation Server

Once you have classified the servers there are certain properties which need to be enforced:

  • Each class of server would have different PEM to access them. This is from AWS point of view. Where when you launch the server you define 7 different key pairs. Ideally, you should not share the PEM with anyone. Those are supposed to be only used once for spawning, even better approach would be that creating your custom base ubuntu server which can auto download ssh authorized keys based on the server tags. I will write a post on this soon.
  • Gatekeepers would be defined to get access to the server. The idea behind this is that having security level gatekeepers, i.e. a level 0 person can access almost all servers in your infrastructure and so on. Thus, gatekeepers for each level can give access to his/her level only.
  • Each class of server can not co-exist in the same subnet. This is to further reduce the risk of accidental access to servers.
  • A higher security level server cannot access lower level server. So level 6 server can in no case access a level 5 server. Because the level 5 server has more privileges and less vulnerable compared to level 6, so if you are exposing level 5 to level 6 you are exposing the vulnerabilities to level 5 as well, which will cause the entire model to fail.

I believe following this model of classification will help you not only from as aspect of security but also when giving access to your team. You can extend this model and add/subtract more levels depending upon your use case.

If you have questions or concerns, leave them into comments and I will definitely get back to you.