Identitätsorientiertes Infrastruktur-Zugangsmanagement

Kapitel 1. Einleitung: Die Säulen des Zugangs

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

Der Zugang zur Computerinfrastruktur wird sowohl wichtiger als auch schwieriger, wenn man sie skaliert. In diesem Buch werden Methoden untersucht, die den Zugang einfacher, skalierbarer und sicherer machen.

Der Begriff "Computing-Infrastruktur" ist sehr weit gefasst, aber in diesem Buch meinen wir damit Rechenressourcen in Cloud-Umgebungen, vor Ort oder in kollokierten Rechenzentren und sogar Internet of Things (IoT)-Geräte in öffentlichen Netzwerken. Die Definition von Rechenressourcen umfasst Hardware wie Server, Netzwerke und Speicherung sowie Infrastruktursoftware wie Datenbanken, Message Queues, Kubernetes-Cluster, Monitoring-Dashboards, Continuous Integration/Continuous Delivery (CI/CD) und andere DevOps-Tools.

Der kontrollierte Zugang zu dieser komplexen Vielfalt basierte in der Vergangenheit auf der Vorstellung eines Netzwerks und von Benutzerdaten, der digitalen Version von dem, was Menschen benutzen, um den Zugang zu ihrem Haus zu kontrollieren: eine Tür und ein Schlüsselbund. Ein Benutzerausweis, wie z. B. ein Passwort oder ein privater Schlüssel, ist nichts anderes als eine geheime Information, die einen bestimmten Bereich aufschließt. All diese Geheimnisse sind nur Daten - wie alle Daten können sie verloren, weitergegeben, kopiert, gestohlen oder sogar verkauft werden. Weder ein physischer noch ein digitaler Schlüssel garantiert die Identität der Person, die sich Zugang verschaffen will. Allein der Besitz des Schlüssels ermöglicht den Zugang. Wenn sich das Zugangsmanagement auf Geheimnisse stützt, wird der Zugang nicht einem Kunden gewährt, sondern dem Geheimnis selbst. Das macht ein gestohlenes Geheimnis sehr mächtig.

Wie bei den meisten Zugriffskontrollen, die an der Außenfassade eines Hauses durchgeführt werden, bleibt das Schloss an der Haustür unangetastet, sobald sich ein Eindringling Zugang verschafft hat. Jeder, der einen einzigen Schlüssel zum Haus hat, hat Zugang zu allen Wertgegenständen im Haus. Zusätzliche Sicherheitsvorkehrungen innerhalb des Hauses haben das gleiche grundlegende Problem. Sobald ein Angreifer im Haus ist, ist alles zugänglich.

Unternehmensnetzwerke, die sich auf Geheimnisse und Perimeterverteidigung verlassen, haben dieselbe Schwäche, nur noch schlimmer. Perimeter-basierte Sicherheit auf der Grundlage von Geheimnissen ist unzureichend, weil:

• Die Schlüssel können gestohlen werden, verloren gehen oder an eine legitime Person weitergegeben und heimlich dupliziert werden. Mit anderen Worten: Geheimnisse sind anfällig für menschliche Fehler.

• Wenn die Komplexität der Infrastruktur zunimmt, kann es zu viele Eintrittspunkte geben, die geschützt werden müssen, was den betrieblichen Aufwand erhöht und zu einem wachsenden Dickicht an Schwachstellen führt.

• Es kann viele Nutzer/innen mit unterschiedlichen Zugangsanforderungen für verschiedene Ressourcen geben, was es schwierig macht, jedem/r Nutzer/in nur den richtigen Zugang zu gewähren.

• Ein Eindringling, dem es gelingt, sich Zugang zu verschaffen, kann den Angriff leicht auf benachbarte Ressourcen innerhalb des Perimeters ausrichten und auf dem Weg dorthin Schaden anrichten.

Wenn ein Unternehmen wächst, lässt sich ein sicheres Zugangsmodell, das auf einem Perimeter und Geheimnissen basiert, nicht skalieren. Die oben genannten Schwachstellen zeigen alle dasselbe Muster: Ein Angreifer nutzt menschliche Fehler aus und schwenkt dann um, um überall hinzukommen.

Deine Computing-Infrastruktur kann aus Cloud-Konten mit API-Endpunkten, virtuellen Maschinen (VMs), Datenbanken, Kubernetes-Clustern, Monitoring-Dashboards und CI/CD-Tools bestehen. Vielleicht hast du sogar traditionelle Rechenzentren, in denen dieselben Ressourcen laufen, und jede einzelne Ressource benötigt einen eigenen Zugang. Die Konfiguration von Konnektivität, Authentifizierung, Autorisierung und Audit für jede Ressource erfordert in der Regel die Pflege unzähliger Konfigurationsdateien, von denen jede ihre eigenen Compliance-Anforderungen und Syntax hat. Mit zunehmender Anzahl von Ressourcen wird die Verwaltung des Zugangs zu diesen Komponenten immer komplexer und die Kosten eines Konfigurationsfehlers immer höher.

In diesem Kapitel beginnen wir die Diskussion über den identitätsbasierten Infrastrukturzugang damit, dass wir aufzeigen, wie jeder Einbruch oder Angriff auf genau den Merkmalen beruht, die traditionelle Sicherheitsmodelle fördern, indem wir die Säulen des Infrastrukturzugangs überprüfen. Wir werden darlegen, wie ein echter identitätsbasierter Infrastrukturzugang all diese Herausforderungen löst, indem er die Grundlage beseitigt, auf der die meisten Angriffe auf die Infrastruktur beruhen: menschliches Versagen und die Fähigkeit des Angreifers, sich zu bewegen.

Die meisten Angriffe sind gleich

Die meisten Angriffe auf die Infrastruktur folgen demselben Muster aus menschlichem Versagen und Pivot:

1. Der Angreifer verschafft sich zunächst Zugang zu unternehmenseigenen Rechenressourcen, indem er menschliche Fehler ausnutzt.

