Verbinden von DevOps und Sicherheit mit DevSecOps Teil V

Ich lege ein weiteres Scheit Holz auf das Lagerfeuer um es am brennen zu halten.

In den vorangegangenen Posts habe wir die Entwicklung und den Betrieb automatisiert. Der letzte Schritt besteht nun darin , die Sicherheit mit zu automatisieren. Hier setzt DevSecOps an: Es integriert die Sicherheit in jedem Schritt der Entwicklung und der Freigabe an den Betrieb. DevSecOps umfasst das Testen, die Bereitstellung und die endgültige Auslieferung.

Verstehen der Sicherheit in DevOps

Ein beliebter Begriff ist „Security by Design“. Aber selbst „Security by Design“ muss in die Unternehmensarchitektur eingebettet werden. Das gilt auch für den DevOps-Zyklus: DevOps muss Sicherheit durch Design bieten. Bevor wir dies und Prinzipien wie Zero-Trust erörtern können, müssen wir zunächst ein gutes Verständnis der Sicherheit und ihrer Auswirkungen auf die DevOps-Praxis erlangen.

Entwicklung ist derzeit immer noch hauptsächlich Menschenarbeit. Menschen machen Fehler. Ist das das größte Risiko bei DevOps oder gibt es noch andere spezifische Risiken, die beachtet werden müssen?

Um die Frage zu beantworten, ob DevOps spezifische Risiken mit sich bringt: Ja. Die Implementierung von DevOps ohne Beachtung der Sicherheit erhöht definitiv das Risiko von Angriffen, da sich die Angriffsfläche der Systeme vergrößert. Es gibt drei Hauptthemen, die angesprochen werden müssen:

• Zugriffsverwaltung: DevOps-Teams verwenden wahrscheinlich Code-Repositories , auf die entweder Entwickler oder Tools manuell zugreifen. Der Code muss geschützt werden, selbst wenn er im Open-Source-Modus betrieben wird, un der Code wird gemeinsam genutzt, damit mehr Entwickler zum Code beitragen können. Selbst in diesem Fall möchten Unternehmen den Zugriff auf den Code regeln, damit er nicht an die Öffentlichkeit gelangt oder, schlimmer noch, bösartiger Code eingeschleust wird. Sie benötigen ein rollenbasiertes Zugriffsmodell für die Code-Repositories: Wer hat Lese- und Schreibrechte und wer hat vollem Zugriff - und aus welchen Grund? Behalten Sie den Überblick über die Konten. GitHub-Unternehmen können beispielsweise interne Repositories haben, auf die nur zugewiesene Mitarbeiter - oder Tools des Unternehmens - Zugriff haben. Innerhalb dieses internen Repository’s delegiert der Administrator die Rollen. Die Berechtigungsnachweise werden eintsprechend den Sicherheitsrichtlinien des Unternehmen festgelegt. Eine empfohlene Methode zur Zugriffskontrolle ist die Implementierung von Privileged Access Management (PAM). Aufgrund von DevOps müssen Teams mehr privilegierte Konten erstellen, die-entweder manuell oder automatisch - von Entwicklern und Tools gemeinsam genutzt werden. Zu diesen Konten gehören auch Dienstkonten, Verschlüsselungsschlüssel, SSH-Schlüssel und API-Zertifikate, die alle in den Repositories aufbewahrt werden. Ein unbefugter Zugriff auf diese Repository’s ist fatal. Eine PAM-Lösung bietet die Möglichkeit, jede Aktivität im DevOps-Zyklus zu autorisieren und zu überprüfen. Die meisten dieser Lösungen verwenden Schlüsseltresore, um die Zugangsdaten zu sichern und die Benutzer zu authentifizieren und zu autorisieren, bevor sie auf die Repositories zugreifen können.

• Fehlende Leitplanken und Richtlinien für eine DevOps-Arbeitsweise und - Tools: Der Zugang zu Code ist eine Sache, die nächste Frage ist: Was mach wir mit diesem Code? Es ist sehr unwahrscheinlich, dass Unternehmen den DevOps-Teams erlauben, neuen Code einfach zu commiten und in Produktion zu geben. Zuallererst muss sich das Unternehmen oder der Chefarchitekt - in den meisten größeren Unternehmen gibt es eine Gruppe führender Architekten - wirklich Gedanken über das bevorzugte Toolset machen. Es ist wichtig, dass jedes DevOps-Team dieses Toolset verwendet, anstatt Tools der eigenen Wahl zu implementieren, so verlockend das auch sein mag. Das Problem ist, dass die DevOps-Toolsets keinen gemeinsamen Standard für Sicherheitsrichtlinien, wie z.B. die Zugriffskontrolle, haben. Das ist etwas, das das Unternehmen selbst einrichten und umsetzen muss, was einfacher ist, wenn man sich für ein Toolset entscheidet. Das Gleiche gilt für die Arbeitsweise: Sie muss im gesamten Unternehmen einheitlich sein; das können wir gar nicht genug betonen. All dies muss in einer Liste bevorzugter Technologien und DevOps-Leitplanken und -Prinzipien definiert werden. In der Regel wird es einen Master-branch geben. Neuer Code wird zunächst in einen separaten Branch verschoben - oft als Funktionszweig bezeichnet -, wo er getestet wird. Nach dem validierten, positiven Testerergebnissen wird der Code mit dem Master-Branch zusammengeführt. Der Mastercode oder Hauptzweig wird wiederum im Repository gespeichert.

