How to use Kubernetes in Swedish Healthcare

How to use Kubernetes in Swedish Healthcare

Kubernetes has demonstrated its ability as a platform to help teams deliver software fast and reliably. But how can it be used in highly regulated environments, such as Swedish Healthcare?

Regulatory Context

Patientdatalagen (PdL – 2008:355) regulates handling of patient data in Sweden. According to the Swedish Data Authority (Datainspektionen), PdL complements regulations dealing with personal data handling, such as the EU-wide General Data Protection Regulation (GDPR). In a sense, PdL can be seen as stricter than GDPR. Among other regulations, PdL mandates data access minimization to patient records (patientjournal). In essence, patient records may only be accessed by healthcare workers who need it and only with the patient’s consent. While the application in itself needs to be developed with regulation in mind, that is really just the tip of the proverbial iceberg. The underlying platform is an inescapable part of the entire software and hardware stack. The regulations cover all layers equally.

 

 

PdL’s associated ordinance (Patientdataförordning2008:360) gives powers to the National Board of Health and Welfare (Socialstyrelsen) to clarify data minimization measures. The Board’s regulations and recommendations (Socialstyrelsens föreskrifter och allmänna råd om journalföring och behandling av personuppgifter i hälso- och sjukvården – HSLF-FS 2016:40) introduces the notion that patient records must be handled with strict information security measures in mind. One one hand, HSLF-FS is explicitly aligned with and encourages the implementation of the ISO 27001 information security standard. On the other hand, the HSLF-FS is clear that simply implementing a security standard is insufficient, and that said security standard must be implemented to respect HSLF-FS.

What Does HSLF-FS Mandate?

To those familiar with ISO 27001, the HSLF-FS will read like a stricter version of the former. HSLF-FS mandates working systematically with information security. On a higher level, this implies regularly performing an information security risk assessment and having a clear management structure for information security. On a lower level, HSLF-FS clarifies requirements regarding:

  • Documented Operating Procedures (Driftdokumentation): Every system involved in handling patient records needs to have clear and up-to-date documentation.
  • Supplier Relationships and Outsourcing (Upphandling och utveckling): HSLF-FS makes it explicit that any supplier or outsourcing agreement dealing with patient records is bound by HSLF-FS.
  • Continuity, Disaster Recovery and Backups (Planering av verksamhet vid funktionsstörning, Säkerhetskopiering): There needs to be a plan for how to deal with a degraded information system, and how to restore the system to normal operations.
  • Physical Security (Fysiskt skydd av informationssystem): The hardware needs to be physically secure against unauthorised access. HSLF-FS even mandates secure destruction of storage media, such as hard drives.
  • Use of Cryptography (Behandling av personuppgifter i öppna nät): If patient records are accessible via public networks, then strong authentication and encryption must be used.
  • Intrusion detection (Utvärdering av skyddet mot olovlig åtkomst): HSLF-FS mandates that the system should regularly be checked against active attempts to gain unauthorized access to patient records.

Is Kubernetes Usable in Such a Highly Regulated Context?

In short, not by default and not by itself.

For better or worse, Kubernetes needs to carefully balance “works by default” with “secure by default”. Hence, a default Kubernetes installation does not comply with HSLF-FS. Furthermore, being a highly focused project, Kubernetes by itself does not provide everything. For example, Kubernetes does not offer intrusion detection, backups or encryption, and instead relies on other projects to solve those aspects.

Fortunately, Kubernetes can be made compliant with Swedish Healthcare regulations, in three steps. The first step is to choose a data center which complies with physical security requirements. The second step is to security harden the Kubernetes cluster, among others, by:

  • Configuring a single-sign-on solution, such as Dex, so that each engineer or automation pipeline needing access to the Kubernetes cluster can be individually identified.
  • Enabling Kubernetes audit logs and forwarding them to a tamper-proof logging environment.
  • Enabling and configuring Role-Based Access Control, to ensure that engineers only have the required access to the Kubernetes cluster.
  • Enabling and configuring PodSecurityPolicy, to ensure that no Pods run privileged or more permissions than required.

If needed, more hardening can be performed using tools, such as kube-bench.

Third step is to configure additional services, such as Falco for introduction detection, cert-manager for encrypting Internet traffic, and Velero for backup and disaster recovery.

Compliant Kubernetes

Compliant Kubernetes with text reading "CK8s"

To help entities regulated by Swedish Healthcare, Elastisys has carefully integrated all of the above in our open-source Compliant Kubernetes (CK8s) distribution. We offer CK8s as a managed service on top of ISO 27001 certified data centers. Elastisys also offers 24/7 support and enterprise-grade SLAs.

Contact us to find out more!

Cristian Klein

Cristian is a cloud native architect at Elastisys and a teacher at Umeå University, Sweden. He received a PhD in 2012 from INRIA, France. He gathered over 9 years of experience in the area of cloud computing, acting variously as a practitioner, a teacher, as well as a researcher. He was overall responsible for a cloud computing course, chief cloud architect and executive in a start-up, but also worked hands-on in customer projects, teaching them how to reap the benefits of cloud native technologies. When coming out of the clouds, Cristian works out by playing with his two daughters.