Secrets Management Automation: Der praktische Leitfaden für 3-Tier Systeme

Tatsächlich verwaltet eine durchschnittliche Person heute 168 Passwörter, mit steigender Tendenz. Diese beeindruckende Zahl verdeutlicht, warum Secrets Management Automation in modernen IT-Umgebungen unverzichtbar geworden ist.

Darüber hinaus zeigt die Praxis, dass ein strukturiertes Secrets Management System mit drei Ebenen - von convenience-orientierten Zugangsdaten bis hin zu höchst sensiblen Informationen - erhebliche Vorteile bietet. Ein solches System kann beispielsweise bis zu 700 Passwörter in der untersten Ebene, 100 in der mittleren und 5-10 in der obersten Sicherheitsebene effektiv verwalten.

Dieser praktische Leitfaden erklärt, wie Unternehmen ein robustes 3-Tier System für ihr Secrets Management implementieren können, um sowohl Sicherheit als auch Benutzerfreundlichkeit zu gewährleisten. Dabei wird besonders auf die Automatisierung der Prozesse und die spezifischen Anforderungen jeder Systemebene eingegangen.

Grundlagen des Secrets Management in 3-Tier Systemen

Die Verwaltung sensibler Zugangsdaten in modernen IT-Umgebungen erfordert eine strukturierte Herangehensweise. Ein systematisches Verständnis der Architektur bildet hierbei die Grundlage für eine effektive Implementierung von Secrets Management Automation. Um dieses Verständnis zu entwickeln, betrachten wir zunächst die grundlegende Architektur, in der diese Prozesse stattfinden.

Was sind 3-Tier Systeme?

Die 3-Tier Architektur ist ein etabliertes Konzept im Softwaredesign, das Anwendungen in drei logische und physische Rechenebenen unterteilt. Diese klare Trennung bildet das Fundament für ein effektives Secrets Management System. In einer 3-Tier Architektur finden wir folgende Ebenen:

Präsentationsebene (Presentation Tier): Diese oberste Schicht bildet die Benutzeroberfläche und Kommunikationsschicht der Anwendung, über die Endbenutzer mit dem System interagieren. Ihre Hauptaufgabe besteht darin, Informationen anzuzeigen und vom Benutzer zu erfassen. Diese Ebene kann als Webbrowser, Desktop-Anwendung oder grafische Benutzeroberfläche (GUI) ausgeführt werden. Web-Präsentationsebenen werden typischerweise mit HTML, CSS und JavaScript entwickelt.

Anwendungsebene (Application/Logic Tier): Als Herzstück der Anwendung verarbeitet diese mittlere Ebene die in der Präsentationsebene gesammelten Informationen – manchmal gegen andere Daten in der Datenebene – und wendet dabei Geschäftslogik an. Diese Ebene kann auch Daten in der Datenebene hinzufügen, löschen oder ändern. Die Anwendungsebene wird üblicherweise mit Programmiersprachen wie Python, Java, Perl, PHP oder Ruby entwickelt und kommuniziert mit der Datenebene über API-Aufrufe.

Datenebene (Data Tier): Diese unterste Schicht, auch als Datenbankebene bezeichnet, ist für die Speicherung und Verwaltung aller Informationen zuständig, die von der Anwendung verarbeitet werden. In einer 3-Tier-Anwendung läuft die gesamte Kommunikation über die Anwendungsebene. Die Präsentationsebene und die Datenebene können nicht direkt miteinander kommunizieren.

Der wesentliche Vorteil dieser Architektur liegt in der logischen und physischen Trennung der Funktionalität. Jede Ebene kann auf einer separaten Betriebssystem- und Serverplattform ausgeführt werden, die optimal zu ihren funktionalen Anforderungen passt. Darüber hinaus wird jede Ebene auf mindestens einem dedizierten Hardware-Server oder einem virtuellen Server ausgeführt, sodass die Dienste jeder Ebene angepasst und optimiert werden können, ohne die anderen Ebenen zu beeinträchtigen.

Für die Secrets Management Automation bietet diese Architektur entscheidende Vorteile:

• Jede Ebene kann unabhängig skaliert werden, um erhöhte Lasten oder Anforderungen zu bewältigen

• Änderungen an einer Ebene haben oft minimale Auswirkungen auf die anderen, was die Modifikation, Aktualisierung oder Fehlersuche bestimmter Anwendungskomponenten erleichtert

• Technologien innerhalb einzelner Ebenen können aktualisiert oder ersetzt werden, ohne das gesamte System zu überholen

Typische Secrets in jeder Systemebene

In jeder Ebene der 3-Tier Architektur werden unterschiedliche Arten von Secrets verwendet, die jeweils spezifische Schutzmaßnahmen erfordern. Als "Secrets" bezeichnet man digitale Zugangsdaten wie Passwörter, API-Schlüssel, Verschlüsselungsschlüssel, SSH-Schlüssel, Token und ähnliche sensible Informationen. Diese werden sowohl für die Verwaltung von Zugriffsberechtigungen auf Ebene der Mensch-zu-Anwendung- als auch der Anwendung-zu-Anwendung-Interaktion verwendet.

Präsentationsebene: In dieser Ebene finden sich hauptsächlich Secrets, die den Zugriff auf die Benutzeroberfläche und die Interaktion mit dem System steuern:

• Benutzeranmeldedaten: Passwörter und Benutzernamen für Endbenutzer, die auf das Frontend zugreifen

