Detailstandard 40: Vorgaben für die Erstellung von containerisierten Softwareprodukten
Zusammenfassung
Dieses Dokument beschreibt die zu erfüllenden Anforderungen im Bereich "Erstellung von containerisierten Softwareprodukten".
Standardisierung
Für die Erstellung von containerisierten Softwareprodukten ergeben sich folgende Detailanforderungen:
Aus den Softwarelieferanten-Abschnitten des Whitepaper für die Erstellung von Containern (siehe Referenzdokumente) müssen folgende Vorgaben erfüllt werden:
- Die im DVC Detailstandards - (44) Logging von Containern aufgelistete, aus dem Whitepaper für die Erstellung von Containern Kapitel 4.3 (siehe Referenzdokumente) übernommene Anforderung WP_EC_4.3_1 muss erfüllt werden.
- Die im DVC Detailstandards - (41) Vorgaben für die Lieferung oder Bereitstellung von containerisierten Softwareprodukten aufgelisteten, aus dem Whitepaper für die Erstellung von Containern Kapitel 6 (siehe Referenzdokumente) übernommenen Softwarelieferanten-Anforderungen WP_EC_6_1 bis WP_EC_6_11 müssen erfüllt werden.
Dazu müssen auch noch die folgenden - noch nicht in anderen Detailstandards aufgenommenen - Anforderungen aus dem Whitepaper für die Erstellung von Containern (siehe Referenzdokumente) erfüllt werden:
Implementierung/Containererstellung
Datenspeicherung
| ID | Rolle | Modalverb | Detailanforderung |
|---|---|---|---|
| WP_EC_4.1.1_1 | Softwarelieferant | MUSS | die Nutzung von temporärem Speicher so vorsehen, dass ein Restart des Containers und ein Wechsel des Hosts zur Laufzeit möglich ist. (SYS.1.6.A9 S) |
| WP_EC_4.1.1_2 | Softwarelieferant | MUSS | notwendige persistente Volumen und deren Nutzung (z. B. RWM, RWO, RW/RO) im Deployment Descriptor beschreiben. (SYS.1.6.A19 S) Umsetzungshinweise: z.B. Zielpfad im Containerbetrieb, Größe, Berechtigungen, Dateisystem, Performance. Die Beschreibung sollte in einer formalen Sprache erfolgen. Das Physical Volume Claim soll dynamisch erfolgen. Bitte mögliche Einschränkungen im Rechenzentrum beachten. |
| WP_EC_4.1.1_3 | Softwarelieferant | MUSS | sicherstellen, dass keine Zugangsdaten (z.B. Passworte, geheime/private Schlüssel, API-Keys, Schlüssel für symmetrische Verschlüsselungen) in Container-Images bzw. in Konfigurationsdateien gespeichert werden. (SYS.1.6.A8 B) Umsetzungshinweise: Anstatt statische Secrets auszuliefern können Secrets beim Deployment generiert werden. |
| WP_EC_4.1.1_4 | Softwarelieferant | MUSS | die Software so gestalten, dass diese keine Geheimnisse und Kennwörter als Plain-Text nutzt. (APP.4.4.A2 B) |
| WP_EC_4.1.1_5 | Softwarelieferant | MUSS | für seine Software sicherstellen, dass diese mit minimalen Berechtigungen lauffähig ist.(SYS.1.6.A21 H) Umsetzungshinweise: Beispielsweise sollen für Anwendungen, die nur Lesezugriff benötigen, nur Nutzer verwendet werden, die keinen Schreibzugriff haben. |
| WP_EC_4.1.1_6 | Softwarelieferant | MUSS | die Container mit Ressourcenbeschränkungen ausliefern (z.B. Datenmenge und Speicherzugriffe). (SYS.1.6A23 H) |
| WP_EC_4.1.1_7 | Softwarelieferant | MUSS | Daten in eigene Mount-Verzeichnisse schreiben. (SYS.1.6A23 H) |
| WP_EC_4.1.1_8 | Softwarelieferant | MUSS | sicherstellen, dass Daten, die im Container ausschließlich gelesen werden, als Read-Only-Volume in den Container eingebunden werden. (SYS.1.6A23 H) Umsetzungshinweise: Ein technischer Ansatz kann die Pod-Security-Policy “ReadOnlyRootFileSystem” sein |
| WP_EC_4.1.1_9 | Softwarelieferant | SOLL | keine lokalen Speicher der Workernodes benutzen. (SYS.1.6.A19 S) Umsetzungshinweise: Es sollte nur persistent Storage genutzt werden. “Sollte” bietet Ausnahmen für flüchtige Anwendungsfälle (virenscan) |
| WP_EC_4.1.1_10 | Softwarelieferant | SOLL | für seine Software sicherstellen, dass diese nicht in das Root-File-System des Containers schreiben darf. (SYS.1.6A23 H) |
| WP_EC_4.1.1_11 | Softwarelieferant | SOLL | das temporäre Speichern von Daten in dediziert dafür bereitgestellten Volumes (gängigerweise Ephemeral Storage) vornehmen. (SYS.1.6.A23 H) Umsetzungshinweise: bspw. Daten in temp-Verzeichnissen, wie File-Uploads, etc. |
Dienste und Service-Accounts
| ID | Rolle | Modalverb | Detailanforderung |
|---|---|---|---|
| WP_EC_4.1.2_1 | Softwarelieferant | MUSS | bei Neuentwicklungen die Software so gestalten, dass jeder Container nur einen Dienst bereitstellt. (SYS.1.6.A11 S) |
| WP_EC_4.1.2_2 | Softwarelieferant | MUSS | für Dienste, die unterschiedlich skalieren oder auf verschiedenen Worker-Nodes betrieben werden sollen, entsprechende Parameter der Deployment Descriptoren vorsehen. (SYS.1.6.A11 S) Umsetzungshinweise: Für Helm Charts ist die Parametrisierung über die values.yaml vorzusehen. |
| WP_EC_4.1.2_3 | Softwarelieferant | MUSS | pro Anwendung (mindestens) einen eigenen Service-Account bereitstellen, mit dem die Anwendung vollständig betrieben werden kann. (APP.4.4.A9 S) |
| WP_EC_4.1.2_4 | Softwarelieferant | MUSS | die Software so entwickeln, dass die Service-Accounts mit den geringst möglichen Berechtigungen (Least-Privilege) betrieben werden können. (APP.4.4.A9 S) |
| WP_EC_4.1.2_5 | Softwarelieferant | SOLL | bei der Nutzung von zeitlich wiederkehrenden Aktivitäten auf Systemebene (z.B. CRON-Jobs) die Mechanismen der Container-Plattform zur Ausführung nutzen. (SYS.1.6.A9 S) |
| WP_EC_4.1.2_6 | Softwarelieferant | SOLL | die Container so auslegen, dass eine horizontale Skalierung möglich ist. (SYS.1.6.A9 S) |
| WP_EC_4.1.2_7 | Softwarelieferant | SOLL | die Software so gestalten, dass jeder Container nur einen Dienst bereitstellt. (SYS.1.6.A11 S) Umsetzungshinweise: Die Einstufung mit “soll” ist nur aufgrund der Übergangsphase aus der “klassischen” in die Containerwelt vorgenommen worden. Es wird ein “muss” angestrebt. |
| WP_EC_4.1.2_8 | Softwarelieferant | SOLL | die Software so gestalten, dass Pods nicht den default Service-Account benötigen. (APP.4.4.A9 S) Umsetzungshinweise: Bei OpenShift sind die Rechte des “default” Service-Account bereits maximal eingeschränkt. |
Monitoring
| ID | Rolle | Modalverb | Detailanforderung |
|---|---|---|---|
| WP_EC_4.1.3_1 | Softwarelieferant | SOLL | Liveness- und Readiness-Checks gemäß der Kubernetes-Dokumentation bereitstellen. Die Checks, insbesondere die Readiness-Checks, sind anwendungsspezifisch zu betrachten (siehe einschlägige Best-Practices, bspw. Google Cloud Blog). (APP.4.4.A11 S) |
| WP_EC_4.1.3_2 | Softwarelieferant | SOLL | die forensische Analyse unterstützen, indem u.a. die eingehenden und ausgehenden Requests, sowie Konfigurationsänderungen geloggt werden. (SYS.1.6.A22 H) |
| WP_EC_4.1.3_3 | Softwarelieferant | SOLL | ein für seine Software erwartbares Verhalten (Systemaufrufe, Kommunikationsbeziehungen usw.) definieren, beschreiben und dem Softwarebetreiber vorlegen. (SYS.1.6.A24 H) Umsetzungshinweise: Wenn der Softwarelieferant das normale Verhalten - wie oben angesprochen - nicht angeben kann, dann muss der Softwarebetreiber das normale Verhalten durch Erprobung feststellen |
| WP_EC_4.1.3_4 | Softwarelieferant | KANN | Start-up-Checks für den Start der Container implementieren. (APP.4.4.A11 S) Umsetzungshinweise: siehe z.B. Configure Liveness, Readiness and Startup Probes |
Images
| ID | Rolle | Modalverb | Detailanforderung |
|---|---|---|---|
| WP_EC_4.1.4_1 | Softwarelieferant | MUSS | sicherstellen, dass gelieferte Artefakte, insb. Images, dem IT-Grundschutz entsprechen. (SYS.1.6.A10 S) |
| WP_EC_4.1.4_2 | Softwarelieferant | MUSS | das Image mit Metainformation versehen und signieren. (SYS.1.6.A12 S) Umsetzungshinweise: Es muss eine Liste von Metadaten die mindestens vorhanden sein müssen existieren (Versionierung und Tagging von Images). |
| WP_EC_4.1.4_3 | Softwarelieferant | MUSS | bewerten und sicherstellen, dass sämtliche Bestandteile seiner Anwendungsimages aus vertrauenswürdigen Quellen stammen. Dabei kann auf vom Plattformbetreiber freigegebene Base-Images aufgesetzt werden. (SYS.1.6.A6 S) |
| WP_EC_4.1.4_4 | Softwarelieferant | MUSS | dem Softwarebetreiber Container Images mit allen zur Runtime benötigten Modulen bereitstellen. Ein Nachladen von Modulen DARF NICHT erfolgen. (SYS.1.6.A6 S) |
| WP_EC_4.1.4_5 | Softwarelieferant | MUSS | regelmäßig Images auf Schwachstellen und Schadcode prüfen und bei Bedarf geeignete Updates zur Verfügung stellen. (SYS.1.6.A6 S) Umsetzungshinweise: Gängig sind in diesem Zusammenhang Security Scanner der Image Registry. Welche Reaktionszeiten angemessen sind, ist vertraglich zu definieren. |
Kommunikationsverbindungen
| ID | Rolle | Modalerb | Detailanforderung |
|---|---|---|---|
| WP_EC_4.1.5_1 | Softwarelieferant | MUSS | die Software so bereitstellen, dass keine Fernwartung möglich ist. (SYS.1.6.A16 S) Umsetzungshinweise: Die Container Images DÜRFEN KEINE Komponenten zur Fernwartung (zum Beispiel ssh, telnet) enthalten. |
| WP_EC_4.1.5_2 | Softwarelieferant | MUSS | Zugriffe und Berechtigungen auf Ressourcen durch seine Software auf die technisch notwendigen Zugriffe beschränken. (APP.4.4.A21 H und SYS.1.6.A21 H) |
| WP_EC_4.1.5_3 | Softwarelieferant | MUSS | die Vorgaben und Rahmenbedingungen des Software- und des Plattformbetreibers für die Kommunikationsbeziehungen berücksichtigen und seine Implementierung entsprechend auslegen. (SYS.1.6.A5B) Umsetzungshinweise: Bei Anbietern für Standardsoftware sollte der Plattformbetreiber prüfen, ob seine Anforderungen dem Marktangebot gerecht werden. |
| WP_EC_4.1.5_4 | Softwarelieferant | MUSS | die eingehende und ausgehende Kommunikation der Anwendung über Kubernetes-Serviceressourcen (Ingress und Egress) umsetzen. |
| WP_EC_4.1.5_5 | Softwarelieferant | MUSS | die notwendigen Kommunikationsbeziehungen (auch innerhalb von Namespaces) zwischen den Komponenten der Anwendung (z.B. Containern und Pods), sowie mit Komponenten außerhalb der Container-Plattform in geeigneter Weise dokumentieren. (APP.4.4.A18) |
| WP_EC_4.1.5_6 | Softwarelieferant | SOLL | die zertifikatsbasierte Authentifizierung unterstützen und Kommunikationsverbindungen nur für die in den Zertifikaten hinterlegten Identitäten erlauben. (APP.4.4.A18) Umsetzungshinweise: z.B. mittels mTLS. Es sollte mindestens eine Serverauthentifizierung umgesetzt werden. Eine Client-Authentifizierung sollte möglich werden. Die Umsetzung kann auch über einen Service-Mesh (Bereitstellung durch Plattformbetreiber notwendig) umgesetzt werden. |
Systemarchitektur
| ID | Rolle | Modalverb | Detailanforderung |
|---|---|---|---|
| WP_EC_4.1.6_1 | Softwarelieferant | MUSS | Software-Produkte so entwickeln, dass ein Re-Deployment auf einem "Restore-Cluster" jederzeit möglich ist (APP.4.4.A5 B) |
| WP_EC_4.1.6_2 | Softwarelieferant | SOLL | die Anwendung so bereitstellen, dass die lt. Schutzbedarf erforderliche Anwendung von technischen Schutzmaßnahmen wie z.B. die Verwendung von Betriebssystem-Mechanismen, die Isolation und Kapselung der Anwendung und auch die Netzwerktrennung durch die Software-Architektur unterstützt und nicht verhindert wird (durch Plattform vorgegebene Isolationsmechanismen wie z.B. SE Linux und CGroups; plattformspezifische Isolationsmechanismen wie z.B. Namespaces, Pod Security Admission und Network Policies) (SYS.1.6.A3 B, APP.4.4.A4 B) |
| WP_EC_4.1.6_3 | Softwarelieferant | SOLL | Software-Produkte so entwickeln, dass zu jedem beliebigen Zeitpunkt eine konsistente Datensicherung seiner Anwendung durch den Software- oder Plattformbetreiber durchgeführt werden kann und eine Point in Time Wiederherstellung möglich ist. (APP.4.4.A5 B) Umsetzungshinweise: Bei einem Recovery ist der exakt gleiche Zustand des Clusters (gleiche Anzahl an Pods) nicht erreichbar. Folgende Mechanismen sollten beachtet werden: - Festspeicher (Persistent Volumes) - Konfigurationsdateien von Kubernetes und den weiteren Programmen der Control Plane - plattformspezifische Erweiterungen wie z.B. Monitoring, Logging, Ingress etc. - Datenbanken der Konfiguration, namentlich hier etcd - alle Infrastrukturanwendungen die zum Betrieb des Clusters und der darin befindlichen Dienste notwendig sind - die Datenhaltung der Code und Image Registries |
Konfiguration/Administration
| ID | Rolle | Modalverb | Detailanforderung |
|---|---|---|---|
| WP_EC_4.2_1 | Softwarelieferant | MUSS | Konfigurationsanpassungen so ausführen, dass keine manuellen Anpassungen in laufenden Containern erfolgen. (SYS.1.6.A9 S) |
| WP_EC_4.2_2 | Softwarelieferant | MUSS | die Software so gestalten, dass die Container-Runtime und alle instanziierten Container nur von einem nicht-privilegierten System-Account ausgeführt werden, der keine erweiterten Rechte für den Container-Dienst bzw. das Betriebssystem des Host-Systems benötigt oder diese Rechte erlangen kann. Ausnahmen hiervon sind Container, welche Aufgaben des Host-Systems übernehmen.(kein “privileged”-Mode für die Container-Runtime und den laufenden Containern. Beispiel für Ausnahmen sind: ingress, egress und Infrastrukturcontainer) (SYS.1.6.A17 S) |
| WP_EC_4.2_3 | Softwarelieferant | MUSS | die Privilegien für Container auf das erforderliche Minimum begrenzen. (SYS.1.6.A17 S) |
| WP_EC_4.2_4 | Softwarelieferant | MUSS | die Informationen zur Einschränkung der Nutzung von erweiterten Privilegien dem Softwarelieferanten zur Verfügung stellen. (SYS.1.6.A17 S) |
| WP_EC_4.2_5 | Softwarelieferant | MUSS | die Software so gestalten, dass die genutzten User- und Group-ID’s keine Berechtigungen auf die System und Datenbereiche des Hosts erfordern. (SYS.1.6.A18 S) |
| WP_EC_4.2_6 | Softwarelieferant | MUSS | die erforderlichen User- und Group-ID’s und deren Berechtigungen benennen (z.B. in den Konfigurationsdateien). (SYS.1.6.A18 S) |
| WP_EC_4.2_7 | Softwarelieferant | MUSS | die mitgelieferte Konfiguration der Container versioniert bereitstellen und den Bezug zu Imageversionen sicherstellen. (SYS.1.6.A20 S) Umsetzungshinweise: Entweder z.B. durch Label in der YAML oder als git-repo. |
| WP_EC_4.2_8 | Softwarelieferant | MUSS | das vom Softwarebetreiber benötigte Verteilungsschema für die Pods unterstützen. (APP.4.4.A14 H) Umsetzungshinweise: z.B. Aufteilung der Pods entsprechend der Aufgaben. Der Softwarebetreiber muss das Verteilungsschema für die Pods definieren. Die Nodes müssen mindestens nach folgenden Aufgaben unterschieden und getrennt werden: - Bastion-Nodes zur Realisierung von ingress und egress - Anwendungs-Nodes zum Betrieb der Pods für die Anwendungen - Speicher-Nodes zur Bereitstellung der Speicherlösungen - Management-Nodes für den Cluster |
| WP_EC_4.2_9 | Softwarelieferant | MUSS | notwendige Berechtigungen im Deployment beschreiben. Diese müssen minimal gewählt werden. (APP.1.6.A19 S) |
| WP_EC_4.2_10 | Softwarelieferant | MUSS | den Abschluss eines Init-Container sicherstellen. (APP.4.4.A6 S) |
| WP_EC_4.2_11 | Softwarelieferant | MUSS | den Init-Container eindeutig von der Applikation logisch trennen. (APP.4.4.A6 S) |
| WP_EC_4.2_12 | Softwarelieferant | SOLL | das automatische Management seiner Software durch die Bereitstellung von geeigneten Administrationswerkzeugen unterstützen. (SYS.1.6.A2 B) Umsetzungshinweise: Werkzeuge können Deployment-Scripte, Pipeline-Scripte für CI/CD, Kubernetes Operatoren sein. |
| WP_EC_4.2_13 | Softwarelieferant | SOLL | Init-Container für Konfigurationsanpassungen nutzen. (SYS.1.6.A9 S) |
| WP_EC_4.2_14 | Softwarelieferant | SOLL | die Deployments entsprechend der Richtlinien des Softwarebetreibers ausrichten. (APP.4.4.A13 H). Umsetzungshinweise: Der Softwarebetreiber muss Richtlinien für die Einstellungen von Deployments definieren und dem Softwarelieferanten bekannt geben. |
| WP_EC_4.2_15 | Softwarelieferant | SOLL | bei besonders kritischen Anwendungen Operatoren zur Automatisierung von Betriebsaufgaben liefern. (APP.4.4.A16 H) |
Fehlertoleranz
| ID | Rolle | Modalverb | Detailanforderung |
|---|---|---|---|
| WP_EC_4.4_1 | Softwarelieferant | MUSS | eine Fehlertoleranz für die Anwendung für den Wiederanlauf nach einem ungeordneten Abbruch der Datenverarbeitung sicherstellen. (APP.4.4.A19 H) Umsetzungshinweise: Mögliche Maßnahmen: - atomare Gestaltung - keine persistente Daten im Container - Synchrone Transaktionen falls mehrere Datenbanken, Webservices usw. genutzt werden - Mechanismus zur Prüfung der Konsistenz der Daten - ggf. Mittel zur Wiederherstellung der Konsistenz. |
| WP_EC_4.4_2 | Softwarelieferant | SOLL | die Anwendung stateless gestalten, um die Mittel der Plattform bei einer Umsetzung von Hochverfügbarkeit nutzen zu können. (APP.4.4.A19 H) Umsetzungshinweise: Die Optionen hinsichtlich Zustandslosigkeit sind für Bestandsanwendungen beschränkt und lassen sich ggf. nicht umsetzen. |
| WP_EC_4.4_3 | Softwarelieferant | SOLL | Container stateless gestalten und eine transaktionsorientierte Funktionsweise der Anwendung sicherstellen. (SYS.1.6.A9 S) Umsetzungshinweise: Die transaktionsorientierte Funktionsweise soll sicherstellen, dass alle Verarbeitungen korrekt abgeschlossen werden können und keine inkonsistenten Zustände entstehen, selbst wenn Container neu deployed werden. |
| WP_EC_4.4_4 | Softwarelieferant | KANN | Start-up-Checks für den Start der Container implementieren. (APP.4.4.A11 S) Umsetzungshinweise: siehe Configure Liveness, Readiness and Startup Probes |
Update- und Patchmanagement
| ID | Rolle | Modalverb | Detailanforderung |
|---|---|---|---|
| WP_EC_4.5_1 | Softwarelieferant | MUSS | ein Patchmanagement gewährleisten. (SYS.1.6.A10 S) |
| WP_EC_4.5_2 | Softwarelieferant | MUSS | sicherstellen, dass Updates von Software nicht im laufenden Container installiert werden. Bei persistenten Containern SOLLTE geprüft werden, ob in (absolut seltenen) Ausnahmefällen ein Update des jeweiligen Containers geeigneter ist, als den Container vollständig neu zu provisionieren. (SYS.1.6.A14 S) Umsetzungshinweise: Es dürfen keine Tools enthalten sein, welche nicht für den Betrieb der Applikation notwendig sind (Paketmanager, YUM, APT, APK usw.). |
| WP_EC_4.5_3 | Softwarelieferant | MUSS | bei sicherheitsrelevanten und featurebasierten Updates der Anwendungen oder der Standardimages neue Images erstellen und eindeutig versioniert innerhalb der vereinbarten Zeiträume / SLAs zur Verfügung stellen. (SYS.1.6.A14 S) |
| WP_EC_4.5_4 | Softwarelieferant | MUSS | das Rechte- und Rollenkonzept für die Verwaltung des Sourcecodes umsetzen. (APP.4.4.A2 B) (s, auch CON.8) |
| WP_EC_4.5_5 | Softwarelieferant | SOLL | sicherstellen, dass die Software in der Lage ist, den Service auch während Updates entsprechend der definierten Anforderungen aufrechtzuerhalten. (SYS.1.6.A14 S) Umsetzungshinweise: d.h. Clusterfähigkeit der Software |
Dokumentation des Containers
| ID | Rolle | Modalverb | Detailanforderung |
|---|---|---|---|
| WP_EC_5.1_1 | Softwarelieferant | MUSS | die Richtlinien und Vorgaben zum sicheren Betrieb dem Softwarelieferanten bereitstellen. (SYS.1.6.A10 S) |
| WP_EC_5.1_2 | Softwarelieferant | MUSS | dokumentieren, welche Quellen für Images verwendet wurden. (SYS.1.6.A12 S) |
| WP_EC_5.1_3 | Softwarelieferant | MUSS | beschreiben, welche Quellen für Bestandteile des Image verwendet wurden, inklusive eines ggf. genutzten Basis-Images (SYS.1.6.A12 S) Umsetzungshinweise: Dies dient der Verdeutlichung des konzeptionellen Aufbaus der Software (z.B. zur Beurteilung hinsichtlich der verwendeten Lizenzen) |
| WP_EC_5.1_4 | Softwarelieferant | MUSS | Dimensionierungen (Requests) und Begrenzungen (Limits) für CPU, RAM sowie temporären Speicher für jeden Container auf den von ihm angenommenen Nutzerprofil empfehlen. (SYS.1.6.A15 S) Umsetzungshinweise: Der Softwarelieferant muss Defaultwerte für die Limits liefern, die dann ggf. vom Softwarebetreiber angepasst werden können. |
| WP_EC_5.1_5 | Softwarelieferant | MUSS | die Möglichkeiten und Funktionsweisen zur Skalierung der Dienste beschreiben. (SYS.1.6.A15 S) z.B. kubernetes pod hpa Umsetzungshinweise: Anmerkung: Limitierung muss auch berücksichtigt werden, wenn der Dienst skaliert werden soll |
| WP_EC_5.1_6 | Softwarelieferant | MUSS | Konfigurationsoptionen für die Protokollierung beschreiben. (SYS.1.6.A7 B) Umsetzungshinweise: Der Softwarebetreiber soll in die Lage versetzt werden, die Protokollierung, bspw. Log-Level, -Format oder -Kategorien, einzurichten. |
| WP_EC_5.1_7 | Softwarelieferant | MUSS | den Einsatz eines Init-Containers dokumentieren. (APP.4.4.A6 S) Umsetzungshinweise: Es müssen die Berechtigungen dargestellt werden. Er muss die notwendigen Ressourcen dokumentieren und eine Empfehlung bereitstellen. |
| WP_EC_5.1_8 | Softwarelieferant | MUSS | die Ressourcenanforderungen an die Init-Container beschreiben und dem Softwarebetreiber mitteilen. (APP.4.4.A6 S) |
| WP_EC_5.1_9 | Softwarelieferant | SOLL | die Umsetzung der Richtlinien und Vorgaben mit dem Softwarelieferanten vertraglich festhalten. (SYS.1.6.A10 S) Umsetzungshinweise: Insbesondere bei der Lieferung von Images, da hier die Fähigkeit der Anpassung der Images beschränkt wird. |
| WP_EC_5.1_10 | Softwarelieferant | SOLL | Handlungsempfehlungen bereitstellen, für den Fall, dass ein Container an seine Ressourcengrenzen kommt. (SYS.1.6.A15 S) |
| WP_EC_5.1_11 | Softwarelieferant | SOLL | die Möglichkeiten der Hochverfügbarkeit darstellen. (SYS.1.6.A25 H) |
| WP_EC_5.1_12 | Softwarelieferant | KANN | dem Softwarebetreiber ein Klassifikationssystem für die Erstellung einer Whitelist für vertrauenswürdige Quellen vorschlagen. (SYS.1.6.A12 S) |
Dokumentation von Anforderungen an persistenten Speicher
| ID | Rolle | Modalverb | Detailanforderung |
|---|---|---|---|
| WP_EC_5.2_1 | Softwarelieferant | MUSS | die Dimensionierungen und die Größe des benötigten persistenten Speichers empfehlen. Die Informationen müssen dem Softwarebetreiber mitgeteilt werden. (SYS.1.6.A15 S) Umsetzungshinweise: Der Softwarelieferant muss Defaultwerte für die Limits liefern, die dann ggf. vom Softwarebetreiber angepasst werden können. |
Kommunikationsbeziehungen dokumentieren
| ID | Rolle | Modalverb | Detailanforderung |
|---|---|---|---|
| WP_EC_5.3_1 | Softwarelieferant | MUSS | alle erforderlichen Kommunikationsverbindungen inklusive Ziele, Kommunikationsprotokolle und Ports beschreiben, die für Inbetriebnahme und Betrieb erforderlich sind.(APP.4.4.A7 S, siehe auch SYS.1.6.A5 B, siehe auch APP.4.4.A14 H ). Umsetzungshinweise: Feste Zuordnung von Containern zu Container-Hosts, Ausführung der einzelnen Container und/oder des Container-Hosts mit Hypervisoren und feste Zuordnung eines einzelnen Containers zu einem einzelnen Container-Host. |
| WP_EC_5.3_2 | Softwarelieferant | MUSS | benötigte Zugriffe und Berechtigungen auf Ressourcen dokumentieren. (APP.4.4.A21 H) |
| WP_EC_5.3_3 | Softwarelieferant | MUSS | dem Softwarebetreiber die von ihm definierten erweiterten Maßnahmen mitteilen, sofern vorhanden. (SYS.1.6.A26 H) Umsetzungshinweise: Bei klar definierten Zielen sollten FQDN oder IP-Adressen zur Beschreibung genutzt werden. Auch die Kommunikation innerhalb der Anwendung muss bekannt und beschrieben sein. |
| WP_EC_5.3_4 | Softwarelieferant | SOLL | Dimensionierungen (Requests) und Begrenzungen (Limits) auf den von ihm angenommenen Nutzerprofil für das Netzwerk definieren und dem Softwarebetreiber mitteilen. (SYS.1.6.A15 S) |
| WP_EC_5.3_5 | Softwarelieferant | KANN | in Abstimmung mit dem Softwarebetreiber die Kommunikationsbeziehungen in einer technisch formalen Form darstellen. (APP.4.4.A7 S, siehe auch SYS.1.6.A5 B) Umsetzungshinweise: siehe Network Policies |
Berechtigungen
| ID | Rolle | Modalverb | Detailanforderung |
|---|---|---|---|
| WP_EC_5.4_1 | Softwarelieferant | MUSS | darlegen, für welche Zwecke technische User (z.B.: Kubernetes Service-Accounts) Berechtigungen erfordern. (APP.4.4.A3 B) Umsetzungshinweise: Der Softwarebetreiber muss die benötigten Accounts und Berechtigungen beim Plattformbetreiber anfordern und sie müssen den Privilegienrichtlinien entsprechen. Der Softwarebetreiber muss anonyme Zugriffe für administrative Handlungen verhindern. |
Lizenzen
| ID | Rolle | Modalverb | Detailanforderung |
|---|---|---|---|
| WP_EC_5.5_1 | Softwarelieferant | MUSS | dem Softwarebetreiber bekannt geben, welche Lizenzen auf der Container-Plattform für den Betrieb der Software erforderlich sind und diese je nach vertraglicher Vereinbarung auch bereitstellen. (SYS.1.6.A9 S) |
Sonstiges
Zusätzlich müssen noch die folgenden - nicht im Whitepaper aufgeführten - Vorgaben erfüllt sein:
| ID | Rolle | Modalverb | Detailanforderung |
|---|---|---|---|
| DS_40_A001 | Softwarelieferant | SOLL | bei der Erstellung von Containern maximal einen Prozess im Container erzeugen (Single-Process Only). |
Hoheit über Krypto-Module und -Schlüssel
| ID | Rolle | Modalverb | Detailanforderung |
|---|---|---|---|
| DS_40_A002 | Softwarelieferant | MUSS | als Vorgabe für den Einsatz von Krypto-Technologien und Tools TR02102 beachten. |
| DS_40_A003 | Softwarelieferant | MUSS | sicherstellen, dass der Softwarebetreiber alle mit Krypto-Modulen verbundenen Aufgaben im operativen Tagesgeschäft durchführen kann. Die Hoheit über alle benötigten Schlüssel liegt beim Softwarebetreiber. |
| DS_40_A004 | Softwarelieferant | MUSS | sicherstellen, dass alle benötigten Informationen bezüglich Zertifikaten, Schlüsseln etc. in der Dokumentation des Softwarelieferanten enthalten sind. |
Referenzdokumente
| Dokument | Version | Link | |
|---|---|---|---|
| DVC Detailstandards - (41) Vorgaben für die Lieferung oder Bereitstellung von containerisierten Softwareprodukten | Detailstandard 41: "Vorgaben für die Lieferung oder Bereitstellung von containerisierten Softwareprodukten" | Detailstandard 41 PDF | |
| DVC Detailstandards - (44) Logging von Containern | Detailstandard 44: "Logging von Containern" | Detailstandard 44 PDF | |
| Whitepaper für die Erstellung von Containern | 2.0 | nur PDF | Whitepaper PDF |
| Technische Richtlinie TR-02102-2 Kryptographische Verfahren: Empfehlungen und Schlüssellängen | 2024-01 | nur PDF | Technische Richtlinie TR-02102-2 |