Due to the increasing popularity of public cloud services, we want to take an in-depth look at how AWS and Microsoft Azure secure your data. It can be argued that security is probably the number one concern when organisations first consider ‘cloud first’ or longer-term hybrid cloud strategies. The questions we are often asked include:-
- Where is my data located?
- What levels of encryption are being used?
- How can I secure data both in transit and at rest?
- Is a direct network connection into a public cloud provider secure and encrypted?
- Can I have multi-factor authentication?
- What audit controls are there?
There are more of course but these are the most frequently asked by businesses and organisations who come to us when they are considering using the two leading public cloud providers, Microsoft Azure and AWS. So let’s consider each one in detail:
Where is my data located?
Currently, both providers have a presence in the European Union. AWS has data centres in Dublin and Frankfurt, with plans for a third region to open in the UK in the next six to twelve months. Microsoft recently added UK availability – in London, Durham and Cardiff – in addition to its existing facilities in Dublin and Amsterdam. It’s worth bearing in mind that although the core Azure services are available in the UK, not all services are.
Both providers comply with EU Data Protection Directives (for Amazon compliance click here while details of Microsoft’s EU compliance are here) and commit to hosting your data where you specify when creating services and/or applications. Although in the fullness of time the UK will be leaving the EU, the Directive applies also to countries within the European Economic Area, so this also includes non-EU countries such as Iceland and Norway. There is much speculation as to how the United Kingdom will operate outside of the EU, most people seem to accept that future data protection laws in the UK will operate along similar lines and mirror the upcoming GDPR initiative.
In short, where you decide to put your data in the pubic cloud is your choice and your choice alone.
What levels of encryption are used?
This question is obviously broad in scope, but you can expect cryptos such as AES-256, TLS/SSL, IPsec, Transparent Data Encryption for SQL Server and Hardware Security Modules (HSM) to provide multi-layered approaches to encryption. HSMs provide a hardware-based “vault” for encryption which is typically single tenanted (i.e. not shared with other customers). For example, AWS’s CloudHSM service holds encryption keys that are accessible only to you. Amazon does not and cannot access the content in your CloudHSM device.
Both providers utilise industry standard levels of encryption for both data at rest and data in transit. IPsec VPNs can provide an encrypted tunnel to pass data to and from your premises to AWS or Azure and storage services provide data at rest encryption.
Microsoft provides a full page of detail on how they provide encryption services to Azure customers. Likewise, Amazon also provides documentation on how encryption of data can be achieved with AWS. This is broken down by service, but includes popular services such as S3 and Elastic Block Storage (EBS).
Again, both providers’ provision for encryption is comparable and uses industry standard technologies to achieve this.
How can I secure data both in transit and at rest?
As noted in the previous answer, server side data encryption is easy to achieve with both AWS and Azure. Data encryption in transit can be managed by using industry standard IPsec VPN tunnels between your organisation and your cloud provider(s). In the modern world, security comes as standard and not an optional extra. Even moving huge amounts of data using physical devices uses encryption. Services such as Import/Export Snowball with AWS provide a physical device with tamper proof controls and a Trusted Platform Module (TPM) to provide the highest levels of security and audit compliance.
Aside from the above, both management portals use HTTPS by default and tools such as AzCopy (Azure data copy utility) also use HTTPS as standard.
Is a direct network connection into a public cloud provider secure and encrypted?
Both Azure and AWS provide the ability for a dedicated network uplink into your public cloud environment. Azure calls this ExpressRoute while for AWS it is Direct Connect. Both have the same objective – to provide high speed/low latency dedicated connections in hybrid deployments. These uplinks are preferable in high traffic environments and can provide bandwidth of up to 10Gbps, but are notably different in the sense that they are not encrypted by default.
This can be mitigated by deploying a VPN solution (or third party appliance) to encrypt data in transit over this link, but this is a key decision that needs to be considered during the requirements process, before designs are even drawn up. Some may be happy with the direct point-to-point link to the cloud provider (via an Internet Service Provider or ISP) that does not traverse the public internet, but other more secure environments require specific encryption to be in place before the solution can be approved for production use.
One possible way to mitigate this risk is to analyse what kind of traffic will be sent from your premises to the public cloud and how you can natively secure it. For example, web traffic can use HTTPS to send data from point-to-point. Other protocols are encrypted by design, such as RDP or Kerberos traffic. You can also use encryption with SMB traffic on more modern versions of Windows Server and client to keep data secure over a physical connection to Azure or AWS.
In short, if you are able to scope out what kind of traffic will traverse this physical link, you may be able to control data encryption with native tools without having to resort to third party solutions or additional management tools. This further reduces cost and complexity.
Can I have multi-factor authentication?
In short, yes. Both the AWS and Azure management portals support the use of One Time Passkey (OTP) generation using either secure key fobs, or the more popular (and cheaper) solution of authentication mobile applications such as Azure Authenticator or Google Authenticator. Along with your login credentials, the OTP feature generates a new six digit passcode every 30 seconds, meaning that even if a username and password to Azure or AWS was compromised, the attacker would still need access to the administrator’s key generator in order to access the portal.
Microsoft takes this process one step further as Azure Active Directory (AD) is used in the background, meaning services or applications using this mechanism for authentication (Office 365 for example) can also use the same OTP process to validate user’s credentials. You have the choice of either the mobile app, a text to a mobile phone or an automated call to a pre-nominated land line.
What audit controls are there?
Both Microsoft Azure and AWS provide secure audit mechanisms to provide immutable trails of the ‘who, what and when’ – the three key requirements of any audit system. AWS has CloudTrail and Azure uses Activity Logs natively within the Azure Portal. Additional features include the ability to capture Linux syslogs and Windows Event logs (Application, System, Security, Diagnostics) from an OS and/or application perspective. Once ingested, reports can be run and alerts can be set against certain types of log activity, so potential security threats can be dealt with proactively as they happen, and not reactively when the door has already been opened.
There are also features within optional products such as Microsoft’s Operations Management Suite (OMS) that use machine learning to report on suspicious login activity to Azure, from different continents or unusual times of the day, for example.
In conclusion
The advice above is certainly not prescriptive as every deployment is different, but hopefully it has given you a flavour of the “art of the possible.” It is absolutely right that any and all security concerns should be addressed at the requirements stage and not as an afterthought. However, with careful planning, there is no reason why a public cloud deployment cannot be as secure (if not more secure) than an on premises deployment.
Once you also factor in third party solutions (Next-Generation Firewalls, HSM devices) and best practice tools such as CIS hardening guides, you can have a secure environment at multiple layers using the appropriate tools.