• API-Schlüssel für Frontend-Services: Schlüssel für Drittanbieter-Dienste, die in die Benutzeroberfläche integriert sind, wie Kartendienste oder Payment-Provider

• Session-Token: Temporäre Credentials, die nach der Authentifizierung für die laufende Sitzung verwendet werden

Anwendungsebene: Die mittlere Ebene enthält einige der kritischsten Secrets, da sie den Zugriff auf Geschäftslogik und Datenverarbeitung steuern:

• Service-to-Service Authentifizierung: Credentials, die verschiedene Dienste innerhalb der Anwendungsebene oder zwischen Anwendungs- und Datenebene verwenden

• API-Schlüssel: Werden zur Authentifizierung von Anwendungen verwendet und gewähren Zugriff auf verschiedene APIs

• Verschlüsselungsschlüssel: Dienen zur Verschlüsselung und Entschlüsselung von Daten und sichern deren Vertraulichkeit

• Zertifikate und Token: Werden für verschiedene Zwecke verwendet, einschließlich der Authentifizierung von Benutzern, der Gewährung von Zugriff auf Ressourcen und der Sicherung von Kommunikation

Datenebene: In dieser Ebene finden sich Secrets, die den Zugriff auf sensible Daten steuern:

• Datenbankanmeldedaten: Benutzernamen und Passwörter für den Zugriff auf Datenbanken

• Backup-Credentials: Zugangsdaten für Backup-Systeme und -Dienste

• Storage-Zugriffsschlüssel: Schlüssel für den Zugriff auf Speichersysteme wie SAN (Storage Area Network) oder NAS

Jedes dieser Secrets durchläuft in der Regel vier Hauptphasen während seines Lebenszyklus:

1. Erstellung: Secrets können entweder manuell von einem Benutzer erstellt (ein Passwort für ein persönliches Konto) oder automatisch generiert werden (ein Verschlüsselungsschlüssel zum Entschlüsseln einer geschützten Datenbank).

2. Speicherung: Secrets können zentral oder separat gespeichert werden, wobei spezielle Lösungen (ein PAM-basiertes Secrets Management Tool oder ein Passwort-Manager) oder gängige Ansätze (in einer Textdatei, auf einer gemeinsamen Festplatte usw.) zum Einsatz kommen.

3. Rotation: Secrets können nach einem Zeitplan geändert oder zurückgesetzt werden, wodurch die Gesamtsicherheit der Infrastruktur einer Organisation verbessert wird.

4. Widerruf: Secrets können im Falle eines Cybersicherheitsvorfalls widerrufen werden.

Herausforderungen bei verteilten Architekturen

Die Verwaltung von Secrets in 3-Tier Systemen bringt spezifische Herausforderungen mit sich, besonders wenn diese Systeme verteilt und komplex sind. Diese Herausforderungen erfordern durchdachte Lösungsansätze für eine effektive Secrets Management Automation.

Mangelnde Transparenz: Bei einer ständig wechselnden Anzahl von Systemen, Ressourcen, Konten und Anwendungen ändern sich auch die Anzahl und die Standorte der Secrets. Ohne klare Transparenz wird eine Organisation nicht in der Lage sein, Secrets effektiv und sicher zu verwalten. Außerdem können Transparenzlücken zusätzliche Herausforderungen für Audits schaffen.

Fehlende Secrets-Management-Richtlinie: Das Festlegen klarer Regeln in Sicherheitsrichtlinien erleichtert die Kontrolle der verschiedenen Phasen im Lebenszyklus eines Secrets und hilft Organisationen, die Anforderungen von Sicherheitsvorschriften zu erfüllen. Allerdings verfügen viele Organisationen nicht über eine solche Richtlinie oder befolgen sie nicht ordnungsgemäß.

Manuelle Verwaltung: Laut einer von Centrify durchgeführten Umfrage verwenden 52% der Organisationen keine Passwort-Tresore oder andere dedizierte Secrets-Management-Tools oder -Systeme zur Verwaltung ihrer digitalen Zugangsdaten. Dies verlangsamt den Verwaltungsprozess und kann sowohl die Speicherung als auch die Übertragung von Schlüsseln weniger sicher machen.

Hardcodierte Zugangsdaten: Hardcodierte oder eingebettete Zugangsdaten in Anwendungen oder Skripten sind eine gängige Praxis, insbesondere in älteren Systemen. Dies stellt ein erhebliches Sicherheitsrisiko dar, da es Secrets für jeden zugänglich macht, der Zugriff auf den Code hat.

Herausforderungen bei der Cloud-Integration: Mit der Verlagerung ihrer Aktivitäten in die Cloud müssen Unternehmen auch eine neue Reihe von Secrets verwalten, die mit Cloud-Computing-Privilegien zusammenhängen. Diese Secrets, zu denen Zugriffsschlüssel und Token gehören, werden aufgrund des Zugriffsniveaus, das sie bieten, oft von Cyberkriminellen ins Visier genommen. Die Verwaltung dieser Secrets kann komplex sein, insbesondere in Multi-Cloud-Umgebungen.

Sichere Speicherung: Secrets müssen sicher gespeichert werden, um unbefugten Zugriff zu verhindern. Dies kann in Cloud-Umgebungen schwierig sein, wo Secrets möglicherweise über mehrere Server und Standorte hinweg gespeichert werden.

