Unteranlage 4-1 Anlage zur Systemumgebung_rlp-Cloud.pdf

[Seite 1]

Vorgaben zur Softwareeinbringung in

die rlp-Cloud 2.0

OpenShift Containerplattform

Version 1.4 vom 12.03.2026

Cloud-Competence-Center (Cloud-Competence-Center@ldi.rlp.de)

Landesbetrieb Daten und Information Valenciaplatz 6

55118 Mainz

[Seite 2]

rlp-Cloud 2.0 - Containerplattform

Inhaltsverzeichnis

1 Einleitung ...................................................................................................................... 4 1.1 Begriffe.................................................................................................................... 4 1.2 Schlüsselworte ........................................................................................................ 4 2 Architekturvorgaben .................................................................................................... 5 2.1 OpenShift Plattform ................................................................................................. 5 2.2 Zugänge / Administration ........................................................................................ 5 2.3 Kommunikation intern / extern ................................................................................. 6 2.4 Ingress .................................................................................................................... 6 2.5 Egress ..................................................................................................................... 6 2.6 TLS-Versionen und unterstützte Cipher Suites ........................................................ 7 2.7 Monitoring, Logging und Telemetrie ........................................................................ 7 2.8 Datenschutz und Compliance .................................................................................. 7 2.9 Lizenzierung ............................................................................................................ 7 2.10 Quotas und Limits ................................................................................................... 7 2.11 Anwendungs-Deployments ...................................................................................... 8 2.12 Storage ................................................................................................................... 8 2.12.1 Ephemeral Storage .......................................................................................... 8 2.12.2 Persistent Storage ............................................................................................ 8 2.12.3 Block Storage (PV – Persistent Volume) .......................................................... 8 2.12.4 Object Storage (S3) ......................................................................................... 8 3 Konventionen und Standards ...................................................................................... 9 3.1 Namespace as a Service ........................................................................................ 9 3.2 Namespace Namenskonvention .............................................................................. 9 4 Sichere Container-Images ........................................................................................... 9 4.1 Freigegebene Base-Image Repositories ................................................................. 9 4.2 Auslaufende Base-Image Repository Freigaben ....................................................10 4.3 Erlaubte Base-Images ............................................................................................10 4.4 Empfohlene Base-Images ......................................................................................11 4.5 Erlaubte Paket Repositories ...................................................................................11 4.6 Minimale und gehärtete Basis-Images ...................................................................11 4.7 Regelmäßige Schwachstellenanalyse und -behebung ...........................................12 4.8 Secure Supply Chains (Lieferketten) ......................................................................13 4.9 Software Bill of Materials (SBOM) ..........................................................................13 4.10 Keine schützenswerten Informationen in den Images.............................................13 4.11 Verwendung von Multi-Stage-Builds .......................................................................13 4.11.1 OpenShift Kompatibilität ..................................................................................13 4.11.2 Dockerfile Beispiel ...........................................................................................14 4.12 Signierung und Verifizierung von Images ...............................................................14 4.13 Image Anlieferung ..................................................................................................15 4.13.1 Prozessbild Image Anlieferung ........................................................................16 4.14 Prozess des Anwendungs-Deployment ..................................................................17 4.14.2 Helm-Charts ....................................................................................................17 4.14.3 Prozessbild Tekton Pipeline Deployment ........................................................19 4.15 Regelmäßige Aktualisierung der Basis-Images ......................................................19 4.16 Härtung von Container Images ...............................................................................19 4.17 Image Versionierung ..............................................................................................19 4.18 Code Anlieferung ...................................................................................................19 4.19 Verantwortlichkeiten ...............................................................................................20

Vorgaben für Kunden und Lieferanten Seite 2 von 25 1.4 vom 12.03.2025 Landesbetrieb Daten und Information

[Seite 3]

rlp-Cloud 2.0 - Containerplattform

5 Softwareentwicklung und Anwendungskonfiguration .............................................20 5.1 Grundlegende Anwendungsanforderungen ............................................................20 5.2 Microservice Architektur .........................................................................................20 5.3 Prinzip der geringsten Rechte (Least Privilege) für Anwendungen .........................20 5.4 Sichere Programmierpraktiken ...............................................................................20 5.5 Verwaltung von Anwendungsabhängigkeiten .........................................................21 5.6 Input-Validierung und Output-Encoding ..................................................................21 5.7 Sichere Handhabung von Geheimnissen zur Laufzeit ............................................21 5.8 Empfehlung für „stateless“ Anwendungen ..............................................................21 5.9 Health Checks ........................................................................................................21 5.10 Sichere Konfiguration und Vermeidung von Standardeinstellungen .......................21 5.11 DNS-Nutzung .........................................................................................................21 5.12 Zeitsynchronisation ................................................................................................21 5.13 E-Mail .....................................................................................................................22 5.14 Zertifikate ...............................................................................................................22 5.15 Abweichungen ........................................................................................................22 5.16 Testumgebungen ...................................................................................................22 5.17 Standard Operatoren und Software ........................................................................22 6 Sichere Laufzeitkonfiguration und Orchestrierung ..................................................23 6.1 Netzwerksicherheit und Segmentierung .................................................................23 6.2 Ressourcenbeschränkungen und Quality of Service (QoS) ....................................23 6.3 Read-only Root-Dateisystem ..................................................................................23 6.4 Immutable Infrastructure ........................................................................................23 6.5 ConfigMaps ............................................................................................................23 6.6 Secrets ...................................................................................................................23 7 Logging, Monitoring und Auditing .............................................................................24 7.1 Vorgaben Logging ..................................................................................................24 7.2 Monitoring ..............................................................................................................24 7.3 Regelmäßige Audits ...............................................................................................25 7.4 Alarmierung ............................................................................................................25 8 Schutz sensibler Daten ...............................................................................................25 8.1 Datenverschlüsselung (im Ruhezustand und während der Übertragung) ...............25 8.2 Datenminimierung ..................................................................................................25

Vorgaben für Kunden und Lieferanten Seite 3 von 25 1.4 vom 12.03.2025 Landesbetrieb Daten und Information

[Seite 4]

rlp-Cloud 2.0 - Containerplattform

1 Einleitung

