Freigeben über

Empfehlungen zur Sicherung eines Entwicklungslebenszyklus

  • Artikel

Hierfür gilt die Empfehlung der Power Platform Well-Architected Security-Checkliste:

SE:02 Sorgen Sie für einen sicheren Entwicklungslebenszyklus durch die Verwendung einer verstärkten, weitgehend automatisierten und überprüfbaren Software-Lieferkette. Integrieren Sie ein sicheres Design, indem Sie Bedrohungsmodellierung zum Schutz vor sicherheitsgefährdenden Implementierungen verwenden.

Diese Anleitung beschreibt die Empfehlungen zur Sicherung Ihres Codes und Ihrer Entwicklungsumgebung durch die Anwendung bewährter Sicherheitsmethoden während des gesamten Entwicklungszyklus.

Den Kern einer Workload bilden die Komponenten, die die Geschäftslogik implementieren. Diese Komponenten können eine Mischung aus Low-Code-Elementen wie Canvas-Apps und Flows und Code-First-Elementen wie Plug-Ins sein. Alle Komponenten Ihrer Workload müssen frei von Sicherheitsmängeln sein, um Vertraulichkeit, Integrität und Verfügbarkeit sicherzustellen.

Die Sicherung der Infrastrukturebene mit Identitäts- und Netzwerkkontrollen ist zwar wichtig, reicht jedoch nicht aus. Verhindern Sie eine mangelhafte Implementierung von Power Platform-Workloads und beeinträchtigte Aktivitäten in diesen Workloads, um Ihre allgemeine Sicherheitslage zu stärken. Der Prozess der Integration von Sicherheit in Ihren Entwicklungslebenszyklus ist im Wesentlichen ein Härtungsprozess. Genau wie die Ressourcenhärtung ist auch die Straffung der Code-Entwicklung kontextunabhängig. Der Fokus liegt dabei auf der Erhöhung der Sicherheit, nicht auf den funktionalen Anforderungen der Anwendung.

Definitionen

Begriff Definition
Security Development Lifecycle (SDL) Eine Reihe von Praktiken, die von Microsoft bereitgestellt wurden, und die die Sicherheitsgarantie- und Compliance-Anforderungen unterstützen.
Software Development Lifecycle (SDLC) Ein mehrstufiger, systematischer Prozess zur Entwicklung von Softwaresystemen.

Wichtige Designstrategien

Sicherheitsmaßnahmen sollten an mehreren Stellen in Ihren bestehenden Software Development Lifecycle (SDLC) integriert werden, um Folgendes sicherzustellen:

  • Designentscheidungen führen nicht zu Sicherheitslücken.
  • Low-Code- und Code-First-Komponenten sowie -Konfigurationen verursachen keine Schwachstellen aufgrund einer ausnutzbaren Implementierung und unsachgemäßer Codierungspraktiken.
  • Low-Code- und Code-First-Komponenten und Bereitstellungsprozesse werden nicht manipuliert.
  • Durch Vorfälle aufgedeckte Schwachstellen werden behoben.
  • Die Compliance-Anforderungen werden weder beeinträchtigt noch verringert.
  • Die Überwachungsprotokollierung ist in allen Umgebungen implementiert.

Die folgenden Abschnitte bieten Sicherheitsstrategien für die häufig praktizierten Phasen des SDLC.

Anforderungsphase

Das Ziel der Anforderungsphase besteht darin, die funktionalen und nicht funktionalen Anforderungen für eine Workload oder eine neue Funktion einer Workload zu sammeln und zu analysieren. Diese Phase ist wichtig, da sie die Erstellung von Leitplanken erleichtert, die auf die Ziele der Workload zugeschnitten sind. Der Schutz der Daten und der Integrität Ihrer Workload sollte in jeder Phase des Entwicklungslebenszyklus eine zentrale Anforderung sein.

Stellen Sie sich beispielsweise eine Workload vor, bei der Benutzer Daten innerhalb einer Anwendung eingeben und ändern. Bei der Sicherheitsgestaltung sollten Zusicherungen für die Interaktion des Benutzers mit den Daten berücksichtigt werden, etwa die Authentifizierung und Autorisierung der Benutzeridentität sowie das Zulassen ausschließlich zulässiger Aktionen mit den Daten. Nichtfunktionale Anforderungen umfassen Verfügbarkeit, Benutzerfreundlichkeit und Wartbarkeit. Zu den Sicherheitsentscheidungen sollten Segmentierungsgrenzen, Firewall-Eingang und -Ausgang sowie andere übergreifende Sicherheitsaspekte gehören.

