4 fundamental practices for serverless architecture security
Are you ready for serverless security? Learn about four critical planning considerations software teams need to focus on if they plan to adopt serverless.
Serverless computing adopters have little knowledge of what underlying physical hardware and software providers use to support workloads. Enterprises adopting serverless, therefore, have little knowledge about the security of those systems. The abstraction of the serverless platform requires that software teams start thinking differently.
There are four major points of serverless architecture security: the platform vendor's specific security methods, secure coding methods, diligent data encryption and rigorous token management.
Understand vendors' security approaches
Third-party public cloud providers host the majority of serverless computing activity. Prospective users should make sure they are confident in the base level of security that these platforms offer.
Although there are cases of security breaches of workloads that sit on top of these cloud platforms, these problems tend to occur on the application side, due to poor workload architecture. The underlying vendor resources should not be an issue, as they deal with cloud security attentively and across a vast offering.
If your organization doesn't choose a major vendor, like Google, AWS or Microsoft, for serverless, your team might be responsible to ensure the serverless provider closely follows specific policies and procedures.
Avoid insecure code at all costs
If your code is insecure, you leave a door open for anyone to gain basic access to the platform, no matter how secure that platform is. One step to secure serverless application code is to build in protections from the point of access using approaches like two-factor authentication and OAuth (Open Authorization).
As the layers of physical, virtual, application, database and user interactions get abstracted and evolve in serverless architectures, organizations must focus on ways to protect data.
Another way to put intelligence behind these points of access is to use time and place as alternate factors for authentication. This tactic identifies discrepancies, such as if a user logs in from New York, but 10 minutes later tries to log in from Tokyo. An access control security setup can also discern things such as if a user attempts to access highly secure information from a coffee shop's public Wi-Fi network, which is incongruous behavior.
Data encryption is critical
The underlying data for a serverless workload should be your team's main security concern. With serverless, the end device is still there as it is in traditional application designs, but it stores little to no transactional data or transient information, as all this data remains in the cloud.
The trick is to ensure that data exists as a binary stream of ones and zeros, at least from the perspective of a malicious attacker. The team should encrypt data both at rest and on the move and also ensure that any entity requesting data is who or what it purports to be.
Create a dynamic token system
Token systems, such as OAuth, give requestors access via an agreed-upon authentication method that carries over from point of authentication to the workload.
When the requesting entity is another serverless workload, it becomes difficult for the system to create a strict token that combines standard, software-based details with physical details, like IP addresses. It also doesn't help that IP addresses are too easily spoofed.
Instead, you need certified tokens between the serverless environments. Security tokens work with digital certificates for validation. The workloads remain dynamic and flexible, but any request from one workload to another has a dependable method of proving the workload's identity. Once this identity confirmation takes place, a one-time token is issued for that session. And, if needed, you can set tokens to time out during a session for extra security.
Token-based authentication between services does not necessarily affect the users of a serverless application, and they should not need to log in again as these confirmations take place. The workload that gets called maintains state in the background but, at the same time, requests that the calling workload receives a new token. This action takes little time and should work smoothly, although the most time-dependent workloads, such as financial trading systems, may find even small delays intolerable.
Serverless security does not exist in a vacuum. IT organizations have adapted workload security practices as hosting resources evolved from physical to virtual and then from cloud to multi-cloud. As the layers of physical, virtual, application, database and user interactions get abstracted and evolve in serverless architectures, organizations must focus on ways to protect data.