2. Der Angreifer schwenkt dann um, um sich Zugang zu benachbarten Computersystemen im selben Netzwerk zu verschaffen.

Menschliche Fehler können zwar durch Sicherheitsschulungen, strenge Rekrutierung und andere Prozesse minimiert, aber nicht völlig ausgeschlossen werden. Menschen werden zuverlässig Menschen sein. Menschen entwerfen anfällige Webanwendungen, klicken auf bösartige E-Mail-Anhänge, lassen ihre Laptops in der U-Bahn liegen und geben API-Schlüssel in öffentliche Git-Repositories ein. Diese und andere Fehler hinterlassen eine Spur von ausnutzbaren Schwachstellen.

Beachte, dass sich jeder sicherheitsrelevante menschliche Fehler um eine Art Geheimnis dreht. Passwörter, private Verschlüsselungsschlüssel, API-Schlüssel, Browser-Cookies und Sitzungs-Tokens sind allesamt Dreh- und Angelpunkte für menschliche Fehler. Jedes Geheimnis ist ein potenzieller Einstiegspunkt für einen böswilligen Akteur. Jedes Mal, wenn ein neues Geheimnis in eine Computerumgebung eingeführt wird, steigt die Wahrscheinlichkeit eines Einbruchs. Diese Wahrscheinlichkeit mag zunächst unbedeutend erscheinen, und ein erfolgreicher Einbruch mag in einem kleinen Unternehmen unwahrscheinlich sein, aber je größer ein Unternehmen wird, desto eher stellt sich die Frage, wann und nicht ob.

Ein Geheimnis wie ein Passwort soll zwar die Identität beweisen, die durch den Benutzernamen ausgedrückt wird, aber das ist nicht der Fall. Ein geheimnisbasierter Zugang setzt voraus, dass nur die berechtigte Person das Geheimnis kennen kann, aber wir wissen, dass das nicht stimmt. Ein Geheimnis verleiht einer Person alle Vorteile einer Identität, ohne dass eine echte Authentifizierung oder Autorisierung durchgeführt werden kann. Jeder, der im Besitz eines Geheimnisses ist, kann vorgeben, jemand anderes zu sein. In diesem Sinne ist der gängige Begriff Identitätsdiebstahl irreführend, denn was tatsächlich passiert, ist ein Diebstahl des Geheimnisses. Eine echte Identität kann nicht geteilt, kopiert oder gestohlen werden.

Die Wahrscheinlichkeit, dass ein einzelner Mensch einen Fehler macht, der zu einem kompromittierten Geheimnis führt, ist relativ gering, vor allem mit einem kompetenten Ingenieurteam und einer starken Sicherheitskultur. Die Einführung von robusten Prozessen und Lösungen zur Verwaltung von Geheimnissen reduziert die Wahrscheinlichkeit eines Geheimnisverlustes auf eine extrem niedrige Zahl, aber sie bringt sie nie auf null. In der Praxis ist der Unterschied zwischen einer niedrigen Zahl und Null enorm, wenn ein Unternehmen in großem Maßstab arbeitet.

Um die Speicherbeschädigung in einem Server als Analogie zu verwenden, ist die Wahrscheinlichkeit eines Bitflips extrem gering. Aber wenn deine Infrastruktur wächst und das Datenvolumen weiter zunimmt, wird es irgendwann jede Minute zu Bitflops kommen. Deshalb ist ein Fehlerkorrekturcode in großem Maßstab unerlässlich: Er verwandelt die Wahrscheinlichkeit eines Bitflips von einer sehr kleinen Zahl in Null. Dies geschieht bei allen Arten von Ereignissen mit geringer Wahrscheinlichkeit. In einem großen Rechenzentrum werden Vollzeitmitarbeiter eingestellt, die jeden Tag Festplatten austauschen, obwohl jede Festplatte eine Lebensdauer von drei Jahren oder mehr hat.

Ähnlich verhält es sich mit der Abhängigkeit von einem Geheimnis, um Zugang zu erhalten. Die Wahrscheinlichkeit, dass ein Mensch ein Geheimnis versehentlich verrät, mag gering erscheinen. Je größer die Infrastruktur und die Teams werden, desto größer wird diese geringe Wahrscheinlichkeit zwangsläufig. Je größer und komplexer die Infrastruktur wird, desto größer wird die Oberfläche der Geheimnisse und desto größer wird die Wahrscheinlichkeit, dass ein Geheimnis verraten wird. Deshalb wird in einer modernen Cloud-Infrastruktur das bloße Vorhandensein eines Geheimnisses als Schwachstelle betrachtet.

Es mag verlockend sein, das Risiko, dass ein Geheimnis durchsickert, durch die Einführung strengerer Prozesse zu verringern. Drakonische Sicherheitsverfahren vermitteln zwar eine beruhigende Illusion von Sicherheit, aber sie machen Ingenieure weniger produktiv und schaffen Anreize für schlechtes Verhalten. Schwer zu handhabende Sicherheitsmaßnahmen verleiten dazu, kürzere Passwörter zu verwenden, eigene Hintertüren in die Infrastruktur einzubauen, sichere Sitzungen länger als nötig offen zu halten, zu versuchen, die Beteiligung des Sicherheitsteams an der Entscheidungsfindung zu minimieren und andere Abkürzungen zu nehmen. Selbst die Leute, die sich ernsthaft bemühen, ein schwieriges Verfahren zu befolgen, machen irgendwann einen Fehler.

Es sind nicht die Menschen, die das Problem sind. Es sind die Geheimnisse selbst. Geheimnisse sind nur Daten; Daten sind anfällig für Diebstahl, Verlust und Kopieren.

Unternehmen wie Google und andere so genannte Hyperscaler waren unter den ersten, die sich dieser Realität gestellt haben, und haben eine skalierbarere Zugangsarchitektur entwickelt, die auf zwei entscheidenden Mustern beruht:

• Keine Geheimnisse

• Null Vertrauen

Dieses Buch behandelt diese beiden Muster und erklärt, wie sie in Echtzeit mit der Infrastruktur skalieren, ohne die Angriffsfläche oder die Wahrscheinlichkeit eines Einbruchs zu erhöhen.

Keine Geheimnisse bedeutet keine Passwörter, Schlüssel oder Token. Die Abschaffung von Geheimnissen trägt dazu bei, den sicheren Zugang zu skalieren, denn ohne Geheimnisse gibt es nichts, was kompromittiert werden könnte, sodass menschliche Fehler nicht mehr ausgenutzt werden können. Anstatt sich auf Geheimnisse zu verlassen, basiert der Zugang auf der Identität selbst.

Zero Trust bedeutet, dass jeder Nutzer, jedes Gerät, jede Anwendung und jede Netzwerkadresse von Natur aus nicht vertrauenswürdig ist. Es gibt keinen Perimeter, weil es kein "Innen" gibt, in dem Entitäten vertrauenswürdig sind. In einem Zero-Trust-Zugriffsmodell wird jede Netzwerkverbindung verschlüsselt, jede Sitzung muss authentifiziert werden, jeder Client muss autorisiert sein, und für jede Client-Aktion wird ein Audit-Protokoll geführt. Mit Zero Trust kann jede Rechenressource sicher über eine öffentliche IP-Adresse in einem nicht vertrauenswürdigen öffentlichen Netzwerk betrieben werden.

Zero Trust verringert die Wahrscheinlichkeit, dass ein Angreifer die Kontrolle über ein einzelnes System erlangt, erheblich und reduziert den "Aktionsradius" eines Angriffs auf das System, das ursprünglich angegriffen wurde.

Keine Geheimnisse und Zero Trust tragen gemeinsam dazu bei, das Muster "menschliches Versagen + Pivot" zu neutralisieren. Wenn es keine Geheimnisse gibt, können menschliche Fehler keine Schwachstellen verursachen. Bei Zero Trust gibt es kein "Inneres", zu dem man gelangen kann, so dass Pivoting sinnlos wird. Das gibt uns die Freiheit, über den Zugang selbst nachzudenken.

Zugang

Access ermöglicht es Menschen, Software und Hardware sicher zusammenzuarbeiten. Im Kern ist der Zugang eine Sammlung von Privilegien oder Berechtigungen, die es einem Subjekt (einem Kunden) erlauben, bestimmte Aktionen auf einem Objekt (einer Rechenressource) für eine bestimmte Zeit durchzuführen. Zugriffskontrolle bedeutet, dass Anfragen von Subjekten, oft Nutzern, zum Zugriff auf Objekte vermittelt werden, indem Rechte verwendet werden, die festlegen, welche Art von Zugriff einem bestimmten Subjekt auf ein bestimmtes Objekt gewährt wird. Ziel ist es, jedes Zugriffsereignis innerhalb eines Systems zu kontrollieren, um Daten und Ressourcen vor unbefugter Offenlegung oder Veränderung zu schützen und gleichzeitig den Zugriff durch legitime Nutzer/innen zu gewährleisten.

DasZugriffsmanagement der Infrastruktur ist die Möglichkeit, festzulegen und durchzusetzen, wie jeder Client mit jeder Ressource arbeitet. Die Zugriffsverwaltung ist die Grundlage für die Sicherheit der Computerinfrastruktur. Sie regelt die Nutzung der gesamten Hardware und Software und wie Informationen übertragen, verarbeitet und gespeichert werden.

Im Allgemeinen ist der verwaltete Zugriff ein Fernzugriff, weil er die Kommunikation zwischen verschiedenen Rechnern beinhaltet. In modernen Infrastrukturen ist es selten, dass jemand nur an einem einzigen, isolierten Rechner arbeitet. Die Verwaltung des Fernzugriffs basiert auf vier Säulen:

Sichere Konnektivität

Sichere Kommunikation über ein nicht vertrauenswürdiges Netzwerk

Authentifizierung

Nachweis der Identität des Kunden

Autorisierung

Festlegen der Aktionen, die ein Client durchführen kann

Audit

Eine Aufzeichnung von historischen Ereignissen in Echtzeit und

Diese vier Komponenten stellen sicher, dass der richtige Kunde die richtige Art von Zugang zu geschützten Ressourcen hat und dass die richtigen anderen sehen können, was vor sich geht. Die nächsten Abschnitte geben einen kurzen Überblick darüber, warum jede Säule wichtig ist. In den folgenden Kapiteln wird jede einzelne Säule ausführlicher behandelt.

Sichere Konnektivität

Eine sichere Verbindung ist die erste Säule des Zugangs. Bevor eine Authentifizierung stattfinden kann, muss eine sichere Verbindung hergestellt werden. Um sicher auf eine geschützte Ressource zugreifen zu können, muss ein Unternehmen in der Lage sein, Nachrichten auszutauschen, ohne befürchten zu müssen, abgehört zu werden.

Der frühere Ansatz für Konnektivität beruhte auf der Sicherheit am Netzwerkrand, als Verschlüsselung nur für Nachrichten benötigt wurde, die den Netzwerkrand, auch bekannt als lokales Netzwerk (LAN) oder virtuelle private Cloud (VPC), verließen. Jeder, der sich innerhalb des LAN oder VPC befand, war vertrauenswürdig. Wenn die Infrastruktur wächst, wird das Netzwerk immer komplizierter. Die Verwendung von virtuellen privaten Netzwerken (VPNs) und Firewalls zum Zusammenfügen von Perimetern, um vertrauenswürdige Bereiche zu schützen, wird extrem schwierig und hinterlässt immer mehr Lücken.

