Azure-Sicherheit für cloudeigene Apps

Tipp

Dieser Inhalt ist ein Auszug aus dem eBook, Architecting Cloud Native .NET Applications for Azure, verfügbar auf .NET Docs oder als kostenlose herunterladbare PDF, die offline gelesen werden kann.

PDF herunterladen

Cloudnative Anwendungen können sowohl einfacher als auch schwieriger zu sichern sein als herkömmliche Anwendungen. Auf der Anderen Seite müssen Sie kleinere Anwendungen sichern und mehr Energie für die Entwicklung der Sicherheitsinfrastruktur bereitstellen. Die heterogene Art der Programmiersprachen und -stile in den meisten Dienstbereitstellungen bedeutet auch, dass Sie mehr Aufmerksamkeit auf Sicherheitsbulletinen von vielen verschiedenen Anbietern achten müssen.

Andererseits beschränken kleinere Dienste, die jeweils über einen eigenen Datenspeicher verfügen, den Umfang eines Angriffs. Wenn ein Angreifer ein System kompromittiert, ist es für den Angreifer wahrscheinlich schwieriger, den Sprung zu einem anderen System zu machen, als es sich in einer monolithischen Anwendung befindet. Prozessgrenzen sind starke Grenzen. Wenn eine Datenbanksicherung verfügbar gemacht wird, ist der Schaden eingeschränkter, da diese Datenbank nur eine Teilmenge von Daten enthält und unwahrscheinlich ist, dass sie personenbezogene Daten enthalten.

Bedrohungsmodellierung

Unabhängig davon, ob die Vorteile die Nachteile von Cloud-nativen Anwendungen überwiegen, muss die gleiche ganzheitliche Sicherheits-Denkweise befolgt werden. Sicherheit und sicheres Denken müssen Teil jedes Schritts der Entwicklungs- und Betriebsgeschichte sein. Bei der Planung einer Anwendung stellen Sie Fragen wie:

• Was wäre die Auswirkung dieser Daten, die verloren gegangen sind?
• Wie können wir den Schaden an fehlerhaften Daten einschränken, die in diesen Dienst eingefügt werden?
• Wer sollte Zugriff auf diese Daten haben?
• Gibt es Überwachungsrichtlinien für den Entwicklungs- und Veröffentlichungsprozess?

All diese Fragen sind Teil eines Prozesses, der als Bedrohungsmodellierung bezeichnet wird. Dieser Prozess versucht, die Frage zu beantworten, welche Bedrohungen es für das System gibt, wie wahrscheinlich die Bedrohungen sind und welche potenziellen Schäden sie haben.

Sobald die Liste der Bedrohungen eingerichtet wurde, müssen Sie entscheiden, ob sie eine Milderung wert sind. Manchmal ist eine Bedrohung so unwahrscheinlich und teuer zu planen, dass es sich nicht lohnt, Energie darauf zu investieren. Beispielsweise könnte ein Akteur auf Zustandsebene Änderungen in das Design eines Prozesses einfügen, der von Millionen von Geräten verwendet wird. Anstatt nun einen bestimmten Codeabschnitt in Ring 3 auszuführen, wird dieser Code in Ring 0 ausgeführt. Dieser Prozess ermöglicht einen Exploit, der den Hypervisor umgehen und den Angriffscode auf den Bare-Metal-Computern ausführen kann, sodass Angriffe auf alle virtuellen Computer möglich sind, die auf dieser Hardware ausgeführt werden.

Die veränderten Prozessoren sind schwer zu erkennen, ohne ein Mikroskop und fortgeschrittene Kenntnisse des Designs auf Silizium des jeweiligen Prozessors. Dieses Szenario ist unwahrscheinlich und teuer zu minimieren, daher würde wahrscheinlich kein Bedrohungsmodell das Erstellen des Exploit-Schutzes empfehlen.

Wahrscheinlicheren Bedrohungen, wie z. B. defekte Zugriffssteuerungen Id, die zu erhöhenden Angriffen führen (indem Id=2 durch Id=3 in der URL ersetzt wird) oder SQL-Injection, sind attraktiver, um Schutzmechanismen zu entwickeln. Die Maßnahmen zur Entschärfung dieser Bedrohungen sind ziemlich vernünftig, um peinliche Sicherheitslücken zu verhindern, die den Ruf des Unternehmens schädigen.

Prinzip der geringsten Rechte

Eine der Gründungsideen in der Computersicherheit ist das Prinzip der geringsten Rechte (POLP). Es ist eigentlich eine grundlegende Idee in den meisten Formen von Sicherheit, sei es digital oder physisch. Kurz gesagt ist das Prinzip, dass jeder Benutzer oder Prozess über die kleinste Anzahl von Rechten verfügen sollte, die für die Ausführung seiner Aufgabe möglich sind.

Denken Sie beispielsweise an die Geldzähler bei einer Bank: Der Zugriff auf das Safe ist eine ungewöhnliche Aktivität. Der durchschnittliche Kassierer kann also den Tresor nicht öffnen. Um Zugang zu erhalten, müssen sie ihre Anfrage über einen Bankmanager eskalieren, der zusätzliche Sicherheitsprüfungen durchführt.

