Freigeben über

Architekturstrategien für die Sicherung eines Entwicklungslebenszyklus

Gilt für diese Empfehlung der Azure Well-Architected Framework-Sicherheitsprüfliste:

SE:02 Richten Sie den sicheren Entwicklungslebenszyklus (SDL) im gesamten Lebenszyklus der Softwareentwicklung (SDLC) aus, um die Vertraulichkeit, Integrität und Verfügbarkeit von Software zu gewährleisten und eine Sicherheits-erste Denkweise zu übernehmen.

Anwendungscode ist der Kern jeder Workload. Betten Sie die Sicherheit im gesamten SDLC ein, indem Sie Steuerelemente in mehreren Entwicklungsphasen integrieren. Ziel ist es, sicherzustellen, dass Entwurfsentscheidungen keine vermeidbaren Sicherheitslücken darstellen und dass Code- und Konfigurationsentscheidungen nicht zu ausnutzbaren Sicherheitsrisiken führen.

Ein Diagramm des Sicherheitszyklus.

In diesem Leitfaden werden bewährte Methoden zur Sicherheit beschrieben, um Anwendungscode zu schützen und anfällige Implementierungen und die Einführung kompromittierter Komponenten zu verhindern. Erweitern Sie die bewährten Methoden auf Drittanbieter- und Open-Source-Komponenten, um das Lieferkettenrisiko zu reduzieren. Der Fokus liegt nicht auf der Infrastrukturebene.

Der Leitfaden basiert auf SDL-Praktiken und setzt ein grundlegendes Verständnis von DevSecOps-Prinzipien voraus. Es erstreckt sich über den Anwendungscode hinaus, um die gesamte Software-Lieferkette zu adressieren, einschließlich Entwicklerarbeitsstationen, Quellrepositorys, Buildsysteme und Bereitstellungsumgebungen.

Terminologie

Begriff Definition
Gemeinsame Schwachstellen und Expositionen (CVE) Eine öffentlich verfügbare Datenbank bekannter Sicherheitsrisiken und Gefährdungen in Software- und Hardwareprodukten.
Verteidigung in der Tiefe Eine Sicherheitsstrategie, die mehrere Schutzebenen verwendet, um Systeme zu schützen. Wenn also eine Ebene fehlschlägt, bieten andere weiterhin Sicherheit.
DevSecOps Ein Ansatz, der Sicherheitspraktiken in den DevOps-Prozess integriert, wobei die Zusammenarbeit zwischen Entwicklungs-, Sicherheits- und Betriebsteams während des gesamten Softwarelebenszyklus hervorgehoben wird.
Dynamische Anwendungssicherheitstests (DAST) Sicherheitstests, die Anwendungen während der Laufzeit analysieren, um Sicherheitsrisiken zu identifizieren, indem reale Angriffsszenarien simuliert werden.
Verwaltete Identität Ein Azure-Feature, das Anwendungen eine automatisch verwaltete Identität in Microsoft Entra-ID bereitstellt, ohne dass Anmeldeinformationen im Code gespeichert werden müssen.
Progressive Belichtung Eine Bereitstellungsstrategie, die schrittweise Änderungen an Teilmengen von Benutzern veröffentlicht, um Risiken zu minimieren und potenzielle Probleme zu enthalten.
Sicherheitsentwicklungslebenszyklus (SDL) Eine Reihe von Methoden, die von Microsoft bereitgestellt werden, die Sicherheitsüberprüfungs- und Complianceanforderungen unterstützen.
Lebenszyklus der Softwareentwicklung (SDLC) Ein mehrstufiger, systematischer Prozess für die Entwicklung von Softwaresystemen.
Statische Anwendungssicherheitstests (Static Application Security Testing, SAST) Sicherheitstests, die Quellcode, Bytecode oder Binärdateien analysieren, ohne das Programm auszuführen, um potenzielle Sicherheitsrisiken zu identifizieren.
SCHREITEN Eine Methodik zur Bedrohungsmodellierung, die Bedrohungen in sechs Arten kategorisiert: Spoofing, Manipulation, Ablehnung, Offenlegung von Informationen, Denial of Service und Rechteerweiterung.
Sicherheit der Lieferkette Schutz der gesamten Software-Lieferkette, einschließlich Komponenten von Drittanbietern, Entwicklungstools und Prozessen vor Kompromittierung oder Manipulation.
Bedrohungsmodellierung Ein strukturierter Prozess zum Identifizieren, Bewerten und Verringern potenzieller Sicherheitsbedrohungen für ein System frühzeitig in der Entwurfsphase.

