Como restringir o acesso ao GitHub.com usando um proxy corporativo

Se você usar Enterprise Managed Users, poderá impedir que os usuários em sua rede se autentiquem GitHub.com com contas que não são membros da sua empresa. Isso ajuda a reduzir o risco de os dados da empresa serem expostos ao público.

Para impor essa restrição, você configurará seu proxy de rede ou firewall para injetar um cabeçalho nas solicitações web e de API de seus usuários para GitHub.com.

Esse recurso requer um firewall ou proxy externo. Suporte do GitHub não pode ajudar na instalação ou solução de problemas para ferramentas externas como essas. Para saber mais sobre o escopo do suporte, confira Sobre GitHub suporte.

Habilitando restrições de acesso

Este recurso não está habilitado por padrão. Um proprietário corporativo pode habilitar o recurso para sua empresa.

Navegue até sua empresa. Por exemplo, na página Enterprises em GitHub.com.
Na parte superior da página, clique em Configurações.
Em Configurações, clique em Segurança de Autenticação.
Na seção "Enterprise access restrictions", selecione Habilitar restrições de acesso corporativo.

Pré-requisitos

Você deve usar um empresa com usuários gerenciados em GitHub.com.
- Você saberá que está usando um empresa com usuários gerenciados se todos os nomes de usuário dos seus usuários estiverem acompanhados do código abreviado da sua empresa.
- Se você usar GitHub Enterprise Cloud com residência de dados, sua empresa ficará em um subdomínio dedicado de GHE.com, portanto o cabeçalho não será necessário para diferenciar o tráfego destinado aos recursos da sua empresa.
Para impor a restrição, todo o tráfego deve fluir por um proxy ou firewall. O proxy ou firewall deve:
- Ser capaz de interceptar e editar o tráfego, geralmente chamado de proxy de "quebra e inspeção"
- Oferecer suporte para injeção arbitrária de cabeçalhos
O proprietário da empresa habilitou esse recurso.

Como localizar o cabeçalho

Para impor a restrição, você injetará um cabeçalho em todo o tráfego que vai para determinados endpoints com suporte. O cabeçalho tem o formato a seguir.

sec-GitHub-allowed-enterprise: ENTERPRISE-ID

Um proprietário da empresa pode identificar a ID empresarial correta a ser usada no cabeçalho de sua empresa.

Navegue até sua empresa. Por exemplo, na página Enterprises em GitHub.com.
Na parte superior da página, clique em Configurações.
Em Configurações, clique em Segurança de Autenticação.
Na seção "Restrições de acesso da empresa", encontre o cabeçalho correspondente à sua empresa.

Usar o cabeçalho

Para ter resultados melhores, configure o proxy para injetar o cabeçalho em todo o tráfego para os pontos de extremidade com suporte a seguir.

Ponto de extremidade	Finalidade
`github.com/*`	Tráfego da Web para GitHub.com
`api.github.com/*`	Solicitações à API REST e GraphQL
`*.githubcopilot.com`	Tráfego necessário para determinadas GitHub Copilot funcionalidades

Isso impedirá que as pessoas em sua rede acessem esses pontos de extremidade com contas de usuário que não pertencem à sua empresa. Junto com esse recurso, você pode bloquear o tráfego de fora da rede configurando uma lista de IPs permitidos. Confira Como restringir o tráfego de rede para sua empresa com uma lista de permissões de IP.

Observação

O acesso a github.com/login é necessário para criar tíquetes de suporte. Para garantir que usuários com direitos de suporte possam solicitar ajuda, convém isentá-los da restrição.

Habilitando restrições de acesso para várias empresas

Os proprietários da empresa podem impor a restrição em várias contas corporativas.

Habilite o recurso para cada conta corporativa. Consulte Habilitar restrições de acesso.
Insira um cabeçalho em todo o tráfego direcionado a determinados endpoints suportados. O cabeçalho tem o formato a seguir.

sec-GitHub-allowed-enterprise: ENTERPRISE1-ID, ENTERPRISE2-ID, ENTERPRISE3-ID ... ENTERPRISE20-ID.

Os proprietários da empresa podem encontrar a ID corporativa correta a ser usada no cabeçalho de cada uma das empresas. Consulte Localizar o cabeçalho.

Observação

Atualmente, há suporte para até 20 IDs corporativas exclusivas a serem incluídas no cabeçalho.

Remover a restrição para determinados usuários

Talvez você queira remover a restrição para determinados usuários que precisam contribuir para recursos de código aberto usando uma conta pessoal ou que talvez precisem criar tíquetes de suporte em caso de problemas. Para lidar com isso, você precisa configurar sua rede para injetar o cabeçalho somente para usuários que pretende restringir.

As opções incluem:

Segregação de rede: crie uma rede "de trabalho" que injete o cabeçalho e uma rede de "código aberto" que não o faz. Limite o acesso à rede de "código aberto" aos usuários que precisam dela.
Agrupamento de dispositivos: se o proxy ou firewall é autenticado, você pode coletar um grupo de usuários que não precisam do cabeçalho e excluí-los seletivamente da injeção.

Recursos sem suporte

Como essa restrição só se aplica a solicitações enviadas por meio de um proxy que adiciona um cabeçalho corporativo, determinados GitHub recursos não dão suporte à restrição para impedir que os usuários acessem ou usem suas contas pessoais. Para impedir que os usuários em sua rede acessem esses recursos, você precisará fazer as alterações descritas abaixo.

Recurso	Endpoint associado	Observações
GitHub Pages	`github.io`	Geralmente, é um conteúdo gerado pelo usuário que não pode aceitar dados. Talvez você não queira restringir o acesso.
GitHub Codespaces	`github.dev`	Para restringir o acesso, bloqueie totalmente o ponto de extremidade.
Acesso SSH	Porta 22 em GitHub.com	Para restringir o acesso, bloqueie totalmente o ponto de extremidade.
SSH sobre HTTPS	`ssh.github.com`	Para restringir o acesso, bloqueie totalmente o ponto de extremidade.
GitHub-corredores hospedados	Vários	Para impor o roteamento específico, use a rede privada do Azure. Confira Sobre a rede privada do Azure para executores hospedados no GitHub em sua empresa.
Executores auto-hospedados	Vários	Para impor o roteamento específico, utilize um servidor proxy. Confira Utilizando servidores proxy com um executor.

Pontos de extremidade que não exigem restrição

Os pontos de extremidade a seguir não dão suporte nem exigem a restrição porque fornecem apenas dados e não os aceitam.

*.githubusercontent.com
*.githubassets.com
Tráfego de Websocket em GitHub.com

Como funciona a restrição?

Para o tráfego que inclui o cabeçalho corporativo, quando um usuário tenta acessar GitHub.com por meio da Web, Git ou API usando uma conta de usuário (ou um token associado a uma conta de usuário) que não é membro da empresa:

O usuário verá uma mensagem de erro com um código de status 403. Confira Erros exibidos para usuários bloqueados.
Um evento business.proxy_security_header_unsatisfied será registrado nos logs de auditoria da empresa. Esses eventos de log não terão o campo actor por motivos de privacidade, mas terão um campo actor_ip se habilitados (confira Exibir endereços IP no log de auditoria da sua empresa). Para investigar esses eventos mais além, você pode examinar os logs de proxy em seu ambiente.

As seções a seguir fornecem detalhes sobre o comportamento esperado que se aplica à atividade da Web e às solicitações de API dos usuários.

Atividade da Web

Para atividades na interface do GitHub.com usuário, o cabeçalho restringe as contas nas quais um usuário pode fazer login.

Enquanto um usuário está conectado à sua rede:

Pode fazer login em um conta de usuário gerenciada na sua empresa.
Não pode entrar em uma conta fora de sua empresa.
Não pode usar o seletor de conta para alternar para uma conta fora de sua empresa.

Se um usuário já estiver conectado a uma conta fora da sua empresa (por exemplo, ele se conectou enquanto estiver fora da sua rede), quando o usuário colocar seu dispositivo em sua rede, ele receberá um erro e não poderá acessar GitHub.com até entrar com sua conta corporativa.

Atividade do Git

Se o proxy estiver configurado para injetar o cabeçalho em solicitações HTTP(S), os usuários da sua rede serão impedidos de se autenticar no GitHub.com por HTTP(S), a menos que sejam membros da sua organização. Solicitações de leitura públicas não são bloqueadas para usuários anônimos não autenticados.

Você não pode usar o cabeçalho da empresa para restringir atividades do Git por SSH. Em vez disso, pode optar por bloquear totalmente a porta para solicitações SSH. Confira Recursos sem suporte.

Solicitações de API

Para o tráfego das APIs REST e GraphQL para api.github.com, incluindo solicitações por meio do GitHub CLI, o cabeçalho restringe o uso de tokens de acesso enquanto os usuários estiverem conectados à sua rede.

Cenário	Resultado	Tipos de token afetados
Um usuário usa um personal access token associado a uma conta de propriedade da sua empresa.	O personal access token funciona como esperado em solicitações de API.
`ghp_` e `github_pat_`
Enquanto estiver conectado à sua rede, um usuário tenta usar um personal access token associado a um usuário fora da sua organização.	Solicitações que usam o token são bloqueadas.
`ghp_` e `github_pat_`
Enquanto está fora de sua rede, usando uma conta fora de sua empresa, um usuário entra em uma aplicação OAuth que é executada no dispositivo dele. Em seguida, o usuário traz o dispositivo dele para dentro de sua rede.	Os tokens OAuth do aplicativo param de funcionar.	`gho_`
Enquanto estiver fora da sua rede, usando uma conta fora da sua empresa, um usuário entra em um GitHub App que é executado em seu dispositivo. Em seguida, o usuário traz o dispositivo dele para dentro de sua rede.	Os tokens do aplicativo param de funcionar.	`ghu_`
Enquanto está conectado à rede, um aplicativo tenta atualizar uma sessão para um usuário fora da sua empresa usando um GitHub App token de atualização.	A atualização falha.	`ghr_`
Enquanto está conectado à sua rede, um aplicativo tenta obter um token de instalação (um token sem uma identidade de usuário, apenas a identidade do aplicativo) para uma organização fora de sua empresa.	O token não funcionará.	`ghs_`