In einem Computersystem ist ein fantastisches Beispiel die Rechte eines Benutzers, der eine Verbindung mit einer Datenbank herstellt. In vielen Fällen wird ein einzelnes Benutzerkonto verwendet, um die Datenbankstruktur zu erstellen und die Anwendung auszuführen. Außer in extremen Fällen benötigt das Konto, das die Anwendung ausführt, keine Möglichkeit, Schemainformationen zu aktualisieren. Es sollten mehrere Konten vorhanden sein, die unterschiedliche Berechtigungsstufen bereitstellen. Die Anwendung sollte nur die Berechtigungsstufe verwenden, die Lese- und Schreibzugriff auf die Daten in den Tabellen gewährt. Diese Art von Schutz würde Angriffe beseitigen, die darauf abzielen, Datenbanktabellen abzulegen oder böswillige Auslöser einzuführen.

Fast jeder Teil der Erstellung einer cloudeigenen Anwendung kann von der Erinnerung an das Prinzip der geringsten Rechte profitieren. Sie finden sie beim Einrichten von Firewalls, Netzwerksicherheitsgruppen, Rollen und Bereichen in der rollenbasierten Zugriffssteuerung (RBAC).

Penetrationstests

Da Anwendungen komplizierter werden, steigt die Anzahl der Angriffsvektoren mit einer alarmierenden Rate. Die Bedrohungsmodellierung ist fehlerhaft, da sie tendenziell von denselben Personen ausgeführt wird, die das System erstellen. Auf die gleiche Weise, wie viele Entwickler Probleme bei der Darstellung von Benutzerinteraktionen haben und dann unbrauchbare Benutzeroberflächen erstellen, haben die meisten Entwickler Schwierigkeiten, jeden Angriffsvektor zu sehen. Es ist auch möglich, dass die Entwickler, die das System erstellen, nicht gut in Angriffsmethoden versiert sind und etwas Entscheidendes verpassen.

Penetrationstests oder "Pen-Tests" beinhalten das Einbringen externer Fachleute, um das System zu attackieren. Diese Angreifer können ein externes Beratungsunternehmen oder andere Entwickler mit guten Sicherheitskenntnissen aus einem anderen Teil des Unternehmens sein. Sie erhalten carte blanche, um zu versuchen, das System zu subvertieren. Häufig finden sie umfangreiche Sicherheitslöcher, die gepatcht werden müssen. Manchmal ist der Angriffsvektor etwas völlig unerwartetes wie das Ausnutzen eines Phishingangriffs auf den CEO.

Azure selbst unterliegt ständig Angriffen von einem Team von Hackern innerhalb von Microsoft. Im Laufe der Jahre waren sie die ersten, die Dutzende möglicherweise katastrophaler Angriffsvektoren fanden und schlossen, bevor sie extern ausgenutzt werden können. Je verlockender ein Ziel ist, desto wahrscheinlicher, dass externe Akteure versuchen, es auszunutzen, und es gibt nur wenige Ziele in der Welt, die verlockender als Azure sind.

Überwachung

Sollte ein Angreifer versuchen, in eine Anwendung einzudringen, sollte eine Warnung angezeigt werden. Häufig können Angriffe erkannt werden, indem die Protokolle von Diensten untersucht werden. Angriffe hinterlassen verräterische Anzeichen, die entdeckt werden können, bevor sie erfolgreich sind. Beispielsweise führt ein Angreifer, der versucht, ein Kennwort zu erraten, mehrere Anfragen an ein Anmeldesystem. Die Überwachung des Anmeldesystems kann seltsame Muster erkennen, die nicht mit dem typischen Zugriffsmuster in Einklang stehen. Diese Überwachung kann in eine Warnung umgewandelt werden, die wiederum eine Betriebsperson benachrichtigen kann, um eine Art Gegenmaßnahmen zu aktivieren. Ein maßgeblich ausgereiftes Überwachungssystem kann sogar Maßnahmen ergreifen, die auf diesen Abweichungen basieren, indem es proaktiv Regeln hinzufügt, die Anforderungen blockieren oder Antworten drosseln.

Sichern des Builds

Ein Ort, an dem die Sicherheit häufig übersehen wird, findet sich im Build-Prozess. Der Build sollte nicht nur Sicherheitsprüfungen ausführen, z. B. die Überprüfung auf unsicheren Code oder eingecheckte Anmeldeinformationen, sondern der Build selbst sollte sicher sein. Wenn der Buildserver kompromittiert ist, bietet er einen fantastischen Vektor für die Einführung von beliebigem Code in das Produkt.

Stellen Sie sich vor, dass ein Angreifer versucht, die Kennwörter von Personen zu stehlen, die sich bei einer Webanwendung anmelden. Sie könnten einen Build-Schritt einführen, der den ausgecheckten Code so ändert, dass sämtliche Anmeldeanforderungen auf einen anderen Server gespiegelt werden. Wenn der Code das nächste Mal den Build durchläuft, wird er im Hintergrund aktualisiert. Die Sicherheitsrisikoüberprüfung des Quellcodes wird diese Sicherheitsanfälligkeit nicht erkennen, da sie vor dem Build ausgeführt wird. Ebenso wird niemand es in einer Codeüberprüfung abfangen, da die Buildschritte auf dem Buildserver live ausgeführt werden. Der ausgenutzte Code wird in die Produktion gehen, wo es Kennwörter ernten kann. Wahrscheinlich gibt es kein Audit-Protokoll der Änderungen im Buildprozess oder zumindest niemanden, der das Audit überwacht.

