A Step-by-Step Approach to a Secure AWS Environment

Posted on by Hardeep Singh

Secure Your Access

APIs drive the success of the public cloud and make infrastructure as a code possible. While APIs provide the ability to rapidly scale the environment, they also expose the underbelly of the public cloud. APIs need to be authenticated, and long-term credentials used by operators and pipelines get leaked. One potential solution is to move away from static to dynamic credentials by leveraging trust relationships afforded to compute resources by the cloud environments. Some examples: AWS EC2 granted trust via linked IAM roles, and Kubernetes Pods granted trust via namespaces. These trust relationships enable a generation of temporary credentials that can be used by applications to make API calls to the cloud infrastructure. Ephemeral capabilities can also be afforded to applications via native secret management service like AWS Secret Manager, Kubernetes secrets storage or external services like HashiCorp Vault. These services can be extended to enable automated credential rotation.

Ephemeral access for human operators is enabled by extending the corporate AuthN boundary to the cloud, since most cloud providers can integrate their IAM service to an external Identity Provider via SAML or OpenID Connect. Corporate SSO enables MFA-backed authentication that is authorized via the cloud RBAC. Users get mapped to the AuthZ flow via membership in one or more IdP groups. Since all members in the group inherit the privileges of the mapped role, it is a good idea to have granular IdP groups created for narrow business needs, and RBAC policies granting minimum privileges necessary for the job. Rather than granting some groups elevated privileges all the time, it is better to enable just-in-time elevated access by mapping privileged IdP groups to a pager duty roster.

Segregation Is Not Always a Bad Thing

Organize your public cloud environment, at a minimum, into production, staging, Infosec and playground. Keeping the novices in the playground will prevent them from inadvertently exposing your production assets to the world. Add guardrails to each organization to enforce policies like tagging of resources, encryption of storage and use of sanctioned images.These guardrails prevent accidental or intentional noncompliance, even by administrators.

The public cloud by its very definition is as such, so critical resources should be further isolated by placing them in virtual private clouds inside each organization. This not only limits their visibility to the outside world but also controls access from inside the perimeter. Proper configuration of firewalls via NACL’s Route Tables and Security Groups enforces proper network segregation. All public-facing bastions must be placed behind corporate VPNs with gateways for restricted environments limited to selected groups.

Zero Trust can be achieved by judicious use of granular groups, guardrails, policies and firewall rules to control “who can do what to which resource from where and when.”

Only the Paranoid Will Survive

A robust Threat and Vulnerability Management system covers logging, monitoring, scanning, patching and change management process. A CI/CD pipeline should continuously push scanned and patched golden images to all organizations. These base images should be configured to collect and forward system auth logs, activate endpoint protection, and setup AuthN and AuthZ mechanisms.

Store API, network, database, storage, access, IdP, pipeline and application security logs in the Infosec accounts for compliance and forensic purposes. These logs can be streamed to cloud native analysis services like AWS GuardDuty, or to external ones like Splunk, Sumo or even your own ELK Stack. Many of these services provide environment-specific SIEM modules. In order to deliver an auditable change management process, only allow the CI/CD pipeline to make changes to infrastructure. Monitor the logs to alert on any changes made that are not linked to the pipeline roles and endpoints. Setup alerts on behavior changes of human or service roles-based activity that could indicate leaked credentials or rootkits. Alert flows can be targeted from the owner of the role all the way to Infosec and management.

In the end, no matter how good your defenses are, you have a determined opponent. Have a contingency plan on how to quickly recover from a successful attack. Periodically simulate a security incident and incorporate lessons learned to reduce the blast radius. Good internal pen testers are worth their weight in company stocks.

Hardeep Singh

Principal Security Architect , Upstart

Cloud Security & Virtualization Security Strategy & Architecture Technology Infrastructure & Operations

cloud security security architecture

Blogs posted to the RSAConference.com website are intended for educational purposes only and do not replace independent professional judgment.  Statements of fact and opinions expressed are those of the blog author individually and, unless expressly stated to the contrary, are not the opinion or position of RSA® Conference, RSA Security LLC or any other co-sponsors. RSA Conference does not endorse or approve, and assumes no responsibility for, the content, accuracy or completeness of the information presented in this blog.

Share With Your Community