Alle diese Entscheidungen sollten zu einer guten Definition der Sicherheitslage der Workload führen. Dokumentieren Sie die Sicherheitsanforderungen in einer vereinbarten Spezifikation, und spiegeln Sie sie im Rückstandsprotokoll wider. Das Dokument sollte die Sicherheitsinvestitionen sowie die Kompromisse und Risiken, die das Unternehmen bereit ist einzugehen, wenn die Investitionen von den Geschäftspartnern nicht genehmigt werden, explizit darlegen. Sie können beispielsweise die Notwendigkeit dokumentieren, in Power Platform-Umgebungen eine IP-Firewall zu verwenden, um Ihre Unternehmensdaten zu schützen, indem Sie den Dataverse-Zugriff auf ausschließlich zulässige IP-Standorte beschränken. Wenn geschäftliche Stakeholder die Mehrkosten für die Nutzung einer Lösung wie verwaltete Umgebungen nicht tragen möchten, müssen sie das Risiko in Kauf nehmen, dass auf Unternehmensressourcen von öffentlichen Standorten, beispielsweise einem Café, aus zugegriffen wird. Stellen Sie sich als weiteres Beispiel vor, dass Ihre Anwendung eine Verbindung zu einer Drittanbieter-Datenquelle herstellen muss. Power Platform verfügt möglicherweise über einen vorgefertigten Konnektor hierfür, dieser unterstützt jedoch möglicherweise nicht die von Ihren Sicherheitsteams genehmigten Authentifizierungsanforderungen. In diesem Fall sind Ihre Sicherheits-Stakeholder möglicherweise bereit, das Risiko einer nicht genehmigten Authentifizierungsmethode in Kauf zu nehmen. Alternativ können Sie die Verwendung eines benutzerdefinierten Konnektors prüfen, wobei Sie die Vorteile einer längeren Entwicklungszeit und einer möglichen Projektverzögerung abwägen müssen.

Das Erfassen der Sicherheitsanforderungen ist ein entscheidender Teil dieser Phase. Ohne diesen Aufwand basieren die Entwurfs- und Implementierungsphasen auf unausgesprochenen Entscheidungen, was zu Sicherheitslücken oder geänderten Anforderungen führen kann, welche die Entwicklungszeit verlängern. Aus Sicherheitsgründen müssen Sie die Implementierung möglicherweise später ändern, was kostspielig sein kann.

Designphase

