When moving to an AWS infrastructure, responsibility for security is shared between Amazon and your organization. Amazon’s Shared Responsibility Model clearly shows where both parties’ responsibilities begin and end. AWS secures the lower layers of the infrastructure stack, while the organization is accountable for everything else up to and including the application layer.
Six security best practices for organizations moving to AWS
Extend your common security model
Conventional security and compliance concepts still apply in the cloud. Whether we’re talking about existing apps migrating to the cloud or new ones being built there, they must be secured and good practices still apply. You can minimize the time and resources required to achieve this by leveraging the processes and technologies already in place within your organization.
Identity silos expand your attack surface, increase overhead and lead to identity sprawl. Rather than create additional local AWS user accounts and Access Keys, use existing identities (e.g., Active Directory) and enable federated login. Federation enables you to grant an existing user identity within your enterprise directory the appropriate rights to access any AWS service. This avoids identity sprawl, issues with identity duplication and synchronization, and the need to provision and manage yet another identity silo.
Shared privileged accounts (like Amazon ec2_user and Windows administrator accounts) are anonymous. To ensure accountability, it’s important that users log in with their individual accounts vs. shared anonymous accounts and elevate privilege as required. Entitlements can be managed centrally from Active Directory, and roles and groups can be easily mapped to AWS roles. All user activities across a hybrid enterprise can then be tied back to unique individual users for 100% accountability. Privileged login sessions should be video recorded and all attempts to log in to AWS portals and Amazon EC2 instances as well as all privilege elevation attempts should be audited and recorded.
Least privilege access
When it comes to the AWS Management Console, AWS services, Amazon EC2 instances and access to hosted apps, users should be given the just enough privilege necessary to complete the task at hand. Centrify customers leverage their existing directory infrastructure to manage and audit the roles and rights that give each user the appropriate access at the AWS service level and at the Amazon EC2 Instance level. Any IT user or group from any directory service can be added as a member of a Centrify role, which is then mapped to an AWS role to assign granular rights in the AWS interface.
Log and monitor authorized and unauthorized user sessions to Amazon EC2 instances. Admins can log in directly with individual accounts, or they can log into the shared password management portal and (if their role allows) log in remotely to an instance using their enterprise credentials. Activities can be audited via session-recording at the proxy or host level, but preferably at the host level to ensure visibility in the event a proxy is bypassed. Centrify Auditing & Reporting, AWS CloudTrails and CloudWatch can be used to help associate all activity to an individual, and for reporting on privileged activity and access rights.
Highly sensitive actions may require additional user validation, the best practice is to use multi-factor authentication (MFA) everywhere. Even with the appropriate role, users must assure their identities with an out-of-band factor like a push notification to a pre-enrolled mobile device before certain actions can be performed. This can significantly increase confidence in identity assurance, preventing attackers using compromised credentials common in the latest cyberattacks. Implement MFA for AWS service management upon login and privilege elevation for Amazon EC2 instances, when checking out vaulted passwords and when accessing enterprise apps.
For a more detailed guide to securing your organization’s AWS cloud environment, download this white paper. Inside you will find details for 3 common use cases.
This is written by the individual author in his/her personal capacity, and the opinions, views and/or thoughts expressed herein are solely the author’s own. They are not intended to and may not necessarily reflect the official policy or position, or the opinions or views of ThycoticCentrify or its affiliates, employees, or any other group or individual.