Politik als Kodex

Kapitel 1. Politik als Code: Eine sanfte Einführung

Diese Arbeit wurde mithilfe von KI übersetzt. Wir freuen uns über dein Feedback und deine Kommentare: [e-mail]

Schätzungen zufolge wurden in den letzten mehr als 60 Jahren mehr als 2,7 Billionen Codezeilen geschrieben. Wie viele Zeilen hast du geschrieben? Ich weiß nicht, wie viele Zeilen ich geschrieben habe, aber ich schreibe schon seit fast 30 Jahren Code. Erst in den letzten acht Jahren habe ich Policy as Code (PaC) eingesetzt, um Änderungen besser zu kontrollieren, mich durch komplexe Systeme und Lösungen zu führen und sicherzustellen, dass das, was ich schreibe, auch das ist, was ich schreiben, ausführen und verteilen will.

Unabhängig vom System oder Artefakt hat sich PaC als Standard dafür entwickelt, wie wir unerwünschte und nicht-deterministische Änderungen und Verhaltensweisen in den Systemen und Lösungen, die wir nutzen, erstellen und unterstützen, reduzieren. PaC ermöglicht es uns, die Richtlinien, die wir festlegen, befolgen und durchsetzen, zu kodifizieren. PaC hat seinen Nutzen von Kodierungsstandards und bewährten Methoden sowie von den Kontrollen zu deren Umsetzung.

PaC taucht heute in vielen Systemen und Lösungen auf und verbessert sie. Das reicht von Cloud Computing und Kubernetes bis hin zu Autorisierung (AuthZ), kontinuierlicher Integration/kontinuierlicher Bereitstellung(CI/CD), DevOps, DevSecOps, GitOps und Software Supply Chain Security. In diesem Buch gehe ich näher auf PaC ein und stelle Ideen, Muster und Beispiele vor, wie du PaC nutzen kannst, um deine Lösungen richtlinienfähig zu machen. In diesem Kapitel stelle ich dir PaC-Konzepte vor, zeige dir, wie du PaC aus deinen Standards ableiten kannst, und beschreibe die Merkmale von PaC, die dir bei der Auswahl der richtigen Lösung für deine Bedürfnisse helfen können. Am Ende des Kapitels wirst du einen Prozess und eine Checkliste haben, die du im Laufe dieses Buches anwenden kannst, um zu beurteilen, wie zusätzliche PaC-Lösungen zu deinen Bedürfnissen passen.

Was ist Politik?

Du befolgst jeden Tag Richtlinien. Richtlinien helfen dir, Entscheidungen im Kontext der Situationen zu treffen, in denen du tätig bist. Normalerweise basieren diese Richtlinien auf dokumentierten Regeln und Leitlinien. Du erklärst dich mit diesen Regeln und Richtlinien einverstanden, wenn du angestellt bist oder einer Organisation angehörst, in der du tätig bist. Politik ist nichts Neues für dich. Einfach ausgedrückt, ist eine Richtlinie ein geplantes System von Regeln und Richtlinien, das die Benutzer und die Automatisierung anweist, sich innerhalb bestimmter Grenzen zu bewegen. Richtlinien setzen Leitplanken, die sowohl aufklären als auch begrenzen.

Ich würde hinzufügen, dass wir mit der Politik versuchen, gewünschte Ergebnisse zu erreichen. Wenn du bei der Arbeit die Unternehmensrichtlinien befolgst, versucht das Management, die gewünschten Ergebnisse zu erreichen, z. B. indem es sicherstellt, dass du deine Abwesenheit von der Arbeit ordnungsgemäß dokumentierst und meldest.

Die Regulierungspolitik hat sich zu einer treibenden Kraft für die IT-Systeme entwickelt, die Unternehmen bedienen. Laut der Organisation für wirtschaftliche Zusammenarbeit und Entwicklung (OECD)"geht es bei der Regulierungspolitik darum, die Ziele der Regierung durch den Einsatz von Vorschriften, Gesetzen und anderen Instrumenten zu erreichen, um bessere wirtschaftliche und soziale Ergebnisse zu erzielen und so das Leben der Bürger und Unternehmen zu verbessern.

Die General Data Protection Regulation (GDPR) ist eine der bekanntesten neuen Datenschutzregelungen in der Europäischen Union (EU). Daher sollte die GDPR als treibende Kraft betrachtet werden, ebenso wie Regulierungsmaßnahmen im Allgemeinen.

Da sich die Politik in diesem Buch auf Informationstechnologiesysteme (IT) konzentriert, brauchen wir eine Definition der Politik, die sich mehr auf die IT konzentriert. Torin Sandall schreibt 2017 in seinem Medium-Artikel "What Is Policy? Part One: Enforcement" (Teil 1: Durchsetzung): "Im Kontext von Softwaresystemen sind Richtlinien die Regeln, die bestimmen, wie sich das System verhält."

Ich möchte hinzufügen, dass die Richtlinien auch bestimmen, wie sich die Akteure innerhalb dieser Systeme verhalten. Richtlinien definieren Regeln, und diese Regeln legen fest, wie sich Systeme verhalten und wie sie konfiguriert, für den festgelegten Zweck genutzt und gesichert werden.

Ein wichtiges Thema dieses Buches ist der Einsatz von Richtlinien und Richtlinienwerkzeugen, um unerwünschte Änderungen zu verhindern und bewährte Methoden in unseren Systemen und Artefakten durchzusetzen. Es ist nur logisch, dass wir eine Richtliniendefinition wählen, die unsere Bedürfnisse besser abdeckt.

Nachdem wir nun die Grundidee und den Zweck von Richtlinien verstanden haben, wollen wir sie als Code definieren.

Was ist Politik als Code?

Wie unter im Vorwort erwähnt, ist PaC die Verwendung von Code-Artefakten - Richtlinien - zur Verwaltung und Anwendung von Regeln und Bedingungen. Policy-Engines sind die Programme, die Policy-Artefakte interpretieren, um Policy-Entscheidungen unter Verwendung der oben genannten Regeln und Bedingungen anzuwenden. Die in den Richtlinienartefakten definierten Regeln und Bedingungen helfen uns, die von uns erstellten oder angenommenen organisatorischen Standards und Richtlinien umzusetzen. Diese Implementierungen - bekannt als Kontrollen - wendenEntscheidungen zu Sicherheit, Compliance, Governance und bewährten Methoden an, um unerwünschte Änderungen in den von uns unterstützten und genutzten Systemen zu verhindern oder darauf zu reagieren.

Auf der grundlegenden Ebene, während der Ausführung, um Entscheidungen zu treffen, beantwortet PaC Fragen - Fragen über Systeme, Artefakte, Szenarien und Situationen, die kontrolliert werden müssen. Mehr beantwortete Fragen bedeuten mehr implementierte Kontrollen. Mehr Kontrollen bedeuten mehr deterministische Verhaltensweisen, weniger unerwünschte Verhaltensweisen und weniger Überraschungen.

Im nächsten Abschnitt werden wir die Struktur und die Merkmale der Politik untersuchen.

Was ist eine Richtlinie?

Wir können eine Richtlinie einfach modellieren, indem wir sie in Teile zerlegen, die für unsere Zwecke sinnvoll sind. Auf einer hohen Ebene besteht unser Richtlinienmodell aus den folgenden Teilen:

Name der Politik

Dient zur Kennzeichnung der Police für die spätere Bezugnahme

Zweck der Politik

Der Grund, warum es diese Richtlinie gibt, und was sie durchsetzen oder angehen soll

Politische Situation

Der Kontext (einschließlich System und Umgebung), in dem die Richtlinie angewandt werden soll

Politische Regeln

Individuelle Kontrollen oder vorgeschriebene Verhaltensweisen; Richtlinien können mehrere Regeln haben

Politische Maßnahmen

Maßnahmen, die ergriffen werden, wenn gegen eine Regel verstoßen wird (nicht immer Teil der Policy Engine)

Als Nächstes werden wir die Merkmale der Politiken, die sie so nützlich machen, und die Politiksprachen, die sie verwenden, genauer untersuchen.

Merkmale der PaC-Politik

Im Kontext von PaC haben Richtlinien weitere Eigenschaften, die sie in IT-Systemen nützlich machen. Erstens werden PaC-Richtlinien als Code-Artefakte geschrieben, gespeichert, verwaltet und interpretiert. Das macht es einfacher, sie zu verwalten und mit denselben automatisierten Tools und Prozessen, die du bereits für die Anwendungsbereitstellung verwendest, auf Systemen zu verteilen.

Ein weiterer wichtiger Aspekt von PaC-Richtlinien, unabhängig von der zugrunde liegenden Implementierung, ist ihre syntaktische Vertrautheit. Wie du später sehen wirst, wenn du die einzelnen PaC-Lösungen genauer unter die Lupe nimmst, fördern unterschiedliche Policy-Sprachen die Akzeptanz von PaC. Wenn dein Unternehmen z. B. über umfangreiche JavaScript-Fähigkeiten verfügt, könntest du eine PaC-Lösung wählen, die auf der Sprache JavaScript basiert.

Die Vertrautheit mit den PaC-Richtlinien oder ihren Konfigurations-Wrappern trägt dazu bei, dass sie angenommen werden. Je vertrauter mir die Sprache der PaC-Richtlinien oder der Konfigurations-Wrapper ist, desto intuitiver ist die Lösung in der Regel. Wie vertraut oder intuitiv eine Sprache - oder ein Lexikon - für mich ist, ist jedoch subjektiv und basiert auf meinem Wissen und meiner Erfahrung. Vielleicht hast du andere Vorstellungen davon, wie vertraut und intuitiv die Sprachen sind, die du verwendest oder bevorzugst. Vielleicht entscheidest du dich für PaC-Lösungen mit deklarativen Policy-Sprachen oder für Sprachen, die eher imperativ oder sogar assertionsbasiert sind.

Unabhängig von der gewählten Policy-Sprache sind die Eingaben, die PaC verarbeitet, auswertet und ausgibt, in der Regel eher deklarativ und strukturiert. Je deklarativer und strukturierter die Artefakte sind, desto zuverlässiger kann PaC sie auswerten. Zu diesem Zweck werden wir untersuchen, warum JSON und YAML in PaC-Lösungen so beliebt sind.

Die Rolle von JSON und YAML

Ich denke, wir sind uns alle einig, dass JSON und YAML zwei der deklarativsten und intuitivsten Datenformate sind, die in modernen IT-Systemen weit verbreitet sind. Tatsächlich nutzen viele Cloud Computing- und Kubernetes-Ingenieure diese Datenformate täglich, um ihre Konfigurationen in strukturierten Formaten zu definieren und zu deklarieren.

Es ist kein Zufall, dass PaC-Tools diese beiden Datenformate nutzen, um Richtlinien an Systeme zu übermitteln, Eingaben zu verarbeiten und Ausgaben bereitzustellen. Einige in der Branche sind der Meinung, dass PaC-Richtlinien, die in JSON oder YAML geschrieben oder verpackt sind, deklarativer, aussagekräftiger und sogar selbstdokumentierend sind. Auch wenn die PaC-Richtliniensprache, die in einer Policy Engine verwendet wird, nicht auf JSON- oder YAML-Datenformaten basiert, sind die Artefakte, die die Richtlinien auswerten, in der Regel JSON oder YAML. Strukturierte Daten sind einfach einfacher zu handhaben.

PaC analysiert und bewertet JSON- und YAML-Artefakte im Rahmen des Richtlinienabgleichs und der Bewertung. Daten, unabhängig davon, was sie darstellen, sind für PaC-Auswertungen besser geeignet, wenn sie in JSON oder YAML strukturiert werden können. JSON und YAML können sehr einfach ineinander und auseinander konvertiert werden. Schließlich können auch andere unstrukturierte oder weniger strukturierte Artefakte zur weiteren Verarbeitung durch PaC in JSON und YAML geparst werden.

Als Nächstes sehen wir uns an, wie wir unerwünschte Aktionen oder Änderungen vermeiden können, indem wir PaC nutzen, um Leitplanken zu errichten.

Leitplanken: Das Unerwünschte verhindern

Wie ich bereits im Vorwort dieses Buches erwähnt habe, habe ich in der Vergangenheit mit Unternehmen zusammengearbeitet, die PaC eingesetzt haben, um Grenzen für den Cloud Computing-Betrieb zu schaffen. Wenn es darum geht, unerwünschte Änderungen oder Verhaltensweisen durch Benutzer oder Automatisierung zu verhindern, wirken diese Grenzen wie Leitplanken. Wenn die Abläufe innerhalb der Leitplanken bleiben, so wie du normalerweise auf einer Autobahn fährst, dann sind diese Abläufe nicht eingeschränkt. Sobald die Vorgänge vom vorgeschriebenen Weg abweichen, gegen die von den Richtlinien festgelegten Regeln und Bedingungen verstoßen und versuchen, außerhalb der Leitplanken zu operieren, werden diese Vorgänge durch Kontrollen eingeschränkt, die von den Richtlinien erzwungen und umgesetzt werden.

Guardrails ermöglichen einen ungehinderten Fluss zwischen ihren Kanten. Beim Cloud Computing ändert sich die Infrastruktur schnell, um den Geschäftsanforderungen gerecht zu werden. Praktiker, die für Sicherheit, Compliance und Governance zuständig sind, errichten Leitplanken in Form von Kontrollen, um unerwünschte Verhaltensweisen zu verhindern, die das Unternehmen gefährden könnten. Unabhängig von der implementierten Kontrolle besteht ein starker Wunsch, den erlaubten Fortschritt nicht zu behindern.

Viele Unternehmen setzen Kontrollen ein, um festzulegen, wie die Recheninstanzen bereitgestellt werden. Dies hilft dabei, unerwünschte Änderungen zu verhindern, unabhängig von den Absichten oder der Erfahrung und dem Wissensstand der Nutzer. Zum Beispiel gibt es häufig Kontrollen, die verhindern, dass Compute-Instances mit öffentlichen IP-Adressen verknüpft werden. Die Kontrollen fungieren als Leitplanken. Anhand unseres Richtlinienmodells kannst du dir die Richtlinie für das Verbot von Compute-Instanzen mit einer öffentlichen IP-Adresse vorstellen (siehe Abbildung 1-1).

Abbildung 1-1. Richtlinienmodell: ComputePublicIP

Wenn du in diesem Beispiel Rechenleistung bereitstellst, können deine Aktionen uneingeschränkt fortgesetzt werden, solange du dich innerhalb der Leitplanken bewegst. Wenn du jedoch eine Rechenleistung mit einer öffentlichen IP erstellst, wird dein Fortschritt gestoppt und die Rechenleistung, die du bereitgestellt hast, wird deaktiviert oder sogar gekündigt. Abbildung 1-2 zeigt ein einfaches Aktivitätsdiagramm des Ablaufs.

Mit der Zeit lernst du durch Leitplanken den richtigen Fluss und wie du ohne Einschränkungen vorgehen kannst. Organisationen als Ganzes bewegen sich schneller und sicherer, wenn sie sich innerhalb vorgegebener Grenzen mit geringer Reibung bewegen.

Jetzt wollen wir sehen, wie wir PaC nutzen können, um das Unerwünschte zu verhindern, indem wir auf das Ungeplante reagieren.

Abbildung 1-2. Aktivitätsdiagramm der ComputeNoPublicIP-Richtlinie

Pläne: Reagieren auf das Ungeplante

Die Benutzer/innen nehmen ständig Änderungen an Systemen und Artefakten vor. Es ist fast unmöglich zu beurteilen, was sie als nächstes versuchen werden. Noch schwieriger ist es, die Handlungen von schlechten Akteuren einzuschränken. Es ist jedoch nicht unmöglich, zu bestimmen, was beide als Nächstes tun dürfen. Richtlinien, die von PaC-Engines durchgesetzt werden, bilden eine "Defense-in-Depth"-Strategie (DiD), die unabhängig von der Quelle der Veränderung eine zusätzliche Ebene von Gegenmaßnahmen schafft.

Betrachten wir zum Beispiel ein Szenario, in dem du einen Kubernetes-Cluster oder eine Sammlung davon betreibst und wartest. Selbst wenn die Nutzer/innen, die in deinem Cluster arbeiten, zu deinem Unternehmen gehören, hast du nicht immer die Kontrolle über ihren Code oder ihre Container-Images, die du brauchst, um zu verhindern, dass ihre Container die Integrität deines Clusters gefährden. Du kannst bestimmte Praktiken festlegen, um zu verhindern, dass sich ihre Container schlecht verhalten, wie z. B. Sicherheitseinstellungen, Netzwerkeinstellungen oder sogar, von wo Container-Images bezogen werden dürfen. Du kannst dich jedoch nicht darauf verlassen, dass die Nutzer/innen deine Anweisungen befolgen; außerdem verfügen sie vielleicht nicht über das nötige Kubernetes-Wissen. Stattdessen brauchst du Leitplanken.

Um der Möglichkeit entgegenzuwirken, dass unseriöser Code oder Container deinen Cluster überwältigen, brauchst du Richtlinien, die von Policy Engines unterstützt werden, die in Kubernetes integriert sind. Wir werden dieses Thema in späteren Kapiteln genauer untersuchen, aber für den Moment können die folgenden Beispiele für Basisrichtlinien implementiert werden:

• Begrenzung der Beschaffung von Container-Images nur von zugelassenen Registrierungsstellen

• Durchsetzung geeigneter Kubernetes-Sicherheitskontextelemente auf Pod- und Containerebene

• Verhindere unerwünschte Netzwerk-Eingänge und -Ausgänge von und zu Pods, indem du die entsprechenden Kubernetes-Netzwerkrichtlinien durchsetzt

• Verhindern, dass Pods das Netzwerk und die Ports des Hosts nutzen

• Verhindern, dass Pods Hostprozesse und Namensräume nutzen

• Durchsetzung von Requests und Limits für Container-Ressourcen

Alle vorangegangenen Richtlinien passen zu dem zuvor definierten Richtlinienmodell. Die Kombination der vorangegangenen Richtlinien mit Aktionen wie Verweigern oder Ändern kann unerwünschte Änderungen an Clustern und die Möglichkeit, dass Rogue Code Probleme verursacht, verhindern. Selbst wenn es in einem Container Rogue Code oder unerwünschte oder verirrte Binärdateien gibt, wird die Wahrscheinlichkeit, dass sie Schaden anrichten, verringert, wenn nicht sogar ausgeschlossen. Dies ist Teil einer DiD-Strategie, die sich auf das geringste Privileg konzentriert. Mit diesen Richtlinien erhalten die Container nur die Berechtigungen und Ressourcen, die sie benötigen, um korrekt zu funktionieren. Mit diesem Ansatz reagierst du tatsächlich auf Unvorhergesehenes.

Hinweis

PaC ist nur ein Teil einer erfolgreichen DiD-Strategie. Weitere Informationen über DiD findest du in der NIST SP 800-53.

Nachdem wir nun Politik und Richtlinien definiert und erörtert haben, wie sie dazu beitragen können, Unerwünschtes zu verhindern und auf Ungeplantes zu reagieren, müssen wir nun einen Gang höher schalten und untersuchen, wie Open-Source-Software eine Schlüsselrolle bei PaC spielt.

Die Einführung von Open-Source-Software

Wenn ich den Begriff Open Source Software (OSS) höre, denke ich an Software, die öffentlich zugänglich ist, so dass jeder den Code überprüfen oder sogar verändern kann. Natürlich unterliegt dies den OSS-Lizenzen und den Richtlinien und Vereinbarungen der Mitwirkenden. Ich denke auch an eine Gemeinschaft, und mit einer größeren Gemeinschaft von Projektentwicklern kommt die Möglichkeit einer größeren Stabilität und Sicherheit.

Die Mehrheit der PaC-Lösungen sind Open-Source-Projekte. Hast du jemals an einem OSS-Projekt gearbeitet oder dazu beigetragen? Wolltest oder musstest du jemals ein OSS-Projekt für deine Bedürfnisse übernehmen? OSS hat im Zusammenhang mit PaC bestimmte Vor- und Nachteile, und nicht alle OSS-Projekte sind gleich gut.

Meiner Meinung nach sind die beiden größten Vorteile von OSS die potenziellen Kosteneinsparungen, die sie bieten kann, und der Umfang der Beiträge. Viele OSS-Projekte und -Bibliotheken werden von Unternehmen genutzt, um den gesamten Entwicklungsaufwand zu reduzieren. Jemand anderes hat es bereits geschrieben, und wenn es für deine Bedürfnisse funktioniert, warum solltest du den Aufwand verdoppeln? Wenn alles gleich bleibt, kannst du mit OSS schneller vorankommen. Schneller voranzukommen, indem man den Entwicklungsaufwand reduziert, bedeutet in der Regel auch eine Kostenreduzierung.

Es liegt in der Natur der Sache, dass ausgereifte OSS-Projekte eine größere Anzahl von Betreuern und Mitwirkenden haben können. Das bedeutet, dass das Projekt von mehr Personen beobachtet wird und die Beiträge aus unterschiedlichen Perspektiven kommen. OSS-Projektbetreuer/innen leiten das Projekt und halten sich an die festgelegte Projektcharta und -richtung. Mitwirkende liefern Vorschläge und mögliche Änderungen und sind Multiplikatoren für OSS-Projekte; sie erhöhen die Effektivität der Projektaktivitäten.

Mehr Beteiligung bedeutet mehr Kontrolle und eine geringere Wahrscheinlichkeit, dass etwas übersehen wird. Das bedeutet zwar nicht, dass du die Artefakte des Projekts nicht überprüfen und verwalten musst, wie du es bei jedem anderen Softwareprojekt tun würdest, aber es erhöht die Wahrscheinlichkeit, dass größere Probleme früher erkannt und behoben werden.

Hinweis

Weitere Informationen über OSS-Maintainer und Mitwirkende findest du in dem Artikel "How Open Source Maintainers Keep Contributors-and Themselves-Happy" von Klint Finley bei The ReadME Project.

Neben der OSS-Projektreife ist eine kontinuierliche und gleichmäßige Projektdynamik der Schlüssel zu erfolgreichen OSS-PaC-Projekten. PaC-Lösungen sind am erfolgreichsten, wenn sie mehrere Anwendungsfälle lösen können. Das Lösen von Anwendungsfällen erfordert neue und aktualisierte Richtlinien und Integrationen. Mit anderen Worten: Die Projekte müssen weiter wachsen und mehr Probleme für mehr Nutzer lösen. Ohne Dynamik stagnieren PaC-Projekte - und OSS-Projekte im Allgemeinen - und die Nutzer suchen dann woanders nach Lösungen.

Jetzt, wo wir wissen, warum wir OSS nutzen sollten, wollen wir die Gleichung ausgleichen, indem wir einige der Nachteile von OSS betrachten.

Nachteile von OSS

OSS-Projekte sind sicherlich nicht ohne Nachteile und Risiken. Wenn ich es zulassen würde, könnte das Thema OSS-Risiken einen Großteil, wenn nicht sogar das ganze Buch einnehmen. Der bei weitem größte Nachteil von OSS ist der potenzielle Mangel an Unterstützung. Damit will ich nicht sagen, dass OSS-Maintainer und -Beitragende ihre Nutzergemeinschaft nicht unterstützen; meine Erfahrung ist eher das Gegenteil. Allerdings werden OSS-Wartung und -Beiträge in der Regel nebenbei erledigt; Maintainer und Mitwirkende haben neben den Projekten, die sie unterstützen, noch andere Jobs.

Es gibt zwar Ausnahmen, aber dieser Konflikt zwischen Aufträgen und Projekten schränkt natürlich ein, wie schnell Maintainer und Contributors auf Anfragen reagieren können. Für Organisationen, die an Enterprise-Support-Vereinbarungen gewöhnt sind oder die deterministischere Reaktionszeiten für Support-Anfragen benötigen, ist dies möglicherweise nicht praktikabel. Auch wenn es für einige OSS-Projekte Unterstützung durch Dritte gibt, ist dies nicht die Regel.

Wenn du ein OSS-Projekt nutzt und nicht zu den Maintainern gehörst, hast du keine endgültige Kontrolle über die Richtung des Projekts. Du musst entscheiden, ob dieser Mangel an Kontrolle, der durch einen begrenzten Einflussbereich ersetzt wird, deinen Bedürfnissen entspricht. In vielen Fällen ist das ein gangbarer Kompromiss.

Hinweis

Risiken sind ein weiterer möglicher Nachteil von OSS-Projekten. Weitere Informationen über OSS-Risiken findest du in den kürzlich veröffentlichten Top 10 Risks for Open Source Software von OWASP. Diese Liste umreißt die erheblichen Risiken von OSS-Projekten und basiert zum Teil auf den Ergebnissen des Open Source Security and Risk Analysis Report von Synopsys. Der Synopsys-Bericht nennt die folgenden allgemeinen OSS-Risikodaten:

• 89% der Codebases enthalten OSS, die mehr als vier Jahre veraltet ist

• 91% der Codebases enthalten Komponenten, die seit mehr als zwei Jahren nicht mehr neu entwickelt wurden

Zusammen bieten diese beiden Berichte wertvolle Einblicke in die Risiken von OSS-Projekten.

OSS ist nicht perfekt, aber wenn sie richtig eingesetzt wird, ist sie immer noch ein Enabler, wenn nicht sogar ein Kraftmultiplikator. Schauen wir uns nun einige der OSS-Aspekte genauer an, die wir bei der Entscheidung über den Einsatz von OSS-Projekten berücksichtigen sollten.

Die Pflege und Fütterung von OSS

Obwohl OSS Vorteile gegenüber intern entwickelten Projekten bietet, erfordert der Einsatz von OSS eine gewisse Sorgfalt und Fütterung. Die folgenden OSS-Themen sollten berücksichtigt werden:

Lizenzierung

Vergewissere dich, dass das OSS-Projekt, das du nutzen willst, eine Lizenz hat, die die Art und Weise, wie du es nutzen willst, erlaubt. Kannst du es notfalls fälschen? Die meisten Organisationen haben ein Open Source Program Office (OSPO), das festlegt, welche Lizenzen intern verwendet werden dürfen.

Sicherheit

Ist die Sicherheit in das Projekt integriert? Die OpenSSF Scorecard ist ein neues Instrument, um die Sicherheit eines OSS-Projekts zu bewerten.

Reifegrad

Wie ausgereift ist das Projekt? Wie viele und welche Arten von Versionen wurden bereits herausgegeben? Ist es allgemein verfügbar (GA)? Wie hoch ist die Anzahl der Bugs und der gewünschten Verbesserungen? Wie geht das Projekt mit Änderungen um?

Abhängigkeiten

Welche Abhängigkeiten hat das OSS-Projekt? Sind diese Abhängigkeiten dokumentiert? Sind sie sicher?

Aktive Unterstützung

Wie aktiv sind die Betreuer des OSS-Projekts, das du in Betracht ziehst? Wann wurden das letzte Mal Beiträge zu diesem Projekt geleistet? Werden regelmäßig Beiträge geleistet? Wie schnell werden Bugs oder Schwachstellen behoben? Könntest du das Projekt weiterhin unterstützen, wenn du das müsstest? Benötigt deine Organisation eine formellere Support-Vereinbarung für externe Software?

Projektleitung

Wohin soll das Projekt gehen? Macht dein Anwendungsfall für die Projektrichtung Sinn oder ist er nur ein Randfall?

Interne Fähigkeiten

Sind du oder dein Team mit der Technologie oder den Sprachen vertraut, die in dem OSS-Projekt verwendet werden? Könnt ihr alle den Code prüfen und genau entscheiden, ob er zuverlässig und für eure Zwecke geeignet ist? Verfügt ihr über die nötigen Systeme, um die OSS-Projektartefakte zu speichern, zu verwalten und weiterzugeben, damit sie in eurem Unternehmen sicher und zuverlässig verwendet werden können? Habt ihr die Werkzeuge, um Schwachstellen in der OSS gründlich und zuverlässig zu scannen und zu erkennen?

Tipp

Abgesehen von den kurzlebigen Forks, die für Pull-Request-Beiträge verwendet werden, sollten OSS-Projekte nur als letztes Mittel geforkt werden. Das Forken eines OSS-Projekts dient in der Regel dazu, das Projekt in eine andere Richtung zu lenken und es schließlich zu ersetzen.

Auch wenn die Not die "Mutter der Erfindung" (Platon) ist, führen verzweifelte Entscheidungen zu Fehlern und Missverständnissen. Wenn du dich aus irgendeinem Grund für OSS entscheidest, egal ob PaC oder nicht, dann nimm den ganzheitlichen Aufwand auf dich, der mit der Verwaltung der OSS-Artefakte verbunden ist, als ob du sie selbst entwickelt hättest. Wenn du mehr Einfluss auf das OSS-Projekt haben willst, solltest du einen Beitrag zu dem Projekt leisten oder es sogar betreuen, wenn es nötig ist.

Das Sponsoring von Projekten und Mitwirkenden ist eine Möglichkeit, OSS-Projekte über die aktive Beteiligung von Mitwirkenden oder Maintainern hinaus zu unterstützen. Wenn man bedenkt, wie viele OSS-Projekte in Softwareprodukten und -projekten von Unternehmen eingesetzt werden, gibt es nur wenig finanzielle Unterstützung für diese Projekte. Das Sponsoring von Projekten und Mitwirkenden ist eine gute Möglichkeit, der OSS-Projektgemeinschaft und den Projekten, von denen deine Produkte oder Projekte abhängen, etwas zurückzugeben.

Wenn deine Organisation einen OSPO hat, kannst du dessen Wissen und Erfahrung nutzen, um den Weg des geringsten Widerstands bei der Nutzung von OSS-Projekten zu beschreiten. Der OSPO hat das alles schon erlebt und ist damit beauftragt, deinem Unternehmen zu helfen, OSS erfolgreich und sicher zu nutzen.

Hinweis

Weitere Informationen über OSPOs und die Gemeinschaft der Praktiker findest du bei der Organisation Talk Openly Develop Openly (TODO).

Nach den OSS-Belangen wollen wir uns nun ansehen, wie PaC mit den Standards und Kontrollen deines Unternehmens zusammenhängt.

Standards und Kontrollen

