Live Demo
Blog   >   Cloud Security   >   System Access and User Accountability in the Cloud

System Access and User Accountability in the Cloud

Evaluating Your Security Mechanisms

Throughout the IT industry, security mechanisms are used to allow or deny access to objects, such as a file, by subjects, such as an individual. A complete security mechanism consists of five elements: identification, authentication, authorization, auditing, and accountability. If any one of these elements is missing or misconfigured, the security mechanism is flawed and attribution of a subject’s action on an object can be questioned. This is nothing new, and applies to the cloud as much as it does to a traditional environment.

In this post, I will review some common aspects of access permissions and touch on how they relate to cloud infrastructure.


The first step of a security mechanism is initiated by a subject providing some form of unique information, such as a username, which is used to uniquely identify a subject. By itself, an identity does not prove anything, but once the identity is verified through subsequent steps in the security mechanism, the identity is accountable for actions taken by the subject that it is tied to.


Now that you have the identification piece, the next step is proving you are who you say you are through authentication. Identification is not enough; a user must also provide some way to prove their identity. This is where passwords and other authentication methods come into play. To make sure one user does not claim to be another user, each user must have unique credentials to identify themselves.

Three types of authentication factors can be used for authentication. Type 1 is “something you know”, such as a password. Type 2 is “something you have”, such as a physical hardware token or smartphone. Type 3 is “something you are or do”, such as biometrics or behavior. Each type is a progressively stronger means of authentication. Traditionally, Type 1 was sufficient for performing authentication, but with the frequency of fraud, bad password practices, and the use of social engineering, stronger authentication factors are needed to strengthen authentication beyond “something you know”. To provide this protection, multi-factor authentication (MFA) should be enabled for all users. The more methods used for authentication, and the higher level the types, the stronger your authentication will be.


Once a user or service is successfully authenticated, it is important that they only be authorized to access specific resources that they need to perform their tasks. This means implementing the principle of least privilege, where users are only given the least amount of privileges necessary. A mistake that is commonly made when applying these privileges, is to directly apply the privileges to users. A better way to do this, is to apply privileges to groups, then make the user a member of a group. If a user changes roles within the company, or no longer needs access to certain privileges to perform their job, it is easier to remove them from a group than to audit each of the privileges that has been assigned directly to their user. AWS takes this a step further through the concept of AWS Managed Policies, where common job functions and access levels for services have been predefined, allowing administrators to simply apply a managed policy to a group, then apply that group to a user.

As an aside, once you have the basics down, you should explore tools like AWS IAM roles. Any sophisticated AWS environment will use IAM roles to temporarily and securely authorize users or services in specific situations when certain conditions are met.


Assuming that identity, authentication, and authorization have all been handled properly, the next component necessary is a method of recording the user and what actions they performed, when those actions occurred, and where they performed them. By auditing the user’s actions in this way, the user can be held accountable for their actions on a system. Certain best practices should be followed when implementing an auditing system. This includes monitoring server logs and preserving integrity and providing redundancy by sending the information within these logs to a centralized server.


By strongly implementing all of the previous steps in the security mechanism by using best practices, accountability is much easier to achieve. But this is not all that is required for accountability. It is also necessary to review these logs to identify user behaviors. This is made easier through real-time alerting, where anomalous and suspicious activity can be brought to the forefront for ease of triage.

Fortunately, you are not alone in your efforts to ensure that you have a complete security mechanism in place. Through continuous monitoring, real-time alerting, actionable behavioral analysis, and security services to supplement your team, Threat Stack can help you gain visibility into your environment and offer the guidance you need to level up your security mechanisms.

Common Security Mechanism Mistakes

Using the AWS Account Root User

I’ve lost count of the number of times I come across organizations that are logging into the AWS console using the root user to perform various tasks within their AWS environment. When they come across a situation where a standard IAM user does not have the necessary permissions to perform an action, they will simply revert to using the root account, since it is able to perform any action. Although this may be convenient, it breaks identity and accountability, and provides the highest level of authorization available, violating the principle of least privilege.

