Anwendungen und Dienste

Anwendungen und die damit verbundenen Daten dienen letztendlich als primärer Speicher von Geschäftswert auf einer Cloudplattform. Während die Plattformkomponenten wie Identität und Speicher wichtige Elemente der Sicherheitsumgebung sind, spielen Anwendungen eine überdurchschnittliche Rolle bei Risiken für das Unternehmen, da:

  • Geschäftsprozesse sind gekapselt und werden von Anwendungen ausgeführt, und Dienste müssen verfügbar sein und mit hoher Integrität bereitgestellt werden.

  • Geschäftsdaten werden von Anwendungsworkloads gespeichert und verarbeitet und erfordern hohe Vertraulichkeits-, Integritäts- und Verfügbarkeitssicherheit.

Dieser Abschnitt konzentriert sich auf Anwendungen, die von Ihrer Organisation oder von anderen im Auftrag Ihrer Organisation im Vergleich zu SaaS oder kommerziell verfügbaren Anwendungen geschrieben wurden, die auf IaaS-VMs installiert sind.

Diagram of Application Models

Moderne Cloudplattformen wie Azure können sowohl ältere als auch moderne Generationen von Anwendungen hosten

  • Legacyanwendungen werden auf virtuellen IaaS-Computern (Infrastructure as a Service) gehostet, die in der Regel alle Abhängigkeiten einschließlich Betriebssystem, Middleware und anderen Komponenten enthalten.

  • Modernen PaaS-Anwendungen (Platform as a Service) erfordern nicht, dass der Anwendungsbesitzer die zugrunde liegenden Serverbetriebssysteme (OSes) verwaltet und sicher ist und manchmal vollständig "serverlos" ist und hauptsächlich mithilfe von Funktionen als Dienst erstellt wird.

    Notizen: Beliebte Formen moderner Anwendungen sind Anwendungscode, der auf Azure-App Services und containerisierten Anwendungen gehostet wird (Container können jedoch auch auf IaaS-VMs oder lokal gehostet werden).

  • Hybrid – Hybridanwendungen können zwar viele Formen annehmen, aber am häufigsten ist ein "IaaS plus"-Zustand, in dem Legacyanwendungen zu einer modernen Architektur überwechseln und moderne Dienste legacykomponenten ersetzen oder eine Legacyanwendung hinzugefügt werden.