Denken Sie von Tag 1 an über Sicherheit nach

Definieren Sie bei den frühesten Planungs- und Architekturdiskussionen sowohl funktionale als auch nicht funktionale Sicherheitsanforderungen neben den Geschäftszielen. Überlagern Sie die Architektur mit Sicherheitssteuerelementen. Denken Sie an Isolationsgrenzen, Außen- und Innenzugriff und Vertraulichkeitsstufen, die für Workloaddaten gelten. Es wird empfohlen, die Sicherheitscheckliste sorgfältig zu folgen, um die Sicherheitsdimension der Architektur zu entwickeln. Überprüfen Sie auch Architekturentwurfsmuster, die Sicherheit unterstützen.

Um das Team verantwortlich zu halten, müssen Sicherheitsüberlegungen und Ergebnisse direkt zu Backlogelementen hinzugefügt werden, damit sie als Teil des Produkts entworfen und bereitgestellt werden. Betrachten Sie beispielsweise eine Anwendung, die kritische Benutzerflüsse unterstützt, mit der Benutzer Daten hochladen und bearbeiten können. Sicherheitslieferumsätze müssen die Interaktion von Benutzern mit dem System (Erzwingen einer starken Authentifizierung und Autorisierung) adressieren, um sicherzustellen, dass nur zulässige Aktionen zulässig sind.

Architekten müssen Sicherheitsabschläge explizit dokumentieren und die Risikoakzeptanz formalisieren, um Transparenz und Rechenschaftspflicht zu gewährleisten. Eine Sicherheitsentscheidung kann z. B. maßnahmen erfordern, um OWASP-Sicherheitsrisiken vorab zu blockieren. Wenn die Beteiligten sich dafür entscheiden, sie nicht zu finanzieren, müssen sie das resultierende Risiko von Angriffen auf Anwendungsebene anerkennen und akzeptieren.

Auswählen von Technologieoptionen, die Sicherheit unterstützen

Identifizieren Sie die Sicherheitskontrollen, die erforderlich sind, um Ihre gewünschten Ergebnisse zu erzielen, und nutzen Sie die systemeigenen Funktionen von Azure, sofern möglich. Definieren Sie beispielsweise eine Segmentierungsstrategie mithilfe von Identitäts-, Netzwerk- und Ressourcengrenzen und wählen Sie Webanwendungs-Firewalls (WAFs) wie Azure Front Door oder Azure Application Gateway aus, um die Anwendung zu schützen. Wenn ein WAF beim Ingress erforderlich ist, verwenden Sie diese verwalteten Dienste, anstatt ihre Funktionalität im benutzerdefinierten Anwendungscode zu replizieren.

Technische Überlegungen umfassen auch die Auswahl von vertrauenswürdigen Frameworks, Bibliotheken und Lieferkettensoftware, die von verifizierten Anbietern stammen. Drittanbieter müssen Ihre Sicherheitsanforderungen erfüllen und einen verantwortungsvollen Offenlegungsplan verwalten und alle Sicherheitsvorfälle umgehend melden. Verwalten Sie eine Liste genehmigter und unzulässiger Ressourcen, und erzwingen Sie ggf. Schutzschienen in Entwicklungspipelines, um die Verwendung nicht genehmigter Komponenten zu verhindern. Bei genehmigten Abhängigkeiten hilft die automatisierte Überprüfung dabei, Sicherheitsrisiken frühzeitig und konsistent zu erkennen.