Zugriffssteuerung: Es ist wichtig, angemessene Zugriffskontrollen einzurichten, um sicherzustellen, dass nur autorisierte Personen oder Systeme Zugriff auf Secrets haben.

Verteilung: Secrets müssen an die Systeme und Personen verteilt werden, die sie benötigen, während gleichzeitig die Sicherheit aufrechterhalten wird.

Skalierung: Die Verwaltung von Secrets in großem Maßstab kann eine Herausforderung darstellen, da die Anzahl der Secrets und die Anzahl der Systeme, die Zugriff auf sie benötigen, schnell wachsen kann.

Prüfung und Überwachung: Es ist wichtig, die Nutzung von Secrets verfolgen und überprüfen zu können, um Missbrauch zu erkennen und zu verhindern.

Automatisierung: Die Automatisierung des Secrets Managements kann schwierig sein, insbesondere in einer dynamischen, cloudbasierten Umgebung.

Compliance: Je nach Branche und Standort kann es spezifische Vorschriften und Compliance-Anforderungen geben, die bei der Speicherung und Verwaltung von Secrets erfüllt werden müssen.

Rotation: Secrets müssen regelmäßig rotiert werden, um das Risiko eines unbefugten Zugriffs zu minimieren.

Integration: Das Secrets Management sollte mit anderen Sicherheitsmaßnahmen und -systemen in der Organisation integriert werden, wie z.B. Identitäts- und Zugriffsmanagement sowie Sicherheitsvorfall- und Ereignismanagement.

Besonders herausfordernd ist die Tatsache, dass in verteilten 3-Tier Architekturen Dienste oft dieselben Secrets gemeinsam nutzen, was die Identifizierung der Quelle einer

Implementierung von Secrets Management pro Systemebene

Die praktische Umsetzung eines effektiven Secrets Management erfordert spezifische Maßnahmen für jede Ebene einer 3-Tier Architektur. Jede dieser Ebenen weist einzigartige Sicherheitsanforderungen auf, die durch maßgeschneiderte Ansätze adressiert werden müssen. Durch die Implementierung ebenenspezifischer Strategien können Unternehmen ihre gesamte Sicherheitsarchitektur erheblich verbessern.

Präsentationsebene: Frontend-Secrets sicher verwalten

Die Präsentationsebene stellt besondere Herausforderungen für das Secrets Management dar, da hier direkte Interaktionen mit Endbenutzern stattfinden. Für die Präsentationsebene ist es zunächst wichtig zu verstehen, dass API-Schlüssel und andere Secrets, die nicht ordnungsgemäß gespeichert werden, erhebliche finanzielle, regulatorische oder rufschädigende Auswirkungen haben können.

Eine häufige, aber unsichere Praxis ist das direkte Einbetten von Secrets in den Quellcode. Diese Methode ist äußerst riskant, da die Zugangsdaten leicht mit Entwicklertools aus dem Browser extrahiert werden können. Ebenso problematisch ist die Speicherung von Secrets in öffentlichen Repositories - selbst bei privaten Repositories verwenden Hacker oft GitHub-Crawler, um nach Zugangsdaten zu suchen.

Bessere Ansätze für die Frontend-Sicherheit:

1. .env-Dateien: Eine gängige Methode zur Speicherung von Secrets ist die Verwendung von .env-Dateien, die nicht direkt im Code stehen. Durch Hinzufügen dieser Dateien zur .gitignore werden sie nicht in die Versionskontrolle aufgenommen.

2. Umgebungsvariablen: Moderne Anwendungen verwenden Umgebungsdateien, um sensible Werte zu definieren und zu laden, anstatt sie im Code fest zu verankern.

Allerdings ist wichtig zu beachten, dass selbst bei Verwendung von .env-Dateien die API-Schlüssel weiterhin in den Browser-Entwicklertools sichtbar sein können und Teil des Builds werden. Darüber hinaus sollten empfindliche Daten generell verschlüsselt und Tokens nicht im localStorage gespeichert werden.

Für eine wirklich sichere Implementierung sind folgende zusätzliche Maßnahmen sinnvoll:

• Nutzungsbeschränkungen für API-Schlüssel: Viele API-Anbieter ermöglichen die Einschränkung der API-Nutzung durch Festlegung eines täglichen Limits oder durch Spezifizierung bestimmter URLs, von denen aus der API-Schlüssel zugänglich sein soll.

• Secret-Scanning-Tools: Diese Tools scannen Git-Commits in Remote-Repositories auf versehentlich übermittelte Secrets. Sie können auf GitHub, GitLab oder Bitbucket eingesetzt werden.

• Sofortiges Zurücksetzen kompromittierter Secrets: Wenn API-Zugangsdaten in ein Git-Repository hochgeladen wurden, sollte der Schlüssel so schnell wie möglich zurückgesetzt werden.

Anwendungsebene: Service-to-Service Authentifizierung

Die Anwendungsebene, das Herzstück einer 3-Tier-Architektur, erfordert robuste Methoden für die sichere Kommunikation zwischen verschiedenen Diensten. Service-to-Service (S2S) Authentifizierung ist besonders für Szenarien geeignet, in denen Integrationen ohne Benutzerinteraktion ausgeführt werden müssen.

