Serverless architecture is all the rage today among cloud providers and start-ups alike. Serverless promises to take away the problem of managing servers. As serverless also offers advantages such as not worrying about upgrades and paying only when the server is used, it’s easy to see why it has been so popular. But this rise should give tech pause for reflection. One has to wonder if serverless’ promises are too good to be true. Specifically, is it a good idea to outsource your security concerns to a third party like AWS Lambda? What issues do companies open themselves up to under this scenario?
How AWS Works
Serverless architecture is a movement toward allowing developers to focus on code. One should not think that there are no servers at play in serverless. Clearly, there are still servers in place executing the code, but it is Amazon that is managing and maintaining the servers and executing the code. In using AWS, a company can, for example, upload its code to Amazon Lambda. APIs are used to trigger the code either through an HTTP call or by loading data to an S3 bucket or uploading to Dynamo DB.
Advantages of AWS
With AWS, infrastructure, authorization, traffic management, monitoring, and analytics are managed for you. And in truth, the AWS-size data centers are probably run more efficiently than the data centers most smaller companies could build or run on their own. AWS also has the advantage that its servers manage downtime by having data transferred between servers if there are maintenance issues. There are zero admin costs for the user, which is great, as it is expensive and time-consuming to manage downed servers. Particularly for small companies or start-ups, downed servers can mean a halt to service. Also, as a company only pays for the capacity it uses on AWS, serverless is a great way to deal with fluctuating traffic.
In the long-run, using serverless can mean significant cost savings as businesses eliminate or reduce the use and maintenance of their own servers. By decreasing reliance on their own servers, a company can introduce NoOps where they eliminate the use of Ops all together and instead focus on code and its development. In a NoOps environment, responsibility for operational tasks like front-line support is pushed to developers. And in theory, all of this abstraction should decrease time from new idea to actual market deployment.
Caveat Emptor — Limitations of AWS
Amichai Shulman, CTO of Imperva, noted, “[B]usinesses act on the misconception that when they put data into the cloud they somehow transfer responsibility and liability to the cloud provider, and this is simply not true.”
The problem with employing serverless is that companies are assuming that since AWS is responsible for the servers, all security issues are taken care of. The reality is that AWS uses the “shared responsibility model” for providing the security of data placed on its property. This means that AWS provides secure infrastructure and services, while you, the customer, are still responsible for how you code up the functions and ensuring that sensitive data is not leaked by accident because you coded the function to do this.
To achieve a secure global infrastructure, AWS configures components and provides services and features you can use to enhance security, such as the Identity and Access Management (IAM) service, which manages users and user permissions in a subset of AWS services. In essence, this means that AWS guarantees the physical framework of the information on its property but nothing beyond it. One security expert likened AWS’ policy as being akin to putting your software in a vault with a guard but not tracking the movement of the ensuing data at rest or transit once it exits the vault. This division of responsibilities is problematic as it leaves the user exposed as soon as their data leaves the AWS walled garden.
Furthermore, even if a company begins use of AWS, the AWS ecosystem is often just a part of their server footprint in what becomes a hybrid cloud. The large number of cloud applications that companies use on top of AWS combined with the large number of logins and controls make it difficult to know at all times who is accessing what and where and if the activity is treacherous.
Also, AWS has limited monitoring tools at its disposal. Amazon CloudWatch Logs lack the ability to truly robustly monitor your logs. You have only a small amount of visibility into whether your system is being targeted. Companies like Loggly and Logentries are “several generations ahead in their ability to process log data, provide intelligent alerting and help AWS customers identify trends.” There are numerous monitoring tools in the security world as well as alerting tools (like OnPage) that immediately apprise you of potential incidents. However, you do not have the ability to run these on Amazon servers.
Perhaps of biggest concern is that even if AWS got an A+ for security, there is no way serverless can combat the numerous human factors associated with security. Humans are the biggest factor contributing to security issues. According to Threat Stack, “most security incidents actually occur because of credential theft, not sophisticated zero-day attacks against cloud providers themselves”.
Examples of Cloud Failure
Indeed, there have been a number of highly visible failures of companies relying on AWS. For example, CodeSpaces was forced out of business within 12 hours after attackers compromised their entire AWS account in 2014. By the time the company reclaimed its dashboard, attackers had created alternative AWS logins, questioning the overall security of the system. This left them no choice but to shut down.
More recently, the Ashley-Madison data breach in 2015 was made worse in part because AWS tokens, database credentials, certificate private keys and other secret credentials were stored in the cloud. This provided the attackers with free reign over the online service and its data. One can be sure there have been other breaches that have not been as well-publicized but occurred nonetheless.
In the long run, using serverless can mean significant cost savings as businesses eliminate or reduce Ops as well as the use of servers. However, start-ups and more mature companies alike should be careful to fully understand the hazards they face by abdicating security control to one provider.