Die meisten Organisationen haben Gruppen, die sich um Richtlinien und Standards kümmern, z.B. im Bereich Cybersicherheit. Diese Gruppen erstellen ihre eigenen Standards und übernehmen anerkannte Standards und bewährte Methoden von Organisationen wie der Cloud Security Alliance (CSA), dem Center for Internet Security (CIS) und dem National Institute of Standards and Technology (NIST). Weitere Standardisierungsgremien wie die Payment Card Industry (PCI) werden je nach Bedarf und Geschäftsschwerpunkt herangezogen.

Standards lassen sich in der Regel bis zu den Unternehmensrichtlinien zurückverfolgen. Der Unterschied zwischen Organisationsrichtlinien und Standards besteht darin, dass sich die Richtlinien in der Regel mehr auf die Vermittlung von Organisations- oder Managementabsichten konzentrieren, während sich die Standards in der Regel auf die spezifischen, messbaren Anforderungen konzentrieren, die in den Richtlinien enthalten und erforderlich sind.

Die in den Standards festgelegten Anforderungen werden von der Organisation befolgt. Um die Einhaltung der Standards zu regeln, zu verwalten und zu messen, setzen Unternehmen interne - und manchmal auch externe - Teams für Governance, Risk und Compliance (GRC) ein. GRC-Teams konzentrieren sich auf bestimmte Geschäftsbereiche und in manchen Fällen auf bestimmte IT-Systeme. Im Falle der IT arbeiten GRC-Teams mit System- und Technologieexperten zusammen, um die Kontrollen festzulegen, die zur Durchsetzung der Anforderungen erforderlich sind.

Ein Beispiel: Das Cloud-Engineering-Team deines Unternehmens verwaltet die Nutzung von öffentlichen Cloud-Diensten. Um ein sicheres und gut verwaltetes Cloud-Computing zu ermöglichen, arbeitet das Team mit GRC zusammen, um eine Reihe von Kontrollen zu definieren, die den Anforderungen der Unternehmensstandards entsprechen. Die KMU beraten GRC darüber, was in der Cloud möglich ist. Die Arbeitsgruppe, die durch die Zusammenarbeit von GRC und Cloud-Engineering-KMUs gebildet wird, verfolgt die Standards und die damit verbundenen Kontrollen anhand einer Matrix. In der Beispielmatrix für die Rückverfolgbarkeit von Kontrollen in Tabelle 1-1 ist die Kardinalität zwischen Standards und Kontrollen eins-zu-vielen. Standards können mehrere Kontrollen haben.

Tabelle 1-1. GRC-Kontrollen Rückverfolgbarkeitsmatrix

Standard	Schwerpunktbereich	ID	Kontrolle	Status
Nicht kundenorientierte Rechner sollten nicht direkt auf Endpunkte außerhalb des Unternehmensnetzwerks zugreifen.	Informationssicherheit - Cloud Computing	ISCC-1	Verhindern, dass öffentliche IP-Adressen an Computer zugewiesen werden	Genehmigt
	Informationssicherheit - Cloud Computing	ISCC-2	Verhindern, dass NAT mit privaten Subnetzen verbunden wird	In Entwicklung

Die KMUs im Cloud-Engineering-Team stimmen der Implementierung der Kontrollen zu und leiten die internen Bemühungen, die jeweiligen Kontrollen zu entwickeln, zu testen und einzusetzen. Die GRC-Teams sind Projektbeteiligte, die das Cloud-Engineering hinsichtlich der Anforderungen anleiten. GRC prüft die Kontrollen und bestätigt, dass die Kontrollen den Anforderungen entsprechen.

Das Cloud-Engineering-Team nutzt PaC, um die von der GRC-Arbeitsgruppe beschlossenen Kontrollen zu implementieren. Die PaC-Kontrollen geben Protokolle und Nachrichten aus, die als prüfbare Artefakte dienen, mit denen die KMUs gegenüber GRC nachweisen können, dass die implementierten Kontrollen die in den Anforderungen definierten Verhaltensweisen durchsetzen. Ebenso nutzt GRC die prüfbaren Artefakte, um das Management sowie interne und externe Prüfer zufriedenzustellen.

Im Modell dieses Beispiels gibt es eine Rückverfolgbarkeit von den allgemeinen Organisationsrichtlinien zu den fokussierten PaC-Richtlinien, die zur Umsetzung der Kontrollen verwendet werden. Das Pyramidenmodell in Abbildung 1-3 veranschaulicht die Hierarchie und die Eingrenzung des Fokus.

Abbildung 1-3. Rückverfolgbarkeit der Politik und Pyramide der Schwerpunkte

PaC-Richtlinien setzen Kontrollen durch, indem sie unerwünschte Änderungen und Verhaltensweisen verhindern und gewünschte Verhaltensweisen und Praktiken verstärken. Einfach ausgedrückt: PaC implementiert Kontrollen. Normalerweise stammen die Kontrollen, die durch PaC implementiert werden, aus Standards, die von deiner Organisation erstellt oder übernommen wurden. Diese Kontrollen sollten auch nachvollziehbar und überprüfbar sein.

Als nächstes werden wir untersuchen, wie PaC die Art und Weise verändert, wie wir Code-Artefakte nutzen und erweitern.

Politik als Code für alles als Code

In den letzten Jahren hat sich die Art und Weise, wie wir IT-Ressourcen bereitstellen und nutzen, gewissermaßen gewandelt: Wir sind zu Everything as Code (EaC) übergegangen und tun dies auch weiterhin. Viele der Prozesse , die wir jetzt zur Bereitstellung, Änderung oder Validierung von IT-Ressourcen nutzen, verwenden *-as-code Artefakte. Für viele von uns sind die Zeiten vorbei, in denen wir wochen- oder monatelang auf die Bereitstellung von Rechenkapazitäten warten mussten. Jetzt wählen wir sie sozusagen einfach an, indem wir Infrastructure-as-Code (IaC)-Artefakte wie JSON oder YAML oder sogar Terraform-Pläne über unsere öffentlichen oder privaten Cloud-Dienste anwenden. Mit Tools wie Tinkerbell können wir jetzt sogar Bare-Metal-Ressourcen bereitstellen.

Normalerweise gibt es zwar eine Konsole, über die wir unsere Ressourcen bereitstellen können, aber mit IaC haben wir die Möglichkeit, unsere Infrastrukturressourcen genauso zu verwalten wie unseren Anwendungscode. Wir verwenden jetzt Tools zur Quellcodeverwaltung, CI-Tools und sogar GitOps, um die Infrastruktur zu verwalten und anzuwenden. Und während wir IaC normalerweise deklarativ anwenden, haben wir jetzt sogar die Grenzen zwischen dem Imperativen und dem Deklarativen verwischt und die beiden mit Tools wie dem Cloud Development Kit (CDK) von Amazon Web Services (AWS) oder dem Cloud Development Kit for Terraform (CDKTF) von HashiCorp kombiniert.

Unabhängig davon, was du tust oder verwendest, wenn du es mit Code tun kannst, dann hast du mehrere greifbare Vorteile, die verloren gehen, wenn du Aufgaben manuell ausführst. Zum Beispiel kannst du die gleiche Single Source of Truth (SSOT) nutzen, die eine zentrale Quellcodeverwaltung bietet. Du kannst auch die Möglichkeiten der Zusammenarbeit nutzen, die EaC bietet. Die Werkzeuge und Prozesse wurden in jahrelanger Arbeit an der Quellcodeverwaltung verfeinert.

Die Verwendung und Bereitstellung von Artefakten als Code führt zu einer Verbesserung der Wiederholbarkeit, da die automatisierten Prozesse die Variabilität zwischen den Integrationen und Bereitstellungen verringern; da die Artefakte und Bereitstellungen Code sind, der von den zugrunde liegenden Systemen verstanden wird, wird auch die Skalierbarkeit mit deterministischem Verhalten verbessert.