Für den sicheren Betrieb von Software auf der rlp-Cloud 2.0 Containerplattform auf Basis Red Hat OpenShift sind umfassende Anforderungen an die Plattform selbst und die darauf betriebenen Verfahren, deren Entwicklungsprozess und die Konfiguration der Laufzeitumgebung unerlässlich. Dieses Dokument definiert verbindliche Vorgaben, Best Practices und Empfehlungen für die Bereitstellung, Entwicklung und das Deployment von Container-Anwendungen im OpenShift-Cluster. Es richtet sich an Entwickler bzw. Lieferanten und beauftragende Kunden. Die Schwerpunkte liegen auf der sicheren Auswahl und Nutzung von Base-Images, der Einhaltung von Sicherheits- und Architekturvorgaben für Anwendungen sowie auf standardisierten und automatisierten Deployment-Prozessen. Ziel ist es, die Sicherheit, Wartbarkeit und Nachvollziehbarkeit aller bereitgestellten Container-Images und Anwendungen zu gewährleisten.

Das Dokument repräsentiert den Stand der Technik und wird fortlaufend überprüft und aktualisiert. Durch die Aktualisierung des Dokuments können Änderungen an den Vorgaben erfolgen.

1.1 Begriffe Folgende Begriffe werden in diesem Dokument verwendet:

• Plattform: Damit ist die rlp-Cloud 2.0 Containerplattform auf Basis Red Hat OpenShift inkl. des „Ökosystems“ von zugehörigen Anlieferungs- und Umsystemen gemeint. • Anwendung (auch „Verfahren“, „Fachverfahren“ oder „Applikation“ genannt): damit ist die für Kunden des LDI auf der Plattform betriebene Software gemeint. • CPi („Containerplattform innen“): meint die rlp-Cloud 2.0 Containerplattform, die nur über das rlp-Netz erreichbar ist und für Anwendungen der Innenverwaltung des Landes Rheinland-Pfalz gedacht ist. • CPa („Containerplattform außen“): meint die rlp-Cloud 2.0 Containerplattform, die im Internet erreichbar ist und die für Anwendungen gedacht ist, die durch Bürgerinnen, Bürger und externe Organisationen genutzt werden können. • Kunde: Ist eine Landesverwaltung in Rheinland-Pfalz. Die Organisation kann mehrere Lieferanten für mehrere Verfahren beauftragen und damit über viele Namespaces (siehe Kapitel 3) verfügen. • Kunden-Proxies: kundenspezifische Proxy Server sind Reverse Proxy Server, die einer Organisation zugeordnet sind und die Netzwerkkommunikation der Organisation mit der Containerplattform steuern.

1.2 Schlüsselworte In den Anforderungen werden die in Versalien geschriebenen Modalverben „SOLLTE“ und „MUSS“ in ihren jeweiligen Formen sowie den zugehörigen Verneinungen genutzt, um zu verdeutlichen, wie die jeweiligen Anforderungen zu interpretieren sind. Die hier genutzte Definition basiert auf dem BSI IT-Grundschutz (BSI IT-Grundschutz, 2023) und RFC 2119.

Vorgaben für Kunden und Lieferanten Seite 4 von 25 1.4 vom 12.03.2025 Landesbetrieb Daten und Information

[Seite 5]

rlp-Cloud 2.0 - Containerplattform

MUSS / Dieser Ausdruck bedeutet, dass es sich um eine Anforderung handelt, die DARF NUR: unbedingt erfüllt werden muss (uneingeschränkte Anforderung, für die keine Risikoübernahme möglich ist). DARF NICHT / Dieser Ausdruck bedeutet, dass etwas in keinem Fall getan werden darf DARF KEIN: (uneingeschränktes Verbot). SOLLTE: Dieser Ausdruck bedeutet, dass eine Anforderung normalerweise erfüllt werden muss, es aber Gründe geben kann, dies doch nicht zu tun. Dies muss aber sorgfältig abgewogen und stichhaltig begründet werden. SOLLTE NICHT / Dieser Ausdruck bedeutet, dass etwas normalerweise nicht getan werden SOLLTE KEIN: sollte, es aber Gründe gibt, dies doch zu tun. Dies muss aber sorgfältig abgewogen und stichhaltig begründet werden. KANN: Dieser Ausdruck bedeutet, dass eine bestimmte Umsetzung gewählt werden kann. Diese muss allerdings angezeigt werden.

2 Architekturvorgaben

In diesem Abschnitt werden grundsätzliche Architekturvorgaben definiert.

2.1 OpenShift Plattform Die rlp-Cloud 2.0 basiert auf Red Hat OpenShift. Der LDI betreibt eine vom Hersteller unterstützte Version und führt im Rahmen seines Change-Managements regelmäßige Aktualisierungen (major/minor/patch) durch.

Sogenannte „major updates“, bei denen auch Anpassungen durch „breaking changes“ zu erwarten sind, werden vom LDI über den entsprechenden ITSM-Serviceprozess angekündigt. Der LDI informiert mit einem Vorlauf von 3 Monaten über einen Versionssprung upgrade.

Aktuell betreibt der LDI Red Hat OpenShift 4.18.x.

Folgende Vorgaben sind einzuhalten:

• Die Anwendung MUSS immer kompatibel zu der aktuell im LDI betriebenen OpenShift Version sein. • Die Anwendung MUSS alle in diesem Dokument veröffentlichten Richtlinien umsetzen.

2.2 Zugänge / Administration

• Das Onboarding auf die Plattform wird durch den LDI unterstützt. • Zugang zur Administration, egal ob lesend oder schreibend, erfolgt ausschließlich über das RLP-Landes-AD. Externe Zugriffe sind nicht möglich. • Die Berechtigung der Nutzer zu den jeweiligen Rollen erfolgt durch den LDI. Dazu muss der Kunde entsprechende Personen benennen. • Die Startadressen für die OpenShift-Console und die durch den LDI bereitgestellten Tools wie Argo CD, Git und Harbor Registries werden im Rahmen des Onboardings bekanntgegeben.

Vorgaben für Kunden und Lieferanten Seite 5 von 25 1.4 vom 12.03.2025 Landesbetrieb Daten und Information

[Seite 6]

rlp-Cloud 2.0 - Containerplattform

2.3 Kommunikation intern / extern

• Die direkte Kommunikation zwischen Namespaces wird nicht unterstützt. Namespaces kommunizieren über eine vorgelagerte Firewall oder P-A-P Infrastruktur des LDI. • Data-in-Transit MUSS gemäß der BSI Technischen Richtlinien TR-02102-2 verschlüsselt sein. Die unterstützten Cipher Suites sind im Kapitel 2.6 beschrieben.

