Stellen Sie sich folgendes in Erinnerung. Sie entwickeln eine Anwendung und benötigen einen API-Schlüssel für einen Dienst, ein Datenbankpasswort oder einen Storage-Account-Schlüssel. Also fügen Sie ihn direkt in Ihren Code ein, vielleicht in eine Konfigurationsdatei über eine Umgebungsvariante. Und alles läuft einwandfrei, bis Sie den Code auf GitHub hochladen oder ein Notebook mit einem Kollegen teilen. Und schon ist Ihr Geheimnis nicht mehr so geheim. In dieser Code in die falschen Hände gerät, ist Ihr gesamtes System gefährdet. Azure Key Vault ist das Werkzeug, das dieses Problem löst. Es bietet einen sicheren Ort zur Speicherung von Geheimnissen, damit diese nie in Ihrem Code landen. Aber hier liegt der Punkt, den die meisten falsch verstehen. Ein Key Vault allein macht Sie noch nicht automatisch sicher. Die Art und Weise, wie Sie ihn einrichten, den Zugriff kontrollieren und Berechtigungen vergeben, ist genauso wichtig.

Am Ende dieser Folge wissen Sie, was Key Vault wirklich ist, was Sie darin speichern können, wie der Zugriff funktioniert und welches der größte Fehler ist, der Ihre Geheimnisse gefährden könnte. Alles in verständlicher Sprache, ohne Fachjargon und das Wesentliche, das Sie brauchen. Was genau ist also Azure Key Vault? Was ist Azure Key Vault? Ist die einfachste Definition. Azure Key Vault ist ein cloudbasierter, digitaler Tresor für Ihre Geheimnisse. Es ist ein verwalteter Dienst von Microsoft für IPI-Schlüssel, Datenbankpasswörter, Verbindungszeichenfolgen, Verschlüsselungsschlüssel und Zertifikate an einem zentralen Ort. Sie müssen sich nicht um die Infrastruktur kümmern, denn Azure übernimmt Patches, Verfügbarkeit und Sicherheit. Sie nutzen ihn einfach. Stellen Sie es sich wie ein Bürogebäude vor. Sie haben Arbeitsplätze, Besprechungsräume und Aktenschränke, aber irgendwo im Keller gibt es einen sicheren Tresorraum für die wichtigen Dinge.

Hauptschlüssel, Bargeld, rechtliche Dokumente. Niemand geht ohne Erlaubnis und Authentifizierung hinein. Und jedes Mal, wenn jemand die Tür öffnet, wird dies protokolliert. Das ist Key Vault. Der sichere Raum im Keller Ihrer Azure Architektur. Vergleichen Sie das nur mit der alten Folgen. Vor 20 Jahren, wenn man ein Datenbankpasswort brauchte, hat man es fest in eine Konfigurationsdatei oder eine Umgebungsvariable programmiert. Oder noch schlimmer, im Klartext, im Quellcode belassen. Wenn jemand Zugriff auf diesen Server erhielt, hat er alles. Und wenn man das Passwort ändern musste, musste man es überall aktualisieren. In jeder Konfigurationsdatei, jeder Umgebung, jedem Deployment. Es war ein Albtraum. Key Vault ändert das alles. Anstatt Geheimnisse über Ihren Code und Ihre Konfigurationsdateien zu verteilen, speichern Sie sie an einem zentralen Ort. Ihre Anwendungen fragen Sie zur Laufzeit nur dann ab, wenn Sie sie wirklich benötigen.

Und da alles zentralisiert ist, können Sie ein Geheimnis an einer Stelle rotieren. Und jede Anwendung, die es nutzt, übernimmt automatisch den neuen Wert ohne Codeänderungen oder erneute Bereitstellungen. Aber hier ist der Punkt. Key Vault ist nicht nur ein Passwortmanager für Ihre Anwendungen. Es ist ein zentraler Sicherheitsdienst. Jeder Azure-Dienst kann damit integriert werden. App Service Functions, IKS, Data Factories, Synapse Logic Apps und DevOps Pipelines wissen alle, wie Sie mit Key Vault kommunizieren. Es wird zum Rückgrat Ihrer sicheren Cloud-Architektur. Und sobald Sie es richtig eingerichtet haben, müssen Sie sich überhaupt keine Gedanken mehr über das Anmeldedatenmanagement. Das können Sie speichern. Nachdem Sie nun wissen, was Key Vault ist, lassen Sie uns darüber sprechen, was Sie tatsächlich darin ablegen können. Sie haben drei Hauptkategorien. Geheimnisse, Schlüssel und Zertifikate.

