AWS SSM for Improved Security, Auditability and Automation

Amazon Simple Systems Manager or SSM as we’ll refer to it throughout this article, is a great example of an important feature in the Amazon Web Services toolset that we try to highlight for our clients because of its DevOps, compliance and security benefits. As AWS partners recognized for our customer service and expertise, we are often asked about the implications of specific AWS features and their benefits.

If you aren’t already familiar with SSM, or could just use a refresher, it is a feature that sysadmins should really be aware of.  Amazon defines it as,

Simple Systems Manager (SSM) enables you to remotely manage the configuration of your Amazon EC2 instance. Using SSM, you can run scripts or commands using either EC2 Run Command or SSM Config. Simply put, SSM allows sysadmins to run commands remotely on to EC2 instances that are running inside AWS. SSM currently supports both Windows and Linux. Indeed, Amazon just announced that the Linux version of the on-instance SSM agent is now available on GitHub.

Foster Greater Security and Compliance

Organizations have traditionally used tools like SSH that allow remote access to servers. However, SSH enables practices that introduce weaknesses when it comes to security and compliance that SSM has been engineered to overcome.

Specifically, SSM has introduced some very powerful security features:

1. Restrict User Commands
   With SSM, you can restrict which commands users can run. This is significant for information security – especially for organizations within industries where there are especially high compliance or regulatory requirements. In our experience, these companies struggle greatly with how to monitor and audit users who have remote access and the capability to run commands on a system remotely. SSM addresses this issue in part by restricting a user by what commands they are allowed to run.
   
   
2. Restrict Target Systems
   While operating systems have traditionally featured controls for what files a user can (or can’t) edit and what files a user can (or can’t) access, it’s been traditionally very difficult to restrict what particular commands a user can (or can’t) run. However, with SSM, companies with high compliance and/or high security frameworks have the ability to control which user can run which commands and on which systems – all in a very granular fashion.

Every single command is run through either the SSM Command Line Interface or SSM Graphic User Interface, both of which log the actual command. Thus, who ran the command, from what IP address, and at what time is all logged for future reference. From an Information Security standpoint, this is a boon as it leads to a very strong audit trail that can be used for things like HIPAA audits, PCI compliance, and more.

SSM Use Case

We expect this feature to be extremely useful in a couple of cases. First, it will be especially useful for large enterprises with very tight security requirements. Second, we see this feature being quite helpful for organizations of all sizes who operate in the financial services, healthcare or similar industries where strict regulations are at play. The reason both of these groups will benefit from SSM is that it actively reduces the number of users who have the ability to run commands on a given server.

At Flux7 we encourage our clients to treat servers as cattle, not pets. Typically the reason people treat servers as pets (with given names vs. generic numbering, for example) is because they want to allow their users to log into the server. Hence, the server better have a constant domain name or an IP address that they can log into in order to remotely run their command.

Eradicating the Need for Remote Access

The question we almost always ask our clients is: “Why do you need to have access into the server at all?” The two answers we most typically get are
a) We need to copy logs out; or
b) we need to be able to debug an application by starting or restarting the service efficiently without having to re-cycle the entire server.

Fortunately, SSM provides a great solution to both of these reasons. SSM allows you to a run remote command on a group of servers concurrently through a single unified interface while creating the audit trail we discussed above. It does this while not requiring users to have direct access to the server through SSH or remote desktop.

This enables the best of both worlds: users can do something that is not yet been fully automated and the servers at the same time can be treated as cattle. In the process, SSM delivers a major DevOps benefit in the form of automation while providing significant security and compliance benefits.

If you are interested in understanding how SSM could help better secure your environment and generate better audit outcomes through improved logs, then contact our DevOps consultants today; we’d be happy to have a conversation about how SSM can help automate, secure, and provide greater auditability for your environment.

Did you find this useful? 

Interested in getting tips, best practices and commentary delivered regularly? Click the button below to sign up for our blog and set your topic and frequency preferences.