Bewährte Methoden, Prozesse und Grundprinzipien für das Entwerfen und Entwickeln sicherer Anwendungen in der Cloud
E-Book, Deutsch, 570 Seiten
Reihe: Best Practices
ISBN: 978-3-9889008-9-0
Verlag: dpunkt
Format: EPUB
Kopierschutz: Wasserzeichen (»Systemvoraussetzungen)
- praktisches Tutorial und hilfreiches Referenzwerk in einem
- behandelt die Azure-Sicherheitsdienste sowohl auf Anwendungs- als auch auf Netzwerkebene sowie deren Zusammenarbeit
- inkl. kostenloser Code-Beispiele zum Download
Wenn wichtige Anwendungen und Workloads eines Unternehmens in die Microsoft Azure-Cloud verlagert werden, müssen sie gegen eine Vielzahl von ebenso unterschiedlichen wie gefährlichen Bedrohungen gewappnet werden. Um ihre Sicherheit zu optimieren, ist es erforderlich, dass Sie diese bereits zuverlässig in Ihre Entwürfe einbauen, bewährte Best Practices über die gesamte Entwicklung hinweg anwenden und verschiedene Azure-Dienste kombinieren.
In diesem Buch zeigen Ihnen drei führende Azure-Sicherheitsexperten, wie Sie genau das tun. Auf der Grundlage ihrer umfangreichen Erfahrungen mit der Absicherung von Azure-Workloads geben die Autoren Ihnen eine praktische Anleitung zur Bewältigung unmittelbarer Sicherheitsherausforderungen an die Hand sowie eine umfassende Referenz, auf die Sie sich über Jahre hinweg verlassen können. Egal ob Softwarearchitektin, Softwareentwickler oder beim Testen: Integrieren Sie die wichtigsten Azure-Sicherheitstechnologien – von Entwurf und Entwicklung über Tests und Bereitstellung bis hin zu Governance und Compliance.
In diesem Buch werden folgende Themen behandelt:
- Verbesserung der Anwendungs-/Workload-Sicherheit, Verringerung der Angriffsflächen und Implementierung von Zero Trust im Cloud-Code
- Anwendung von Sicherheitsmustern zur einfacheren Lösung gängiger Probleme
- Frühzeitige Modellierung von Bedrohungen, um wirksame Abhilfemaßnahmen zu planen
- Implementierung moderner Identitätslösungen mit OpenID Connect und OAuth2
- Azure-Monitoring, Protokollierung und Kusto-Abfragen optimal nutzen
- Absicherung von Workloads mit den Best Practices von Azure Security Benchmark (ASB)
- Prinzipien für sicheren Code, defensiven Code schreiben, unsicheren Code reparieren und Codesicherheit testen
- Nutzung von Azure-Kryptographie und Technologien für verschlüsselte Datenverarbeitung
- Verstehen von Compliance- und Risikoprogrammen
- Sichere automatisierte CI/CD-Workflows und -Pipelines
- Verstärkung der Container- und Netzwerksicherheit
Weitere Infos & Material
KAPITEL 1
Prozesse für sichere Entwicklungszyklen
Am Ende dieses Kapitels verstehen Sie einige der Prozesse, die für die Entwicklung sicherer Software erforderlich sind. können Sie innerhalb Ihrer Organisation dazu beitragen, eine Sicherheitskultur zu entwickeln. sind Sie in der Lage, den Zweck der verschiedenen Arten von Umgebungen für die Entwicklung bis hin zur Produktion zu erläutern und welche unterschiedlichen Sicherheitsmaßnahmen sie erfordern. Entwickler sind die Hauptursache für Kompromittierungen
Die Hauptursache für Gefährdungen sind nicht Hacker, Angreifer oder andere ruchlose Akteure. Vielmehr sind wir, die Softwareentwickler, die Hauptursache für Sicherheitslücken. Laut einer Analyse von Contrast Security aus dem Jahr 2020 sind fast 50 Prozent aller Kompromittierungen auf Schwachstellen in Anwendungen zurückzuführen – Schwachstellen, die letztlich von Softwareentwicklern geschaffen wurden. Eine Zusammenfassung des Berichts können Sie hier lesen: https://azsec.tech/lvz. Als Softwareentwickler können wir nicht viel gegen Angriffe tun. Sie werden auf jeden Fall stattfinden. Was wir aber tun können, ist, die Sicherheit unseres Codes zu verbessern. Wir kommen nicht darum herum, dass das Design unseres Systems und die Qualität unseres Codes den Unterschied zwischen einem fehlgeschlagenen und einem erfolgreichen Angriff ausmachen können. Wir müssen die Art und Weise ändern, wie wir Software entwerfen und entwickeln, um die Sicherheit so nahtlos wie möglich und mit so wenig Reibungsverlusten wie möglich zu verbessern. Das entscheidende Wort hier ist Reibung. Sicherheit wird oft als eine Art Steuer angesehen, die Entwickler zahlen müssen und die die Entwicklung behindert. Sie steht einfach im Weg. Wir müssen Prozesse und Aufgaben einbeziehen, die die Sicherheit erhöhen, die so reibungslos wie möglich sind und einfach als ein weiterer wichtiger Aspekt bei der Erledigung der Aufgabe angesehen werden. Natürlich sind auch Werkzeuge wichtig. Aber sie sollten nicht blindlings eingesetzt oder als einzige Quelle für die Sicherheit Ihrer Lösung betrachtet werden. Ganz gleich, wie viele Tools oder Automatisierungsfunktionen Sie bei Ihren Entwicklungsverfahren einsetzen, letztendlich sind es Menschen, die Software erstellen, und auch Ihre Sicherheitslage hängt von Menschen ab. Wie das Sprichwort sagt: »Ein Dummkopf mit einem Werkzeug ist immer noch ein Dummkopf.« Wir müssen also nicht nur in die neuesten Sicherheitstools investieren, sondern auch in menschliches Sicherheitskapital und Prozesse. Dieses Kapitel beschäftigt sich sowohl mit dem Prozess und den menschlichen Aspekten der Praktiken für die Softwareentwicklung; aber auch die technischen Aspekte kommen nicht zu kurz. Das Ziel ist, wie erwähnt, bei der Bereitstellung von sicheren Softwarelösungen so reibungslos zu sein wie möglich. Einführung in den Microsoft Security Development Lifecycle
Der Microsoft Security Development Lifecycle (SDL) entstand Anfang der 2000er-Jahre und wurde im Laufe der Jahre angewandt und angepasst. Ein Sprichwort sagt: »Es gibt nichts Neues unter der Sonne«, und das trifft auf den SDL zu. Der SDL unterscheidet sich jedoch durch die Menge an unterstützender Dokumentation, Werkzeugen, Forschungsergebnissen und Vordenkern, die Microsoft öffentlich zugänglich gemacht hat. Was also ist der SDL? Der SDL besteht aus einer Reihe von Praktiken zur Verbesserung der Softwaresicherheit. Er verfolgt zwei übergreifende Ziele: Verringerung der Anzahl von Sicherheitslücken in Ihrem Code Verringerung der Schwere der Schwachstellen, die Sie übersehen Diese beiden Ziele führen zu einer gewissen Spannung in Ihrer Sicherheitsstrategie. Sie möchten die sicherste Software entwickeln, müssen aber gleichzeitig damit rechnen, dass Ihnen etwas entgeht und dass sich die Strategien der Angreifer mit der Zeit weiterentwickeln. Was heute sicher und korrekt ist, kann morgen angreifbar sein. Um Ihr Wissen zu vervollständigen, empfehlen wir Ihnen, die vollständige Liste der SDL-Anforderungen zu lesen, die Sie hier finden:
https://www.microsoft.com/securityengineering/sdl/practices. Qualität ? Sicherheit Wir hören oft, dass Leute sagen: »Wenn man die Qualität verbessert, dann verbessert sich auch die Sicherheit.« Diese Aussage klingt zwar plausibel, aber es gibt keine Beweise, die diese Aussage stützen. Keine. Softwarequalitätsprogramme finden nur selten Sicherheitsprobleme, denn Sicherheitsprobleme sind etwas anderes als Qualitätsprobleme. Außerdem wird Sicherheit, wie wir später in diesem Buch erörtern, oft als »zusätzliche« Funktionalität definiert. Angenommen, Sie haben eine Anwendung, die lediglich die folgenden Datenbankoperationen durchführt: Hinzufügen eines neuen Benutzers (Erstellen/Create in CRUD) Lesen der Details eines Benutzers (Lesen/Read in CRUD) Bearbeitung der Benutzerdaten (Aktualisierung/Update in CRUD) Löschen eines Benutzers (Löschen/Delete in CRUD) Drucken der Benutzerdaten Sie erstellen einige Tests, die erfolgreich oder (absichtlich!) fehlschlagen sollen, und überprüfen dann diese Erfolge und Fehlschläge. Wenn alle Tests, die den Erfolg überprüfen sollen, erfolgreich sind und alle Tests, die das Scheitern überprüfen sollen, pflichtgemäß scheitern, könnte man zu dem Schluss kommen, dass die Anwendung keine Fehler aufweist. Dies ist jedoch nicht der Fall. Wenn die Anwendung beispielsweise eine SQL-Injection-Schwachstelle aufweist, die es einem Tester (oder Angreifer) ermöglicht, alle Benutzer zu lesen oder eine Datenbanktabelle zu löschen, wird die Anwendung dennoch alle Erfolgstests bestehen und alle Fehlertests nicht bestehen. Die Moral von der Geschichte ist, dass Sie Ihren Softwareentwicklungsprozessen Sicherheit als eigenen Faktor hinzufügen müssen. Sicherungsmerkmale vs. Sicherheitsmerkmale Das Microsoft SDL konzentriert sich auf die Sicherung Ihrer Software, nicht nur auf das Hinzufügen weiterer Sicherheitsfunktionen. Sicherheitsfunktionen sind wichtig, aber Sie können nicht einfach jedes beliebige Sicherheitsprodukt in Ihre Lösung einbauen und sie als sicher bezeichnen. Die Funktionen, die Sie Ihren Lösungen hinzufügen, müssen ebenfalls sicher sein. Diese philosophische Perspektive stellt einen wichtigen Sinneswandel für viele dar, die glauben, sie könnten ein Produkt kaufen und es als erledigt betrachten – vor allem, wenn so viele Unternehmen ihre Produkte als Allheilmittel verkaufen. Kurz, Sie müssen sich auf die Disziplin der Softwareentwicklungssicherheit konzentrieren. Sie können diese Verantwortung nicht auf ein Produkt abwälzen. SDL-Komponenten
Die wichtigsten Aufgaben und Anforderungen von Microsoft SDL sind wie folgt: Sicherheitsschulung Definieren Ihrer Bug Bar Analyse der Angriffsfläche Modellierung von Bedrohungen Definieren Ihrer Toolchain Verbotene Funktionalität vermeiden Werkzeuge zur statischen Analyse verwenden Dynamische Analysetools verwenden Review des Sicherheitscodes Reaktionsplan bei Zwischenfällen zur Hand haben Penetrationstests durchführen Schauen wir die einzelnen Punkte genauer an. Agile SDL Sie werden vielleicht denken, dass diese Liste mit Anforderungen vor allem für ein Wasserfallmodell gilt. Tatsächlich handelt es sich aber nur um eine Liste von Aufgaben, die erledigt werden müssen; sie gibt nicht an, wann Sie sie erledigen müssen. Es kann sein, dass Sie nur einen Sprint damit verbringen, an einigen Aufgaben zu arbeiten, und diese Arbeit wird dann für alle zukünftigen Sprints gelten. Wir werden erläutern, wie man jede dieser Aufgaben in einer agilen Umgebung am besten anwendet. Sicherheitsschulung Sicherheitsschulungen sind ein Muss. Aber mit Sicherheitsschulung meinen wir nicht die Schulung »Passwörter nicht wiederverwenden!«, sondern die Schulung »Sicherheit bei der Anwendungsentwicklung«. Lange Zeit verlangte Microsoft von allen technischen Mitarbeitern, dass sie an allgemeinen Sicherheitsschulungen teilnehmen, und die Mitarbeiter können dies auch heute noch tun, wenn sie wollen. Heutzutage verwenden wir jedoch ein...