Jede davon erfüllt einen anderen Zweck und das Verständnis dieser Unterschiede hilft Ihnen, Key Vault richtig einzusetzen. Fangen wir mit den Geheimnissen an. Dies ist das, was am häufigsten gespeichert wird. Geheimnisse sind Verbindungszeichenfolgen, API-Schlüssel, Datenbank, Passwörter, Speicherkontoschlüssel, im Grunde alle alltäglichen Anmeldedaten, die Ihre Apps für die Kommunikation mit anderen Diensten benötigen. Anstatt Sie in Ihren Code oder Ihre Konfigurationsdatei zu schreiben, legen Sie sie in Key Vault ab. Ihre App ruft Sie zur Laufzeit ab und niemand sieht Sie jemals im Klartext. Stellen Sie es sich wie eine verschlossene Schublade in Ihrem digitalen Aktenschrank vor. Als nächstes kommen die Schlüssel. Dies sind Verschlüsselungsschlüssel für ruhende Daten. Wenn Sie vom Kunden verwaltete Schlüssel für Azure Storage, SQL-Datenbanken oder die Verschlüsselung von virtuellen Festplatten verwenden, können diese Schlüssel in Key Vault liegen.

Das gibt Ihnen die volle Kontrolle darüber, wer Sie wann verwenden kann. Und wenn Sie hardwarebasierte Schlüssel für Compliance-Anforderungen benötigen, bietet Ihnen der Premium-Tarif-HSM-Schutz. Dann haben wir die Zertifikate. TLS- und SSL-Zertifikate für Ihre Web-Apps, APIs und internen Dienste. Key Vault kann Sie speichern, Ihren Lebenszyklus verwalten und Sie sogar automatisch erneuern, wenn Sie kurz vor dem Ablauf stehen. Das ist ein Lebensretter für jeden, der schon einmal erlebt hat, dass ein Zertifikat an einem Sonntag um drei morgens abgelaufen ist. Hier ist das praktische Beispiel. Stellen Sie sich vor, Sie haben eine Web-App, die eine Datenbankverbindungszeichenfolge und einen API-Schlüssel für einen Drittanbieterdienst benötigt. Auf die alte Weise würden Sie beides in Ihre JSON-App-Einstellungsdatei schreiben. Wenn diese Datei in Ihrem Repository landet, kann jeder mit Zugriff auf den Code Ihre Datenbankanmeldedaten sehen.

Mit Key Vault speichern Sie beide Werte als Geheimnisse. Ihre App ruft Sie beim Start ab und Sie erscheinen niemals in Ihrem Quellcode. Müssen Sie das Datenbankpasswort rotieren? Aktualisieren Sie einfach in Key Vault. Die App übernimmt den neuen Wert automatisch beim nächsten Neustart. Keine Codeänderungen, keine Neutebereitstellung. Was viele überrascht ist, dass eine Versionsverwaltung integriert ist. Wenn Sie ein Geheimnis aktualisieren, überschreibt Key Vault den alten Wert nicht. Es erstellt eine neue Version. Die alten Versionen bleiben erhalten, sodass Sie bei Problemen ein Roarback durchführen können. Das ist bei Vorfällen unglaublich praktisch. Sie können schnell zu einem früheren Geheimnis zurückkehren, ohne sich an den alten Wert erinnern zu müssen. Sie können alle drei Typen Geheimnisse, Schlüssel und Zertifikate im selben Tresor speichern. Die bewährte Methode ist jedoch die Trennung nach Umgebung.