Zusammengefasst geht es bei der DevOps-Sicherheit um drei Themen:

• Nachvollziehbarkeit: Verfolgen Sie jede Aktion im DevOps-Zyklus und in den Pipelines.

• Überprüfbarkeit: Stellen Sie sicher , dass die in DevOps entwickelten Systeme mit den Sicherheitsstandards des Unternehmens und den Branchen-Frameworks, denen das Unternehmen unterliegt, konform sind.

• Sichtbarkeit: Es müssen solide Überwachunssysteme eingerichtet werden.

---

DevSecOps erfahren werden

Sicherheit beginnt mit dem Zugang zu den Rexpository, der Codequelle, an der der DevOps-Zyklus beginnt. Wie wir bisher gelernt haben, wollen wir so viel wie möglich bei der Entwicklung, den Test und der Bereitstellung automatisieren. Durch die Einführung von DevOps wollen Unternehmen die Entwicklung und Bereitstellung neuer Anwendungen und Funktionen beschleunigen. Geschwindigkeit und Agilität können zu Sicherheitsrisiken führen, da der Code nicht ausreichend getestet wird oder, schlimmer noch, ohne die Anwendung der richtigen Sicherheitsrichtlinien in die Produktion überführt wird, um Zeit zu gewinnen.

Sicherheit muss in DevOps eingebettet sein - Entwicklung und Bereitstellung werden so zu einer gemeinsamen Aufgabe von Entwicklern, Betreibern und Sicherheitsingenieuren. Die Sicherheit liegt nicht nur in der Verantwortung des Sicherheitsteams, sondern des gesamten DevOps-Teams.

Ausgangspunkte für DevSecOps

Die Sicherheitsüberprüfung beginnt , sobald der Code aus den Repositories gezogen wird. Als erstes muss ein rollenbasierten Zugriffsmodell (RBAC) auf das Repository angewendet werden. RBAC definiert, wer Zugriff hat und auf welcher Ebene. Darf eine Identität den Code nur ansehen, oder wird der volle Zugriff gewährt, um Code zu ziehen, zu ändern und dem Repository hinzuzufügen? Beachten Sie, dass es sich dabei nicht unbedingt um eine Person handeln muss. Auch DevOps-Tools sind Identitäten, und Sie müssen sich Gedanken über den erforderlichen Zugriff auf diese Tools machen.

Während des gesamten DevOps-Zyklus wird der Code ständig überprüft, gescannt und auf Schwachstellen getestet.

Der größte Vorteil der Einbettung von Sicherheit in DevOps ist die Tatsache, dass wir auch automatisierte Überprüfungen durchführen und sogar Patches und Korrekturen anwenden können, sobald eine Schwachstelle entdeckt oder bestätigt wird. Wenn beispielsweise eine neue Version einer Codebasis Patches für häufige Schwachstellen und Gefährdungen (Common Vulnerabilities and Exposures, CVEs) enthält, kann dies in die Sicherheits-Baseline aufgenommen und in die Sicherheitsverfahren integriert werden. Der Cide wird automatisch gegen diese neue Baseline geprüft.

DevSecOps mit Containern

Eine wachsende Zahl von Unternehmen arbeitet mit Containern für die Codeverteilung. Genau wie virtuelle Maschinen müssen auch Container den Sicherheitsrichtlinien entsprechen. Unternehmen werden wahrscheinlich gehärtete Container verwenden und Richtlinien für die folgenden Punkte festlegen:

• Abgesicherte Host-Betriebssysteme: häufig handelt es sich dabei um Linux-Betriebssysteme, die den Host vor Angriffen durch infizierte Container schützen.

• Sicherheitsrichtlinien für die Container-Laufzeit: Festlegen spezifischer Berechtigungen für das Einhängen von Containern, privilegierte Container, Deaktivieren von SSH in Containern, Einstellungen für die Bindung von Ports und die Freigabe von Ports.

Architektur für DevSecOps

Wie alles im Bereich der Unternehmens-IT erfordert auch DevSecOps eine architektonische Grundlage.

DevSecOps besteht aus drei Ebenen:

• Kultur: Dies ist keine technische Ebene, aber es wird oft vergessen, dass DevOps viel mehr ist als nur die Anwendung von Tools und die Erstellung von CI/CD-Pipelines. Dasselbe git natürlich auch für DevSecOps. Im Rahmen von DevSecOps fühlt sich jedes Teammitglied für die -Sicherheit verantwortlich und handelt entsprechend, indem es die Verantwortung dafür übernimmt. Das Bedeutet jedoch ich, dass Sicherheitsspezialisten obsolet geworden sind. Es ist keine gute Praxis, einen Sicherheitsingenieur oder -Fachmann im Team zu haben, der manchmal auch als Sicherheitschampion bezeichnet wird. Diese Person muss alle Prozesse im Hinblick auf die Anwendung von Sicherheitsstandards und- Richtlinien leiten und die Einhaltung der Vorschriften sicherstellen.

• Sicherheit durch Design: Die Sicherheit ist in jede Ebene des Systems eingebettet. Dies bedeutet in der Regel, dass ein Unternehmen über ein definierte Architektur verfügt , die alle Aspekte der Sicherheit und der Durchsetzung von Sicherheitsmaßnahmen auf Systemen abdeckt: Authentifizierung, Autorisierung, Vertraulichkeit, Datenintegrität, Datenschutz, Verantwortlichkeit und Verfügbarkeit, einschließlich Abhilfemaßnahmen und Korrekturmaßnahmen, wenn Systeme angegriffen werden. Softwareentwickler müssen nicht jedes Mal an die Sicherheit denken, wenn sie neue Anwendungen oder Funktionen entwerfen und erstellen - die Sicherheitsmaßnahmen werden bereits zu Beginn der Entwicklung angewendet. Die Sicherheitsarchitektur, Rahmenwerke , Regeln und Standards werden zentral verwaltet.

• Automatisierung: Bei DevSecOps wollen wir so viel wie möglich automatisieren, und dazu gehört auch die Sicherheit. Der Grundgedanke für die Automatisierung der Sicherheit ist, dass wir menschliche Fehler vermeiden können und auch automatisierte Mautstellen haben, an denen der Code auf mögliche Schwachstellen oder nicht konforme Komponenten wie nicht lizenzierten Code gescannt wird. Der Sicherheitsverantwortliche übernimmt auch die Verantwortung für die Automatisierung der Sicherheit , tut dies aber gemeinsam mit dem Team. Automatisierung bedeutet auch automatische Audits und die Sammlung von Beweisen im Falle von Agriffen oder Verstößen. Als Nächstes sorgt der Automatisierungsprozess dafür , dass Sicherheitsmetriken gesammelt und als Feedback an die DevSecOps-Praxis zurückgesendet werden. Wenn beispielsweise beim Scannen eine Schwachstelle im Code entdeckt wird oder eine Lizenz verletzt wurde, werden Beweise gesammelt und zur Rückmeldung weitergeleitet.

Um diese Schichten zu verwalten, stützt sich DevSecOps auf die folgenden Komponenten:

• Nutzung von Repositories

• Sicherheit der Anwendung (Code)

• Sicherheit der Cloud-Plattform

• Schwachstellenbewertungen und Tests

Erstellung der Referenzarchitektur

Bevor wir die ReferenzArchitektur von DevSecOps erörtern, müssen wir verstehen, was die Rolle von DevOps ist und wie sich die Sicherheit einfügt. Bei DevOps geht es um den Lebenszyklus der Softwareentwicklung. Eine wichtige Feststellung, die wir machen müssen, ist die Tatsache , dass Entwickler zunehmend Open-Source-Komponenten verwenden. Das ist sinnvoll, da dies eine große Flexibilität bei der Entwicklung von neuem Code bietet.

Open Source ist Gemeinschaftsorientierung, so dass Entwickler gegenseitig zu ihrem Code beitragen und den Prozess beschleunigen können. Projekte können und werden in offenen Git- und GitHub-Repositories, aber auch intern in Unternehmen gemeinsam genutzt. Projekte vom Typ InnerSource-Projekte nutzen in der Regel abgeschirmte , Zugangsbeschränkungen Repositories auf GitHub oder ähnlichen Plattformen.

Dennoch gibt es einige Risiken im Zusammenhang mit Open Source, die aus der Sicherheitsperspektive betrachtet werden müssen. Aufgrund des offenen, gemeinschaftlichen Charakters - die Stärke von Open Source - besteht ein erhöhtes Risiko , Schwachstellen in die Codebasis einzubringen. Ein zweites Risiko ist die Einhaltung von Lizenzen. Lizenzen stehen bei Open Source nicht ganz oben auf der Tagesordnung , aber seien Sie sich bewusst , dass auch OpenSource-Software und- Tools lizenziert werden müssen.

Schauen wir uns zunächst den Prozess an. Der Lebenszyklus der Softwareentwicklung ist ein sich wiederholender Prozess. Der Entwickler zieht den Quellcode aus einem Repository, und ein Build wird ausgelöst. Nachdem der Code geschrieben wurde, wird er verpackt und für den Einsatz in der nächsten Phase des Beförderungspfads freigegeben, d.h. Test, Abnahme und schließlich Produktion. Der gesamte Prozess wird durch CI/CD-Pipelines erleichtert und überwacht.

In der Tat brauchen wir Sicherheit von Beginn des DevOps-Prozesses an. In der Praxis bedeutet das, dass wir ab dem Moment, in dem der Code aus den Repositories gezogen wird, nach S_cherheitsproblemen suchen. Die Repositories sind in der Tat auch Teil des Lebenszyklus der Softwareentwicklung, so dass sie vor unbefugtem Zugriff geschützt werden müssen. Dies erfordert eine rollenbasierten Zugriffskontrolle (RBAC) und ein Identitäts und Zugriffsmanagement (IAM) für Repository’s.

Vor diesem Hintergrund können wir die ReferenzArchitektur für DevSecOps mit den folgenden Komponenten erstellen:

• Repository-Zugriff mit RBAC

• Statische Anwendungssicherheitstests (SAST): Damit werden Fehler im Quellcode aufgespürt.

• Software Prüfung der Anwendungssicherheit (DAST): Hierbei wird der Code dynamisch gescannt

Diese Komponenten sind in die DevSecOps-Pipeline eingebettet.

Zusammenstellung der DevSecOps-Pipeline

Schauen wir uns zunächst die gängige DevOps Pipeline an.

Die grundlegenden Schritte in der Pipeline sind wie folgt:

• Code aus dem Repository ziehen

• Build

• Test

• Deploy

Bei DevSecOps betten wir die Sicherheit in die Pipeline ein und machen Sicherheitsstandards und - Richtlinien zu einem integrierten Bestandteil der Pipeline. Die Sicherheit ist eine Schicht , die auf jeden Schritt in der Pipeline angewendet wird, aber sie umfasst mehrere Schritte.

Diese Schritte sind wie folgt:

Überprüfung der Abhängigkeiten:

Zunächst sollte jede Schwachstelle beseitigt werden, die den Code dem Risiko eines Angriffs aussetzt. Dazu gehört auch Code, der von anderen Teilen des Codes abhängig ist, um ausgeführt werden zu können. Es gibt Unterschiede bei Code-Abhängigkeiten:

Entwickler können kontrollierte und unkontrollierte Abhängigkeiten haben. In der Regel wollen wir keine Abhängigkeiten in unserem Code. Das Risiko besteht darin, dass, wenn der Code, auf den sich die Abhängigkeit stützt, verletzt wird oder die Funktion dieses Codes unterbrochen wird, die gesamte Anwendung ausfällt. Oder Malware, die in ein bestimmtes Codestück eingeschleust wird, aber eine Abhängigkeit zu anderem Code hat, infiziert den gesamten Codestapel. Daher lautet die Grundregel, Abhängigkeiten zu eliminieren - dies ist eines der Grundprinzipien von Zero Trust-Architektur.

Statische Analyse: Diese prüft auf schlechte Kodierungspraktiken, wie z.B. schlechte Konfigurationen. Es gibt Open-Sioruce-Tools für fast jede Programmiersprache. Einige Beispiele für Tools sind folgende:

• ArchUnitNet und Puma Scan für C#

• Go Vet für Go

• Checkstyle und Open Web Application Security Project (OWASP) Abhängigkeitsüberprüfungen für Java

• Flow für JavaScript

• Parse für PHP

• Bandit für Python

Scannen: Die Entwickler werden wahrscheinlich Container und damit Container-Images verwenden, um ihre Anwendungen zu erstellen und zu verpacken. Diese images müssen auf Schwachstellen in den verwendeten Binärdateien und Bibliotheken gescannt werden. Diese Überprüfung erfolgt anhand von Basislisten bekannter Schwachstellen; diese Listen werden von Instituten wie dem Nation Institute of Standards and Technology (NIST), aber auch von Softwareanbietern in Form von CVE-Meldungen (Common Vulnerability and Exporsures) bereitgestellt. Sobald eine neue CVE gemeldet wird, werden die Listen aktualisiert , und die Scan-Tools werden automatisch aktualisiert und veranlassen eine erneute Überprüfung .

Dynamische Analyse: Bei Webanwendungen können Entwickler einen automatisierten Scan der Webanwendung durchführen, um nach fehlerhaften Headern oder fehlenden Token für Cross-Site Request Forgery (CSRF oder XSRF) zu suchen. Diese Token verhindern die Ausnutzung von nicht autorisierten Befehlen, die von einem vertrauenswürdigen Benutzer kommen - dies kann auch eine Funktion auf einer anderen Website sein. Diese automatisierten dynamischen Scans können in die Pipeline integriert werden.

Verwendung gesicherter Container in der Pipeline

