This is a follow-up from my earlier blogpost around –> http://msandbu.org/security-aspects-when-moving-to-the-public-cloud/ and the purpose about this post is highlighting the security aspects on IaaS services.
with IaaS we have the capabilities to provision a set of virtual machines and have different supporting services around it. The purpose of this post is going to be focusing on what services that are being offered from Google, AWS and Microsoft Azure .However most of the topics in this post will act as general guidelines for IaaS public cloud offerings. So let us start looking and the common scenarioes.
1: Control the Deployment & Automation tools
One of the cool features within Azure (Resource Manager), Amazon( Cloudformation) & Google (Deployment manager) Is that you have services that can be used to automate deployment using either JSON or YAML templates, which of course can ease the deployment time instead of navigating around the UI and setting up resources manually.
Of course this can have a negative effect if someone manages to reuse the same template to overwrite or if you have an orchestration tool which overrites an existing configuration or removes an production enviroment running in the any of the cloud vendors. Now all providers have ways to defined policies for their deployment tools so that they can’t replace or delete an existing deployment. Also combine this with resources locks so no one deletes someone unintended.
2: Management access
One of the properties of the cloud is of course self-service, being able to provision features and virtual machines using either CLI or UI, now as part of this offering to make this easy to navigate and manage many virtual machines provisioned are by DEFAULT open to management ports ( SSH or RDP) on their default ports.
Insert Public IP range, Port scan and dictonary attack here –>
Of course what I’ve seen is that many from ease of management like to maintain the easy way to manage virtual machines using RDP “in case something fails” So remember to always remove the default management capabilities after you are done configuring it or restrict it using ACLs inside the provider. Also what I also see is that when a company sets up a cloud subscription many people are added as full administrators which have full access everywhere, now unlike internal IT systems the public cloud is available from everywhere, so if someone manages to get one of those usernames they can delete your entire infrastructure or even access virtual machines or reset local administrator password of a virtual machine.
So always use MFA (Multi-factor authentication) on your cloud subscription so avoid a catastrophic disaster if someone managed to get a admin user.
3: Role based access control within cloud offering
Setting up MFA is one step to closing the gap if someone outside of the organization manages to get access to a set credentials. Defining role based access control within the cloud is the next step. Like you wouldn’t like to have helpdesk with global admin rights on your on-premises infrastructure, you wouldn’t like them to have even more access in the cloud? All cloud vendors have good robust ways to define role based access control within their offerings using their IAM offering. So for instance you can create a custom role which has only access to view performance or view status on virtual machine, or a custom role that can be used to restart virtual machines, and not have the access to delete a instance or remove a harddrive or create a virtual machine which costs the company 10,000$ a month for instance.
4: Think how to segregate the network
The cloud providers all use some form of network virtualization apart of the regular VLAN standard (Since it only scales to 4096) which acts like a generic tunneling protocol, but in most scenarioes customers get a private IP range where all their servers reside on 10.0.0.0/24 something. Which is pretty much the same as you might have had before on-premises where you exposed service externally using NAT on the firewall. Also cloud providers have built-in ACL features into this network virtualization solution, which in cases acts both on layer 2 and layer 3, which means that you can restrict traffic using 5-tuple between two hosts on the same network (where the policy is enforced on the vNIC) and not inside in the guest, which is different from on-premises where we in most cases have a in-guest firewall and ACL between different subnet. Now don’t threat the public cloud network any differently. You are going to expose service using a NAT rule or LB rule to a service which you should have a DMZ-subnet and it again has a set of ACLs which defines how it is allowed to communicate with the internal network. Also it is important to remember that since cloud vendors are using a form of network virtualization feature, many of the layer two features like GARP, RARP, VLAN, VMAC are not supported and will not technically work at all, so therefore it removes some of the risk on layer two attacks.
5: Don’t treat the cloud virtual machines any differently
Regardless if you run a virtual machine in the cloud or on-premises is still requires the same attention, which means you need to have mechanisms in place to handle patching, logging and monitoring, endpoint control and such. So manage and control a VM in cloud as you would on-premises. One thing to note here is that AWS for instance provides a service to do patch management and such –> https://aws.amazon.com/managed-services/?nc2=h_m1
Also many providers have the option to encrypt virtual machines using a Key or hybrid with on-premises HSM modules. This is of course going to reduce the risk if someone manages to get access to the enviroment and managed to download the VM virtual harddisk.
6: Don’t forget the basic features
One of the main things I notice when customers start adopting cloud is that they aren’t reading what’s included in the service. For instance when we setup a virtual machine in Microsoft Azure what are we actually getting? A VM with a dedicated set of resources and a hard disk with IP network connected. Also the backend storage for a virtual machine is often assigned a storage account where it is defined that all storage blocks should be replicated three times within the same datacenter. Great so now we have redundancy what happens if the VM get have gets infected with ransomware? Back to start…. So remember to have basic stuff like backup of virtual machines in place like you would have on-premises.
8: Understand where your responsibility lies
this is also an important part too understand, as a customer of a cloud provider if we manage to understand what is the cloud providers responsbility and what our responsbility is, it makes it easier for us to understand what we actually need to take care of ourselves.
7: Read their documentation!
And if you are uncertain where to start, all providers have good documentation which describes their current best-pratices to deploy a set of different services.
Azure: https://docs.microsoft.com/en-us/azure/security/security-best-practices-and-patterns, IaaS Azure: https://docs.microsoft.com/en-us/azure/security/azure-security-iaas
Amazon Web Services: https://d0.awsstatic.com/whitepapers/Security/AWS_Security_Best_Practices.pdf
Google Cloud Computing: https://cloud.google.com/docs/enterprise/best-practices-for-enterprise-organizations