Verwenden Sie ein Tresor für die Entwicklung, einen für Tests und einen für die Produktion. Dies verhindert, dass jemand versehentlich ein Produktionsgeheimnis in einer Entwicklungsumgebung verwendet und begrenzt den Schaden, falls ein Tresor kompromittiert wird, wird. Aber das Speichern von Geheimnissen ist nur die halbe. Die eigentliche Frage ist, wer darauf zugreifen darf. Wie die Zugriffskontrolle funktioniert Lassen Sie unter ursprünglich mehr Zugänge. Keyword bietet zwei verschiedene Möglichkeiten, den Zugriff auf die Inhalte zu steuern und die Wahl ist entscheidend und die Wahl ist entscheidend. Das erste Modell sind Legacy-Zugriffsrichtlinien. Das ist die alte Methode. Sie erstellen Richtlinien direkt im Tresor und weisen bestimmten Benutzern oder Gruppenberechtigungen für bestimmte Datentypen zu Geheimnisse, Schlüssel oder Zertifikate. Das Problem ist, dass diese Richtlinien direkt an den Tresor gebunden sind.

Wenn Sie mehrere Tresore haben, müssen Sie die Richtlinien für jeden Einzelnen verwalten. Das lässt Sie nicht gut skalieren. Microsoft rät inzwischen von deren Verwendung ab, da bekannte Sicherheitsprobleme bestehen. Sie unterstützen kein Privileged Identity Management und können unerwartete Pfade zur Privilegienerweiterung schaffen. Das zweite Modell ist Azure RBAC, die rollenbasierte Zugriffskontrolle. Das ist die moderne Methode. Sie nutzt Entra-ID-Identitäten und ist konsistent mit der Berechtigungsverwaltung an anderen Stellen in Azure. Wenn Sie bereits wissen, wie man Zugriff auf ein Speicherkonto oder eine virtuelle Maschine gewährt, wissen Sie auch, wie man Zugriff auf Key Vault gewährt. Dasselbe System, dieselben Muster. Hier gilt die goldene Regel, das Prinzip der geringsten Privilegien. Geben Sie nur den minimalen Zugriff, den jemand benötigt. Mehr nicht. Wenn jemand nur Geheimnisse lesen muss, geben Sie ihm keine Berechtigung zum Erstellen oder Löschen.

Wenn jemand nur Zertifikate verwalten muss, geben Sie ihm keinen Zugriff auf Schlüsse. Lassen Sie mich die wichtigsten Rollen erläutern. Es gibt den Key Vault Reader. Damit kann man Geheimnisse auflisten, aber ihre Werte nicht lesen. Key Vault Secrets User. Damit kann man tatsächlich Geheimniswerte lesen. Und Key Vault Secrets Officer. Damit kann man Geheimnisse erstellen, aktualisieren und löschen. Achten Sie auf das Muster. Jede Rolle bezieht sich auf die Daten innerhalb des Tresors, nicht auf den Tresor selbst. Stellen Sie denen nun die allgemeinen Rollen gegenüber Besitzer mitwirkender Leser. Diese beziehen sich auf den Tresor als Ressource, nicht auf die Daten daran. Ein Besitzer kann den gesamten Tresor löschen. Ein Mitwirkender kann die Tresoreinstellung ändern. Doch keine dieser Rollen gewährt für sich allein Zugriff auf die enthaltenen Geheimnisse. Das ist eine separate Berechtigungsebene und genau das ist der entscheidende Punkt.

Zugriffskontrolle ist wie eine Torte mit mehreren Schichten. Sie benötigen Zugriff auf den Tresor selbst, das ist die erste Ebene. Und Sie benötigen Zugriff auf die Daten im Tresor, das ist die zweite Ebene. Beides muss separat gewährt werden. Die meisten Anfänger denken nur an die erste Ebene und vergessen die zweite. Da fangen die Probleme an. Der Sicherheitsfehler Nummer eins. Die Sache ist die. Die meisten Leute sehen die Rolle Key Vault Mitwirkender und halten sie für sicher. Sie lesen das Wort Mitwirkender und gehen davon aus, dass sie die Tresoreinstellung verwalten, aber die Geheimnisse daran nicht anfassen können. Die eigene Dokumentation von Microsoft besagte ursprünglich genau das. Diese Rolle erlaubt keinen Zugriff auf Geheimnisse, Schlüssel oder Zertifikate. Nur stimmt das nicht ganz. Ein Benutzer mit der Rolle Key Vault Mitwirkender kann Zugriffsrichtlinien für den Tresor ändern.

Und wenn dieser Tresor noch Legacy-Zugriffsrichtlinien verwendet, was viele tun, können sie sich einfach selbst vollständigen Lesezugriff auf jedes Geheimnis, jeden Schlüssel und jedes Zertifikat darin gewähren. Kein spezieller Exploit nötig, keine Sicherheitslücke, die behoben werden muss. So funktionieren die Berechtigungen. Sicherheitsforscher bei Datadoc bewiesen dies im Jahr 2024. Sie zeigten, dass ein Mitwirkender in jedem Tresor, der Legacy-Zugriffsrichtlinien verwendet, den Zugriff auf alle Daten erzwingen kann. Microsofts Reaktion war interessant. Sie sagten, dies sei keine Sicherheitslücke, da Mitwirkende dazu konzipiert sind, Zugriffsrichtlinien zu verwalten, aktualisierten aber dennoch die Dokumentation, um ausdrücklich davor zu wahren, dass die Rolle sich selbst Datenebene Zugriff gewähren kann. Es ist also kein Fehler im Key Vault selbst, sondern eine Konfigurationsfalle. Und sie erwischt selbst erfahrene Teams, weil der Rollenname harmlos klingt.

Mitwirkender klingt nicht nach jemandem, der ihre Datenbank-Passwörter lesen kann, aber in der Praxis können sie das. Denken Sie an das Risiko. Wenn ein Angreifer ein Konto mit der Rolle Mitwirkende für ihren Key Vault kompromittiert, muss er nicht in den Tresor einbrechen. Er muss keine Verschlüsselung knacken. Er ändert einfach die Zugriffsrichtlinie, gewährt sich Lesezugriff und schleust heimlich jedes gespeicherte Geheimnis aus, Verbindungszeichenfolgen, API-Schlüsselzertifikate, einfach alles. Und da Änderungen an Zugriffsrichtlinien normale administrative Tätigkeiten sind, lösen sie möglicherweise keine Alarme aus. Das ist also die Lösung. Verwenden Sie für den Zugriff auf die Datenebene Azure ABSC Sicherheitsrichtlinien. RBAC trennt die Verwaltung des Tresors von den darin enthaltenen Daten. Zweitens, geben Sie die Rolle Key Vault Mitwirkender niemals jemandem, der Sie nicht unbedingt benötigt.

Drittens, falls Sie bereits Benutzer mit dieser Rolle haben, prüfen Sie diese noch heute. Ersetzen Sie Mitwirkender durch spezifische Rollen wie Key Vault Geheimnisbenutzer oder Key Vault Geheimnisbeauftragter. Es gibt einen zweiten Fehler, der diesen noch verstärkt, alle Geheimnisse in einem einzigen Tresor zu speichern. Wenn Sie einen Tresor für alles nutzen, Entwicklung, Tests, Staging, Produktion und alle Anwendungen und dieser Tresor kompromittiert wird, ist alles gefährdet. Es ist ein Single Point of Fail. Wir werden gleich mehr über eine Multi-Void-Strategie sprechen, aber das Prinzip ist einfach. Legen Sie nicht alle Eier in einen Korb, besonders wenn dieser Korb die Schlüssel zu Ihrer gesamten Infrastruktur enthält. Verwaltet die Identität der Goldstandard. Wie macht man es also richtig? Lassen Sie Sie über den besten Weg für den Zugriff auf den Key Vault. Es gibt ein grundlegendes Problem.

