3 Steps to De-Risking Your Cloud Security Posture
Last week’s massive mortgage and loan data breach highlights what happens when cloud security, a critical part of your overall cloud architecture, is left unattended. It’s the latest in a series of high-profile breaches involving unsecured object storage, a type of cloud-native storage with web server capabilities.
Thankfully, with just a few simple steps, you can improve your cloud security posture and avoid joining the growing list of companies suffering from what is often a single developer’s (or contractor’s) poor configuration choices.
Here are three approaches to mitigate risks in your cloud security posture, as applied to Amazon S3, today’s most popular object storage service:
- Access Restriction
- Monitoring and Automated Response
In information security, the Principle of Least Privilege states that every process, user, or program should only have access to the data that are necessary for its legitimate purpose. S3 has several methods of restricting access including:
- S3 bucket policies
- IAM Policies
- Access Control Lists (ACLs)
- “S3 block public access” feature (new)
- Pre-signed URLs (time-limited public access)
By default, S3 resources are private; only the resource owner (the AWS account that created it) can access the resource. For many of the recent S3 security breaches in the news, inexperienced project teams inadvertently changed the default private policy to enable public access to sensitive information.
Although implementing many of these S3 security capabilities are fairly straightforward, unpracticed users sometimes implement solutions without realizing their full impact. For example, in the old AWS Console “Authenticated Users” did not mean just users in your account; it meant “Any Authenticated AWS User” across any AWS account — so in essence, public.
Fortunately the new AWS Console no longer gives you this easily mistaken option, but the global/AuthenticatedUsers group is still an option for bucket policy — one you should probably avoid.
MONITORING AND AUTOMATED RESPONSE
Once your environment has been designed and implemented, you need to monitor and respond to potential security threats by using features and services like:
S3 access logging can be enabled to provide detailed records for requests to S3 including key information such as the requester, bucket name, request time, request action, response status and an error code (when relevant). These are particularly helpful as analytics inputs when leveraging the static web server capabilities of S3.
CloudTrail logging can be used to track bucket level and — optionally — object-level actions to support compliance, security and operational audits. By using CloudTrail in conjunction with other services (CloudWatch, Simple Notification System and Lambda), you can move to automated response to potential security issues and even perform remediation actions in real-time.
Additionally, AWS Config can be used to audit your environment including S3 buckets and detect potential vulnerabilities (e.g. S3 buckets with public access). AWS Config provides a searchable resource inventory, configuration history, and configuration change notifications to enable security and governance. You can use prebuilt rules or build your own rules to ensure compliance with security policies. You can even go so far as to automatically rollback changes found to be non-compliant. We recommend organizations serious about compliance and security enable both CloudTrail and AWS Config at a minimum.
Note that Amazon Web Services provides foundational logging, monitoring and automation capabilities, but many enterprises choose to augment these capabilities with more specialized third-party logging solutions and security tools, such as Splunk or Sumo Logic.
Finally, you will always want to protect sensitive data — both in-transit, as well as at-rest (e.g. stored in S3).
S3 defaults to the HTTPS protocol to aide in protecting data across the wire, providing immediate in-transit encryption. Data at rest can easily be secured by using S3 server-side encryption using AWS keys (S3-managed or client-managed Key Management System) or customer provided keys. Amazon has made this process very easy to use — server-side encryption is available with the click of a button.
For extreme edge cases, you can also provide an additional layer of security by encrypting your data before it is even loaded to S3 (via client-side encryption).
For leaders seeking to take systematic approaches to security posture improvement, a cloud governance plan should be a requirement. It aligns your leadership goals with individual developer choices, allowing both parties to better understand the implications of architecture and technology choices. Once in place, tools like AWS Config enable automatic enforcement of the governance plan.
For more information on how Nerdery partners with technology teams to deliver a scalable architecture, solid security, and pragmatic risk and compliance management, visit our Cloud Services page.
Published on 01.31.19