Escolha um modelo de acesso de usuário do GitHub Enterprise Cloud
O GitHub Enterprise Cloud (GHEC) dá suporte a dois modelos distintos de acesso de usuário: ambos dão acesso aos mesmos recursos excelentes e à facilidade de hospedagem, mas cada um foi projetado para facilitar diferentes tipos de fluxos de trabalho e proteções de segurança.
Você precisará selecionar aquele que melhor atende às suas necessidades de negócio durante a criação inicial da conta Enterprise, por isso é importante compreender ambos. Como veremos em breve, cada modelo usa um tipo diferente de conta de usuário que não é mutuamente intercambiável. Mudar de uma conta para outra posteriormente não é simples e requer ferramentas de migração e um processo adicional para migrar o histórico do usuário.
Queremos tornar o processo de adoção com GHEC perfeito, então vamos explorar os prós e os contras de cada modelo de acesso para ajudar você a escolher o modelo certo para suas necessidades desde o início. Ao longo do caminho, ouviremos o que influenciou a adoção de usuários padrão pela Philips e por que a Travelport optou pelos EMUs.
Neste guia, você aprenderá:
Os dois tipos de modelos de usuário disponíveis no GHEC: Enterprise Managed User (EMU) e padrão
As vantagens e desvantagens de usar cada modelo
Orientação para selecionar o modelo que melhor se adapta às necessidades do seu negócio
Modelo padrão do GHEC, ou “Traga sua própria conta”
O modelo padrão enfatiza a conexão com as partes públicas e de código aberto do GitHub.com. Como o nome sugere, os usuários trazem suas próprias contas pessoais para trabalhar, da mesma forma que usariam seu telefone pessoal, laptop ou outro dispositivo. Eles são os proprietários da conta e ela os acompanha à medida que ingressam, contribuem e saem de organizações e participam da comunidade GitHub, não apenas durante seu emprego em uma empresa ou trabalho em um determinado projeto.
As empresas e suas organizações vinculam essas contas e usam identidades SAML para autenticar o acesso aos seus recursos privados. Em seguida, com um provedor de identidade (IdP) compatível e configuração do GitHub, é possível usar o System for Cross-domain Identity Management (SCIM) para usar ainda mais associações de identidade de local de trabalho vinculadas para conceder ou encerrar o acesso a esses recursos protegidos automaticamente.
O modelo padrão também permite adicionar usuários externos como colaboradores externos a repositórios específicos com determinadas permissões apenas para esses repositórios. Esses usuários externos que usam suas contas pessoais do GitHub estão isentos de quaisquer requisitos de autenticação SAML impostos aos membros normais.
Existem também algumas vantagens e desvantagens ao usar o modelo padrão. As empresas não podem impor ou padronizar requisitos relacionados à conta, como obrigar formatos de nome de usuário, e-mails ou nomes de exibição. Em outras palavras, em vez de um formato corporativo comum para nomes de usuário, os funcionários usarão qualquer nome de usuário do GitHub que escolherem, possivelmente muitos anos antes de ingressarem na sua organização. A empresa só pode controlar o comportamento relacionado à política de seus usuários membros e colaboradores neste modelo e, mesmo assim, apenas o comportamento que ocorre no contexto da conta Enterprise e de suas organizações. O que o usuário faz no contexto de sua própria conta ou de outras organizações e repositórios não empresariais não está sujeito aos controles da empresa.
O modelo padrão também permite que repositórios públicos e privados sejam hospedados na mesma organização empresarial, a menos que sejam explicitamente desativados pela política. Essa flexibilidade pode ser fundamental para a participação no código aberto, mas algumas empresas optam por proibir os seus utilizadores de hospedar repositórios públicos para manter uma fronteira mais clara entre o privado e o público.
O modelo padrão pode ser uma boa opção se você atender a alguns ou todos estes critérios:
Você exige que os desenvolvedores interajam perfeitamente com as comunidades públicas e de código aberto do GitHub como parte de seu trabalho diário.
Você precisa adicionar facilmente colaboradores externos aos seus repositórios sem estar sujeito a requisitos de autenticação SAML ou precisar fazer parte de um diretório IdP centralizado.
Você faz uso intenso de repositórios públicos ou recursos semelhantes, como GitHub Gists ou páginas e discussões públicas.
Optamos por usar os usuários padrão do GitHub Enterprise porque queríamos facilitar ao máximo a colaboração externa. Consideramos usar EMUs, mas o código aberto também é importante para nós, e nossos desenvolvedores precisariam usar contas diferentes para suas atividades de código aberto.
Modelo Enterprise Managed User (EMU)
O modelo enterprise managed user (EMU) prioriza o controle empresarial centralizado de uma conta corporativa padronizada de um IdP corporativo. O modelo EMU usa contas GitHub de propriedade da empresa somente para trabalho que operam exclusivamente dentro dos limites de uma conta Enterprise.
Quando um usuário ingressa na sua empresa e recebe acesso ao GHEC, ele obtém uma conta de trabalho de EMU que funciona e é visível apenas na conta Enterprise da sua empresa. Quando ele sai da sua empresa ou perde o acesso ao GHEC, essa conta de trabalho de EMU também é suspensa. O ciclo de vida completo dessas contas, incluindo autenticação e provisionamento, é gerido por um IdP compatível, como o Microsoft Entra ID (anteriormente Azure Ative Directory ou Azure AD), Okta ou PingFederate. A empresa pode padronizar as informações da conta de EMU, incluindo formatação de nome de usuário, endereços de e-mail e nomes de exibição, o que oferece maior transparência e relatórios. Com o requisito estrito de suporte de conta do IdP para contas corporativas, colaboradores externos não podem ser convidados da mesma forma que no modelo de usuário padrão. Todos os usuários, até mesmo convidados, precisam ser inseridos usando o provisionamento de diretório IdP.
Além de fornecer mais padronização, o modelo EMU também adiciona proteções contra tornar conteúdo privado publicamente visível, como enviar acidentalmente para repositórios públicos do GitHub.com. As empresas da Enterprise Managed User não apenas impedem a criação de repositórios públicos, mas os usuários da Enterprise Managed User não podem realizar ações do tipo efetuar push, como enviar, marcar com estrela ou criar problemas ou pull requests em repositórios fora de sua conta Enterprise. No entanto, os usuários EMU têm acesso total de leitura para visualizar e clonar os repositórios públicos do GitHub.com. Embora as contas EMU não possam ser utilizadas para atividades de escrita de código aberto, a contrapartida dessas barreiras de proteção adicionais é uma divisão mais rigorosa entre empresa e código aberto.
O modelo EMU pode ser uma boa opção se você atender a alguns ou todos esses critérios:
Os requisitos de segurança priorizam uma separação entre a comunidade pública do GitHub.com e o conteúdo da sua empresa por meio de uma conexão com código aberto.
O modelo EMU é compatível com o seu IdP (Microsoft Entra ID, Okta, PingFederate) e você deseja padronizar e gerenciar centralmente as contas GitHub de seus usuários como contas de trabalho especializadas apenas para uso no contexto empresarial.
Você não exige (ou deseja) que colaboradores fora do seu IdP possam ser adicionados diretamente a repositórios específicos e, em vez disso, provisionará esses usuários como contas normais ou de convidados em seu diretório do IdP.
Você não precisa de repositórios públicos ou outros recursos públicos, como GitHub Gists ou páginas ou discussões públicas.
Se os seus desenvolvedores criarem e mantiverem regularmente código-fonte aberto como parte do trabalho diário, o modelo de usuário padrão poderá ser o melhor. No entanto, se você precisar de controle total das contas de seus desenvolvedores e de uma separação concreta entre a comunidade de código aberto e o código de sua empresa, os EMUs serão um modelo de usuário mais adequado.
Mudamos para o modelo privado há alguns anos, e os ataques cibernéticos à nossa plataforma dispararam de 1,6 bilhão por trimestre para quase 200 bilhões quando começamos a comercializar nossas inovações para viagens, então a segurança foi um grande motivador para escolhermos o modelo de usuário EMU.
Queríamos fazer o shift-left da segurança e escolhemos o GHEC com EMUs, porque ele nos permite sincronizar com o Microsoft Entra ID para automatizar a integração, a exclusão e as permissões de nossos 1.600 usuários. Esses usuários não são apenas desenvolvedores, são equipes de operações e outras pessoas que precisam de acesso, e a capacidade de gerenciar tudo isso diretamente do nosso provedor de gerenciamento de identidade foi decisiva. Temos mais de 8.000 repositórios em mais de 60 organizações, por isso usamos 260 equipes para fornecer as permissões detalhadas necessárias para promover o innersource e, ao mesmo tempo, atender aos nossos rigorosos requisitos de segurança.
A seguir: Estratégias para usar organizações no GitHub Enterprise Cloud
Na primeira etapa deste roteiro de aprendizagem, aprendemos tudo sobre os componentes estruturais do GHEC e fizemos a simples recomendação de que você se limite a uma única organização para reduzir a sobrecarga administrativa, mas entendemos que essa não é uma solução única. Para grandes empresas e empresas com determinados requisitos de negócios, pode ser necessária uma configuração de múltiplas organizações. Na próxima etapa, exploraremos as considerações envolvidas e apresentaremos algumas estratégias para usar várias organizações em sua conta Enterprise.