Um Anmeldeinformationen aus dem Key Vault zu erhalten, muss sich Ihre Anwendung authentifizieren. Aber zur Authentifizierung benötigt Sie Anmeldeinformation. Wo speichern Sie die Anmeldeinformation, die Ihre App benötigt, um Anmeldeinformation zu erhalten? Es ist ein Henne-Ei-Problem. Die alte Antwort war ein Dienstprinzipal mit einem Client-Geheimnis. Aber dieses muss irgendwo liegen, vielleicht in einer Konfigurationsdatei, Umgebungsvariablen oder einer Bereitstellungspipeline. Und schon sind Sie wieder beim gleichen Problem. Sie haben das Geheimnis nur an einen anderen Ort verschoben. Die verwaltete Identität löst dies vollständig. So funktioniert es. Wenn Sie die verwaltete Identität für eine Azure-Ressource aktivieren, zum B, eine Web-App, eine Funktion oder eine virtuelle Maschine, erstellt Azure automatisch eine Identität für diese Ressource in N3ID. Diese Identität wird vollständig von Azure verwaltet.

Keine Anmeldeinformationen zu erstellen, keine Geheimnisse zu rotieren, nichts zu speichern. Die Ressource besitzt einfach eine Identität, die Azure bekannt ist. Es gibt zwei Typen. Die systemseitig zugewiesene verwaltete Identität ist an eine bestimmte Ressource gebunden. Wenn Sie die Ressource löschen, verschwindet auch die Identität. Sie teilen sich ein Lebenszyklus, was die Verwaltung vereinfacht. Die benutzerseitig zugewiesene verwaltete Identität ist eine eigenständige Identität, die Sie mehreren Ressourcen zuweisen. Sie teilt sich keinen Lebenszyklus mit diesen, daher ist sie nützlich, wenn Sie dieselbe Identität für mehrere Dienste benötigen. So sieht das in der Praxis aus. Sie haben eine Web-App, die eine Datenbankverbindungszeichenfolge aus dem Key Vault lesen muss. Sie aktivieren die systemseitig zugewiesene verwaltete Identität für die Web-App. Dann erteilen Sie dieser Identität die Rolle Key Vault Geheimnis Benutzer für Ihren Tresor.

Das ist alles. Keine Verbindungszeichenfolge im Code, keine kleinen Geheimnisse im Konfigurationsdatei. Die Web-App authentifiziert sich gegenüber dem Key Vault über ihre verwaltete Identität und Azure übernimmt die gesamte Anmeldedatenverwaltung im Hintergrund. Dies kommt einer anmeldedatenfreien Authentifizierung in Azure am nächsten. Es ist ein entscheidender Vorteil für die Sicherheit, da es den häufigsten Angriffsvektor ausschließt gestohlene Anmeldedaten. Wenn es keine Anmeldedaten zu stehlen gibt, kann ein Angreifer auch nichts kompromittieren. Lassen Sie mich ein Beispiel aus der Praxis nennen. Stellen Sie sich eine Datenpipeline in Synapse vor, die auf ein Speicherkonto zugreifen muss. Früher hätte man den Speicherkontoschlüssel in der Pipeline-Konfiguration gespeichert. Wenn jemand Zugriff auf diese Pipeline erhielt hat, den Schlüssel. Mit einer verwalteten Identität besitzt der Synapse-Arbeitsbereich eine eigene Identität.

Diese Identität wird Zugriff auf den Key Vault gewährt, in dem der Speicherkontoschlüssel gespeichert ist. Die Pipeline ruft den Schlüssel zur Laufzeit ab, verwendet ihn und speichert ihn nirgendwo. Keine Schlüssel im Code, keine Geheimnisse in der Pipeline-Konfiguration. Wenn Sie verwaltete Identitäten mit RBC und dem Prinzip der geringsten Rechte kombinieren, erhalten Sie eine sichere Basis für jede Azure Workload. Ihre Anwendungen authentifizieren sich ohne Anmeldedaten. Sie greifen nur auf das zu, was Sie benötigen und jeder Zugriff wird protokolliert und ist prüfbar. Es ist das Muster, das Microsoft für fast jedes Szenario empfiehlt. Sobald Sie es einmal nutzen, werden Sie sich fragen, warum Sie es jemals anders gemacht haben. Kosten- und Multivahlstrategie. Lassen Sie uns also über Kosten sprechen. Hier sind die meisten Leute überrascht. Wie viel kostet Azure Key Vault eigentlich? Das Preismodell ist einfach.

