KRITIS-Relevant Cloud Transformation: Non-Technical Requirements Pose the Greatest Risk

A modern cloud-based payment platform typically consists of 400 to 500 so-called pods. Each of these pods contains either a core business application or components necessary for smooth operation, such as middleware, network access, or a database. A digital orchestrator, such as Kubernetes, manages these pods and ensures that all necessary resources are started and released. One of the key advantages of such architectures is that additional pods for a core application can be easily launched to handle emerging peak loads.

Large service architectures, such as a payment processing platform; therefore no longer need to be designed for permanently maintained peak load but can be optimized for normal load, with required processing capacities increased on demand. When people say that applications in the cloud scale better than monolithic applications, this effect plays a decisive role. However, this requires some design work to fully leverage all the benefits of a cloud architecture.

When properly prepared, entire service architectures can be deployed in just a few hours and controlled almost entirely by the orchestrator (Kubernetes). To achieve this, business applications must be stripped of anything that goes beyond their purely functional purpose. For example, the required middleware or configurations must no longer be hard-coded into the applications. Instead, the orchestrator provides them as needed. In operation, this results in several advantages that could not otherwise be realized:

• At every stage – from development to production – the necessary configurations and access data can be individually assigned to the pods.
• Configurations can be fully automated, ensuring that deployment across different stages proceeds transparently and repeatably with consistent quality.
• Version updates and the introduction of new features can be performed during ongoing operations, which is essential for real-time systems such as instant payments.
• Difference between technical and business configurations: Technical configurations are defined individually for each stage, while business configurations remain unchanged, ensuring that an accepted system can be deployed into production without modification.

The latter is the key factor enabling the service architecture within the cloud to be set up automatically. Thanks to Infrastructure as Code and a proprietary software tool (“Stagedive”), manual errors – particularly during staging (see Fig. 2) – are now virtually nonexistent on the payment transaction platforms operated by PPI for various banks, as the entire process is automated.

However, things get complicated due to the non-technical requirements. Anyone who first designs the architecture around the business applications and only then considers the requirements – particularly those mandated by EU and national regulators – may end up incurring more than just technical debt. The project could even fail because non-technical requirements account for such a large portion of the scope. It is important to note that these requirements are by no means features to be integrated into the technical applications; rather, they typically constitute cross-cutting applications in their own right. Consequently, they also impact other applications, such as those responsible for monitoring or logging.

Non-technical requirements thus represent, in and of themselves, an additional challenge for the overall architecture that must be considered. However, they also have an impact on the remaining components. This is all the more true if third-party services are to be integrated that come with availability and Service Level Agreements (SLAs) that may differ from those required for the platform. Key non-technical requirements include:

1. U.S. Exposure: The largest cloud providers (hyperscalers) create a U.S. exposure that must be effectively mitigated in order to operate cloud platforms securely. All data should be encrypted using an appropriate method, both at rest (“Data at Rest”) and in transit (“Data in Transit”). At the same time, it is recommended to manage the encryption keys exclusively in-house (“Hold your own key”).
2. Access: Two fundamental aspects must be considered here. First, adhere to principles such as “need to know,” and second, provide for authentication that works across applications. The existing role and permission concept forms the basis for this. Uniform authentication and assignment to a role are handled via a central identity provider such as Keycloak. During deployment, each role is assigned the corresponding application-specific permissions, ensuring that actions are limited to the scope of that role.  
3. Support: Agreed-upon response times with customers, as well as the technical tools provided to support staff, also impact the cloud platform as a whole. From software and networks to the required bandwidth, everything must be coordinated to provide the necessary information efficiently and in accordance with the contract.
4. Fault tolerance: KRITIS-relevant systems may only be down for an agreed minimum period of time, and must ensure that as little data as possible is lost in the event of an emergency. This is described by the two metrics RTO (Recovery Time Objective) and RPO (Recovery Point Objective). In practice, failed platforms are restarted in a remote data centre (“georedundancy”). The challenge: Within the time specified by the RTO, the platform must be operational again with a valid data set specified by the RPO.

The last point, in particular, can be quite challenging because the data transfer and deployment of the replacement service architecture must be completed in the shortest possible time. As the complexity of the platform increases, so does the risk of coming back online too late or with an insufficient data set in the event of a disaster. That is why it is essential to develop an overall concept from the outset to properly build the service architecture.