2.4 Ingress

• Eingehende Kommunikation („ingress“ Netzwerk) MUSS über die vorgegebenen und vom LDI betriebenen Kunden-Proxies erfolgen. • Eingehende Kommunikation erfolgt ausschließlich über HTTPS Port 443/TCP. • Das QUIC-Protokoll (UDP) wird nicht unterstützt. • Eingehende Verbindungen sind bei der CPi nur aus dem Landesnetz zulässig. • Anwendungen auf der CPa können aus dem Internet erreicht werden. Das Deployment der Anwendung oder andere administrative Tätigkeiten sind NICHT über das Internet durchführbar. • Die Zertifikatsmechanismen werden im Rahmen des Onboardings erläutert. • Jeder Namespace hat einen IngressController.

Beispiel:

apiVersion: route.openshift.io/v1 kind: Route metadata: name: hello-openshift spec: host: www.example.com port: targetPort: 8080 to: kind: Service name: hello-openshift

2.5 Egress

• Externe Kommunikation („egress“ Netzwerk) ausgehend von der Containerplattform MUSS über eine vorgelagerte Firewall oder P-A-P Infrastruktur des LDI erfolgen. • Eine Kommunikation – ausgehend von einem Namespace innerhalb der CPi in ein Netz mit niedrigerem Schutzbedarf (z. B. Internet) – ist unter Einhaltung der BSI-Vorgaben zur Kommunikation möglich. Die Kommunikation erfolgt über eine Sicherheitsinfra- struktur und muss explizit IP-basiert freigegeben werden. Die Erläuterung erfolgt im Onboarding Prozess. • Einem Namespace wird für ausgehende Kommunikation („egress“) eine feste IPv4- Adresse aus einem definierten LDI-Netz zugewiesen. Falls mehrere Adressen benötigt werden, erfolgt dies in Absprache mit dem LDI. • Es SOLLTE immer mit sicheren Protokollen kommuniziert werden, dies betrifft den gesamten eingehenden und ausgehenden Datenverkehr im Namespace (vgl. BSI Grundschutzkompendium 2023 OPS.1.1.1.A13).

Vorgaben für Kunden und Lieferanten Seite 6 von 25 1.4 vom 12.03.2025 Landesbetrieb Daten und Information

[Seite 7]

rlp-Cloud 2.0 - Containerplattform

• Alle Kommunikationsbeziehungen der Anwendung MÜSSEN durch den Kunden oder Lieferanten dokumentiert seien. Zudem MUSS diese Dokumentation jederzeit vollständig und aktuell sein.

2.6 TLS-Versionen und unterstützte Cipher Suites Für den Ingress-Controller wird im Standard mindestens TLS 1.2 mit folgenden Cipher Suites unterstützt.

• ECDHE-ECDSA-AES128-GCM-SHA256
• ECDHE-RSA-AES128-GCM-SHA256
• ECDHE-ECDSA-CHACHA20-POLY1305
• ECDHE-RSA-AES256-GCM-SHA384
• ECDHE-RSA-CHACHA20-POLY1305
• ECDHE-ECDSA-AES256-GCM-SHA384
• TLS_AES_128_GCM_SHA256
• TLS_AES_256_GCM_SHA384
• TLS_CHACHA20_POLY1305_SHA256

2.7 Monitoring, Logging und Telemetrie

• Die Plattform verfügt über einen Observability-Stack (vgl. Kapitel 7). • Health Checks (Liveness Probes, Readiness Probes und Startup Probes) MÜSSEN implementiert werden.

2.8 Datenschutz und Compliance

• Anwendungskonfigurationen und Richtlinien MÜSSEN sicher gestaltet werden. Diese SOLLTEN regelmäßig überprüft werden. • Verfahren DÜRFEN NICHT auf einer Betriebsplattform betrieben werden, wenn der Schutzbedarf des Verfahrens höher ist als der Schutzbedarf den die Plattform bieten kann. Der Schutzbedarf für die CPi ist als „hoch“ definiert, der Schutzbedarf der CPa ist als „normal“ definiert. • Ruhende Daten (Data-at-Rest) SOLLTEN verschlüsselt werden.

2.9 Lizenzierung

• Für Anwendungen, die eine Lizenzierung benötigen, MUSS der Auftraggeber sicherstellen, dass die notwendigen Lizenzen bereitgestellt und überwacht werden. Die Lizenzpflege obliegt dem Kunden, dabei besteht eine Mitwirkungspflicht des Kunden bei Lizenzaudits. Der LDI haftet nicht für Lizenzverstöße durch Dritte.

2.10 Quotas und Limits

• Jeder Namespace MUSS definierte Ressourcenlimits und Quotas aufweisen. Folgende Limits können je Namespace gesetzt werden: o CPU / RAM (Arbeitsspeicher) ▪ Das Verhältnis zwischen CPU und RAM in GB ist auf 1:8 festgelegt. CPU RAM ▪ Minimum: 0.1 0.8 GB ▪ Standard 1 8 GB

Vorgaben für Kunden und Lieferanten Seite 7 von 25 1.4 vom 12.03.2025 Landesbetrieb Daten und Information

[Seite 8]

rlp-Cloud 2.0 - Containerplattform

▪ Maximum: 32 256 GB o Blockspeicher (PV) ▪ Standard: 50 GB ▪ Maximum: 10 TB o Objektspeicher (S3) ▪ Standard: Es gibt keine Standardreservierung. ▪ Maximum: 10 TB

2.11 Anwendungs-Deployments

• Anwendungs-Deployments liegen im Verantwortungsbereich des Kunden und MÜSSEN automatisiert über Argo CD oder Tekton Pipelines erfolgen. • Die Funktionstauglichkeit eines Deployments MUSS vor der Produktivsetzung verifiziert werden. • Anwendungen SOLLTEN in einem eigenen Namespace bereitgestellt werden (vgl. BSI Grundschutzkompendium 2023 APP.4.4.A1). Dabei stellt eine Anwendung eine logisch zusammenhängende Einheit aus einem oder mehreren Services dar, die gemeinsam eine fachliche Funktion erfüllen.

2.12 Storage Es wird zwischen zwei verschiedenen Storage-Typen unterschieden, dem „Ephemeral Storage“ (flüchtiger Speicher) und dem „Persistent Storage“ (dauerhafter Speicher).