Dieses Szenario ist ein perfektes Beispiel für ein scheinbar niedriges Ziel, das verwendet werden kann, um in das System einzubrechen. Sobald ein Angreifer den Sicherheitsperimeter des Systems durchbricht, kann er daran arbeiten, Wege zu finden, um seine Berechtigungen auf ein Niveau anzuheben, an dem er an jedem beliebigen Ort erheblichen Schaden anrichten kann.

Erstellen von sicherem Code

.NET Framework ist bereits ein ziemlich sicheres Framework. Es vermeidet einige der Fallstricke von nicht verwaltetem Code, wie z. B. das Überschreiten der Grenzen von Arrays. Es wird aktiv daran gearbeitet, Sicherheitslücken zu beheben, sobald sie entdeckt werden. Es gibt sogar ein Bug Bounty-Programm , das Forscher zahlt, um Probleme im Rahmen zu finden und sie zu melden, anstatt sie auszunutzen.

Es gibt viele Möglichkeiten, .NET-Code sicherer zu machen. Die folgenden Richtlinien wie die Richtlinien für die sichere Codierung für .NET sind ein vernünftiger Schritt, um sicherzustellen, dass der Code von Grund auf sicher ist. Die OWASP Top 10 ist ein weiterer wertvoller Leitfaden zum Erstellen von sicherem Code.

Der Buildprozess ist ein guter Ort, um Scan-Tools einzusetzen, um Probleme im Quellcode zu erkennen, bevor er in die Produktion gelangt. Die meisten projekte haben Abhängigkeiten von einigen anderen Paketen. Ein Tool, das nach veralteten Paketen suchen kann, erkennt Probleme in einem nächtlichen Build. Selbst beim Erstellen von Docker-Images ist es hilfreich, zu überprüfen und sicherzustellen, dass das Basisimage keine bekannten Sicherheitsrisiken aufweist. Ein weiterer Punkt, den man überprüfen sollte, ist, dass niemand versehentlich Anmeldedaten hochgeladen hat.

Integrierte Sicherheit

Azure ist so konzipiert, dass die Benutzerfreundlichkeit und Sicherheit für die meisten Benutzer ausgeglichen werden. Unterschiedliche Benutzer haben unterschiedliche Sicherheitsanforderungen, daher müssen sie ihren Ansatz für Cloudsicherheit optimieren. Microsoft veröffentlicht viele Sicherheitsinformationen im Trust Center. Diese Ressource sollte der erste Schritt für diese Experten sein, die wissen möchten, wie die integrierten Angriffsminderungstechnologien funktionieren.

Im Azure-Portal ist der Azure Advisor ein System, das ständig eine Umgebung scannt und Empfehlungen vornimmt. Einige dieser Empfehlungen sind so konzipiert, dass Benutzer Geld sparen, andere jedoch darauf ausgelegt sind, potenziell unsichere Konfigurationen zu identifizieren, z. B. einen Speichercontainer offen für die Welt zu haben und nicht durch ein virtuelles Netzwerk geschützt zu werden.

Azure-Netzwerkinfrastruktur

In einer lokalen Bereitstellungsumgebung ist viel Energie für die Einrichtung von Netzwerken vorgesehen. Das Einrichten von Routern, Switches und dergleichen ist kompliziert. Netzwerke ermöglichen es bestimmten Ressourcen, mit anderen Ressourcen zu sprechen und in einigen Fällen den Zugriff zu verhindern. Eine häufige Netzwerkregel besteht darin, den Zugriff auf die Produktionsumgebung von der Entwicklungsumgebung aus für den Fall zu beschränken, dass ein halb fertig entwickelter Code fehlfunktioniert und eine große Menge an Daten löscht.

Standardmäßig verfügen die meisten PaaS Azure-Ressourcen nur über die grundlegendsten und zulässigsten Netzwerksetups. Beispielsweise kann jeder im Internet auf einen App-Dienst zugreifen. Neue SQL Server-Instanzen sind in der Regel eingeschränkt, sodass externe Parteien nicht darauf zugreifen können, aber die von Azure selbst verwendeten IP-Adressbereiche sind zulässig. Während der SQL-Server also vor externen Bedrohungen geschützt ist, muss ein Angreifer nur einen Azure-Bridgehead einrichten, von dem aus sie Angriffe auf alle SQL-Instanzen in Azure starten können.

Glücklicherweise können die meisten Azure-Ressourcen in ein virtuelles Azure-Netzwerk platziert werden, das eine differenzierte Zugriffssteuerung ermöglicht. Ähnlich wie lokale Netzwerke private Netzwerke einrichten, die von der breiteren Welt geschützt sind, sind virtuelle Netzwerke Inseln privater IP-Adressen, die sich im Azure-Netzwerk befinden.

Abbildung 9-1. Ein virtuelles Netzwerk in Azure.

Auf die gleiche Weise wie lokale Netzwerke über eine Firewall für den Zugriff auf das Netzwerk verfügen, können Sie eine ähnliche Firewall an der Grenze des virtuellen Netzwerks einrichten. Standardmäßig können alle Ressourcen in einem virtuellen Netzwerk weiterhin mit dem Internet kommunizieren. Nur eingehende Verbindungen erfordern eine explizite Ausnahme in der Firewall.

