The shared responsibility Model

I can tell, you’re wondering, where to start? I know you’re trying to catch up with application teams who are releasing new features or bug fixes daily and have a lot to worry about. I know it’s tempting to jump to the cool stuff and start enforcing policies via automation or other means but understanding your responsibilities as a customer is where you need to start, so start with the shared responsibility model because you are going to avoid lots of rookie mistakes in the long run.

Depending on your choice of AWS compute service (EC2, ECS/EKS, or lambda, etc) or public Cloud model (IaaS, PaaS, or SaaS) your responsibility as a customer could change radically, but we won’t cover that in detail on this post because this can be an article on its own.

High level though, you should be very anxious about securing your data as you can’t offload this responsibility to AWS, it’s your obligation no matter what AWS services your use or public cloud model you adopt.

The more you move toward serverless, the less you will have to worry about patch management and OS level security hardening nightmares.

The same goes for your public cloud model, the more you move toward SaaS, the less you have to worry about infrastructure security. Please note, I am not advocating for SaaS, I am just stating facts.

Public Cloud Models

The Multi Account Model

After understanding your security responsibilities as a customer, it’s time to think about implementing governance at scale. One of the significant lessons early adopters learned are; deploying your applications on a single AWS account is a dangerous practice as it complicates your cloud management processes from a security and cost management standpoints.

AWS Accounts Architecture

I will let you decide how you architect your accounts, but the above diagram illustrates a common pattern.

You need a sandbox account for your developers to try new cool things, and formal Dev, pre-Prod, and Prod accounts for each product. Have a logging account where you aggregate all you CloudTrail logs, Config rules, S3 access logs, and other security-related data that auditors may need access to in the event of a breach.

You also need a management account that you use to enforce policies on your other accounts. Try to delegate billing to a billing-Admin account instead of using your master account. Use the master account to apply organizations service control policies on your linked accounts.

Resource tagging is a huge issue and cost control is one of the significant problems the enterprise is facing today. Again, multi-account model to the rescue, since you have deployed each product on a separate AWS account, you know that “product team” can eat the entire bill and you shouldn’t worry too much about their tagging shortcomings event though I believe tagging is essential for many other reasons.

Lots of AWS customers who used a single account for all of their applications experience the pain of increasing services limits. You have many engineers competing for a limited amount of resources (s3 buckets, computer resources, and others) not to mention that AWS have some hard limits that they can’t increase for you.

My all-time favorite benefit of the multi-account model is the limited blast radius it offers. I can make sure Dev team A does not have access to Dev team B’s accounts, so they don’t break their stuff. I can also go to sleep at night knowing that if my cat’s image processing product on AWS account 120 was to get breached my other products on the other AWS accounts won’t be impacted. I think you now see the benefits of using this model :) and it does not cost you more money! AWS accounts are free until you start using resources.

Cloud Enablement

Make sure you do whatever it takes not to block your developers for no good reasons. It’s very had to achieve that balance between allowing developers to move fast and making sure your environments are secure. Start by making sure your developers know that you are not there to be the blocker but rather the enabler.

Establish an agreed upon security baseline that needs to be on each account for your business to be compliant with your industry-specific regulations.

Anatomy and velocity are essential to your business as much as security so make sure you align your security practices to your business so both work together in harmony, this is easy said than done as it takes lots of evangelism, understanding of your products and infrastructure in addition to all your compliance requirements.

Automation & Policy as Code (PaC)

I don’t know about you, but the idea of architecting security policies in code and having them deployed to production within minutes is very cool. You can version control your policies, know who made a lousy merge and what was the last good version to good use.

Remember when developers had to wait five weeks for you to approve that firewall request? Well, those days are gone. Developers can now create security group rules in a few seconds and open port 22 to the world in less than that.

Developers never cared about your tedious documentation that is filled with outdated security policies, they never read them, and they will never do even if you spent your valuable time updating them.

So what should you do? If you’re thinking about automating your security policies, you should pat yourself on the shoulder. To keep up with speed, the cloud provides your business; security policies need to be as elastic as your infrastructure. You need to move as fast or as slow as your application teams.

There are many ways to define policies on AWS, AWS organizations service control policies, IAM policies, and service-specific policies such as KMS keys policies and bucket policies.

Automation enables that flexibility, and codifying your policy is incredible since you can treat your security policies as your infrastructure and application code. Policies can be checked in git, revised, improved, refactored, looked at by multiple people, and everything that applies to application code can be applied to your policies code.

You can use services such as Lambda and CloudWatch events or leverage open source tools such as Cloud Custodian to help you achieve compliance via automation.

The point is, automate your security controls or be prepared to lose this battle.

Real-time detection, notification, and remediation are very cloud and human-friendly.

If one of your developers open an s3 bucket to the world during a Prd deployment, detect that, notify them immediately that you have detected the issue and fixed it for them. If you discover security findings two weeks after that product went to production convincing the builder to fix it would not be a fun exercise. Real-time feedback is usually well received as they can be acted upon immediately.

Identity and Access Management

AWS IAM, the heart of AWS security. If you talk to IAM ninjas, they will tell you that getting AWS IAM right is a game changer as it is one of AWS most powerful services in my humble opinion.

AWS IAM enables you to define very fine-grained policies that help you set boundaries and implement least privilege principles with ease. IAM integrates with all AWS services even services that allow you to establish policies directly on them such as s3 and KMS.

The key with IAM is to use roles and assume those roles instead of having to use API keys everywhere. Also, automate the creation of policies, groups, and roles as much as possible and have a well-defined naming conversion for your policies, roles, and groups to avoid configuration drifts. Understanding conditions and IAM actions can be tricky, but it is indispensable if you’re trying to have a firm handle on your access policies.