Die Integration von Sicherheitsfunktionen in eine Lösung erst spät im Design- und Entwicklungszyklus führt oft zu kostspieligen Nacharbeiten und Einbußen bei der Benutzerfreundlichkeit, was die Leistungsfähigkeit der Lösung und die Erfahrung der Benutzer beeinträchtigt. Lösungen von Anfang an sicher zu konzipieren, trägt dazu bei, ein angemessenes Gleichgewicht zwischen Benutzerfreundlichkeit, Interoperabilität, Ausfallsicherheit und Sicherheit für die endgültige Lösung zu gewährleisten.

Secure by Design ist das Prinzip, dass die Gestaltung, Entwicklung und Umsetzung eines Projekts Sicherheits- und Compliance-Praktiken umfassen müssen, die von einem qualifizierten und erfahren Team durchgeführt werden. Sicherheitsdesignrichtlinien wie die folgenden steuern architektonische Denkprozesse.

Der Designprozess muss mit dem Einsatz von Design Thinking auf Unternehmensebene beginnen, um sich auf die erforderlichen Benutzerergebnisse für Risiko-, Compliance- und Sicherheits-Stakeholder zu konzentrieren, sowohl innerhalb als auch außerhalb von Unternehmen. Zu den externen Stakeholdern gehören Kunden, Regierung und Regulierungsbehörden. Zu den internen Stakeholdern gehören diejenigen, die Risiko, Compliance und Sicherheit managen.

Der Designprozess wird mit architektonischem Denken fortgesetzt, um architektonische Merkmale und Entscheidungen, die funktionale Architektur und das Cloud-Bereitstellungsmodell zu definieren. Anschließend werden die Merkmale der Sicherheitsdienste, wie beispielsweise Resilienz, Leistung und Skalierbarkeit, definiert.

Nach dem Definieren von Anforderungen und Architektur kann die Entwicklung der Sicherheitsfunktionalität und -infrastruktur erfolgen, wobei der Grundsatz „Secure by default“ befolgt wird.

IBM bietet einen langjährigen Ansatz für Sicherheit und Datenschutz bei der Entwicklung von Produkten. Das veröffentlichte IBM Redpaper über Sicherheit in der Entwicklung: Das IBM Secure Engineering Framework ist für Überprüfungen hilfreich.

Wenn Benutzer oder Software bei einem System übermäßige Berechtigungen haben, besteht das Risiko eines Missbrauchs, sei es versehentlich oder absichtlich. Bedrohungsakteure können die berechtigten Konten interner Benutzer kompromittieren und ihre Berechtigungen ausnutzen, um in das Netzwerk und die Systeme zu gelangen.

Minimale Berechtigung besagt als Prinzip, dass das System Benutzern oder Software nur minimale Berechtigungen erlaubt, die nötig sind, um ihre vorgesehenen Aufgaben auszuführen. Das System sollte dies von der höchsten Ebene einer Anwendung bis hin zur einzelnen Verbindung zwischen zwei Softwarekomponenten implementieren.

Um das Prinzip der minimalen Berechtigung umzusetzen, müssen Sie die Assets in Ihrer dynamischen IT-Umgebung verstehen. Berechtigter Zugriff ist nicht nur ein menschliches Problem, man muss wissen, welche Anwendungen Zugriff auf welche Daten haben. Der Prozess der Entdeckung, Klassifizierung und Risikobewertung ist fortlaufend. Führen Sie Risikodaten aus Ihren digitalen Assets zusammen, um neue Erkenntnisse über Geschäftsrisiken zu gewinnen und so die richtigen Richtlinien festzulegen.

Ein Benutzer oder eine Software kann zum Zeitpunkt der ersten Identifizierung und Authentifizierung für eine Sitzung einen sicheren Kontext haben, ein Bedrohungsakteur könnte die aktive Sitzung aber kompromittieren und nutzen, um ein System weiter zu kompromittieren.