Nachdem das Netzwerk eingerichtet wurde, können interne Ressourcen wie Speicherkonten so eingerichtet werden, dass nur der Zugriff auf Ressourcen möglich ist, die sich auch im virtuellen Netzwerk befinden. Diese Firewall bietet eine zusätzliche Sicherheitsstufe, wenn die Schlüssel für dieses Speicherkonto durchleckt werden, angreifer könnten keine Verbindung mit ihr herstellen, um die geleckten Schlüssel auszunutzen. Dieses Szenario ist ein weiteres Beispiel für das Prinzip der geringsten Rechte.

Die Knoten in einem Azure Kubernetes-Cluster können genauso wie andere Ressourcen, die in Azure nativer sind, an einem virtuellen Netzwerk teilnehmen. Diese Funktionalität wird als Azure Container Networking Interface bezeichnet. Im Grunde genommen wird ein Subnetz innerhalb des virtuellen Netzwerks bereitgestellt, auf dem virtuelle Maschinen und Container-Abbilder zugeordnet werden.

Wenn Sie den Weg der Veranschaulichung des Prinzips der geringsten Berechtigungen fortsetzen, muss nicht jede Ressource innerhalb eines virtuellen Netzwerks mit jeder anderen Ressource sprechen. In einer Anwendung, die eine Web-API über ein Speicherkonto und eine SQL-Datenbank bereitstellt, ist es unwahrscheinlich, dass die Datenbank und das Speicherkonto miteinander kommunizieren müssen. Jeder Datenaustausch zwischen ihnen würde über die Webanwendung erfolgen. Daher könnte eine Netzwerksicherheitsgruppe (Network Security Group, NSG) verwendet werden, um den Datenverkehr zwischen den beiden Diensten zu verweigern.

Eine Richtlinie zur Beschränkung der Kommunikation zwischen Ressourcen kann schwierig umzusetzen sein, insbesondere wenn man zuvor Azure ohne Netzwerkverkehrsbeschränkungen genutzt hat. Bei einigen anderen Clouds ist das Konzept von Netzwerksicherheitsgruppen viel häufiger. Die Standardrichtlinie für AWS ist beispielsweise, dass Ressourcen nicht untereinander kommunizieren können, bis sie durch Regeln in einer NSG aktiviert sind. Während die Entwicklung langsamer ist, bietet eine restriktivere Umgebung einen sichereren Standardwert. Wenn Sie die richtigen DevOps-Methoden verwenden, insbesondere mithilfe von Azure Resource Manager oder Terraform zum Verwalten von Berechtigungen, können Sie die Steuerung der Regeln vereinfachen.

Virtuelle Netzwerke können auch beim Einrichten der Kommunikation zwischen lokalen und Cloudressourcen hilfreich sein. Ein virtuelles privates Netzwerk kann verwendet werden, um die beiden Netzwerke nahtlos miteinander zu verbinden. Dieser Ansatz ermöglicht das Ausführen eines virtuellen Netzwerks ohne eine Art Gateway für Szenarien, in denen alle Benutzer vor Ort sind. Es gibt eine Reihe von Technologien, mit denen dieses Netzwerk hergestellt werden kann. Am einfachsten ist die Verwendung eines Standort-zu-Standort-VPN , das zwischen vielen Routern und Azure hergestellt werden kann. Der Datenverkehr wird verschlüsselt und über das Internet zu den gleichen Kosten pro Byte wie jeder andere Datenverkehr getunnelt. Für Szenarien, in denen mehr Bandbreite oder mehr Sicherheit wünschenswert ist, bietet Azure einen Dienst namens Express Route , der eine private Verbindung zwischen einem lokalen Netzwerk und Azure verwendet. Es ist teurer und schwieriger zu etablieren, aber auch sicherer.

Rollenbasierte Zugriffssteuerung zum Einschränken des Zugriffs auf Azure-Ressourcen

RBAC ist ein System, das eine Identität für Anwendungen bereitstellt, die in Azure ausgeführt werden. Anwendungen können mithilfe dieser Identität auf Ressourcen zugreifen, entweder anstelle oder zusätzlich zu Schlüsseln oder Kennwörtern.

Sicherheitsprinzipale

Die erste Komponente in RBAC ist ein Sicherheitsprinzipal. Ein Sicherheitsprinzipal kann ein Benutzer, eine Gruppe, ein Dienstprinzipal oder eine verwaltete Identität sein.

Abbildung 9-2. Verschiedene Arten von Sicherheitsprinzipale.

• Benutzer – Jeder Benutzer, der über ein Konto in Azure Active Directory verfügt, ist ein Benutzer.
• Gruppe – Eine Sammlung von Benutzern aus Azure Active Directory. Als Mitglied einer Gruppe übernimmt ein Benutzer zusätzlich zu seinen eigenen Rollen die Rollen dieser Gruppe.
• Dienstprinzipal – Eine Sicherheitsidentität, unter der Dienste oder Anwendungen ausgeführt werden.
• Verwaltete Identität – Eine von Azure verwaltete Azure Active Directory-Identität. Verwaltete Identitäten werden in der Regel beim Entwickeln von Cloudanwendungen verwendet, die die Anmeldeinformationen für die Authentifizierung bei Azure-Diensten verwalten.