Entscheiden Sie, wie Anwendungsschlüssel und vorab freigegebene Schlüssel auf sichere Weise gespeichert werden. Speichern Sie niemals Anmeldeinformationen oder geheime Schlüssel im Quellcode-Repository. Verwenden Sie externe Tools wie Azure Key Vault, sodass Angreifer auch dann keinen Zugriff erhalten können, wenn der Quellcode verfügbar gemacht wird. Vermeiden Sie, wenn möglich, geheime Schlüssel vollständig zu verwenden, z. B. durch Nutzung von verwalteten Identitäten. Weitere Anleitungen finden Sie unter Empfehlungen zum Verwalten von Anwendungsgeheimnissen.

Erstellen einer Designdisziplin zur Bedrohungsmodellierung

Mithilfe der Bedrohungsmodellierung können Sie Sicherheitsrisiken erkennen, Bedrohungen auswerten und Risikominderungen frühzeitig in der Entwurfsphase definieren. Definieren Sie zunächst den Bereich: Legen Sie klare Systemgrenzen fest und inventarisieren Sie Ihre Ressourcen, damit Sie sich auf das Wesentliche konzentrieren. Sammeln Sie detaillierte Informationen zu jeder Komponente, einschließlich Datenflüssen und Abhängigkeiten, und analysieren Sie die einzelnen Komponenten aus der Perspektive eines Angreifers, um zu bestimmen, wie sie ausgenutzt werden könnte. Verinnerlichen Sie die Denkweise Annahme von Sicherheitsverstößen – planen Sie für Kontrollversagen und wenden Sie die Tiefenverteidigung an, um die Auswirkungen einzudämmen.

Verwenden Sie eine Branchenmethodik wie STRIDE , um Bedrohungen zu klassifizieren und Entschärfungsentscheidungen voranzutreiben. Dokumentieren Sie jede identifizierte Bedrohung, die Steuerelemente, die sie verhindern, und den Antwortplan, wenn diese Steuerelemente fehlschlagen. Definieren Sie klare Zeitrahmen und Zuständigkeiten, um Schwachstellen schnell zu beheben, damit sie nicht unbearbeitet bleiben.

Verfolgen Sie die Ergebnisse der Bedrohungsmodellierung, und überprüfen Sie sie während des gesamten Workload-Lebenszyklus. Aktualisieren Sie das Modell, da sich die Architektur weiterentwickelt, um sicherzustellen, dass neue Features und Änderungen kein nicht verwaltetes Risiko darstellen.

Weitere Informationen finden Sie unter: Microsoft Threat Modeling Tool

Entwickeln von Expertise im sicheren Codieren

Stellen Sie sicher, dass das Entwicklungsteam formale, rollenspezifische Schulungen in sicheren Codierungspraktiken abschließt. Web- und API-Entwickler sollten z. B. wissen, wie die websiteübergreifende Skripterstellung (Cross Site Scripting, XSS) verhindert werden kann, während Back-End-Entwickler verstehen sollten, wie Risiken wie SQL-Einfügung und andere Angriffe auf Datenbankebene abgemildert werden. Fordern Sie Entwickler auf, diese Schulung abzuschließen, bevor Sie Zugriff auf den Produktionsquellcode gewähren. Stärken Sie diese Fähigkeiten durch interne Peer-Code-Überprüfungen, die Verantwortlichkeit, Wissensaustausch und kontinuierliche Verbesserung fördern.

Verwenden von Sicherheitstests als strategische Kontrolle

Machen Sie Sicherheitstests zu einer kerntechnischen Disziplin. Richten Sie eine Teststrategie ein, die Architektur, Code und Laufzeitverhalten während des gesamten Entwicklungslebenszyklus kontinuierlich auswertet. Verwenden Sie eine Mischung aus Architektur-Analyse, statischen und dynamischen Tests, Abhängigkeitsscan und automatisierte Schutzmechanismen.

Verwenden Sie statische Anwendungssicherheitstests (SAST), um Sicherheitsrisiken im Code zu erkennen, während Entwickler sie schreiben. Ergänzen Sie dies durch dynamische Anwendungssicherheitstests (DAST), um die ausgeführte Anwendung auszuwerten und reale Angriffsszenarien zu simulieren.

