Tuesday, September 8, 2020
By Maril Vernon and Charles Buege, Fuel User Group Members, Fuel Editorial Advisory Committee
A recent article in the Hosting Tribunal cited that 94% of companies are already using a cloud service in some capacity, with a projected 83% of workloads to be cloud-based by the end of this year.
There are many objective benefits offered by cloud computing, from elasticity to cost savings. However, while the cloud is meant to be user-friendly and easily spun up, its many configuration options are daunting. It is a space of infinite options and its rapid and wide-spread implementation has left many to learn by doing; those new to the cloud too often miss basic cloud computing principles.We have often found in our own discussions that the cloud has a way of sneaking things past its users. With this in mind, we’ve created a list of common “mythconceptions” to make sure you don’t fall victim to common mentalities and myths surrounding cloud security utilization. In part one of this multi-part series, we look at myths related to security and identity access management (IAM).
Myth #1: The cloud handles all of my security.
This is true, to a point. The cloud operates on a shared responsibility model. Depending on Software as a Service (SaaS), Platform as a Service (PaaS) or Infrastructure as a Service (IaaS) utilization of the cloud, there is a difference in what the cloud provider and cloud consumer are responsible for. The general principle is the cloud service provider is responsible for the security of the cloud, and the consumer is responsible for the security of what’s in the cloud.
You should trust but verify claims that cloud providers give. Is your data truly encrypted at rest? If it’s not a default setting, did you, the end-user, turn it on? If so, what does that mean to the provider?
A good rule to remember with the cloud, contrary to intuitive thought, is that the defaults are not the most secure.
Additionally, defense in depth is real, even in the cloud. Host instances on different subnets — should one be compromised, the entire network is not. Use unique keys for each instance, limiting access if compromised. Closely govern IAM user groups, roles and policies. Network access control list (ACL) rules compensating for overly permissive security group rules or vice versa. The basic principles of segmentation still need to be implemented even in the cloud. Otherwise, it’ll be a single plane of access behind the web application firewall (WAF) — if you have one, and if it’s 100% properly configured.
Myth #2: The cloud automatically backs up all of my data.
Sometimes yes, sometimes no. This depends on the service or offering, configured frequency, amount of data that is retained and/or the duration that it is retained for, etc.
If you have a database server in the cloud, the cloud provider can do all of the work for you: integrity checks, backups, firewall settings, expanding storage as necessary, etc. But if your data retention policies/rules aren’t set up, then nothing will be backed up.
Be sure to inspect and confirm in your environment.
Myth #3: The cloud automatically encrypts all of my data.
The cloud is empowered with strong encryption and transport layer security (TLS) protocols but you have to enable them for your data, for each service and instance, every time if you want to benefit from it. It is not always the case that the data is encrypted at default. If you’d like it to be encrypted, you benefit from the strength of the encryption level your cloud has to offer.
For compliance purposes with frameworks such as International Organization for Standardization (ISO), National Institute of Standards and Technology (NIST) and Payment Card Industry Data Security Standard (PCI DSS), end-to-end encryption is required. Therefore, unless this is currently enabled, an audit of your environment may prove deficient.
Amazon Web Services (AWS) pro-tip: If you turn on S3 encryption after the bucket is created, it does not retroactively encrypt the contents of that bucket. It means only encrypted items can be stored there from that point on. Everything formerly unencrypted still is.
Myth #4: Everything in the cloud is accessible to the internet.
Absolutely not. While everything in the cloud is hosted in the internet and can be made to be web accessible, the opposite is usually the default. In the case of AWS, subnets have to be purposefully opened not only with an additional network interface and internet gateway, but they also need permission via the security group (the instance-level firewall). On the other hand, with Azure, unless you specify that the resource should NOT be internet accessible, in most cases internet-based access is turned on by default.
You can completely lock down VMs and instances not to be accessible on the internet. Or, you can set VMs and other instances to only be accessible over specific remote services protocols on specific ports from specifically defined IP addresses, and/or allow access to certain internal networks.
Myth #5: Everyone needs access keys and a password.
This is the exact opposite of best practices. It used to be standard in at least one cloud provider we’re aware of that users automatically got access keys and a console access password upon creation, but that has since been changed. Users can be created with one or the other and it is highly recommended for segregation that automation users do not get console passwords. They’re essentially user accounts and thus will never need to use the GUI to function. Therefore, it’s an additional attack surface that is exposed, since someone could log on under that service account and get access to console-only functions like billing.
It is highly recommended that users who have both, especially admins, be reviewed regularly for needing to maintain that access. If a user has an access key that has not been used in the last 90 days, it is also recommended to disable and delete it.
Myth #6: Adding my users to the cloud will automatically mirror my Active Directory (AD) configurations.
Be sure to check with your cloud provider for setting up integrations between their user management system and your local Windows AD infrastructure. Just because you create a user in one location doesn’t guarantee that it is going to be set up in the other automatically.
Microsoft Azure has a series of documents, examples and tools to perform this type of synchronization. The process isn’t difficult, but it can be tricky, so be sure to pay attention to the details. Additionally, the tools that perform the synchronization between local and cloud AD systems (in Azure’s case it is called ‘Azure AD Connect’) are periodically being updated as well. Make yourself a periodic reminder to make sure that those tools are kept up to date to allow you to be able to take the greatest advantage of your cloud provider’s offerings.
Additionally, once this integration is complete, you can also integrate into your Palo Alto Networks Firewall appliances. We wrote a basic article on the topic recently and you can find it here.
If you found these myths helpful or interesting and would like more information, please contact the Fuel Editor at firstname.lastname@example.org.
More to Explore
Check out these Fuel blog posts for further reading: