Architekturstrategien für Sicherheitstests

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

Strenge Tests sind die Grundlage eines guten Sicherheitsdesigns. Tests sind auch eine proaktive Möglichkeit, Sicherheitsrisiken im System zu erkennen.

Etablieren Sie Teststrenge durch systematische Abläufe und Überprüfung aus verschiedenen Perspektiven. Berücksichtigen Sie Perspektiven von innen nach außen, die Plattform und Infrastruktur prüfen, sowie Bewertungen von außen nach innen, die das System wie ein externer Angreifer testen.

Die wichtigsten Strategien in diesem Artikel basieren auf den grundlegenden Testpraktiken, die in OE:09 Architekturstrategien für Tests beschrieben werden. Überprüfen Sie zuerst diesen Artikel. Dieses Handbuch enthält Empfehlungen zum Testen des Sicherheitsstatus Ihrer Workload. Implementieren Sie diese Testmethoden, um den Widerstand Ihrer Workload gegen Angriffe zu verbessern und Vertraulichkeit, Integrität und Verfügbarkeit von Ressourcen aufrechtzuerhalten.

Terminologie

Zusammenarbeit mit Sicherheitsexperten zum Entwerfen von Tests

Beteiligen Sie sich an der Testplanung. Häufig wird diese Aufgabe von einer Organisation zentralisiert. Stellen Sie sicher, dass Ihr Team an diesem Entwurfsprozess beteiligt ist, damit die Sicherheitsvorkehrungen den Funktionen der Anwendung entsprechen.

Entwickeln Sie eine Denkweise, die einen Angriff annimmt. Entwerfen Sie Ihre Testfälle mit der Annahme, dass das System angegriffen wird und der Angreifer innerhalb der Umgebung arbeitet. Simulieren Sie Ihre Tests, um realistische Angriffsszenarien widerzuspiegeln, z. B. die Überprüfung der lateralen Bewegungseindämmung innerhalb einer kompromittierten Anwendungs-VM. Auf diese Weise können Sie potenzielle Sicherheitsrisiken aufdecken und die Tests entsprechend priorisieren.

Teilen Sie die Architekturdiagramme, das Bedrohungsmodell und andere relevante Dokumentationen, um die Arbeitsauslastung sinnvoll zu testen.

Priorisieren von Tests basierend auf der Bedrohungsmodellierung und kritischen Flüssen

Die Bedrohungsmodellierung ist eine wichtige Methode, um potenzielle Bedrohungen und Sicherheitsrisiken in Ihrer Workload zu identifizieren. Verwenden Sie die Schweregradbewertungen Ihres Bedrohungsmodells, um Ihre Testbemühungen zu priorisieren und zu beschränken. Die höchsten Schweregradebedrohungen gegen Ihre kritischsten Flüsse verdienen die größte Abdeckung.

Decken Sie die gesamte Angriffsfläche des Workloads ab. Bewerten Sie Identitäten, Anwendungscode, Infrastrukturkontrollen, Drittanbieterkomponenten, Bibliotheken und Dienste sowie automatisierte und menschliche Prozesse wie Genehmigungsworkflows und Zugriffsprüfungen.

Beginnen Sie mit Identitäts- und Zugriffssteuerungen, da eine kompromittierte Identität die meisten nachgeschalteten Abwehrmaßnahmen umgeht. Überprüfen Sie dann Netzwerkgrenzen und schließlich die Verteidigung auf Anwendungsebene.

Priorisieren Sie Flüsse, die Authentifizierung, vertrauliche Daten oder Finanztransaktionen behandeln. Identifizieren Sie für jeden kritischen Fluss die Bedrohungen mit der höchsten Bewertung des Schweregrads in Ihrem Bedrohungsmodell. Erstellen Sie risikogesteuerte Testfälle, die die einzelnen Bedrohungen dem Steuerelement zuordnen, mit dem sie abgemildert werden sollen.

Eine gute Übung zur Bedrohungsmodellierung verweist auf wichtige Bereiche für die Testabdeckung und -häufigkeit. Empfehlungen zur Bedrohungsmodellierung finden Sie unter Empfehlungen zum Sichern eines Entwicklungslebenszyklus.

Risiko: Veraltete Bedrohungsmodelle können zu falsch ausgerichteten Testbemühungen führen. Aktualisieren Sie Ihr Bedrohungsmodell regelmäßig, um Änderungen der Workload und der sich entwickelnden Bedrohungslandschaft widerzuspiegeln.

Nutzen von Drittanbieter-Know-how