Selbst im besten Fall funktioniert die Perimetersicherheit nicht, weil sie dich anfällig für Angreifer macht. Interessanterweise ist die Sicherheit nicht das einzige Argument gegen den Perimeter. Da immer mehr externe Dienste Verbindungen zu privaten Netzwerken benötigen, sind Firewalls im Grunde nur noch Bremsklötze. Im Grunde ist der Perimeter schon lange tot.

Das bedeutet, dass es so etwas wie ein vertrauenswürdiges Netzwerk nicht geben kann. Das ist es, was Zero Trust bedeutet. Verschlüsselung, Authentifizierung, Autorisierung und Kontrolle können sich nicht mehr auf das Netzwerk verlassen und müssen von der Netzwerk- auf die Anwendungsschicht verlagert werden. Anfragen können nicht mehr danach bearbeitet werden, ob sie sich in einem vertrauenswürdigen Netzwerk befinden. Das Netzwerk selbst wird nicht mehr vertrauenswürdig, d. h. die Kommunikation muss auf Sitzungsebene Ende-zu-Ende verschlüsselt werden.

Zum Glück wurden die Technologien dafür schon vor langer Zeit erfunden und werden für die sichere Kommunikation über das Internet verwendet. Wir alle nutzen sie bereits beim Online-Banking oder beim Einkaufen. Wir müssen nur die gleichen Zero-Trust-Prinzipien auf unsere Computerumgebungen innerhalb des LANs oder VPCs anwenden, nicht nur an der Peripherie.

Authentifizierung

Authentifizierung bedeutet, die Identität nachzuweisen. Eine Person, ein Computer, ein Dienst oder ein anderer Client, der den Zugriff auf eine geschützte Ressource beantragt, muss nachweisen können, dass er derjenige ist, für den er sich ausgibt. Wenn du einen Anmeldebildschirm siehst, ist das eine Art der Authentifizierung. Die Authentifizierung muss von der Autorisierung getrennt werden, damit die Berechtigungen einer Einheit aktualisiert werden können, wenn sich ihre Rolle ändert. Bei der Authentifizierung wird nicht festgelegt, was eine Entität tun darf. Durch die Authentifizierung wird nur die Identität bestätigt.

Die Überprüfung von Passwörtern ist eine beliebte Authentifizierungsmethode, aber sie reicht nicht aus, um die Identität zu beweisen. Schließlich zeigt die passwortbasierte Authentifizierung lediglich den Besitz des Geheimnisses selbst an und beweist nicht die Identität des Inhabers. Authentifizierung muss den Kern der Identität treffen, was eine schwierigere Aufgabe ist. Wie kann man die wahre Identität einer Person in der digitalen Welt nachweisen?

Ein Versuch, die Identität nachzuweisen, ist die Multifaktor-Authentifizierung (MFA), die in der Regel zwei oder drei verschiedene Arten von Geheimnissen verwendet, um den Nachweis zu erbringen. Dieses Muster wird manchmal auch als " Wissen + Haben + Sind" bezeichnet und beinhaltet oft ein Passwort (etwas, das du weißt), einen einmaligen Token, der von einem separaten Gerät generiert wird (etwas, das du hast), und deine biologischen Merkmale (etwas, das du bist). Leider wird bei den gängigen Implementierungen der Multifaktor-Authentifizierung das Paar "Wissen + Haben" einfach in ein Sitzungs-Token oder ein Browser-Cookie umgewandelt - also in ein weiteres Geheimnis mit all den Problemen, die ein Geheimnis mit sich bringt.

Die Authentifizierung ist ein schwieriges Problem, denn es geht darum, die wahre Identität einer Person in eine digitale Form zu übertragen, die nicht dieselben Schwächen aufweist wie Geheimnisse.

Autorisierung

Sobald die Identität festgestellt ist, wird durch die Autorisierung festgelegt, welche Aktionen ein Subjekt ausführen darf - zum Beispiel nur Lesezugriff oder Vollzugriff.

Wenn man über die Autorisierung nachdenkt, wird schnell klar, warum ein geheimnisbasierter Zugang ohne eine starke Verbindung zu einer Identität unzureichend ist. Dein Hausschlüssel gibt dir (oder jedem, der ihn besitzt) die Möglichkeit, dein Haus zu betreten, aber erst deine Identität gibt dir die Berechtigung dazu. Du kannst anderen die Erlaubnis erteilen, bestimmte Aktionen durchzuführen. Du könntest jemanden ermächtigen, einen undichten Wasserhahn zu reparieren oder einen Freund zum Essen einzuladen. Hoffentlich erteilst du diese Berechtigungen aufgrund deiner Identität und nicht aufgrund des Besitzes eines Hausschlüssels.

Die Autorisierung ist von der Authentifizierung getrennt, hängt aber von ihr ab. Ohne zu wissen, wer den Zugriff auf eine Ressource beantragt, ist es unmöglich zu entscheiden, ob der Zugriff gewährt wird. Die Autorisierung besteht aus der Festlegung und Durchsetzung von Richtlinien: Es wird entschieden, wer auf welche Ressourcen zugreifen darf, und diese Entscheidungen werden durchgesetzt. Die Matrix aus Entitäten und Berechtigungen kann sehr groß und komplex sein und wurde oft vereinfacht, indem Zugriffsgruppen erstellt und Ressourcen in Gruppen mit definierten Berechtigungen eingeteilt wurden. Das vereinfacht zwar die Verwaltung der Richtlinien, vergrößert aber den Radius eines Einbruchs. Jemand mit einem gestohlenen Berechtigungsnachweis erhält Zugang zu einer großen Gruppe von Ressourcen, je nachdem, welcher Rolle der Berechtigungsnachweis zugewiesen ist.

Audit

Audits zeigen, welche Aktionen von jedem Benutzer oder Rechner durchgeführt wurden und welche Ressourcen davon betroffen waren. Die Notwendigkeit von identifizierbaren Audit-Protokollen - zu wissen, wer was getan hat - ist ein weiterer Grund, warum ein Perimeter-basierter Zugang nicht skalierbar ist. Wenn du dich auf eine Netzwerkgrenze verlässt, um Clients zu authentifizieren, und die Ressourcen in einem internen Netzwerk nicht geschützt sind, bedeutet das, dass alle Benutzer als ein einziger "Gast" (oder schlimmer noch: "Admin") zusammengefasst werden, wodurch die Audit-Protokolle nutzlos werden.

Sobald sich der Zugriff von einem Perimeter-basierten Ansatz auf die Ressourcen- und Anwendungsebene verlagert und detailliertere und granularere Ereignisse erzeugt, wird es noch wichtiger, sowohl eine Echtzeitansicht als auch eine historische Aufzeichnung des Zugriffs zu haben. Audit fällt typischerweise unter die Sicherheitsbegriffe Verwaltbarkeit und Nachvollziehbarkeit, wobei der wichtige Punkt ist, dass du tatsächlich weißt und kontrollierst, was in deiner Umgebung vor sich geht.

Das identitätsbasierte Infrastruktur-Zugriffsmanagement bietet ein hohes Maß an Kontrolle über die einzelnen Zugriffsrechte, aber die Kehrseite der Medaille ist die Verantwortung dafür, dass die Berechtigungen entzogen werden, wenn sie nicht mehr benötigt werden. Regelmäßige Audits können dazu beitragen, das Risiko zu minimieren, dass Privilegien falsch vergeben werden oder über den Zeitpunkt hinaus bestehen bleiben, an dem sie nicht mehr benötigt werden. Mit anderen Worten: Audits sind eine weitere Absicherung gegen menschliche Fehler.

Eine Echtzeit-Ansicht und eine historische Aufzeichnung des Zugangs ist eine wichtige Sicherheitsfunktion. Die Abkehr von einem perimeterbasierten Ansatz hin zu einem identitätsbasierten Infrastrukturzugang bietet ein hohes Maß an Zugangskontrolle, denn durch Audits kann jeder Zugang auf individueller Ebene mit einer Identität verknüpft werden.

Sicherheit versus Bequemlichkeit

Sicherheit und Bequemlichkeit stehen bekanntlich im Widerspruch zueinander. Wenn wir uns nach dem Einkaufen unserem Haus nähern, müssen wir abbremsen, die Tüten auf der Veranda abstellen und nach den Schlüsseln greifen. Das ist nicht gerade bequem, vor allem wenn es regnet!

Die Unannehmlichkeiten der Sicherheit werden in Computerumgebungen noch deutlicher. Oft gibt es zwei Gruppen von Ingenieuren, die an Entscheidungen über den Fernzugriff beteiligt sind. Auf der einen Seite haben wir Softwareentwickler, die schnell Fehler beheben, neue Funktionen an die Kunden liefern, die Leistung verbessern und Fehler beheben müssen - und das alles innerhalb eines engen Zeitrahmens. Auf der anderen Seite gibt es Sicherheits- und Compliance-Ingenieure, die sich vor allem mit dem Risiko befassen.

Diese beiden Gruppen haben sehr unterschiedliche Anreize. Softwareentwickler wollen nicht, dass die Sicherheit im Weg steht, weil sie sie verlangsamt - und in vielen Fällen hat die Art und Weise, wie die Sicherheit gemessen wird, nichts mit der tatsächlichen Sicherheit zu tun. Sicherheits- und Compliance-Ingenieure sind mehr daran interessiert, Risiken zu verringern, als daran, wie schnell die Dinge erledigt werden. Infolgedessen gibt es oft Spannungen zwischen Entwicklern und Sicherheitsingenieuren, die sich manchmal in einem offenen Konflikt äußern. Es muss ein Kompromiss gefunden werden.

Unternehmen gehen dies auf unterschiedliche Weise an. Kleinere Technologie-Start-ups setzen auf Produktivität, weil ihr Hauptrisiko kein Sicherheitsrisiko, sondern ein Geschäftsrisiko ist. Sie konzentrieren sich vielleicht noch darauf, das Produkt an den Markt anzupassen, so dass die Geschwindigkeit der Produktentwicklung wichtiger ist als die Einhaltung von Vorschriften. Mit zunehmender Reife verschiebt sich das Gleichgewicht hin zu robusteren Sicherheitspraktiken und der Durchsetzung von Vorschriften, wobei ein Teil der Geschwindigkeit der Produktentwicklung auf der Strecke bleibt.

Die Umstellung der Branche auf Cloud Computing hat zu diesem Dilemma beigetragen. Ingenieurinnen und Ingenieure haben mehr Kontrolle über ihre Infrastruktur, weil die Infrastruktur selbst jetzt mit Code bereitgestellt wird. Unterdrückende Sicherheitsprozesse schaffen Anreize für Ingenieure, ihre eigenen Abkürzungen zu implementieren, was bei der Bereitstellung von Infrastruktur als Code leicht möglich ist. Oft glaubt die Unternehmensleitung, dass sie solide Sicherheitsmaßnahmen ergriffen hat, während ihr Ingenieurteam in Wirklichkeit eigene Wege für den Zugriff auf Cloud-Umgebungen gefunden hat. Dieser Ansatz wird als Sicherheitstheater bezeichnet.

Daraus können wir schließen, dass ein System für den Zugang zur Infrastruktur nur dann sicher ist, wenn das Ingenieurteam es tatsächlich gerne benutzt.

Skalierung von Hardware, Software und Peopleware

Die Definition von Infrastruktur wird immer breiter. In dem Maße, in dem Remote-Arbeit und persönliche Geräte Teil des Arbeitsplatzes werden und sich verschiedene Computerumgebungen ausbreiten, ist die Fläche dessen, was wir früher als Infrastruktur bezeichnet haben, unvorstellbar komplex geworden. Es ist nicht mehr praktikabel, in Netzwerken und Abgrenzungen zu denken. Stell dir ein Unternehmen wie Tesla vor, das über ein Netzwerk von Ladestationen und Millionen von Fahrzeugen rund um den Globus verfügt, die alle mit zahlreichen CPUs, Speicherungen und Konnektivität ausgestattet sind. Wohin werden die Software-Updates verteilt? Ihr Verteilungsziel ist der Planet Erde!