In dieser Phase werden die Sicherheitsanforderungen in technische Anforderungen umgewandelt. Dokumentieren Sie in Ihrer technischen Spezifikation alle Designentscheidungen, um Unklarheiten während der Implementierung zu vermeiden. Im Folgenden sind einige typische Aufgaben aufgeführt:

  • Definieren Sie die Sicherheitsdimension der Architektur. Überlagern Sie die Architektur mit Sicherheitskontrollen. Beispiele hierfür sind praktische Kontrollen in Bezug auf die Netzwerkisolationsgrenzen, die Arten von Identitäten und Authentifizierungsmethoden, die für die Komponenten der Workload benötigt werden, und die Art der zu verwendenden Verschlüsselungsmethoden.

  • Bewerten Sie die von der Plattform bereitgestellten Möglichkeiten. Es ist wichtig, die Aufteilung der Verantwortung zwischen Ihnen und Power Platform zu verstehen. Vermeiden Sie Überschneidungen oder Duplikate mit nativen Power Platform-Sicherheitskontrollen. Sie erhalten eine bessere Sicherheitsabdeckung und können Entwicklungsressourcen entsprechend den Anforderungen der Anwendung neu zuweisen.

    Anstatt beispielsweise eine benutzerdefinierte Logik zu erstellen, die nicht genehmigte Verwendungsmuster in Apps und Flows reaktiv identifiziert und davor warnt, verwenden Sie Richtlinien zur Verhinderung von Datenverlust, um zu kategorisieren, wie Konnektoren verwendet werden können.

    Wählen Sie nur vertrauenswürdige Referenzimplementierungen, Vorlagen, Codekomponenten, Skripts und Bibliotheken. Ihr Design sollte auch eine sichere Versionskontrolle vorsehen. Anwendungsabhängigkeiten sollten von vertrauenswürdigen Parteien bezogen werden. Drittanbieter sollten in der Lage sein, Ihre Sicherheitsanforderungen zu erfüllen und ihren Plan zur verantwortungsvollen Offenlegung Teilen. Jeder Sicherheitsvorfall sollte umgehend gemeldet werden, damit Sie die erforderlichen Maßnahmen ergreifen können. Außerdem sind bestimmte Bibliotheken oder Referenzimplementierungen möglicherweise in Ihrer Organisation verboten. Beispielsweise kann es sein, dass die Anwendung auch dann nicht zugelassen wird, wenn sie sicher ist und keine Sicherheitslücken aufweist, da sie Funktionen verwendet, die von Ihrer Organisation noch nicht genehmigt wurden, oder weil Lizenzbeschränkungen oder das Supportmodell der Referenzimplementierung vorliegen.

    Um sicherzustellen, dass diese Richtlinien befolgt werden, führen Sie eine Liste genehmigter und/oder nicht genehmigter Frameworks, Bibliotheken und Anbieter und stellen Sie sicher, dass Ihre Entwickler mit dieser Liste vertraut sind. Platzieren Sie, wenn möglich, Leitplanken in den Entwicklungspipelines, um die Liste zu unterstützen. Automatisieren Sie so weit wie möglich die Verwendung von Tools zum Scannen von Abhängigkeiten auf Schwachstellen.

  • Speichern Sie Anwendungsgeheimnisse sicher. Implementieren Sie sicher die Verwendung von Anwendungsgeheimnissen und vorab freigegebenen Schlüsseln, die Ihre Anwendung verwendet. Anmeldeinformationen und Anwendungsgeheimnisse sollten niemals im Quellcode der Workload (App oder Flow) gespeichert werden. Verwenden Sie externe Ressourcen wie Azure Key Vault, um sicherzustellen, dass kein weiterer Zugriff auf Ihren Quellcode möglich ist, wenn dieser einem potenziellen Angreifer zugänglich wird.

  • Verbinden Sie Ihre Daten sicher. Nutzen Sie die starken Sicherheitsfunktionen, die Microsoft Dataverse zum Schutz Ihrer Daten bietet, beispielsweise rollenbasierte Sicherheit und Sicherheit auf Spaltenebene. Verwenden Sie für andere Datenquellen Konnektoren mit sicheren Authentifizierungsmethoden. Vermeiden Sie Abfragen, die Benutzernamen und Kennwörter im Klartext speichern. Vermeiden Sie HTTP zum Erstellen benutzerdefinierter Konnektoren.

  • Definieren Sie, wie Endbenutzer mit der Workload und den Daten interagieren. Überlegen Sie, ob Benutzer direkten Zugriff auf die Daten haben, welche Zugriffsebene sie benötigen und von wo aus sie auf die Daten zugreifen. Überlegen Sie, wie Anwendungen mit Endbenutzern geteilt werden. Stellen Sie sicher, dass nur diejenigen Zugriff auf die App und die Daten haben, die dies benötigen. Vermeiden Sie komplexe Sicherheitsmodelle, die Problemumgehungen fördern, um Sicherheitsblocker zu umgehen.

  • Vermeiden Sie Hardcodierung. Vermeiden Sie die Hartcodierung von URLs und Schlüsseln. Vermeiden Sie beispielsweise einer Power Automate-HTTP-Aktion die Hartcodierung der URL oder des Schlüssels zum Backend-Dienst. Verwenden Sie stattdessen einen benutzerdefinierten Konnektor oder eine Umgebungsvariable für die URL und Azure Key Vault für den API-Schlüssel.

  • Definieren Sie Testpläne. Definieren Sie klare Testfälle für Sicherheitsanforderungen. Bewerten Sie, ob Sie diese Tests in Ihren Pipelines automatisieren können. Wenn Ihr Team über Prozesse zum manuellen Testen verfügt, schließen Sie Sicherheitsanforderungen für diese Tests ein.

Anmerkung

