Security Compliance in GCP (HIPAA + SOC2)

Still in Draft

This document is not ready for the reader. I probably reference it in another article though and so... here you are! Read on if you'd like, but it may be best to wait until I complete it.

Checklist

• Executed a Google Cloud BAA.

• Disabled or otherwise ensured to not use Google Cloud Products that are not explicitly covered by the BAA when working with PHI.

• Using IAM best practices when configuring who has access to the Google Cloud Platform (GCP) projects containing or executing on PHI.

• All customer content is encrypted at rest and in-transit.

• Configured audit log export to Cloud Storage for long term (7 year) archival, as well as to BigQuery for any analytical, monitoring, and/or forensic needs.

• Configured access control for the logs. Regularly review audit logs to ensure security and compliance with requirements.

• All PHI is encrypted using GCP’s Key Management Service with a 90 day key rotation of a symmetric key. This algorithm uses 256-bit Advanced Encryption Standard (AES-256) keys in Galois Counter Mode (GCM), padded with Cloud KMS-internal metadata. We do not have access to the key, and in theory, no one at Google or anywhere else has access to it.

• When creating or configuring indexes in Cloud Firestore using PHI, we enforce blind indices using a combined bycrypt + SHA3 hash with a uniquely generated salt per PHI value. The salt is encrypted using the same level of security as our PHI encryption explained above.

• We sanitize all metadata and resource data being captured in our logs.

• We use Identity Platform practices when using Identity Platform for your project, which includes our product’s authentication.

• We never store PHI in build config files, source control files, or other build artifacts.

• We never cache PHI on our services, CDN, on the user’s device or browser’s local storage.

• All product changes that impact PHI are reviewed by our Security Compliance Officer.

• Our staff have routine HIPAA compliance training.

• We perform an internal and/or independent audit of our HIPAA compliance and BAAs annually.

• User access to PHI assumes least privilege and requires authentication with automatic log off of session inactivity.

• We self-proclaim compliance with HIPAA and GDPR. You can review our Privacy Policy and Terms of Service for more details.

Resources

• https://www.hipaajournal.com/hipaa-compliance-checklist/

• https://www.hipaajournal.com/hipaa-audit-checklist/

• https://www.hipaaguide.net/hipaa-compliance-guide/

• https://www.hipaajournal.com/gdpr-requirements-for-us-companies/

• https://www.hipaajournal.com/protect-healthcare-data-from-phishing/

• https://cloud.google.com/security/compliance/hipaa

• https://github.com/GoogleCloudPlatform/solution-acceleration-toolkit

• https://drive.google.com/file/d/1TuK3XJ8nkZhXKVJx3K-TyBeJvvo8Nk3i/view?usp=sharing

• https://www.backhub.co/

• If serverless, then there is no need for Blackduck or other vulnerability scanning services.

• https://cloud.google.com/filestore/docs/backup-restore

  • https://cloud.google.com/filestore/docs/scheduling-backups

• https://stackoverflow.com/a/33112378/6090140

  • https://cloud.google.com/kms/docs/create-validate-mac-signatures#create_mac_signature

  • Note that the problem with utilizing a MAC is 1) if the secret key ever rotates, the output changes and 2) if the secret key is ever compromised, the MAC is no more secure than a regular hash and a rainbow table can be used and 3) it is generally the case to use one secret key per database, making a compromised key compromised for all data in the database.

  • Lookup Blind Indices for more information. It's all about what level of comfort you have. Ask yourself: "If a malicious average user of your platform was insanely smart and dedicated, could they compromise your system?" "If a malicious admin-level user ..." "If a malicious developer ..." "If a malicious cloud/devops admin ..."