Microsoft Azure Security (eBook)
570 Seiten
dpunkt (Verlag)
978-3-98890-089-0 (ISBN)
Michael Howard ist Principal Security Program Manager im Bereich Security Engineering. Er ist einer der Architekten des Microsoft Security Development Lifecycle und hat einer Vielzahl von unterschiedlichen Kunden dabei geholfen, ihre Azure-Workloads zu sichern. Heinrich Gantenbein ist Senior Principal Consultant für Cybersicherheit bei Microsofts Industry Solutions Delivery. Mit über 30 Jahren Erfahrung im Softwareengineering und in der Beratung bringt er jede Menge praktisches Know-how in seine Rolle ein. Er ist auf Azure-Sicherheit, Bedrohungsmodellierung und DevSecOps spezialisiert.Simone Curzi ist Principal Consultant bei Microsofts Industry Solutions Delivery. Als anerkannter Experte für Bedrohungsmodellierung und den Microsoft Security Development Lifecycle tritt er regelmäßig als Speaker auf internationalen Konferenzen auf.
Michael Howard ist Principal Security Program Manager im Bereich Security Engineering. Er ist einer der Architekten des Microsoft Security Development Lifecycle und hat einer Vielzahl von unterschiedlichen Kunden dabei geholfen, ihre Azure-Workloads zu sichern. Heinrich Gantenbein ist Senior Principal Consultant für Cybersicherheit bei Microsofts Industry Solutions Delivery. Mit über 30 Jahren Erfahrung im Softwareengineering und in der Beratung bringt er jede Menge praktisches Know-how in seine Rolle ein. Er ist auf Azure-Sicherheit, Bedrohungsmodellierung und DevSecOps spezialisiert.Simone Curzi ist Principal Consultant bei Microsofts Industry Solutions Delivery. Als anerkannter Experte für Bedrohungsmodellierung und den Microsoft Security Development Lifecycle tritt er regelmäßig als Speaker auf internationalen Konferenzen auf.
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: |
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...
Erscheint lt. Verlag | 28.11.2023 |
---|---|
Reihe/Serie | Best Practices | Best Practices |
Übersetzer | Rainer G. Haselier |
Verlagsort | Heidelberg |
Sprache | deutsch |
Themenwelt | Mathematik / Informatik ► Informatik ► Netzwerke |
Schlagworte | Cloud Computing • Compliance • Datenbank-Sicherheit • Governance • Kryptografie • Monitoring • Netzwerksicherheit • security patterns • sichere Anwendungen • Sicherheit • software architecture • Softwarearchitektur • software development • Softwareentwicklung |
ISBN-10 | 3-98890-089-3 / 3988900893 |
ISBN-13 | 978-3-98890-089-0 / 9783988900890 |
Haben Sie eine Frage zum Produkt? |
![EPUB](/img/icon_epub_big.jpg)
Größe: 10,6 MB
DRM: Digitales Wasserzeichen
Dieses eBook enthält ein digitales Wasserzeichen und ist damit für Sie personalisiert. Bei einer missbräuchlichen Weitergabe des eBooks an Dritte ist eine Rückverfolgung an die Quelle möglich.
Dateiformat: EPUB (Electronic Publication)
EPUB ist ein offener Standard für eBooks und eignet sich besonders zur Darstellung von Belletristik und Sachbüchern. Der Fließtext wird dynamisch an die Display- und Schriftgröße angepasst. Auch für mobile Lesegeräte ist EPUB daher gut geeignet.
Systemvoraussetzungen:
PC/Mac: Mit einem PC oder Mac können Sie dieses eBook lesen. Sie benötigen dafür die kostenlose Software Adobe Digital Editions.
eReader: Dieses eBook kann mit (fast) allen eBook-Readern gelesen werden. Mit dem amazon-Kindle ist es aber nicht kompatibel.
Smartphone/Tablet: Egal ob Apple oder Android, dieses eBook können Sie lesen. Sie benötigen dafür eine kostenlose App.
Geräteliste und zusätzliche Hinweise
Buying eBooks from abroad
For tax law reasons we can sell eBooks just within Germany and Switzerland. Regrettably we cannot fulfill eBook-orders from other countries.
aus dem Bereich