S2S-Authentifizierung verwendet den Client Credentials OAuth 2.0 Flow, der den Zugriff auf Ressourcen mithilfe der Identität einer Anwendung ermöglicht. Im Gegensatz dazu können OAuth-Delegierungsflows wie Autorisierungscode, impliziter Grant-Flow und Ressourcenbesitzer-Passwort-Anmeldeinformationen so konfiguriert werden, dass sie Multifaktor-Authentifizierung (MFA) erfordern.

Implementierungsansätze für S2S-Authentifizierung:

Die S2S-Authentifizierung ermöglicht zwei Hauptszenarien:

1. Unternehmenseinrichtung mittels Automatisierungs-API: Automatisierungs-APIs bieten die Möglichkeit, die Unternehmenseinrichtung durch APIs zu automatisieren. Diese APIs werden verwendet, um Mandanten auf einen Anfangszustand zu bringen.

2. Externer Benutzer- und nicht-interaktiver Benutzerzugriff auf APIs und Webdienste: S2S-Authentifizierung ermöglicht sowohl externen Benutzer- als auch nicht-interaktiven Benutzerzugriff auf Business Central Online.

Bei der Einrichtung einer Microsoft Entra-Anwendung für S2S-Authentifizierung müssen spezifische Informationen angegeben werden, einschließlich eines eindeutigen Namens, unterstützter Kontotypen und optionaler Umleitungs-URI. Außerdem muss ein Client-Secret für die registrierte Anwendung erstellt werden.

Insbesondere sollte darauf geachtet werden, dass Anwendungen dem Least-Privilege-Prinzip folgen und nur die für die Integration erforderlichen Berechtigungen erhalten. Dies entspricht der sicherheitstechnischen Best Practice, nur die minimal notwendigen Rechte zu vergeben.

Für die Bewilligung der Anwendung sind zwei Möglichkeiten verfügbar:

• Administratorzustimmung im Azure-Portal

• Zustimmung vom Business Central-Webclient

Ein wichtiger Aspekt der S2S-Authentifizierung ist die Behandlung von Zugriffstokens. Bei der Beschaffung von Zugriffstokens ist es wichtig, die Sicherheit im Auge zu behalten und sicherzustellen, dass die Tokens nicht offengelegt werden.

Datenebene: Datenbank-Credentials und Verschlüsselungsschlüssel

Die Datenebene enthält einige der sensibelsten Informationen eines Unternehmens, weshalb hier besonders strikte Sicherheitsmaßnahmen erforderlich sind. Datenbankanmeldedaten und Verschlüsselungsschlüssel sind typische Anwendungsfälle für Secrets in dieser Ebene.

Verschlüsselungsschlüssel-Management:

Ein hierarchisches Schlüsselmodell bietet einen Rahmen für die Verwaltung von Verschlüsselungsschlüsseln. In der Sicherheitsterminologie bezeichnet man einen übergeordneten Schlüssel, der alle untergeordneten Schlüssel verschlüsselt, als 'Wrapping'.

Ein solches hierarchisches Modell kann aus vier Schlüsselebenen bestehen:

• Root-Schlüssel

• Konto-Masterschlüssel

• Tabellen-Masterschlüssel

• Datei-Schlüssel

In einem mandantenfähigen Cloud-Service isoliert das hierarchische Schlüsselmodell jedes Konto durch die Verwendung separater Konto-Masterschlüssel. Dies reduziert den Umfang jeder Schlüsselebene. Beispielsweise verschlüsselt ein Tabellen-Masterschlüssel eine einzelne Tabelle, während ein Datei-Schlüssel eine einzelne Datei verschlüsselt.

Automatisierte Schlüsselrotation:

Für maximale Sicherheit sollten alle Schlüssel automatisch rotiert werden, wenn sie älter als 30 Tage sind. Dabei werden aktive Schlüssel zurückgezogen und neue Schlüssel erstellt. Wenn festgestellt wird, dass der zurückgezogene Schlüssel nicht mehr benötigt wird, wird er automatisch vernichtet.

Die Status eines Schlüssels können sein:

• Aktiv: Der Schlüssel wird zur Verschlüsselung von Daten verwendet und steht dem Kunden zur Verfügung.

• Zurückgezogen: Der Schlüssel wird ausschließlich zur Entschlüsselung von Daten verwendet und steht nur für den Zugriff auf die Daten zur Verfügung.

Die regelmäßige Schlüsselrotation begrenzt den Lebenszyklus der Schlüssel auf einen begrenzten Zeitraum. Periodisches Neuverschlüsseln vervollständigt den Lebenszyklus. Wenn das periodische Neuverschlüsseln aktiviert ist, wird automatisch ein neuer Verschlüsselungsschlüssel erstellt und alle zuvor durch den zurückgezogenen Schlüssel geschützten Daten mit dem neuen Schlüssel neu verschlüsselt.

Kundenverwaltete Schlüssel:

Ein von Kunden verwalteter Schlüssel (Customer-Managed Key, CMK) ist ein Master-Verschlüsselungsschlüssel, den der Kunde im Schlüsselverwaltungsdienst für den Cloud-Anbieter verwaltet. Dieser CMK kann dann mit einem vom System verwalteten Schlüssel kombiniert werden, um einen zusammengesetzten Masterschlüssel zu erstellen.

Zu den Vorteilen kundenverwalteter Schlüssel gehören:

• Kontrolle über den Datenzugriff: Vollständige Kontrolle über den Masterschlüssel im Schlüsselverwaltungsdienst und damit über die Daten.

