The purpose of this document is to describe the architecture of NextLabs application. 

Out of Scope:

• NextLabs policy design and details will covered in a separate deliverable. 

• Information related to product documentation that can be found online will not be documented here. 

• NextLabs security and policy design. Please refer to NextLabs Policy Design document for details. 

Key Decisions and Requirement

1 NextLabs built-in KMS has limited features (e.g., Key Encryption Keys is currently not supported) and if it does not meet requirements, Voltage KMS might be used instead.

Application Architecture

Overview

Data Access Enforcer (DAE) from NextLabs will be deployed for SyWay. DAE provides fine-grained, attribute-based access control (ABAC) for data, ensuring that only authorized users or applications can access sensitive data based on real-time policies and contextual information. For SyWay, it enforces authorization decisions to grant access and decrypt sensitive data.

NextLabs Dynamic Authorization Management (DAM) extends native role-based authorization and enforces finer-grained, attribute-based controls to critical SAP applications. However, DAM can only be implemented on the SAPGUI UI level to mask data and since SyWay will be using Fiori, DAM does not fit and will not be implemented. 

The following diagram describes the different NexLabs components.

Application Components

NextLabs Components

• Policy Controller: Key component of NextLabs that evaluate data access request against the policies and makes the decisions to deny or allow access to sensitive data.
• ICENET Servers: Distributes policy definitions from Management Server to Policy Controller and also clears the logs from the policy controllers by moving them to NextLabs's DB (MS SQL).
• Management Server: Administrative component that is used to manage NextLabs instances and policies. It is also used configure policies. 
• Bulk Obfuscation Tool (BOT): Allows users to select which data to encrypt. In addition to encrypting data, it also creates encryption keys, stores them in NextLabs DB and writes the key ID in into a /NXL/ table in HANA DB.
• MS SQL: Database for NextLabs. It stores configuration, policies, logs and encryption keys used for Format-Preserving Encryption (FPE). For NextLabs Azure SQL DB (DaaS) will be leveraged. 
• DAE for SAP : NextLabs binaries that run on SAP application. At run-time, DAE for SAP will intercept data request for sensitive request and send it to Policy controller to evaluate if access should be granted.
• NextLabs add-on: Installs NextLabs programs and tables in S/4HANA application. 
• Azure Files: Network files systems are required between DAE for SAP & Policy Controller and ICENET servers & Management Servers.

Integrating Systems

• Access Flag: Houses information on user access to the corresponding controlled document, taking into account the constraints from the various Export control regulations: ITAR, EAR, European Dual Use, German military. 
• SuccessFactors: Syensqo HR system that serves as a source of truth for employee data.
• EntraID: Integrated with NexLabs for SAML SSO and provides the user's location at the point of SSO for access evaluation. 

NextLabs Data and Security Flow

NextLabs Initial Configurations 

The following steps will be carried out to prepare S/4HANA 

1. NextLabs add-on will be installed in S/4HANA. This will import NextLabs programs and tables in /NXL/ namespace.
2. A share file system will be mounted across S/4HANA application VMs and Policy Server VMs. This NFS will contain binaries for DAE for SAP and used to store log files from DAE.
   • Path for DAE installation - /usr/NextLabs/DAE
   • Path for DAE working and log directory - /usr/sap/<SID>/DAE
3. DAE bootstrap command is to be executed on S/4HANA application server which will load NextLabs configurations into S/4HANA Kernel. This step is to be repeated when S/4HANA kernel is updated.
4. BOT component will required ODBC connection to S/4HANA.

Encryption

1. User selects which data to encrypt in BOT Web UI.
2. BOT creates an encryption key for the selected data, encrypts the data and writes the key ID in into a /NXL/ table in HANA DB.
3. BOT stores the encryption key and key ID in MS SQL DB.

Accessing Sensitive Data 

Reading Sensitive Data

1. Sensitive data access is requested using any access method (SAPGUI, Fiori, interfaces etc.).
2. DAE intercepts the DB call and send the request to the Policy controller. 
3. Policy controller evaluates if access should be granted based on the policies defined in NextLabs.
4. If access is granted, DAE for SAP will retrieve the encryption key ID from /NXL/ table and query Management server for the encryption key.
5. Management server retrieves the key from MS SQL DB and sends it to DAE.
6. DAE reads the encrypted data from HANA DB, decrypts the data and returns the decrypted data to SAP application. 

 Writing Sensitive Data