Wenn die Infrastruktur wächst, müssen wir erkennen, dass sie nicht homogen ist. Es gibt viele verschiedene Arten von Ressourcen und Nutzern, die jeweils unterschiedliche Rollen, Bedürfnisse und Richtlinien haben. Wir müssen unterschiedliche Verhaltensweisen in verschiedenen Kontexten durchsetzen: Entwicklung, Staging, Test und Produktion, zum Beispiel. Wir müssen die gesamte Softwareentwicklungskette vor Schwachstellen (menschliches Versagen) schützen und den Aktionsradius im Falle eines Verstoßes begrenzen. Die sichere Verwaltung des Zugriffs in all diesen Umgebungen, mit so vielen miteinander verbundenen Zielen und beweglichen Teilen, ist ungeheuer komplex.

Die Infrastruktur konnte schnell skaliert werden, indem man von der Verwaltung physischer Geräte auf die Verwendung von APIs für die Bereitstellung virtueller Geräte umgestiegen ist. Da alles als Code definiert und verwaltet werden kann (Infrastructure as Code [IaC]), ist es einfach, elastisch zu skalieren, indem man mehr von jeder benötigten Ressource bereitstellt. Die Netzwerke sind dynamisch und die Ressourcen sind vollständig fungibel. Alles wird über einen eigenen Netzwerksockel abgehört und benötigt Zugang zu einer bestimmten Anzahl anderer Ressourcen. Es wäre unmöglich, jeden Netzwerksocket und jeden Endpunkt zu überwachen und zu blockieren, um eine Infiltration zu verhindern.

Die Schwierigkeit bei der Verwaltung des Infrastrukturzugriffs liegt letztlich in der Skalierung aller drei Hauptelemente einer Computerumgebung:

Hardware

Die physischen Komponenten, aus denen das System besteht, einschließlich Server, Speicherung, PCs, Telefone und Netzwerkgeräte

Software

Container, Kubernetes-Cluster, Datenbanken, Überwachungssysteme, interne Webanwendungen, Dienste und Clients, die innerhalb einer VPC oder über Netzwerke hinweg miteinander kommunizieren

Peopleware

Die menschliche Rolle in der Informationstechnologie , einschließlich Softwareentwickler, DevOps und Sicherheitsteams

Alle drei Elemente werden mit zunehmender Größe immer komplexer. In Unternehmen gibt es oft Zehntausende von geografisch verteilten Servern, auf denen immer vielfältigere Cloud Computing-Umgebungen mit VMs, Containern, Kubernetes-Clustern, Datenbanken und einer Vielzahl von Logging- und Überwachungs-Tools laufen. Dies führt zu Zugangssilos über diese Dimensionen hinweg:

• Der Zugriff auf die Hardware ist isoliert, weil die Infrastruktur der Cloud anders genutzt wird als die älteren Umgebungen, die in einem traditionellen Rechenzentrum untergebracht sind.

• Der Zugriff auf die Software ist isoliert, da der Zugriff auf die Datenbanken über ein VPN erfolgt, der Zugriff auf Secure Shell (SSH) über eine Reihe von Jump-Hosts mit privaten Schlüsseln, die in einem Tresor gespeichert sind, und die CI/CD-Tools sind über eine öffentliche IP-Adresse zugänglich und mit einem unternehmensweiten Single-Sign-On-System (SSO) verbunden.

• Der Zugang zu Peopleware ist isoliert, denn einige Teams verwenden manuell eingerichtete Konten mit einem Passwortmanager, um auf ihre Systeme zuzugreifen, andere verwenden SSO, und wieder andere Teams haben besondere Anforderungen - wie z.B. ein Compliance-Team, das bestimmte Arten des Zugangs nur von einem genehmigten Laptop aus erlaubt, der in einem Safe aufbewahrt wird.

Da die Teams immer verteilter und flexibler werden und sich auf Auftragnehmer und andere externe Mitarbeiter verlassen, muss der Zugang schnell bereitgestellt, verwaltet und vor allem wieder freigegeben werden.

Abbildung 1-1 zeigt, wie Silos unweigerlich entstehen, wenn man eine bestimmte Größe erreicht. Jede Software (dargestellt durch die schattierten Rechtecke) hat ihre eigene Zugriffsmethode - bereits ein Silo. Wenn sich die Infrastruktur auf mehrere Umgebungen wie Amazon Web Services (AWS) und On-Premise ausbreitet, entstehen zusätzliche Silos, die orthogonal zu den Software-Silos sind. Wenn ein Unternehmen in großem Umfang neue Mitarbeiter einstellt, werden die Auftragnehmer aus Sicherheitsgründen wahrscheinlich auf ihre eigenen Zugangsmethoden festgelegt. Schlimmer noch, verschiedene Rollen werden manchmal zu verschiedenen Zugriffsmethoden gezwungen. Das Ergebnis ist eine mehrdimensionale Matrix von Silos, die eine einheitliche Anwendung der Zugriffsrichtlinien nahezu unmöglich macht.

Da wir immer mehr Aufgaben automatisieren, soll die Rolle des Menschen mit der Zeit immer kleiner werden. Damit das funktioniert, muss Software sicher und autonom mit anderer Software kommunizieren können, um automatisierte Prozesse wie CI/CD-Deployments, Monitoring, Backups, das Zusammenspiel von Microservices in verteilten Anwendungen und die dynamische Bereitstellung von Informationen zu unterstützen. Herkömmliche Sicherheitsmethoden verwenden Token, Cookies und andere Geheimnisse, die auf die wachsende Zahl separater Tools mit leicht unterschiedlichen Sicherheitsprotokollen zugeschnitten sind. Dies ist nicht nur nicht skalierbar, sondern bietet auch keine Möglichkeit, menschliche Fehler nachzuverfolgen und zu korrigieren, wenn sie zu Schwachstellen und Sicherheitsverletzungen führen.