Die meisten Entwickler verwenden Container, um ihren Code zu verpacken und bereitzustellen, in der Regel Docker-Container. Für die Verwendung und Sicherung von Containern gibt es einige bewährte Verfahren. Um die Konsistenz und Sicherheit von Containern aufrechtzuerhalten, sollten sie regelmäßig gescannt werden, auch wenn die Anwendung einen stabilen Zustand erreicht hat und Updates weniger häufig durchgeführt werden oder die aktive Entwicklung eingestellt wurde. Wenn die Anwendung noch mit den ihr zugrunde liegenden Containern läuft , in denen die verschiedenen Anwendungskomponenten untergebracht sind, müssen diese Container gescannt werden, da immer die Möglichkeit besteht, dass eine Abhängikeit eine neue Schwachstelle schafft.

Anwendungen, die aus Containern bestehen, werden durch Dockerdateien definiert .

Lining - die Analyse des Codes auf Fehler oder schlechte Syntax im Code - kann verwendet werden , um einen Static Code Analyzer (SCA) der Dockerdateien durchzuführen und sicherzustellen, dass diese Dateien sicher bleiben. Ein beliebtes Lining-Tool für diesen Zweck ist Haskell Dockerfile Linter (Hadolint).

Verwaltung von Geheimnissen

Datenbankanmeldeinformaitonen, API-Schlüssel, Zertifikate und Zugriffstoken müssen stets an einem sicheren Ort aufbewahrt werden. Daran ändert auch die Verwendung von CI/CD und Containern nichts. Es wird dringend empfohlen, einen Tresor außerhalb der Repositories zu verwenden, auf die die Pipelines für CI/CD zugreifen. Die besten Praktiken für die Verwaltung von Geheimnissen lauten wie folgt:

• Verschlüsselung im Ruhezustand und bei der Übertragung. Es werden AES-256-Verschlüsselungsschlüssel empfohlen.

• Geheimnisse, wie z.B. Schlüssel, dürfen niemals Git/GitHub-Repositories gespeichert werden.

• Es wird empfohlen, Geheimnisse über eine sichere Zeichenkette als Umgebungsvariable in die Anwendung zu injizieren.

Arbeiten mit DevSecOps unter Verwendung der Industry Security Framework

Ein wichtiges Artefakt im Bereich Sicherheit - und DevSecOps - sind Sicherheitsrahmenwerke. Es gibt allgemeine Rahmenwerke , wie z.B. das Center for Internet Security (CIS) , aber in der Regel müssen Branchen spezifische Sicherheitsstandards einhalten und über deren Einhaltung berichten. Diese wirken sich auf die Art und Weise aus, wie Sicherheit in Unternehmen gehandhabt wird, und damit auch auf die Implementierung von DevSecOps.

Verständnis des Sicherheitsrahmens der Branche

IT-Umgebungen in Unternehmen sind nicht länger monolithische Systeme, die im Keller eines Unternehmens stehen und als Rechenzentrum des Unternehmens fungieren. Heute teilen sich IT-Umgebungen verschiedene Komponenten und sind über Internetverbindungen mit der Außenwelt verbunden. Das bedeutet , dass die Systeme standardmäßig über das Internet zugänglich sind. Dennoch sollten nur autorisierte Benutzer auf diese Systeme zugreifen können. Daher benötigen wir einige starke Verteidigungsmaßnahmen, um die Systeme vor Sicherheitsverletzungen zu schützen.

Das erforderliche Maß an Sicherheit ist je nach Branche unterschiedlich. In erster Linie müssen Finanzinstitute sicherstellen , dass Bankkonten nicht kompromittiert werden können und dass keine illegalen Geldtransfers stattfinden. Einrichtungen des Gesundheitswesens müssen die persönlichen und gesundheitlichen Daten ihrer Patienten schützen. Hersteller wollen ihr geistiges Eigentum und ihre Patente schützen. Vor allem aber gibt es mehrere übergreifende Grundsätze in Bezug auf die Sicherheit, den Schutz von Daten und Identitäten sowie die Absicherung von Systemen gegen Angriffe von außen.

Integration von DevSecOps mit DevOps

Bisher haben wir eine DevSecOps-Architektur entworfen, Prozesse identifiziert und diese dann mit den Geschäftszielen des Unternehmens abgestimmt. Der näschste Schritte besteht darin, all dies zu verwalten, und das ist das Thema der Governance.

DevSecOps ist nicht nur eine PowerPoint-Präsentation und ein Visio-Diagramm mit den CI/CD-Pipelines. Ein Unternehmen braucht qualifizierte Mitarbeiter , die damit arbeiten, und ein Governance-Modell, das das sichere digitale Betriebsmodell beschreibt.

In diesem Abschnitt werden wir dies anhand des IT4IT-Framework von The Open Group als Best Practice diskutieren.

In IT4IT ist Governance, Risk und Compliance (GRC) eine unterstützende Aktivität für die vier Wertströme. Dies bedeutet , dass GRC vollständig in jeden Wertstrom eingebettet ist. Was macht GRC?

