IBM Hyper Protect Virtual Servers on-premises
This chapter introduces IBM Hyper Protect Services on-premises offering and includes the following topics:
5.1 Introduction to IBM Hyper Protect Virtual Servers on-premises
IBM Hyper Protect Virtual Servers on-premises (referred to as IBM Hyper Protect Virtual Servers) is a virtualization platform that protects and hosts Linux container workloads on IBM Z and LinuxONE servers throughout their lifecycle, build, management, and deployment phases. This solution delivers the security that is needed to protect mission-critical applications in hybrid multicloud deployments.
IBM Hyper Protect Virtual Servers offering provide an encrypted environment (data at-rest and data in-flight), with peer-to-peer and peer-to-host isolation that protects container applications from access by way of hardware and operating system administrator credentials, whether access is accidental or malicious, and internal or external to an organization.
These servers ensure that your applications can be deployed and managed from trusted sources without the infrastructure team accessing the data, secrets, or application.
IBM Cloud Hyper Protect Virtual Servers address the security concerns of regulated enterprises. To provision one of these Linux Virtual Servers in the public cloud, it requires the user to provide a public SSH key, which means that only the user can access.
These Virtual Servers are built on IBM LinuxONE technology, which provides built-in workload isolation, tamper protection from privileged user access, and encryption of all data at-rest and in-flight. IBM Cloud Hyper Protect Virtual Servers provide data protection and security in the cloud without sacrificing vertical scalability or performance.
IBM Hyper Protect Virtual Servers enable the following users:
•Developers to securely build their applications in a trusted environment with integrity.
•IT infrastructure providers to manage the servers and virtualized environment where the applications are deployed without accessing those applications or their sensitive data.
•Application users to validate that those securely built applications originate from a trusted source by integrating this validation into their own auditing processes.
•Chief Information Security Officers (CISOs) to be confident that their data is protected and private from internal and external threats.
IBM Hyper Protect Virtual Servers includes the following key benefits:
•Protect workloads from internal threats
Hyper Protect Virtual Servers is the evolution of the IBM Secure Service Container for IBM Cloud Private. As with Secure Service Container technology, Hyper Protect Virtual Servers protect your workloads from internal and external threats. On premises, the enhanced capabilities provide developers with security throughout the entire development lifecycle.
•Apply cloud native app development
Empower developers with familiar tools and an automated, continuous software delivery pipeline to develop in a private, public, or hybrid cloud. Hyper Protect Services provide secure cloud services for on- and off-premises deployments.
•Simplify management
Fully integrate IBM Z and LinuxONE into a hybrid multicloud environment and manage everything from behind the firewall. Hyper Protect Virtual Servers reduce user management of low-level execution environment and uses EAL5+ certified LPARs for peer isolation. Although cloud and infrastructure providers cannot access your sensitive data, they can manage images by using APIs.
•Extend encryption everywhere
Advanced data encryption, key management, and tamper-resistance incorporates security and compliance as a part of DevSecOps, rather than adding in security measures after the fact. Application secrets are encrypted, which ensures that the confidentiality of the application is protected. Cloud providers and system administrators cannot access data, which protects against insider threats and malicious attacks.
•Maintain image integrity
With IBM Hyper Protect Virtual Servers, developers can securely build source files, starting with the containerized application. Solution developers can keep image integrity, knowing it contains only what is intended, and maintain confidence in the deployed application’s origin.
•Build securely with trusted CI/CD
All images can be encrypted and securely built with a trusted CI/CD flow. Developers can build images and ensure that users can validate their origin, which removes the possibility of a back door introduction during the build process. Signed container images inherit security without any code changes, which preventing access to data while it is being processed in the database.
5.2 IBM Hyper Protect Virtual Servers key features
An IBM Hyper Protect Virtual Servers solution is deployed to a Secure Service Container based logical partition (LPAR). It uses IBM Secure Service Container technology to integrate security directly into the solution.
Although security policies and best practices are still a fundamental piece of enterprise security, a technological layer of security bolsters the enterprise’s ability to protect its sensitive data and workloads, even from threat vectors, such as internal threats and leaked privileged credentials.
IBM Hyper Protect Virtual Servers expand on the security benefits of IBM Secure Service Containers. This expansion creates a secure enclave to host the most secure data and applications by deploying into the virtual machine, with no need to modify the code of the application itself.
IBM Hyper Protect Virtual Servers use operational assurance to data protection and technical insurance (see Figure 5-1 on page 128). It is not technically possible for IBM or other parties to access data in the Secure Service Container.
Figure 5-1 Operational assurance versus technical assurance
The following features are described in this section:
•Trusted CI/CD
•GREP11
•User management
•Bring Your Own Image
•Encryption
5.2.1 Trusted CI/CD
Continuous Integration and Continuous Delivery (CI/CD) is a core principle of DevOps, and one of the main drivers behind cloud computing.
Continuous integration (CI) is a DevOps practice in which each developer integrates their work with the main branch of code regularly and consistently (preferably once a day, or many times a day). Continuous delivery (CD) is another DevOps practice that focuses on delivering any validated changes to code (updates, bug fixes, even new features) to users as quickly and safely as possible.
Continuous delivery picks up where continuous integration ends. It automates the delivery of applications to selected infrastructure environments. It also ensures automated pushing of code changes to different environments, such as development, testing, and production.
This practice of automated pushing and delivering of new code opens the door for vulnerabilities that might pass unnoticed. What occurs when a malicious actor gains access to the build process or repository from which the code is automatically updated?
Secure Build
The first step to ensure the code or application that is running in your virtual server is safe is to ensure that the build process is not vulnerable. Without the proper security at build, application developers can deliberately or accidentally introduce vulnerabilities into the source. Application builders also can build alternative source code and introduce harmful artifacts.
IBM Secure Service Container technology contains features that alleviate this risk, such as static code scanning, to identify common coding errors and image scanning to identify if an image contains a component that is known to be vulnerable.
IBM Hyper Protect Virtual Servers contains a component that is called the Secure Build Server (SBS), which is packaged as a container and loaded into the Secure Service Container by using a command line tool. By using the securebuild command, you can build, tag, sign, and push images to a trusted repository.
For more information about Trusted CI/CD and Secure Build, see 7.2, “Trusted CI/CD: Building and deploying containers securely” on page 197.
Repository Registration
The Secure Build feature works hand-in-hand with Repository Registration. From a Secure Build, containerized application images are signed with GNU Privacy Guard (GPG) keys when published, and verified again when it is deployed. The signing keys are generated within the secure build process and your private keys are never revealed. Only the images that are generated by using the secure build procedure can be uploaded to the organization’s container repository and installed onto the Secure Service Container partitions. The repository and the containerized images are protected with different keys on different stages.
The Secure Service Container partition pulls images from only the registered repository, and creates Hyper Protect Virtual Server instances of those images on the partition. Registration is simple with a few standard commands.
For more information about the commands that are required to register and use your repository with Hyper Protect Virtual Server images, see IBM Knowledge Center.
For more information about Repository registration, see 7.5, “Bring Your Own Image (Trusted Repository Registration)” on page 216.
5.2.2 GREP11
IBM Hyper Protect Virtual Servers provides Enterprise PKCS #11 over gRPC containers for crypto operations, such as key generation, encryption, decryption, and data wrapping and unwrapping. With the Enterprise PKCS #11 over gRPC (GREP11) containers, you can integrate your application with the asymmetric (public and private) key pairs that are generated by the Hardware Security Modules (HSM) on the IBM Z or LinuxONE servers. GREP11 is a stateless interface for cryptographic operations on cloud.
|
Note: IBM Hyper Protect Virtual Servers Version 1.2.0 allows a solution developer to access crypto express domain and use it to generate the asymmetric (public or private) key pairs for signing or encrypting as needed by the deployed application. An enhancement is planed in 2020 for a post GA version where a solution developer can access crypto express domain and use it to generate the asymmetric (public/private) key pairs for signing:
•The application in the secure build flow
•The built manifest file from the secure build flow
|
For more information about GREP11, see 7.4, “GREP11 (EP11 over gRPC)” on page 210.
5.2.3 User management
One of the primary concerns that IBM Hyper Protect Virtual Servers mitigates is attack vectors from internal threats. Historically, enterprise security focused on building walls around the organization to protect from external threats. However, recent studies show that most data leaks and breaches are the result of malicious actors inside the organization, or the leaking of those individuals’ internal credentials. Firewalls, remediation of vulnerable software, and strict security policies do not do much to prevent an employee with root access to the system from stealing sensitive data.
On traditional cloud platforms (public cloud and on-premises), typically a single superuser (cluster administrator or similar role) has full access to the solution stack, from hardware to the containerized applications that are running in the environment.
With Hyper Protect Virtual Servers, administrative responsibilities are split between various roles, and each role accesses only the parts of the environment for which that role is responsible. If each administrative role is given to separate individuals in the organization, one person cannot access all of the data that is present in the virtual machine.
For more information about user management, see 7.1, “User roles in Hyper Protect Virtual Servers” on page 196.
5.2.4 Bring Your Own Image
IBM Hyper Protect Virtual Servers allow the deployment of images from only trusted, registered repositories into the hosting appliance. This feature prevents users from loading potentially harmful images from external repositories that are not officially trusted by the organization. Because this feature is part of IBM Secure Service Container technology and the hosting appliance, registered repositories are not a new feature.
However, a limitation with registered repositories was that only IBM can create the necessary JSON registration files. IBM Hyper Protect Virtual Servers introduces Bring Your Own Image (BYOI), a new feature that allows users to create their own JSON registration files so organizations can decide for themselves which registry they want to trust, and then deploy images from that registry.
For more information about Bring Your Own Image, see 7.5, “Bring Your Own Image (Trusted Repository Registration)” on page 216.
5.2.5 Encryption
IBM Hyper Protect Virtual Servers provide various security advantages by using the IBM Secure Service Container as the solution’s hosting environment.
IBM Secure Service Container supports the deployment of software container technology without requiring application changes to use the security capabilities. To gain these security capabilities, a user must deploy only their workload into the Secure Service Container. This feature is especially useful considering the regulatory focus on protecting critical data from internal and external threats, as shown in the following examples:
•The infrastructure and data are protected against access and abuse by root users, system administrator credentials, and other privileged user access.
•Infrastructure management organizations can manage the physical IT infrastructure without having visibility to the user’s applications and customer data.
As a system or appliance administrator who manages the underlying infrastructure, you can download the appliance, deploy it, and then make it available on their system for their developers.
A developer can focus on creating their containerized solution and deploy it into this environment, and still know that their solution is not visible to the system administrator.
Various security mechanisms are applied to protect the data in the IBM Hyper Protect Virtual servers. For more information, see 5.5, “A sample use case: Hyper Protect Virtual Server for secure storage” on page 138.
For more information about the cryptographic capabilities of the Secure Service Container web server and other solution components, see IBM Knowledge Center.
5.3 IBM Hyper Protect Virtual Servers use cases
As enterprises move their data to the cloud, concerns around security, privacy, and regulation inhibit many enterprises from moving their sensitive data and workloads. As the probability of a breach rises every day, so too does the costs that are associated with breaches; that is, costs because downtime, fines, and damage to brand image can be steep.
IBM Hyper Protect Virtual Servers incorporate the security capabilities of Secure Service Containers with the cloud, so that stakeholders can be comfortable knowing that their data and workloads are protected by the IBM LinuxONE platform, even in the cloud.
IBM Hyper Protect Virtual Servers also provide a way to deploy a virtual server in a Secure Service Container to ensure confidentiality of data and code that is run within that virtual server. No external access to data is possible, even for privileged users, such as cloud administrators. Only the user who provisioned the virtual server with the public keys can access the virtual server.
A virtual server with this high level of security is applicable to use cases across businesses and workloads of all types, for on-premises and public cloud environments. The following sections describe a few examples of IBM Hyper Protect Virtual Servers that are in use around the world.
An organization might be inclined to keep all of their data and workloads on their own hardware, in their own data center, or managed by their own people for many reasons, including the following examples:
•Compliance
Many regulated industries, such as Financial Services, Healthcare, and Government feature strict requirements about where data is located, and who can access it. Many countries, states, and other levels of government have their own compliance standards that must also be met.
•Protection of intellectual property
Some companies are not limited by compliance, but because of the sensitive nature of their data and intellectual property, they do not trust a third party to host it. Instead, they want to rely on themselves to manage the security and privacy responsibilities.
However, the need to keep data in-house does not need to be a reason to avoid cloud technology altogether. IBM Hyper Protect Virtual Servers can be integrated into an on-premises, private cloud infrastructure to gain all of the benefits of a cloud platform while retaining complete control of the data, security, and management.
IBM Hyper Protect Virtual Servers protect Linux workloads on IBM Z and LinuxONE throughout their lifecycle build management and deployment. This solution delivers the security that is needed to protect mission-critical applications in hybrid multi-cloud deployments.
Consider the following IBM Hyper Protect Virtual Servers on-premises use cases:
•Digital asset custody
In recent years, the video game industry transformed into an online and digital market, rather than distributing physical copies of their games for consoles. This digital transformation means that the gaming industry is a prime candidate for a cloud platform.
A large gaming company wanted on-demand environments for their developers with easy integration into existing facilities, services instead of hardware purchases, and environmental control. The company tapped into an IBM Hyper Protect Virtual Server in a private cloud that is connected to customer facilities, which gives developers the needed environments while satisfying administrators’ requirement for control and visibility.
•Workload sensitivity
A financial services firm wanted a retail payment fraud prevention production environment. Because of workload sensitivity, the firm did not consider public cloud an option. Its IT leaders wanted environmental control and security, bare metal database servers for performance, advanced storage features, and reliable, consistent pricing. IBM created three interconnected private clouds (two in North America and one in Europe), which provided the environments they needed and were close to their operations and customers.
5.4 IBM Hyper Protect Virtual Servers architecture overview
Figure 5-2 shows the IBM Hyper Protect Virtual Servers on-premises architecture.
Figure 5-2 Hyper Protect Virtual Servers on-premises architecture
The following a various components are part of the Hyper protect Virtual Servers on-premises solution:
•PR/SM
Processor Resources/System Manager is a type1 hypervisor that allows multiple logical partitions that share same resources, such as CPU, IO channels, and LAN interfaces.
•SSC LPAR
The partition that is LPAR type runs on IBM Z servers that are based on Secure Service Container framework.
•Secure Service Container
Secure Service Container is a container technology that is a runq-based, virtualized Docker container environment that provides containers isolation and data protection on top of the IBM Z or LinuxONE servers.
•Hosting Appliance
A software appliance that supports REST API access to the resources on the Secure Service Container.
•Docker Engine
Open source containerization technology with workflows to build and containerize applications.
•runq
runq is a specialized Docker runtime environment that is used to create a dedicated QEMU virtual machine (VM) for each instantiated Docker image. It also provides for each of those QEMU VMs a dedicated guest operating system kernel, and later used as the runtime environment for workloads.
It is an open-sourced hypervisor-based Docker runtime environment, which is based on runc to run regular containerized images in a lightweight KVM or QEMU virtual machine.
•runc
runc is a CLI tool for creating and running containers according to the Open Container Initiative (OCI) specification.
•Hyper Protect Virtual Server
IBM Hyper Protect Virtual Server for on-premises provides a secure virtualized infrastructure for private cloud deployments; that is, to protect the entire lifecycle of critical Linux workloads during their build, deployment, and management on-premises.
•Command Line Interface Tool
A management server or node where the CLI is available to manage the lifecycle operations of various containers that are deployed on Hyper Protect Virtual Servers on-premises solution. It provides the following command set:
– Automate the base infrastructure of the IBM Cloud Private worker and proxy nodes by using the isolated VM image.
– Create and manage the Hyper Protect Virtual Server container.
– Securely build and publish your applications as containerized workloads.
– Deploy your containerized workloads to the Secure Service Container framework.
– Monitor IBM Hyper Protect appliance health, such as the usage of CPU, memory, disk, and uptime.
– Provide Enterprise PKCS #11 (EP11) interfaces for crypto operations, such as key generation, encryption, decryption, and data wrapping and unwrapping in EP11 over gRPC (GREP11) client applications.
•Secure Build Server
The container that provides building the application code from a Git-like source repository into a container image for s390x architecture, signing the image by using the authentication keys, and publishing the image to the remote repository for later integration. Figure 5-3 shows the Secure Build Server.
Figure 5-3 Secure Build Server
•Repository
A repository is a set of containerized images. A repository can be shared by pushing it to a registry server. Different images in the repository can be labeled by using tags; for example, hpvsop-base.
•Registry
A registry is a hosted service that contains repositories of container images that respond to the Registry API; for example, Docker Hub.
•Registration files
A registration file is used to register the repository for authentication or validation reasons, such that a Hosting Appliance trusts that the image is authentic when pulled from the registry.
•Bring Your Own Image (BYOI)
A base image of Hyper Protect Virtual Server container that can be used to host customer application code. Customer can create to build an image by using this base image and application code that uses BYOI capability that is provided in Hyper Protect Virtual Server on-premises solution. Figure 5-4 shows the BYOI registration files flow.
Figure 5-4 Bring Your Own Image (BYOI)
•hpvsop-base
The Docker image of the base Hyper Protect Virtual Server image without the SSH daemon
•Appliance monitoring
Monitoring images that enable in gathering metrics, such as CPU, memory, disk, uptime, and load from Secure Service Container. Two containers support of monitoring appliance level metrics, such as CPU, memory, disk, up-time, and load from Secure Service Container: One container operates on runq, the other container operates on runc. Figure 5-5 shows the monitoring containers integration.
Figure 5-5 Monitoring containers integration
•PKCS#11 and EP11
PKCS #11 is a Public Key Cryptography Standard that defines a platform-independent API to cryptographic tokens, such as hardware security modules (HSM) and smart cards. EP11 (Enterprise PKCS #11) is a library that is implemented by the Cryptographic Service Providers (CS) back end.
•GREP11
GREP11 is a Container (GREP11-container) that provides Enterprise PKCS #11 (EP11) interfaces over gRPC, which communicates with Hardware Security Module (HSM). This container provides interfaces for crypto operations, such as encrypt, decrypt, get mechanisms, wrap, and unwrap. Figure 5-6 on page 138 shows the Grep-11 integration architecture.
Figure 5-6 GREP11 integration architecture
5.5 A sample use case: Hyper Protect Virtual Server for secure storage
In a cloud native environment, applications are deployed as microservices. Using stateless systems does not work well for applications that are prone to failure. To enable effective recovery from application failures, data persistency is necessary. To persist the data, system administrators must provision volumes that need to be used by the applications for storage.
With more data, the responsibility of securing it also increases. System administrators must answer the following questions before configuring these data volumes:
•Where should the secondary volumes be stored?
•How will the volumes be managed?
•How are applications going to access these volumes?
•Should the data be replicated or distributed storage?
Third-party software defined storage solutions are available that can help system administrators with challenges. But, how to secure this environment? With more security in place, a chance of overdoing it is possible, which results in a complicated environment that is difficult to manage and troubleshoot.
While deploying any new applications, system administrators must ensure that enough security is in place to prevent unauthorized application deployment. With images built into docker, a probability exists that those images might include vulnerable software.
When new applications are deployed, a system administrator must answer the following questions:
•How secure is this application?
•Is it going to make my platform vulnerable?
•How can any unauthorized application be prevented from being deployed in my platform?
•How can applications be prevented from accessing unauthorized directories?
When developers want to deploy a custom application in a private cloud, they must answer the following questions:
•Does the platform support custom applications?
•How can the application be deployed in the cloud environment?
•How it is going to be accessible by others?
•Will it get enough resources?
Hyper Protect Virtual Server answers most of these questions through the following features:
•Because ssh is disabled, no user can log in to the LPAR, which is the host of these applications.
•Every Docker image must be signed and uploaded into the repository.
•Unsigned docker images are not deployed into the LPAR.
•Developers can configure the required storage and CPU requirements for their application by using a configuration file. The Hyper Protect Virtual Servers CLI use this script to deploy the container.
•All containers that are deployed are runq containers as opposed to runc containers. The runc containers are a process that is running within a namespace; runq containers are almost a virtual machine.
•Users cannot mount any system directory into a container; therefore, the host is secured any unauthorized access and data leakage.
•Every image is associated with a repository definition file. These repository definition files are blueprints of runq containers. They contain information, such as the location of the image in repository and access credentials. Encrypting these files ensures the prevention of unnecessary data breaches.
•Monitoring servers enable system administrators to collect system-related data. Users can deploy the Prometheus server to publish the details.
•With features, such as Bring Your Own Image (BYOI) and Secure Build Server, customers can deploy their own custom images security. Also, unauthorized application deployment is prevented.
•GREP11 enables customers to take advantage of the hardware accelerated support of crypto operations. Currently, this feature enables developers and customers to manage keys and secrets securely.
The communication follows the gRPC standard along with the PKCS 11 standard for cryptographic operations; therefore, the name GREP11. Hyper Protect Virtual Servers makes it impossible to steal secrets and keys and customers do not need to worry about the performance implications because cryptographic operation can be resource hogging.
5.5.1 Creating a Secure Storage Server in Hyper Protect Virtual Servers
As described in 5.5, “A sample use case: Hyper Protect Virtual Server for secure storage” on page 138, in the world of cloud native applications where microservices come and go, it is important to persist data for effective recovery. Various technologies exist in the marketplace that provide data persistence. For this solution, use of GlusterFS is described next.
GlusterFS is a popular software-defined storage solution that is used for managing volumes. It is open source in nature and enables system administrators to provision distributed, replicated, or distributed-replicated volumes.
Customers can build GlusterFS containers with glusterfs-server and glusterfs-client packages, sign the image, and host it in an image repository by using a secure build server. Then, this image can be deployed in a Hyper Protect Virtual Servers environment by using the hpvs-cli command, such as HPVS create.
Containers in a Hyper Protect Virtual Servers environment are not typical Docker containers; they also are not virtual machines. For clarity, we say that these are Virtual Servers, which are little more than a Docker container, but little less than virtual machine (see Figure 5-7).
Figure 5-7 Sample container
Because GlusterFS server listens to port 24006 and 24007, applications can use GlusterFS client packages to communicate with the server and run volume management commands. Developers can write their own application to monitor the GlusterFS server by using api calls by using Python.
..................Content has been hidden....................
You can't read the all page of ebook, please click here login for view all page.