This post originally appeared on The New Stack.
Ever since the cloud became a thing about a decade ago, we’ve been inundated with warnings (such as here, here and here) about how the cloud can pose security risks. In reality, the cloud is not inherently insecure, despite what some people may imply. Nonetheless, there are important cloud native security steps that users of cloud services need to take to secure their cloud-based environments and workloads — especially those that cloud vendors themselves cannot effectively secure. This article walks through those steps by highlighting what cloud vendors do to improve serverless security, and which extra vulnerability management precautions users need to take.
Your Cloud Vendor’s Security Responsibility
The cloud native security your cloud vendor provides will vary depending on exactly which type of cloud service you use.
If you’re using an IaaS service like AWS EC2 or Azure Virtual Machines, your cloud vendor is only responsible for the underlying infrastructure. The OS, middleware, cloud native firewall and other runtimes fall on the client.
For PaaS platforms, such as Google App Engine, a client builds their own application; however, tasks such as data storage and management are abstracted away.
With software as a service (SaaS), cloud vendors host, manage and offer infrastructure as well as applications and serverless security features that companies can purchase and use. With all these cloud computing categories, however, the client is responsible for the data that is involved.
End-Users’ Cloud Security Responsibilities
No matter which type of cloud service you use, the burden of securing certain types of workloads falls on you and not your cloud vendor.
In general, you’ll want to keep the following pointers in mind to maximize the security of your cloud environment.
Review default cloud settings
The first thing you need to remember is that while certain settings are automatically set by the provider, some of these must be manually activated. It’s always better to have your own set of security policies than to assume that the cloud vendor is taking care of a particular aspect of your cloud native security.
Adapt data storage and authentication configurations to your organization
All locations where data will be uploaded should be password-protected. In addition, password expiration policies should be carefully selected to suit the needs of your organization.
Don’t assume your cloud data is safe
Never assume that cloud vendor-encrypted data is totally safe. Some cloud vendors provide encryption services before upload, and some do not. Whatever the case, make sure to encrypt your data using your own keys. Keep in mind, too, that data should be encrypted in transit and at rest.
Integrate with your cloud’s data retention policy
Understanding your cloud vendor’s data retention and deletion policy is essential in ensuring the safety of your data. What happens when you delete data from the cloud? Is it still accessible to the cloud vendor? Are there any places where it might have been cached or copied? These are some of the things you should verify up front when hopping onto a new cloud environment. It’s also important to have multiple copies of your data and have a fixed data retention period.
Set appropriate privileges
Appropriate settings for privilege levels go a long way to make your cloud environment more secure. By using Role-Based Access Controls for authorization, you can ensure that every person who views or works with your service only has access to the things that are absolutely necessary. Alternatively, a Rule-Based Access Control service, such as Twistlock, simplifies this process.
Keep cloud-based software up-to-date
Your cloud vendor may provide infrastructure, and in some cases, a prebuilt software environment or cloud native firewall. But anything that you add is on you to secure.
Thus, it’s your responsibility as a user of a cloud service to ensure that your security patches, OS, etc. are up-to-date. The simplest way to prevent technical debt and backlogs is to automate the updates.
Build security policies and best practices into your cloud images
Leaving your cloud native security to different developers on your DevOps security team might result in discrepancies in policy. A good way to combat this is to create cloud images with security tools configured and policies applied so that developers can simply create instances of them and work with those.
Isolate your cloud resources
To reduce the risk of hackers gaining complete control over your system, it is advisable to have separate admin accounts for development, deployment, testing, etc. That way, if a hacker accesses one account, he or she cannot hop on to other aspects of the environment.
Your cloud vendor will do what it can to secure resources you run in the cloud, but the fact is that your cloud provider cannot protect you on their own. Your collaboration is critical for serverless security services and resources that the cloud vendor either does not manage, or may not have configured in a way that ideally suits your organization’s needs.
Follow us on Twitter
Follow us on Twitter for real time updates on the cloud native ecosystem, Twistlock product, and cloud native security threats.
How My Company (Teckro) Uses ContainersRead the Blog
Mitigating CVE-2019-5736 Impacting RunC and DockerRead the Blog
From Agile to DevSecOps and DevOps SecurityRead the Blog
What’s Next for Cloud-Native Infrastructure Technology?Read the Blog
The What and Why of a Unified Security StrategyRead the Blog