Integrieren Sie automatisierte Sicherheitsüberprüfungen in Build- und Integrationsworkflows, sodass Sicherheit zu einem Qualitätsgater wird. Scannen Sie Abhängigkeiten und Komponenten von Drittanbietern kontinuierlich, und behandeln Sie anfällige Bibliotheken als Lieferkettenrisiken, die eine aktive Verwaltung erfordern. Verwenden Sie Linters und Codeanalysatoren, um zu verhindern, dass vertrauliche Daten, wie z.B. Anmeldedaten, in die Quellcodeverwaltung gelangen. Verstärken Sie diese Schutzmaßnahmen durch Pipelinesicherheitsmaßnahmen, die das Aufdecken von Geheimnissen erkennen und blockieren.

Übernehmen Sie Branchenstandards als Eine Möglichkeit, um Ihr Vertrauen in Ihre Sicherheitsresilienz zu steigern. Weitere Informationen finden Sie im Abschnitt " Communityressourcen " in diesem Artikel.

Schreiben Sie nur genügend Code

Jede Codezeile erhöht Ihre Angriffsfläche. Priorisieren Sie die Wiederverwendung gegenüber neuerfindung. Verwenden Sie bewährte Frameworks und Bibliotheken, die bereits eine Sicherheitsüberprüfung durchlaufen haben, anstatt Funktionen in benutzerdefiniertem Code zu duplizieren.

Verinnerlichen Sie eine plattformorientierte Denkweise. Verwenden Sie verwaltete Azure-Dienste und PaaS-Funktionen, wenn möglich, um schwere Hebelastungen an Azure zu entladen, z. B. Authentifizierung, Verschlüsselung, Skalierung und Eingangsschutz. Je weniger benutzerdefinierte Sicherheitslogik Sie schreiben, desto niedriger ist ihr langfristiges Risiko.

Wenn Sie Code schreiben, standardmäßig verweigern. Entwerfen Sie autorisierungslogik so, dass der Zugriff blockiert wird, es sei denn, der Zugriff ist explizit zulässig. Verwenden Sie Zulassungslisten für bestimmte, genehmigte Entitäten, und stellen Sie sicher, dass privilegierte Vorgänge nur dann erfolgreich ausgeführt werden, wenn sie eindeutig autorisiert sind.

Entwicklerumgebungen stärken

Ihre Entwicklungsumgebung ist Teil Ihrer Angriffsfläche. Schützen Sie Entwicklerarbeitsstationen mit demselben Rigor wie Produktionssysteme. Dies bedeutet, dass starke Identitätskontrollen durchgesetzt, Netzwerkschutzmaßnahmen umgesetzt und das Patchen diszipliniert ausgeführt wird. Eine kompromittierte Arbeitsstation kann zu einem direkten Zugang zu Ihrer Codebasis und zu Ihren Buildsystemen werden.

Ihr Quellcode-Repository ist eine wichtige Ressource. Gewähren Sie Zugriff nach dem Prinzip der geringsten Rechte und nur auf Basis des notwendigen Wissens. Richten Sie strukturierte, sicherheitsorientierte Codeüberprüfungsprozesse mit klaren Genehmigungsworkflows ein, die an geschäftliche Begründungen gebunden sind. Eine starke Governance über Repositorys und Pipelines reduziert die Wahrscheinlichkeit von Manipulationen und begrenzt die Auswirkungen einer Verletzung.

Außerdem sollte der Netzwerkzugriff segmentiert werden, damit Entwickler keinen direkten Zugriff auf Produktionssysteme haben.

Entwicklungstools können auch dazu beitragen, die Sicherheit zu verbessern, indem IDE-Erweiterungen verwendet werden, die Code überwachen, wie er geschrieben ist, und lokale Builds auf Sicherheitsrisiken überprüfen. Anmeldeinformationen müssen geschützt werden, indem sichergestellt wird, dass geheime Schlüssel nicht in Konfigurationsdateien gespeichert werden und anmeldeinformationsmanager verwendet werden, wenn der Zugriff auf geheime Schlüssel erforderlich ist.