Einfach ausgedrückt , geht es beim GRC darum, Ziele zu erreichen und gleichzeitig Unsicherheiten zu bewältigen, indem vereinbarte und akzeptierte Geschäftsrichtlinien der Branche angewendet werden. Jedes Unternehmen muss sich an bestimmte Richtlinien halten. Dabei kann es sich um internationale Vorschriften für den Handel , nationale Gesetze oder auch branchenspezifische Standards handeln. Dazu gehören auch Sicherheits- und Datenschutzbestimmungen. Die Implementierung von GRC ist keine einmalige Angelegeheit: Unternehmen müssen regelmäßig Anpassungen vornehmen. An dieser Stelle kommt das GRC-Fähigkeitsmodell ins Spiel. Dieser Modell ist im folgenden Diagramm dargestellt:

Dieser Modell besteht aus vier Elementen:

• Lernen: Die Ziele des Unternehmens müssen klar definiert sein, aber sie werden klar definiert sein, aber sie werden in den Kontext gestellt, in dem das Unternehmen tätig ist. Das Ziel eines Krankenauses besteht beispielsweise darin, die Gesundheit der Menschen zu verbessern; der Kontext is viel breiter gefasst und umfasst beispielsweise die Beziehungen zu Pharmaunternehmen und Krankenversicherungen. Die Ziele und der Kontext bestimmen die Strategie eines Unternehmens.

• Anpassen: Die Ziele des Unternehmens und potenzielle Bedrohungen , die die Strategie des Unternehmens gefährden, werden bewertet . Daraus ergeben sich Anforderungen und Gegenmaßnahmen, damit das Unternehmenseine Ziele erreichen und neue Chancen nutzen kann, während die Bedrohungen gemildert werden.

• Durchführen: Dies ist die Phase , in der unerwünschte Ereignisse erkannt und Maßnahmen ergriffen werden.

• Überprüfung: Das Unternehmen muss ständig überprüfen, ob die Bedrohungen rechtzeitig erkannt und angemessen bewertet wurden und ob die Abhilfemaßnahmen erfolgreich waren. Dies führt zu einem Lernprozess , da sich der Kontext ändern kann und die Strategie angepasst werden muss.

Die Implementierung und Verwaltung dieser Fähigkeiten erfordert eine entsprechende Steuerung. Ein Unternehmen muss Personen zuweisen, die diese Fähigkeiten auf verschiedenen Ebenen im Unternehmen kontrollieren. Dazu gehört auch die Integration von GRC-Funktionen in DevSecOps. Wie können wir ein Best-Practice-Governance-Modell einrichten?

Wir müssen uns die verschiedenen Ebenen im Unternehmen ansehen, und genau das tut IT4IT. Das folgende Diagramm zeigt die Grundprinzipien des Modells:

Modell für verschiedene Ebene der Sicherheitssteuerung im Unternehmen

• Unternehmensebene: Die Schlüsselrolle auf Unternehmensebene spielt der Unternehmensarchitekt, der für die Architektur im Unternehmen verantwortlich ist. Auf dieser Ebene wird der Unternehmensarchitekt mit dem Chief Information Officer (CIO) zusammenarbeiten. In modernen Unternehmen verändert sich die Rolle des CIO und es kommen weitere Rollen hinzu. Der Chief Digital Officer (CDO) un der Chief Data oder Chief Digital Officer (CDO) und der Chief Data oder Chief Privacy Officer tauchen immer häufiger in den Organigrammen auf. Der CDO ist eine wichtige Positionfür die Umsetzung der Strategie der digitalen Transformation, einschließlich der Einführung von DevSecOps. Beachten Sie, dass DevSecOps nie ein strategisches Ziel an sich ist: Es ist eine Methode, die die digitale Transformation begleitet.

• Wertströme: Die Unternehmensebene ist die strategische Ebene; die Wertströme sind die taktische Ebene; die Wertströme sind die taktische Ebene. Die entscheidenden Rollen auf dieser Ebene sind der Domain-Architekt udn der SecOps-Ingenieur. Sie müssen die Implementierung von übergreifenden DevOps-Architekturen und die Sicherheit in den verschiedenen DevOps-Teams überwachen.

• DevOps-Teams: Die goldenen DevOps-Regeln lauten: „Build it, you run it“ und “You break it, you fix it“. Das bedeutet nicht, dass es keine anderen Regeln - oder besser gesagt Richtlinien - in DevOps gibt. Ein Unternehmen strebt nach Konsistenz bei DevOps, und zwar über alle verschiedenen Teams hinweg . Diese Teams arbeiten zwar autonom, müssen sich aber dennoch an zentrale Richtlinien halten, die auf Unternehmensebene festgelegt und auf der Ebene des Wertstroms implementiert und verwaltet werden. Warum ist dies wichtig? Ein Unternehmensservice oder -Produkt kann sehr wohl aus Bausteinen aufgebaut sein, für die verschiedene DevOps-Teams zuständig sind. Wenn die Arbeitsweise , Richtlinien und Sicherheitsplanken nicht aufeinander abgestimmt sind , wird das Endprodukt oder der Dienst höchstwahrscheinlich nicht den Qualitätsstandards des Unternehmens entsprechen.

