Freigeben über

Bewährte Methoden für die Sicherheit

  • Artikel

DevSecOps

DevSecOps nutzen: Implementieren sie Zero Trust Prinzipien, um Ihre DevOps-Plattformzu stärken, Ihre Entwicklungsumgebungzu schützen und Zero Trust nahtlos in Ihre Entwicklerworkflowszu integrieren.

Hinweis

Im Kontext von CI/CD kann die Implementierung des Zugriffs mit den geringsten Rechten aufgrund der dynamischen Natur der Architektur kontraproduktiv sein. Jedes Mal, wenn ein neuer Dienst eingeführt wird, müssen Berechtigungen vorab aktualisiert werden. Darüber hinaus erfordern Rollbacks möglicherweise zusätzliche Berechtigungen, die berücksichtigt werden müssen. Diese Herausforderung wird in Umgebungen mit mehreren Pipelines vergrößert. Während die geringsten Berechtigungsberechtigungen darauf abzielen, die Auswirkungen von Sicherheitsverletzungen zu minimieren, ist es entscheidend, die Sicherheit mit produktivitätsgleicher Sicherheit zu ausgleichen. Sie können dieses Gleichgewicht erreichen, indem Sie mehr eingeschränkten Zugriff übernehmen und die damit verbundenen Risiken mit ausgleichenden Kontrollen und Sicherheitspraktiken verringern, die auf dieser Seite beschrieben sind.

  • Vererbung deaktivieren: Deaktivieren Sie nach Möglichkeit die Vererbung. Durch die Vererbung kann unerwarteten Benutzern versehentlich Zugriff oder Berechtigungen gewährt werden, da dies standardmäßig zulässig ist. Weitere Informationen finden Sie im Abschnitt zur Berechtigungsvererbung
  • Umgebungssegmentierung: Weisen Sie separate Azure-Konten für Entwicklung, Tests, Produktion und andere Umgebungen zu. Dieser Ansatz verbessert die Sicherheit, indem der Strahlradius minimiert wird und Ressourcenkonflikte und Datenkontaminationen verhindert werden. Darüber hinaus ermöglicht es mehrere kurzlebige, feature-spezifische Ressourcen innerhalb des Entwicklungskontos. Bei großen Organisationen sollten Sie mindestens ein Konto pro Team pro Umgebung zuordnen. Separate Konten für geschäftskritische Workloads können ebenfalls gerechtfertigt sein. Erwägen Sie die Verwendung von Azure Landing Zone für eine optimierte Bereitstellung und effizientere Verwaltung.
  • Zugriffssteuerung und -Compliance: Wenden Sie Azure Policy in Verwaltungsgruppen an, um den Zugriff auf ungenutzte Azure-Regionen und -Dienste zu beschränken und die Einhaltung der Organisationsstandards sicherzustellen.
  • Attribute-Based Zugriffssteuerung (Access Control, ABAC): Implementieren sie ABAC- mit ordnungsgemäß markierten Ressourcen, um den Zugriff auf nicht autorisierte Akteure zu beschränken und nicht autorisierte Ressourcenerstellung zu verhindern.

Weitere Informationen zu Berechtigungen finden Sie in den folgenden Artikeln:

Berechtigungen auf Projektebene

  • Beschränken des Zugriffs auf Projekte und Repositorys: Verringern Sie das Risiko, dass vertrauliche Informationen verloren gehen, und stellen Sie unsicheren Code bereit, indem Sie den Zugriff auf Projekte und Repositorys beschränken. Verwenden Sie integrierte oder benutzerdefinierte Sicherheitsgruppen, um Berechtigungen zu verwalten.
  • Deaktivieren von „Öffentliche Projekte zulassen”: Deaktivieren Sie in den Richtlinieneinstellungen Ihrer Organisation die Option zum Erstellen öffentlicher Projekte. Wechseln Sie bei Bedarf die Sichtbarkeit des Projekts von öffentlich in privat. Benutzer, die sich nicht angemeldet haben, haben schreibgeschützten Zugriff auf öffentliche Projekte, während angemeldete Benutzer Zugriff auf private Projekte erhalten und zulässige Änderungen vornehmen können.
  • Einschränken der Projekterstellung: Verhindern, dass Benutzer neue Projekte erstellen, um die Kontrolle über Ihre Umgebung zu behalten.

Just-in-Time-Zugriff für Administratorgruppen

Wenn Sie über die Rolle Projektsammlungsadministrator und den Projektadministratorzugriff verfügen, können Sie die Konfiguration Ihrer Organisation oder Ihres Projekts ändern. Um die Sicherheit für diese integrierten Administratorgruppen zu verbessern, sollten Sie den Just-in-Time-Zugriff mithilfe einer Privileged Identity Management-(PIM-)Gruppe von (Microsoft Entra) implementieren. Mit diesem Ansatz können Sie erhöhte Berechtigungen nur bei Bedarf erteilen und somit das Risiko verringern, das mit permanentem Zugriff verbunden ist.

Konfigurieren des Zugriffs

  1. Erstellen Sie eine Gruppe in Microsoft Entra ID, der Rollen zugewiesen werden können.
  2. Fügen Sie Ihre Microsoft Entra-Gruppe der Azure DevOps-Gruppe hinzu.

Hinweis

Wenn Sie Just-in-Time-Zugriff mit einer Microsoft Entra Privileged Identity Management-(PIM-)Gruppe konfigurieren, stellen Sie sicher, dass jeder Benutzer mit erhöhtem Zugriff auch den Standardzugriff auf die Organisation behält. Auf diese Weise können sie die erforderlichen Seiten anzeigen und ihre Berechtigungen bei Bedarf aktualisieren.

Zugriff verwenden

  1. Aktivieren Sie Ihren Zugriff.
  2. Aktualisieren Sie Ihre Berechtigungen in Azure DevOps.
  3. Ergreifen Sie die Aktion, die Administratorzugriff erfordert.

Hinweis

Benutzer haben einen erhöhten Zugriff in Azure DevOps für bis zu 1 Stunde, nachdem ihr PIM-Gruppenzugriff deaktiviert wurde.

Sparsames Verwenden von PATs

  • Festlegen von PATs auf bestimmte Rollen: Weisen Sie PATs nur die erforderlichen Berechtigungen für bestimmte Aufgaben zu. Vermeiden Sie die Gewährung des globalen Zugriffs auf mehrere Organisationen oder Repositorys, um das Risiko eines versehentlichen Missbrauchs zu minimieren.
  • Vermeiden Sie Berechtigungen zum Schreiben oder Verwalten für Builds und Versionen: PATs sollten keine Schreib- oder Verwaltungsberechtigungen für Builds, Versionen oder andere wichtige Ressourcen haben. Durch das Einschränken dieser Berechtigungen können unbeabsichtigte Aktionen verhindert werden, die sich auf Ihre Pipelines oder Bereitstellungen auswirken könnten.
  • Legen Sie Ablaufdaten fest, und halten Sie PATs geheim: Legen Sie immer ein Ablaufdatum für PATs fest. Überprüfen und erneuern Sie sie bei Bedarf regelmäßig. Behandeln Sie PATs so kritisch wie Kennwörter, bewahren Sie sie vertraulich auf, und vermeiden Sie öffentliche Freigaben oder Hardcoding im Anwendungscode.
  • Vermeiden Sie hartcodierte PATs im Anwendungscode: Anstatt PATs direkt in Ihren Code einzubetten, verwenden Sie sichere Konfigurationsdateien oder Umgebungsvariablen, um PATs dynamisch zu speichern und abzurufen. dynamisch.
  • Regelmäßiges Überwachen und Widerrufen nicht verwendeter PATs: Administratoren sollten regelmäßig alle PATs mithilfe der REST-APIs überprüfen. Widerrufen Sie alle PATs, die nicht mehr benötigt werden oder die empfohlenen Kriterien nicht erfüllen.

Weitere Informationen finden Sie unter Verwalten von PATs mit Richtlinien – für Administratoren und die Verwendung von PATs.

