I am looking into hosting a HIPAA compliant web application on Azure VM's. For the database, right now I am leaning towards using a VM with SQL 2014 Standard Edition.

Since TDE is not available with Standard Edition, I am going to just use BitLocker to encrypt the entire drive. According to what I have read, however, it is not possible to encrypt the OS drive on an Azure VM without using some kind of third party service (like CloudLink).

This article from MSDN implies that it is possible, however, to use BitLocker to encrypt the data drive. Therefore, I guess my question is two-fold:

1) Is it possible to encrypt the data drive with BitLocker on an Azure VM?

2) If I get an Azure VM with SQL Standard, will it be necessary to encrypt the OS drive in order to remain HIPAA compliant?

  • If it helps anyone to answer, anything that touches protected health information needs to be encrypted. Therefore, if I install SQL Server on drive D:\ and Windows runs on drive C:\, will any data that SQL Server processes ever reside on C:\, even temporarily?
    – blizz
    Jan 1 '15 at 21:44

Disclaimer: I am not a lawyer.

First, some required reading:

Microsoft Azure Trust Center

HIPAA Business Associate Agreement (BAA)

HIPAA and the HITECH Act are United States laws that apply to healthcare entities with access to patient information (called Protected Health Information, or PHI). In many circumstances, for a covered healthcare company to use a cloud service like Azure, the service provider must agree in a written agreement to adhere to certain security and privacy provisions set forth in HIPAA and the HITECH Act. To help customers comply with HIPAA and the HITECH Act, Microsoft offers a BAA to customers as a contract addendum.

Microsoft currently offers the BAA to customers who have a Volume Licensing / Enterprise Agreement (EA), or an Azure only EA enrollment in place with Microsoft for in-scope services. The Azure only EA does not depend on seat size, rather on an annual monetary commitment to Azure that allows a customer to obtain a discount over pay as you go pricing.

Prior to signing the BAA, customers should read the Azure HIPAA Implementation Guidance. This document was developed to assist customers who are interested in HIPAA and the HITECH Act to understand the relevant capabilities of Azure. The intended audience includes privacy officers, security officers, compliance officers, and others in customer organizations responsible for HIPAA and HITECH Act implementation and compliance. The document covers some of the best practices for building HIPAA compliant applications, and details Azure provisions for handling security breaches. While Azure includes features to help enable customer's privacy and security compliance, customers are responsible for ensuring their particular use of Azure complies with HIPAA, the HITECH Act, and other applicable laws and regulations, and should consult with their own legal counsel.

Customers should contact their Microsoft account representative to sign the agreement.

You might be required to sign a BAA with your cloud provider (Azure.) Ask your compliance representative(s).

Here is the Azure HIPAA Implementation Guidance.

It is possible to use Azure in a way that complies with HIPAA and HITECH Act requirements.

Azure VMs, and Azure SQL, and SQL Server instances running within Azure VMs, are all in scope and supported here.

Bitlocker is sufficient for encryption of data at rest. It uses AES encryption in a way that satisfies HIPAA requirements (as well as the requirements of other similar organizations) for encryption of data at rest.

Furthermore, SQL Server will not store unencrypted, sensitive data on the OS drive unless you configure SQL to do so... like for instance configuring TempDB to live on the OS drive or something.

Encryption of cells/fields/columns within individual databases isn't strictly required assuming you have already satisfied requirements for encryption of data at rest in other ways, e.g. TDE or Bitlocker.

How you choose to manage the Bitlocker encryption key may come up, since it will not live inside a TPM chip or on a removable USB drive since you don't have access to the physical machine. (Consider having a sysadmin manually enter a password to unlock the data drive every time the server reboots.) This is sort of the main draw to services such as CloudLink, as they manage that sacred encryption key for you.

  • 8
    There is no requirement to encrypt data at rest at all and be compliant under HIPAA. The data needs to be protected, encryption is one way to do that, but it's not the only way. The encryption requirement is more appropriate for data readily transported (on CDs, USB keys, laptops, etc.). When your data is bolted to the floor in man trapped first class data center, encryption becomes much less necessary. Rather you simply have to have other mechanisms to mitigate risk of data exposure (i.e. secure the servers). TDE doesn't help much when they have your SSH password, does it? Jan 2 '15 at 1:27
  • 6
    The HIPAA Security Rule fails to explicitly mention a lot of things. It (and all other similar compliance doctrines) are purposely vague in an attempt to transcend technology. But what it does explicitly say is that you must implement an addressable specification if it is reasonable and appropriate to do so. So you will need to convince your auditors that encrypting your data is an unreasonable and inappropriate activity for you.
    – Ryan Ries
    Jan 2 '15 at 2:07
  • 1
    And indeed we chose to not encrypt because lights-out cold boot is more important (the servers will come up on their own after power cycling the building). As you should know, any disk encryption that allows lights-out cold boot is inherently vulnerable to attack.
    – joshudson
    Jan 2 '15 at 4:08
  • Thank you this answer is extremely helpful. Lastly, can anyone confirm that it is possible to encrypt the data disk on an Azure VM?
    – blizz
    Jan 2 '15 at 5:59

Answering your comment: If you install SQL Server on D: and Windows runs on C:, SQL data will live in: the MDF and LDF files (on D:), in TempDB (on D:), and in Memory. It's possible in a severe low memory state for the data to get swapped to the page file, which may live on C:. Locking pages in memory may help. SQL 2014 should support this. See http://support.microsoft.com/kb/918483.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.