• Ermöglichende Teams: Dies sind die Teams , die sich um die Grundlage kümmern, z.B. die Hosting-Plattformen und die Repositories, die zur Speicherung von Artefakten verwendet werden. DevOps-Ingenieure und Entwickler müssen sich nicht um die Netzwerkeinstellungen auf der Plattform kümmern - diese werden von Enabling-Team vorgenommen.

Implementierung einer Zero-Trust-Architektur

Zero Trust bedeutet zunächst einmal wirklich Null Vertauen. Die Grundsätze des Null-Vertrauens haben in den letzten Jahren in der IT-Sicherheit stark an Bedeutung gewonnen, und das aus guten Grund. Angriffe kommen nicht nur von außen , sondern auch aus den internen Netzwerken von Unternehmen. Zero Trust setzt sich dafür ein , dass jeder Benutzer , oder vielleicht sogar jede Identität, authentifiziert wird, unabhängig davon , ob sich der Benutzer innerhalb oder außerhalb des Unternehmensnetzwerks befindet. Nach der Authentifizierung muss der Benutzer anhand von Sicherheitrichtlinien validiert und autorisiert werden, bevor der Zugriff auf Anwendungen gewährt wird. Der Datenzugriff sollte nur über überprüfte Anwendungen erfolgen, für die die Benutzer authentifiziert und autorisiert sind.

Zero Trust beginnt damit , dass man weiß , wer sich um Unternehmensnetzwerk befindet. An dieser Stelle ist ein wichtiger Punkt zu beachten: In der Cloud ist alles eine Identität.

Dabei kann es sich um einen echten Benutzer, eine Person, aber auch um einen Dienst handeln, der eine bestimmte Aktion ausführt. Außerdem haben Dienste bestimmte Rechte: Sie dürfen eine bestimmte Aktion ausführen oder einen bestimmten Datensatz abrufen und dürfen keine anderen Aktionen durchführen. Daher müssen alle Identitäten, oder genauer gesagt Konten, bekannt sein, und drüber hinaus muss klar sein, welche Rechte sie haben. Das bedeutet, dass ein Unternehmen alle seine Konten sowie deren Berechtigungsnachweise und Rechte ständig überwachen und validieren muss. Dies muss in Echtzeit geschehen.

Zero Trust bedeutet auch, dass ein Unternehmen Maßnahmen ergriffen hat, um zu verhindern, dass authentifizierte Benutzer mehr tun, als sie dürfen. Sie denken vielleicht daran , Konten mit den geringsten Rechten auszustatten, aber Sie müssen auch die Netzwerksegmentierung und die Beschränkung bestimmter Protokolle in Netzwerken in Betracht ziehen. Im Grunde müssen Sie alles berücksichtigen, was ein Konto enthält, damit es nur die Aufgaben ausführen kann, zu denen es berechtigt ist , und zwar an dem Ort , an dem das Konto berechtigt ist. Dies muss durch starke Identitäts- und Zugriffsverwaltungsrichtlinien (IAM) , Netzwerksegmentierung , externe und interne Firewalls, Gateways und strenge Routing-Richtlinien , wie z.B. deny all und allow only whitelisted addresses, durchgesetzt werden.

Die folgenden Grundsätze müssen in Zero Trust enthalten sein:

• Kontotypen udn Anmeldeinformationen basieren immer auf dem Prinzip der geringsten Berechtigung.

• Spezifizierte privilegierte Rechte und Regeln für die Anwendung dieser Rechte.

• Definierte Endpunkte für Dienste und Anwendung dieser Rechte.

• Definierte Endpunkte für Dienste und Anwendungen.

• Authentifizierungsprotokolle

• Die Sicherheitsüberwachung umfasst die Erkennung von Eindringlingen und die Erkennung von Anomalien.

• Härtung des Betriebssystems mit den neuesten Versionen und aktuellsten Patches.

• Software-Lebenszyklus mit den neuesten Versionen und den neuesten Patches.

Wie wirkt sich das auf DevOps aus?

Die Antwort auf diese Frage lautet: Zero Trust hat einen großen Einfluss auf DevOps und die agile Arbeitsweise . Bei DevOps geht es darum, die Entwicklung und Bereitstellung von Anwendungscode zu beschleunigen.

Diese erfordert Flexibilität und ein hohes Maß an Verantwortung für die DevOps-Teams. Es stimmt , dass sehr strenge Sicherheitregeln den schnellen Prozess der Entwicklung und Bereitstellung behindern können.

