Einschränken des Zugriffs auf GitHub.com mithilfe eines Unternehmensproxys

Note

Der Header zum Einschränken des Zugriffs auf GitHub.com befindet sich derzeit in public preview und kann geändert werden. Obwohl Previewreleases normalerweise nicht vom GitHub-Support unterstützt werden (siehe Early-Access-Versionen mit Funktionsvorschau erkunden), wird dieses Feature in der public preview vom GitHub-Support unterstützt.

Wenn du Enterprise Managed Users verwendest, kannst du verhindern, dass sich Benutzende in deinem Netzwerk mit Konten bei GitHub.com authentifizieren, die keine Mitglieder deines Unternehmens sind. Dies trägt dazu bei, das Risiko zu verringern, dass die Daten deines Unternehmens öffentlich zugänglich gemacht werden.

Um diese Einschränkung zu erzwingen, konfiguriere deinen Netzwerkproxy oder deine Firewall so, dass ein Header in die Web- und API-Anforderungen der Benutzenden an GitHub.com eingefügt wird.

Für dieses Feature ist eine externe Firewall oder ein Proxy erforderlich. GitHub-Support kann bei externen Tools wie diesem nicht bei der Einrichtung oder Problembehandlung helfen. Weitere Informationen zum Umfang der Unterstützung findest du unter Informationen zum GitHub Support.

Anfordern des Zugriffs

Diese Funktion ist nicht standardmäßig aktiviert. Wende dich für die Zugriffsanforderung an den Kontomanager im GitHub-Vertriebsteam, oder registriere dich hier.

Voraussetzungen

Du musst ein Unternehmen mit verwalteten Benutzer*innen auf GitHub.com verwenden.
- Du wirst bemerken, dass du ein Unternehmen mit verwalteten Benutzer*innen verwendest, wenn an alle Benutzernamen der Benutzenden der Kurzcode deines Unternehmens angefügt wird.
- Wenn du GitHub Enterprise-Cloud mit Datenresidenz verwendest, befindet sich dein Unternehmen in einer dedizierten Unterdomäne von GHE.com, sodass der Header nicht erforderlich ist, um den Datenverkehr zu den Ressourcen deines Unternehmens zu unterscheiden.
Um die Einschränkung zu erzwingen, muss der gesamte Datenverkehr einen Proxy oder eine Firewall durchlaufen. Der Proxy bzw. die Firewall muss Folgendes können:
- Abfangen und Bearbeiten von Datenverkehr (wird häufig als Break-and-Inspect-Proxy bezeichnet)
- Unterstützen der arbiträren Headerinjektion
GitHub muss dir Zugriff auf dieses Feature gewährt haben.

Ermitteln des Headers

Um die Einschränkung zu erzwingen, injizierst du einen Header in den gesamten Datenverkehr, der an bestimmte unterstützte Endpunkte weitergeleitet wird. Der Header weist das folgende Format auf.

sec-GitHub-allowed-enterprise: ENTERPRISE-ID

Unternehmensbesitzende können die richtige Unternehmens-ID identifizieren, die im Header für dein Unternehmen verwendet werden soll.

Klicke in der oberen rechten Ecke von GitHub auf dein Profilfoto und dann auf Dein Unternehmen.
Klicken Sie auf der linken Seite der Seite in der Randleiste des Enterprise-Kontos auf Einstellungen.
Wähle unter Einstellungen die Option Authentifizierungssicherheit aus.
Im Abschnitt „Enterprise access restrictions“ findest du den Header für dein Unternehmen. Dieser Abschnitt ist nur für Unternehmen sichtbar, für die das Feature aktiviert ist.

Verwenden des -Headers

Um optimale Ergebnisse zu erzielen, konfiguriere deinen Proxy so, dass der Header in den gesamten Datenverkehr an die folgenden unterstützten Endpunkte injiziert wird.

Endpunkt	Zweck
`github.com/*`	Webdatenverkehr an GitHub.com
`api.github.com/*`	REST- und GraphQL-API-Anforderungen
`*.githubcopilot.com`	Datenverkehr, der für bestimmte GitHub Copilot-Features erforderlich ist

Dadurch wird verhindert, dass Personen in deinem Netzwerk auf diese Endpunkte mit Benutzerkonten zugreifen, die nicht im Besitz deines Unternehmens sind. Neben diesem Feature kannst du den Datenverkehr von außerhalb deines Netzwerks blockieren, indem du eine IP-Zulassungsliste einrichtest. Weitere Informationen findest du unter Einschränken des Netzwerkdatenverkehrs in deinem Unternehmen mit einer Liste zugelassener IP-Adressen.

Note

Der Zugriff auf github.com/login ist für das Erstellen von Supporttickets erforderlich. Um sicherzustellen, dass Benutzende mit Supportberechtigungen Hilfe anfordern können, musst du diese Benutzende von der Einschränkung ausschließen.

