Cloud service providers play an important role in making sure users have what they need to run cloud native applications, but they don’t take responsibility for security beyond what they promise in their agreements. There are important steps that users need to take to ensure cloud native security and protect their cloud environments and workloads — especially those that vendors cannot effectively secure. Here’s what cloud vendors do to improve serverless security and which additional vulnerability management precautions users need to take.
Your Vendor’s Security Responsibility
The cloud native security your vendor provides will vary depending on exactly which type of service you use.
IaaS
If you’re using an infrastructure as a service (IaaS) offering like AWS EC2 or Azure Virtual Machines, your vendor is only responsible for the underlying infrastructure. The responsibility for OS, middleware, cloud native firewall and other runtimes falls on the client.
PaaS
For platform as a service (PaaS), such as Google App Engine, clients builds their own applications, but tasks such as data storage and management are abstracted away.
SaaS
With software as a service (SaaS), vendors will host, manage and offer infrastructure as well as applications and serverless security features that companies can purchase and use. With these cloud computing categories, the client is responsible for the data involved.
End-Users’ Security Responsibilities
No matter which type of cloud service you use, the burden of securing certain types of workloads will always fall on you, never your vendor.
In general, you’ll want to keep the following pointers in mind to maximize your cloud environment security.
Review default settings
While certain settings are automatically set by the provider, some must be manually activated. It’s always better to have your own set of security policies than to assume that the 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 vendor-encrypted data is totally safe. Some vendors provide encryption services before upload, and some do not. Whichever the case, make sure to encrypt your data in transit and at rest using your own keys.
Integrate with your cloud’s data retention policy
Understanding your vendor’s data retention and deletion policy is essential. It’s important to have multiple copies of your data and have a fixed data retention period. But what happens when you delete data from the cloud? Is it still accessible to the vendor? Are there other places where it might have been cached or copied? These are things you should verify upfront when spinning up a new cloud environment.
Set appropriate privileges
Appropriate settings for privilege levels go a long way toward 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 data only has access to the things that are absolutely necessary. Alternatively, a Role-Based Access Control service such as Prisma Cloud simplifies this process.
Keep cloud software up-to-date
Your 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 to ensure that your security patches, OS, etc. are up to date. The simplest way to prevent tech 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 policy discrepancies. 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 separate admin accounts for development, deployment, testing, etc. That way, if a bad actor accesses one account, he or she cannot hop on to other aspects of the environment.
Conclusion
Your vendor will do what it can to secure resources you run in the cloud, but the fact is that your provider cannot protect you alone. Your collaboration is critical for serverless security services and resources that the vendor either does not manage, or may not have configured in a way that ideally suits your organization’s needs.
Get an in-depth look at what a full suite of cloud native security tools can look like. Watch the Cloud Native Security Summit.
This post originally appeared on The New Stack.