Kontinuierliche Verifizierung ist das Prinzip, dass ein Benutzer oder eine Software ständig verifiziert werden muss, um zu beurteilen, ob sie noch einen sicheren Kontext hat. Ziel der kontinuierlichen Überprüfung ist es, Sicherheitsprobleme und Schwachstellen so früh wie möglich zu erkennen, idealerweise auch Bedrohungsakteur

Die kontinuierliche Verifizierung bestätigt, dass die Personen die sind, für die sie sich ausgeben, z. B. durch eine Anfrage zur Authentifizierung mit einem zweiten Faktor. Ein Workload muss möglicherweise aktualisiert werden, um die kontinuierliche Überprüfung von Benutzern und Software mithilfe von Lösungen zu unterstützen, die eine Zero Trust Network Architecture (ZTNA) verwenden. Unternehmen, die sich auf die Bereitstellung erstklassiger Benutzererfahrungen konzentrieren, wollen Benutzer eher nicht mit unnötigen Anfragen stören, diese Art der Identitätssicherung ist jedoch für Zero Trust von entscheidender Bedeutung.

Ein Bedrohungsakteur ist möglicherweise bereits in ein Unternehmen eingedrungen. Wenn Unternehmen nur nach Bedrohungen an der externen Boundary suchen und nicht nach Bedrohungen, die einen gültigen Mechanismus zur Umgehung der Boundary-Kontrolle verwendet haben, kann es sein, dass Sicherheitsvorfälle lange Zeit nicht entdeckt werden. Das Prinzip Annahme eines Sicherheitsverstoßes bedeutet, dass Unternehmen davon ausgehen, dass ein Sicherheitsverstoß durch einen Bedrohungsakteur stattgefunden hat.

Der Ansatz erfordert, dass das Bedrohungsmanagement eine proaktive interne Erkennung hinzufügt, auf Frühwarnzeichen achtet, Bedrohungsjagden und bewährte Runbooks verwendet. Die Erkennung und Reaktion muss eng in die Erkenntnis- und Durchsetzungsebenen integriert werden, um den Kontext zu teilen und die Richtlinien zur Zugriffskontrolle dynamisch an die erkannten Bedrohungen anzupassen.

Informationssysteme weisen Schwachstellen in der Software, Firmware und Hardware auf. Konfigurationen und Software ändern sich und neue Schwachstellen entstehen. Wenn eine Verteidigungsschicht verwundbar ist, muss das System sicher bleiben.

Tiefgreifende Verteidigung besagt als Prinzip, dass ein System mehrere Verteidigungsschichten braucht, sodass bei Ausfall einer Schicht eine andere Schicht bestehen bleibt, um die sensiblen Daten im System zu schützen. Die Verwendung eines mehrschichtigen Ansatzes für Sicherheitsstrategien stellt sicher, dass Unternehmen einen Angreifer auf einer nachfolgenden Schicht stoppen können, wenn eine Verteidigungsschicht durchbrochen wurde.

Die Sicherheitsstrategie und -architektur des Unternehmens muss Maßnahmen umfassen, die Schutz auf den nachfolgenden Schichten des traditionellen Netzwerk-Computing-Modells bieten. Im Allgemeinen müssen Unternehmen die Sicherheit von der grundlegendsten (Sicherheit auf Systemebene) bis zur komplexesten (Sicherheit auf Übertragungsebene) Ebene planen.

Die Angriffsfläche eines Unternehmens ist die Summe der Schwachstellen, Wege oder Methoden – manchmal auch Angriffsvektoren genannt – die Bedrohungsakteure nutzen können, um sich unbefugt Zugriff auf das Netzwerk oder sensible Daten zu verschaffen oder um einen Cyberangriff durchzuführen. Da Unternehmen zunehmend Cloud-Services und hybride Arbeitsmodelle (vor Ort/von zu Hause aus) einsetzen, werden ihre Netzwerke und die damit verbundenen Angriffsflächen immer größer und komplexer.