2.12.1 Ephemeral Storage • Es DÜRFEN KEINE kritischen Daten außerhalb des eigentlichen Verarbeitungsvorgangs gespeichert werden. Dazu gehören insbesondere personenbezogene oder geschäftliche Daten, aber auch Protokolldateien. • Es MUSS beachtet werden, dass der flüchtige Speicher nur während der Laufzeit existiert und zwischen den Containern in einem Pod geteilt wird. • Je Namespace stehen maximal 10 GB Ephemeral Storage zur Verfügung.

2.12.2 Persistent Storage • Statische Inhalte MÜSSEN im Persistent Volume Claim (PVC) vorgehalten werden. • Es kann Block Speicher und Objektspeicher (S3) genutzt werden.

2.12.3 Block Storage (PV – Persistent Volume) • Der PV wird auf einem Hochleistungsspeicher bereitgestellt. • Die Storage Class ist definiert als: o Name: hypermetro-fs o PVC ReclaimPolicy: Delete o RWO o Snapshots: unterstützt o Backendprotokoll: NFS 4.1 o Dynamische Speicherverteilung: unterstützt o Backup: in Vorbereitung

2.12.4 Object Storage (S3) • Object Storage MUSS projektspezifisch über den LDI beantragt werden.

Vorgaben für Kunden und Lieferanten Seite 8 von 25 1.4 vom 12.03.2025 Landesbetrieb Daten und Information

[Seite 9]

rlp-Cloud 2.0 - Containerplattform

3 Konventionen und Standards

3.1 Namespace as a Service Das Betriebsmodell ist „Namespace as a Service“. Kunden/Mandanten haben volle Kontrolle über den eigenen Namespace. Anlegen, ändern und löschen von Namespaces, sowie administrative Aufgaben, die über den Namespace hinausgehen, werden durch den LDI durchgeführt.

3.2 Namespace Namenskonvention Alle Namespaces MÜSSEN dieser Namenskonvention folgen. Die Einhaltung der Namenskonvention wird vom LDI bei der Einrichtung der Namespaces gewährleistet. Es sind maximal 63-Zeichen erlaubt (alphanumerisch und Bindestrich), Großbuchstaben DÜRFEN NICHT verwendet werden.

--- Dabei ist • verfahren = Fachverfahren • kunde = Organisation (Code der Landesbehörde) • stagekurzform = Stage (z. B. “d”=Development, “t”=TEST, “r”=Referenz, “I”=Integration, “s”=Schulung, “p”=PROD) • id = Eineindeutiger Identifier (Zahlencode) wird vom LDI bereitgestellt.

4 Sichere Container-Images

4.1 Freigegebene Base-Image Repositories Die Definition der sicheren Image Repositories soll die Qualität, Sicherheit und Wartbarkeit sicherstellen. Die angegeben Repositories können Links enthalten, die auf Content Delivery Networks (CDNs) oder alternative Hostnamen verweisen.

Tabelle 1: Freigegebene Base-Image Repositories

Vorgaben für Kunden und Lieferanten Seite 9 von 25 1.4 vom 12.03.2025 Landesbetrieb Daten und Information

[Seite 10]

rlp-Cloud 2.0 - Containerplattform

4.2 Auslaufende Base-Image Repository Freigaben Die folgenden Freigaben werden in der nächsten Version dieses Dokuments (1.5) zurück- gezogen:

Tabelle 2: Auslaufende Base-Image Repository Freigaben

4.3 Erlaubte Base-Images Die Freigaben beziehen sich auf die Hauptversionen der Software bzw. Betriebssysteme. Beispiel Alpine Linux 3.22 inkludiert somit auch eine Freigabe der nächsten Unterversion z. B. 3.23. Die Freigabe erlischt, wenn der „End-of-Life“ des jeweiligen Produktes erreicht ist oder die Unterstützung in einer neuen Version dieses Dokuments zurückgezogen wurde.

• Die Base-Images MÜSSEN die Architektur AMD64 (x86_64) unterstützen. • Die Versionen der Base-Images MÜSSEN im Support-Zeitraum liegen. • Es MÜSSEN offiziell bereitgestellte und vertrauenswürdige Basis-Images von geprüften Quellen verwendet werden. In der folgenden Tabelle nicht aufgeführte Quellen bedürfen einer schriftlichen Genehmigung durch den LDI. • Die Lizenzbedingungen der Images MÜSSEN durch den Lieferanten überprüft werden. • Die Repository Links weichen ggf. von den Image Links ab.

Tabelle 3: Erlaubte Base-Images

Vorgaben für Kunden und Lieferanten Seite 10 von 25 1.4 vom 12.03.2025 Landesbetrieb Daten und Information

[Seite 11]

rlp-Cloud 2.0 - Containerplattform

4.4 Empfohlene Base-Images Die empfohlenen Base-Images wurden mit Blick auf die Balance zwischen Markt- gegebenheiten, Pflege und Sicherheit sorgfältig gewählt. Es wird empfohlen Images zu verwenden, die den „near zero CVE“-Ansatz verfolgen. Im Gegensatz zu der vorherigen Version dieses Dokuments haben sich die Empfehlungen geändert.

Tabelle 4: Empfohlene Base-Images

4.5 Erlaubte Paket Repositories Es DÜRFEN beliebige Anwendungspakete in den Images deployed werden. Dabei MÜSSEN die Vorgaben aus diesem Dokument eingehalten werden (u. A. CVE, Support). Anwendungs- pakete DÜRFEN NICHT Schadcode oder anderen nicht vertrauenswürdigen Code enthalten.

4.6 Minimale und gehärtete Basis-Images

• Im Allgemeinen SOLLTEN die kleinstmöglichen (minimalen) Basis-Images, die nur die absolut notwendigen Betriebssystemkomponenten, Bibliotheken und Laufzeit- umgebungen für die Anwendung enthalten (z. B. "distroless" Images, schlanke Alpine Linux-Varianten) genutzt werden. • Es SOLLTEN verschiedene Varianten für Build (Dev-Images) und für die spätere Runtime verwendet werden (vgl. Kapitel 4.11). • Es SOLLTEN nur Softwarepakete, Werkzeuge, etc. installiert werden, die zwingend für den Einsatzzweck benötigt werden, um potentielle Angriffsflächen zu reduzieren. • Es SOLLTE darauf geachtet werden Images mit möglichst wenigen Layern zu verwenden.

Vorgaben für Kunden und Lieferanten Seite 11 von 25 1.4 vom 12.03.2025 Landesbetrieb Daten und Information