Es gibt keine Speichergebühr pro Geheim. Sie zahlen nicht für jedes Passwort oder den AP-Schlüssel, den Sie sprechen. Stattdessen zahlen Sie pro Vorgang. Für den Standardtarif sind es etwa 3 Cent pro 10.000 Vorgänge. Ein Aufruf zum Abrufen eines Geheimnisses zählt als infolgt. Ebenso das Erstellen eines Geheimnisses oder das Auflisten des Waldinhalts. Für eine typische kleine bis mittlere Anwendung summiert sich das auf wenige Cent pro Monat. Buchstäblich nur ein paar Cent. Vergleichen Sie das mit dem ABS Secrets Manager. Dort berechnet man 40 Cent pro Geheimnis und Monat allein für die Speicherung plus zusätzliche Gebühren für Abrufe. Wenn Sie 100 Geheimnisse haben, sind das 40 Dollar pro Monat, bevor Sie überhaupt eines davon gelisten. Mit Azure Key Vault könnten 100 Geheimnisse bei moderater Nutzung 15 Cent kosten. Der Unterschied wächst bei größerem Umfang schnell an. Es gibt auch einen Premium-Tarif.

Dieser bietet HSM-gestützte Schlüssel für Workloads, die höchste kryptografische Sicherheit erfordern. Denken Sie an Finanztransaktionen, Gesundheitsdaten oder staatliche Systeme. Die Kosten pro Vorgang sind höher. Etwa 15 Cent pro 10.000 Vorgängen für fortgeschrittene Schlüsseltypen zuzüglich einer monatlichen Gebühr pro HSM-Schlüssel, Schlüssel. Aber für die meisten Anwendungen ist der Standardtarif mehr als ausreichend. Hier ist die Kostenüberraschung, die viele Leute unvorbereitet trippen. Für eine typische Web-App mit einer Handvoll Geheimnissen und ein paar tausend Operationen pro Monat kostet Key Vault weniger als einen Dollar. Sie geben mehr für den Kaffee aus, den Sie während der Einrichtung trinken. Doch es gibt eine Strategie, die wichtiger ist als die Kosten. Wie viele Vaults Sie verwenden. Der intelligente Ansatz ist eine Multi-Vault-Strategie. Verwenden Sie separate Vaults für Entwicklung, Tests, Staging und Produktion.

Dies verhindert den häufigsten Unfall. Jemand führt ein Test-Skript aus, das versehentlich eine Produktionsdatenbank liest, weil die Verbindungszeichenfolge im selben Vault lag. Wenn Umgebungen getrennt sind, wird dieser Fehler unmöglich. Sie sollten auch nach Geschäftseinheiten oder Compliance-Bereichen trennen. Wenn Sie Zahlungskartendaten verarbeiten, legen Sie diese Geheimnisse in einen eigenen Vault. Allgemeine Geschäftsworkloads kommen in einen anderen, Gesundheitsdaten in einen dritten. Es geht nicht darum, es kompliziert zu machen, sondern die Schadensradius zu begrenzen. Wenn ein Vault kompromittiert wird, sind nur die Geheimnisse in diesem Vault betroffen. Der Rest Ihrer Infrastruktur bleibt sicher. Und zwei integrierte Sicherheitsnetze, die Sie marktivieren sollten. Soft-Delete bedeutet, wenn jemand ein Geheimnis löscht, ist es nicht dauerhaft weg. Es geht in einen wiederherstellbaren Zustand für einen Zeitraum Ihrer Wahl bis zu 90 Tage, bis zu 90 Tage.

Der Lash-Schutz, Perch-Protection geht noch ein Schritt weiter. Niemand kann den Vault oder dessen Inhalt dauerhaft löschen, bis dieser Aufbewahrungszeitraum abgelaufen ist. Zusammen verhindern Sie die Art von versehentlichem Datenverlust, die Sicherheitsteams um den Schlaf bringt. Wie alles zusammenhängt. Führen wir das alles zusammen und sehen, wie die Teile ineinander greifen. Key Vault ist keine Insel. Es ist das zentrale Nervensystem für Geheimnisse in Ihrer Azure-Architektur. Wenn Sie verstehen, wie das gesamte System funktioniert, ergibt alles einen Sinn. Hier ist was passiert, wenn eine Anwendung ein Geheimnis benötigt. Die Anwendung fordert es unter Verwendung Ihrer verwalteten Identität an. Diese Identität ist bereits in EntraID registriert. Azure hat sie automatisch erstellt, als Sie die verwaltete Identität für die Ressource aktiviert haben. EntraID validiert die Legitimität der Identität und leitet die Anfrage an Key Vault weiter.