Die Minimierung der Angriffsfläche besagt als Prinzip, dass ein System den Umfang der Angriffsvektoren verringern sollte, um die Möglichkeiten, wie ein Bedrohungsakteur Zugang erlangen kann, zu verringern. Sicherheitsexperten unterteilen die Angriffsfläche in drei Teilflächen: Die digitale Angriffsfläche, die physische Angriffsfläche und die Social-Engineering-Angriffsfläche.

1. Die digitale Angriffsfläche kann die Cloud- und die lokale Infrastruktur des Unternehmens jedem Bedrohungsakteur mit einer Internetverbindung aussetzen. Zu den gängigen Angriffsvektoren gehören Netzwerkzugriffe, Software-Schwachstellen, die Aktivierung ungenutzter Ressourcen, Schatten-IT und veraltete Software.

2. Die physische Angriffsfläche legt Assets und Informationen offen, auf die normalerweise nur Benutzer mit autorisiertem Zugriff auf das physische Büro oder die Endgeräte des Unternehmens zugreifen können. Dazu gehören Angriffe von böswilligen Insidern, Gerätediebstahl und „Baiting“ – ein Angriff, bei dem Bedrohungsakteure mit Malware infizierte USB-Sticks in der Hoffnung an öffentlichen Orten zurücklassen, Benutzer dazu zu bringen, die Geräte an ihre Computer anzuschließen und unbeabsichtigt Malware herunterzuladen.

3. Die Social-Engineering-Angriffsfläche bringt Menschen dazu, Informationen offenzulegen, die eigentlich nicht weitergegeben werden sollten, nicht für diesen Zweck vorgesehene Software herunterzuladen, verbotene Websites zu besuchen, Kriminellen Geld zu senden oder andere Fehler zu begehen, die ihre persönliche Sicherheit oder die Sicherheit des Unternehmens gefährden.

Unternehmen sollten das Risiko für die vom System verarbeiteten, sensiblen Daten evaluieren, indem jede dieser Angriffsflächen untersucht wird.

Benutzer könnten Zugriff auf extrem sensible Daten erhalten, die eine Umgehung von Kontrollmechanismen ermöglichen, wie z. B. Verschlüsselung, oder die Berechtigung haben, Aktionen mit besonderen Berechtigungen durchzuführen, wie z. B. die Überweisung großer Geldsummen. Selbst wenn ein System die Benutzer überwacht, können diese ihre Rechte missbrauchen, was katastrophale geschäftliche Folgen haben kann.

Aufgabentrennung beruht auf dem Prinzip, dass Benutzer mit weitreichendem Zugriff auf Daten oder Aktionen mehr als einen Benutzer benötigen, um die Aktion auszuführen. Sie bietet Unternehmen die Möglichkeit, administrative Funktionen auf mehrere Personen aufzuteilen, ohne dass es zu Überschneidungen der Verantwortlichkeiten kommt, sodass kein einzelner Benutzer über uneingeschränkte Befugnisse verfügt.

Bei Aktivitäten wie der Verwaltung von Verschlüsselungen verlangt das Unternehmen von Administratoren von Verschlüsselungscode, verschiedene Teile des Codes zu verwalten, sodass kein einzelner Administrator über den gesamten Code informiert ist. Bei geschäftlichen Transaktionen kann die Anwendung verlangen, dass die Person, die eine Transaktion beantragt, einen oder mehrere Genehmiger hat, damit die Transaktion abgeschlossen werden kann.

In einigen Branchen kann eine Regulierungsbehörde als Teil der regulatorischen Leitlinien eine Aufgabentrennung für wichtige Funktionen vorschreiben. Die Aufgabentrennung hilft Unternehmen, Vorschriften von Behörden einzuhalten, und vereinfacht die Verwaltung der Befugnisse.

Produkte oder Dienstleistungen enthalten viele verschiedene Konfigurationspunkte und es besteht der Wunsch, sie so einfach wie möglich zu nutzen. Daher verfügen diese Produkte über eine unsichere Sicherheitskonfiguration, z. B. offene Netzwerkports oder leicht zu merkende Passwörter.