[Seite 12]

rlp-Cloud 2.0 - Containerplattform

4.7 Regelmäßige Schwachstellenanalyse und -behebung

• Bereits beim Prozess der Erstellung SOLLTE auf Best Practices zur Sicherheit geachtet werden. Es wird empfohlen in der CI/CD Pipeline mehrstufige Quality Gates zu implementieren. • Im Image-Staging-Prozess des LDI werden alle extern angelieferten Images auf Schwachstellen und Secrets durch Trivy geprüft. Erst nach einer erfolgreichen Prüfung werden die Images von der externen in eine innere Registry verschoben, aus der dann ein Deployment auf die Plattform möglich ist.

• Es MUSS beachtet werden, dass die Images nicht nur zum Zeitpunkt der Anlieferung, sondern auch im laufenden Betrieb durch ACS (Advanced Cluster Security) untersucht werden. Ein zuvor unauffälliges Image kann so bei neu veröffentlichten CVEs kritisch werden und eine Suspendierung der des Containers erfordern (vgl. Tabelle 5: CVE- Redemiation). Die Überprüfung der Images garantiert keine Schwachstellenfreiheit. • ES MÜSSEN alle verwendeten Bibliotheken und Frameworks aktuell gehalten werden. Patches für bekannte Schwachstellen sind innerhalb der u.g. Zeiten einzupflegen. Die Vorgaben sind angelehnt an den Vorgaben des C5-Kriterienkatalogs (OPS-22). Die Definitionen sind der nachfolgenden Tabelle zu entnehmen.

Tabelle 5: CVE-Redemiation

• Der Startzeitpunkt für die Behebungszeit beginnt sobald ein Patch oder eine Mitigation zur Verfügung steht. • Die Images werden kontinuierlich gescannt, sodass auch während der Laufzeit Alarme generiert und versendet werden. Sollten die Softwareschwachstellen nicht innerhalb des angegebenen Zeitraums behoben werden, behält der LDI sich vor die betroffenen Container zu suspendieren. • Der Softwareentwickler SOLLTE bereits lieferantenseitig automatisierte Tools zur Schwachstellenerkennung (Image-Scanner) in den dortigen CI/CD-Prozess integrieren, um eine Anlieferung von Anwendungen zu vermeiden, die auf der LDI- Plattform dann auffällig werden und ggf. abgelehnt werden.

Vorgaben für Kunden und Lieferanten Seite 12 von 25 1.4 vom 12.03.2025 Landesbetrieb Daten und Information

[Seite 13]

rlp-Cloud 2.0 - Containerplattform

• Ein Prozess für das Patchen von Schwachstellen durch Neuerstellung und erneute Anlieferung der Images MUSS durch den Lieferanten entsprechend der oben angegebenen Behebungszeit implementiert werden. Der Kunde ist für die Einhaltung gegenüber dem LDI verantwortlich.

4.8 Secure Supply Chains (Lieferketten) Die Nachweisbarkeit der Lieferketten gewinnt immer weiter an Bedeutung. Um diesen Umstand zu begegnen wurden Technologien und Methoden entwickelt um die Lieferketten von Software nachvollziehbar und auditierbar zu gestalten. Empfohlen wird:

• Code Commit signing (SSH-Key oder GPG) • Signierung von Images • Signierung von SBOM

4.9 Software Bill of Materials (SBOM)

• Für den sicheren Betrieb MUSS eine Software-Stückliste (SBOM) für jedes Container- Image automatisch erzeugt werden und diese MUSS den Anforderungen der TR- 03183-2 entsprechen. Die SBOM listet alle Softwarekomponenten inkl. verwendeter Version und zugrundliegender Lizenz auf, erleichtert das Schwachstellen- management und sichert die Lizenzkonformität. • Es wird empfohlen die SBOM zu signieren (z. B. mit Cosign).

4.10 Keine schützenswerten Informationen in den Images

• Es MUSS durch den Softwarelieferanten sichergestellt werden, dass das Speichern von sensitiven Daten, z. B.: o Passwörter, o API-Schlüssel, o Zertifikate oder o Konfigurationsgeheimnisse direkt im Container-Image unterbunden ist.

4.11 Verwendung von Multi-Stage-Builds

• Wenn möglich SOLLTEN Multi-Stage-Builds genutzt werden, um Build-Tools, temporäre Dateien und Entwicklungscode aus dem finalen Produktions-Image auszuschließen. Dieses reduziert die Image-Größe und die potenzielle Angriffsfläche. • Die Minimierung des Footprints vereinfacht den Security-Scan Prozess, indem False- Positive Meldungen reduziert werden. • Es wird empfohlen Build- und Runtime-Stage zu trennen.

4.11.1 OpenShift Kompatibilität Um die Kompatibilität mit OpenShift sicherzustellen, MÜSSEN Container Arbitrary User IDs unterstützen. OpenShift vergibt zufällige User IDs aus einem vordefinierten Bereich. Diese User sind immer Mitglied der Root-Gruppe (GID 0).

Vorgaben für Kunden und Lieferanten Seite 13 von 25 1.4 vom 12.03.2025 Landesbetrieb Daten und Information

[Seite 14]

rlp-Cloud 2.0 - Containerplattform

Daraus ergeben sich zwei Anforderungen:

• Die Anwendung DARF NICHT als ein bestimmter User zu laufen. • Alle benötigten Daten und Verzeichnisse MÜSSEN für die Gruppe 0 (root) lesbar, beschreibbar und ausführbar sein.

4.11.2 Dockerfile Beispiel

Build Stage (rootful)

FROM dhi.io/golang:1.26-alpine3.23-dev AS builder

WORKDIR /src

COPY go.mod go.sum ./ RUN go mod download

Kopieren des Applikationscodes

COPY . .

Statisch kompilieren (Für minimale Runtime)

RUN CGO_ENABLED=0 GOOS=linux GOARCH=amd64
go build -trimpath -ldflags="-s -w" -o /out/app ./cmd/server

Runtime Stage (non-root)

FROM dhi.io/golang:1.26-alpine3.23

Arbeitsverzeichnis anlegen

WORKDIR /app

Artifact aus Build-Stage kopieren

COPY --from=builder /out/app /app/app

Rechte für Gruppe 0 setzen (OpenShift Arbitrary User Id support)

RUN chgrp -R 0 /app && chmod -R g=u /app

Nicht-privilegierter User (wird von OpenShift überschrieben)