Richtlinien

  • Anfordern externer Prüfer: Stellen Sie mindestens einen Prüfer neben dem ursprünglichen Prüfer für einen gründlichen Überprüfungsprozess sicher. Der Genehmigende ist für die Änderungen mitverantwortlich und trägt die Verantwortung für mögliche Auswirkungen.
  • CI-Build muss übergeben werden: Richten Sie einen Basisplan für die Codequalität ein, indem Sie den CI-Build (Continuous Integration) vor dem Zusammenführen einer PR übergeben müssen. CI-Prüfungen umfassen Codelinting, Komponententests und Sicherheitsüberprüfungen.
  • Selbstgenehmigung nicht zulassen: Verhindern Sie, dass der ursprüngliche PR-Antragsteller ihre eigenen Änderungen genehmigt, um einen unvoreingenommenen Überprüfungsprozess sicherzustellen und Interessenkonflikte zu vermeiden.
  • Fertigstellung der PR mit „Warten“- oder „Ablehnen“-Stimmen nicht zulassen: Verhindern Sie die Fertigstellung der PR, auch wenn einige Prüfer dafür stimmen, zu warten oder abzulehnen, und ermutigen Sie dazu, vor dem Zusammenführen alle Rückmeldungen zu berücksichtigen.
  • Zurücksetzen von Prüferstimmen zu Änderungen: Zurücksetzen von Prüferstimmen, wenn aktuelle Änderungen an die PR verschoben werden, um sicherzustellen, dass Prüfer den aktualisierten Code neu bewerten.
  • Sperren Von Releasepipelines: Beschränken Sie Freigabepipelines auf bestimmte Verzweigungen (in der Regel Produktion oder Haupt), um versehentliche Bereitstellungen von anderen Zweigstellen zu vermeiden.
  • Durchsetzen der einstellbaren Variablen zum Zeitpunkt der Warteschlangenverarbeitung: Aktivieren Sie die Option „Settable bei Warteschlangen-Zeit erzwingen“ für Pipeline-Variablen, um zu verhindern, dass Benutzer Variablenwerte während der Pipeline-Ausführung überschreiben.
  • Außerkraftsetzungen von Variablen im Editor nicht zulassen: Für Variablen, die im Pipeline-Editor festgelegt sind, verbieten Sie Benutzerüberschreibungen, um Konsistenz beizubehalten und unbeabsichtigte Änderungen zu verhindern.

Agents

  • Gewähren Sie Berechtigungen sparsam: Beschränken Sie Berechtigungen auf den kleinsten erforderlichen Satz von Konten, um die Angriffsfläche zu reduzieren.
  • Konfigurieren Sie restriktive Firewalls für Agents: Richten Sie Firewalls so restriktiv wie möglich ein, ohne die Funktionsfähigkeit der Agenten zu beeinträchtigen, und schaffen Sie so ein Gleichgewicht zwischen Sicherheit und Benutzerfreundlichkeit.
  • Aktualisieren Sie regelmäßig Agentpools: Halten Sie Ihre Agentflotte auf dem neuesten Stand, indem Sie regelmäßig Agents aktualisieren, um sicherzustellen, dass anfälliger Code nicht ausgeführt wird, wodurch das Risiko der Ausbeutung verringert wird.
  • Verwenden Sie einen separaten Agentpool für Produktionsartefakte: Isolieren Sie Produktionsartefakte, indem Sie einen separaten Agentpool verwenden, um versehentliche Bereitstellungen aus Nicht-Produktionszweigen zu verhindern.
  • Segmentieren vertraulicher Pools: Erstellen Sie separate Pools für vertrauliche und nicht sensible Workloads. Zulassen von Anmeldeinformationen in Builddefinitionen, die dem entsprechenden Pool zugeordnet sind.

Definitionen

  • Verwenden von YAML für Pipelinedefinitionen: Definieren von Pipelines mithilfe von YAML (Yet Another Markup Language) zur besseren Rückverfolgbarkeit und Einhaltung von Genehmigungsrichtlinien und Versionskontrollpraktiken.
  • Einschränken des Bearbeitungszugriffs auf Pipelinedefinitionen: Beschränken Sie den Zugriff auf Bearbeitungspipelinedefinitionen auf die minimal erforderlichen Konten, um das Risiko von versehentlichen oder nicht autorisierten Änderungen zu verringern.

Eingabe

  • Schließen der Überprüfungen auf Variablen in Buildskripts ein: Implementieren Sie Prüfungen in Ihren Buildskripts, um potenzielle Befehleinjektionsangriffe durch settable-Variablen zu mindern. Überprüfen Sie die Eingabewerte, und verhindern Sie unbeabsichtigte oder böswillige Befehle.
  • Beschränken der „bei der Freigabe einstellbaren“ Build-Variablen: Minimieren Sie die Anzahl der zur Veröffentlichung festgelegten Buildvariablen, um die Angriffsfläche zu reduzieren und die Konfigurationsverwaltung zu vereinfachen.