Das Sichern einer Anwendung erfordert Sicherheitsüberprüfungen für drei verschiedene Komponententypen:

  • Anwendungscode – Dies ist die Logik, die die benutzerdefinierte Anwendung definiert, die Sie schreiben. Die Sicherheit dieses Codes liegt in der Verantwortung der Anwendungsbesitzer in allen Generationen der Anwendungsarchitektur, einschließlich aller Open Source-Codeausschnitte oder -Komponenten, die im Code enthalten sind. Die Sicherung des Codes erfordert die Identifizierung und Minderung von Risiken aus dem Entwurf und der Implementierung der Anwendung sowie die Bewertung des Lieferkettenrisikos enthaltener Komponenten. Beachten Sie, dass die Weiterentwicklung von Anwendungen in Microservices-Architekturen verschiedene Aspekte von Anwendungscode in kleinere Dienste und eine einzelne monolithische Codebasis unterbricht.

  • Anwendungsdienste – Dies sind die verschiedenen standardisierten Komponenten, die die Anwendung verwendet, z. B. Datenbanken, Identitätsanbieter, Event Hubs, IoT-Geräteverwaltung usw. Für Clouddienste ist dies eine gemeinsame Verantwortung:

    • Cloudanbieter – Die Sicherheit des zugrunde liegenden Diensts liegt in der Verantwortung des Cloudanbieters.

    • Anwendungsbesitzer – Der Anwendungsbesitzer ist für sicherheitsrelevante Auswirkungen der Konfiguration und des Betriebs der dienstinstanz(en) verantwortlich, die von der Anwendung verwendet werden, einschließlich aller im Dienst gespeicherten und verarbeiteten Daten.

  • Application Hosting Platform – Dies ist die Computerumgebung, in der die Anwendung tatsächlich ausgeführt und ausgeführt wird. In einem Unternehmen mit lokal gehosteten Anwendungen, in Azure und in Drittanbieterclouds wie Amazon Web Services (AWS) kann dies viele Formen annehmen, mit erheblichen Unterschieden darüber, wer für die Sicherheit verantwortlich ist:

    • Legacyanwendungen erfordern in der Regel ein vollständiges Betriebssystem (und jegliche Middleware), das auf physischer oder virtualisierter Hardware gehostet wird. Die virtuelle Hardware kann lokal oder auf IaaS-VMs (Infrastructure as a Service) gehostet werden. Dieses Betriebssystem und installierte Middleware/andere Komponenten werden vom Anwendungsbesitzer oder dessen Infrastrukturteam(en) betrieben und gesichert.
      Die Verantwortung für die physische Hardware und die Betriebssystemvirtualisierungskomponenten (Virtualisierungshosts, Betriebssysteme und Verwaltungsdienste) variiert:

      • Lokal – Der Anwendungsbesitzer oder seine Organisation ist für Wartung und Sicherheit verantwortlich.

      • IaaS – Der Cloudanbieter ist für die Wartung und Sicherheit der zugrunde liegenden Infrastruktur verantwortlich, und die Organisation des Anwendungsbesitzers ist für die VM-Konfiguration, das Betriebssystem und alle darauf installierten Komponenten verantwortlich.

    • Moderne Anwendungen werden in PaaS-Umgebungen (Platform as a Service) gehostet, z. B. in einem Azure-Anwendungsdienst. In den meisten Anwendungsdiensttypen wird das zugrunde liegende Betriebssystem vom Anwendungsbesitzer abstrahiert und durch den Cloudanbieter gesichert. Anwendungsbesitzer sind für die Sicherheit der Anwendungsdienstkonfigurationen verantwortlich, die ihnen bereitgestellt werden.

    • Container sind ein Anwendungspaketierungsmechanismus, bei dem Anwendungen aus der Umgebung abstrahiert werden, in der sie ausgeführt werden. Diese containerisierten Anwendungen passen entweder in die oben genannten älteren oder modernen Modelle, je nachdem, ob sie auf einem Containerdienst vom Cloudanbieter (Moderne Anwendungen) oder auf einem von der Organisation verwalteten Server (lokal oder in IaaS) ausgeführt werden. Weitere Informationen finden Sie unten im Abschnitt "Containersicherheit ".

Identifizieren und Klassifizieren geschäftskritischer Anwendungen

Stellen Sie sicher, dass Sie die Anwendungen in Ihrem Portfolio identifiziert und klassifiziert haben, die für Geschäftsfunktionen wichtig sind.

Enterprise Organisationen verfügen in der Regel über ein großes Anwendungsportfolio. Daher kann die Priorisierung, wo Zeit und Aufwand in manuelle und ressourcenintensive Aufgaben wie die Bedrohungsmodellierung investiert werden, die Effektivität Ihres Sicherheitsprogramms erhöhen.

Identifizieren Sie Anwendungen, die eine hohe potenzielle Auswirkung und/oder eine hohe potenzielle Gefährdung durch Risiken haben.

  • Hohe potenzielle Auswirkungen – Identifizieren Sie Anwendungen, die sich erheblich auf das Unternehmen auswirken würden, wenn sie kompromittiert würden. Dies kann in Form eines oder mehrerer der folgenden Aktionen erfolgen:

    • Unternehmenskritische Daten – Anwendungen, die Informationen verarbeiten oder speichern, was zu erheblichen negativen Auswirkungen auf das Geschäft oder die Mission führen würde, wenn eine Vertraulichkeits-, Integritäts- oder Verfügbarkeitsgewissheit verloren geht.

    • Regulierte Daten – Anwendungen, die Geldinstrumente und vertrauliche personenbezogene Informationen behandeln, die durch Standards geregelt sind. Beispiel: Payment Card Industry (PCI) und Health Information Portability and Accountability Act (HIPAA).

    • Unternehmenskritische Verfügbarkeit – Anwendungen, deren Funktionalität für Unternehmen von entscheidender Bedeutung ist, z. B. Produktionslinien, die Umsatz, Geräte oder Dienste generieren, die lebens- und sicherheitskritisch sind, und andere kritische Funktionen.

    • Erheblicher Zugriff – Anwendungen, die Zugang zu Systemen mit hoher potenzieller Auswirkung haben, z. B. durch technische Mittel wie

      • Gespeicherte Anmeldeinformationen oder Schlüssel/Zertifikate, die Zugriff auf die Daten/den Dienst gewähren

      • Berechtigungen , die über Zugriffssteuerungslisten oder andere Mittel gewährt werden

  • Hohe Angriffsexposition – Anwendungen, die für Angreifer leicht zugänglich sind, z. B. Webanwendungen im offenen Internet. Legacyanwendungen können auch eine höhere Gefährdung sein, da Angreifer und Penetrationstester häufig darauf abzielen, da sie wissen, dass diese Legacyanwendungen häufig Sicherheitslücken aufweisen, die schwer zu beheben sind.

Übernehmen des DevOps-Ansatzes

Organisationen sollten von einem "Wasserfall"-Entwicklungszyklus zu DevOps Lebenszyklus kontinuierlicher Integration, kontinuierlicher Bereitstellung (CI/CD) für Anwendungen so schnell wie möglich wechseln. DevOps ist die Vereinigung von Personen, Prozessen und Tools, die eine kontinuierliche Wertschöpfung für Endbenutzer ermöglichen. Die Zusammenziehung von Dev und Ops bezieht sich auf die Kombination der Entwicklungs- und Betriebsdisziplinen in multidisziplinären Teams, die mit gemeinsamen und effizienten Praktiken und Tools zusammenarbeiten.

Das DevOps-Modell erhöht die Fähigkeit der Organisation, Sicherheitsbedenken schnell anzugehen, ohne auf einen längeren Planungs- und Testzyklus eines Wasserfallmodells zu warten.

Befolgen DevOps Sicherheitsleitfaden

Organisationen sollten Anleitungen und Automatisierung zum Sichern von Anwendungen in der Cloud nutzen, anstatt von Null aus zu beginnen.

Die Verwendung von Ressourcen und Erkenntnissen, die von externen Organisationen gesammelt wurden, die early adopters dieser Modelle sind, kann die Verbesserung des Sicherheitsstatus einer Organisation mit weniger Aufwand und Ressourcen beschleunigen.

Verwenden von Clouddiensten anstelle von benutzerdefinierten Implementierungen

Entwickler sollten die von Ihrem Cloudanbieter verfügbaren Dienste für gut etablierte Funktionen wie Datenbanken, Verschlüsselung, Identitätsverzeichnis und Authentifizierung verwenden, anstatt benutzerdefinierte Versionen davon zu schreiben.

Diese Dienste bieten eine bessere Sicherheit, Zuverlässigkeit und Effizienz, da Cloudanbieter sie mit dedizierten Teams mit umfassender Expertise in diesen Bereichen betreiben und sichern. Die Nutzung dieser Dienste befreit Ihre Entwicklerressourcen auch davon, das sprichwörtliche Rad neu zu erfinden, damit sie sich auf Ihre individuellen Anforderungen für Ihr Unternehmen konzentrieren können. Diese Vorgehensweise sollte befolgt werden, um Risiken bei der Entwicklung neuer Anwendungen zu vermeiden und risiken in vorhandenen Anwendungen entweder während des geplanten Updatezyklus oder mit einem sicherheitsorientierten Anwendungsupdate zu reduzieren.

