Note
Die Unterstützung von OpenID Connect (OIDC) und der Richtlinie für bedingten Zugriff für Enterprise Managed Users ist nur in Microsoft Entra ID (früher Azure AD) verfügbar.
Informationen zur Unterstützung der Richtlinien für bedingten Zugriff
Wenn dein Unternehmen OIDC SSO verwendet, nutzt GitHub automatisch die IP-Bedingungen der Richtlinie für bedingten Zugriff (conditional access policy, CAP) deines Identitätsanbieters, um Interaktionen mit GitHub zu überprüfen, wenn Mitglieder die Web-UI verwenden oder die IP-Adressen ändern. Für jede Authentifizierung wird jedem Benutzerkonto ein personal access token oder ein SSH-Schlüssel zugeordnet.
Note
Der CAP-Schutz für Websitzungen befindet sich derzeit in der public preview und kann noch geändert werden.
Wenn die IDP-CAP-Unterstützung für dein Unternehmen bereits aktiviert ist, kannst du den erweiterten Schutz für Websitzungen über die Einstellungen „Authentication security“ deines Unternehmens aktivieren. Um dieses Feature zu aktivieren, muss dein Unternehmen über 1.000 oder weniger Mitglieder verfügen, aktiv oder gesperrt.
GitHub Enterprise Cloud unterstützt CAP für alle Unternehmen mit verwalteten Benutzerinnen mit aktiviertem OIDC-SSO. Unternehmensbesitzerinnen können diese Konfiguration für eine Liste zugelassener IP-Adressen anstelle der Liste zugelassener IP-Adressen von GitHub Enterprise Cloud verwenden. Dies ist nach der Konfiguration von OIDC-SSO möglich. Weitere Informationen zu IP-Positivlisten findest du unter Einschränken des Netzwerkdatenverkehrs in deinem Unternehmen mit einer Liste zugelassener IP-Adressen und Verwaltung erlaubter IP-Adressen für deine Organisation.
- GitHub Enterprise Cloud erzwingt die IP-Bedingungen deines Identitätsanbieters, kann aber nicht die Gerätekompatibilitätsbedingungen erzwingen.
- Richtlinien für die Multi-Factor Authentication werden nur zum Zeitpunkt der Anmeldung beim IdP erzwungen.
Weitere Informationen zur Verwendung von OIDC mit Enterprise Managed Users findest du unter Konfigurieren von OIDC für Enterprise Managed Users und Migrieren von SAML zu OIDC.
Informationen zu CAP und Bereitstellungsschlüsseln
Ein Bereitstellungsschlüssel ist ein SSH-Schlüssel, der Zugriff auf ein einzelnes Repository gewährt. Da Bereitstellungsschlüssel keine Vorgänge im Namen eines Benutzers ausführen, gelten die CAP-IP-Bedingungen nicht für Anforderungen, die mit einem Bereitstellungsschlüssel authentifiziert wurden. Weitere Informationen finden Sie unter Verwalten von Bereitstellungsschlüsseln.
Überlegungen zu Integrationen und Automatisierungen
GitHub sendet die IP-Quelladresse zur Überprüfung anhand deiner CAP an deinen IdP. Um sicherzustellen, dass Aktionen und Apps nicht von der CAP deines IdP blockiert werden, musst du Änderungen an deiner Konfiguration vornehmen.
Warning
Wenn du GitHub Enterprise Importer verwendest, um eine Organisation von deine GitHub Enterprise Server-Instanz zu migrieren, verwende unbedingt ein Dienstkonto, das von der Entra ID-CAP ausgenommen ist, da deine Migration sonst blockiert werden könnte.
GitHub Actions
Aktionen, die ein personal access token verwenden, werden wahrscheinlich von der CAP deines Identitätsanbieters blockiert. personal access token sollten von einem Dienstkonto erstellt werden, das dann von IP-Steuerungen in der CAP deines Identitätsanbieters ausgenommen ist.
Wenn du kein Dienstkonto verwenden kannst, ist die Zulassung der von GitHub Actions verwendeten IP-Bereiche eine weitere Option, Aktionen freizugeben, die personal access token verwenden. Weitere Informationen finden Sie unter Informationen zu den IP-Adressen von GitHub.
GitHub Codespaces
GitHub Codespaces ist u. U. nicht verfügbar, wenn dein Unternehmen OIDC-SSO mit CAP verwendet, um den Zugriff anhand von IP-Adressen zu beschränken. Dies liegt daran, dass Codespaces mit dynamischen IP-Adressen erstellt werden, die wahrscheinlich durch die CAP deines IdP blockiert werden. Andere CAP-Richtlinien können sich auch auf die Verfügbarkeit von GitHub Codespaces auswirken, abhängig vom spezifischen Setup der Richtlinie.
Der github.dev-Editor
Der github.dev-Editor ist möglicherweise nicht verfügbar, wenn Ihr Unternehmen OIDC SSO mit CAP verwendet, um den Zugriff nach IP-Adressen zu beschränken. Der Grund dafür ist, dass github.dev auf dynamische IP-Adressen angewiesen ist, die von der CAP Ihres IdP wahrscheinlich blockiert werden. Andere CAP-Richtlinien können sich auch auf die Verfügbarkeit von github.dev auswirken, abhängig vom spezifischen Setup der Richtlinie.
GitHub Apps und OAuth apps
Wenn GitHub Apps und OAuth apps eine Benutzerin anmeldet und Anforderungen im Auftrag von dieser bzw. diesem vornehmen, sendet GitHub die IP-Adresse des Servers der App zur Überprüfung an deinen IdP. Wenn die IP-Adresse des Servers der App von der CAP deines IdP nicht überprüft wird, tritt bei der Anforderung ein Fehler auf.
Wenn GitHub Apps GitHub-APIs aufruft, die entweder als App selbst oder als Installation fungieren, werden diese Aufrufe nicht im Namen von Benutzer*innen ausgeführt. Da die CAP deines Identitätsanbieters ausgeführt wird und Richtlinien auf Benutzerkonten anwendet, können diese Anwendungsanforderungen nicht anhand der CAP überprüft werden und sind immer zulässig. Weitere Informationen zur Authentifizierung von GitHub Apps als Apps selbst oder als Installation findest du unter Informationen zur Authentifizierung mit einer GitHub-App.
Du kannst die Besitzer der Apps, die du verwenden möchtest, nach ihren IP-Bereichen fragen und die CAP deines IDP konfigurieren, um den Zugriff von diesen IP-Bereichen aus zu ermöglichen. Wenn du dich nicht an die Besitzer wenden kannst, kannst du deinen IdP-Anmeldeprotokollen die in den Anforderungen angezeigten IP-Adressen entnehmen und dann diese Adressen auf die Zulassungsliste setzen.
Wenn du nicht alle IP-Adressbereiche für alle Apps deines Unternehmens zulassen möchtest, kannst du auch installierte GitHub Apps und autorisierte OAuth apps aus der Liste zugelassener IP-Adressen des Identitätsanbieters ausschließen. In diesem Fall funktionieren diese Apps weiterhin, unabhängig von der ursprünglichen IP-Adresse. Weitere Informationen finden Sie unter Erzwingen von Richtlinien für Sicherheitseinstellungen in deinem Unternehmen.
Weiterführende Themen
- Verwenden der Standortbedingung in einer Richtlinie für bedingten Zugriff auf Microsoft Learn