Aufgaben

  • Vermeiden von remote abgerufenen Ressourcen: Vermeiden Sie nach Möglichkeit das Abrufen von Ressourcen aus den externen URLs während des Buildprozesses. Wenn Remoteressourcen erforderlich sind, verwenden Sie Versionsverwaltung und Hashüberprüfung, um die Integrität zu gewährleisten.
  • Vermeiden der Protokollierung geheimer Schlüssel: Protokollieren Sie niemals vertrauliche Informationen, z. B. geheime Schlüssel oder Anmeldeinformationen, in Ihren Buildprotokollen, um unbeabsichtigte Gefährdung und Sicherheitskompromittierungen zu verhindern.
  • Verwenden von Azure Key Vault für geheime Schlüssel: Statt geheime Schlüssel direkt in den Pipelinevariablen zu speichern, verwenden Sie Azure Key Vault, um geheime Schlüssel sicher zu verwalten und abzurufen.
  • Beschränken der Ausführung von Builds auf beliebige Verzweigungen oder Tags: Beschränken Sie für sicherheitskritische Pipelines die Ausführung von Builds für alle Verzweigungen oder Tags. Definieren Sie bestimmte autorisierte Verzweigungen oder Tags, um versehentliche oder nicht autorisierte Ausführungen zu verhindern.
  • Deaktivieren der Vererbung für Pipelineberechtigungen: Geerbte Berechtigungen können übermäßig sein und entsprechen möglicherweise nicht genau Ihren Anforderungen. Deaktivieren Sie die Vererbung, und legen Sie Berechtigungen explizit fest, um die Sicherheitsanforderungen anzupassen.
  • Einschränken von Auftragsautorisierungsbereichen: Beschränken Sie Auftragsautorisierungsbereiche immer auf das erforderliche Minimum. Optimieren Sie Berechtigungen basierend auf den spezifischen Aufgaben, die von jedem Auftrag ausgeführt werden.

Repositorys und Branches

  • Anfordern einer Mindestanzahl von Prüfern: Aktivieren Sie die Richtlinie, um sicherzustellen, dass jede Pullanforderung Rezensionen von mindestens zwei Genehmigenden empfängt, um eine gründliche Codeüberprüfung und Rechenschaftspflicht zu fördern.
  • Konfigurieren der repositoryspezifische Sicherheitsrichtlinien: Passen Sie Sicherheitsrichtlinien an jedes Repository oder jeden Zweig anstelle von projektweiten Richtlinien an, um Risiken zu reduzieren, Änderungsmanagementstandards durchzusetzen und die Codequalität zu verbessern.
  • Isolieren der geheimen Produktionsgeheimnisse in einem separaten Schlüsseltresor: Speichern Sie geheime Produktionsgeheimnisse separat in einem Azure Key Vault, und beschränken Sie den Zugriff auf eine bedarfsorientierte Basis, um die Trennung von Nichtproduktionsbuilds aufrechtzuerhalten.
  • Trennen der Testumgebungen von der Produktion: Vermeiden Sie das Mischen von Testumgebungen mit der Produktion, um sicherzustellen, dass Anmeldeinformationen und geheime Schlüssel nicht in Nichtproduktionskontexten verwendet werden.
  • Deaktivieren der Freihandeingabe: Durch das Deaktivieren der Freihandeingabe können Sie die Sicherheit verwalten, indem die Verbreitung von Forks verhindert wird, wodurch die Sicherheit für alle Kopien einfacher nachverfolgt werden kann.
  • Vermeiden der Bereitstellung von Geheimschlüsseln für Verzweigungsbuilds: Teilen Sie geheime Schlüssel nicht mit verzweigten Builds, um sie vertraulich zu halten und nicht für Forks verfügbar zu machen.
  • Erwägen des manuelle Auslösens von Freihandbuilds: Lösen Sie Builds für Forks manuell aus, anstatt automatische Auslöser zuzulassen, um eine bessere Kontrolle über Sicherheitskontrollen zu bieten.
  • Verwenden der von Microsoft gehosteten Agents für Freihandbuilds: Verwenden Sie von Microsoft gehostete Agents für verzweigte Builds, da sie verwaltet und sicher sind.
  • Scannen der Produktionsbuilddefinitionen in Git-Repositorys: Überprüfen Sie regelmäßig Produktionsbuilddefinitionen, die im Git-Repository Ihres Projekts gespeichert sind, auf Anmeldeinformationen oder vertrauliche Informationen.
  • Konfigurieren der Prüfungen der Branch-Kontrolle für den Produktionskontext: Richten Sie Prüfungen für die Branch-Kontrolle ein, um die Nutzung sensibler Verbindungen (z. B. Produktionsverbindung) auf Pipelines zu beschränken, die im Kontext der Produktions-Branch ausgeführt werden, um eine ordnungsgemäße Autorisierung sicherzustellen und versehentlichen Missbrauch zu verhindern.