Aufhebung der Einschränkung für bestimmte Benutzende

Du musst die Einschränkung für bestimmte Benutzende aufheben, die mit einem persönlichen Konto zu Open-Source-Ressourcen beitragen oder bei Issues Supporttickets erstellen müssen. Hierfür musst du dein Netzwerk so konfigurieren, dass der Header nur für Benutzende injiziert wird, die du einschränken möchtest.

Beispiele für Optionen:

Netzwerktrennung: Erstelle das Netzwerk „Work“, das den Header injiziert, und das Netzwerk „Open Source“, das den Header nicht injiziert. Beschränke den Zugriff auf das Netzwerk „Open Source“ auf Benutzende, die das Netzwerk benötigen.
Gerätegruppierung: Wenn dein Proxy oder deine Firewall authentifiziert ist, kannst du eine Gruppe von Benutzenden auswählen, die den Header nicht benötigen, und sie selektiv aus der Injektion ausschließen.

Nicht unterstützte Funktionen

Da diese Einschränkung nur für Anforderungen gilt, die über einen Proxy gesendet werden, der einen Unternehmensheader hinzufügt, unterstützen bestimmte GitHub-Features die Einschränkung nicht, um zu verhindern, dass Benutzende auf ihre persönlichen Konten zugreifen oder diese verwenden. Um zu verhindern, dass Benutzende in deinem Netzwerk auf diese Features zugreifen, musst du die im Folgenden beschriebenen Änderungen vornehmen.

Funktion	Zugeordneter Endpunkt	Hinweise
GitHub Pages	`github.io`	Dies sind in der Regel von den Benutzenden generierte Inhalte, die keine Daten akzeptieren können. Du solltest den Zugriff nicht einschränken.
GitHub Codespaces	`github.dev`	Um den Zugriff einzuschränken, blockiere den Endpunkt vollständig.
SSH-Zugriff	Port 22 auf GitHub.com	Um den Zugriff einzuschränken, blockiere den Endpunkt vollständig.
Auf GitHub gehostete Runner	Verschiedene	Um ein bestimmtes Routing zu erzwingen, verwende das private Azure-Netzwerk. Weitere Informationen findest du unter Private Netzwerktechnologie mit von GitHub gehosteten Runnern in Ihrem Unternehmen.

Endpunkte, die keine Einschränkung erfordern

Die folgenden Endpunkte unterstützen oder erfordern die Einschränkung nicht, da sie nur Daten bereitstellen und nicht akzeptieren.

*.githubusercontent.com
*.githubassets.com
WebSocket-Datenverkehr auf GitHub.com

Wie funktioniert die Einschränkung?

Wenn Benutzende bei Datenverkehr mit dem Unternehmensheader versuchen, über das Web, Git oder eine API und mithilfe eines Benutzerkontos (oder eines Tokens, das einem Benutzerkonto zugeordnet ist) auf GitHub.com zuzugreifen, das kein Mitglied des Unternehmens ist, geschieht Folgendes:

Den Benutzenden wird eine Fehlermeldung mit dem Statuscode 403 angezeigt. Weitere Informationen findest du unter Fehler, die blockierten Benutzenden angezeigt werden.
Ein business.proxy_security_header_unsatisfied-Ereignis wird in den Unternehmensüberwachungsprotokollen protokolliert. Diese Protokollereignisse weisen aufgrund von Datenschutzgründen kein actor-Feld auf, verfügen aber bei Aktivierung über ein actor_ip-Feld (siehe Anzeigen von IP-Adressen im Überwachungsprotokoll für dein Unternehmen). Um diese Ereignisse weiter zu untersuchen, kannst du die Proxyprotokolle in deiner Umgebung überprüfen.

Die folgenden Abschnitte enthalten Details zum erwarteten Verhalten, das für die Webaktivität und API-Anforderungen der Benutzenden gilt.

Webaktivität

Bei Aktivitäten auf der GitHub.com-Benutzeroberfläche schränkt der Header ein, bei welchen Konten sich Benutzende anmelden können.

Wenn sich Benutzende in deinem Netzwerk befinden, trifft Folgendes zu:

Sie können sich bei einem verwaltetes Benutzerkonto in deinem Unternehmen anmelden.
Sie können sich nicht bei einem Konto außerhalb deines Unternehmens anmelden.
Sie können den Kontowechsel nicht verwenden, um zu einem Konto außerhalb deines Unternehmens zu wechseln.

Wenn Benutzende bereits bei einem Konto außerhalb deines Unternehmens angemeldet sind (z. B. bei Anmeldung außerhalb deines Netzwerks) und ihr Gerät in deinem Netzwerk verwenden, erhalten sie eine Fehlermeldung und können erst dann auf GitHub.com zugreifen, wenn sie sich mit ihrem unternehmenseigenen Konto anmelden.