Secure by Default besagt als Prinzip, dass ein Unternehmen Produkte oder Dienste erhält, die von vornherein in einem sicheren Zustand konfiguriert sind. Die Produkte sind so eingerichtet, dass sie vor den häufigsten Bedrohungen und Sicherheitslücken schützen, ohne dass die Endbenutzer zusätzliche Maßnahmen ergreifen müssen, um sie abzusichern.

Ein System kann zu Beginn sicher konfiguriert sein, aber ein Entwickler kann anschließend eine Änderung vornehmen, die die Konfiguration verändert, oder ein Bedrohungsakteur nimmt eine Änderung durch eine Schwachstelle vor, die das System kompromittiert.

Kontinuierliche Compliance besagt als Prinzip, dass die Sicherheitskonfiguration des Systems ständig überprüft wird, angefangen bei der Systementwicklung bis hin zum laufenden System. Das Ziel der kontinuierlichen Compliance ist es, Sicherheitsprobleme und Schwachstellen zu finden, bevor Bedrohungsakteure es tun.

Idealerweise erfolgen alle Compliance-Prüfungen automatisiert und decken alle Sicherheitskonfigurationen ab, einschließlich der Cloud-Plattform, der Container-Plattform, Middleware und Compute-Images wie Virtual Servers und Container. Bei Compute-Images ist es möglicherweise besser, Infrastructure as Code (IaC) zu verwenden, um das gesamte Image regelmäßig zu ersetzen.

Die gemeinsamen Verantwortlichkeiten für die Bereitstellung von Sicherheit und Compliance in einer Hybrid-Cloud-Umgebung hängen von den Service-Modellen, Rechenplattformen und Cloud-Service-Anbietern ab, die von der Workload oder Anwendung verwendet werden. Ein Sicherheitsarchitekt muss die Verantwortlichkeiten für die Konzeption, den Aufbau und den Betrieb der Sicherheitsdienste dokumentieren und kommunizieren. Ohne Klarheit kann es zu Sicherheitslücken in der Lösung kommen.

Jede Dimension hat unterschiedliche Auswirkungen auf die gemeinsamen Verantwortlichkeiten:

• Cloud-Servicemodell - Die NIST-Definition von Cloud Computing sieht je nach Cloud-Servicemodell, wie IaaS, PaaS, SaaS oder verteilte Cloud, unterschiedliche Verantwortlichkeiten vor. Sicherheitsdienstleistungen sind Teil der gemeinsamen Verantwortlichkeiten. Zu den gemeinsamen Verantwortlichkeiten für IBM Cloud gehören beispielsweise Identity und Access Management (IAM) sowie Sicherheit und Einhaltung gesetzlicher Vorschriften. Die geteilten Verantwortlichkeiten für diese Kategorien variieren je nach Cloud-Service-Modell.
   

• Compute-Plattform – Das Hosting einer Workload kann aus einer oder mehreren Compute-Plattformen bestehen, zum Beispiel Bare Metal Server, virtuelle Server, Container-Plattformen und serverlose Varianten. Jede Rechenplattform hat ein anderes Spektrum an gemeinsamen Verantwortlichkeiten. Bei Bare Metal Servern beispielsweise ist der Eigentümer der Workload für alle Sicherheitskontrollen auf der Plattform verantwortlich, außer für die physische Hardware und die Netzwerkintegration.
   

• Cloud-Service-Anbieter – Die Verantwortlichkeiten ändern sich ebenfalls je nach Cloud-Service-Anbieter. Beispielsweise sind die Kubernetes-Plattformen der einzelnen Cloud-Service-Anbieter unterschiedlich (es sei denn, Sie verwenden Red Hat OpenShift), da sie jeweils aus einem anderen Satz von zusammengestellten Open-Source-Paketen bestehen.