In almost all cases, standard IAM users should be used to achieve a desired action on a system. There are rare exceptions to this, such as changing your AWS support plan, and Amazon has specifically defined tasks that require root.

When root login is required, all activity performed during the session should be logged appropriately for auditing purposes, leaving no ambiguity as to why the root login occurred, what actions were performed, and who performed the actions. Preferably, the actions should not be performed by a single individual. One should perform the actions, while another observes, audits, and logs the activity. This is not only good practice for security reasons, but can also help prevent accidental mistakes when making a change. If you want to take this to the next level, have one individual possess access to the root user credentials while another possesses a physical MFA device. This method provides an additional strong MFA factor by disallowing root login without the interaction between individuals.

Access Keys for the Account AWS Root User

For similar reasons to why individuals login as the root account, they also create and access their account programmatically through the use of an access key assigned to the root account. This allows anyone who has access to this key to perform any action within the AWS environment.

If the root account has an associated access key being used for programmatic access, this key should be removed and replaced with role-based users and access keys that follow the principle of least privilege. The program or service should only be allowed to perform actions that it needs in order to perform its task.

For more information on best practices for root access keys, see:

No Password Policy in Place

This seems pretty basic, but often it is the simple things that are overlooked. Until very recently, AWS hasn’t required a password policy by default, and it was on you to put one in place. Without a strong password policy, this weakens authentication within the security mechanism.

We recommend using the following password policy for AWS users:

  • Require at least one uppercase letter
  • Require at least one lowercase letter
  • Require at least one non alphanumeric character (! @ # $ % ^ & * ( ) _ + – = [ ] { } | ‘)
  • Require at least one number
  • Minimum length of 14 characters
  • Prevent reuse of last 24 passwords (maximum)
  • Require password rotation at least every 90 days
  • Require administrator reset upon password expiration

The good news is that AWS recently announced a set of sensible requirements for a new default IAM policy that will take effect on August 3, 2020. You can, however, still set your own password policy requirements. For more information, as well as instructions on how to set a password policy within AWS, see:

Failure to Use MFA for User Authorization

Setting up a strong password policy satisfies authentication factor Type 1, but due to the prevalence of fraud and the fact that most users share passwords between their accounts, it does not offer a strongly defensible form of authentication. For these reasons and others, all user accounts should require multi-factor authentication (MFA) for authorization. Multi-factor authentication usually entails the generation of an expiring one-time code (OTC) from either a Virtual MFA Device, such as a smartphone, or a Hardware MFA Device, such as a security token.

For more details on MFA and how to set it up, see the following articles:

For most user accounts, a virtual MFA device should be sufficient.

For the root account, a hardware MFA device should be used instead of a virtual MFA device:

Using Shared Accounts

A common mistake is the use of a single user account between multiple members of a team or an individual’s user account being used for running automated scripts, making identification difficult or impossible. Although it might seem convenient, this can make it difficult to identify who actually performed actions and opens the possibility of plausible deniability or false attribution, breaking accountability (identity management mayhem, as it has been called). It is important for each user to have their own individual user account, preferably their name or an abbreviation of their name which can be uniquely tied back to them. Users should be applied to groups while following the principle of least privilege. Likewise, services should have an associated username/account, which is assigned to a group allowing only permissions that that service needs to accomplish its task. The most common example of this mistake involves the use of the root account by multiple users and/or services.

And please, whatever you do, do not share access to the root user, especially for accomplishing everyday tasks. You should only do it as an absolute last resort. Unfortunately, we still see users sharing root this way in the wild.

How Can Threat Stack Help?

While we can’t stop employees from sharing root access, Threat Stack can alert you to suspicious root activity (and sudo usage, for that matter) as soon as it happens. Threat Stack’s continuous, detailed level of monitoring is especially helpful for long-term auditing of root usage in your environment, given the difficulty of keeping tabs on root in Linux. It might not seem like a pressing concern today, but you’ll want to be able to easily pull these artifacts for your next compliance audit, whether that’s PCI DSS, HIPAA, SOC 2, etc.

For more on how Threat Stack can help track root activity across your EC2 and AWS Management Console, we’d love to learn more about your environment and work with you on a tailored demo. Thanks for reading!