Enterprise IT has evolved from on-premise, to renting space in datacentres, into the cloud and even more abstracted approaches like the current crop of serverless offerings. At CACI we have worked with numerous customers to deliver serverless projects and each time the security considerations are always central to the design. Previous security practices and guidance have been focussed on the more traditional routes to enterprise IT, but does that guidance relate to serverless solutions?
The UK's National Cyber Security Centre has always provided well considered and proven guidance on security practices. CACI have recently worked with them on a serverless project and used the opportunity to help review their 14 Cloud Security Principles, so how do they hold up?
One of the main benefits of moving to a cloud service is the delegation of responsibility for managing the physical infrastructure to a provider. All the cloud security principles that relate to the selection of that provider are still relevant and comprise of a very useful set of considerations. Those principles can be used a checklist of requirements that you should be looking for when you decide on a provider, if you look around, the main players in the market have already documented responses to the NCSCs guidance to make that easier.
A serverless solution to a problem typically has a few more moving parts than its monolithic counterparts and the some of the principles become more important as a result. Protecting your data in transit is a fundamental consideration for any project, but with greater amounts of communication between components in a serverless system, and the nature of the shared infrastructure these services are provided on, this becomes an ever more important concern. Measures such as ensuring connections to datastores, messages sent to queues and REST interfaces are all secured using TLS with a robust key policy go a long way to answering this concern, and many of the services provided by the major players come with these safeguards built in.
The principle concerning secure development practices are still very relevant and the adoption of a new style of architecting solutions with serverless components brings its own challenges. If your team do not have a good understanding of the provider's services and the constraints that may be applied to them, for example some serverless versions of services only support certain versions of software, it is easy to leave routes open to malicious actors. Each of the major providers have partner programs where there are companies that offer a range of services from the traditional penetration test to a full architectural review of your solution. It is worth considering if the use of these external services is appropriate to you.
Ultimately, the last principle in the list is still one of the most important messages. You are responsible for the proper use of the tools you opt to use from the provider. If you don't fully understand what each service does, the constraints around its use and the best practices for that use, you run the risk of undermining whatever protection your provider has built into the service and exposing your solution to attack from malicious or misinformed use. Some of the simplest mistakes have led to massive breaches of data, accidently checking the box to make an S3 bucket public allows anybody to download the data and numerous high-profile companies have lost control of their data this way.
The use of cloud services in general, and serverless options in particular, give you an almost unlimited opportunity to scale your solutions to solve problems at a massive scale but remember - you pay for what you use. Including some good service monitoring into your solution, and a basic understanding of the pricing models of your chosen provider, should give you the peace of mind to fully utilise the power and flexibility of the serverless architecture.
Adam Wharton – Senior Engineer at CACI Ltd Twitter: @CACI_II
This insight is part of techUK's Cloud Week 2020. You can find related news and insights here.