Interne Teams können blinde Flecken haben. Externe Experten und Crowdsourcing-Forscher sehen Ihre Arbeitslast so, wie es ein Angreifer tut. Bringen Sie spezialisierte Experten ein, um Ihre Arbeitsauslastung aus sicht eines Gegners zu testen und Einblicke in die neuesten Angriffstechniken und Trends zu bieten.

Vermeiden Sie es, Ihrem Workload zu weitreichende Zugriffsrechte zu gewähren. Gewähren Sie externen Testern nur den Zugriff, den ihr spezifisches Engagement erfordert. Ein Blackbox-Penetrationstest benötigt keinen Code oder internen Zugriff, während eine Whitebox-Überprüfung Quellcode, Entwurfsdokumente oder Protokolle benötigt.

Bewerten Sie, ob Ihr Team die Fähigkeit hat, externe Berichte zu triagen, bevor Sie ein Programm starten. Richten Sie dann ein Programm für Bug-Bounty oder einen Mechanismus für die Community ein, um Sicherheitsprobleme zu melden. Prüfen Sie jeden gemeldeten Befund, führen Sie bestätigte Schwachstellen in Ihr Bedrohungsmodell zurück und fügen Sie einen Testfall hinzu, um jede Regression zu erkennen.

Testen von Compliance-Kontrollen und Generieren von prüfbereiten Nachweisen

Compliance ist keine einmalige Überprüfung. Behandeln Sie jede regulatorische Kontrolle als prüfbare Anforderung, damit Sie immer neue Nachweise für Prüfer haben.

Identifizieren Sie die Vorschriften, die Ihre Arbeitsauslastung erfüllen muss. Ordnen Sie jedes regulatorische Steuerelement einem bestimmten Testfall zu. Planen Sie die Tests so, dass sie in regelmäßigen Abständen und vor jedem Go-Live ausgeführt werden. Speichern Sie die Testausgabe an einem auditierbaren Speicherort, damit Sie Nachweise bei Bedarf erstellen können.

Kompromiss: Tests für regulatorische Kontrollen können Vorgänge verlangsamen. Zum Beispiel erhöhen Tests vor der Bereitstellung die Latenz der Pipeline. Es gibt auch zusätzliche Kosten für die Ausführung dieser Vorgänge. Priorisieren Sie Tests für Steuerelemente mit der höchsten Überwachungs- und Risikowirkung.

Risiko: Audit-Nachweise sind selbst vertraulich. Ohne Integritätsschutz und Zugriffsprotokollierung wird der Beweisspeicher sowohl zu einem Angriffsziel als auch zu einer potenziellen Complianceverletzung.

Schützen von Testressourcen

Testressourcen sind selbst eine Angriffsfläche. Schützen Sie ihre Vertraulichkeit, Integrität und Verfügbarkeit, damit Ihre Tests keine vertraulichen Informationen offenlegen oder neue Angriffsvektoren öffnen.

• Verwenden Sie sanitisierte oder synthetische Daten, die keine personenbezogenen Informationen (PII) oder Produktionsdaten enthalten.
• Speichern Sie Testdaten nur so lange wie erforderlich, und löschen Sie sie sicher.
• Vergewissern Sie sich, dass grenzüberschreitende Datenhaltungsregeln in Testumgebungen erzwungen werden, die Regionen umfassen.
• Generieren Sie dedizierte Testanmeldeinformationen, API-Schlüssel und Zertifikate. Speichern Sie sie in einer separaten Schlüsseltresorinstanz mit eigenen Zugriffsrichtlinien.
• Richten Sie isolierte Testumgebungen ein, die Produktionssicherheitskontrollen wie Netzwerksicherheitsgruppen (NSGs), rollenbasierte Zugriffssteuerungsrichtlinien, Firewall- und DLP-Regeln (Data Loss Prevention, Verhinderung von Datenverlust) spiegeln. Wenden Sie dieselbe Segmentierungsanleitung wie die Produktion an. Weitere Informationen finden Sie unter Empfehlungen für die Segmentierungsstrategie.

Führen Sie regelmäßige Schwachstellen-Scans auf Testsystemen durch.

Überprüfen Sie Testressourcen auf Sicherheitsrisiken in demselben Rhythmus wie Produktionsressourcen, einschließlich Testcode, Infrastruktur als Code (IaC), Container- und VM-Images, Repositorys und Pipelines. Verwenden Sie Tools, die in Ihre Entwicklungs- und Bereitstellungsworkflows integriert sind, um diese Prüfungen zu automatisieren.