Quellcode-Verwaltungs- und CI-Tools bieten Automatisierungen für die Verwaltung deiner *-als-Code-Artefakte. Du kannst sowohl das Testen als auch das Scannen des Quellcodes automatisieren. Mit automatisierten Tests und PaC wendest du Richtlinien auf den Code an, um Änderungen zu bewerten, bevor sie zusammengeführt werden dürfen. Mehr Automatisierung führt zu einer schnelleren Erkennung von Problemen und ermöglicht es dir, schneller fehlzuschlagen und erfolgreich zu sein, wobei die Ergebnisse deterministischer sind. Mit anderen Worten: Du erhältst mehr Wiederholbarkeit und Reproduzierbarkeit - und wie ich bereits gesagt habe, sind weniger Überraschungen generell eine gute Sache.

Die Anwendung von PaC auf deinen Quellcode hilft dir auch bei der Umsetzung von Compliance as Code (CaC). Bei CaC werden Compliance-Richtlinien als Tests verwendet und oft in CI-Pipelines eingesetzt, um *-as-code-Artefakte zu validieren, bevor sie für nachgelagerte Änderungen verwendet werden können.

Security as Code (SaC) ist mit CaC verwandt und kann auch von PaC profitieren. Jim Bird schreibt in seinem Buch DevOpsSec (O'Reilly): "Sicherheit als Code ist die Praxis, Sicherheit in DevOps-Tools und -Workflows einzubauen, indem man aufzeichnet, wie Änderungen an Code und Infrastruktur vorgenommen werden, und Orte findet, an denen Sicherheitsprüfungen, Tests und Gates hinzugefügt werden können, ohne unnötige Kosten oder Verzögerungen zu verursachen."

Durch die Kodifizierung der Sicherheit und der entsprechenden Richtlinien werden die Sicherheitseinstellungen von den nur für Menschen lesbaren Dokumenten befreit und in für Menschen und Maschinen lesbare Artefakte umgewandelt, wodurch die SaC-Artefakte ausführbar, nachvollziehbar und prüfbar werden.

Meiner Meinung nach setzt SaC, wie von Jim Bird definiert, PaC voraus. PaC kann verwendet werden, um die Artefakte zu bewerten und die Bescheinigungen zu erstellen, die von DevOps-Gates benötigt werden. Solange die Bescheinigungen (Beweise) von der PaC-Richtlinien-Engine geparst werden können (JSON, YAML usw.), ist PaC für diesen Anwendungsfall geeignet.

Mit der Zeit bilden die PaC-Richtlinien, die für CaC und SaC verwendet werden, Leitplanken, genau wie Testfälle für die testgetriebene Entwicklung (TDD). Die fortlaufende Automatisierung von Tests und PaC-Bewertungen erhöht die Zuverlässigkeit deiner Codebases und verhindert, dass unerwünschte Abweichungen in deine Produktionsumgebung gelangen. In Abbildung 1-4 ist dargestellt, wie CaC und SaC PaC für EaC nutzen.

Abbildung 1-4. CaC und SaC mit PaC für die Anwendung von Richtlinien auf EaC

Nachdem wir nun den Einsatz von PaC in der sich entwickelnden EaC-Landschaft erkundet haben, wollen wir uns nun den Engines und Sprachen zuwenden, die für unsere Bedürfnisse Richtlinien erstellen und ausführen.

Policy Engines und Sprachen

Als Teil einer PaC-Lösung übernehmen Policy Engines die schwere Arbeit, indem sie die Policy-Sprache interpretieren und die Daten auswerten. Bruce A. Fette schreibt in seinem Buch Cognitive Radio Technology, Second Edition (Academic Press): "Eine Policy Engine ist ein Programm oder ein Prozess, der in der Lage ist, maschinenlesbare Richtlinien aufzunehmen und sie auf einen bestimmten Problembereich anzuwenden, um das Verhalten von Netzwerkressourcen einzuschränken.

Mir gefällt diese Definition, da sie drei Merkmale enthält, die meiner Meinung nach PaC-Policy Engines richtig charakterisieren:

• Einlesen von maschinenlesbaren Richtlinien (PaC)

• Anwendung von Richtlinien auf bestimmte Problembereiche (Daten)

• Einschränkende Verhaltensweisen (Ergebnisse)

Eine Policy Engine nimmt die Richtlinie, die bei der Auswertung verwendet werden soll, die auszuwertenden Daten und die zu verwendende Abfrage auf. Dann wertet die Policy Engine die bereitgestellten Daten anhand der bereitgestellten Policy aus und gibt eine Antwort, die von dem System verwendet wird, in das die Policy Engine integriert ist oder das sie bedient. Richtlinien werden so geschrieben, dass sie mit den Daten, die sie auswerten, übereinstimmen; außerdem geschieht dieser Abgleich, bevor die Richtlinie die Daten auswertet und nach allen Eingabeprozessen, wie dem Parsing. Abbildung 1-5 zeigt ein Flussdiagramm des typischen Bewertungsprozesses einer Policy Engine.

Abbildung 1-5. Ablauf der Policy Engine Bewertung

Wenn in dem in Abbildung 1-5 dargestellten Fluss eine Richtlinie nicht mit den gegebenen Daten übereinstimmt, kann die Policy Engine ein undefiniertes oder leeres Objekt, einen Fehler oder sogar einen falschen Wert zurückgeben. Einige Policy Engines unterstützen die Möglichkeit, Richtlinien und unterstützende Daten asynchron zu laden, nicht nur während der Bewertungszyklen. Und es gibt Policy Engines, die sogar externe Daten als Teil des Bewertungszyklus abfragen.

Im Zusammenhang mit einer Policy Engine ist die Policy-Sprache die Sprache, in der die Policy geschrieben ist, nicht unbedingt die Sprache, in der die Engine geschrieben ist. Allerdings verwenden nicht alle Policy-Engines die gleichen Policy-Sprachen. In diesem Buch behandle ich unter anderem die folgenden Policy Engines und die dazugehörigen Policy Languages:

• Cloud Custodian (c7n)-YAML

• jsPolicy-JavaScript

• Kyverno-YAML

• MagTape-Rego

• Open Policy Agent (OPA)-Rego

• OPA/Gatekeeper-Regound YAML

Ich werde sie später genauer beschreiben, aber jetzt schauen wir uns erst einmal an, wie wir die richtige PaC-Lösung für unsere Bedürfnisse auswählen können, basierend auf der Sprache und anderen Faktoren.

Die Wahl der richtigen PaC-Lösung

Welche Policy Engine solltest du verwenden? Die Antwort auf diese Frage hängt von mehreren Faktoren ab. Es kann sogar sein, dass du einen Großteil dieses Buches lesen und mehrere PaC-Lösungen ausprobieren musst, bevor du diese Entscheidung treffen kannst. Die gute Nachricht ist, dass die Wahl der richtigen PaC-Lösung, derjenigen, die deinen Bedürfnissen am besten entspricht, nicht unbedingt eine Einbahnstraßenentscheidung ist. Vielmehr ist es nicht ungewöhnlich, dass Benutzer/innen mehrere PaC-Lösungen einsetzen; sie können in den Systemen, die sie bedienen, nebeneinander bestehen.

Die bewährte Methode zur Auswahl der richtigen PaC-Lösung beginnt mit Ehrlichkeit. Sei ehrlich zu dir selbst, deinem Team und deinem Unternehmen. Entscheide dich nicht einfach für die Lösung, die du für die coolste hältst oder die am meisten vermarktet, angenommen oder bekannt ist. Wähle die Lösung, die deine Auswahlkriterien am besten erfüllt - alle (oder zumindest die meisten) deiner Auswahlkriterien. Verstehe und definiere deine "Must-haves" gegenüber deinen "Should-haves" oder sogar deinen "Nice-to-haves". Eine Gewichtung der Auswahlkriterien ist für diesen Klassifizierungsprozess sinnvoll. Lege deine Auswahlkriterien so fest, dass sie die Bedürfnisse und Fähigkeiten deines Unternehmens widerspiegeln.

Kenne deine Anwendungsfälle ganz genau. Der nächste Schritt bei der Auswahl der richtigen PaC-Lösung für deine Bedürfnisse ist wohl die Abstimmung auf deine Anwendungsfälle. Dicht darauf folgt die Abstimmung der Nutzererfahrung (UX), die du brauchst, um eine möglichst breite Akzeptanz und Annahme in deinem Unternehmen zu erreichen. Ein Teil der UX-Anpassung besteht natürlich darin, deine Nutzer zu definieren und ihre Bedürfnisse zu verstehen. Die Übungen zum Abgleich von Anwendungsfällen und UX helfen dir, Fehlentscheidungen zu vermeiden, die zu einer unpassenden Lösung führen.

Versuche nicht, den Ozean mit deiner gewählten PaC-Lösung zum Kochen zu bringen. Nimm dich vor Kanten in Acht. Selbst wenn die PaC-Lösung, die du in Betracht ziehst, einen bestimmten Anwendungsfall abdeckt, der deinem Unternehmen Probleme bereitet, kann es sein, dass sie nicht die richtige Lösung ist, wenn es sich um einen Randfall handelt, der nicht auf breiter Basis angenommen oder unterstützt wird.

In den nächsten Abschnitten werde ich detailliert auf die Faktoren für die PaC-Auswahl eingehen, wie du deine Kriterien aufstellst und wie du datengestützte Entscheidungen treffen kannst, je nachdem, wie gut die Faktoren deine Kriterien erfüllen. Auch wenn die Entscheidung relativ leicht rückgängig gemacht werden kann, ist sie nicht ohne Kosten oder Auswirkungen auf das Geschäft. Deshalb ist es wichtig, die PaC-Auswahlfaktoren, die mit den Entscheidungen verbunden sind, mit deinen Auswahlkriterien abzustimmen.

Der folgende Abschnitt enthält eine nicht erschöpfende Liste möglicher PaC-Auswahlfaktoren. Diese Faktoren werden zusammen mit Anwendungsfällen und organisationsspezifischen Faktoren verwendet, um deine relativen Auswahlkriterien zu definieren und eine entsprechende Scorecard zu erstellen. Deine Scorecard ermöglicht es dir, fundierte, datengestützte Entscheidungen zu treffen. Denke daran, dass deine Entscheidungen den Einsatz mehrerer Lösungen bedeuten können; PaC-Lösungen schließen sich nicht unbedingt gegenseitig aus. Du kannst dich zum Beispiel für eine PaC-Lösung für Cloud Computing IaC entscheiden, während du eine andere PaC-Lösung für CI/CD oder Kubernetes nutzt.

Beispiel PaC Auswahlfaktoren

Bevor du dich für eine PaC-Lösung entscheidest , musst du die folgenden Faktoren berücksichtigen :

Ausrichtung - Organisatorische Fähigkeiten

Wie gut passen die von der PaC-Lösung verwendeten Technologien (Sprachen usw.) zu den technischen Fähigkeiten des/der Teams, das/die die Lösung einführen und verwalten wird/werden?

Organisatorische Strategien ausrichten

Wie gut passt die PaC-Lösung zu den internen Strategien, wie Werkzeuge und Anwendungen eingeführt und verwaltet werden sollen?

Angleichung - organisatorische Standards

Wie gut erfüllen die Kontrollen, die mit der PaC-Lösung aufgebaut werden sollen, zumindest teilweise die Anforderungen der internen Standards, die dieser Entscheidung zugrunde liegen?

Analyse/Protokollierung/Metriken

Wie gut bietet die PaC-Lösung angemessene Protokollierung, Metriken und Analysen, um interne Anforderungen, einschließlich Audits, zu unterstützen?

Automatisierung (CI/CD)

Kann die PaC-Lösung in CI/CD-Pipelines verwendet werden, indem sie vom Zielsystem nach links verschoben wird? Wenn ja, wie? Kann die Bereitstellung der Engine und der Richtlinien automatisiert werden?

Verfügbare Beispiele und Muster

Gibt es angesichts der von dir gewünschten Anwendungsfälle genügend Beispiele und Muster für Tests, Evaluierungen und Proofs of Concept?

Annahme durch die Gemeinschaft

Wer nutzt und unterstützt diese PaC-Lösung? Wie stark wurde das Projekt angenommen?

Komplexität

Wie schwierig ist es, diese Lösung in deiner Umgebung zu installieren und zu verwalten?

Dokumentation

Wie gut ist die Lösung dokumentiert? Wie verständlich ist die Dokumentation?

Betriebsarten

PaC-Lösungen unterscheiden sich darin, wie sie genutzt werden können (Server, Bibliotheken, CLI, etc.). Welche Betriebsarten werden unterstützt, und passen sie zu deinen Bedürfnissen und verbessern sie sogar deine Praxis?

Häufigkeit des Projekts

Wie aktuell sind die Beiträge und Änderungen an dem Projekt? Ist das Projekt noch lebensfähig?

Melden

Bietet die Lösung eine Berichtsfunktion? Verwendet sie Standard-Berichtstools oder lässt sie sich in diese integrieren? Wie gut unterstützt sie Datenaustauschstandards wie OSCAL?

Sicherheit

Welche Risiken und Schwachstellen gibt es in dem OSS-Projekt? Wie schnell werden Risiken und Schwachstellen normalerweise behoben? Welche automatisierten Tools und Prozesse werden eingesetzt, um Sicherheitsprobleme zu entdecken? Gibt es eine proaktive Sicherheitshaltung? Werden Commits signiert? Welche Sicherheitskontrollen gibt es in der Software selbst, z. B. Multifaktor-Authentifizierung (MFA) und Ähnliches?

Erweiterbarkeit der Lösung

Kannst du die Lösung mit Skripten, Sprachen oder Modulen erweitern? Wie einfach ist dieser Prozess?

Lösung/Projektreife

Hat die Lösung/das Projekt genug Iterationen durchlaufen? Ist es ausgereift genug, um operationalisiert zu werden? Gibt es Beispiele oder Unterlagen für die Umsetzung der Lösung?

Modell unterstützen

Wie gut wird die Lösung unterstützt? Kannst du bei Bedarf Unternehmenssupport erwerben?

Anwendungsfälle (IaC, Kubernetes, etc.)

Was sind die wichtigsten Anwendungsfälle, die von der Lösung unterstützt werden? Stimmen sie mit deinen Anwendungsfällen überein?

Benutzererfahrung

Wie einfach ist es, die PaC-Lösung zu nutzen? Ist sie intuitiv und vertraut? Wie viel Schulung ist für den Einsatz erforderlich?

Da wir nun die Auswahlfaktoren kennen, wollen wir uns ansehen, wie wir sie nutzen können, um unsere Auswahlkriterien zu erstellen und PaC-Lösungen zu bewerten.

PaC Auswahl Scorecard

Sobald du die Auswahlfaktoren definiert und verstanden hast, kannst du deine Auswahlkriterien ableiten und deine Scorecard erstellen (siehe Abbildung 1-6). Die Auswahlkriterien setzen sich aus den Auswahlfaktoren zusammen, die für deine Situation relevant sind und mit einer Gewichtung versehen werden. Die Faktorgewichtung gibt an, wie wichtig jeder einzelne Faktor für dein Unternehmen ist. Bei Faktoren, die keine Bedeutung haben, kannst du den Faktor entweder entsprechend gewichten (mit einer Null) oder ihn ganz aus der Scorecard streichen. Die Bewertung der Passung ist selbsterklärend; sie gibt an, wie gut das Auswahlkriterium für die PaC-Lösung zu deinen Bedürfnissen passt.

In der in Abbildung 1-6 dargestellten Scorecard enthält die Spalte Gewichtung die Werte 1-3, die angeben, welche der drei Klassifizierungen (Muss, Soll, Kann) auf die Auswahlfaktoren angewendet werden, um die für die Bewertung gewählten Auswahlkriterien zu bilden. Die Scorecard enthält Bewertungen für zwei Lösungen nebeneinander. Du multiplizierst die Fit-Spalten in jedem Bewertungsabschnitt mit der gemeinsamen Gewichtungsspalte, um die individuelle Punktzahl für jedes Auswahlkriteriumzu ermitteln. Die Spalte Passung verwendet die Werte 1-5. Um einen größeren Unterschied in den Bewertungen anzuzeigen, könntest du die Bereiche in den Spalten "Gewicht" und "Passung" größer wählen oder sogar die Basis-10-Zahlen durch Fibonacci-Zahlen ersetzen.

Mit diesem Scorecard-Ansatz kannst du die richtige Lösung für deine Bedürfnisse bewerten und auswählen. Mit der Scorecard hältst du deine datengestützten Entscheidungen fest, die auf deinen Bewertungen basieren. Deine Bewertungen stammen aus aktiven Tests und/oder Proofs of Concept. Bei OSS-Projekten können die jeweiligen Projektgemeinschaften wertvolle Unterstützung leisten und Einblicke in potenzielle Anwendungsfälle und die Projektausrichtung geben.

Abbildung 1-6. PaC Solution Selection Scorecard

Schließlich kannst du auch Diagramme verwenden, um deine Entscheidungen zu visualisieren und zu kommunizieren. Abbildung 1-7 ist ein Beispiel für ein Lollipop-Diagramm, das deine Gesamtbewertung übersichtlich darstellt, ohne die Details deiner Auswahlkriterien preiszugeben. Das ist ideal, wenn du dich an Interessengruppen wendest, die nur wenig Zeit oder Aufmerksamkeit haben. Für mehr Details würde ich ein Radardiagramm, ein Flächendiagramm oder sogar ein Radial-Lollipop-Diagramm vorschlagen.

Abbildung 1-7. Lollipop-Diagramm zur Darstellung der Gesamtpunktzahl

Da wir nun mit einer Methode zur Bewertung verschiedener PaC-Lösungen ausgestattet sind, möchte ich die Cloud Native Computing Foundation (CNCF) vorstellen und darauf eingehen, wie sie die Reife ihrer "akzeptierten" OSS-Projekte angibt.

Die Stiftung für Cloud Native Computing

Die CNCF ist Teil der Linux Foundation. Die CNCF ist ein Zentrum für quelloffene, herstellerneutrale Projekte, die von der CNCF akzeptiert wurden. Einer ihrer Schwerpunkte ist die Förderung der Cloud Native Adoption.

Laut der CNCF-Charta wurde die CNCF mit einer Mission gegründet: "Cloud Native allgegenwärtig zu machen". Was ist Cloud Native Computing (CNC)? Es steht dir frei, die CNCF-Definition von Cloud Native Computing in Ruhe zu lesen.

Für mich beschreibt die CNCF-Definition von CNC Technologien, die wir für eine nachhaltige, moderne Anwendungsentwicklung und -bereitstellung nutzen. Einige der CNCF-Merkmale, die ich für dieses Buch am wichtigsten und relevantesten finde, sind:

• Automatisierung

• Cloud Computing (öffentlich, privat und hybrid)

• Häufige und deterministische Änderungen

• Unveränderlichkeit

• Verwaltbarkeit

• Beobachtbarkeit

• Skalierbarkeit

• Sicherheit

CNC-Technologien sind für die meisten Unternehmen wünschenswert. Selbst mit der CNC-Definition fällt es Organisationen oft schwer, CNC-Projekte und -Technologien zu finden, die sofort einsatzbereit sind. An dieser Stelle kommt die CNCF ins Spiel. Nur Projekte, die die strengen CNC-Richtlinien der CNCF erfüllen, werden für eine Mitgliedschaft in der CNCF in Betracht gezogen. Mit dieser Mitgliedschaft geht ein Label einher, das angibt, inwieweit das jeweilige Mitgliedsprojekt bereit ist, in CNC-Anwendungsfällen eingesetzt zu werden.

Die Projektreife ist ein wichtiger Aspekt bei der Bewertung von OSS-Projekten, und wie ich bereits erwähnt habe, ist die Lösungs-/Projektreifeeiner der von mir empfohlenen PaC-Auswahlfaktoren. Im Kontext der CNCF lässt sich die Projektreife de facto an den drei Stufen der CNCF-Projekte ablesen: Sandbox, Incubating und Graduated. Im Laufe der folgenden Kapitel werde ich auf die CNCF-Projekte und ihre jeweilige CNCF-Projektstufe hinweisen.

Hinweis

Ich habe mir nicht vorgenommen, einen umfassenden Bericht über alle möglichen IT-Regeln und -Richtlinien zu schreiben, die heute verfügbar sind. Vielmehr habe ich mich bewusst auf die Regeln und Instrumente beschränkt, die spezifisch für CSP sind. Einige der Tools und Dienste, die ich in diesem Buch ausdrücklich nicht behandelt habe, sind:

• AWS-Service-Kontrollrichtlinien

• AWS-Konfiguration

• Azure-Politik

• Google Cloud Platform (GCP) Organisationsrichtlinien-Dienst

• Richtlinien für das Identitäts- und Zugriffsmanagement (IAM)

In diesem Buch befasse ich mich mit PaC- und PaC-Lösungen, die größtenteils herstellerneutral und CSP-agnostisch sind.

Zusammenfassung

Wir haben in dieser Einführung in PaC viele Informationen behandelt, aber wir haben nur an der Oberfläche gekratzt. In diesem Kapitel haben wir uns mit Richtlinien, Policies und Policy as Code (PaC) beschäftigt. Wir haben über Policy-Engines und -Sprachen gesprochen, über einige Einsatzmöglichkeiten von PaC (z. B. Guardrails) und darüber, wie du die beste PaC-Lösung für deine Bedürfnisse auswählst. Mit einem allgemeinen Verständnis von PaC und vor dem Hintergrund von OSS und der CNCF können wir nun tiefer in PaC-Lösungen für die Systeme eintauchen, die du nutzt, baust und unterstützt.

Im weiteren Verlauf dieses Buches werde ich bestimmte PaC-Lösungen und ihre jeweiligen Anwendungsfälle, Technologien und allgemeinen Funktionen detaillierter vorstellen. Wenn du dieses Buch durcharbeitest, nimm bitte die PaC Solution Selection Scorecard mit, die du auf deinem Weg anwenden kannst. Ich habe sie in diesem ersten Kapitel eingeführt, damit du sie im weiteren Verlauf des Buches als vorläufigen Leitfaden für die Bewertung der verschiedenen PaC-Lösungen verwenden kannst, die nun folgen. Und schließlich werde ich mich auf das praktische Wissen über die PaC-Lösungen konzentrieren und nur bei Bedarf auf die Dokumentation verweisen, um zu vermeiden, dass ich bereits veröffentlichte Unterlagen wiederkäue.

In Kapitel 2 beginne ich meine ausführliche Darstellung der PaC-Lösungen mit einem tieferen Einblick in den Open Policy Agent.