Weitere Informationen finden Sie unter Weitere Sicherheitsüberlegungen.

Container

  • Verwenden Sie vertrauenswürdige Images: Verwenden Sie offizielle und überprüfte Images aus seriösen Quellen wie Azure Container Registry oder Docker Hub. Geben Sie immer eine bestimmte Version oder ein bestimmtes Tag an, um Konsistenz und Zuverlässigkeit aufrechtzuerhalten, anstatt auf das latest-Tag zu vertrauen. Aktualisieren Sie regelmäßig Basisimages, um die neuesten Sicherheitspatches und Fehlerkorrekturen einzuschließen.
  • Überprüfen von Containern auf Sicherheitsrisiken und Durchsetzen des Runtime-Bedrohungsschutzes: Verwenden Sie Tools wie Microsoft Defender for Cloud, um Sicherheitsrisiken zu überwachen und zu erkennen. Darüber hinaus bietet Azure Container Registry integrierte Schwachstellenüberprüfung, um sicherzustellen, dass Container-Images vor der Bereitstellung sicher sind. Sie können auch Scantools von Drittanbietern über Azure DevOps-Erweiterungen für zusätzliche Sicherheitsüberprüfungen integrieren.
  • Implementieren Sie Sicherheitsrichtlinien, um eine Berechtigungseskalation zu verhindern und sicherzustellen, dass Container mit der geringsten Menge an Berechtigungen ausgeführt werden, dieerforderlich sind: Beispielsweise können Sie mit Azure Kubernetes Service (AKS), rollenbasierte Zugriffssteuerungund Pod Security Admission Richtlinien erzwingen, die Containerberechtigungen einschränken, die nicht stammbasierte Ausführung gewährleisten und den Zugriff auf kritische Ressourcen einschränken. Definieren Sie Pod Security Admission-Richtlinien (für Kubernetes 1.22 und höher), um Einschränkungen anzuwenden, z. B. die Verwendung privilegierter Container zu verhindern oder sicherzustellen, dass Container nicht auf das Hostnetzwerk zugreifen.
  • Netzwerkrichtliniennutzen: Netzwerkrichtlinien können verwendet werden, um die Kommunikation zwischen Containern einzuschränken, um sicherzustellen, dass nur autorisierte Container auf vertrauliche Ressourcen innerhalb Ihres Netzwerks zugreifen können. Darüber hinaus können Azure-Richtlinien für AKS genutzt werden, um bewährte Methoden für die Containersicherheit zu erzwingen, z. B. dass nur vertrauenswürdige Container-Images bereitgestellt werden.
  • Festlegen von containerspezifischen Ressourcengrenzwerten: Legen Sie beispielsweise Grenzwerte für CPU und Arbeitsspeicher fest, um zu verhindern, dass Container übermäßige Ressourcen verbrauchen, was zu Denial-of-Service- oder Sicherheitsrisiken führen kann.

Sichere GitHub-Integrationen

  • Verwenden des OAuth-Flusses anstelle von PATs: Deaktivieren Sie die PAT-basierte Authentifizierung für GitHub-Dienstverbindungen, und entscheiden Sie sich für den OAuth-Fluss für eine bessere Sicherheit und Integration.
  • Vermeiden der Administrator- oder Besitzeridentitäten: Authentifizieren Sie niemals GitHub-Dienstverbindungen mithilfe einer Identität, die ein Administrator oder Besitzer von Repositorys ist. Beschränken Sie Berechtigungen auf die erforderliche Ebene.
  • Vermeiden der GitHub-PATs mit vollem Umfang: Vermeiden Sie die Verwendung eines GitHub-PAT mit vollem Umfang, um Dienstverbindungen zu authentifizieren. Verwenden Sie Token mit den minimal erforderlichen Berechtigungen.
  • Vermeiden der persönlichen GitHub-Konten als Dienstverbindungen: Verwenden Sie keine persönlichen GitHub-Konten als Dienstverbindungen in Azure DevOps. Erstellen Sie stattdessen dedizierte Dienstkonten, oder verwenden Sie Konten auf Organisationsebene.