Charles Goldberg | VP, product marketing
Security is a Shared Responsibility
Almost three years ago, Amazon Web Services (AWS) became the first company to receive the U.S. Department of Defense (DoD) level 3-5 Provisional Authorization for the AWS GovCloud (US) region under the Defense Information Systems Agency’s (DISA) Cloud Security Model (CSM). This authorization allows DoD agencies to use AWS GovCloud’s compliant infrastructure for all but level 6 (classified) workloads.
AWS’ “regions” are essentially a set of AWS data centers. AWS GovCloud is an isolated region designed to host US Government sensitive data and regulated workloads. It is also available to organizations in government-regulated industries that the government permits to use AWS GovCloud.
AWS GovCloud (US) is operated by employees who are vetted U.S. Citizens on U.S. soil, and root account holders of AWS accounts must confirm they are U.S. Persons. Sounds great, right? So, government customers can now take advantage of cloud technology, as long as they are within this exclusive AWS region without worrying about their data? Not so fast…
The AWS GovCloud team reminds agencies, right in the “What Is AWS GovCloud” section of their site that:
“AWS manages physical and logical access controls for the AWS boundary. However, the overall security of your workloads is a shared responsibility, where you are responsible for controlling user access to content in your AWS GovCloud (US) account.”
How do customers share this responsibility? How do customers know that their agency has the ability to “control user access to content in your AWS GovCloud account”?
To further this question, if AWS owns all of an agency’s infrastructure, including the entire security infrastructure, down to the encryption and associated encryption keys; agencies should ask themselves: Am I sharing in the responsibility to protect my agency’s data or am I relinquishing responsibility?
Encryption and key management remain the most fundamental data security controls. If an agency is going to take responsibility for its data’s destiny, it should be with absolute control over who can access your data in the clear.
Help control your agency’s destiny with Thales
For some time, Thales agency customers have used Vormetric Transparent Encryption in their AWS GovCloud deployments to encrypt their data stored in Amazon Elastic Block Storage (EBS). Here’s how it works:
The data is encrypted in their Amazon Elastic Compute (EC2) Workload before it is stored in EBS. In this solution, the agency maintains control of their encryption keys in a FIPS 140-2 Level 3 Vormetric Data Security Manager (DSM) that resides on their premises. The DSM enables them to securely store their keys, centrally set all their access control policies—including what EBS data a Privileged User can see in the clear (which is typically set to allow the Privileged Users to perform functions on the files, but never see the data in clear-text). The DSM also collects granular continuous monitoring logs of every data access attempt on their files and databases from every EC2 instance that is protected by Vormetric Transparent Encryption.
The FIPS 140-2 Level 1 Virtual DSM can reside in AWS GovCloud as well. However, to date, all Thales agency customers elect to keep their keys on-premises in the FIPS 140-2 Level 3 DSM. We have commercial customers and service provider partners that run their Virtual DSM in AWS, furthermore, the Virtual DSM is approved for use in AWS GovCloud; so it is ready when the agencies are.
Many AWS GovCloud customers also use AWS Simple Secure Storage (S3) object storage. The Thales solution for this environment is the Vormetric Cloud Encryption Gateway. This product is a virtual gateway that can run on-premises to assure clear-text data is never stored in S3. The Gateway uses the same DSM to securely store your encryption keys. This creates operational efficiency by centralizing key management for all your encryption solutions.
If customers prefer, they can also run the Vormetric Cloud Encryption Gateway in AWS GovCloud and, similar to Vormetric Transparent Encryption, have the option of storing and controlling their keys with a FIPS 140-2 Level 3 on-premises DSM in AWS GovCloud using the FIPS 140-2 Level 1 validated virtual DSM. The Vormetric Cloud Encryption Gateway assures that customers have control of their S3 stored data. This means the agency decides if the data is encrypted and decrypted on premises (it’s never clear-text in the cloud), who has access to this data, and can continuously monitor and log who reads and writes data from their S3 buckets.
I’d also like to point out that the Vormetric Cloud Encryption Gateway has another very slick capability: It will detect if a user places clear-text data directly into a protected S3 bucket; perhaps an attempt to circumvent the Gateway. The Gateway continuously inspects all of the protected S3 buckets and if it detects unencrypted data—it will encrypt it! This means the user must pass through the Gateway and be authenticated and logged if they want to access that data again.
The advantages of the cloud are clear, and I applaud the U.S. government for aggressively taking advantage of cloud technologies in a secure fashion. As someone who started their career working for NASA and living in the Washington D.C. Metro Area, I know and appreciate first-hand the commitment to innovation that U.S. government agencies are making.
Keep in mind, as AWS always reminds their customers, “security is a shared responsibility” and this is no different in AWS GovCloud. Thales offers a host of solutions to cost effectively, and with operational efficiency, control agency data in AWS GovCloud as well as across your hosted and owned facilities.
There is no better way to control your data’s destiny and taking responsibility for your data’s security than by leveraging encryption and strong key management that you own and manage.
For more information on how government agencies can best protect their data in the AWS GovCloud and how Thales can help, click here or find me on Twitter at @chvrles.