Git-Aktivität

Wenn dein Proxy so konfiguriert ist, dass der Header in HTTP(S)-Anforderungen injiziert wird, werden Benutzende in deinem Netzwerk daran gehindert, sich über HTTP(S) bei GitHub.com zu authentifizieren, es sei denn, sie sind Mitglieder deines Unternehmens. Öffentliche Leseanforderungen werden für nicht authentifizierte anonyme Benutzende nicht blockiert.

Du kannst den Unternehmensheader nicht verwenden, um Git-Aktivitäten über SSH einzuschränken. Stattdessen kannst du den Port für SSH-Anforderungen vollständig blockieren. Weitere Informationen findest du unter Nicht unterstützte Features.

API-Anforderungen

Für REST- und GraphQL-API-Datenverkehr an api.github.com (einschließlich Anforderungen über die GitHub CLI) schränkt der Header die Verwendung von Zugriffstokens ein, während Benutzende mit deinem Netzwerk verbunden sind.

Szenario	Ergebnis	Betroffene Tokentypen
Benutzende verwenden ein personal access token, das einem Konto im Besitz deines Unternehmens zugeordnet ist.	Das personal access token funktioniert in API-Anforderungen wie erwartet.	`ghp_` und `github_pat_`
Während einer bestehenden Verbindung mit deinem Netzwerk versuchen Benutzende, ein personal access token zu verwenden, das anderen Benutzenden außerhalb deines Unternehmens zugeordnet ist.	Anforderungen, für die das Token verwendet wird, werden blockiert.	`ghp_` und `github_pat_`
Während Benutzende sich nicht in deinem Netzwerk befinden und ein Konto außerhalb deines Unternehmens verwenden, melden sie sich bei einer OAuth-App an, die auf ihrem Gerät ausgeführt wird. Die Benutzenden verbinden ihr Gerät dann mit deinem Netzwerk.	OAuth-Tokens aus der App funktionieren nicht mehr.	`gho_`
Während Benutzende sich nicht in deinem Netzwerk befinden und ein Konto außerhalb deines Unternehmens verwenden, melden sie sich bei einer GitHub App an, die auf ihrem Gerät ausgeführt wird. Die Benutzenden verbinden ihr Gerät dann mit deinem Netzwerk.	Tokens aus der App funktionieren nicht mehr.	`ghu_`
Während einer bestehenden Verbindung mit deinem Netzwerk versucht eine Anwendung, eine Sitzung für Benutzende außerhalb deines Unternehmens mithilfe eines GitHub App-Aktualisierungstokens zu aktualisieren.	Bei der Aktualisierung tritt ein Fehler auf.	`ghr_`
Während einer bestehenden Verbindung mit deinem Netzwerk versucht eine Anwendung, ein Installationstoken (Token ohne Benutzeridentität, nur App-Identität) für eine Organisation außerhalb deines Unternehmens abzurufen.	Das Token funktioniert nicht.	`ghs_`

Fehler, die den blockierten Benutzenden angezeigt werden

Wenn die Einschränkung erwartungsgemäß funktioniert, werden den Benutzenden Fehlermeldungen angezeigt. In den folgenden Situationen treten Fehler auf:

Webaktivität: Ein Fehler tritt auf, wenn Benutzende daran gehindert wird, sich anzumelden oder eine vorhandene veraltete Sitzung zu verwenden.
API-Aktivität: Ein Fehler tritt auf, wenn Benutzende versuchen, ein Token zu verwenden, das anderen Benutzenden außerhalb des Unternehmens zugeordnet ist.
Installationstoken: Ein Fehler tritt auf, wenn eine Anwendung versucht, ein Installationstoken für den Zugriff auf eine Organisation oder ein Benutzerkonto außerhalb des Unternehmens zu verwenden. Bei Installationen werden nur Schreibanforderungen blockiert. Leseanforderungen werden nicht für Ressourcen außerhalb des Unternehmens blockiert. Weitere Informationen zu Installationstoken findest du unter Authentifizierung als GitHub-App-Installation.

Szenario	Fehlercode	Nachricht
Webaktivität	403	Your network administrator has blocked access to GitHub except for the `ENTERPRISE` Enterprise. Please sign in with your `_SHORTCODE` account to access GitHub.
API-Aktivität	403	Your network administrator has blocked access to GitHub except for the `ENTERPRISE` Enterprise. Please use a token for a user from the `_SHORTCODE` enterprise to access GitHub.
Installationstoken	403	Your network administrator has blocked access to GitHub except for the `ENTERPRISE` Enterprise. Only tokens for the `SHORTCODE` enterprise can access GitHub.