Die Konseqwuenz ist, dass auch DevOps-Teams sich an ZeroTrust halten müssen. Teams können nur Konten verwenden , die zum Zugriff auf die Code-Repositorys berechtigt sind, mit Builds arbeiten, die in einem bestimmten Segment des Unternehmensnetzwerks enthalten sind, nur zugelassene Betriebssysteme, Software und Tools verwenden und Sicherheitsrichtlinien anwenden, die durch Routing- und Firewall-Regeln durchgesetzt werden.

Zero Trust bedeutet jedoch nicht , dass der DevOps-Prozess standardmäßig verlangsamt wird. Das passiert nur, wenn die Verantwortung für die Anwendung von Zero Trust außerhalb des Teams liegt.

Architektur für Zero-Trust-Sicherheit

Mit einem guten Verständnis des Konzepts von Zero Trust können wir Architekturen definieren, die die Grundsätze von Zero Trust anwenden. Die folgenden Leitlinien helfen bei der Definition der Architektur.

• Bewerten und analysieren Sie alle Zugriffskontrollen. Strenge Richtlinien für IAM müssen vorhanden sein. Least Privilege muss Teil dieser Richtlinien sein. Dies ist laut dem National Institute of Standards and Technology (NIST) das Rückgrad von Zero Trust. Sie haben eine Reihe von Prinzipien für Zero-Trust-Architekturen definiert, die alle die Art und Weise von Prinzipien für Zero-Trust-Architekturen definiert, die alle die Art und Weise betreffen, wie Unternehmen mit IAM umgehen. Das wichtigste Prinzip ist eine einzige Quelle für Identitäten. In den meisten Fällen werden Unternehmen hierfür Active Directory (AD) verwenden. Kurz gesagt , jeder Benutzer oder jede Identität muss dem AD bekannt sein.

• Als nächstes muss eine starke Authentifizierung erfolgen. Ist die Identität wirklich die, die sie vorgibt zu sein? Eine Multi-Faktor-Authentifizierung (MFA) wird dringend empfohlen. NIST betont auch die Notwendigkeit, den Kontext, in dem Benutzer autorisiert und authentifiziert werden, zu verifizieren und zu validieren.

• Es müssen spezifische Zugriffsrichtlinien für Anwendungen festgelegt und kontrolliert werden. Ein Entwickler, der an einer Marketing-Website arbeitet, wird wahrscheinlich keinen Zugriff auf die Anwendung benötigen, die die Lieferkette eines Unternehmens steuert. In diesem Fall sollte der Zugriff auf diese Anwendung eingeschränkt werden. Zero Trust bedeutet also, dass für jede Anwendung eigene Richtlinien gelten: Wer darf auf sie zugreifen, in welchem Umfang und mit welchen Rechten?

• Datenklassifizierung und Datensicherheit sind die nächsten Bausteine einer Zero-Trust-Architektur. Daten müssen geschützt werden. Die Herausforderung in der modernen , cloudbasierten IT besteht darin, dass Daten überall sein können und über Plattformen, Anwendungen und Dienste hinweg gemeinsam genutzt werden. Unternehmen müssen genau wissen, wo sich ihre Daten befinden, um welche Art von Daten es sich handelt und wer oder was unter strengen Bedingungen auf sie zugreifen darf. Die Daten müssen identifiziert und klassifiziert werden: Sind sie beispielsweise vertraulich oder dürfen sie öffentlich zugänglich sein? Strenge Datenschutzvorschritften, wie die Allgemeine Datenschutzverordnung (GDPR) in der Europäischen Union, sind Richtlinien für die Klassifizierung von Daten; die Anwendung dieser Richtlinien liegt in der Verantwortung des Unternehmens.

• Das NIST und das National Cybersecurity Center of Excellence (NCCoE) definieren die vertrauenswürdige Cloud ebenfalls als einen Baustein. Das liegt an dem dynamischen Charakter, den Clouds von Haus aus haben. Jetzt befinden wir uns wirklich im Herzen von DevOps, wo wir nach der Regel autonom arbeitender Teams vorgehen, die Umgebungen in dem Moment, in dem sie die benötigen, aufsetzen, verändern und sogar löschen können. Diese Umgebungen werden Daten verwenden, aber einige dieser Umgebnungen sind vielleicht nur von kurzer Dauer, während andere schließlich in die Produktion überführt werden. Die Cloud-Technologie, bei der alles Code ist, macht dies möglich. Dies stellt eine große Herausforderung für die Sicherheit dar, insbesondere wenn es darum geht, die Umgebungen mit den Sicherheitsrichtlinien in Einklang zu bringen. Daher muss die Sicherheit in DevOps eingebettet werden. Die Überwachung sollte in Echtzeit erfolgen und Kontrollen ermöglichen, um jede Verletzung der Sicherheitsrichtlinien zu erkennen, auch wenn dies bedeutet, dass die Entwicklung dadurch gestoppt wird.