Abbildung 1-1. Wie Silos entstehen, wenn die Infrastruktur wächst

Mit anderen Worten: Die Trennung zwischen Menschen, die auf Maschinen zugreifen, und Maschinen, die aufeinander zugreifen, schafft doch ein weiteres Zugangssilo: Menschen gegen Maschinen.

Die verwundbarste Komponente in einem Informationssystem ist die Peopleware: Benutzer, Administratoren, Entwickler und andere, die auf das System zugreifen. Jeder Verstoß kann auf einen menschlichen Fehler zurückgeführt werden. Die Komplexität der Arbeit mit so vielen verschiedenen Zugangsprotokollen und den damit verbundenen Geheimnissen und mehrstufigen Authentifizierungsverfahren verleitet Menschen dazu, Abkürzungen zu nehmen: zwischen den Sitzungen eingeloggt zu bleiben, Passwörter wiederzuverwenden, Geheimnisse aufzuschreiben und andere schlechte Verhaltensweisen. Diese Tendenz erhöht die Wahrscheinlichkeit, dass ein Fehler ausgenutzt wird. Oft erhöhen gut gemeinte neue Sicherheitsmaßnahmen den Druck auf die Menschen, die sie anwenden, so dass sie noch mehr Abstriche machen, um ein gewisses Maß an Produktivität zu bewahren.

Der Punkt ist, dass eine wachsende Anzahl von Zugangssilos, jedes mit seinen eigenen Geheimnissen, Protokollen, Authentifizierungs- und Autorisierungsmethoden usw., zu einem unüberschaubaren Labyrinth von Schwachstellen führt, die tendenziell zunehmen, wenn die Komplexität des Zugangs beginnt, die Fähigkeit der Menschen zu beeinträchtigen, produktiv zu sein.

Um das Problem zu lösen, ist es notwendig die Komplexität zu reduzieren, was nicht nur das Nutzererlebnis verbessert, sondern auch die Sicherheit erhöht, indem es überschaubarer wird. Wenn wir schon dabei sind, das Element des menschlichen Fehlers zu beseitigen, wäre es von Vorteil, von einem geheimnisbasierten Sicherheitsmodell wegzukommen. Aber um die Wahrscheinlichkeit menschlicher Fehler zu verringern, muss nicht nur die Anzahl der Geheimnisse reduziert werden. Es ist auch notwendig, die Komplexität der Zugangskonfiguration für eine Vielzahl unterschiedlicher Ressourcen zu beherrschen und Silos aufzubrechen, indem Hardware, Software und Peopleware in einer einzigen, einheitlichen Quelle für die Zugangspolitik zusammengefasst werden.

Die Vereinheitlichung der Zugriffskontrolle für Menschen, Maschinen und Anwendungen verringert den Bedarf an Fachwissen für die Konfiguration von Konnektivität, Authentifizierung, Autorisierung und Audit in all diesen verschiedenen Systemen, reduziert die Komplexität insgesamt und ermöglicht eine konsistente Auditierbarkeit. Durch die Verringerung der Komplexität steht die Sicherheit wiederum der Bequemlichkeit und Produktivität nicht mehr im Weg, sodass Ingenieure weniger Gründe haben, Abkürzungen zu nehmen oder die Sicherheitsrichtlinien auf andere Weise zu unterlaufen.

Es hat sich herausgestellt, dass es einen Ansatz gibt, mit dem diese Ziele erreicht werden können.

Identität-Native Infrastruktur Zugang

Das Ziel des identitätsbasierten Infrastrukturzugangs ist es, von Geheimnissen wegzukommen. Geheimnisse sind nur Daten, und Daten sind anfällig für menschliche Fehler. Wahre Identität sind keine Daten, die heruntergeladen, kopiert oder gestohlen werden können. Wahre Identität ist ein Merkmal der physischen Welt. Du bist du. Der schwierigste Aspekt bei der Gewährung von Zugang auf der Grundlage der Identität ist das Problem der digitalen Darstellung der physischen Identität. An Benutzernamen gebundene Geheimnisse waren ein vergeblicher Versuch, Nutzeridentitäten in die digitale Welt zu bringen.

Die Idee, einen zentralen Identitätsspeicher zu verwenden, war der erste Versuch, die Anzahl der Geheimnisse innerhalb einer Organisation zu reduzieren. Anstatt dass jede Anwendung ihre eigene Liste von Benutzerkonten mit den dazugehörigen Logins und Passwörtern pflegt, ist es sinnvoll, alle Benutzerkonten in einer Datenbank zusammenzufassen und diese irgendwie für viele Anwendungen freizugeben. Genau so funktionieren zentralisierte Identitätsmanagementsysteme (IdM). Sie fassen die Benutzerkonten an einem einzigen Ort zusammen und bieten eine standardisierte API, über die Anwendungen auf sie zugreifen können. Wenn ein Nutzer zum Beispiel den Zugang zu einer Webanwendung beantragt, leitet die Anwendung den Nutzer an ein IdM-System wie Okta oder Active Directory weiter. Das IdM stellt sein eigenes Login zur Verfügung, um den Nutzer zu authentifizieren, überträgt eine Darstellung der Identität des Nutzers zurück auf den Computer des Nutzers und leitet den Nutzer mit der Identität des Nutzers in Form eines Tokens zurück zur Anwendung, auf die er zugreifen möchte.

Abbildung 1-2 zeigt die SSO-Anmeldesequenz von oben nach unten:

1. Ein nicht authentifizierter Benutzer (kein Token, kein Session-Cookie) versucht, auf eine Web-App zuzugreifen.

2. Die Web-App leitet den Nutzer zu einem IdM wie Active Directory weiter.

3. Der Benutzer meldet sich mit seinen Anmeldedaten beim IdM an.

