IBM i systems used by enterprises in regulated industries face specific challenges in migrating to the cloud, but there are ways around some of the biggest problems.

By John Ghrist

IBM Power Systems and its predecessor platforms are strongly represented in regulated industries (e.g., banking, healthcare, insurance, government) that must follow national laws set up for these types of market sectors. These most notably include the Payment Card Industry Data Security Standard (PCI DSS), which requires protection of payment card account information; the Sarbanes-Oxley Act of 2002 (SOX), which mandates security controls on financial data and annual reporting/auditing of those controls; the Health Insurance Portability and Accountability Act (HIPAA), which specifies measures needed to protect the security and privacy of individual's data in the healthcare industry; and Europe's General Data Protection regulation (GDPR), which governs handling of the personal data of European Union residents.

While these laws provide numerous necessary benefits in preventing the loss or compromise of individuals’ financial data and transactions, the stringency of implementing and tracking the success rate of these and other government-mandated compliance tasks can be a crucial stumbling block for enterprises wanting to adopt cloud technology. Requirements such as industry standards compliance, security and privacy concerns, data sovereignty and storage location limitations, cross-border data transfers, auditing and reporting strictures, and governance and cost tracking needs, among others, can be a challenge for a worldwide cloud storage and processing environment in which geography is often irrelevant.

Systems of Record

Power Systems running IBM i are primarily used as Systems of Record (SoR), which means they serve as authoritative sources of verified business information about crucial data entities such as customers, products, and employees within a specific domain. (SoRs can be easily confused with Single Sources of Truth (SoT), which aggregate and reconcile differences between data sources, as well as providing an overview of data from multiple SoRs.) SoRs provide a primary data source that verifies that available information is validated and timely, as well as methods for accurately synchronizing data across an enterprise's information systems.

Regulatory compliance, however, can present challenges to an SoR. Government regulations mandate how, where, and which users can access a system, depending on the type and sensitivity of the data it contains. The need to keep data accurate requires commitment to ongoing data governance that's supported at the highest levels of an enterprise. In situations where the users accessing the information are diverse, an SoR must also balance data availability with differing opinions about what constitutes authoritativeness. Consumers may be looking for different kinds of information than internal users, for example. In addition, the auditing requirements will differ between on-premises and cloud-supported environments.