• Reaktion auf Sicherheitsverletzungen: Bei einer Sicherheitsverletzung kann der Zugriff auf den Schlüssel deaktiviert und alle Datenoperationen gestoppt werden.

Allerdings müssen bei der Verwendung kundenverwalteter Schlüssel wichtige Verantwortlichkeiten beachtet werden:

• Der Schlüssel muss jederzeit sicher und vertraulich gehalten werden.

• Der Schlüssel muss vor unbefugter Änderung oder Löschung geschützt werden.

• Um Abfragen auszuführen und auf die Daten zuzugreifen, muss der Schlüssel für das System kontinuierlich verfügbar sein.

AWS Secrets Manager:

Bei containerisierten Anwendungen muss das Secrets Management nahtlos in Orchestrierungsplattformen wie Kubernetes integriert werden. Hier bieten sich plattformeigene Lösungen zur Sicherung von Secrets an:

# Kubernetes Secret mit RBAC und HashiCorp Vault-Integration
apiVersion: v1
kind: Secret
metadata:
name: api-secrets
namespace: production
annotations:
vault.hashicorp.com/agent-inject: "true" vault.hashicorp.com/agent-inject-secret-config: "secret/data/api"
type: Opaque
---
apiVersion: v1
kind: Pod
metadata:
name: api-service
spec:
serviceAccountName: api-service-account # RBAC-kontrolliert
containers:
- name: api
image: my-api:latest
env:
- name: API_KEY
valueFrom:
secretKeyRef:
name: api-secrets
key: api-key

Für AWS-Anwendungen integriert sich AWS Secrets Manager nahtlos und rotiert Anmeldedaten automatisch nach einem definierten Zeitplan. Anwendungen rufen Secrets zur Laufzeit ab und stellen so sicher, dass sie Zugriff auf aktuelle Werte haben. Durch die Verwendung von AWS Secrets Manager werden Secrets nicht im Code hartcodiert, und man erhält Funktionen wie verschlüsselte Speicherung, Auditprotokolle und automatisierte Rotation.

Das Verschlüsselungs-Schlüsselmanagement ist ideal für den Schutz sensibler Daten mit zentralisierter Schlüsselverwaltung und einfachen APIs für die Datenverschlüsselung. Beispiele für dieses Schlüsselmanagement sind die Verwendung von Hashicorp Vault (Open Source) oder, wenn Sie öffentliche Cloud (Closed Source) verwenden, die am häufigsten verwendeten Closed-Source-Schlüsselverwaltungssysteme wie Amazon Web Service (AWS) Key Management Service (KMS), Google Cloud KMS und 

Automatisierung des Secrets Lifecycle

Die Effizienz eines Secrets Management Systems hängt maßgeblich davon ab, wie gut die verschiedenen Phasen im Lebenszyklus eines Secrets automatisiert werden können. Automatisierung reduziert nicht nur den manuellen Aufwand, sondern minimiert auch das Risiko menschlicher Fehler erheblich, die bei der Verwaltung sensibler Zugangsdaten besonders kritisch sein können.

Secrets Rotation implementieren

Die regelmäßige Rotation von Secrets ist ein methodischer Ansatz, bei dem bestehende Zugangsdaten durch neu generierte ersetzt werden, um die Sicherheit zu maximieren. Entgegen der verbreiteten Meinung geht es hierbei nicht nur um häufige Passwortänderungen, sondern um einen systematischen Prozess, der je nach Komplexität des Netzwerks und Sensibilität der Daten unterschiedlich gestaltet sein kann.

Für die Implementierung einer automatisierten Secrets Rotation stehen verschiedene Tools wie HashiCorp Vault oder Doppler zur Verfügung. Diese Tools erleichtern den Rotationsprozess erheblich und können an die spezifischen Anforderungen eines Unternehmens angepasst werden.

Schritte zur erfolgreichen Implementierung:

1. Rotationsstrategie definieren: Basierend auf internen Richtlinien sollte festgelegt werden, wie oft Secrets rotiert werden sollen. AWS empfiehlt beispielsweise, Root-Benutzerzugriffsschlüssel regelmäßig zu ändern, um die Sicherheit zu erhöhen.

2. Rotationsworkflows testen: Für jeden Secret-Typ sollten spezifische Rotationsabläufe getestet werden, da der Prozess je nach Art des Secrets unterschiedlich sein kann.

3. Prozess für Anwendungsdeployment etablieren: Nach der Rotation ist es wichtig, einen automatisierten Workflow zu implementieren, der die neuesten Secret-Versionen in den Anwendungen bereitstellt.

Besonders praktisch ist die Einrichtung einer automatischen Rotation. Viele Cloud-Dienste bieten diese Funktion an. Bei AWS Secrets Manager können Benutzer beispielsweise alternating users rotation implementieren – eine Strategie, bei der Secrets Manager den Benutzer klont und dann abwechselnd die Anmeldeinformationen der Benutzer aktualisiert. Diese Methode eignet sich besonders für Hochverfügbarkeitsanforderungen, da einer der abwechselnden Benutzer immer über aktuelle Anmeldeinformationen für die Datenbank verfügt, während der andere aktualisiert wird.

Zudem unterstützen moderne Plattformen wie Kong die automatische Rotation von Secrets einmal pro Minute im Hintergrund. Dies entkoppelt den Rotationsprozess vom Proxy-Betrieb. Allerdings bedeutet die Aktualisierungsrate von einmal pro Minute, dass ein Secret mit einer TTL von 30 Sekunden im ungünstigsten Fall bis zu 60 Sekunden bis zur Aktualisierung benötigen kann.