Einrichten eines kontinuierlichen Testrhythmus für die Arbeitsauslastung

Behandeln Sie Sicherheitstests als kontinuierliche Aktivität, die den Sicherheitsstatus der Workload aktuell hält, während Bedrohungen, Code und Konfigurationen weiterentwickelt werden. Führen Sie Tests nach einem Zeitplan aus, sodass Änderungen keine Sicherheitsrisiken oder Regressionen verursachen. Seien Sie bereit für sicherheitsrelevante Überprüfungen der Organisation, die jederzeit auftreten können, und für Tests, die durch einen Sicherheitsvorfall ausgelöst werden. In den folgenden Abschnitten werden die Rhythmen beschrieben, die bei der Planung zu berücksichtigen sind.

Routinetests

Routinetests legen den Basisplan für den Sicherheitsstatus Ihrer Workload fest. Führen Sie sie in regelmäßigen Abständen im Rahmen Ihrer Standardbetriebsverfahren und zur Einhaltung der Complianceanforderungen durch. Sie können verschiedene Tests in unterschiedlichen Abständen ausführen, aber der Schlüssel besteht darin, dass Sie sie regelmäßig und nach einem Zeitplan durchführen.

Diversifizieren Sie die Testsuite, um die Sicherheiten für Identität, Datenspeicherung und Übertragung sowie Kommunikationskanäle zu überprüfen. Wenn Sie neue Probleme an den gleichen Punkten des Lebenszyklus entdecken, fügen Sie neue Testfälle hinzu.

Verlassen Sie sich nicht nur auf automatisierte Tests. Verwenden Sie manuelle Tests, um Schwachstellen zu finden, die nur menschliches Fachwissen erfassen können, und für explorative Arbeiten an unbekannten Risiken.

Improvisierte Tests

Improvisierte Tests bieten eine zeitpunktbezogene Validierung der Sicherheitsmaßnahmen. Sicherheitswarnungen, die sich auf die Workload zu diesem Zeitpunkt auswirken, lösen diese Tests aus. Organisationsmandats erfordern möglicherweise eine Pausen- und Test-Denkweise, um die Wirksamkeit von Verteidigungsstrategien zu überprüfen, wenn die Warnung zu einem Notfall eskaliert.

Der Vorteil von improvisierten Tests ist die Vorbereitung auf einen echten Vorfall. Diese Tests können eine Erzwingungsfunktion sein, um Benutzerakzeptanztests (User Acceptance Testing, UAT) durchzuführen.

Das Sicherheitsteam überwacht möglicherweise alle Workloads und führt diese Tests nach Bedarf aus. Als Workloadbesitzer müssen Sie die Zusammenarbeit mit Sicherheitsteams erleichtern und kooperieren. Verhandeln Sie genügend Vorlaufzeit mit Sicherheitsteams, damit Sie sich vorbereiten können. Bestätigen und kommunizieren Sie Ihrem Team und den Projektbeteiligten, dass diese Unterbrechungen erforderlich sind.

In anderen Fällen müssen Sie möglicherweise Tests ausführen und den Sicherheitsstatus des Systems gegen die potenzielle Bedrohung melden.

Abwägung: Da spontane Tests Unterbrechungen verursachen, müssen Sie damit rechnen, Aufgaben neu zu priorisieren, was andere geplante Arbeiten verzögern kann.

Risiko: Es besteht das Risiko des Unbekannten. Improvisierte Tests können einmalige Anstrengungen ohne etablierte Prozesse oder Werkzeuge sein. Aber das vorherrschende Risiko ist die potenzielle Unterbrechung des Rhythmus des Geschäfts. Bewerten Sie diese Risiken im Verhältnis zu den Vorteilen.

Sicherheitsvorfalltests

Verwenden Sie Tests, die die Ursache eines Sicherheitsvorfalls an seiner Quelle erkennen. Beheben Sie diese Sicherheitslücken, um zu verhindern, dass der Vorfall wiederholt wird.

Vorfälle verbessern auch Testfälle im Laufe der Zeit, indem vorhandene Lücken aufgedeckt werden. Das Team sollte die Erkenntnisse aus dem Vorfall anwenden und routinemäßig Verbesserungen integrieren.

Überprüfen von Sicherheitskontrollen auf der gesamten Angriffsfläche