Fehler mit einem 400-Code deuten auf einen Fehler in deiner Konfiguration hin. Informationen hierzu finden Sie unter Problembehandlung.

Beispiel für lokale Tests

Du kannst deine Netzwerkkonfiguration lokal mit einem Webdebuggingtool testen. Dieser Abschnitt enthält ein Beispiel, in dem Fiddler verwendet wird. Beachte, dass Fiddler und andere externe Debuggingtools nicht im Bereich des GitHub-Support liegen.

Im folgenden Beispiel fügst du einige FiddlerScript-Elemente hinzu, die für jede Anforderung ausgeführt werden.

Installieren Sie Fiddler.
Konfiguriere Fiddler für das Entschlüsseln von HTTPS-Datenverkehr. Weitere Informationen findest du in der Fiddler-Dokumentation.

Navigiere in Fiddler zur Registerkarte „FiddlerScript“, und füge der OnBeforeRequest-Funktion den folgenden Code hinzu. Lege die enterpriseId-Variable auf deine Unternehmens-ID fest.

JavaScript

// Your enterprise id
var enterpriseId: String = "YOUR-ID";

 //Inject on the web UI
 if (oSession.HostnameIs("github.com")){
     oSession.oRequest.headers.Add("sec-GitHub-allowed-enterprise",enterpriseId)
     oSession["ui-color"] = "green";
 }

 // Inject on API calls
 if (oSession.HostnameIs("api.github.com")){
     oSession.oRequest.headers.Add("sec-GitHub-allowed-enterprise",enterpriseId)
     oSession["ui-color"] = "blue";
     }

 // Inject on Copilot API calls
 if (oSession.HostnameIs("githubcopilot.com")){
     oSession.oRequest.headers.Add("sec-GitHub-allowed-enterprise",enterpriseId)
     oSession["ui-color"] = "yellow";
 }

// Your enterprise id
var enterpriseId: String = "YOUR-ID";

 //Inject on the web UI
 if (oSession.HostnameIs("github.com")){
     oSession.oRequest.headers.Add("sec-GitHub-allowed-enterprise",enterpriseId)
     oSession["ui-color"] = "green";
 }

 // Inject on API calls
 if (oSession.HostnameIs("api.github.com")){
     oSession.oRequest.headers.Add("sec-GitHub-allowed-enterprise",enterpriseId)
     oSession["ui-color"] = "blue";
     }

 // Inject on Copilot API calls
 if (oSession.HostnameIs("githubcopilot.com")){
     oSession.oRequest.headers.Add("sec-GitHub-allowed-enterprise",enterpriseId)
     oSession["ui-color"] = "yellow";
 }

Klicke auf Skript speichern.

Der Header wird nun für jede der angegebenen Domänen injiziert, während die Paketerfassung aktiv ist. Um die Injektion zu aktivieren oder zu deaktivieren, kannst du die Einstellung für die Paketerfassung ändern, indem du auf Datei > Datenverkehr erfassen klickst.

Du kannst diese Injektion aktivieren und deaktivieren, um die Anmeldung mit einem unzulässigen Konto und das Herstellen einer Verbindung mit dem Netzwerk bzw. die Anmeldung bei einem unzulässigen Konto bei bestehender Verbindung mit dem Netzwerk zu simulieren.

Problembehandlung

Wenn die Headerinjektion nicht wie erwartet funktioniert, werden Fehler mit dem 400-Code angezeigt, wenn du versuchst, die betroffenen Endpunkte zu verwenden. Diese unterscheiden sich von den 403-Fehlern, die angezeigt werden, wenn das Feature erwartungsgemäß funktioniert (siehe Fehler, die blockierten Benutzenden angezeigt werden).

Im Allgemeinen treten 400-Fehler in den folgenden Situationen auf.

Der Header verwendet ein ungültiges Datenfeld oder eine ungültige Unternehmens-ID.
Der Header listet mehrere Unternehmen auf.
Die Anforderung enthält mehrere sec-GitHub-allowed-enterprise-Header.

Szenario	Fehlercode	Nachricht
Ungültiges Datenfeld oder ungültige ID	400	The enterprise named in the `sec-GitHub-allowed-enterprise` header cannot be found. Ensure that the „enterprise slug“ is entered correctly in the firewall or proxy settings. Contact your network administrator if this error persists.
Mehrere Unternehmen	400	Only one enterprise can be used with the `sec-GitHub-allowed-enterprise` header. Ensure that only a single enterprise and header is provided. If this issue persists, contact your network administrator
Mehrere Header	400	More than one `sec-GitHub-allowed-enterprise` was received. This header must be overwritten by the firewall or proxy, to ensure that only a single enterprise is granted access. If this issue persists, contact your network administrator.

Weiterführende Themen

Verwalten des Zugriffs auf GitHub Copilot im eigenen Unternehmensnetzwerk