Key Vault prüft die Erberechtigung, die Sie zugewiesen haben. Wenn die Identität die richtige Rolle hat, wie Key Vault Secrets User, wird das Geheimnis zurückgegeben. All das geschieht in Millisekunden. Die Anwendung sieht niemals einer mit dem Informationspaar. Sie speichern niemals ein Passwort. Sie erhält einfach den Wert, den Sie benötigt. Denken Sie nun daran, wie viele Azure-Dienste dies nutzen können. App Service Functions, AKS, Data Factory, Synapse Logic Apps, DevOps Pipelines, DevOps Pipelines. Sie alle wissen, wie man mit Key Vault kommuniziert. Sie können eine Web-App so konfigurieren, dass Sie direkt in Ihren Anwendungseinstellungen auf ein Geheimnis verweist. Sie können eine Data Factory Pipeline so einrichten, dass Sie zur Laufzeit einen Storage-Account-Schlüssel aus Key Vault ab. Sie können einen Kubernetes-Cluster so konfigurieren, dass er Geheimnisse über den Key Vault-CSI-Treiber abruft.

Jeder Dienst integriert sich auf die gleiche Weise. Unter Verwendung desselben Identitätssystems, derselben ABA-C-Rollen und derselben Audit-Protokollierung. Das CI-CD-Muster ist besonders leistungsfähig. Ihre Pipelines rufen Geheimnisse zum Zeitpunkt der Bereitstellung aus dem Key Vault. Sie speichern diese niemals in Pipeline-Variablen oder Repository-Secrets. Wenn Sie ein Datenbank-Passwort rotieren müssen, aktualisieren Sie es einfach im Key Vault. Beim nächsten Durchlauf Ihrer Pipeline wird der neue Wert automatisch übernommen. Keine Pipeline-Änderung, keine Code-Anpassung, keine erneuten Bereitstellung. Hier ist der Punkt, der alles verständlich macht. Sobald Sie Key Vault mit verwalteter Identität und RBRC eingerichtet haben, müssen Sie sich nicht mehr um die Anmeldeinformationsverwaltung kümmern. Ihre Anwendungen funktionieren einfach. Geheimnisse werden rotiert, ohne dass es jemand merkt.

Zertifikate erneuern sich ohne Notfälle mit Nennen. Das System erledigt das alles im Hintergrund. Das ist die Sicherheitslage, auf die es ankommt. Die Identität ist der Perimeter, nicht das Netzwerk. Es spielt keine Rolle, ob jemand innerhalb oder außerhalb Ihres virtuellen Netzwerks ist. Wichtig ist nur, ob die Person eine gültige Identität mit den richtigen Berechtigungen besitzt. Key Vault erzwingt dies durch sein Design. Jede Zugriffsanfrage durchläuft die Entra-ID-Authentifizierung und RBRC-Autorisierung, egal woher die Anfrage kommt. Und alles wird protokolliert. Jeder Lesezugriff auf Geheimnisse, jeder Schlüsselvorgang, jede Zertifikatserfolg. Sie können sehen, wer wann auf was zugegriffen hat. Wenn etwas verdächtig aussieht, haben Sie die Daten für eine Untersuchung. Dies ist entscheidend für die Compliance, die Reaktion auf Vorfälle und um einfach zu wissen, was in Ihrer Umgebung geschieht.