Verwenden Sie eine Vielzahl von Testmethoden, um vollständige Abdeckung zu erhalten und Lücken bei Sicherheitskontrollen, Fehlkonfigurationen und Schwachstellen bei der Beobachtung und Erkennung aufzudecken. Die meisten in diesem Abschnitt beschriebenen Tests können als Routinetests ausgeführt werden. Die Wiederholbarkeit kann jedoch Kosten verursachen und Störungen verursachen. Berücksichtigen Sie diese Kompromisse sorgfältig.

Testen Sie Verschlüsselungssteuerelemente. Verschlüsselungsfehler bleiben unbemerkt. Daten werden geschützt, bis eine Verletzung andernfalls offengelegt wird.

• Überprüfen Sie, ob die Verschlüsselung erzwungen wird, nicht nur konfiguriert.
• Testen Sie nach jeder Schlüsselrotation, Zertifikaterneuerung und Infrastrukturänderung erneut.

Testen Sie Netzwerksteuerelemente. Netzwerkgrenzen sind der Ort, an dem Ihre Segmentierung erzwungen wird.

• Testen Sie sie nach einer Änderung der Netzwerktopologie.
• Vergewissern Sie sich, dass Default-Deny-Regeln gelten und dass zulässige Datenverkehrspfade mit den Vorgaben Ihrer Architektur übereinstimmen.

Testanwendungscode. Die Verteidigung auf Anwendungsebene ist die letzte Grenze, bevor ein Angreifer Daten erreicht.

• Überprüfen Sie, ob bereitgestellte Anwendungen gängigen Angriffsmustern standhalten, statt den Quellcode nur während des Builds zu scannen.
• Führen Sie Methoden für Anwendungssicherheitstests (APPLICATION Security Testing, AST) im Quellcode aus, um sichere Codierungsmethoden zu bestätigen und Laufzeitfehler wie Speicherbeschädigungen und Berechtigungsprobleme abzufangen. Ausführliche Informationen finden Sie unter Communitylinks.

Simulieren von identitätsbasierten Angriffen und Überprüfen der Erkennung

Identitätsbasierte Angriffe sind der am häufigsten verwendete Angriffsvektor. Simulieren Sie diese Angriffe, um zu überprüfen, ob Ihre Identitätskontrollen funktionieren und ob Ihre Überwachung die Ereignisse erfasst.

Zugriffssteuerungen sind die erste Verteidigungslinie. Testen Sie sie nach jeder Rollen- oder Richtlinienänderung und in einem automatisierten Zeitplan. Simulieren Sie häufige Angriffsmuster, und stellen Sie sicher, dass Ihre Steuerelemente die geringsten Berechtigungen erzwingen und Umgehungsversuche widerstehen.

Berücksichtigen Sie diese Angriffsmuster beim Entwerfen von Tests:

• Umgehung der Autorisierung
• Tokendiebstahl und Wiedergabe
• Laterale Bewegung über Konten oder Dienste hinweg
• Berechtigungseskalation

Überprüfen Sie beide Seiten jedes Steuerelements:

• Positive Fälle: Autorisierte Benutzer sind erfolgreich.
• Negative Fälle: Nicht autorisierte Versuche werden blockiert und protokolliert.

Testen der Bedrohungserkennung und Warnung

Die Erkennung, die keine Warnung auslöst, bietet wenig Wert. Testen Sie Ihre Überwachung und Warnung im Rahmen jeder Überprüfung der Sicherheitssteuerung, und überprüfen Sie, ob die Mechanismen zum Erkennen von Angriffen erwartungsgemäß funktionieren.

Führen Sie End-to-End-Simulationen der Angriffe aus, und bestätigen Sie dann jede Phase der Erkennungspipeline:

• Überprüfen Sie, ob Sicherheitsereignisse wie Anmeldeversuche, Berechtigungsänderungen und Tokenvorgänge mit ausreichend Details protokolliert werden.
• Stellen Sie sicher, dass Ihre Sicherheitsinformations- und Ereignisverwaltungsplattform (SIEM) oder das Dashboard für Sicherheitsvorgänge verwandte Ereignisse korreliert.
• Richten Sie eine Vereinbarung auf Dienstebene (Service Level Agreement, SLA) für Warnungen ein, und testen Sie, dass Warnungen innerhalb dieses Zeitraums umsetzbar und verfügbar sind.
• Stellen Sie sicher, dass Protokolle nicht von nicht administrativen Konten manipuliert oder gelöscht werden können.
• Vergewissern Sie sich, dass der Erkennungsmechanismus bei jedem simulierten Angriff anspricht. Wenn Sie z. B. einen verteilten Denial-of-Service-Angriff (DDoS) mit gültigen Datenverkehrsmustern simulieren, bestätigen Sie, dass die Häufigkeitsbegrenzung erkennt und verringert.