4. Der IdM sendet die Identität des Nutzers in Form eines Tokens.

5. Der Nutzer kann nun auf die Web-App zugreifen, indem er das Authentifizierungs-Token angibt.

Abbildung 1-2. Die SSO-Anmeldesequenz

Es ist leicht zu erkennen, warum dieser Ansatz besser skaliert: Egal wie viele Anwendungen oder andere identitätsbewusste Ressourcen ein Unternehmen einsetzt, die Anzahl der Geheimnisse bleibt gleich. Außerdem bleibt der Aufwand für die Bereitstellung und den Entzug des Zugangs für Mitarbeiter, die einem Team beitreten oder es verlassen, der gleiche.

IdM ist zwar ein großer Schritt nach vorn, aber es beseitigt die Geheimnisse nicht vollständig, sondern reduziert nur ihre Anzahl. Vergessen wir nicht den Browser-Cookie. Da ein Cookie nur ein weiteres Geheimnis ist, löst es das eigentliche Problem nicht. Wenn du das Cookie stiehlst, kannst du jemand anderes werden.

Ein weiteres praktisches Problem mit Identitätsmanagementsystemen ist, dass sie in erster Linie mit Blick auf Webanwendungen entwickelt wurden. Die gängigen Protokolle, die für IdM verwendet werden, sind HTTP-Protokolle: Security Assertion Markup Language (SAML), OAuth2 und OpenID Connect. Die Computerinfrastruktur verlässt sich dagegen auf viel ältere, ressourcenspezifische Protokolle wie SSH, das Remote-Desktop-Protokoll (RDP), MySQL, PostgreSQL und andere, die nicht in einem Browser funktionieren und nicht nativ in ein IdM-System integriert werden können.

Die beiden größten Herausforderungen bei der Implementierung einer identitätsbasierten Infrastruktur sind daher der Zugang:

• Abkehr von der Speicherung der Identität als geheime Daten

• Einen Weg finden, um die Identität mit Hilfe nativer Infrastrukturprotokolle zu übertragen

Die Abkehr von Geheimnissen im Identitätsmanagement bedeutet, dass die Identität mit einer realen, physischen Welt verbunden wird, indem biometrische Authentifizierung für Menschen und Hardware-Sicherheitsmodule für Maschinen verwendet werden.

Die nächste Frage ist, wie die wahre Identität in den digitalen Bereich übertragen werden kann, denn ein Zugangssystem muss irgendwie mit der wahren Identität interagieren. Der beste derzeit verfügbare Mechanismus, um die wahre Identität sicher in ein Zugangssystem zu übertragen, sind digitale Zertifikate. Tabelle 1-1 zeigt, wie sich Zertifikate im Vergleich zu Geheimnissen für die Zugriffskontrolle eignen.

Tabelle 1-1. Ein Vergleich der Merkmale von Zertifikaten und Geheimnissen

	Bescheinigungen	Geheimnisse
Standardisiert über Protokolle und Anwendungen hinweg	Ja	Nein
Anfälligkeit für Diebstahl	Niedrig	Hoch
Management Gemeinkosten	Niedrig	Hoch
Identitäts- und Kontext-Metadaten	Ja	Nein

Zertifikate können für Maschinen, Menschen und Anwendungen ausgestellt werden. Zertifikate werden von den gängigen Infrastrukturprotokollen unterstützt. Zertifikate sind sicherer als Geheimnisse, weil sie weit weniger anfällig für Diebstahl und Missbrauch sind. Ein Zertifikat kann widerrufen werden, automatisch ablaufen, für eine einmalige Verwendung ausgestellt werden und an einen bestimmten Kontext (Absicht) und eine Netzwerkadresse gebunden werden. Das macht den Diebstahl eines Zertifikats nahezu sinnlos. Durch die Vertrauenskette, die zu einer Zertifizierungsstelle (CA) zurückführt, gibt es nur ein einziges Geheimnis, das geschützt werden muss - die CA selbst - unabhängig von der Größe der Organisation. Mit anderen Worten: Dieser Ansatz ist unbegrenzt skalierbar, ohne die Sicherheit zu beeinträchtigen.

Ein modernes, zertifikatsbasiertes, zentrales Identitätsmanagementsystem enthält außer der Zertifizierungsstelle keine weiteren Geheimnisse. Die wahre Identität der Kunden wird nicht in einer Datenbank gespeichert, sondern in der realen Welt als identifizierende physische Attribute von Menschen und Maschinen: menschliche Biometrie, Hardware-Sicherheitsmodule und vertrauenswürdige Plattformmodule. Die Übertragung der Identität erfolgt in einem Zertifikat, das an einen Kontext gebunden und zeitlich begrenzt werden kann. Dadurch wird der Zugang auf eine einzige Ebene verlagert, auf der alle Säulen des Zugangs einheitlich auf der Grundlage der wahren Identität eines jeden Unternehmens erfolgen.

Dieser Ansatz bildet nicht nur die Grundlage für mehr Sicherheit und einen bequemeren Zugang für die Nutzer/innen, sondern auch für die Bewältigung der Herausforderungen von Größe und Komplexität. Der Ansatz beruht auf den beiden bereits erwähnten Prinzipien: Beseitigung von Geheimnissen (um menschliches Versagen auszuschließen) und Zero Trust (um im Falle eines Verstoßes ein Umschwenken unmöglich zu machen).

Das ist der Ansatz, den Hyperscale-Unternehmen gewählt haben. Weg von Geheimnissen, hin zur digitalen Darstellung der wahren Identität von Hardware, Software und Peopleware. Zero Trust bedeutet nicht nur, alle Verbindungen zu verschlüsseln, sondern alle Infrastrukturkomponenten so zu gestalten, dass sie auch ohne Firewall sicher sind - denn es gibt keine Grenzen.

In den folgenden Kapiteln wird erklärt, wie das geht und warum es nicht schmerzhaft sein muss.