Implementing HIPAA Compliant Secure File Transfer Service on Google Cloud Platform
HIPAA Security mandates that confidentiality and integrity of ePHI data be protected while in transition and at rest. Therefore, as a general practice, all HIPAA-covered entities use a secure FTP server for the data transfer.
A majority of the services offered by Google Cloud Platform (GCP) are HIPAA compliant (https://cloud.google.com/security/compliance/hipaa). GCP also provides recommendations to create a HIPAA-aligned project (https://cloud.google.com/solutions/setting-up-a-hipaa-aligned-project)
Once the GCP project is properly set up one can implement a secure FTP Service using the following reference architecture.
Service Components
This reference architecture can be implemented using a Google Compute Engine VM and Cloud Storage bucket with following software components.
- SFTP Server
SFTP server is accessible over the public IP using 2-factor authentication (through Google Authenticator). It is accessible only to the whitelisted IPs. All other services and ports are blocked by the firewall on this VM.
2. Cloud Storage
This is the GCP service for the file storage. It provides secure buckets per environment — a) production and development would have separate buckets, b) production bucket can be accessed only by authorized people. The files in a bucket can be viewed only by the authorized users of the project. All files received from the client using SFTP will be stored in the GCP Cloud Storage bucket and encrypted using a custom encryption key (CMK) managed by the Cloud KMS.
3. Cloud Storage Sync Service
This custom service (trillo.io) is responsible for transferring the file from the VM’s SFTP directory to the cloud storage bucket. This service is also responsible for the removal of the file from the disk after copying it to the bucket. During the transfer, the file gets automatically encrypted by the GCP service using the custom key. This service creates audit logs for all important steps, file name collision handling, and failures.
SFTP Client Credentials
As mandated by the HIPAA practices, the client will use 2-factor authentication to upload a file. It uses the following factors for the authentication:
- Private and public key pairs.
- Google Authenticator application running on the user’s portable device.
There are two options for the private-public key pair:
- End-user will generate own private and public key. The user will provide the public key which will be configured on the FTP server. This is recommended.
- The SFTP server admin can generate a key-pair and provide the private key to the end-user. (Not recommended, but makes more convenient for the user).
Uploading File (Client Access)
The end-user uses an SFTP client to upload the file (SFTP put). The client asks for the private key for authentication. Due to 2-factor authentication, the system will prompt for the verification code. The end-user enters the verification code obtained using the Google Authenticator. Once the authentication is successful, the user can follow the standard SFTP commands to upload the file.
Data Encryption and Custom Key Management Policy
GCP provides custom keys to encrypt the data stored in the Cloud Storage Bucket. It can be achieved simply by associating the custom key name with the bucket. GCP allows the auto-rotation of the custom key. The keys can also be rotated manually. We recommend the custom keys are configured for the auto-rotation by default. In the event of any suspicion of the data breach, the manual rotation of the key can be initiated.
Dev-Ops Responsibilities
HIPAA compliance requires that the production environment access should be available only to the select people in the organization. It means that there should be a well-defined process to handoff the production environment to the authorized users so they can set new credentials to access the server (for emergency maintenance) and SFTP service. GCP IAM settings should also be updated to ensure that all unauthorized members are denied access to the production project and buckets (such as the people in QA or development team who had access during the development phase). The design should ensure that there is no leak of credentials through a source code control system (for example a source code controlled file should not contain configuration information).
Administrative — Independent Security Audit Requirements
Eventually, the organization may be required (by the customer) to conduct an independent security audit. It requires that the process followed to make the environment secure is documented. This may include:
- Design document of the service.
- The test result should be documented.
- The process to secure the production environment should be documented.