Validieren Sie bei ausgereiften Workloads die Governance-Leitplanken im Rahmen von Routinetests. Stellen Sie absichtlich unsichere Konfigurationen vor, und stellen Sie sicher, dass die Pipeline erkennt und reagiert. Vergewissern Sie sich, dass Azure Policy- oder Landungszoneneinschränkungen die erwarteten Schutzmaßnahmen erzwingen. Das Plattform- oder Sicherheitsteam führt in der Regel diese Tests aus, nicht das Workloadteam.

Stärkung der Abwehrmaßnahmen mit gegnerbasierten Tests

Verwenden Sie Tests, die die Bedrohungssuche ermöglichen, indem Sie Realangriffe simulieren. Diese Tests können potenzielle Bedrohungsakteure, ihre Techniken und ihre Exploits identifizieren, die eine Bedrohung für die Arbeitsauslastung darstellen. Machen Sie die Angriffe so realistisch wie möglich. Verwenden Sie alle potenziellen Bedrohungsvektoren, die Sie während der Bedrohungsmodellierung identifizieren.

Hier sind einige Vorteile des Testens durch reale Angriffe:

• Wenn Sie diese Angriffe zu einem Teil von Routinetests machen, verwenden Sie eine außenstehende Perspektive, um die Workload zu überprüfen und sicherzustellen, dass die Verteidigung einem Angriff standhalten kann.
• Basierend auf den Lektionen, die sie lernen, aktualisiert das Team sein Wissen und Qualifikationsniveau. Das Team verbessert das Situationsbewusstsein und kann seine Bereitschaft zur Reaktion auf Vorfälle selbst bewerten.

Risiko: Das Testen im Allgemeinen kann sich auf die Leistung auswirken. Destruktive Tests können Daten löschen oder beschädigen und Geschäftskontinuitätsprobleme verursachen. Es gibt auch Risiken, die mit der Exposition von Informationen verbunden sind. Behalten Sie die Vertraulichkeit der Daten bei. Stellen Sie die Integrität der Daten nach Abschluss des Tests sicher.

Einige Beispiele für simulierte Tests sind Blackbox- und Whitebox-Tests, Penetrationstests und Kriegsspielübungen.

Blackbox- und Whitebox-Tests

Diese Testtypen bieten zwei verschiedene Perspektiven. Bei Black-Box-Tests bleiben die internen Funktionen des Systems nicht sichtbar. Bei Whitebox-Tests verfügt der Tester über ein gutes Verständnis der Anwendung und hat sogar Zugriff auf Code, Protokolle, Ressourcentopologie und Konfigurationen für die Durchführung des Experiments.

Risiko: Der Unterschied zwischen den beiden Typen ist die Vorabkosten.Risk: The difference between the two types is upfront cost. White-Box-Tests können zeitaufwendig und kostspielig sein, wenn es darum geht, das System zu verstehen. In einigen Fällen erfordern White-Box-Tests den Kauf spezieller Tools. Black-Box-Tests benötigen keine Anlaufzeit, aber sie sind möglicherweise nicht so effektiv. Möglicherweise müssen Sie zusätzliche Anstrengungen unternehmen, um Probleme aufzudecken. Es ist eine Zeitinvestment-Abwägung.

Tests, die Angriffe durch Penetrationstests simulieren

Sicherheitsexperten, die nicht Teil der IT- oder Anwendungsteams der Organisation sind, führen Penetrationstests oder Pentesting durch. Sie betrachten das System so, wie böswillige Akteure eine Angriffsfläche festlegen. Ihr Ziel ist es, Sicherheitslücken zu finden, indem Informationen gesammelt, Sicherheitsrisiken analysiert und die Ergebnisse gemeldet werden.

Kompromiss: Penetrationstests sind improvisiert und können in Bezug auf Störungen und Geldinvestitionen teuer sein, da Penetrationstests in der Regel ein kostenpflichtiges Angebot von Drittanbietern sind.

Risiko: Ein Penetrationstest kann sich auf die Laufzeitumgebung auswirken und die Verfügbarkeit für den normalen Datenverkehr stören.

Die Praktiker benötigen möglicherweise Zugriff auf vertrauliche Daten in der gesamten Organisation. Befolgen Sie die Einsatzregeln, um sicherzustellen, dass der Zugriff nicht missbraucht wird. Weitere Informationen finden Sie in den ressourcenbezogenen Links.

