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

Se você usa Enterprise Managed Users, pode impedir que os usuários da rede se autentiquem no GitHub.com usando contas que não são membros de 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 à API dos usuários para o GitHub.com.

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

Solicitar acesso

Esse recurso não fica habilitado por padrão e, no momento, está disponível apenas para empresas que pagam com fatura.

• Se você paga com fatura, para solicitar o acesso, entre em contato com seu gerente de conta da equipe de Vendas do GitHub.
• Se você paga com cartão de crédito ou PayPal, esse recurso não está disponível no momento.

Pré-requisitos

• Você precisa usar um empresa com usuários gerenciados no GitHub.com.
  • Você saberá que está usando um empresa com usuários gerenciados se o código curto da sua empresa for acrescentado a todos os nomes de usuário dos seus usuários.
  • Se você usa GitHub Enterprise Cloud com residência de dados, sua empresa reside em um subdomínio dedicado do GHE.com, portanto, o cabeçalho não é necessário para diferenciar o tráfego para os recursos da 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"
  • Dar suporte à injeção arbitrária de cabeçalho
• Sua equipe de conta da GitHub precisa ter concedido a você acesso a 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 pontos de extremidade 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.

1. No canto superior direito do GitHub, selecione sua foto de perfil e depois Sua empresa.
2. Do lado esquerdo da página, na barra lateral da conta empresarial, clique em Configurações.
3. Em Configurações, clique em Segurança da autenticação.
4. Na seção "Enterprise access restrictions", encontre o cabeçalho de sua empresa. Essa seção fica visível apenas para empresas com o recurso habilitado.

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 Web para o GitHub.com
api.github.com/*	Solicitações à API REST e GraphQL
*.githubcopilot.com	Tráfego necessário para determinados recursos do GitHub Copilot

Isso impedirá que as pessoas em sua rede acessem esses pontos de extremidade com contas de usuário que não pertencem à 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.

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 se aplica apenas a solicitações enviadas por meio de um proxy que adiciona um cabeçalho empresarial, determinados recursos do GitHub não dão suporte à restrição para impedir que os usuários acessem ou usem suas contas pessoais. Para impedir que usuários em sua rede acessem esses recursos, você precisará fazer as alterações descritas abaixo.

Recurso	Ponto de extremidade 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 no GitHub.com	Para restringir o acesso, bloqueie totalmente o ponto de extremidade.
Executores hospedados no GitHub	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.

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 no GitHub.com

Como funciona a restrição?

Para o tráfego que inclui o cabeçalho da empresa, quando um usuário tenta acessar o GitHub.com pela 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 usuário do GitHub.com, o cabeçalho restringe em quais contas um usuário pode entrar.

Enquanto está em sua rede, um usuário:

• Pode entrar em um conta de usuário gerenciada em 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á está conectado a uma conta fora de sua empresa (por exemplo, ele se conectou enquanto estava fora da rede), quando ele coloca o dispositivo dele em sua rede, recebe um erro e não pode acessar o GitHub.com até entrar com sua conta empresarial.

Atividade do Git

Se o proxy está configurado para injetar o cabeçalho em solicitações HTTP(S), os usuários em sua rede são impedidos de autenticar no GitHub.com por HTTP(S), a menos que sejam membros de sua empresa. 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 de API REST e GraphQL para api.github.com, incluindo solicitações pela GitHub CLI, o cabeçalho restringe o uso de tokens de acesso enquanto os usuários estão 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.	Os personal access token funciona conforme o esperado em solicitações à API.	ghp_ e github_pat_
Enquanto está conectado à sua rede, um usuário tenta usar um personal access token associado a um usuário fora de sua empresa.	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 está fora de sua rede, usando uma conta fora de sua empresa, um usuário entra em um GitHub App que é executado no dispositivo dele. 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 à sua rede, um aplicativo tenta atualizar uma sessão para um usuário fora de sua empresa usando um token de atualização do GitHub App.	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	O administrador de rede bloqueou o acesso ao GitHub exceto para o ENTERPRISE Enterprise. Entre com sua conta do _SHORTCODE para acessar o GitHub.
Atividade da API	403	O administrador de rede bloqueou o acesso ao GitHub exceto para o ENTERPRISE Enterprise. Use um token para um usuário do _SHORTCODE Enterprise para acessar o GitHub.
Token de instalação	403	O administrador de rede bloqueou o acesso ao GitHub exceto para o ENTERPRISE Enterprise. Somente tokens para o "SHORTCODE" Enterprise podem acessar o 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 o Fiddler e outras ferramentas de depuração externas não estão no escopo do Suporte do GitHub.

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

1. Instale o Fiddler.

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

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

4. 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 uma ID empresarial ou slug 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. Verifique se o "slug da empresa" foi 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

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