Führen Sie in dieser Phase eine Bedrohungsmodellierung durch. Durch Bedrohungsmodellierung können Sie bestätigen, dass die Designentscheidungen den Sicherheitsanforderungen entsprechen, und Lücken aufdecken, die Sie schließen sollten. Wenn Ihre Workload hochsensible Daten verarbeitet, investieren Sie in Sicherheitsexperten, die Sie bei der Bedrohungsmodellierung unterstützen können.

Die erste Übung zur Bedrohungsmodellierung sollte während der Designphase erfolgen, wenn die Architektur und das allgemeine Design der Software definiert werden. Wenn Sie dies in dieser Phase tun, können Sie potenzielle Sicherheitsprobleme erkennen, bevor sie in die Systemstruktur integriert werden. Bei dieser Übung handelt es sich jedoch nicht um eine einmalige Aktivität. Es ist ein kontinuierlicher Prozess, der während der gesamten Weiterentwicklung der Software fortgesetzt werden sollte.

Weitere Informationen finden Sie unter Empfehlung zur Bedrohungsanalyse.

Entwicklungs- und Testphase

In dieser Phase besteht das Ziel darin, Sicherheitsmängeln und Manipulationen an Code-, Build- und Bereitstellungspipelines vorzubeugen.

Sie sollten im Bereich der sicheren Code-Praktiken gut geschult sein.

Das Entwicklungsteam sollte Schulung in sicheren Codierungspraktiken erhalten. Beispielsweise sollten Entwickler mit Sicherheitskonzepten in Microsoft Dataverse vertraut sein, um ein Sicherheitsmodell mit den geringsten Berechtigungen und Inhaltssicherheitsrichtlinien für modellgesteuerte Apps zu implementieren und so die Einbettung auf vertrauenswürdige Domänen sowie auf Authentifizierungsmethoden für Konnektoren/lokale Gateways zu beschränken.

Entwickler sollten verpflichtet sein, diese Schulung zu absolvieren, bevor sie mit der Arbeit an Power Platform-Workloads beginnen.

Führen Sie interne Peer-Code-Überprüfungen durch, um kontinuierliches Lernen zu fördern.

Verwenden Sie Codeanalysetools

Die Lösungsüberprüfung sollte für Power Platform-Ressourcen verwendet werden, und der Quellcode jedes herkömmlichen Codes könnte auf potenzielle Sicherheitslücken überprüft werden, einschließlich des Vorhandenseins von Anmeldeinformationen im Code. Identifizieren Sie mögliche Fälle der Offenlegung von Anmeldeinformationen und Geheimnissen im Quellcode und in Konfigurationsdateien. Dies ist ein guter Zeitpunkt, um zu überprüfen, wie Verbindungsanmeldeinformationen in der Produktion gehandhabt werden.

Fuzz-Tests durchführen

Verwenden Sie fehlerhafte und unerwartete Daten, um nach Schwachstellen zu suchen und die Fehlerbehandlung zu validieren. Dies ist besonders wichtig bei Lösungen, die Power Pages umfassen.

Schreiben Sie nur so viel Code, wie eben nötig

Wenn Sie Ihren Code-Fußabdruck reduzieren, verringern Sie auch die Wahrscheinlichkeit von Sicherheitsmängeln. Verwenden Sie Code und Bibliotheken erneut, die bereits verwendet werden und Sicherheitsüberprüfungen durchlaufen haben, anstatt Code zu duplizieren. Erkennung und Überprüfung von Open-Source-Software auf Version, Sicherheitsrisiken und rechtliche Verpflichtungen. Es gibt immer mehr Open-Source-Ressourcen für Power Platform, daher sollte dies nicht übersehen werden. Wenn möglich, sollte dies während der Designphase besprochen werden, um Probleme in letzter Minute zu vermeiden.

Entwicklungsumgebungen schützen

Um eine Offenlegung zu verhindern, müssen Entwickler-Workstations mit starken Netzwerk- und Identitätskontrollen geschützt werden. Stellen Sie sicher, dass Sicherheitsupdates sorgfältig angewendet werden.