Tests, die Angriffe durch Kriegsspielübungen simulieren

In dieser Methodik simulierter Angriffe nehmen zwei Teams teil:

• Das rote Team fungiert als Gegner und versucht, reale Angriffe zu modellieren. Falls sie erfolgreich sind, identifizieren Sie Lücken in Ihrem Sicherheitsdesign und bewerten den Schadensradius ihrer Sicherheitsverletzungen.

• Das blaue Team ist das Workload-Team, das sich gegen die Angriffe wehrt. Sie testen ihre Fähigkeit, die Angriffe zu erkennen, zu reagieren und zu beheben. Sie überprüfen die Abwehrmaßnahmen, die Arbeitsauslastungsressourcen schützen.

Wenn Sie diese Tests routinemäßig durchführen, können Kriegsspielübungen fortlaufende Sichtbarkeit und Sicherheit bieten, dass Ihre Verteidigung wie vorgesehen funktioniert. Simulationsübungen können potenziell mehrere Ebenen innerhalb Ihrer Workloads testen.

Eine beliebte Wahl zum Simulieren realistischer Angriffsszenarien ist das Microsoft Defender für Office 365 Attack Simulation Training.

Weitere Informationen finden Sie unter Insights und Berichte zur Angriffssimulationsschulung.

Informationen zum Einrichten von red-team und blue-team finden Sie unter Microsoft Cloud Red Teaming.

Azure-Unterstützung

Microsoft Sentinel ist eine native Lösung, die Security Information & Event Management (SIEM) und Security Orchestration Automated Response (SOAR) kombiniert. Es analysiert Ereignisse und Protokolle aus verschiedenen verbundenen Quellen. Basierend auf Datenquellen und deren Warnungen erstellt Microsoft Sentinel Vorfälle und führt Bedrohungsanalysen für die früherkennung aus. Durch intelligente Analysen und Abfragen können Sie proaktiv nach Sicherheitsproblemen suchen. Wenn ein Vorfall vorhanden ist, können Sie Workflows automatisieren. Außerdem können Sie mithilfe von Arbeitsmappenvorlagen schnell Einblicke durch Visualisierung gewinnen.

Produktdokumentation finden Sie unter "Suchfunktionen" in Microsoft Sentinel.

Microsoft Defender für Cloud bietet Sicherheitsrisikoüberprüfungen für verschiedene Technologiebereiche. Ausführliche Informationen finden Sie unter Aktivieren der Sicherheitsrisikoüberprüfung mit Microsoft Defender Vulnerability Management – Microsoft Defender für Cloud.

Die Praxisansatz von DevSecOps integriert Sicherheitstests als Teil eines kontinuierlichen Verbesserungsansatzes. Kriegsspielübungen sind eine gängige Praxis, die in den Rhythmus des Geschäfts bei Microsoft integriert ist. Weitere Informationen finden Sie unter "Sicherheit in DevOps (DevSecOps)".

Azure DevOps unterstützt Tools von Drittanbietern, die Sie als Teil der Pipelines für kontinuierliche Integration/kontinuierliche Bereitstellung automatisieren können. Ausführliche Informationen finden Sie unter Aktivieren von DevSecOps mit Azure und GitHub – Azure DevOps.

Verwandte Links

Befolgen Sie die Zugriffsrichtlinien, um sicherzustellen, dass der Zugriff nicht missbraucht wird. Anleitungen zum Planen und Ausführen simulierter Angriffe finden Sie in den folgenden Artikeln:

• Einsatzregeln für Penetrationstests

• Penetrationstests

Sie können Denial-of-Service-Angriffe (DoS) in Azure simulieren. Achten Sie darauf, die in Azure DDoS Protection-Simulationstests festgelegten Richtlinien zu befolgen.

Communitylinks

Anwendungssicherheitstests: Tools, Typen und bewährte Methoden – GitHub Resources beschreibt die Arten von Testmethoden, die die Buildzeit- und Laufzeitabwehr der Anwendung testen können.

Penetration Testing Execution Standard (PTES) enthält Richtlinien zu allgemeinen Szenarien und den Aktivitäten, die zum Einrichten eines Basisplans erforderlich sind.

OWASP Top Ten | OWASP Foundation bietet bewährte Methoden für Sicherheit für Anwendungen und Testfälle, die häufige Bedrohungen abdecken.

Sicherheitsprüfliste

Lesen Sie die vollständigen Empfehlungen.