How Druva securely manages almost a hundred AWS accounts

Previous approaches to managing cloud access

Previously, cloud access was managed by leveraging individual IAM users/groups and long-term credentials (access keys). User activities were recorded via CloudTrail for each AWS account and region separately and had to be manually enabled for each new AWS account created and new region opened. IAM users’ MFA had to be enforced using IAM policies. Users had to use multiple browsers or switch roles manually to access multiple AWS accounts. Also, each IAM user had broad access because access control would come from the IAM policy level. In addition to this, some applications had separate login consoles. Onboarding a user and the access revoke process was time-consuming. Keeping track of all access keys and rotating them within security the SLA was also overhead. 

How did Druva solve the problem?

We enabled AWS organizations to centrally manage and govern the environment. Using AWS organizations, we had the capacity to create/suspend new AWS accounts within minutes and allocate resources, group accounts to organize workflows, apply policies to accounts or groups (for governance, guardrails, compliance, audits, etc.), and simplify billing and logging by using a single payment method and CloudTrail log stream for all accounts. 

Diagram Source: AWS blogs

Additionally, we migrated to AWS single sign-on (SSO) which seamlessly allowed us to centrally manage SSO access to multiple AWS accounts and business applications. It enabled users to sign in to a user portal with their existing corporate credentials and access all assigned accounts and applications from one place. 

Diagram Source: AWS Blogs

Securing organizational trail and simplifying SIEM 

With the organization's trail, we had the ability to record all user activities across all accounts and regions automatically. This log was stored securely and indefinitely in a separate highly restricted AWS account in a security-hardened and tamperproof S3 bucket. We ensured that the trail was enabled globally and in multi-regions. CloudTrail log file validation was enabled for logs integrity. S3 bucket access was highly restricted, controlled, and recorded in a separate bucket using a combination of S3 access logging, bucket policy, and the CloudTrail as well as access log files were encrypted to the highest industry standard. All public access to the buckets was blocked. We implemented SCP to ensure that the CloudTrails could not be disabled by anyone. On top of that, we pushed the trail logs to our internal SIEM tool to alert us in almost real-time of any unusual activities before taking action to remediate any incidents. Our alerts were carefully designed to reduce noise and only deliver critical “actionable” events so we could promptly take action. 

Security enhancements

• We use short-term credentials instead of IAM access keys. This massively improved the cloud security posture.
• We enforced multi-device multi-factor authentication (MFA) and ensured a strong standard password policy for all AWS users and applications.
• We control onboarding and access to various resources and applications with a single click and from a single console. 
• We have a centralized inventory of all AWS accounts, users, groups, permissions, and applications.
• We regularly audit access by leveraging AWS access analyzers to implement PoLP (principle of least privilege).
• We manage multiple services from one single console for all AWS accounts (like AWS access analyzer, AWS GuardDuty, AWS artifacts, AWS config, AWS CloudTrail, tag policies, etc.), which ensure common standards in the organization. 
• We apply guardrails to various accounts using SCP (for example, blocking certain AWS regions, services, APIs, and destructive actions, etc.).
• We use standard tagging rules and consolidated billing; this was extremely powerful in tracking and analyzing our AWS bills to save costs. On top of that, SCP ensures that each team can spin up resources to their exact business needs without overprovisioning. 

Lesson learned

We curated access to the exact business needs of users while securing our cloud with a standard set of logs, rules, guardrails, and policies across the organization. This enhanced security and compliance. Most of all, it increased collaboration between various teams during the change process and opened doors to many security conversations and feedback on AWS accounts and access management. Because, at the end of the day, there are not just “users” but actual humans who use the system and work towards a common goal. 

Summary

Druva has almost a hundred AWS accounts and ~500 users across various teams performing thousands of operations on multiple services and regions. So how does Druva securely manage access, record, store, analyze, and remediate account activities in almost real-time? The short answer is, through a combination of services — AWS organizations, AWS Single-sign-on (SSO), AWS service control policies (SCP), AWS access analyzer, organization trail, and a scalable SIEM tool.

Next steps

Learn more about the technical innovations and best practices powering cloud backup and data management. Visit the Innovation Series section of Druva’s blog archive.

Join the team!

Looking for a career where you can shape the future of cloud data protection? Druva is the right place for you! Collaborate with talented, motivated, passionate individuals in a friendly, fast-paced environment; visit the careers page to learn more.

About the author

I have been in the cloud tech world since 2015, wearing multiple hats and working as a consultant to help customers architect their cloud journey. I joined Druva four years ago as a cloud engineer. Currently, I lead Druva’s cloud security initiatives, roadmap, and planning. I love to approach cloud security pragmatically because I strongly believe that the most important component of security is the humans behind the systems. 

Find me on LinkedIn: https://www.linkedin.com/in/aashish-aj/

Get my hands-on style weekly cloud security newsletter. Subscribe here

Email: aashish.aacharya@druva.com