Entwickler sollten genehmigten Entwicklertools folgen und Installationen verwenden, die zentral verwaltet werden. Entwicklungsumgebungen wie GitHub Codespaces und Microsoft Dev Box können Sicherheit erzwingen, indem isolierte, zentral verwaltete Arbeitsbereiche bereitgestellt werden.

Tests sollten auch in einer kontrollierten Umgebung mit nur den erforderlichen Mindestberechtigungen ausgeführt werden.

Sichere Build- und Bereitstellungspipeline

Build- und Bereitstellungs-Pipelines sind vorrangige Ziele. Angreifer können Ihre Pipeline manipulieren, schädlichen Code einfügen, geheime Schlüssel aufrufen oder downstream-Umgebungen kompromittieren.

Behandeln Sie Build-Agents als hochwertige Ressourcen. Sie haben privilegierten Zugriff auf Quellcode und Build-Pipelines, was sie zu attraktiven Zielen macht. Authentifizieren und autorisieren Sie den Zugriff streng, segmentieren Sie sie auf Netzwerkebene, und unterliegen sie der kontinuierlichen Sicherheitsüberwachung. Bevorzugen Sie von Microsoft gehostete Build-Agents gegenüber selbst gehosteten Agents, um das Betriebsrisiko zu reduzieren und die Persistenz zu begrenzen, da sie saubere Umgebungen für jede Pipelineausführung bereitstellen. Benutzerdefinierte Agents erhöhen den Verwaltungsaufwand und erweitern die Angriffsfläche.

Sichern Sie Anmeldeinformationen, und entfernen Sie temporäre Artefakte, um Lecks zu verhindern. Wo immer möglich, isolieren Sie Build-Agents, indem Sie den eingehenden Zugriff einschränken und nur kontrollierte ausgehende Kommunikation zulassen.

Beginnen Sie, indem Sie klare Sichtbarkeit und Kontrolle beibehalten. Bewahren Sie einen aktuellen Bestand aller integrierten Komponenten und Abhängigkeiten auf und überprüfen Sie regelmäßig, ob das, was in der Pipeline läuft, mit dem Genehmigten übereinstimmt. Verwenden Sie Pipelineaufgaben und Erweiterungen nur aus vertrauenswürdigen, überprüften Quellen, und erkennen Sie, dass sie mit privilegiertem Zugriff ausgeführt werden.

Schützen Sie Anmeldeinformationen, indem Sie festcodierte Geheimnisse beseitigen und verwaltete Identitäten sowie sichere Geheimnisspeicher bevorzugen.Segmentieren Sie die Pipeline-Stufen, um unnötige Exposition sensibler Vermögenswerte zu verringern und laterale Bewegungen zu begrenzen, wenn eine Phase kompromittiert wird.

Die Umweltisolation ist ebenso wichtig. Halten Sie Produktions- und Nichtproduktionssysteme streng getrennt, vermeiden Sie es, Produktionsdaten in weniger geschützten Umgebungen zu nutzen, und verhindern Sie eine direkte Konnektivität, die die Ausbreitung einer Sicherheitsverletzung ermöglichen könnte. Steuern des Risikos durch progressive Exposition. Führen Sie Änderungen schrittweise mithilfe von Feature-Flags oder stufenweisen Rollouts ein, sodass Sie, wenn eine Sicherheitslücke auftritt, die Auswirkungen eindämmen können. Entwerfen Sie Ihre Pipelines, um sowohl regelmäßige als auch Notfallbereitstellungen zu unterstützen. Sicherheitsfixes erfordern häufig eine schnelle Reaktion, und Ihr Prozess sollte einen schnellen Roll-Forward- oder Rollback ermöglichen, ohne die Systemstabilität zu beeinträchtigen. Legen Sie klare Kommunikations- und Genehmigungsverfahren fest, um Notfalländerungen verantwortungsbewusst zu beschleunigen.

Hinweis

