The Health Insurance Portability and Accountability Act (HIPAA) regulates covered entities and their business associates operating in the US healthcare and healthcare insurance market. Title II allows regulated entities to process, store and exchange healthcare information, in exchange for handling Protected Health Information (PHI) – such as names, email addresses, social security numbers – according to rules.
In this series, we focus on complying with the Privacy and Security Rule with cloud native technologies and Kubernetes. Don’t miss our previous post on the Privacy Rule and Kubernetes.
Security Rule
In brief, the Security Rule states that HIPAA covered entities must take safeguards to avoid PHI leaks. This occurs at three levels: administrative, physical and technical. The Security Rule is very similar in spirit to the ISO 27001 standard.
Administrative safeguards include granting and revoking employees access to system dealing with PHI. When it comes to Kubernetes clusters, integrating with a central Identity Provider (IdP) reduces the burden of access control. For example, if an employee leaves, Human Resources (HR) needs to update a single database. The IdP integration will pass the revocation to Kubernetes clusters as needed.
Physical safeguards include restricting and monitoring access to servers, and destroying hard disk safely at disposal. Unless there is a strict need to run the application on-prem, regulated entities can reduce compliance burden by
deploying on ISO 270001 certified data centers.
Technical safeguards include access control, backups, technical vulnerability management and network segmentation, to name a few.
Technical safeguards on a Kubernetes cluster
Access control means that each employee should be given the minimal amount of access. Kubernetes’ Role-Based Access Control (RBAC) restricts the API calls of each employee or group of employees. More complex access control may require Open Policy Agent (OPA).
Network segmentation divides your Pods into “zones”, such as frontend, backend and database. The security team then configures each zone to talk only to zones it needs to. For example, the frontend zone should not talk to the database zone directly. Similarly, the database zone should have no access to the Internet. Security teams were traditionally implementing zoning using firewall rules. However, this is no longer feasible. Kubernetes creates and destroys Pods on every change, hence IP addresses change very often. Therefore, the security team instead describes network segmentation in terms of NetworkPolicies, which in turn configure low-level firewall rules. Calico is currently the leading Cloud Native project for implementing NetworkPolicies on top of a Kubernetes cluster.
Technical vulnerability management aims at minimizing the risk of a vulnerability leaking into production, thereby facilitating a data theft. For a Kubernetes cluster, vulnerability management occurs at several levels. First, the base Operating System (OS) image needs to be kept minimal and needs to be regularly updated. Indeed, a minimal base OS image reduces the attack surface. Preferably, the OS image should contain just enough for a Kubernetes cluster, such as the Docker Daemon and kubelet. Regular updates mitigate vulnerabilities such as the infamous DirtyCOW Linux kernel vulnerability or the Kubernetes Service-Side Request Forgery. Second, container images need to be regularly scanned for vulnerabilities and updated accordingly. Harbor offers a container registry integrated with the Trivy vulnerability scanner. Trivy can not only scan system packages, like APT and Yum, but also application dependencies like Pipenv and NPM.
Welkin
To help HIPAA-regulated entities, Elastisys has carefully integrated all of the above in our open-source Welkin distribution. We provide 24/7 support or should you want to keep in-house resources dedicated to your core business, we also offer Welkin as a managed service with enterprise grade SLAs and Business Associate Agreements (BAA).
Contact us to find out more!