USER 65532:0

EXPOSE 8080 ENTRYPOINT ["/app/app"]

4.12 Signierung und Verifizierung von Images

• Container-Images SOLLTEN am Ende des Build-Prozesses signiert werden, um Integrität und Herkunft sicherzustellen (z. B. mit Cosign). Eine Abweichung MUSS dem LDI gegenüber begründet werden. Diese Anforderung wird in einer zukünftigen Dokumentenversion präzisiert.

Vorgaben für Kunden und Lieferanten Seite 14 von 25 1.4 vom 12.03.2025 Landesbetrieb Daten und Information

[Seite 15]

rlp-Cloud 2.0 - Containerplattform

4.13 Image Anlieferung Die Anlieferung von Images kann über zwei Wege erfolgen.

1. Pull von der Anlieferungsregistry („reg-ext“ im LDI) gegen die Registry des Lieferanten. Der Sync kann nicht durch Kunden oder Lieferanten konfiguriert werden. Images werden ausschließlich von der externen (siehe 4.10.1) Container-Registry (reg-ext Harbor) über einen abgesicherten und freigegebenen Kanal gepullt. Images werden nur von Registries gepullt die über eine feste IPv4 Adresse verfügen und vom LDI über eine Firewall-Whitelist freigegeben wurden. Änderungen an der Lieferanten-Registry sind dem LDI vorab mitzuteilen.

2. Manuelle Übertragung der Images mittels ROI und Docker/Podman Client.

Vorgaben für Kunden und Lieferanten Seite 15 von 25 1.4 vom 12.03.2025 Landesbetrieb Daten und Information

[Seite 16]

rlp-Cloud 2.0 - Containerplattform

4.13.1 Prozessbild Image Anlieferung

Abbildung 1 - Prozess Anlieferung Images

Vorgaben für Kunden und Lieferanten Seite 16 von 25 1.4 vom 12.03.2025 Landesbetrieb Daten und Information

[Seite 17]

rlp-Cloud 2.0 - Containerplattform

4.14 Prozess des Anwendungs-Deployment Es stehen zwei Wege für das Anwendungs-Deployment zur Verfügung. Zum einen das Deployment über Argo CD, zum anderen das Deployment über eine Tekton Pipeline. Beide Varianten sind an die jeweilige Plattform gebunden. Zugriffsrechte können Kapitel 5.17 entnommen werden.

4.14.1.1 Hinweis für das Deployment Achten Sie darauf, dass ein Deployment die korrekten Werte für „request“ und „limits“ beinhaltet um OOM-Kills („out of memory“) zu vermeiden.

[…] spec: containers:

• resources: limits: cpu: 1 memory: 2Gi requests: cpu: 250m memory: 512Mi […]

4.14.2 Helm-Charts Die Containerplattform unterstützt Helm-Charts für das Deployment von Anwendungen. Die Charts MÜSSEN im Repository des Projektes vorliegen. Durch die Charts referenzierte Images MÜSSEN in der internen Image Registry vorliegen. Images können nicht direkt von außerhalb bezogen werden.

Vorgaben für Kunden und Lieferanten Seite 17 von 25 1.4 vom 12.03.2025 Landesbetrieb Daten und Information

[Seite 18]

rlp-Cloud 2.0 - Containerplattform

Abbildung 2 - Argo CD Deployment

Vorgaben für Kunden und Lieferanten Seite 18 von 25 1.4 vom 12.03.2025 Landesbetrieb Daten und Information

[Seite 19]

rlp-Cloud 2.0 - Containerplattform

4.14.3 Prozessbild Tekton Pipeline Deployment

Abbildung 3 - Tekton Pipeline Deployment

4.15 Regelmäßige Aktualisierung der Basis-Images Entsprechend „4.7 Regelmäßige Schwachstellenanalyse und -behebung“ MÜSSEN die Container unabhängig von Änderungen in den Applikationen bei bekannt werden von Schwachstellen in den Betriebssystemkomponenten neu erzeugt werden.

4.16 Härtung von Container Images

• Es SOLLTEN Frameworks und Richtlinien zur Absicherung von Container Images genutzt werden (z. B. CIS-Benchmark).

4.17 Image Versionierung

• Images MÜSSEN identifizierbare Tags (Bezeichnungen z. B. "dev-1.0") aufweisen. • Container-Images MÜSSEN eindeutig versioniert und getaggt seien.

4.18 Code Anlieferung

• Source Code (z. B. Deployment-Skripte) MUSS aus dem rlp-Netz ins GIT der Plattform angeliefert werden.

Vorgaben für Kunden und Lieferanten Seite 19 von 25 1.4 vom 12.03.2025 Landesbetrieb Daten und Information

[Seite 20]

rlp-Cloud 2.0 - Containerplattform

4.19 Verantwortlichkeiten

• Es MÜSSEN Ansprechpersonen für die vom Lieferanten erstellten Images benannt werden, um bei Sicherheitsvorfällen adäquat reagieren zu können. • Es MUSS eine Dokumentation über Ansprechpartner vorliegen und regelmäßig auf Aktualität geprüft werden.

5 Softwareentwicklung und Anwendungskonfiguration

5.1 Grundlegende Anwendungsanforderungen

• Von den Anwendungen verwendeten Systembenutzer MÜSSEN UIDs >1000 verwenden. • Anwendungen, die Netzwerk-Sockets verwenden MÜSSEN Portnummern >1024 verwenden. • Es dürfen nur notwendige Netzwerk-Sockets geöffnet werden. • Anwendungen SOLLTEN unabhängig von spezifischen Hardwareanforderungen lauffähig seien, dies kann z. B. bei KI-Prozessen mit Nvidia Cuda notwendig sein. • Anwendungen SOLLTEN „stateless“ sein. • Anwendungen MÜSSEN so gestaltet seien, dass im Fehlerfall ein Transfer auf andere Workernodes ohne manuelle Eingriffe erfolgen kann.

5.2 Microservice Architektur Anwendungen SOLLTEN nach dem Microservices-Prinzip entwickelt werden.

• Jeder Service ist eigenständig deployment-fähig und unabhängig skalierbar. • Services kommunizieren ausschließlich über definierte APIs (z. B. REST, gRPC, Messaging). • Jeder Service verwaltet seine eigenen Daten (keine gemeinsame Datenbank zwischen Services). • Lose Kopplung und klare Verantwortlichkeiten zwischen den Services. • Fehler- und Ausfalltoleranz durch geeignete Patterns (z. B. Circuit Breaker, Retry, Timeouts).