Mehrere Funktionen, die aufgrund potenzieller Sicherheitswirkungen zuerst priorisiert werden sollten:

  • Identität – Benutzerverzeichnisse und andere Authentifizierungsfunktionen sind komplex zu entwickeln und für Sicherheitsüberprüfungen von entscheidender Bedeutung. Vermeiden Sie die Verwendung von eigenen Authentifizierungslösungen, und bevorzugen Sie ausgereifte Funktionen wie Azure Active Directory (Azure AD), Azure AD B2B, Azure AD B2C oder Lösungen von Drittanbietern, um Benutzer, Partner, Kunden, Anwendungen, Dienste und andere Entitäten zu authentifizieren und berechtigungen zu erteilen.

  • Datenschutz – Entwickler sollten etablierte Funktionen von Cloudanbietern wie native Verschlüsselung in Clouddiensten verwenden, um Daten zu verschlüsseln und zu schützen. Die Sicherheitswelt ist übersät mit Beispielen für fehlgeschlagene Versuche, Daten oder Kennwörter zu schützen, die realen Angriffen nicht standhalten. Wenn eine direkte Verwendung der Kryptografie erforderlich ist, sollten Entwickler gut etablierte kryptografische Algorithmen aufrufen und nicht versuchen, ihre eigenen zu erfinden.

  • Schlüsselverwaltung – Verwenden Sie im Idealfall die Identität für die Authentifizierung, anstatt Schlüssel direkt zu behandeln (siehe "Identitätsauthentifizierung vor Schlüsseln bevorzugen"). Verwenden Sie in Situationen, in denen der Zugriff auf Dienste, die Zugriff auf Schlüssel erfordern, einen Schlüsselverwaltungsdienst wie Azure Key Vault oder AWS Schlüsselverwaltungsdienst, um diese Schlüssel zu verwalten und zu sichern, anstatt zu versuchen, Schlüssel im Anwendungscode sicher zu behandeln. Sie können CredScan verwenden, um potenziell verfügbar gemachte Schlüssel in Ihrem Anwendungscode zu ermitteln.

  • Anwendungskonfigurationen – Inkonsistente Konfigurationen für Anwendungen können Sicherheitsrisiken darstellen. Azure App Configuration bietet einen Dienst zum zentralen Verwalten von Anwendungseinstellungen und Featurekennzeichnungen, wodurch dieses Risiko verringert wird.

Verwenden nativer Sicherheitsfunktionen in Anwendungsdiensten

Verwenden Sie systemeigene Sicherheitsfunktionen, die in Clouddienste integriert sind, anstatt externe Sicherheitskomponenten hinzuzufügen (für Datenverschlüsselung, Netzwerkdatenverkehrsfilterung, Bedrohungserkennung und andere Funktionen).

Systemeigene Sicherheitskontrollen werden vom Dienstanbieter verwaltet und unterstützt, wodurch der Aufwand für die Integration externer Sicherheitstools und das Aktualisieren dieser Integrationen im Laufe der Zeit eliminiert oder reduziert wird. Clouddienste entwickeln sich schnell weiter, was die Belastung durch die Wartung eines externen Tools erheblich erhöht und das Risiko erhöht, dass die Sichtbarkeit und der Schutz vor diesen Tools verloren gehen, wenn das Tool nicht mit dem Clouddienst schritt hält.

Identitätsauthentifizierung vor Schlüsseln bevorzugen

Authentifizieren Sie sich immer mit Identitätsdiensten und nicht mit kryptografischen Schlüsseln, wenn diese verfügbar sind.

Die sichere Verwaltung von Schlüsseln mit Anwendungscode ist schwierig und führt regelmäßig zu Fehlern wie der versehentlichen Veröffentlichung vertraulicher Zugriffstasten in Code-Repositorys wie GitHub. Identitätssysteme bieten eine sichere und nutzbare Oberfläche für die Zugriffskontrolle mit integrierten komplexen Mechanismen für die Schlüsseldrehung, die Überwachung auf Anomalien und vieles mehr. Die meisten Organisationen verfügen auch über qualifizierte Teams, die sich der Verwaltung von Identitätssystemen widmen, und nur wenige (falls vorhanden) Personen, die wichtige Sicherheitssysteme aktiv verwalten.

