Einschränken des Zugriffs auf .com mithilfe eines Unternehmensproxys

Wenn du Enterprise Managed Users verwendest, kannst du verhindern, dass sich Benutzende in deinem Netzwerk mit Konten bei .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 .com eingefügt wird.

Für dieses Feature ist eine externe Firewall oder ein Proxy erforderlich. -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 Support.

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

• Du musst ein Unternehmen mit verwalteten Benutzer*innen auf .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 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
• muss dir Zugriff auf dieses Feature gewährt haben.

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--allowed-enterprise: ENTERPRISE-ID

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

1. Klicke in der oberen rechten Ecke von auf dein Profilfoto und dann auf Dein Unternehmen.
2. Klicke oben auf der Seite auf Settings.
3. Wähle unter Einstellungen die Option Authentifizierungssicherheit aus.
4. 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.

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

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.

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.

Da diese Einschränkung nur für Anforderungen gilt, die über einen Proxy gesendet werden, der einen Unternehmensheader hinzufügt, unterstützen bestimmte -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.

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

• *.usercontent.com
• *.assets.com
• WebSocket-Datenverkehr auf .com

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 .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.

Bei Aktivitäten auf der .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 .com zugreifen, wenn sie sich mit ihrem unternehmenseigenen Konto anmelden.

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 .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.

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

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 -App-Installation.

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

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 -Support liegen.

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

1. Installieren Sie Fiddler.

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

3. 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(".com")){
        oSession.oRequest.headers.Add("sec--allowed-enterprise",enterpriseId)
        oSession["ui-color"] = "green";
    }
   
    // Inject on API calls
    if (oSession.HostnameIs("api..com")){
        oSession.oRequest.headers.Add("sec--allowed-enterprise",enterpriseId)
        oSession["ui-color"] = "blue";
        }
   
    // Inject on Copilot API calls
    if (oSession.HostnameIs("copilot.com")){
        oSession.oRequest.headers.Add("sec--allowed-enterprise",enterpriseId)
        oSession["ui-color"] = "yellow";
    }
   

4. 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.

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--allowed-enterprise-Header.

• Verwalten des Zugriffs auf Copilot im eigenen Unternehmensnetzwerk