Bei der Rotation mit TTLs ist es normalerweise sinnvoll, zwei Versionen desselben Secrets gleichzeitig gültig zu haben. Dies bedeutet, dass während der Secrets Rotation folgende Schritte auftreten:

1. Ein neues Secret wird erstellt, was zu drei gültigen führt

2. Alle drei Secrets werden verifiziert

3. Das älteste Secret wird entfernt oder ungültig gemacht, was zu zwei gültigen führt

Integration in CI/CD-Pipelines

Die Integration von Secrets Management in CI/CD-Pipelines ist entscheidend für die Aufrechterhaltung der Sicherheit während des gesamten Entwicklungs- und Bereitstellungsprozesses. Hierbei ist es besonders wichtig, dass Secrets niemals im Klartext zugänglich sind, selbst für Entwickler nicht.

Viele Unternehmen übertragen Secrets in ihren Pipelines über Umgebungsvariablen, damit Benutzer diese in ihren Automatisierungen und API-Aufrufen verwenden können. Das Problem dabei ist, dass alle Secrets transparent sind – jeder kann sie einfach ausgeben und verwenden, was ein erhebliches Sicherheitsrisiko darstellt.

Best Practices für CI/CD-Integration:

GitHub empfiehlt für GitHub Actions die Verwendung ihrer verschlüsselten Secrets-Funktion: "Um Ihre Secrets zu schützen, empfehlen wir, Ihre Secrets in GitHub zu speichern und dann in Ihrem Workflow darauf zu verweisen. Die Secrets werden im GitHub-Repository verschlüsselt und werden den GitHub Actions-Runnern während des Job-Ausführungsprozesses nicht zugänglich gemacht."

Die Integration von Secrets Management in CI/CD-Pipelines erfordert zunächst eine vollständige Sichtbarkeit der SDLC-Umgebung, Assets und CI/CD-Prozesse. Ohne diese Gesamtsicht ist es nicht möglich, alle Secrets vollständig zu verwalten.

Folgende Ansätze haben sich bewährt:

• Secrets Pipeline: Implementierung einer speziellen Pipeline, die große Teile des Secrets Managements (z.B. Erstellung, Rotation) übernimmt

• Dynamische Secrets: Wenn eine Anwendung startet, kann sie Datenbankanmeldedaten anfordern, die dynamisch generiert werden. Dies reduziert die Angriffsfläche erheblich, da bei einem Diebstahl der Anmeldedaten diese nach einem Neustart ungültig werden

• Automatisierte Rotation statischer Secrets: Da die manuelle Rotation von Schlüsseln fehleranfällig ist, sollte der Prozess automatisiert oder zumindest ausreichend durch IT unterstützt werden

Im Kontext von DevOps ist die Automatisierung besonders wichtig. Die Rolle der Automatisierung erstreckt sich auf zwei Hauptkategorien:

1. Infrastrukturwartung: Erstellung neuer VM-Instanzen, Einrichtung von Apache, Ermöglichung des Entwicklerzugriffs auf Ressourcen usw. Dies ist der Bereich, in dem Automatisierung am sichtbarsten ist.

2. Infrastrukturbehebung: Hier geht es um Problemlösungen, wobei jedes Problem unterschiedlich ist. Der Schlüssel zur erfolgreichen Behebung liegt in der Automatisierung der ersten Kategorie.

Die automatisierten Python- und Bash-Skripte dienen als "lebende Dokumentation" dessen, was von Servern und Netzwerken erwartet wird: Wenn sich der Workflow ändert, ändern sich auch die Skripte.

Notfallzugriff und Recovery-Strategien

Jedes Secrets Management System benötigt robuste Notfallzugriffs- und Wiederherstellungsstrategien. Es gibt zwei Hauptbedrohungen für einen Secret-Tresor: Erstens, dass ein Angreifer die Secrets lesen kann, und zweitens, dass der Zugriff verloren geht – beides kann gleichermaßen schwerwiegende Folgen haben.

Emergency Kit erstellen:

Ein Emergency Kit ist ein Minimum-Subset eines vollständigen Backups und sollte Folgendes enthalten:

• Das Master-Passwort: Dies ist untrennbar mit der Verschlüsselung des Tresors verbunden und ohne es hat man nichts

• Die E-Mail-Adresse: Für den Zugriff auf den Tresor notwendig

• Den 2FA-Wiederherstellungscode: Für einen Tresor sollte unbedingt 2FA aktiviert sein

Für die Speicherung des Emergency Kits empfiehlt es sich, alle diese Informationen auf einem Stück Papier aufzuschreiben und dort aufzubewahren, wo wichtige Dokumente wie Geburtsurkunde, Fahrzeugschein und Heiratsurkunde aufbewahrt werden.

Break-Glass-Prozesse:

Es sollten Notfall-Prozesse ("Break-Glass") implementiert werden, um den Dienst wiederherzustellen, falls das System aus anderen Gründen als der regulären Wartung nicht verfügbar ist. Notfall-Break-Glass-Anmeldedaten sollten regelmäßig sicher in einem sekundären Secrets Management System gesichert und routinemäßig getestet werden, um zu überprüfen, ob sie funktionieren.

Backup und Wiederherstellung:

Die Sicherungs- und Wiederherstellungsverfahren des Systems sollten regelmäßig getestet und auf ihre Sicherheit überprüft werden. Einige Anforderungen an Backup & Restore sind:

• Ein automatisiertes Backup-Verfahren muss vorhanden sein und regelmäßig ausgeführt werden; die Häufigkeit der Backups und Snapshots sollte auf der Anzahl der Secrets und ihrem Lebenszyklus basieren

• Regelmäßiges Testen der Wiederherstellungsverfahren, um zu gewährleisten, dass die Backups intakt sind

• Verschlüsselung von Backups und Ablage auf sicherem Speicher mit reduzierten Zugriffsrechten

Designprinzipien für Notfallsituationen:

Ein besserer Ansatz für Notfallsituationen besteht darin, das System so zu gestalten, dass selbst wenn jemand ausfällt und seine Anmeldedaten für immer verloren gehen, nichts Schlimmes passiert. Wenn mindestens zwei Personen autorisiert sind, etwas zu tun, spielt es keine Rolle, wenn eine von ihnen ausfällt.

Darüber hinaus ist es sinnvoll, Anweisungen von sensiblen Informationen zu trennen. Die Anweisungen müssen für jeden leicht lesbar sein, können aber Hinweise enthalten, wie man Zugriff auf den ordnungsgemäß gesicherten Teil der Daten erhält. Dies ermöglicht die Trennung von Zugänglichkeit und Sicherheit.

Die Entscheidungen zur Geschäftslogik umfassen auch Fragen zur Betriebszeit. Wenn im Leben eines Administrators etwas schief geht, wie viel Zeit hat ein anderer Administrator, um dessen Arbeit zu übernehmen, bevor das Geschäft beeinträchtigt wird? Diese Überlegungen sollten in die Planung von Notfallzugriff und Recovery-Strategien einfließen.

Durch die Implementierung dieser Strategien zur Automatisierung des Secrets Lifecycle können Unternehmen nicht nur die Sicherheit ihrer sensiblen Daten erhöhen, sondern auch betriebliche Effizienz und Zuverlässigkeit steigern. Die kontinuierliche Rotation von Secrets minimiert das Zeitfenster, in dem potenzielle Cyberkriminelle diese ausnutzen können, während gut durchdachte Notfallzugriffs- und Recovery-Strategien sicherstellen, dass kritische Geschäftsprozesse auch in unvorhergesehenen Situationen funktionsfähig bleiben.

Systemanforderungen

Systemanforderungen

Bei der Planung einer robusten Secrets Management Automation Lösung spielen die technischen Rahmenbedingungen eine entscheidende Rolle für langfristigen Erfolg. Die richtigen Systemvoraussetzungen bilden das Fundament, auf dem ein zuverlässiges Secrets Management aufgebaut werden kann.

Hardwareanforderungen

Die Infrastruktur für ein Secrets Management System muss ausreichende Redundanz bieten, um die hohe Verfügbarkeit sensibler Zugangsdaten zu gewährleisten. Für geschäftskritische Anwendungen empfehlen sich Rechenzentren mit Tier-3-Zertifizierung, die eine Verfügbarkeit von 99,982% garantieren. Diese Verfügbarkeitsrate wird durch redundante Systeme erreicht, die kontinuierlichen Betrieb auch bei Ausfällen einzelner Komponenten sicherstellen.

Redundante Stromversorgungssysteme sind unerlässlich und werden typischerweise durch unterbrechungsfreie Stromversorgungen (USV) in Kombination mit Backup-Generatoren implementiert. Ebenso wichtig ist die Netzwerkredundanz, bei der mehrere Netzwerkverbindungen zwischen zwei Punkten eingerichtet werden, um Single Points of Failure zu vermeiden.

Für die Datenspiegelung und -replikation werden Speichergeräte benötigt, die mehrere Kopien jeder für Anwendungen erforderlichen Datei enthalten können. Dies ermöglicht eine schnelle Wiederherstellung im Katastrophenfall. Der Umfang der Hardware sollte an den Anforderungen des Unternehmens ausgerichtet sein und kann je nach Größe und Komplexität der IT-Landschaft variieren.

Softwareanforderungen

Die Wahl der richtigen Software-Lösung hängt stark von den spezifischen Anwendungsfällen ab. Organisationen haben mehrere Optionen:

• Cloud-übergreifende Secrets Management Lösungen: Geeignet für Unternehmen mit Multi-Cloud-Strategien

• Cloud-spezifische Secrets Manager: Optimal für Organisationen, die primär eine bestimmte Cloud-Plattform nutzen

• Open-Source Projekte für Secrets Management: Bieten Flexibilität und Kosteneinsparungen

• Selbst entwickelte Secrets Management Lösungen: Ermöglichen höchste Anpassungsfähigkeit an spezifische Anforderungen

Populäre Lösungen wie HashiCorp Vault bieten umfassende Funktionen für die sichere Speicherung und den Zugriff auf Secrets sowie andere sensible Daten wie Zugriffstoken, API-Schlüssel, Verschlüsselungsschlüssel, Passwörter und Zertifikate. Der Hauptzugriffsmechanismus erfolgt über APIs auf Basis vorab festgelegter Sicherheitsrichtlinien.

Außerdem können einige Tools wie Vault Secrets bei Bedarf dynamisch generieren, was besonders für bestimmte Operationen wie PostgreSQL-Datenbanken vorteilhaft ist. AWS Secrets Manager bietet eine schlanke, aber widerstandsfähige Lösung, die das Rotieren, Verwalten und Abrufen von Datenbankanmeldedaten, API-Schlüsseln und Passwörtern erleichtert.