Für Dienste, die die Azure AD-Authentifizierung anbieten, z. B. Azure Storage, Azure App Service, Azure Backup, verwenden Sie sie für die Authentifizierung und Autorisierung. Um die Verwendung von Identitäten für Entwickler weiter zu vereinfachen, können Sie auch verwaltete Identitäten nutzen, um Ressourcen wie VMs und App-Diensten Identitäten zuzuweisen, sodass Entwickler keine Identitäten innerhalb der Anwendung verwalten müssen.

Bottom-up-Ansatz zur Reduzierung des Sicherheitsfehlervolumens und der Auswirkungen

image showing bottom-up approach to reduce security bug volume and impact

Verringern Sie die Anzahl und den potenziellen Schweregrad von Sicherheitsfehlern in Ihrer Anwendung, indem Sie Während des Entwicklungslebenszyklus Sicherheitspraktiken und -tools implementieren.

Sicherheitsfehler können dazu führen, dass eine Anwendung vertrauliche Daten preisgibt, sodass Kriminelle Daten/Datensätze ändern können oder die Daten/Anwendung für Kunden und Mitarbeiter nicht mehr verfügbar sind. Anwendungen weisen immer einige Logikfehler auf, die zu Sicherheitsrisiken führen können. Daher ist es wichtig, sie zu ermitteln, zu bewerten und zu korrigieren, um Schäden am Ruf, dem Umsatz oder den Margen der Organisation zu vermeiden. Es ist einfacher und billiger, diese früher im Entwicklungslebenszyklus zu beheben, als sie zu korrigieren, nachdem die Anwendung die Tests abgeschlossen hat, in der Produktion verwendet wird oder häufig als "Linksschicht" oder "Push-Left"-Prinzip bezeichnet wurde.

Die Reduzierung des Anwendungsrisikos wird durch die Integration von Sicherheitspraktiken und Tools in den Entwicklungslebenszyklus erreicht, der häufig als sicherer Entwicklungslebenszyklus (SDL oder SDLC) bezeichnet wird. Microsoft hat eine Reihe von Empfehlungen in einem Whitepaper mit dem Titel "Entwickeln sicherer Apps in Azure basierend auf dem Sicherheitsentwicklungslebenszyklus von Microsoft" veröffentlicht, um häufige Risiken mit der Eingabe- und Ausgabeüberprüfung zu mindern, Fuzz-Tests durchzuführen, Überprüfungen der Angriffsfläche und vieles mehr.

Top-Down-Ansatz durch Bedrohungsmodellierung

image showing top-down approach through threat modeling

Führen Sie die Bedrohungsmodellierung für Ihre geschäftskritischen Anwendungen durch, um potenzielle Risiken für Ihre Organisation zu ermitteln und zu mindern.

Die Bedrohungsmodellierung identifiziert Risiken für die Anwendung selbst sowie Risiken, die die Anwendung für Ihr Unternehmen darstellen kann, insbesondere bei der Bewertung einzelner Anwendungen in einem größeren System.

Die Bedrohungsmodellierung kann in jeder Phase der Anwendungsentwicklung oder -produktion verwendet werden, ist aber für die Entwurfsphasen neuer Funktionen einzigartig effektiv, da für diese Anwendung noch keine realen Daten vorhanden sind.