Priorisieren Sie immer Sicherheitsfixes über den Komfort. Kompromittiere niemals die Qualität und führe keine Regressionen ein. Wenn Sie einen Fix über eine Notfallpipeline beschleunigen müssen, bewerten Sie, welche automatisierten Tests sicher umgangen werden können. Berücksichtigen Sie den Kompromiss zwischen dem Wert jedes Tests und dessen Ausführungszeit. Beispielsweise sind Komponententests schnell und wichtig, während Integrations- oder End-to-End-Tests länger dauern können, aber dennoch eine kritische Abdeckung bieten. Treffen Sie diese Entscheidungen absichtlich, um Geschwindigkeit mit Vertrauen in die Korrektur auszubalancieren.

Code in der Produktionsumgebung schützen

Die Produktion ist die letzte Verteidigungslinie zum Schutz von Entwicklercode, bevor sie Benutzer erreicht. Teams sollten einen Datensatz des goldenen Images verwalten, das in der Produktion bereitgestellt wird, und einen Katalog aller bereitgestellten Ressourcen und deren Versionen führen, um Fehlerbehebung, Reaktion auf Vorfälle und Verwaltung von Schwachstellen zu unterstützen. Es kann auch Konfigurationsabweichungsmechanismen beeinflussen. Automatisierte Prüfungen auf veröffentlichte CVEs helfen dabei, veraltete oder riskante Komponenten schnell zu identifizieren.

Entwicklungsumgebungen sollten keinen direkten Produktionszugriff haben. Dieser Zugriff sollte eingeschränkt werden. Ändern Sie außerdem regelmäßig geheime Schlüssel und Zertifikate, und führen Sie sicherheitsorientierte Übungen wie Tabletop-Simulationen und Red-Teaming durch, um die Verteidigungen zu validieren.

Schützen von Code von der Entwicklung bis zur Stilllegung

Der Schutz von Code ist eine fortlaufende Verantwortung. Der SDLC ist iterativ, und die Anforderungen werden weiterentwickelt, sodass Praktiken aus früheren Phasen weiterhin angewendet und im Laufe der Zeit verstärkt werden müssen.

Halten Sie alle Software-, Bibliotheken- und Infrastrukturkomponenten mit rechtzeitigen Sicherheitspatches auf dem neuesten Stand. Bewerten und verbessern Sie Ihre Prozesse kontinuierlich, indem Sie Lektionen aus Codeüberprüfungen, Feedback, Vorfalluntersuchungen und neuen Bedrohungen integrieren. Integrieren Sie umgehend Korrekturen von Produktionsproblemen wieder in den Entwicklungslebenszyklus, um Wiederholungen zu verhindern.

Außerbetriebnahme von Legacyressourcen, die nicht mehr verwendet werden, um die Angriffsfläche zu reduzieren und die Wartung zu vereinfachen. Verfeinern Sie regelmäßig sichere Codierungsmethoden, um bei sich entwickelnden Bedrohungen voraus zu sein und sicherzustellen, dass Ihre Sicherheitslage während des gesamten Lebenszyklus stark und widerstandsfähig bleibt.

Azure-Unterstützung

Microsoft Security Development Lifecycle (SDL) empfiehlt sichere Methoden, die Sie auf Ihren Entwicklungslebenszyklus anwenden können. Weitere Informationen finden Sie unter Microsoft Security Development Lifecycle.

Defender für DevOps und die SAST-Tools sind bestandteil von GitHub Advanced Security oder Azure DevOps. Diese Tools können Ihnen helfen, eine Sicherheitsbewertung für Ihre Organisation nachzuverfolgen.

Folgen Sie den Azure-Sicherheitsempfehlungen, die in diesen Ressourcen beschrieben werden:

Um Anmeldeinformationen im Quellcode zu finden, sollten Sie Tools wie GitHub Advanced Security und OWASP-Quellcodeanalysetools verwenden.

Überprüfen Sie die Sicherheit von Open-Source-Code in Ihrer Anwendung. Diese kostenlosen Tools und Ressourcen können Ihnen bei Ihrer Bewertung helfen:

Sicherheitsprüfliste

Lesen Sie die vollständigen Empfehlungen.

Sicherheitsprüfliste

  • Last updated on