Warum sollten sich Sicherheitsarchitekten also für die Unterschiede in der Dienstverantwortung interessieren? Das für den Sicherheitsbetrieb zuständige Team kann vordefinierte Sicherheitsdienste zur Unterstützung des Betriebs des Dienstes verwenden. Die Sicherheitsdienste können Teil der Cloud-Plattform sein oder lokal implementiert werden und eine umfassende Integration erfordern.

Ein internes Sicherheitsteam verwendet beispielsweise eine andere Technologie als ein globaler Systemintegrator (GSI) wie IBM Consulting. Für das interne Sicherheitsteam kann die Steuerungsebene, auf der die Sicherheitsdienste gehostet werden, lokal sein, während das GSI möglicherweise Cloud-Sicherheitsdienste eines anderen Cloud-Service nutzt.

Für das Software-as-a-Service (SaaS) Cloud-Servicemodell steht dem Benutzer des Cloud-Services nur die Verwaltung der Anwendung zur Verfügung. Sicherheit ist normalerweise als Teil des Dienstes in die Anwendung integriert, wobei die Sicherheitskonfiguration nur begrenzt gesteuert werden kann. In diesem Fall übernimmt der SaaS-Anbieter die meisten Sicherheitsverantwortlichkeiten.

Ohne dokumentierte Verantwortlichkeiten gibt es möglicherweise keine Eigentümer, die Komponenten entwerfen, entwickeln und ausführen, die von der Ausführung der Workload abhängen. Das Verständnis der gemeinsamen Verantwortlichkeiten für die Sicherheitsdienste ermöglicht, dass die Lösungsarchitektur den betrieblichen Anforderungen gerecht wird und eine Überarbeitung der Lösung in einem späteren Projektstadium vermieden wird.

Sicherheitsdienste in einer Hybrid-Cloud-Architektur nutzen unterschiedliche Cloud-Servicemodelle, Rechenplattformen und Cloud-Service-Anbieter. Diese Dienste benötigen eine gemeinsame Architektur der Steuerungsebene, um eine konstante Verwaltung und Überwachung von Sicherheit und Compliance zu gewährleisten.

Bei einem Unternehmen mit Workloads im lokalen Rechenzentrum kann sich die Steuerungsebene in einem lokalen Rechenzentrum befinden, um gegen den Ausfall eines Cloud-Service-Anbieters gewappnet zu sein. Ein lokaler Sicherheitsdienst hat jedoch nicht unbedingt die Möglichkeit, die Cloud-Plattform vollständig zu verwalten. Entwickeln Sie daher eine Architektur für die Steuerungsebene, um den Sicherheitsstatus zu melden und Risiken bei den verschiedenen Cloud-Services zu erkennen.

Bei cloudnativen Unternehmen kann das Hosting der Steuerungsebene in einer anderen Cloud, an einem Point-of-Presence (POP) oder in einem Rechenzentrum erfolgen. Die Steuerungsebene muss möglicherweise auch dann verfügbar bleiben, wenn es zu einem Ausfall bei einem Cloud-Service-Anbieter gekommen ist.

Für Sicherheitsarchitekten ist es wichtig, Architekturentscheidungen zu dokumentieren und abzustimmen, um eine einheitliche Architektur der Steuerungsebene zur Sicherheit im gesamten Unternehmen zu gewährleisten. Treffen Sie diese Entscheidung zu Beginn des Projekts, um sicherzustellen, dass die Lösung der Strategie der Organisation entspricht.

Sicherheit bedeutet nicht in erster Linie die Bereitstellung von Funktionen, sondern den Schutz von Geschäftsdaten und Prozessen vor Bedrohungen. Verwenden Sie einen systematischen Ansatz, um die Datenflüsse durch das System zu verfolgen und die Sicherheitskontrollen zum Schutz der Daten bei der Übertragung, im Ruhezustand und bei der Nutzung zu identifizieren.

Architekten müssen sensible Daten zum Schutz identifizieren, indem sie mit einem Systemkontextdiagramm beginnen, um die Systemgrenze und externe Interaktionen zu identifizieren, die den Datenfluss durch das System initiieren. Die internen Datenflüsse der Anwendung werden dann mithilfe eines Diagramms untersucht, um die funktionalen Komponenten zu beschreiben, beispielsweise einem Komponentendiagramm.