Das Quellcode-Repository muss ebenfalls geschützt werden. Gewähren Sie Zugriff auf Code-Repositorys nur nach dem „Need-to-know“-Prinzip, und reduzieren Sie die Offenlegung von Schwachstellen so weit wie möglich, um Angriffe zu verhindern. Führen Sie einen gründlichen Prozess durch, um den Code auf Sicherheitslücken zu überprüfen. Verwenden Sie zu diesem Zweck Sicherheitsgruppen und implementieren Sie einen Genehmigungsprozess, der auf geschäftlichen Begründungen basiert.

Code-Bereitstellungen sichern

Es reicht nicht aus, nur den Code zu sichern. Wenn er in ausnutzbaren Pipelines ausgeführt wird, sind alle Sicherheitsbemühungen vergeblich und unvollständig. Build- und Release-Umgebungen müssen ebenfalls geschützt werden, da Sie verhindern möchten, dass böswillige Akteure Schadcode in Ihrer Pipeline ausführen.

Führen Sie ein aktuelles Inventar aller Komponenten, die in Ihre Anwendung integriert sind.

Jede neue Komponente, die in eine Anwendung integriert wird, vergrößert die Angriffsfläche. Um eine ordnungsgemäße Verantwortlichkeit und Benachrichtigung beim Hinzufügen oder Aktualisieren neuer Komponenten sicherzustellen, sollten Sie über ein Inventar dieser Komponenten verfügen. Überprüfen Sie regelmäßig, ob Ihr Manifest mit dem Inhalt Ihres Build-Prozesses übereinstimmt. Auf diese Weise stellen Sie sicher, dass keine neuen Komponenten unerwartet hinzugefügt werden, die „Hintertüren“ oder andere Schadsoftware enthalten.

Wir empfehlen die Verwendung von Pipelines für Power Platform für Ihre Bereitstellungen. Erweitern Sie Pipelines mit GitHub-Aktionen. Wenn Sie GitHub-Workflows verwenden, bevorzugen Sie von Microsoft erstellte Aufgaben. Validieren Sie außerdem Aufgaben, da diese im Sicherheitskontext Ihrer Pipeline ausgeführt werden.

Erkunden Sie die Verwendung von Dienstprinzipalen für die Bereitstellung.

Produktionsphase

Die Produktionsphase stellt die letzte verantwortungsvolle Möglichkeit dar, Sicherheitslücken zu schließen. Führen Sie ein Protokoll über das Golden Image, das in der Produktion freigegeben wird.

Versionierte Artefakte beibehalten

Führen Sie einen Katalog aller bereitgestellten Assets und ihrer Versionen. Diese Informationen sind bei der Vorfallsichtung, bei der Problembehebung und bei der Wiederherstellung eines funktionsfähigen Systems hilfreich. Versionierte Assets können auch mit veröffentlichten CVE-Hinweisen (Common Vulnerabilities and Exposures) verglichen werden. Sie sollten diese Vergleiche mithilfe der Automatisierung durchführen.

Notfallkorrekturen

Ihr automatisiertes Pipeline-Design sollte die Flexibilität haben, sowohl reguläre als auch Notfallbereitstellungen zu unterstützen. Diese Flexibilität ist wichtig, um schnelle und verantwortungsvolle Sicherheitskorrekturen zu unterstützen.

Ein Release ist typischerweise mit mehreren Genehmigungsgates verknüpft. Erwägen Sie die Erstellung eines Notfallprozesses, um Sicherheitskorrekturen zu beschleunigen. Der Prozess kann die Kommunikation zwischen Teams beinhalten. Die Pipeline sollte schnelle Rollforward- und Rollback-Bereitstellungen ermöglichen, die Sicherheitskorrekten, kritische Fehler und Code-Updates berücksichtigen, die außerhalb des regulären Bereitstellungslebenszyklus auftreten.

Anmerkung

Geben Sie Sicherheitskorrekturen immer Vorrang vor der Benutzerfreundlichkeit. Eine Sicherheitskorrektur sollte keine Regression oder Fehler verursachen. Wenn Sie die Behebung des Problems durch eine Notfall-Pipeline beschleunigen möchten, überlegen Sie sorgfältig, welche automatisierten Tests umgangen werden können. Bewerten Sie den Wert jedes Tests im Hinblick auf die Ausführungszeit. Beispielsweise sind Unit-Tests normalerweise schnell abgeschlossen. Integrations- oder End-to-End-Tests können lange dauern.