Da die Bedrohungsmodellierung eine fähigkeitsintensive Übung ist, empfehlen wir, Maßnahmen zu ergreifen, um die Zeitinvestitionen zu minimieren und gleichzeitig den Sicherheitswert zu maximieren:

  1. Priorisieren nach Risiko – Wenden Sie zuerst die Bedrohungsmodellierung auf geschäftskritische Anwendungen an, die sich auf das Unternehmen auswirken würden, wenn sie kompromittiert würden.

  2. Bereich einschränken - Führen Sie die Bedrohungsmodellierung in progressiven Detailphasen durch, um schnelle Erfolge und umsetzbare Gegenmaßnahmen schnell zu identifizieren, bevor Sie viel manuellen Aufwand aufwenden:

    1. Beginnen Sie mit der einfachen Fragenmethode (siehe Methode für einfache Fragen), die unten dokumentiert ist, um schnell Einblicke in Risiken zu erhalten und ob grundlegende Schutzmaßnahmen vorhanden sind.

    2. Stufenweises Auswerten des Anwendungsentwurfs – wenn Ressourcen und Fachwissen verfügbar sind, wechseln Sie zu einer fortgeschritteneren Analyse mithilfe der STRIDE-Methode Advanced Threat Modeling-Techniken oder einer anderen ähnlichen, die bereits von Ihrem Team verwendet wird. Beginnen Sie mit dem Entwurf auf Architekturebene, und erhöhen Sie schrittweise die Details, sobald Zeit und Ressourcen Folgendes zulassen:

      1. Design auf Systemebene – umfasst Anwendungen und deren Interaktion miteinander

      2. Anwendungsebene – umfasst Komponenten der Anwendung und deren Interaktion miteinander

      3. Komponentenebene – umfasst, wie die einzelne Komponente zusammengesetzt wird und wie jedes Element miteinander interagiert.

  3. Am Entwicklungslebenszyklus ausrichten – Optimieren Sie Ihre Bemühungen, indem Sie Aktivitäten zur Bedrohungsmodellierung an Ihre Anwendungsentwicklungslebenszyklen anpassen.

    1. Wasserfall – Stellen Sie sicher, dass wichtige Projekte während des Entwurfsprozesses und bei wichtigen Aktualisierungen der Anwendung die Bedrohungsmodellierung umfassen sollten.

    2. DevOps – Auslösen von Bedrohungsmodellierungsaktivitäten mit einer Häufigkeit, die einen Sicherheitswert hinzufügt, ohne die Entwicklungsteams zu überlasten. Gute Integrationspunkte sind bei der Einführung erheblicher Features oder Änderungen an der Anwendung und einem regelmäßigen Terminplan für wiederkehrende Kalender, z. B. jedes Quartal für geschäftskritische Anwendungen.

    3. Legacyanwendungen – Diese Anwendungen verfügen in der Regel nicht über Unterstützung, Quellcodezugriff und/oder Know-how in der Organisation. Führen Sie daher die Bedrohungsmodellierung mit bestem Aufwand mit den verfügbaren Anwendungskenntnissen/ -kenntnissen durch.

Methode für einfache Fragen

Diese einfache Fragemethode wurde entwickelt, um Sicherheitsexperten und Entwicklern den Einstieg in die Bedrohungsmodellierung zu ermöglichen, bevor Sie mit einer fortgeschritteneren Methode wie STRIDE oder OWASP fortfahren (siehe Top-Down-Ansatz durch Bedrohungsmodellierung).

Stellen und beantworten Sie für jede Anwendung oder Komponente diese Fragen.

  • Authentifizieren Sie Verbindungen mithilfe von Azure AD, TLS (mit gegenseitiger Authentifizierung) oder einem anderen modernen Sicherheitsprotokoll, das von Ihrem Sicherheitsteam genehmigt wurde? Dies schützt vor unbefugtem Zugriff auf die Anwendung und Daten

    • Zwischen Benutzern und der Anwendung (falls zutreffend)

    • Zwischen verschiedenen Anwendungskomponenten und Diensten (falls zutreffend)

  • Beschränken Sie, welche Konten zugriffsberechtigt sind, um Daten in der Anwendung zu schreiben oder zu ändern, auf diejenigen, die dazu erforderlich sind? Dadurch wird das Risiko nicht autorisierter Datenmanipulation/-änderung reduziert.

  • Wird die Anwendungsaktivität über Azure Monitor oder eine ähnliche Lösung protokolliert und in eine SICHERHEITSINFORMATIONS- und Ereignisverwaltung (SECURITY INFORMATION and Event Management, SIEM) eingespeist? Dies hilft dem Sicherheitsteam, Angriffe zu erkennen und schnell zu untersuchen.

  • Sind geschäftskritische Daten durch Verschlüsselung geschützt, die vom Sicherheitsteam genehmigt wurde? Dies trägt zum Schutz vor unbefugtem Kopieren von Daten im Ruhezustand bei.

  • Wird eingehender und ausgehender Netzwerkdatenverkehr mitHILFE von TLS verschlüsselt? Dies schützt vor unbefugtem Kopieren von Daten während der Übertragung.

  • Ist die Anwendung vor DDoS-Angriffen (Distributed Denial of Service) mitHilfe von Diensten wie Azure DDoS-Schutz, Akamai oder ähnlichem geschützt? Dies schützt vor Angriffen, die die Anwendung überladen, sodass sie nicht verwendet werden kann

  • Speichert die Anwendung Anmeldeinformationen oder Schlüssel für den Zugriff auf andere Anwendungen, Datenbanken oder Dienste? Auf diese Weise kann ermittelt werden, ob ein Angriff Ihre Anwendung verwenden kann, um andere Systeme anzugreifen.

  • Ermöglichen Ihnen die Anwendungssteuerelemente die Erfüllung der Sicherheits- und Datenschutzanforderungen für die Gebietsschemas, in denen Sie arbeiten? (Dies trägt dazu bei, die privaten Daten des Benutzers zu schützen und Compliance-Geldbußen zu vermeiden)