1. User or interface tries to update S/4HANA Data from web or SAPGUI.
2. DAE for SAP intercepts the DB write command and sends it to Policy Controller. 
3. Policy Controller evaluates if the write command contains sensitive data and the users has access to the corresponding data. 
4. If yes, DAE for SAP will retrieve the encryption key ID from /NXL/ table and query Management server for the encryption key.
5. Management server retrieves the key from MS SQL DB and sends it to DAE.
6. DAE for SAP uses the encryption key to replace the sensitive data in the write command with its corresponding encryption value and send the write command to HANA DB. 

System Landscape

NextLabs landscape will consist of a 4-tier landscape.

*QAS instance will be integrated to INT and UAT landscapes.  

Hosting Details

NextLabs system will be hosted in both EU and US region. Since NextLabs requires low latency network connection to S/4HANA, NextLabs will be hosted in the same Azure region and physical zone as SAP RISE.

In EU and US, NextLabs will be deployed to the following Subscriptions and vNETs. In both regions, NextLabs vNETs will be attached to region's Syensqo's Hub. To optimize latency between S/4HANA and NextLabs, NextLabs will be deployed in the same zone as SAP RISE.

For more details on NextLabs infrastructure please refer to Network and Infrastructure Architecture .

URL Naming Convention

NextLabs Policy Controller, ICNET and Management server components require an FQDN to be defined. The following URL naming convention will be adopted. 

Component URL: NXL-<environment>-<component><##>.syensqo.com

Load balancer URL: NXL-<environment>-<component>.syensqo.com

URLs 

Database

Azure SQL Server (DaaS) service will be used as NextLabs database. The table below summaries the DB details

Development 

Development NextLabs instance will follow combined deployment where multiple components are deployed together.

QAS

QAS NextLabs instance will follow a distributed deployment with no high-availability (HA).

Production and Parallel Run

Parallel run instance will follow a high-availability architecture. 

• Multiple instances of Policy controller and ICENET servers will be deployed in an active-active configuration. 
• Management server will be deployed in an active-passive configuration using RHEL Pacemaker.
• Azure built-in high-availability will be leveraged for SQL DB and Azure Files. 
• Since BOT is not runtime critical, it will be deployed without HA. 

Application Security

User Access

NextLabs will be accessed by NextLabs administrators from Syensqo network via HTTPS. Default security roles will be used.

Authentication

NextLabs is configured to perform SAML SSO with Syensqo Entra ID. 

Communication Security

Data in transit is encrypted using secure TLS protocols (v.1.2 or greater) with 2048-bit keys. 

Data Security

The following controls are implemented to ensure data security:

• Encryption is enable to protect data at rest
  • Transparent Data Encryption (TDE) will be enabled for Azure SQL Database.
  • As part of Syensqo's standard disk encryption is enabled by default. 
  • All backup are encrypted.
  • As part of Syensqo's Azure standards, encryption keys must be customer managed and is stored in the respective KMS provisioned for each environment. 
• Data protection.
  • All backups are storage in immutable storage.
  • Non-PRD backups are stored in zone redundant storage.
  • Production backups are stored in Geo-redundant storage and are replicated to another region.

Other Controls

• The target availability SLA for NexLabs is 99.95% (similar to S/4HANA).
• CrowdStrike endpoints installed on VMs.

Operation Architecture

Change and Configuration Management

NextLabs policies will be transported using NextLabs Policy Migration tool. This tool will be configured to transport to DEV → QAS → PAR → PRD.

Monitoring

The following monitoring will be enabled for NextLabs.

Sizing & Capacity Management

TBC

High Availability & Disaster Recovery

NextLabs HA/DR approach is similar to S/4HANA - Short distance disaster recovery. With this approach, Redundant NextLabs components will be deployed across 2 zones.

The following table lists down the HA/DR approach for each component. 

For more details please refer to DD-TEC-140 HA/DR Architecture Design.

Backup

The following backups are configured for NextLabs.

For more details please refer to DD-TEC-160 Back up and Restore Design.

Backup Storage Locations

TBC

Maintenance Plan

Syensqo's maintenance and patching schedule will be adopted for NextLabs systems.

For parallel run and production instance, the HA configuration will be leverage to perform the activities without downtime. 

See also

• LeanIX Factsheet - NextLabs-DAE

Change log