Although the term says “serverless,” serverless applications don’t really run without any servers involved. Rather, serverless applications run inside cloud-based infrastructures so that developers and operators need no longer stand up and run their own servers, virtual or physical. That is, the application still runs on a server, but the responsibility for server management falls on the cloud service or cloud platform provider instead. That means that organizations need not themselves provision, scale, manage and maintain servers on which their applications run – they use a serverless architecture to build, test, deploy and run their applications and services for clients, customers, end-users, and so forth. AWS Lambda, for example, is a serverless service that includes automatic scaling, with high availability baked into the runtime environment, charged on a pay-for-value basis.
As is typical for cloud-based runtime environments, serverless applications adhere to what’s often called a “shared security model.” Following this model means that the cloud provider is responsible for the security of the cloud while those who host their applications are responsible for security of their application in the cloud. When organizations adopt serverless technologies, the responsibility that the cloud or application provider assumes climbs up the stack to include operating system and networking security for the servers it operates on which the organization’s serverless application runs.
Theoretically this means that the job of security is easier for serverless applications than for cloud-based applications where the operating organization also stands up underlying virtual infrastructures. In fact, Amazon recommends (and most other cloud service and platform providers concur) that companies adhere strictly to the Principle of Least Privilege (PLP) and also follow best practices for securing their serverless applications. They recommend their own identity and access management (IAM) platform to secure and manage access to their services and resources, but similar capabilities are available from all of the major cloud platform providers including Azure, Google, Oracle, IBM, Alibaba and others as well.
Proper use of identity and access management technology is indeed key to securing serverless applications. This includes access controls through accounts and groups or job roles, and specific constraints on how users may interact with serverless applications. These might pertain to days of the week, times of the day, originating IP addresses, as well as require use of SSL or other secure protocols, and even require multi-factor authentication (2FA or better) before allowing access to proceed.
In addition, most cloud platforms’ identity and access management tools support access auditing and reporting, so the organization’s security team and administrators can confirm that prevailing policies provide only authorized public and private accounts with appropriate access to applications and their resources. In fact, organizations should use this reporting to tweak and adjust their security policies to enable access only to services in use, following PLP. Multi-Factor Authentication (MFA) makes most sense for privileged accounts and access (administrators, developers, architects and security staff) so that privileged access is available only to those who provide a hardware MFA device, or who use an authentication app on a mobile device to provide an additional authentication factor. Best practice also dictates auditing for privileged access and activity, so those who exercise higher levels of privilege will know that their actions are open to scrutiny.
In fact, most cloud platforms’ identity and access management tools also include federated access to their management consoles and service APIs. This means the identity and access management tools integrate with local identity systems, such as Microsoft Active Directory. In fact, most serverless offerings will work with identity management solutions that support SAML 2.0, which includes not just Active Directory and Azure AD, but also privileged access solutions from CyberArk, BeyondTrust, Centrify, and others.
The best development environments build security in from design forward, from development through test and into deployment. According to a 2018 Network World story, one in five of over 1,000 serverless apps audited by the Israeli firm PureSec manifested security vulnerabilities and weaknesses. Most originated from cut-and-paste of “insecure sample code into real-world projects, poor development practices, and lack of serverless education.” Clearly, developers must be properly schooled on building secure code, and their development environments should be scanning their code for such vulnerabilities and insecure practices with each code commit, release build, and public release deployment.
Proper code scanning and vulnerability remediation helps organizations avoid known potholes and pitfalls. These include injection actions (SQL or NoSQL), remote code execution, buffer overflows, and unauthorized actions and instructions. The best way to secure serverless applications is to make sure they’re developed as securely as possible, and then to audit them regularly for security flaws. As these flaws are discovered, best practice indicates they should be replaced, remediated, or worked around to prevent and limit exposure.