Der Sicherheitsprinzipal kann auf die meisten Ressourcen angewendet werden. Dieser Aspekt bedeutet, dass es möglich ist, einem Container, der in Azure Kubernetes ausgeführt wird, einen Sicherheitsprinzipal zuzuweisen, sodass er auf geheime Schlüssel zugreifen kann, die im Key Vault gespeichert sind. Eine Azure-Funktion kann eine Berechtigung übernehmen, mit der sie mit einer Active Directory-Instanz kommunizieren kann, um einen JWT für einen aufrufenden Benutzer zu überprüfen. Sobald Dienste mit einem Dienstprinzipal aktiviert sind, können ihre Berechtigungen präzise mithilfe von Rollen und Bereichen verwaltet werden.

Rollen

Ein Sicherheitsprinzipal kann viele Rollen übernehmen oder, um eine stilistische Analogie zu verwenden, viele Hüte tragen. Jede Rolle definiert eine Reihe von Berechtigungen, z. B. "Nachrichten von Azure Service Bus-Endpunkt lesen". Der effektive Berechtigungssatz eines Sicherheitsprinzipals ist die Kombination aller Berechtigungen, die allen Rollen zugewiesen sind, über die ein Sicherheitsprinzipal verfügt. Azure verfügt über eine große Anzahl integrierter Rollen, und Benutzer können ihre eigenen Rollen definieren.

Abbildung 9-3. RBAC-Rollendefinitionen.

In Azure integriert sind auch eine Reihe von allgemeinen Rollen wie Besitzer, Mitwirkender, Leser und Benutzerkontoadministrator. Mit der Rolle "Besitzer" kann ein Sicherheitsprinzipal auf alle Ressourcen zugreifen und anderen Personen Berechtigungen zuweisen. Ein Mitwirkender hat dieselbe Zugriffsebene auf alle Ressourcen, kann aber keine Berechtigungen zuweisen. Ein Leser kann nur vorhandene Azure-Ressourcen anzeigen, und ein Benutzerkontoadministrator kann den Zugriff auf Azure-Ressourcen verwalten.

Genauere integrierte Rollen wie DNS-Zonenmitwirkende verfügen über Rechte, die auf einen einzelnen Dienst beschränkt sind. Sicherheitsprinzipale können eine beliebige Anzahl von Rollen übernehmen.

Geltungsbereiche

Rollen können auf einen eingeschränkten Satz von Ressourcen in Azure angewendet werden. Beispielsweise können Sie für das vorherige Beispiel des Lesens aus einer Service Bus-Warteschlange den Bereich beschränken, indem Sie die Berechtigung auf eine einzelne Warteschlange reduzieren: "Nachrichten vom Azure Service Bus-Endpunkt blah.servicebus.windows.net/queue1 lesen".

Der Bereich kann so eng wie eine einzelne Ressource sein oder auf eine gesamte Ressourcengruppe, ein Abonnement oder sogar eine Verwaltungsgruppe angewendet werden.

Beim Testen, ob ein Sicherheitsprinzipal über bestimmte Berechtigungen verfügt, wird die Kombination aus Rolle und Bereich berücksichtigt. Diese Kombination bietet einen leistungsfähigen Autorisierungsmechanismus.

Leugnen

Bisher waren nur „Erlauben“-Regeln für RBAC zulässig. Dieses Verhalten hat es schwer gemacht, einige Umfänge zu bauen. So kann z. B. ein Sicherheitsprinzipalzugriff auf alle Speicherkonten gewährt werden, mit Ausnahme einer erforderlichen, expliziten Berechtigung für eine potenziell endlose Liste von Speicherkonten. Jedes Mal, wenn ein neues Speicherkonto erstellt wurde, müsste es dieser Liste von Konten hinzugefügt werden. Dieser zusätzliche Verwaltungsaufwand, der sicherlich nicht wünschenswert war.

Ablehnungsregeln haben Vorrang vor Zulassungsregeln. Der jetzt denselben Gültigkeitsbereich "alle außer einem zulassen" darstellt, könnte als zwei Regeln "alle zulassen" und "dieses eine bestimmte verweigern" dargestellt werden. Verweigerungsregeln erleichtern nicht nur die Verwaltung, sondern ermöglichen besonders sichere Ressourcen, indem ihnen allen der Zugriff verweigert wird.

Überprüfen des Zugriffs

Wie Sie sich vorstellen können, kann das Vorhandensein einer großen Anzahl von Rollen und Bereichen die effektive Berechtigung eines Dienste-Principals ziemlich schwierig gestalten. Das Anhäufen von Ablehnungsregeln verstärkt nur die Komplexität. Glücklicherweise gibt es einen Berechtigungsrechner , der die effektiven Berechtigungen für jeden Dienstprinzipal anzeigen kann. Es befindet sich in der Regel unter der Registerkarte IAM im Portal, wie in Abbildung 9-3 dargestellt.

Abbildung 9-4. Berechtigungsrechner für einen App-Dienst.

Sicherung von Geheimnissen

Kennwörter und Zertifikate sind ein gängiger Angriffsvektor für Angreifer. Kennwort-Cracking-Hardware kann einen Brute-Force-Angriff durchführen und versuchen, Milliarden von Kennwörtern pro Sekunde zu erraten. Daher ist es wichtig, dass die Kennwörter, die für den Zugriff auf Ressourcen verwendet werden, stark sind, mit einer vielzahl von Zeichen. Diese Kennwörter sind genau die Art von Kennwörtern, die nahezu unmöglich zu merken sind. Glücklicherweise müssen die Kennwörter in Azure von keinem Menschen bekannt sein.

