With an ever-growing footprint on the public cloud, including production environments, security is at the forefront of Zuora’s business priorities. Having selected AWS as our public cloud vendor of choice, security for our AWS Infrastructure services is built on the Shared Responsibility Model. This essentially means that AWS is responsible for the security of underlying cloud infrastructure, but AWS customers are responsible for the security of cloud resources provisioned using the infrastructure.
AWS provides its customers with several security tools and features, and as a customer, our responsibility is take full advantage of these features to secure our cloud infrastructure. What follows is a description of some of the features and best practices that, from our experience, can help bootstrap your own AWS Cloud Infrastructure.
Root Account Security
The root account provides extremely powerful privileged access. Do not use the root account for day-to-day use. One of the best ways to protect your account is to avoid generating an access key for your root account. Also, don’t forget to enable MFA for your root account.
IAM Best Practices
AWS Identity and Access Management (IAM) allows for the creation of users, groups and roles - each of which is a more streamlined and standardized way of providing access permissions. A few must-have IAM features and best practices include:
Enabling MFA for IAM Users
IAM password policies aligned to your company’s information security policy
Least Privileged Access with managed IAM policy
Regular audits of unused IAM Access Keys
Using IAM Roles for EC2 Instances
Segment Your Network
Leverage AWS Virtual Private Cloud (VPC) features, including subnets, routes, Internet and NAT Gateways to create a segmented network per your business need. Most web architectures should fit within the following basic 3-Tier architectures:
Perimeter Tier: Hosts ELB and NAT Gateway
Application Tier: EC2 instances that host frontend and backend applications
Persistent Tier: Hosts database servers & services: RDS, MySQL, Redshift etc.
Whether you follow a multi-VPC or Single-VPC architecture (usually driven by your organization policy or VPC limits), you should keep Command & Control (CNC) in a separate VPC outside your service VPC. CNC VPC should host DNS, SMTP, Jumphosts (a.k.a bastion hosts for single point of entry to other hosts) and monitoring services, to name a few. This way you will be able to build simple IAM policies to limit access to CNC Services.
Security Groups & Network Access Control Lists (NACLs)
The stateless firewall of AWS, combined with VPC subnets and routes make Security Groups a convenient way to support your desired network segmentation. Some general best practices for Security Groups include:
Create function or tier specific security groups and define standard set of policies for each category
Setup continuous monitoring around those security groups to review changes
All inbound connections from public network restricted via Elastic Load Balancer (ELB)
All egress traffic to the internet are routed via NAT Gateway
Enforce a standard tagging policy for Security Groups to distinguish them by tier, environment or application. Once you have so, you will be able to monitor easily right security group(s) are applied to right resources
Some of the key best practices to follow while creating policies for Security Groups:
Do not allow wide open (unfettered) access to instances from world (0.0.0.0/0 to all-ports).
Allow management services (SSH, RDP etc) only from authorized sources, such as Jumphosts
Allow database (MySQL/3389, Redshift/5439 etc) ports only from application subnet
Do not allow database ports from public network
Access to world (0.0.0.0/0) is restricted for customer facing application protocols (e.g. HTTP/HTTPS) via ELB
Internal service/application ports (8080, 8443 etc) are restricted from ELB (Security Group) only
Audit them regularly to identify unused and wide open security groups
Encryption at Rest
This is a cool feature we really like using in AWS. In the good old days, whenever we wanted to enable encryption, we always had to be cognisant of performance implications. In AWS, IOPS are guaranteed with or without encryption, which makes “enable encryption wherever you can” practical and realizable. Some of the key places to consider encrypting at rest include S3 SSE, RDS, Redshift, and EBS Volumes.
Simple Storage Service (S3) Security
If your organization uses S3 storage to store critical data, here are some best practices you should consider:
Ensure that S3 buckets that do not need public access are set as private
Access to private buckets are restricted via VPC Endpoint
Enable Server-Side-Encryption (SSE)
S3 access policies can be managed at multiple places, so auditing might sometimes become tricky if they are not managed properly. Use IAM policies as much as possible to control access. S3 lets you create two types of access policies:
Resource Policies: Bucket Policy, Access Control List
User Policies: IAM Policy
Leveraging Resource Tagging
While tagging is mostly considered an operational and cost traceability tool, a consistent tagging policy across resources becomes handy for security. You can implement:
Access policies based on tags (e.g. department or service)
Governance and audit of controls based on tags (e.g. environment)
Vulnerability Management (e.g. intelligent threat modeling based on tier, service or environment)
Logging and Auditing
Finally, a key to success for all Security controls is quality monitoring and auditability. We recommend enabling all of the following logging options, then ingesting the logs into whichever 3rd party analysis tools that your organization uses.
CloudTrail: Monitor changes in your infrastructure near real time and set notification/thresholds to be alerted on for critical changes: IAM Policy changes, new user creation, wide-open security group, and so on.
ELB Access Log: Monitor who is accessing your web application
S3 Access Log: Monitor who is accessing data
VPC Flow Log: Monitor traffic reaching deep into your network; do you see SSH, RDP or database access from external origins?
What’s next
Now that we’ve provided a bit of a whirlwind tour of some of the security features we leverage and best practices we recommend, we’ll dive deeper into some of the specific controls in future blog posts. Stay tuned!
... View more