Wenn Architekten zur Implementierung übergehen, untersuchen sie die Datenströme zwischen den Komponenten, die auf der Cloud bereitgestellt werden, anhand eines Cloud-Architekturdiagramms. IBM hat eine technische Diagramm-Designsprache entwickelt, die ein Design ermöglicht, das unabhängig vom Cloud-Service-Anbieter ist.

Um die Bedrohungen für diese Datenströme zu identifizieren, verwenden Sie die Bedrohungsmodellierung sowohl für die funktionalen Komponenten der Workload als auch für ihre Infrastruktur.

Kombiniert bieten diese Techniken und Artefakte einen wiederholbaren und konstanten Ansatz für das architektonische Denken im Hinblick auf Sicherheit und Compliance.

Bei der Verarbeitung besonders sensibler Daten sollten Sie über eine weitere Schutzschicht durch Confidential Computing und homomorphe Verschlüsselung nachdenken.

Ein System muss viele verschiedene Kontrollanforderungen erfüllen und die Liste kann lang und schwer zu verwalten sein. Anstatt mit vielen einzelnen Anforderungen zu arbeiten, sollten Sie mit Prozessen, Diensten oder Funktionen arbeiten, die Anforderungen in Bereitstellungsfunktionen einteilen. Zum Beispiel sind Identity Lifecycle Management oder die Erkennung nicht autorisierter Komponenten potenzielle Bereitstellungsfunktionen.

Befolgen Sie diese Schritte, um die Compliance effektiver zu verwalten:

1. Erstellen Sie ein einheitliches Compliance-Framework mit Rückverfolgbarkeit bis zu den ursprünglichen Quellen.
2. Ordnen Sie die Anforderungen im Compliance-Framework einer Reihe von Bereitstellungsfunktionen zu
3. Gewährleisten Sie konforme Funktionen in allen Phasen von Entwurf, Entwicklung, Test und Betrieb.
4. Die Produktionsvorgaben müssen weiterhin eingehalten werden.

Der Sicherheitsarchitekt muss sicherstellen, dass den Sicherheitsfunktionen Service Level Objectives (SLOs), Verantwortlichkeitsvereinbarungen usw. zugeordnet sind.

Oft muss sichergestellt werden, dass die Daten eines Kunden, eines Geschäftsbereichs oder einer Umgebung nicht in einen anderen gelangen. Die Ausführung der Workload und die Speicherung der Daten müssen getrennt erfolgen. Das gelingt zum Beispiel durch eine andere Tabelle in einer Datenbank oder getrennte physische Server.

Die Hybrid Cloud bietet viele Möglichkeiten, um die Trennung der Datenverarbeitung durchzusetzen. Eine Trennung sollte zwischen folgenden Komponenten erfolgen:

1. Workloads oder Anwendungen – zum Beispiel Buchhaltung im Vergleich zu Personalwesen
2. Umgebungen – zum Beispiel Entwicklung, Test und Produktion
3. Kunden – zum Beispiel Kunde A im Vergleich zu Kunde B
4. Standort – zum Beispiel UK im Vergleich zu USA

Es gibt viele verschiedene Optionen für die Segmentierung innerhalb einer Hybrid-Cloud-Umgebung, die jeweils unterschiedliche Funktionen und Sicherheit bieten:

1. Enterprise-Konto
2. Cloud-Konto
3. Ressourcengruppe
4. Virtual Private Cloud
5. Ausführungsbereich – zum Beispiel ein Container- oder Server-Image
6. Projekt
7. Hauptverwaltungsbereich
8. Physische Geräte

Die Unternehmensrichtlinien müssen festlegen, welche Art der Trennung für die Workload, die die Daten verarbeitet, angemessen ist. Beispielsweise kann die Richtlinie verlangen, dass das Hosting der Produktionskundendaten nicht in einer produktionsexternen Umgebung stattfinden darf. Als Mindestmaß an Trennung ist ein anderes Cloud-Konto erforderlich, da dort die Verwaltung von Identität und Zugriff stattfindet.

