Data stored in the cloud is an attractive target for hackers. High profile breaches like the recent exposure of images of license plates at a U.S. port of entry have become commonplace. These events justifiably alarm consumers. Every incident cements distrust toward the tech industry, causing technology users to demand better security from software creators.
To confront these challenges software architects must help their teams adopt good security practices, ideally creating an environment that prevents issues early in the software development lifecycle.
One of the easiest ways to avoid problems is to increase developer awareness of likely issues through formal and informal training. Formal training makes the importance of security clear to the team and gets everyone on the same page. Informal training seeds detailed knowledge into the team, where it is shared between peers–this can be as simple as activities like posting the latest relevant CVEs or security-themed AWS product updates to slack.
Benefits of AWS
AWS is able to make access to enterprise-grade functionality affordable for start-ups and hobbyists by charging for products by usage. For a new developer this comes at the cost of increasing the learning curve for AWS (e.g. having to configure IAM permissions for every product used), but makes the developer aware of functionality required for robust systems. This is worthwhile if security vulnerabilities are actually avoided, as they are much less costly to avoid early than if they need to be remediated later.
The AWS metered billing model creates a natural incentive for individuals and teams to pay attention to some very basic security concerns–if you’re learning AWS on a hobby account, the last thing you want is to expose your API key and have a hacker run up a huge bill. This is a great incentive to learn how to manage secrets (e.g. git-secrets to prevent unintended check-ins of secrets)
Types of Breaches
Data breaches are often caused by a hacker exposing one of several classes of problem. These include unpatched servers running code with known vulnerabilities, resources with overly generous permissions, SQL injection, and cross site scripting. Effective use of AWS services can in some cases eliminate or reduce the risk surface area of these problems.
Every user account in AWS defaults to having no permissions. As you adopt new functionality, you must grant the user privileges to do each new task. When this practice is followed consistently, each user account should have only the bare minimum required permissions in the final product. When the permissions are scripted (e.g. with Cloudformation), this process also produces a documentation artifact representing the as-built design of IAM groups and roles.
In other cases, AWS products help you avoid an entire class of security issues. A development team might choose a microservices architecture built on AWS lambda to reduce operational costs, while delegating server patching to Amazon.
While you still need to monitor your code for the use of insecure libraries or Docker containers, the surface area for damage is significantly reduced by not running your own servers. This is also true at the data center level – you can carefully control where network traffic is allowed to flow using VPCs, but without having to patch and maintain your own switches and firewalls.
By building infrastructure with code, developers learn the building blocks of security. Knowledge alone won’t guarantee good decisions–that happens when developers have the right incentives. Pressure to bring software to market can encourage developers to cut corners, often forcing projects to defer security concerns until launch.
This creates an environment where technology consumers are frequently burned and push back as best they can, increasing demand for everything from VPNs to additional regulation. By combining careful development practices with natural benefits of cloud products, development teams can mitigate or avoid many security issues before they grow into serious issues.