Halten Sie unterschiedliche Umgebungen getrennt

Produktionsdaten sollten nicht in niedrigeren Umgebungen verwendet werden,** da diese Umgebungen möglicherweise nicht über die strengen Sicherheitskontrollen der Produktion verfügen. Vermeiden Sie die Verbindung von einer nicht für Produktionsumgebungen bestimmten Anwendung zu einer Produktionsdatenbank, und vermeiden Sie die Verbindung von Nicht-Produktionskomponenten zu Produktionsnetzwerken.

Schrittweise Offenlegung verwenden

Nutzen Sie die schrittweise Offenlegung, um Funktionen basierend auf ausgewählten Kriterien einer Teilmenge von Benutzern zugänglich zu machen. Wenn Probleme auftreten, werden die Auswirkungen für diese Benutzer minimiert. Dieser Ansatz ist eine gängige Strategie zur Risikominderung, da er die Oberfläche reduziert. Mit zunehmender Weiterentwicklung der Funktion und steigendem Vertrauen in die Sicherheitszusagen können Sie diese nach und nach einem größeren Benutzerkreis zugänglich machen.

Wartungsphase

Das Ziel dieser Phase besteht darin, sicherzustellen, dass sich die Sicherheitslage mit der Zeit nicht verschlechtert. SDLC ist ein fortlaufender agiler Prozess. Die in den vorhergehenden Phasen behandelten Konzepte gelten auch für diese Phase, da sich die Anforderungen im Laufe der Zeit ändern.

Kontinuierliche Verbesserung. Bewerten und verbessern Sie die Sicherheit des Softwareentwicklungsprozesses kontinuierlich, indem Sie Codeüberprüfungen, Feedback, gewonnene Erkenntnisse und sich entwickelnde Bedrohungen sowie neue durch Power Platform bereitgestellte Funktionen berücksichtigen.

Entsorgen Sie Altanlagen , die veraltet sind oder nicht mehr verwendet werden. Dadurch wird die Oberfläche der Anwendung reduziert.

Zur Wartung gehört auch die Behebung von Vorfällen. Wenn in der Produktion Probleme festgestellt werden, müssen diese umgehend wieder in den Prozess integriert werden, damit sie nicht erneut auftreten.

Verbessern Sie Ihre sicheren Codierungspraktiken kontinuierlich, um mit der Bedrohungslandschaft Schritt zu halten.

SDL in Microsoft Power Platform

Power Platform basiert auf einer Kultur und Methodik des sicheren Designs. Sowohl die Kultur als auch die Methodik werden ständig durch die Praktiken der in der Branche führenden Praktiken des Security Development Lifecycle (SDL) und der BedrohungsModellierung von Microsoft ständig verstärkt.

Der Überprüfungsprozess der BedrohungsModellierung stellt sicher, dass Bedrohungen während der Entwurfsphase identifiziert, eindämmt und überprüft werden, um sicherzustellen, dass sie eingedämmt wurden.

Die BedrohungsModellierung berücksichtigt auch alle Änderungen an Diensten, die bereits live sind, durch kontinuierliche regelmäßige Überprüfungen. Der Einsatz des STRIDE-Modells hilft, die häufigsten Probleme mit unsicherem Design zu lösen.

Microsofts SDL entspricht dem OWASP Software Assurance Maturity Model (SAMM). Beide basieren auf der Prämisse, dass sicheres Design ein integraler Bestandteil der Sicherheit von Webanwendungen ist. Weitere Informationen finden Sie unter Top-10-OWASP-Risiken: Risikominderung in Power Platform.

Umsetzung in Power Platform

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

Defender für DevOps und die SAST-Tools (Static Application Security Testing) sind Teil von GitHub Advanced Security und Azure DevOps. Mithilfe dieser Tools können Sie den Sicherheitswert Ihrer Organisation ermitteln.

Mit der Lösungsprüferfunktion können Sie eine umfangreiche Prüfung der statischen Analyse auf Ihren Lösungen für einen Satz von Regeln der bewährten Methode ausführen und diese problematischen Muster schnell ermitteln. Siehe Lösungsüberprüfung verwenden, um Ihre Lösungen zu validieren.

Sicherheitscheckliste

Lesen Sie die vollständigen Empfehlungen.

Sicherheitscheckliste