Erros exibidos para usuários bloqueados

Erros serão exibidos aos usuários quando a restrição estiver funcionando conforme o esperado. Ocorrem erros nas seguintes situações:

Atividade da Web: quando um usuário é impedido de entrar ou de usar uma sessão obsoleta existente.
Atividade da API: quando um usuário tenta usar um token associado a um usuário fora da empresa.
Token de instalação: quando um aplicativo tenta usar um token de instalação para acessar uma organização ou conta de usuário fora da empresa. Para instalações, somente solicitações de gravação são bloqueadas. Solicitações de leitura para recursos fora da empresa não são bloqueadas. Para saber mais sobre tokens de instalação, confira Como autenticar como uma instalação de Aplicativo GitHub.

Cenário	Código do erro	Mensagem
Atividade da Web	403	Seu administrador de rede bloqueou o acesso a GitHub, exceto à `ENTERPRISE` Enterprise. Entre com sua `_SHORTCODE` conta para acessar GitHub.
Atividade da API	403	Seu administrador de rede bloqueou o acesso a GitHub, exceto para o `ENTERPRISE` Enterprise. Use um token de um usuário da empresa `_SHORTCODE` para acessar GitHub.
Token de instalação	403	Seu administrador de rede bloqueou o acesso a GitHub, exceto à `ENTERPRISE` Enterprise. Somente tokens para a empresa "`SHORTCODE`" podem acessar GitHub.

Erros com um código 400 indicam um erro em sua configuração. Consulte Solucionar problemas.

Exemplo de teste local

Você pode testar a configuração de rede localmente usando uma ferramenta de depuração da Web. Esta seção fornece um exemplo usando o Fiddler. Observe que Fiddler e outras ferramentas externas de depuração não estão no escopo de Suporte do GitHub.

No exemplo a seguir, você adicionará FiddlerScript para execução em cada solicitação.

Instale o Fiddler.
Configure o Fiddler para descriptografar o tráfego HTTPS. Confira a documentação do Fiddler.

No Fiddler, navegue até a guia "FiddlerScript" e adicione o código a seguir à função OnBeforeRequest. Defina a variável enterpriseId para sua ID empresarial.

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";
 }

Clique em Save script.

Agora, o cabeçalho será injetado para cada um dos domínios especificados enquanto a captura de pacotes estiver ativa. Para habilitar ou desabilitar a injeção, você pode alternar a captura de pacotes clicando em File > Capture Traffic.

Você pode ativar e desativar essa injeção para simular a entrada com uma conta não permitida e, em seguida, a entrada na rede, ou pode tentar entrar em uma conta não permitida enquanto está na rede.

Solução de problemas

Se a injeção de cabeçalho não estiver funcionando conforme o esperado, você verá erros com um código 400 ao tentar usar pontos de extremidade afetados. Eles são diferentes dos erros 403 exibidos quando o recurso está funcionando conforme o esperado (confira Erros exibidos para usuários bloqueados).

De modo geral, erros 400 ocorrem nas situações a seguir.

O cabeçalho usa um campo de dados dinâmico ou ID de empresa inválido.
O cabeçalho lista mais de uma empresa.
A solicitação contém vários cabeçalhos sec-GitHub-allowed-enterprise.

Cenário	Código do erro	Mensagem
ID ou slug inválido	400	A empresa nomeada no cabeçalho `sec-GitHub-allowed-enterprise` não pode ser encontrada. Certifique-se de que o "campo de dados dinâmico da empresa" está inserido corretamente nas configurações de firewall ou proxy. Entre em contato com o administrador da rede se o erro persistir.
Mais de uma empresa	400	Somente uma empresa pode ser usada com o cabeçalho `sec-GitHub-allowed-enterprise`. Verifique se apenas uma empresa e um cabeçalho são fornecidos. Se o problema persistir, entre em contato com o administrador da rede.
Vários cabeçalhos	400	Mais de um `sec-GitHub-allowed-enterprise` foi recebido. Esse cabeçalho deve ser substituído pelo firewall ou proxy para garantir que apenas uma empresa receba acesso. Se o problema persistir, entre em contato com o administrador da rede.

Leitura adicional

Gerenciando o acesso do GitHub Copilot à rede da sua organização