Wichtig: Sicherheit ist ein komplexes Thema, und die potenziellen Risiken sind nur durch die Vorstellungskraft intelligenter motivierter Angreifer begrenzt. Diese Fragen sollen helfen, leicht auffindbare Lücken zu identifizieren, die von Angreifern leicht ausgenutzt werden können. Wenn Sie mit dieser Methode Komfort und Kompetenzen entwickeln, können Sie ihre Fähigkeit zum Bedrohungsmodell erweitern, indem Sie zu fortgeschrittenen Techniken der Bedrohungsmodellierung wechseln.

Erweiterte Bedrohungsmodellierungstechniken

Ein umfassenderes Bedrohungsmodell kann mehr potenzielle Risiken identifizieren, zwei beliebte Techniken sind STRIDE und OWASP

  • Microsoft Der Sicherheitsentwicklungslebenszyklus hat einen Prozess der Bedrohungsmodellierung dokumentiert und ein kostenloses Tool zur Unterstützung dieses Prozesses veröffentlicht.

    • Diese Methode wertet Anwendungskomponenten und Verbindungen/Beziehungen anhand potenzieller Risiken aus, die der STRIDE-Mnemonic zugeordnet sind:

      • Spoofing

      • Manipulationen

      • Ablehnung

      • Offenlegung von Informationen

      • Denial of Service

      • Rechteerweiterung

    • Diese Methode kann auf jede Ebene des Designs von den architekturspezifischen Anwendungskomponenten auf hoher Ebene angewendet werden.This method can be applied to any level of the design from the high level architectural specific application components.

  • OWASP – Die Open Web Application Security Project (OWASP) hat einen Ansatz zur Bedrohungsmodellierung für Anwendungen dokumentiert, der sich auf STRIDE und andere Methoden bezieht.https://www.owasp.org/index.php/Application_Threat_Modeling

Verwenden von Webanwendungsfirewalls

Webanwendungsfirewalls (WAFs) mindern das Risiko, dass ein Angreifer häufig gesehene Sicherheitslücken für Anwendungen ausnutzen kann. WaFs sind zwar nicht perfekt, bieten jedoch ein grundlegendes Mindestmaß an Sicherheit für Webanwendungen.