On-premises systems give enterprises complete control over their infrastructures, particularly guarding against any data leaving the premises and prohibiting third-party participation in data processing or storage. Such systems also require Write-Once Read-Many (WORM) storage configurations to protect the integrity of audit logs and make misconfigurations more likely to cause audit failures. Retention policies are manual and depend on staff reliably enforcing them. Data must be exported via on-site retrieval, which can be unreliable under incident conditions. Low baseline latency (i.e., providing minimal time between a read/write and the system's response to a user) is better for apps where milliseconds count (e.g., financial trading, Internet of Things operations) and is easiest to maintain in on-premises systems. Although they require more resources and maintenance, on-premises systems provide full control over auditing software and methods.

In contrast, cloud environments extend the necessary boundaries of auditing to the cloud provider and its environment, requiring negotiation about how responsibilities should be divided between the user enterprise and the service provider(s). Some providers offer unalterable storage and audit logging policies only as managed services at additional cost. However, cloud providers can offer lifecycle policies that are sensitive to regulatory timelines and improve regulatory compliance via their own enforcement policies. API-controlled data exporting can facilitate a faster response to audit demands by delivering audit-ready data in hours. Inter-zone network hops in cloud environments offer flexibility and scalability but can increase audit-log transmission times. Security concerns, particularly encrypting sensitive information, require a sharing of responsibility for data protection between the CSP and the data owner.

In hybrid cloud environments, audit boundaries can span multiple time zones and shift non-critical audit processing to cloud nodes while keeping sensitive data tasks on-premises. Still, these capabilities require real-time network hardware and adaptive policies to support such mixed infrastructures — which may not be solely under the data owner's control when using a cloud service provider (CSP). In addition, software-based auditing from a CSP offers expedited provisioning, scalability, and automatic updates for regulatory requirements, but means reduced control over infrastructure for the user enterprise.

These and other complications make adopting cloud for SoRs require a necessary focus on creating a wider strategy to meet compliance issues than is possible when keeping all data private to the enterprise and foregoing the benefits of cloud technology.

Moving to the cloud involves choosing a service model that best suits enterprise needs. There are four major models. In Infrastructure as a Service (IaaS), the CSP offers virtualized servers, storage, and networking resources, and the user enterprises manage applications, middleware, and operating systems. Platform as a Service (PaaS) provides a managed environment that includes middleware and databases for application development; Software as a Service (SaaS) supplies Internet-accessible, fully managed applications; and Function as a Service (FaaS) provides an environment for executing code that scales automatically but doesn't require managing servers.

Shared Responsibility Models

IBM offers several products for IBM i that simplify and ease some of the burdens involved with moving processing in regulated industries to the cloud without leaving the IBM i platform. For Power Systems running IBM i, IBM addresses this challenge with a comprehensive suite of services called IBM Cloud, which serves as a good example of the "shared responsibility" models organizations in regulated industries need to meet.

*IBM Cloud shouldn't be confused with IBM Power Virtual Server (PowerVS), which is not a standalone service, but an extension of IBM Power Systems that provides access to more than 250 IBM Cloud services (e.g., DevOps, IBM Db2, disaster recovery) via APIs and functions as a Power-specific Infrastructure as a Service layer within IBM Cloud. PowerVS isn't a requirement for IBM Cloud use.

Moving to a cloud environment means physical security of the data center and its underlying infrastructure, as well as maintaining the hardware, networking, and visualization aspects of the computing environment, becomes the responsibility of the cloud provider. The customer retains responsibility for protecting the data via encryption and other means, securing apps and operating systems, and controlling identity and access management (IAM).

The shared responsibility model enables organizations to offload operational burdens to the cloud provider, enabling them to focus on their core business. It also leverages the provider's advanced security capabilities, such as threat detection and automated patching, to enhance overall security posture.

Under IBM Cloud in operations management, IBM is responsible for system monitoring, problem determination, high availability, and recovery. The customer may have to manage application-level monitoring and reporting issues to IBM. In change management, IBM controls platform upgrades, patches, and infrastructure configuration. Customers are responsible for application and data deployment, configuration, and updates. In the IAM area, IBM handles the security of the platform and infrastructure, while customers are responsible for application and data authentication, authorization, and access policies. In the area of security and compliance, IBM institutes security controls and handles compliance certification for cloud infrastructure. In the domain of disaster recovery, IBM is responsible for keeping infrastructure operational in unaffected areas while customers manage application and data recovery operations.

In general, governance accountability remains with the customer, although customers can choose services that delegate risk management. Compliance is a shared responsibility spelled out in contracts and specific compliance stipulations, as modified by the cloud service model selected by the customer. Specific delineations of security responsibilities are available via the Cloud Security Association's document on critical areas of focus in cloud computing.

Support for Data Residency Policies with DB2 for IBM i

Another important IBM offering in supporting cloud operations for enterprises in regulated industries on IBM i is DB2 for IBM i, a product suite that helps users secure confidential data physically located in an IBM i environment, thereby avoiding the need to move such data to external servers maintained by a CSP. The product handles all backups, processing, and storage on the IBM i; supports role-based access, data encryption, and audit logging; provides integrated utilities that can back up DB2 data directly to IBM i storage and thereby maintain data residency on the platform; and the platform itself supports regulatory compliance features such as audit trail, data classification, and retention policies. In addition, users can manage the product via IBM i command lines, SQL commands, and integrated additional products such as IBM i Access Client Solutions. IBM i also provides onboard performance monitoring and tuning tools to ensure best use of local resources, and data is shareable with other IBM i systems via Distributed Relational Database Architecture (DRDA) or Portable Application Solutions Architecture (PASE).

*A few native IBM i capabilities enhance compliance and data protection functions. For example, Authority Collection collects data associated with runtime authority checks and forwards it to a repository that displays and analyzes it. Audit Journal (QAUDJRN) enables auditing on a system-wide basis for all users, auditing for specific objects, and auditing for specific users. Row and Column Access Control (RCAC) controls access to tables at the row and column levels (or both). Field Procedures checks access to ILE *PGM objects when a field procedure is added to a table.

Key Protect for IBM Cloud Handles Encryption Management

IBM Key Protect for IBM Cloud is a native application that lets users provision, manage, and govern encryption keys for any IBM apps stored in the cloud. The product offers 140-2 Level 3 (for standard tiers) and 140-3 Level 4 (for dedicated tiers) (although the latter doesn't support import tokens), hardware security models (HSMs), and telemetry that tracks user and application activities via IBM Cloud Activity Tracker and IBM Cloud Logs. The generated keys also contain other information, such as metadata that identifies the key and the key material (e.g., the key's format, private key elements that must stay confidential, and type of usage for each key) used to create it.

Import tokens are a temporary but secure means of authorizing and transferring encryption key material into a key management service (KSM) without transmitting the key in plain text. Key Protect generates a 4096-bit key pair and a public key for encrypting and uploading the key pair into the KSM. Key Protect verifies a user request to import the key pair, decrypts the encrypted packet, and stores the key material as a root key (i.e., a key used to protect other encryption keys that aren't used to encrypt data and are usually stored within an HSM).

*Third-Party Approaches to Compliance Issues on IBM i

There are several examples of IBM i-specific apps that help with compliance issues. Fortra’s SecureCare for IBM i helps users identify misconfiguration problems and provides ongoing monitoring and reporting of security settings for PCI-DSS, SOX, and HIPAA. Vanguard Compliance Manager for IBM i automates compliance with security standards and guidelines set by The Center for Internet Security (CIS) by setting up both a “high-security” and a “general use” compliance standard, and even automates baseline checks via a series of predefined questions with default answers. Seasoft’s Auditing and Compliance solutions provide such features as application and field-level monitoring, change management tracking, user authority provisioning, and compliance scoring and reporting.

Dealing With Cost-Performance Cloud Trade-offs

Enterprises in regulated industries can move to the cloud. Still, one cost is realizing that there are trade-offs that must be part of a permanent evaluation and optimization process. It can't be a strategic policy decision made at the outset of adoption and then conveniently set in stone. There are a few issues to address.

Let's start with the conflict between self-managed services and managed ones. Aside from the loss of control already mentioned, moving to the cloud requires finding a balance between lower operational overhead and paying ongoing subscription fees. Closely related is the question of latency (how long individual users must wait to get information they've requested). Keeping everything local generally means quicker response, but using the cloud means remote data retrieval, storage overhead, decryption, transmission glitches, and other factors that may cause perceptible delays. How long must a delay last before it's a business problem? Do the costs of networking outweigh those of reduced throughput?

How does the throughput factor affect the choice between using on-demand, reserved, or preemptible spot use instances? If the business has times of fluctuating demand, should it pay for auto-scaling policy support or risk overprovisioning when demand may not warrant it at times?

To make this choice, enterprises should define their own service-level objectives (e.g., latency, availability, and throughput), preliminarily decide how workloads map to cloud service categories (e.g., computing, storage, networking, supported app types), benchmark expected performance, and model the business impact of downtime or underperformance. Then commit to making these same evaluations periodically but permanently, because deciding how to balance these and other factors will always be a moving target.

*Fundamentally, successful cloud adoption for regulated IBM I environments is a governance and architectural exercise rather than simply a technology migration. Overall, enterprises in regulated industries may find that IBM's cloud-related product and service offerings provide answers to several major problems that should be considered before rejecting cloud technology out of hand.

John Ghrist has been a journalist, programmer, and systems manager in the computer industry since 1982. He has covered the market for IBM i servers and their predecessor platforms for more than a quarter century and has attended more than 25 COMMON conferences. A former editor-in-chief with Defense Computing and a senior editor with SystemiNEWS, John has written and edited hundreds of articles and blogs for more than a dozen print and electronic publications. You can reach him at This email address is being protected from spambots. You need JavaScript enabled to view it..