11 April,19 at 11:50 AM
Background
Amazon AWS is at the heart of many of our customers workloads. Last year I started a series of tech blogs to discuss how to leverage Centrify's product portfolio to secure your AWS assets.
This year, I've had the opportunity to review the AWS Security Best Practices document and in this new series we'll provide guidance on how to implement controls to meet or exceed the Shared Responsibility Model.
About the Shared Responsibility Model
The concept is very straightforward. Amazon AWS will implement controls to provide assurance for confidentiality (e.g. encryption at rest and in transit), integrity (transaction trust), availability (redundancy of hardware, power, etc), however, depending on your business requirements, you may need to add additional controls to increase your security posture or to provide assurances to your customers beyond what's offered by AWS.
Amazon AWS Defines a "Shared Responsibility" model that has the following scope
In this article we'll focus on how to use Centrify Identity Service (or Privilege Service) to secure the Amazon Account.
What's the Amazon account?
The amazon account (or Amazon root account) holds the keys to the AWS Kingdom. This is the first account set up, most likely used to set up billing, IAM roles and groups, keys, etc.
What constitutes a bad practice?
If your organization is sharing the Amazon account with several members of your IT staff and you're not adding additional controls around it, you are going against several security best practices.
What is Amazon's guideline?
Amazon's guidelines are simple:
The basic guideline is to implement a model of least privilege access. At Centrify that's what we have traditionally preached in the context of Operating Systems and Apps. Additional complexity is added depending on your AWS deployment model. This is an except from the AWS Security Best Practices document (August 2016, Pg 16).
How can Centrify help?
Centrify Identity Service (and Privilege Serivce) provide a simple-to-use federation engine that allows the implementation of Amazon IAM without the overhead of federation services. In addition, it provides a powerful policy and multi-factor authentication engine that allows the deployment of controls to secure the account.
Enhancements since the previous entry
Last year when I wrote the original post, I outlined how to implement MFA to secure the root account. The Amazon AWS (User/Password) app is deployed leveraging the password wallet built-in to the platform. Since the password is securely replayed, users just click on the app link, they don't rely on shared credentials.
A big benefit of our approach was flexibility. In addition to Smart Card or Yubikey for pre-authentication, you could use the Centrify Mobile Authenticator and individual OATH codes for each user, you could use Phone factor, e-mail, SMS and security question as step-up authentication when the application is lauched.
Enhancements since last year
Example
With Centrify assets, you can deploy controls that limit access to users that have been explicity approved access to the application, and to use the Amazon account they must use multi-factor authentication, only from inside the corporate network and during business hours. You can have different combinations of controls on different environments (accounts).
Conclusion
With Centrify Identity Platform (Identity Service and Privilege Service) not only you can meet, but exceed the Shared Responsibility of securing your Amazon account.
Demo
In this demo, we implement three controls:
- Documented Approvals (with ServiceNow)
- Secure the shared password (not available/visible)
- Multi-factor Authentication
Related Articles
AWS Shared Responsibility - Securing Windows AMIs with Centrify Windows MFA
AWS Shared Responsibility - Securing Amazon RDS Instances
AWS Shared Responsibility - Securing Linux Systems using Centrify's new Identity Broker