Sicherheitsempfehlungen für DevOps-Ressourcen
In diesem Artikel werden die Empfehlungen aufgeführt, die in Microsoft Defender für Cloud angezeigt werden, wenn Sie eine Azure DevOps-, GitHub- oder GitLab-Umgebung mithilfe der Seite "Umgebungseinstellungen " verbinden. Die Empfehlungen, die in Ihrer Umgebung angezeigt werden, basieren auf den Ressourcen, die Sie schützen und auf Ihrer angepassten Konfiguration.
Informationen zu Aktionen, die Sie als Reaktion auf diese Empfehlungen ausführen können, finden Sie unter "Korrekturempfehlungen" in Defender für Cloud.
Weitere Informationen den Vorteilen und Features von DevOps-Sicherheit finden Sie hier.
DevOps-Empfehlungen wirken sich nicht auf Ihre Sicherheitsbewertung aus. Um zu entscheiden, welche Empfehlungen zuerst behoben werden sollen, sehen Sie sich den Schweregrad jeder Empfehlung und die potenziellen Auswirkungen auf Ihre Sicherheitsbewertung an.
DevOps-Empfehlungen
Azure DevOps-Empfehlungen
In Azure DevOps-Repositorys sollte GitHub Advanced Security für Azure DevOps (GHAzDO) aktiviert sein.
Beschreibung: Die DevOps-Sicherheit in Defender für Cloud verwendet eine zentrale Konsole, um Sicherheitsteams mit der Möglichkeit zu unterstützen, Anwendungen und Ressourcen vor Code in der Cloud in Azure DevOps zu schützen. Durch die Aktivierung von GHAzDO-Repositorys (GitHub Advanced Security für Azure DevOps) erhalten Sie Ergebnisse zu Geheimnissen, Abhängigkeiten und Codesicherheitsrisiken in Ihren Azure DevOps-Repositorys, die in Microsoft Defender for Cloud erkannt wurden.
Schweregrad: hoch
Für Azure DevOps-Repositorys sollten Ergebnisse des Geheimnisscannens behandelt werden.
Beschreibung: Geheime Schlüssel wurden in Coderepositorys gefunden. Beheben Sie dies umgehend, um eine Sicherheitsverletzung zu verhindern. In Repositorys gefundene Geheimnisse können nach außen dringen oder von Angreifern entdeckt werden, was zur Kompromittierung einer Anwendung oder eines Dienstes führen kann. Hinweis: Das Microsoft Security DevOps-Tool für das Scannen von Anmeldeinformationen überprüft nur Builds, für die die Ausführung des Tools konfiguriert wurde. Daher spiegeln die Ergebnisse möglicherweise nicht den vollständigen Status von Geheimnissen in Ihren Repositorys wider.
Schweregrad: hoch
Für Azure DevOps-Repositorys müssen Ergebnisse des Codescannens aufgelöst werden.
Beschreibung: Sicherheitsrisiken wurden in Coderepositorys gefunden. Um den Sicherheitsstatus der Repositorys zu verbessern, empfiehlt es sich dringend, diese Sicherheitsrisiken zu beheben.
Schweregrad: Mittel
Für Azure DevOps-Repositorys sollten Ergebnisse der Scans auf Abhängigkeitssicherheitsrisiken behoben sein.
Beschreibung: Abhängigkeitsrisiken wurden in Coderepositorys gefunden. Um den Sicherheitsstatus der Repositorys zu verbessern, empfiehlt es sich dringend, diese Sicherheitsrisiken zu beheben.
Schweregrad: Mittel
Azure DevOps-Repositorys sollten über „Infrastruktur als Code“-Scans verfügen, deren Ergebnisse behandelt wurden.
Beschreibung: Infrastruktur als Codesicherheitskonfigurationsprobleme wurden in Repositorys gefunden. Die unten gezeigten Probleme wurden in Vorlagendateien erkannt. Um den Sicherheitsstatus der zugehörigen Cloudressourcen zu verbessern, empfiehlt es sich dringend, diese Probleme zu beheben.
Schweregrad: Mittel
In Azure DevOps-Buildpipelines sollten keine Geheimnisse für Builds von Forks verfügbar sein.
Beschreibung: In öffentlichen Repositorys ist es möglich, dass Personen von außerhalb der Organisation Forks erstellen und auf dem Verzweigungsrepository ausführen. Wenn diese Einstellung aktiviert ist, können Außenstehende Zugriff auf Buildpipeline-Geheimnisse erhalten, die intern sein sollen.
Schweregrad: hoch
Azure DevOps-Dienstverbindungen sollten nicht allen Pipelines Zugriff gewähren.
Beschreibung: Dienstverbindungen werden verwendet, um Verbindungen von Azure-Pipelines zu externen und Remotediensten zum Ausführen von Aufgaben in einem Auftrag zu erstellen. Pipelineberechtigungen steuern, welche Pipelines für die Verwendung der Dienstverbindung autorisiert sind. Um die Sicherheit der Pipelinevorgänge zu unterstützen, sollten Dienstverbindungen nicht zugriff auf alle YAML-Pipelines gewährt werden. Dies trägt dazu bei, das Prinzip der geringsten Rechte beizubehalten, da eine Sicherheitsanfälligkeit in Komponenten, die von einer Pipeline verwendet werden, von einem Angreifer genutzt werden kann, um andere Pipelines zu attackieren, die Zugriff auf kritische Ressourcen haben.
Schweregrad: hoch
Sichere Azure DevOps-Dateien sollten nicht allen Pipelines Zugriff gewähren.
Beschreibung: Mit sicheren Dateien können Entwickler Dateien speichern, die über Pipelines hinweg freigegeben werden können. Diese Dateien werden in der Regel verwendet, um geheime Schlüssel wie Signaturzertifikate und SSH-Schlüssel zu speichern. Wenn einer sicheren Datei Zugriff auf alle YAML-Pipelines gewährt wird, kann ein nicht autorisierter Benutzer Informationen aus den sicheren Dateien stehlen, indem er eine YAML-Pipeline erstellt und auf die sichere Datei zugreift.
Schweregrad: hoch
Azure DevOps-Variablengruppen mit geheimen Variablen sollten nicht allen Pipelines Zugriff gewähren.
Beschreibung: Variable Gruppen speichern Werte und geheime Schlüssel, die Sie möglicherweise an eine YAML-Pipeline übergeben oder in mehreren Pipelines verfügbar machen möchten. Sie können Variablengruppen in mehreren Pipelines im selben Projekt gemeinsam verwenden. Wenn eine variable Gruppe, die geheime Schlüssel enthält, als barrierefrei für alle YAML-Pipelines markiert ist, kann ein Angreifer die Objekte ausnutzen, die die geheimen Variablen betreffen, indem eine neue Pipeline erstellt wird.
Schweregrad: hoch
Azure DevOps: Klassische Azure-Dienstverbindungen sollten nicht für den Zugriff auf ein Abonnement verwendet werden.
Beschreibung: Verwenden Sie den Azure Resource Manager (ARM)-Typ von Dienstverbindungen anstelle von Azure Classic-Dienstverbindungen, um eine Verbindung mit Azure-Abonnements herzustellen. Das ARM-Modell bietet mehrere Sicherheitsverbesserungen, darunter eine stärkere Zugriffssteuerung, verbesserte Überwachung, ARM-basierte Bereitstellung/Governance, Zugriff auf verwaltete Identitäten und Schlüsseltresor für geheime Schlüssel, Entra Permissions-basierte Authentifizierung und Unterstützung für Tags und Ressourcengruppen für eine optimierte Verwaltung.
Schweregrad: Mittel
GitHub-Empfehlungen
Für GitHub-Repositorys muss das Geheimnisscannen aktiviert sein.
Beschreibung: GitHub durchsucht Repositorys nach bekannten Arten von Geheimschlüsseln, um betrügerische Verwendung von Geheimschlüsseln zu verhindern, die versehentlich an Repositorys begangen wurden. Beim Geheimnisscannen wird der gesamte Git-Verlauf für alle Branches in Ihrem GitHub-Repository nach Geheimnissen durchsucht. Beispiele für Geheimnisse sind Token und private Schlüssel, die ein Dienstanbieter für die Authentifizierung ausstellen kann. Wenn ein Geheimnis in ein Repository eingefügt wird, kann jeder, der über Lesezugriff auf das Repository verfügt, das Geheimnis verwenden, um mit diesen Berechtigungen auf den externen Dienst zuzugreifen. Geheimnisse sollten in einem dedizierten, sicheren Speicherort außerhalb des Repositorys für das Projekt gespeichert werden.
Schweregrad: hoch
Für GitHub-Repositorys muss das Codescannen aktiviert sein.
Beschreibung: GitHub verwendet Codeüberprüfung, um Code zu analysieren, um Sicherheitsrisiken und Fehler im Code zu finden. Mit dem Codescannen können Sie Korrekturen für vorhandene Probleme in Ihrem Code suchen, selektieren und priorisieren. Durch das Codescannen wird außerdem verhindert, dass Entwickler neue Probleme einführen. Für Überprüfungen können bestimmte Tage und Uhrzeiten festgelegt werden, oder Überprüfungen können ausgelöst werden, wenn im Repository ein bestimmtes Ereignis auftritt, z. B. ein Push. Wenn beim Codescannen ein potenzielles Sicherheitsrisiko oder ein Fehler im Code gefunden wird, zeigt GitHub eine Warnung im Repository an. Eine Sicherheitslücke ist ein Problem im Code eines Projekts, das ausgenutzt werden könnte, um die Vertraulichkeit, Integrität oder Verfügbarkeit des Projekts zu beeinträchtigen.
Schweregrad: Mittel
Für GitHub-Repositorys muss das Dependabot-Scannen aktiviert sein
Beschreibung: GitHub sendet Dependabot-Warnungen, wenn sie Sicherheitsrisiken in Codeabhängigkeiten erkennt, die Sich auf Repositorys auswirken. Eine Sicherheitslücke ist ein Problem im Code eines Projekts, das ausgenutzt werden könnte, um die Vertraulichkeit, Integrität oder Verfügbarkeit des Projekts oder anderer Projekte, die seinen Code verwenden, zu beeinträchtigen. Sicherheitsrisiken variieren im Hinblick auf Typ, Schweregrad und Angriffsmethode. Wenn Code von einem Paket abhängt, das eine Sicherheitslücke aufweist, kann diese anfällige Abhängigkeit eine Reihe von Problemen verursachen.
Schweregrad: Mittel
Für GitHub-Repositorys müssen Ergebnisse des Geheimnisscannens aufgelöst werden.
Beschreibung: Geheimnisse wurden in Coderepositorys gefunden. Dies sollte sofort behoben werden, um eine Sicherheitsverletzung zu verhindern. In Repositorys gefundene Geheimnisse können nach außen dringen oder von Angreifern entdeckt werden, was zur Kompromittierung einer Anwendung oder eines Dienstes führen kann.
Schweregrad: hoch
Für GitHub-Repositorys müssen Ergebnisse des Codescannens aufgelöst werden.
Beschreibung: Sicherheitsrisiken wurden in Coderepositorys gefunden. Um den Sicherheitsstatus der Repositorys zu verbessern, empfiehlt es sich dringend, diese Sicherheitsrisiken zu beheben.
Schweregrad: Mittel
Für GitHub-Repositorys sollten Ergebnisse der Scans auf Abhängigkeitssicherheitsrisiken behoben sein.
Beschreibung: GitHub-Repositorys sollten Abhängigkeitsüberprüfungsergebnisse behoben haben.
Schweregrad: Mittel
GitHub-Repositorys sollten über „Infrastruktur als Code“-Scans verfügen, deren Ergebnisse behandelt wurden.
Beschreibung: Infrastruktur als Codesicherheitskonfigurationsprobleme wurden in Repositorys gefunden. Die unten gezeigten Probleme wurden in Vorlagendateien erkannt. Um den Sicherheitsstatus der zugehörigen Cloudressourcen zu verbessern, empfiehlt es sich dringend, diese Probleme zu beheben.
Schweregrad: Mittel
Für GitHub-Repositorys sollten Schutzrichtlinien für den Standardbranch aktiviert sein.
Beschreibung: Die Standardbranch des Repositorys sollte über Branch-Schutzrichtlinien geschützt werden, um zu verhindern, dass unbeabsichtigte/böswillige Änderungen direkt an das Repository gebunden werden.
Schweregrad: hoch
Für GitHub-Repositorys sollten erzwungene Pushvorgänge an den Standardbranch deaktiviert sein.
Beschreibung: Da die Standardbranch in der Regel für die Bereitstellung und andere privilegierte Aktivitäten verwendet wird, sollten alle Änderungen daran vorsichtig behandelt werden. Das Aktivieren von Force-Pushes kann unbeabsichtigte oder böswillige Änderungen an den Standardbranches verursachen.
Schweregrad: Mittel
Für GitHub-Organisationen sollte der Pushschutz für das Geheimnisscannen aktiviert sein.
Beschreibung: Der Pushschutz blockiert Commits, die geheime Schlüssel enthalten, wodurch versehentliche Expositionen von Geheimschlüsseln verhindert werden. Um das Risiko einer Gefährdung von Anmeldeinformationen zu vermeiden, sollte der Pushschutz für jedes Repository mit Unterstützung für Geheimnisüberprüfungen automatisch aktiviert sein.
Schweregrad: hoch
GitHub-Repositorys sollten keine selbstgehosteten Runner verwenden.
Beschreibung: Self-Hosted Runners auf GitHub fehlen Garantien für den Betrieb in kurzlebigen sauber virtuellen Computern und können dauerhaft durch nicht vertrauenswürdigen Code in einem Workflow kompromittiert werden. Selbstgehostete Runner sollten daher nicht für Aktionsworkflows verwendet werden.
Schweregrad: hoch
GitHub-Organisationen sollten über Workflowberechtigungen für Aktionen verfügen, die auf schreibgeschützt festgelegt sind.
Beschreibung: Standardmäßig sollten Aktionsworkflows schreibgeschützte Berechtigungen erteilt werden, um böswillige Benutzer daran zu hindern, überberechtigungierte Workflows für den Zugriff auf ressourcen zu nutzen und sie zu manipulieren.
Schweregrad: hoch
GitHub-Organisationen sollten über mehr als eine Person mit Administratorberechtigungen verfügen.
Beschreibung: Wenn sie mindestens zwei Administratoren haben, verringert sich das Risiko, dass der Administratorzugriff verloren geht. Dies ist bei Notfall-Kontoszenarien nützlich.
Schweregrad: hoch
GitHub-Organisationen sollten über Basisberechtigungen verfügen, die auf „keine Berechtigungen“ oder „Lesen“ festgelegt sind.
Beschreibung: Basisberechtigungen sollten für eine Organisation nicht festgelegt oder gelesen werden, um dem Prinzip der geringsten Berechtigungen zu folgen und unnötigen Zugriff zu verhindern.
Schweregrad: hoch
(Vorschau) Für GitHub-Repositorys müssen beim API-Sicherheitstest festgestellte Probleme behoben werden.
Beschreibung: Api-Sicherheitsrisiken wurden in Coderepositorys gefunden. Um den Sicherheitsstatus der Repositorys zu verbessern, empfiehlt es sich dringend, diese Sicherheitsrisiken zu beheben.
Schweregrad: Mittel
GitLab-Empfehlungen
Für GitLab-Projekte müssen Ergebnisse des Geheimnisscannens aufgelöst werden.
Beschreibung: Geheimnisse wurden in Coderepositorys gefunden. Dies sollte sofort behoben werden, um eine Sicherheitsverletzung zu verhindern. In Repositorys gefundene Geheimnisse können nach außen dringen oder von Angreifern entdeckt werden, was zur Kompromittierung einer Anwendung oder eines Dienstes führen kann.
Schweregrad: hoch
Für GitLab-Projekte müssen Ergebnisse des Codescannens aufgelöst werden.
Beschreibung: Sicherheitsrisiken wurden in Coderepositorys gefunden. Um den Sicherheitsstatus der Repositorys zu verbessern, empfiehlt es sich dringend, diese Sicherheitsrisiken zu beheben.
Schweregrad: Mittel
Für GitLab-Projekte sollten Ergebnisse der Scans auf Abhängigkeitssicherheitsrisiken behoben sein.
Beschreibung: GitHub-Repositorys sollten Abhängigkeitsüberprüfungsergebnisse behoben haben.
Schweregrad: Mittel
GitLab-Projekte sollten über „Infrastruktur als Code“-Scans verfügen, deren Ergebnisse behandelt wurden.
Beschreibung: Infrastruktur als Codesicherheitskonfigurationsprobleme wurden in Repositorys gefunden. Die unten gezeigten Probleme wurden in Vorlagendateien erkannt. Um den Sicherheitsstatus der zugehörigen Cloudressourcen zu verbessern, empfiehlt es sich dringend, diese Probleme zu beheben.
Schweregrad: Mittel
Veraltete DevOps-Sicherheitsempfehlungen
Für Coderepositorys müssen Ergebnisse des Codescannens aufgelöst werden
Beschreibung: Die DevOps-Sicherheit in Defender für Cloud hat Sicherheitsrisiken in Coderepositorys gefunden. Um den Sicherheitsstatus der Repositorys zu verbessern, empfiehlt es sich dringend, diese Sicherheitsrisiken zu beheben. (Keine zugehörige Richtlinie)
Schweregrad: Mittel
Für Coderepositorys müssen Ergebnisse des Geheimnisscannens aufgelöst werden
Beschreibung: Die DevOps-Sicherheit in Defender für Cloud hat in Coderepositorys einen geheimen Schlüssel gefunden. Dies sollte sofort behoben werden, um eine Sicherheitsverletzung zu verhindern. In Repositorys gefundene Geheimnisse können nach außen dringen oder von Angreifern entdeckt werden, was zur Kompromittierung einer Anwendung oder eines Dienstes führen kann. Für Azure DevOps überprüft das Microsoft Security DevOps CredScan-Tool nur Builds, in denen es für die Ausführung konfiguriert wurde. Daher spiegeln die Ergebnisse möglicherweise nicht den vollständigen Status von Geheimnissen in Ihren Repositorys wider. (Keine zugehörige Richtlinie)
Schweregrad: hoch
Für Coderepositorys müssen Ergebnisse des Dependabot-Scannens aufgelöst werden
Beschreibung: Die DevOps-Sicherheit in Defender für Cloud hat Sicherheitsrisiken in Coderepositorys gefunden. Um den Sicherheitsstatus der Repositorys zu verbessern, empfiehlt es sich dringend, diese Sicherheitsrisiken zu beheben. (Keine zugehörige Richtlinie)
Schweregrad: Mittel
Für Coderepositorys müssen Ergebnisse des Infrastructure-as-Code-Scannens aufgelöst werden
Beschreibung: Die DevOps-Sicherheit in Defender für Cloud hat Infrastruktur als Codesicherheitskonfigurationsprobleme in Repositorys gefunden. Die unten gezeigten Probleme wurden in Vorlagendateien erkannt. Um den Sicherheitsstatus der zugehörigen Cloudressourcen zu verbessern, empfiehlt es sich dringend, diese Probleme zu beheben. (Keine zugehörige Richtlinie)
Schweregrad: Mittel
Für GitHub-Repositorys muss das Codescannen aktiviert sein.
Beschreibung: GitHub verwendet Codeüberprüfung, um Code zu analysieren, um Sicherheitsrisiken und Fehler im Code zu finden. Mit dem Codescannen können Sie Korrekturen für vorhandene Probleme in Ihrem Code suchen, selektieren und priorisieren. Durch das Codescannen wird außerdem verhindert, dass Entwickler neue Probleme einführen. Für Überprüfungen können bestimmte Tage und Uhrzeiten festgelegt werden, oder Überprüfungen können ausgelöst werden, wenn im Repository ein bestimmtes Ereignis auftritt, z. B. ein Push. Wenn beim Codescannen ein potenzielles Sicherheitsrisiko oder ein Fehler im Code gefunden wird, zeigt GitHub eine Warnung im Repository an. Eine Sicherheitslücke ist ein Problem im Code eines Projekts, das ausgenutzt werden könnte, um die Vertraulichkeit, Integrität oder Verfügbarkeit des Projekts zu beeinträchtigen. (Keine zugehörige Richtlinie)
Schweregrad: Mittel
Für GitHub-Repositorys muss das Geheimnisscannen aktiviert sein.
Beschreibung: GitHub durchsucht Repositorys nach bekannten Arten von Geheimschlüsseln, um betrügerische Verwendung von Geheimschlüsseln zu verhindern, die versehentlich an Repositorys begangen wurden. Beim Geheimnisscannen wird der gesamte Git-Verlauf für alle Branches in Ihrem GitHub-Repository nach Geheimnissen durchsucht. Beispiele für Geheimnisse sind Token und private Schlüssel, die ein Dienstanbieter für die Authentifizierung ausstellen kann. Wenn ein Geheimnis in ein Repository eingefügt wird, kann jeder, der über Lesezugriff auf das Repository verfügt, das Geheimnis verwenden, um mit diesen Berechtigungen auf den externen Dienst zuzugreifen. Geheimnisse sollten in einem dedizierten, sicheren Speicherort außerhalb des Repositorys für das Projekt gespeichert werden. (Keine zugehörige Richtlinie)
Schweregrad: hoch
Für GitHub-Repositorys muss das Dependabot-Scannen aktiviert sein
Beschreibung: GitHub sendet Dependabot-Warnungen, wenn sie Sicherheitsrisiken in Codeabhängigkeiten erkennt, die Sich auf Repositorys auswirken. Eine Sicherheitslücke ist ein Problem im Code eines Projekts, das ausgenutzt werden könnte, um die Vertraulichkeit, Integrität oder Verfügbarkeit des Projekts oder anderer Projekte, die seinen Code verwenden, zu beeinträchtigen. Sicherheitsrisiken variieren im Hinblick auf Typ, Schweregrad und Angriffsmethode. Wenn Code von einem Paket abhängt, das eine Sicherheitslücke aufweist, kann diese anfällige Abhängigkeit eine Reihe von Problemen verursachen. (Keine zugehörige Richtlinie)
Schweregrad: Mittel