Das ist schön an der ganzen Sache. Key Vault, Entra-ID, ABS-C und verwaltete Identitäten arbeiten als einheitliches Sicherheitsframework zusammen. Jedes Element steckt die anderen. Und wenn alles korrekt eingerichtet ist, haben Sie ein Verwaltungssystem für Anmeldeinformationen, das sicherer und einfacher zu betreiben ist, als alles, was Sie selbst aufbauen könnten oder gönnten. Praktische Erkenntnisse. Was sollten Sie also jetzt konkret tun? Lassen Sie uns dieses Wissen in Taten umsetzen. Hier sind die Aufgaben, die Sie diese Woche angehen können. Beginnen Sie mit Ihrem Berechtigungsmodell. Öffnen Sie Ihren Key Vault im Portal, gehen Sie zur Zugriffskonfiguration und prüfen Sie die Einstellung. Wenn Sie Vault-Zugriffsrichtlinien sehen, ist das der alte Weg. Wir möchten stattdessen die rollenbasierte Zugriffssteuerung von Azure nutzen. Die Migration ist einfach. Wechseln Sie das Berechtigungsmodell und weisen Sie die RBAC-Rollen denselben Personen zu, die bereits Zugriffsrichtlinien hatten.

Tun Sie es noch halt. Microsoft empfiehlt dies und unsere Untersuchung hat genau gezeigt, warum. Überprüfen Sie als nächstes alle Konten, die die Rolle Key Vault-Mitwirkender innehaben. Öffnen Sie das IAM-Blade Ihres Vaults und sehen Sie nach, wer mitwirkende Zugriff hat. Jede Person mit dieser Rolle benötigt einen guten Grund dafür. Meistens tun Sie das nicht. Ersetzen Sie Mitwirkender durch etwas Spezifischeres. Wenn jemand nur Geheimnisse lesen muss, geben Sie ihm die Rolle Key Vault-Geheimnisbenutzer. Wenn er Geheimnisse verwalten muss, verwenden Sie Key Vault-Geheimnisbeauftragter. Das Ziel ist, dass diesen Eskalationspfad vollständig ist zu schließen. Nutzen Sie anschließend verwaltete Identitäten. Jeder Azure-Dienst, der Zugriff auf Key Vault benötigt, sollte diese verwenden. Wenn Sie eine Web-App, eine Funktion, eine Data Factory oder einen virtuellen Computer haben, der noch einen Dienstprinzipal mit Client-Geheimnis verwendet, wechseln Sie zu einer verwalteten Identität.

Es ist einfacher, sicherer und löst das zuvor besprochene HEN-Ei-Problem. Er übernimmt die Anmeld-Informationsverwaltung im Hintergrund für Sie. Noch etwas. Aktivieren Sie das vorläufige Löschen und den Bereinigungsschutz für jeden Tresor. Das vorläufige Löschen ist bei neuen Tresoren standardmäßig aktiviert, der Bereinigungsschutz jedoch nicht. Schalten Sie ein. Diese Einstellung verhindert, dass jemand einen Tresor oder dessen Inhalt während des Aufbewahrungszeitraums dauerhaft löscht. Sie hat schon so manches Team vor einem katastrophalen Fehler bewahrt. Hier ist Ihre Handlungsaufforderung. Überprüfen Sie Ihren aktuellen Ansatz zur Verwaltung. Finden Sie ein Geheimnis, das noch in einer Konfigurationsdatei einer Umgebungsvariablen oder fest im Code steht. Verschieben Sie es diese Woche in den Key Vault. Nein. Sobald Sie sehen, wie einfach es ist, werden Sie den Rest ebenfalls verschieben.

Einrichtung. Es ist eine ständige Praxis. Key Vault erleichtert diese Praxis aber nur, wenn Sie es korrekt verwenden. Die Werkzeuge sind vorhanden. Die Muster sind bewährt. Jetzt liegt es an Ihnen, Sie umzusetzen. Das ist das System. Key Vault ist Ihr digitaler Safe, aber er ist nur so sicher wie die Zugriffskontrollen, die Sie da rumherum aufbauen. Beginnen Sie mit dem Audit, das ich gerade beschrieben habe. Überprüfen Sie Ihr Bewechtigungsmodell. Überprüfen Sie Ihre Zuweisungen für Mitwirkende und verschieben Sie diese Woche ein Geheimnis in ein Tresor. Abonnieren Sie für weitere Cloud-Sicherheitstipps in einfachem Deutsch und teilen Sie dies mit jemandem, der Geheimnis immer noch in Konfigurationsdateien speichert.