Viele Sicherheitsexperten schlagen vor , dass die Verwendung eines Kennwort-Managers, um Ihre eigenen Kennwörter beizubehalten, der beste Ansatz ist. Während es Ihre Kennwörter an einem Ort zentralisiert, ermöglicht es auch die Verwendung von hoch komplexen Kennwörtern und die Sicherstellung, dass sie für jedes Konto eindeutig sind. Dasselbe System ist in Azure vorhanden: ein zentraler Speicher für geheime Schlüssel.

Azure Key Vault (ein Dienst zur sicheren Verwaltung kryptografischer Schlüssel)

Azure Key Vault bietet einen zentralen Speicherort zum Speichern von Kennwörtern für Elemente wie Datenbanken, API-Schlüssel und Zertifikate. Sobald ein Geheimnis in den Tresor eingegeben wurde, wird es nie wieder angezeigt, und die Befehle zum Extrahieren und Anzeigen sind absichtlich kompliziert. Die Informationen im Tresor werden entweder mit Softwareverschlüsselung oder FIPS 140-2 Level 2-validierten Hardware-Sicherheitsmodulen geschützt.

Der Zugriff auf den Schlüsseltresor wird über RBACs bereitgestellt, was bedeutet, dass nicht nur jeder Benutzer auf die Informationen im Tresor zugreifen kann. Angenommen, eine Webanwendung möchte auf die datenbankverbindungszeichenfolge zugreifen, die in Azure Key Vault gespeichert ist. Um Zugriff zu erhalten, müssen Anwendungen mit einem Dienstprinzipal ausgeführt werden. Unter dieser angenommenen Identität können sie die Geheimnisse aus dem Tresor lesen. Es gibt eine Reihe verschiedener Sicherheitseinstellungen, die den Zugriff, den eine Anwendung auf den Tresor hat, weiter einschränken können, sodass geheime Schlüssel nicht aktualisiert, sondern nur gelesen werden können.

Der Zugriff auf den Schlüsseltresor kann überwacht werden, um sicherzustellen, dass nur die erwarteten Anwendungen auf den Tresor zugreifen. Die Protokolle können wieder in Azure Monitor integriert werden, wodurch die Möglichkeit eröffnet wird, Warnungen einzurichten, wenn unerwartete Bedingungen auftreten.

Kubernetes

Innerhalb von Kubernetes gibt es einen ähnlichen Dienst für die Aufrechterhaltung kleiner geheimer Informationen. Kubernetes Secrets können über die typische kubectl ausführbare Datei festgelegt werden.

Das Erstellen eines geheimen Schlüssels ist so einfach wie das Auffinden der base64-Version der zu speichernden Werte:

echo -n 'admin' | base64
YWRtaW4=
echo -n '1f2d1e2e67df' | base64
MWYyZDFlMmU2N2Rm

Fügen Sie sie dann zu einer geheimen Datei hinzu secret.yml , die z. B. ähnlich wie im folgenden Beispiel aussieht:

apiVersion: v1
kind: Secret
metadata:
  name: mysecret
type: Opaque
data:
  username: YWRtaW4=
  password: MWYyZDFlMmU2N2Rm

Schließlich kann diese Datei in Kubernetes geladen werden, indem Sie den folgenden Befehl ausführen:

kubectl apply -f ./secret.yaml

Diese Geheimnisse können dann in Volumes eingebunden oder Containerprozessen über Umgebungsvariablen bereitgestellt werden. Der Zwölf-Faktor-App-Ansatz zum Erstellen von Anwendungen schlägt vor, den niedrigsten gemeinsamen Nenner zu verwenden, um Einstellungen an eine Anwendung zu übertragen. Umgebungsvariablen sind der niedrigste gemeinsame Nenner, da sie unabhängig vom Betriebssystem oder der Anwendung unterstützt werden.

Eine Alternative zur Verwendung der integrierten Kubernetes-Geheimnisse besteht darin, in Kubernetes auf die Geheimnisse in Azure Key Vault zuzugreifen. Die einfachste Möglichkeit hierfür ist das Zuweisen einer RBAC-Rolle für den Container, der Geheimnisse laden möchte. Die Anwendung kann dann die Azure Key Vault-APIs verwenden, um auf die geheimen Schlüssel zuzugreifen. Dieser Ansatz erfordert jedoch Änderungen am Code und folgt nicht dem Muster der Verwendung von Umgebungsvariablen. Stattdessen ist es möglich, Werte in einen Container einzufügen. Dieser Ansatz ist tatsächlich sicherer als die direkte Verwendung der Kubernetes-Geheimnisse, da sie von Benutzern im Cluster aufgerufen werden können.

Verschlüsselung während der Übertragung und im Ruhezustand

Es ist wichtig, die Daten sicher zu halten, unabhängig davon, ob sie sich auf dem Datenträger befinden oder zwischen verschiedenen Diensten übertragen werden. Die effektivste Möglichkeit, Daten vor dem Verlust zu schützen, besteht darin, sie in einem Format zu verschlüsseln, das nicht einfach von anderen gelesen werden kann. Azure unterstützt eine Vielzahl von Verschlüsselungsoptionen.