WAFs sind eine wichtige Entschärfung, da Angreifer Webanwendungen auf einen Einstiegspunkt in eine Organisation abzielen, die einem Clientendpunkt ähnelt. WAFs sind für beide geeignet

  • Organisationen ohne ein starkes Programm zur Anwendungssicherheit, da es eine kritische Sicherheitsmaßnahme ist (ähnlich wie ein Fallschirm in einem Flugzeug. Beachten Sie, dass dies nicht der einzige geplante Sicherheitsmechanismus sein sollte, um das Volumen und den Schweregrad von Sicherheitsfehlern in Ihren Anwendungen zu verringern. Ausführliche Informationen finden Sie unter Verringern des Sicherheitsfehlervolumens und der Auswirkungen.

  • Organisationen, die als WAFs in Anwendungssicherheit investiert haben, bieten einen wertvollen zusätzlichen Schutz und eine tiefgreifende Entschärfung. WAFs fungieren in diesem Fall als endgültiger Sicherheitsmechanismus für den Fall, dass ein Sicherheitsfehler durch Sicherheitspraktiken im Entwicklungslebenszyklus übersehen wurde.

Microsoft umfasst WAF-Funktionen in Azure Application Gateway und viele Anbieter bieten diese Funktionen als eigenständige Sicherheitsgeräte oder als Teil von Firewalls der nächsten Generation an.

Befolgen Sie bewährte Methoden für die Containersicherheit

Anwendungen, die in Containern gehostet werden, sollten allgemeine bewährte Methoden für Anwendungen sowie einige spezifische Richtlinien zum Verwalten dieses neuen Anwendungsarchitekturtyps befolgen.

Containerisierte Anwendungen stehen den gleichen Risiken wie jede Anwendung gegenüber und fügen neue Anforderungen an das sichere Hosting und die Verwaltung der containerisierten Anwendungen hinzu.

Anwendungscontainerarchitekturen haben eine neue Ebene von Abstraktions- und Verwaltungstools (in der Regel Kubernetes) eingeführt, die die Produktivität von Entwicklern und die Einführung DevOps Prinzipien erhöht haben.

Dies ist zwar ein aufstrebender Raum, der sich schnell weiterentwickelt, doch wurden mehrere wichtige Erkenntnisse und bewährte Methoden deutlich:

  • Verwenden eines verwalteten Kubernetes-Diensts anstelle der Installation und Verwaltung von Kubernetes
    Kubernetes ist ein sehr komplexes System und verfügt immer noch über eine Reihe von Standardeinstellungen, die nicht sicher sind, und nur wenige Kubernetes-Sicherheitsexperten auf dem Markt. Obwohl sich dies in den letzten Jahren mit jeder Veröffentlichung verbessert hat, gibt es immer noch viele Risiken, die abgemildert werden müssen.

  • Überprüfen der Container- und Container-Lieferkette
    Ebenso wie Sie die Sicherheit von Open-Source-Code überprüfen sollten, der Ihren Anwendungen hinzugefügt wird, sollten Sie auch Container überprüfen, die Sie Ihren Anwendungen hinzufügen.

    • Stellen Sie sicher, dass die beim Erstellen des Containers angewendeten Praktiken anhand Ihrer Sicherheitsstandards überprüft werden, z. B. anwendung von Sicherheitsupdates, Suchen nach unerwünschtem Code wie Backdoors und illegalen Krypto coin miners, Suchen nach Sicherheitslücken und Anwendung sicherer Entwicklungspraktiken.

    • Überprüfen Sie Container regelmäßig auf bekannte Risiken in der Containerregistrierung, vor der Verwendung oder während der Verwendung.

  • Einrichten der Registrierung von containern mit bekanntem Nutzen
    Dies ermöglicht Es Entwicklern in Ihrer Organisation, durch Die Sicherheit überprüfte Container schnell und ohne Reibung zu verwenden. Erstellen Sie darüber hinaus einen Prozess für Entwickler, um die Sicherheitsüberprüfung neuer Container anzufordern und schnell zu erhalten, um Entwickler zu ermutigen, diesen Prozess zu verwenden und ihn zu umgehen.

  • Führen Sie Container nur dann als Stamm oder Administrator aus, wenn dies explizit erforderlich ist.
    Frühe Versionen von Containern erforderten Stammberechtigungen (was Angriffe erleichtert), dies ist jedoch bei aktuellen Versionen nicht mehr erforderlich.

  • Überwachen von Containern
    Stellen Sie sicher, dass Sie Sicherheitsüberwachungstools bereitstellen, die containerbereit sind, um anomales Verhalten zu überwachen und die Untersuchung von Vorfällen zu ermöglichen.

Nächste Schritte

Weitere Sicherheitsanleitungen von Microsoft finden Sie in der Microsoft-Sicherheitsdokumentation.