Es ist jedoch wichtig, die Begrenzungen des Systems zu beachten. Gemäß den Systemanforderungen sollte die Gesamtzahl der unterstützten Safes, der Konten pro Komponente oder der Secrets Manager-Komponenten pro Vault-Architektur nicht überschritten werden.

Skalierbarkeit und Leistungsanforderungen

Bei der Dimensionierung eines Secrets Management Systems müssen verschiedene Faktoren berücksichtigt werden:

1. Anzahl der verwalteten Secrets: Das System sollte problemlos mit der wachsenden Anzahl von Secrets skalieren können. Dies ist entscheidend, da zunehmend mehr Systeme, Ressourcen und Anwendungen Zugangsdaten erfordern.

2. Zugriffsfrequenz: Die Plattform muss hohe Zugriffsraten bewältigen können, insbesondere in Umgebungen mit zahlreichen automatisierten Prozessen, die kontinuierlich auf Secrets zugreifen.

3. Latenzanforderungen: Für zeitkritische Anwendungen ist eine niedrige Latenz beim Abrufen von Secrets essentiell, um Verzögerungen in Produktionssystemen zu vermeiden.

4. Backup-Kapazität: Ausreichende Speicherkapazität für regelmäßige Backups aller Secrets ist unerlässlich für eine effektive Notfallwiederherstellung.

Besonders bei selbst entwickelten Lösungen ist zu bedenken, dass diese erheblichen Entwicklungsaufwand verursachen. Die Erstellung einer Software, die stets mit den neuesten Drittanbieter-APIs und Infrastruktureinrichtungen auf dem aktuellen Stand ist, erfordert kontinuierliche Aufmerksamkeit eines Entwicklerteams.

Sicherheits- und Compliance-Anforderungen

Die Sicherheitsanforderungen an ein Secrets Management System sind naturgemäß hoch. Die Nichteinhaltung kann zu Problemen wie Secret Sprawl führen, was wiederum Datenschutzverletzungen, Lecks sensibler Anmeldeinformationen und geringe Entwicklereffizienz zur Folge haben kann.

Die kontinuierliche Überwachung der Umgebungsbedingungen innerhalb des Rechenzentrums – Temperatur, Luftfeuchtigkeit, Luftstrom usw. – stellt sicher, dass die Geräte unter optimalen Bedingungen für ihre Leistung arbeiten. Falls eine dieser Variablen außerhalb des zulässigen Bereichs fällt, sollte das automatisierte System in Echtzeit Anpassungen vornehmen, um mögliche Ausfälle zu verhindern.

Um Ausfallzeiten in einem Rechenzentrum zu reduzieren, ist eine strikte Einhaltung von Betriebsstandards und Best Practices erforderlich. Regelmäßige Audits und Compliance-Prüfungen gegen festgelegte Branchenstandards und -vorschriften helfen dabei, Schwachstellen sowohl in physischen als auch in logischen Aspekten zu identifizieren und zu beheben.

Cloud-spezifische Anforderungen

Für Cloud-basierte Implementierungen gelten zusätzliche oder abweichende Anforderungen:

• AWS Secrets Manager: Integriert sich nahtlos in die AWS-Umgebung und rotiert Anmeldedaten automatisch nach einem definierten Zeitplan.

• GCP Secret Manager: Eine praktikable Option für Unternehmen, die Google Cloud Platform als Cloud-Anbieter nutzen.

• Azure Key Vault: Ermöglicht die Erstellung und den Import von Verschlüsselungsschlüsseln sowie die automatisierte Erneuerung von SSL/TLS-Zertifikaten.

Der Hauptvorteil selbst gehosteter Lösungen liegt darin, dass sie einfacher Compliance-Genehmigungen erhalten können, da sie auf der eigenen Infrastruktur des Unternehmens gehostet werden können. Allerdings muss dieser Vorteil gegen den konstanten Zeitaufwand abgewogen werden, der für die Wartung einer so wichtigen Lösung vom Entwicklungsteam abgezogen werden könnte.

Bei Open-Source-Software ohne kommerziellen Support ist hingegen zu beachten, dass keine Partei die Verantwortung für die Wartung, die Behebung relevanter Fehler und die Veröffentlichung von Sicherheitspatches trägt. Dies kann insbesondere bei sicherheitskritischen Anwendungen wie dem Secrets Management problematisch sein.

Für Organisationen mit spezifischen Compliance-Anforderungen bieten Tools wie SOPS von Mozilla oder Confidant, entwickelt bei Lyft, interessante Alternativen. Confidant speichert Geheimnisse in DynamoDB und generiert für jede Änderung der Geheimnisse einen eindeutigen KMS-Datenschlüssel unter Verwendung der Fernet-symmetrischen authentifizierten Kryptographie.

Die Anforderungen an ein Secrets Management System müssen daher sorgfältig evaluiert werden, um eine Balance zwischen Sicherheit, Benutzerfreundlichkeit, Wartbarkeit und Compliance zu finden. Die richtige Infrastruktur bildet das Rückgrat eines erfolgreichen Secrets Management Automation Systems und ermöglicht die sichere und effiziente Verwaltung sensibler Zugangsdaten über alle drei Ebenen einer 3-Tier Architektur hinweg.