Unterwegs

Es gibt mehrere Möglichkeiten zum Verschlüsseln des Datenverkehrs im Netzwerk in Azure. Der Zugriff auf Azure-Dienste erfolgt in der Regel über Verbindungen, die Transport Layer Security (TLS) verwenden. Beispielsweise erfordern alle Verbindungen mit den Azure-APIs TLS-Verbindungen. Ebenso können Verbindungen mit Endpunkten im Azure-Speicher auf die Verwendung nur über VERSCHLÜSSELTE TLS-Verbindungen beschränkt werden.

TLS ist ein kompliziertes Protokoll und einfach zu wissen, dass die Verbindung TLS verwendet, ist nicht ausreichend, um die Sicherheit zu gewährleisten. Beispielsweise ist TLS 1.0 chronisch unsicher, und TLS 1.1 ist nicht viel besser. Auch in den Versionen von TLS gibt es verschiedene Einstellungen, die die Entschlüsselung der Verbindungen vereinfachen können. Die beste Vorgehensweise besteht darin, zu überprüfen und zu sehen, ob die Serververbindung up-to-date und gut konfigurierte Protokolle verwendet.

Diese Überprüfung kann von einem externen Dienst wie dem SSL-Servertest von SSL Labs durchgeführt werden. Eine Testausführung für einen typischen Azure-Endpunkt, in diesem Fall ein Servicebus-Endpunkt, liefert eine nahezu perfekte Bewertung von A.

Sogar Dienste wie Azure SQL-Datenbanken verwenden TLS-Verschlüsselung, um Daten zu schützen. Der interessante Teil zum Verschlüsseln der Daten bei der Übertragung mithilfe von TLS besteht darin, dass es auch für Microsoft nicht möglich ist, die Verbindung zwischen Computern mit TLS zu überwachen. Dies sollte Unternehmen, die sich Sorgen machen, dass ihre Daten von Microsoft selbst oder sogar von einem staatlichen Akteur, der über mehr Ressourcen verfügt als ein typischer Angreifer, gefährdet sein könnten, beruhigen.

Abbildung 9-5. SSL Labs-Bericht mit einer Bewertung von A für einen ServiceBus-Endpunkt.

Diese Verschlüsselungsstufe wird zwar nicht für die Ewigkeit ausreichen, sollte jedoch Vertrauen schaffen, dass Azure TLS-Verbindungen ziemlich sicher sind. Azure wird seine Sicherheitsstandards weiter weiterentwickeln, da die Verschlüsselung verbessert wird. Es ist schön zu wissen, dass jemand die Sicherheitsstandards überwacht und Azure aktualisiert, während sie verbessert werden.

Im Ruhezustand

In jeder Anwendung gibt es eine Reihe von Stellen, an denen sich Daten auf dem Datenträger befinden. Der Anwendungscode selbst wird aus einem Speichermechanismus geladen. Die meisten Anwendungen verwenden auch eine Art Datenbank wie SQL Server, Cosmos DB oder sogar den erstaunlich preiseffizienten Tabellenspeicher. Diese Datenbanken verwenden alle stark verschlüsselten Speicher, um sicherzustellen, dass niemand anderes als die Anwendungen mit ordnungsgemäßen Berechtigungen Ihre Daten lesen kann. Selbst die Systemoperatoren können daten, die verschlüsselt wurden, nicht lesen. So können Kunden sicher bleiben, dass ihre geheimen Informationen geheim bleiben.

Lagerung

Die Untermauerung eines Großteils von Azure ist das Azure Storage-Modul. Datenträger für virtuelle Computer werden über Azure Storage bereitgestellt. Azure Kubernetes Service wird auf virtuellen Computern ausgeführt, die selbst auf Azure Storage gehostet werden. Selbst serverlose Technologien wie Azure Functions Apps und Azure Container Instances verbrauchen den Speicherplatz, der Teil von Azure Storage ist.

Wenn Azure Storage gut verschlüsselt ist, bietet es eine Grundlage dafür, dass auch das meiste andere verschlüsselt werden kann. Azure Storage wird mit FIPS 140-2-kompatiblen256-Bit-AES verschlüsselt. Dies ist eine gut angesehene Verschlüsselungstechnologie, die in den letzten 20 oder so jahren umfangreiche akademische Prüfung unterzogen wurde. Derzeit gibt es keinen bekannten praktischen Angriff, der es jemandem ohne Kenntnis des Schlüssels ermöglichen würde, Daten zu lesen, die von AES verschlüsselt wurden.

Standardmäßig werden die schlüssel, die zum Verschlüsseln von Azure Storage verwendet werden, von Microsoft verwaltet. Es gibt umfangreiche Schutzmaßnahmen, um den böswilligen Zugriff auf diese Schlüssel zu verhindern. Benutzer mit bestimmten Verschlüsselungsanforderungen können jedoch auch eigene Speicherschlüssel bereitstellen , die in Azure Key Vault verwaltet werden. Diese Schlüssel können jederzeit widerrufen werden, wodurch der Inhalt des Speicherkontos, der diese Schlüssel verwendet, effektiv unzugänglich gemacht wird.

