Transcription
E-bookArchitecting for HIPAA Security RuleSecurity and compliance on Red Hat OpenShift 4Rob Starr, Senior Solutions Architect, Red HatRob Sedor, Chief Solutions Architect, Red HatTable of contentsExecutive summary. 3Notice. 3Background. 3Red Hat OpenShift technology components. 4Colocating ePHI with general purpose workloads. 4Network. 4Ingress traffic.5Egress traffic.5Traffic isolation. 6Networks. 6Hardware networks. 6Third-party vendors. 6Storage. 6Persistent storage life cycle. 6Cluster attached storage.7Host and hypervisor attached storage.7Red Hat CoreOS. 8Red Hat OpenShift - Kubernetes. 8Spoofing. 8Tampering. 9Repudiation.10Information .com/company/red-hatredhat.comDenial of service.10
Elevation of privilege. 11Other considerations - CI/CD. 11Registry.12IAM and zed database.13Applications.13Threat landscape.13Service discovery.14Network.14Countering application threats.14Standards for identity and access management.14Communications protocols.16Red Hat OpenShift Service Mesh.16Secrets.16Logging and audit.17Back-up and disaster recovery.18Privileged containers.18Security Context Constraints.18Additional resources.19redhat.comE-book Architecting for HIPAA Security Rule2
Executive summaryThe goal of this document is to provide general technical guidance for users of Red Hat OpenShift and related services who are building applications intended to comply with the Health InsurancePortability and Accountability Act of 1996 (HIPAA) Security Rule requirements. Because there aresignificant integration and configuration options within Red Hat OpenShift on-premise and acrosspublic clouds, we will specifically focus on general recommendations for core services and bettersecuring electronic protected health information (ePHI) in transit and at rest, as well as disasterrecovery, backup, and audit compliance guidance. This document is not intended to be a definitiveguide to deploying Red Hat OpenShift but instead supplements existing documentation with a focuson HIPAA Security Rule requirements.NoticeSimply following this guide will not make you compliant. This document provides guidance on protecting and encrypting protected health information (PHI) within Red Hat OpenShift Container Platform.Each deployment, and specifically public cloud deployments, will have requirements unique to theirenvironment and may have their own HIPAA architecture recommendations. The document assumesthat the end deployment meets public or private cloud infrastructure requirements as a prerequisite.This document also does not specifically address enterprise agreements (EA) or business associateagreements (BAA), which may be required for target cloud infrastructure through a third party thatis used in the deployment and does not intend to provide general business guidance on HIPAA. Thescope is to better secure and encrypt personal health information (PHI) on Red Hat OpenShift, specifically Red Hat OpenShift 4.BackgroundThe Health Insurance Portability and Accountability Act of 1996 (HIPAA) was passed by the U.S.Congress to support American workers. It allows employees to maintain insurance coverage whenchanging jobs, addresses fraud and abuse, standardizes health care information and billing, andrequires protection of PHI.Within HIPAA, there are two primary groups that may be subject to HIPAA rules: covered entities andbusiness associates. A covered entity is any health plan, health care clearinghouse, and health careprovider who transmits health information. This grouping may include doctors, dentists, pharmacies,clinics, health maintenance organizations (HMOs), academic medical centers, health insurance companies, entities that process health information they receive from another entity, and many others. Abusiness associate is any person or entity that is not a member of the covered entities’ workforce thatperforms an activity or function governed by HIPAA. As it relates to the specific technologies discussed in this document, a covered entity may require a business associate contract with a cloud provider to place PHI on a public cloud provider’s platform, regardless of technologies used.PHI is any identifiable health information handled by a covered entity. It does not need to be personally identifiable information (PII). PHI covers information that may be linked to an individual, such asidentifiers like names, emails, social security numbers, finger prints, facial photographs, and accountnumbers, among others. ePHI is any PHI that is transmitted, received, or stored in electronic format.The Health Information Technology for Economic and Clinical Health (HITECH) Act was signedinto law in 2009 and addresses privacy and security of ePHI. HITECH also includes provisions tostrengthen civil and criminal enforcement of HIPAA.redhat.comE-book Architecting for HIPAA Security Rule3
Red Hat OpenShift is broadly adopted, including heavily regulated industries. HIPAA complianceshould not be considered a requirement for running general purpose workloads, even in the healthcare space. In this e-book, we specifically discuss the technical considerations for each component ofRed Hat OpenShift 4 that may be used to store, process, or transmit ePHI.Red Hat OpenShift technology componentsRed Hat OpenShift is not a single software package. It represents a collection of technologies, including Kubernetes, OpenVswitch, Red Hat CoreOS, and many others. The following sections cover specific technologies that can be used to deploy applications containing ePHI across public and privatecloud infrastructure.Colocating ePHI with general purpose workloadsWith proper application security and use of built-in multitenancy features, organizations can colocategeneral purpose workloads with ePHI workloads. There are two primary considerations when colocating workloads:1.Does the workload have specific compliance requirements? Does this conflict complicate or conflate the cost of colocating the workloads? If it does not,there is generally no technical reason they cannot be colocated.2.Is the deployment located in a third-party infrastructure? If deploying across public cloud or third party datacenters, the covered entity is typicallyrequired to have a business associates agreement (BAA) with the third party. This arrangementmay mean that the account or subaccount in the cloud provider needs to be designated as containing PHI and subject to HIPAA. Depending on the percentage of workloads containing PHI, itmay require a specific architecture.Red Hat OpenShift was designed for multitenancy, with more security, segmentation, and platformvisibility from the start, including:1.Configuration and life-cycle management.2.Host and runtime security.3.Identity and access management.4.Data at rest and in transit.5.Logging, monitoring, and metrics.6.Audit and compliance.NetworkBy default, Red Hat OpenShift uses built-in software-defined networking (SDN) provided by theOpen Vswitch (OVS) project and a subproject known as Open Virtual Network (OVN). OVN provideslayer 3 routing, switching, and security group capabilities. These are both selectable as options duringinstallation by setting network type to OpenShiftSDN or OVNKubernetes in your deployment configuration. Both these solutions encapsulate traffic via virtual extensible LAN (VXLAN) or genericnetwork virtualization encapsulation (GENEVE) respectively. While this action will provide logicalredhat.comE-book Architecting for HIPAA Security Rule4
segmentation, the cluster’s internal pod traffic is not encrypted. Traffic between the Red HatOpenShift control plane and compute nodes uses X.509 certificates for security, as does trafficbetween Red Hat OpenShift components.In earlier versions of Red Hat OpenShift (v3), it was possible to add IPsec to encrypt all trafficbetween hosts. Red Hat OpenShift Container Platform 4, as of the 4.5 release, does not supportIPsec. We recommend using Red Hat OpenShift Service Mesh to enable mutual transport layer security (TLS) between services.An important distinction should be made between deploying on trusted and untrusted networksoutside of the corporate firewall. Whenever deploying on third-party networks, especially those thatare shared by unknown sources, all interapplication and database transactions should be encrypted.Specifically, there should be no assumption that cloud provider overlay or logical networks, such asvirtual network (VNet) or virtual private cloud (VPC), encrypt traffic between hosts unless otherwisestated by the cloud provider.Red Hat OpenShift also provides network policy to control access between pods. By default, all podsin a project are accessible from other other pods or network endpoints. Network policy provides asimple way to add filtering. If a pod is matched by selectors in one or more NetworkPolicy objects, thepod will accept only connections that are allowed by at least one of those NetworkPolicy objects. Thefollowing are policy options that can be set to control pod network communications.a.Deny all trafficb.Only allow connections from the OpenShift Container Platform ingress controllerc.Only accept connections from pods within a projectd.Only allow HTTP and HTTPS traffic based on pod labelse.Accept connections by using both namespace and pod selectorsIngress trafficThere are many security implications related to how you configure access to your Kubernetes services from outside of your OpenShift Container Platform cluster. Besides exposing HTTP and HTTPSroutes, ingress routing allows you to set up NodePort or LoadBalancer ingress types. NodePortexposes an application’s service application programming interface (API) object from each clusterworker. LoadBalancer lets you assign an external load balancer to an associated service API object inyour OpenShift Container Platform cluster.Egress trafficEgress firewall rules can provide additional filtering on pods and limit the ability to connect to external resources. Some typical uses are:redhat.coma.A pod can only connect to internal hosts and cannot initiate connections to the public internet.b.A pod can only connect to the public internet and cannot initiate connections to internal hosts thatare outside the OpenShift Container Platform cluster.c.A pod cannot reach specified internal subnets or hosts outside the OpenShift Container Platformcluster.d.A pod can connect to only specific external hosts.E-book Architecting for HIPAA Security Rule5
Traffic isolationThere is no specific legal requirement for traffic isolation. In most cases, encapsulation through theVXLAN and GENEVE overlay and filtering through NetworkPolicy will meet segmentation and isolation requirements. However, in some cases, traffic will need to be further isolated. This isolation maybe accomplished by using multiple networks, hardware, multiple ingress controllers, or third-partynetwork solutions.NetworksAdditional network segmentation may be required based on existing internal security standards,including data and control plane isolation. In this type of configuration, all pods continue to usethe cluster-wide default network but additional interfaces may be added via the Multus containernetwork interface (CNI). You specify each interface by using a custom resource (CR) that has aNetworkAttachmentDefinition type. A CNI configuration inside each of these CRs defines howthat interface is created.The following additional network interface types may be used with the Multis CNI:a.“bridge”allows the use of a bridge network Ipvlan”allows access to a specific host’s physical ethernet device.attaches the pod to a macvlan interface with a unique mac address.allows segmentation with vlan segmentation but shares an interface mac address.Hardware networksThe single root input/output virtualization (SR-IOV) CNI plug-in provides the ability to plumb a virtualfunction (VF) allocated from the SR-IOV device plug-in directly into the pod.Third-party vendorsThird-party network and SDN solutions may be used with Red Hat OpenShift through the CNI.Specific feature questions should be directed to the vendor.StorageFor any given Red Hat OpenShift deployment there may be a few storage backends used—forexample, the underlying disk images for control plane and compute nodes, and an S3 storage bucketfor the registry in Amazon Web Services (AWS) deployments. For the purpose of this section, we willdefine storage as persistent storage volumes used with Red Hat OpenShift.Red Hat OpenShift uses the Kubernetes persistent volume framework to provision persistentvolumes (PV). A PV is independent of any namespace. Developers use these persistent volumes witha persistent volume claim (PVC). PVCs are a method for the developer to request and attach the PVto a pod. The PVCs are restricted to the project namespace.Persistent storage life cycle1.Storage administrators do one of the following: Attach one or more dynamic provisioners so PVs are automatically created on request. Create PVs manually in advance of any request.redhat.comE-book Architecting for HIPAA Security Rule6
2.A user requests a PVC and a PV is bound.3. Thecluster inspects the claim to find a bound volume and mounts the volume for the pod.4. Thestorage object in use protection feature ensures that PVCs in active use by a pod and PVs thatare bound to PVCs are not removed from the system, as this can result in data loss.5.When you are finished with a volume, you can delete the PVC object from the API, which allowsreclamation of the resource.reclaim policy of a PersistentVolume tells the cluster what to do with the volume after it isreleased. The volume’s reclaim policy can be designated as Retain, Recycle, or Delete.6. TheFor storage that contains ePHI, the primary consideration is how the storage attaches to the Red HatOpenShift control plane and compute node and how the storage is encrypted “at-rest.” Typically, inenvironments containing ePHI, the at-rest storage will be encrypted by the backend storage provider.The storage traffic may also need to be encrypted on untrusted networks or you may use dedicatedstorage area network (SAN) or network attached storage (NAS) networks to segment the storagetraffic. It is critical to understand how storage is attached and secured for workloads containing ePHI,not just that the backend storage is encrypted at-rest.Red Hat OpenShift has a number of backend storage choices. The following sections detail theprimary considerations with each option and how they may impact your decision to use them.Cluster attached storageThese storage backends are attached to the cluster, with storage traffic traveling over the clusternetwork to the Red Hat OpenShift nodes: Red Hat Openshift Container Storage Amazon Elastic File System (EFS) Microsoft Azure File Internet small computer systems interface (iSCSI) Network file system (NFS)Encryption of the storage at-rest is dependent on the storage backend. Storage production readiness and availability for PHI should be reviewed as storage may still be in tech preview or not yet certified for ePHI by the storage provider.Host and hypervisor attached storageEach of these storage backends are attached to the physical host or hypervisor: AWS Elastic Block Storage Azure Disk OpenStack Cinder Fiber Channel Google Compute Engine (GCE) Persistent Disk VMware vSphereredhat.comE-book Architecting for HIPAA Security Rule7
Traffic to and from Red Hat OpenShift nodes and the attaching of volumes is managed at the physical host or hypervisor level. Encryption of the storage at-rest is dependent on the storage backend.Storage production readiness and availability for PHI should be reviewed as storage may still be intech preview or not yet certified for PHI by the storage provider.Red Hat CoreOSRed Hat Enterprise Linux CoreOS is a purpose-built operating system that provides a base on whichRed Hat OpenShift can run. Red Hat Enterprise Linux CoreOS is built on the same technologies asRed Hat Enterprise Linux and provides the same security and segmentation features. While all communication between Red Hat OpenShift components includes security and encryption, and containers are intended to be immutable and ephemeral, there could be local data stored on the nodes in thecluster. The container will use locally attached storage—anything written within the container that isnot written to a PV is actively being stored on the underlying host filesystem. To ensure unencrypteddata is not exposed through the base operating system, you should use self-encrypting disks (SED),encrypted enterprise storage, or encrypted block storage provided by an external cloud provider.Red Hat Enterprise Linux CoreOS also supports Linux Unified Key Setup (LUKS) disk encryptionsecured with Trusted Platform Module (TPM) v2 or Network Bound Disk Encryption (NBDE), whichrequires a Tang server.For more information, read the Red Hat OpenShift Container Platform 4.5 installation guide.Red Hat OpenShift - KubernetesKubernetes is an open source container orchestration technology that automates many of the manualprocesses involved in deploying, managing, and scaling containerized applications. Kubernetes is acore component of Red Hat OpenShift.Red Hat OpenShift is an enterprise open source container application platform and is a CNCFcertified Kubernetes distribution. Red Hat OpenShift enables and delivers stricter security policiesthan Kubernetes by itself. It is good security practice, though, to use some type of threat modelwhen evaluating how to modify behavior for an enterprise environment.Although this document isspecific to HIPAA, we will review some threats to our HIPAA data and HIPAA architecture using theSTRIDE model: Spoofing Tampering Repudiation Information disclosure Denial of service Elevation of privilegeSpoofingRed Hat OpenShift implements a least-privilege model, with built-in authentication and authorization. By default, in Red Hat OpenShift, privileged containers cannot run on compute nodes. However,you need to be sure that the applications you deploy on Red Hat OpenShift cannot be spoofed, whichwould lead to compromised applications and data.redhat.comE-book Architecting for HIPAA Security Rule8
Although the Red Hat OpenShift security model requires its components to authenticate via mutualTLS, it is only as secure as the certificate authority (CA) that issues the certificates. A compromisehere will lead to an ineffective mutual TLS (mTLS) layer. A best practice is to only use internal Red Hat OpenShift CAs within the cluster. Another best practice is to use custom certificates. One for authentication of internal componentsand one for external endpoints. Set the automountServiceAccountToken to false for pods that do not need to communicate withthe API server. Use secrets to mount certificates into pods that can be used for authentication of pod identity. Consider integrating with an external vault to manage application secrets. If a service token needs to be mounted, use the configurations for expirationSeconds and audience.TamperingThe security of our information depends on the ability to ensure that data is not maliciously altered.This data integrity is critical, as tampering can lead to elevation of privileges.These Red Hat OpenShift components can be tampered with, which could result in information loss ordamage: etcd, the key-value store that persists the state of all resource objects API server Kubernetes configuration files Container runtime binaries Container images Kubernetes binariesRed Hat OpenShift provides protection for its platform components out of the box. TLS is the general tool for protecting against tampering of data in-transit. All communication to the Red Hat OpenShift API server is over TLS. Only the Red Hat OpenShift API server is allowed to communicate with etcd. All Red Hat OpenShift components are managed with Kubernetes operators, ensuring that onlysupported configuration changes are allowed. If an unsupported configuration change is made, theoperator for that component will reset the change or mark the component as degraded. Red HatOpenShift operators help to manage configuration drift. The container runtime is protected with Security-Enhanced Linux (SELinux), kernel and networknamespaces, Cgroups and, optionally, secure computing mode (seccomp) profiles. Red HatOpenShift Security Context Constraints (SCCs) give the Red Hat OpenShift administrator theability to easily make use of Red Hat Enterprise Linux security features, such as dropping Linuxcapabilities, and apply those restrictions across pods deployed to the cluster. The restricted SCC isredhat.comE-book Architecting for HIPAA Security Rule9
applied to all worker nodes, preventing the running of privileged containers, and preventing accessto the host network and filesystem. If it is necessary to run a privileged pod, a privileged or customSCC can be applied to the pod.These additional recommendations will enhance the security of your Red HatOpenShift cluster dataat-rest: Restrict access to the control plane by configuring a separate ingress controller. Restrict access to repositories with Red Hat OpenShift configuration files. Perform bootstrapping over Secure Shell (SSH) and safeguard the SSH keys. Restrict access to the image registry and associated repositories. Encrypt the etcd datastore. Implement a process to review the securityContext of the pod manifest file to ensure that unnecessary privilege and access is not requested. Image pull secrets.RepudiationIn information security, non-repudiation is the inability to deny.A good practice is to use an audit daemon to watch for write actions on files and directories on thecontrol plane and data plane. In Red Hat OpenShift, API server requests and events are logged bydefault. For additional host audit, auditd can be configured in Red Hat Enterprise Linux CoreOS.Red Hat OpenShift includes an optional Elasticsearch, Fluentd, and Kibana (EFK) logging stackthat collects cluster logs. The ability to collect application logs using the same stack is available as atech preview feature. The Red Hat OpenShift logging stack can be used to forward all logs, includinghost and cluster audit logs, to the security information and event management (SIEM) system ofyour choice.Information disclosureIf using key encryption keys (KEKs) outside the cluster, it may be considered to use a hardware security module (HSM) if on-premise or key management service (KMS) for storing key encryption keyson a public cloud.When storing data for pods, such as passwords or database strings, store them in secrets.If storing the same type of data in a datastore outside of the pods in persistent volumes orConfigMaps and the data is encrypted, keys for decrypting them should be stored in secrets.Denial of serviceRed Hat OpenShift always runs multiple control plane nodes in a high-availability (HA) configurationto avoid a single control plane node becoming a point of failure. If running in the cloud, you shouldconsider replicating control plane nodes across availability zones to prevent consequences ofattacks on the network of a particular zone. Make sure to account for the low latency requirementsfor etcd communication. In Red Hat OpenShift 4, etcd members are automatically deployed to thecontrol plane.redhat.comE-book Architecting for HIPAA Security Rule10
The same principles apply to the data plane nodes. Other considerations for mitigating attacks is
Architecting for HIPAA Security Rule Security and compliance on Red Hat OpenShift 4. . If deploying across public cloud or third party datacenters, the covered entity is typically required to have a business associat