5.3 Prinzip der geringsten Rechte (Least Privilege) für Anwendungen

• Die Anwendung innerhalb des Containers SOLLTE mit dem niedrigsten möglichen Berechtigungslevel laufen. • Anwendungen DÜRFEN NICHT als Root-Benutzer (UID 0) im Container ausgeführt werden.

5.4 Sichere Programmierpraktiken

• Die Anwendung selbst MUSS nach sicheren Programmierprinzipien entwickelt werden, um gängige Schwachstellen wie Injection-Angriffe, Cross-Site Scripting (XSS), unsichere Deserialisierung etc. zu vermeiden. Hierzu MUSS ein definierter, benannter und dokumentierter Standard für sichere Programmierung angewendet werden, z. B.: o OWASP Secure Coding Practices – Quick Reference Guide

Vorgaben für Kunden und Lieferanten Seite 20 von 25 1.4 vom 12.03.2025 Landesbetrieb Daten und Information

[Seite 21]

rlp-Cloud 2.0 - Containerplattform

o NIST SP 800-218 – Secure Software Development Framework (SSDF) • Die Anwendung MUSS gegen die unter OWASP Top 10 bekannten Angriffsszenarien gehärtet sein. Es wird empfohlen die Anwendung automatisiert vor der Auslieferung zu prüfen, z. B. mit dem Open Source Tool ZAP (https://www.zaproxy.org/). • Es SOLLTEN regelmäßige Code-Reviews und Sicherheitstests bspw.: o Static Application Security Testing (SAST), o Dynamic Application Security Testing (DAST) durchgeführt werden.

5.5 Verwaltung von Anwendungsabhängigkeiten Alle direkten und transitiven Abhängigkeiten der Anwendung SOLLTEN regelmäßig auf bekannte Schwachstellen untersucht und bei Bedarf aktualisiert werden. Es wird empfohlen diese Analysen zu automatisieren.

5.6 Input-Validierung und Output-Encoding Es SOLLTEN alle Eingaben serverseitig validiert und Ausgaben kontextgerecht kodiert werden, um Injection-Angriffe und XSS zu verhindern.

5.7 Sichere Handhabung von Geheimnissen zur Laufzeit Die Anwendung MUSS so konzipiert sein, dass sie Geheimnisse sicher von der Umgebung (z. B. über Umgebungsvariablen, eingebundene Dateien aus Secret-Management-Systemen) zur Laufzeit entgegennimmt, anstatt sie fest zu kodieren.

5.8 Empfehlung für „stateless“ Anwendungen Wo möglich SOLLTEN Anwendungen zustandslos gestaltet werden. Persistente Daten sollten in externen, gesicherten Speicherdiensten (PV oder S3) abgelegt werden, nicht im beschreibbaren Layer des Containers.

5.9 Health Checks Es MÜSSEN Liveness- und Readiness-Probes implementiert werden, damit OpenShift den Zustand der Anwendung überwachen kann.

5.10 Sichere Konfiguration und Vermeidung von Standardeinstellungen

• Standard-Anmeldeinformationen und Konfigurationseinstellungen von genutzten Diensten und Bibliotheken MÜSSEN geändert werden. • Eine sichere Standardkonfiguration MUSS für die Anwendung implementiert werden.

5.11 DNS-Nutzung Anwendungen MÜSSEN den Core-DNS Dienst des Clusters verwenden.

5.12 Zeitsynchronisation

• ES MUSS der von LDI bereitgestellte NTP-Service verwendet werden. Die Adressen werden im Rahmen des Onboardings vom LDI bereitgestellt. • Es MUSS sichergestellt sein, dass auch die Zeitzone korrekt konfiguriert ist.

Vorgaben für Kunden und Lieferanten Seite 21 von 25 1.4 vom 12.03.2025 Landesbetrieb Daten und Information

[Seite 22]

rlp-Cloud 2.0 - Containerplattform

5.13 E-Mail Es MUSS der vom LDI bereitgestellte SMTP-Server verwendet werden. Die Nutzung wird im Rahmen des Onboardings erläutert.

5.14 Zertifikate

• Anwendungsspezifische Zertifikate SOLLTEN, wenn benötigt, über ConfigMaps eingebunden werden. • Es SOLLTE geprüft werden ob Service Zertifikate ausreichend sind. • Private Schlüssel für Zertifikate MÜSSEN als Secret eingebunden werden.

5.15 Abweichungen In bestimmten Fällen kann es notwendig sein, weitere Konfigurationen zu Basisdiensten bereitzustellen. Diese zusätzlichen Konfigurationen MÜSSEN über ConfigMaps bereitgestellt werden (vgl. Kapitel 6.5)

5.16 Testumgebungen Es gibt keine dedizierte Testumgebung. Für Anwendungstest können verschiedene Namespaces mit Zuordnungen der unterschiedlichen Stages, wie TEST, REF oder PROD verwendet werden.

5.17 Standard Operatoren und Software Zum Start der Plattform stehen folgende Technologien zur Verfügung: • Registry (Harbor) o Jeder Namespace erhält ein eigenes Projekt in der Registry. o Das PULL-Secret wird im Namespace abgelegt bereitgestellt o Der Nutzer ist nicht über LDAP angebunden o Die Secrets lauten: initial-registry-ext-credentials initial-registry-int-credentials • Git: (Gitea) o Der Nutzer ist nicht über LDAP angebunden. o Jeder Namespace erhält ein eigenes GIT-Repository das mit Argo CD verbunden ist. o Das Secret heißt: initial-git-credentials • Red Hat OpenShift GitOps Operator (Argo CD / CD) o Nutzer ist gleich dem Namespace Admin-User über LDAP o Eigene Instanz für jeden Namespace. • Red Hat OpenShift Pipelines Operator (Tekton / CI) o Im Standard für jeden Namespace aktiviert • Weitere Operatoren stehen für den Nutzer aktuell nicht in der direkten Nutzung (Logging und Monitoring ausgenommen) zur Verfügung.

Vorgaben für Kunden und Lieferanten Seite 22 von 25 1.4 vom 12.03.2025 Landesbetrieb Daten und Information

[Seite 23]

rlp-Cloud 2.0 - Containerplattform

6 Sichere Laufzeitkonfiguration und Orchestrierung

6.1 Netzwerksicherheit und Segmentierung

• Netzwerkrichtlinien MÜSSEN nach dem Least-Privilegs Prinzip designt werden (z. B. Kubernetes Network Policies). • Netzwerkverkehr zwischen Containern/Pods SOLLTE standardmäßig verboten werden (Zero-Trust-Ansatz) und explizit nur notwendige Kommunikationspfade zugelassen werden. • Es SOLLTEN nur notwendige Ports exponiert werden.

6.2 Ressourcenbeschränkungen und Quality of Service (QoS) Ressourcenanfragen und -limits (CPU, RAM/Arbeitsspeicher) MÜSSEN für jeden Container/Pod definiert sein, um Denial-of-Service (DoS)-Angriffe durch Ressourcen- erschöpfung zu verhindern und eine faire Ressourcennutzung sicherzustellen.

6.3 Read-only Root-Dateisystem Container SOLLTEN nach Möglichkeit mit einem schreibgeschützten Root-Dateisystem ("readOnlyRootFilesystem: true" in Kubernetes) konfiguriert seien. Notwendige Schreibvorgänge SOLLTEN in explizit definierte Volumes ausgelagert werden.

6.4 Immutable Infrastructure Container MÜSSEN unveränderlich sein. Änderungen oder Patches MÜSSEN durch die Bereitstellung neuer, aktualisierter Images erfolgen, nicht durch Modifikationen von laufenden Containern.

6.5 ConfigMaps

• Konfigurationen der Applikation oder für Dienste, die von Images bereitgestellt werden MÜSSEN über ConfigMaps erfolgen (z. B. CA-Bundles). • Geheimnisse DÜRFEN NICHT in ConfigMaps hinterlegt sein. • Es DÜRFEN KEINE Binärdateien in ConfigMaps enthalten sein. • Die maximale Speichergröße einer ConfigMap DARF NICHT größer als 1 MB sein.

6.6 Secrets

• Zugangsdaten, Datenbankverbindungen oder andere geheime Informationen MÜSSEN in Secrets abgelegt werden. • Es KÖNNEN Secrets (Informationen nur codiert) oder Sealed-Secrets (Informationen verschlüsselt) verwendet werden. • Sealed-Secrets: o Es können eigene Schlüsselpaare oder der Plattform-Key verwendet werden. o Für die Verschlüsselung wird das Tool kubeseal benötigt.

Vorgaben für Kunden und Lieferanten Seite 23 von 25 1.4 vom 12.03.2025 Landesbetrieb Daten und Information

[Seite 24]

rlp-Cloud 2.0 - Containerplattform

o Aufrufbeispiel: kubeseal --cert kubeseal.pem -o yaml -f example-secret.yaml -n -w sealed-example-secret.yaml o Nutzer können auch eigene Zertifikate verwenden. Diese MÜSSEN durch den Nutzer sicher verwahrt werden. • Die maximale Speichergröße von Secrets DARF NICHT größer als 1 MB sein. • Der öffentliche Schlüssel für Sealed Secrets wird im Rahmen des Onboardings bereitgestellt.

7 Logging, Monitoring und Auditing

7.1 Vorgaben Logging

• Die Anwendung MUSS detaillierte und strukturierte Logs über ihre Aktivitäten, Fehler und sicherheitsrelevante Ereignisse erstellen. • Es DÜRFEN KEINE personenbezogenen Daten in den Anwendungslogs ausgegeben werden. Falls personenbezogene Daten geloggt werden, so MÜSSEN diese pseudonymisiert oder anonymisiert werden. • Anwendungen MÜSSEN nach „stdout“ und „stderr“ loggen. • Logs werden automatisch in das Plattformlogging überführt und gespeichert. • Für den Streaming–Speicher („stdout“ und „stderr) stehen rotierend 5x10 MB zur Verfügung. • Die Retention-Zeit im Plattform-Loki ist 14 Tage.

7.2 Monitoring

• Metriken werden über Prometheus erfasst. Hierfür sind die Endpunkte in der Anwendung z. B. unter /metrics bereitzustellen, • Der Endpunkt kann clusterintern mit http und https erreicht werden. • Die Standardzeit für die Abfrage beträgt 30 Sekunden. Ein kürzeres Intervall SOLL NICHT verwendet werden. • Für die Abfrage muss ein ServiceMonitor je Anwendung bereitgestellt werden.

ServiceMonitor Beispiel:

apiVersion: monitoring.coreos.com/v1 kind: ServiceMonitor metadata: labels: name: my-workload name: metrics namespace: my-namespace spec: endpoints:

Vorgaben für Kunden und Lieferanten Seite 24 von 25 1.4 vom 12.03.2025 Landesbetrieb Daten und Information

[Seite 25]

rlp-Cloud 2.0 - Containerplattform

• authorization: credentials: key: token name: my-workload-metrics-token type: Bearer path: /metrics port: metrics # oder port Nummer wie 8080 scheme: https interval: 60s namespaceSelector: {} selector: matchLabels: name: my-workload

7.3 Regelmäßige Audits Es SOLLTEN regelmäßige Sicherheitsaudits für die Artefakte und Build-Prozesse durch den Lieferanten durchgeführt werden.

7.4 Alarmierung In den Anwendungen SOLLTEN Alarmierungen implementiert sein, die Meldungen bei Anwendungsfehlern ausgeben (z. B. fehlgeschlagene Datenbankverbindung).

8 Schutz sensibler Daten

8.1 Datenverschlüsselung (im Ruhezustand und während der Übertragung) Es SOLLTE sichergestellt werden, dass sensible Daten, die von der Anwendung verarbeitet oder gespeichert werden, sowohl während der Übertragung „Data-in-Transport“ (TLS) als auch im Ruhezustand „Data-at-Rest“ (z. B. verschlüsselte Volumes, Datenbankverschlüsselung) angemessen geschützt sind.

8.2 Datenminimierung Software DARF NUR die für ihre Funktion absolut notwendigen Daten verarbeiten und speichern. Die Einhaltung dieser Anforderungen trägt maßgeblich dazu bei, die Sicherheit von Software in containerisierten Umgebungen zu erhöhen und die Risiken zu managen. Es ist ein kontinuierlicher Prozess, der in den gesamten Lebenszyklus der Softwareentwicklung und des Betriebs integriert werden sollte.

Vorgaben für Kunden und Lieferanten Seite 25 von 25 1.4 vom 12.03.2025 Landesbetrieb Daten und Information