Virtuelle Computer verwenden verschlüsselten Speicher, aber es ist möglich, eine andere Verschlüsselungsebene mithilfe von Technologien wie BitLocker unter Windows oder DM-Crypt unter Linux bereitzustellen. Diese Technologien bedeuten, dass selbst wenn das Datenträgerimage aus dem Speicher verloren ging, es nahezu unmöglich wäre, es zu lesen.

Azure SQL

Datenbanken, die in Azure SQL gehostet werden, verwenden eine Technologie namens Transparent Data Encryption (TDE), um sicherzustellen, dass Daten verschlüsselt bleiben. Sie ist standardmäßig für alle neu erstellten SQL-Datenbanken aktiviert, muss jedoch manuell für Legacydatenbanken aktiviert werden. TDE führt echtzeitbasierte Verschlüsselung und Entschlüsselung nicht nur der Datenbank, sondern auch der Sicherungen und Transaktionsprotokolle aus.

Die Verschlüsselungsparameter werden in der master Datenbank gespeichert und beim Start in den Arbeitsspeicher für die verbleibenden Vorgänge eingelesen. Dies bedeutet, dass die master Datenbank unverschlüsselt bleiben muss. Der tatsächliche Schlüssel wird von Microsoft verwaltet. Benutzer mit exakten Sicherheitsanforderungen stellen jedoch möglicherweise ihren eigenen Schlüssel in Key Vault auf die gleiche Weise bereit wie für Azure Storage. Der Key Vault bietet Dienste wie Schlüsselrotation und Sperrung an.

Der "Transparente" Teil von TDS stammt aus der Tatsache, dass keine Clientänderungen erforderlich sind, um eine verschlüsselte Datenbank zu verwenden. Obwohl dieser Ansatz eine gute Sicherheit bietet, reicht das Auslaufen des Datenbankkennworts aus, damit Benutzer die Daten entschlüsseln können. Es gibt einen anderen Ansatz, der einzelne Spalten oder Tabellen in einer Datenbank verschlüsselt. Always Encrypted stellt sicher, dass die verschlüsselten Daten an keinem Punkt in Nur-Text in der Datenbank angezeigt werden.

Zum Einrichten dieser Verschlüsselungsebene muss ein Assistent in SQL Server Management Studio ausgeführt werden, um die Art der Verschlüsselung auszuwählen und wo im Key Vault die zugehörigen Schlüssel gespeichert werden sollen.

Abbildung 9-6. Auswählen von Spalten in einer Tabelle, die mit Always Encrypted verschlüsselt werden sollen.

Clientanwendungen, die Informationen aus diesen verschlüsselten Spalten lesen, müssen besondere Vorkehrungen treffen, um verschlüsselte Daten zu lesen. Verbindungszeichenfolgen müssen mit Column Encryption Setting=Enabled aktualisiert werden und Clientanmeldeinformationen müssen aus dem Key Vault abgerufen werden. Der SQL Server-Client muss dann mit den Spaltenverschlüsselungsschlüsseln primiert werden. Sobald dies erfolgt ist, verwenden die verbleibenden Aktionen die Standardschnittstellen zum SQL Client. Das heißt, Tools wie Dapper und Entity Framework, die auf SQL Client basieren, funktionieren weiterhin ohne Änderungen. Always Encrypted ist möglicherweise noch nicht für jeden SQL Server-Treiber in jeder Sprache verfügbar.

Die Kombination aus TDE und Always Encrypted, die beide mit clientspezifischen Schlüsseln verwendet werden können, stellt sicher, dass selbst die exaktsten Verschlüsselungsanforderungen unterstützt werden.

Cosmos DB

Cosmos DB ist die neueste Datenbank von Microsoft in Azure. Es wurde von Grund auf unter Berücksichtigung von Sicherheitsaspekten und Kryptografie aufgebaut. AES-256bit-Verschlüsselung ist Standard für alle Cosmos DB-Datenbanken und kann nicht deaktiviert werden. Gekoppelt mit der TLS 1.2-Anforderung für die Kommunikation wird die gesamte Speicherlösung verschlüsselt.

Abbildung 9-7. Der Fluss der Datenverschlüsselung innerhalb von Cosmos DB.

Während Cosmos DB nicht die Möglichkeit zur Bereitstellung von Kundenverschlüsselungsschlüsseln bietet, hat das Team erhebliche Anstrengungen unternommen, um sicherzustellen, dass es PCI-DSS-konform bleibt. Cosmos DB unterstützt auch keine Art von Einzelspaltenverschlüsselung, ähnlich wie die Always Encrypted von Azure SQL.

Sicher halten

Azure verfügt über alle Tools, die zum Freigeben eines hochsicheren Produkts erforderlich sind. Eine Kette ist jedoch nur so stark wie ihre schwächste Verbindung. Wenn die über Azure bereitgestellten Anwendungen nicht mit einer richtigen Sicherheits-Denkweise und guten Sicherheitsüberwachungen entwickelt werden, werden sie zur schwachen Verbindung in der Kette. Es gibt viele großartige statische Analysetools, Verschlüsselungsbibliotheken und Sicherheitspraktiken, die verwendet werden können, um sicherzustellen, dass die auf Azure installierte Software so sicher wie Azure selbst ist. Beispiele sind statische Analysetools und Verschlüsselungsbibliotheken.

ZurückWeiter