Eng mit dem Thema Datentrennung verbunden ist das der Datensouveränität. Bestimmte Länder legen Beschränkungen für den Ort der Datenverarbeitung und des Datenzugriffs fest. Der Blogbeitrag „Addressing Regulations and Driving Innovation with Sovereign Cloud“ beschäftigt sich mit einer Hierarchie der Anforderungen an Datensouveränität.

Die Bedrohungsmodellierung wird häufig als Technik zur Identifizierung und Validierung der Sicherheitskontrollen für Datenflüsse in einem System betrachtet.

Die Bedrohungsmodellierung hat jedoch noch einen weiteren Zweck: Bedrohungen zu identifizieren, die in einem Threat-Monitoring-System überwacht werden sollen. Der Sicherheitsarchitekt muss eine priorisierte Liste von Bedrohungen erstellen. Er definiert dann die erforderlichen Anwendungsfälle für die Funktion der Bedrohungserkennung. Er implementiert und testet die Anwendungsfälle der Erkennung mit Runbooks zur Reaktion auf Vorfälle, um eine effektive Reaktion auf Bedrohungen zu ermöglichen.

Stellen Sie die dokumentierte Rückverfolgbarkeit zwischen den Bedrohungen, den Anwendungsfällen für die Erkennung und den Runbooks für die Reaktion auf Vorfälle sicher, um die vollständige Konzeption und Umsetzung des Projekts zu gewährleisten.

In der Vergangenheit konnten Sicherheitsteams in lokalen Rechenzentren diese Aktivitäten innerhalb weniger Tage oder Stunden erledigen, ohne strenge Serviceniveaus zu benötigen. Bei der Automatisierung von Infrastructure as Code (IaC) wirkt sich der Ausfall eines zentralisierten Sicherheitsdienstes, wie z.B. Code- oder Zertifikatsverwaltung, unmittelbar auf die Verfügbarkeit einer Anwendung aus. Daher benötigen Sicherheitsdienste Serviceniveaus und eine Architektur, um die Verfügbarkeitsanforderungen zu erfüllen.

Definieren Sie für jede Sicherheitsfunktion oder jeden Service Folgendes:

1. Betriebszeiten
2. Reaktionszeiten für Vorfälle, Probleme und Änderungen
3. Kompetenz und Erfahrung des Betriebspersonals
4. Detaillierte, getestete Verfahren, die den Serviceanforderungen entsprechen
5. Automatisierung zur Anpassung an die Serviceanforderungen

Wenn das Team für interne Sicherheitsabläufe die Anforderungen einer cloudnativen Workload nicht erfüllen kann, sollten Sie überlegen, ob ein Anbieter von verwalteten Sicherheitsdiensten besser geeignet ist.

Wenn man es genau betrachtet, benötigen viele Sicherheitsdienste heutzutage eine Ausfallsicherheit und ein Serviceniveau, das mindestens so gut ist wie die Workload, die sie bewältigen müssen.

Veraltete Vorgehensweisen führten dazu, dass Sicherheit erst im Nachhinein berücksichtigt wurde, was die Konfiguration und das Umsetzen von Sicherheitspatches erschwerte, da dies nicht früh im Entwicklungszyklus geschah. Bei DevOps-Arbeitsmethoden müssen die Sicherheitsstandards wie folgt aussehen:

1. In die Entwicklungs- und Testumgebungen integriert.
2. Einheitliche Vorgehensweise von der ersten Entwicklung bis zur vollständigen Produktion.
3. Kontinuierlich auf die Einhaltung der Vorschriften getestet.

Entwicklungsprozesse müssen die unsichere Bereitstellung einer Workload in allen Phasen der Entwicklung und des Betriebs verhindern, um sicherzustellen, dass die Sicherheit nicht erst im Nachhinein berücksichtigt wird.