Defina suas configurações e políticas corporativas do GitHub Enterprise Cloud
Em nossos dois últimos guias, estabelecemos sua conta corporativa e escolhemos um modelo de usuário. Agora, é hora de definir as configurações e políticas que se aplicam a todo o trabalho de desenvolvimento. Configurações e políticas não aplicadas em nível empresarial são gerenciadas em cada organização. Isso permite gerenciar o equilíbrio desejado entre administração centralizada e distribuída. A maioria das políticas, opções de configuração e configurações no nível empresarial tem um equivalente no nível da organização, embora ambos também tenham vários itens de configuração e configurações exclusivos.
É uma prática recomendada revisar suas políticas e configurações com todas as partes interessadas, incluindo membros de desenvolvimento, segurança, operações e quaisquer outras equipes afiliadas. Você deseja otimizar a colaboração e a flexibilidade que seus usuários finais precisam para realizar seu trabalho, bem como os requisitos de conformidade e segurança necessários para proteger sua empresa.
As políticas empresariais são divididas por tópico. Destacaremos alguns dos itens mais importantes para cada tópico neste guia, ignorando os itens configurados com menos frequência. Consulte a documentação da política empresarial para obter detalhes abrangentes sobre essas configurações.
Ao explorar a configuração do GitHub Enterprise Cloud (GHEC), você observará configurações para GitHub Copilot, GitHub Actions, GitHub Codespaces e GitHub Projects. Discutiremos isso no próximo guia, quando explorarmos a cobrança, já que alguns são licenciados separadamente do GHEC, portanto, as configurações podem ter outras implicações de cobrança.
Mas primeiro, ouviremos da Fidelity como eles padronizaram a criação de repositórios para equilibrar a colaboração com a segurança e confirmaram suas decisões de configuração com as partes interessadas em toda a empresa.
Neste guia, você aprenderá:
As diversas políticas disponíveis para configurar sua empresa ou organização, incluindo permissões básicas, a capacidade de criar e criar fork de repositórios e muito mais; e orientação para defini-los quando aplicável
Configurações e recursos do Enterprise, incluindo relatórios de conformidade e suporte
Uma observação sobre “Sem política”
As políticas empresariais sempre oferecem a opção “Sem política”, que permite que cada organização defina sua própria política para aquele item de configuração específico. Isso não significa que você não esteja definindo ativamente uma política, mas sim que não está optando por definir a mesma política em todos os níveis da empresa. “Sem política” é útil para empresas que possuem diversas organizações, cada uma com necessidades de configuração diferentes.
Políticas de repositório
As políticas de repositório estão relacionadas à criação e à visibilidade dos seus repositórios e abrangem algumas das configurações mais confidenciais da sua empresa. Certifique-se de revisar esses itens cuidadosamente, seja no nível empresarial ou em cada nível organizacional.
Permissões básicas de acesso ao repositório
As permissões básicas são as permissões de acesso ao repositório padrão herdadas concedidas a todos os membros plenos (não colaboradores externos) em sua empresa e podem ser um atalho útil para uma cultura de innersource. Elas definem um nível básico de acesso para todos os usuários e podem ser usados para incentivar a visibilidade e a colaboração sem a necessidade de microgerenciar atribuições de acesso individual e de equipe para cada repositório recém-criado. É claro que você também deve considerar se é apropriado que todas as suas organizações tenham o mesmo nível de abertura padrão ou se, em vez disso, você deve definir políticas separadas por organização.
As opções de permissão básica incluem:
Sem permissão: nenhuma permissão básica padrão é concedida em repositórios para membros da organização. Você precisará gerenciar a visibilidade dos repositórios privados por meio da atribuição direta de equipes e usuários, em vez de uma permissão básica.
Leitura: os membros da organização receberão acesso de leitura a todos os repositórios da organização por padrão. Esta é efetivamente uma configuração de innersource. Ele permite que todos os membros da organização visualizem, clonem ou criem pull requests, mas não faz o merge.
Gravação, Admin: os membros da organização receberão acesso de gravação ou de administração a todos os repositórios da organização. Esses padrões são altamente permissivos e não recomendados para empresas.
Política de criação de repositório
Quem você permitirá criar repositórios em suas organizações? Essa é outra política crítica a considerar, e cada opção vem com o seu próprio conjunto de considerações:
Os membros podem criar repositórios: se definidos no nível empresarial, os usuários poderão criar repositórios em organizações da empresa usando os tipos de visibilidade permitidos para sua empresa. As empresas da EMU não poderão selecionar repositórios públicos. Os proprietários da organização sempre poderão criar todas as visibilidades possíveis dos repositórios, independentemente do que você selecionar aqui.
Desabilitado: isso impedirá que os usuários finais criem repositórios na empresa, embora os proprietários da organização ainda possam criar repositórios. As empresas usam essa configuração de política porque planejam usar um processo automatizado para criar repositórios a partir de configurações padrão.
Bloquear a criação de repositórios de namespaces de usuários: esta opção está disponível apenas para empresas da EMU. Os repositórios de namespace de usuário da EMU são repositórios de propriedade de uma conta de usuário específica da EMU, não de uma organização. Algumas empresas optam por aproveitar esses espaços pessoais como uma área restrita para desenvolvedores. Outros optam por bloqueá-los para manter o desenvolvimento contido apenas no espaço da organização, onde as políticas empresariais e organizacionais podem ser aplicadas de forma consistente.
Lembre-se de que os criadores de repositórios recebem automaticamente permissões administrativas nos repositórios que criam.
Definimos políticas de segurança por toda a empresa para garantir que cada repositório esteja adequadamente seguro, e usamos políticas de nível da organização para fornecer diferenciação ainda mais refinada do código de acesso e corporativo. Desenvolvemos um portal de autoatendimento para impulsionar a criação de repositórios para que possamos ter certeza de que esses padrões sejam aplicados de forma universal e estejam em conformidade. Essa abordagem nos permite equilibrar as necessidades de colaboração e segurança.
Política de fork de repositório (e uma nota sobre criar fork)
Um fork é um novo repositório que compartilha configurações de código e visibilidade com o repositório upstream original. Os forks são frequentemente usados para iterar ideias ou mudanças antes de serem propostas de volta ao repositório upstream, como em projetos de código aberto ou quando um usuário não tem acesso de gravação ao repositório upstream. Eles foram originalmente projetados pela comunidade para uso em código aberto e outros cenários de baixa confiança, onde o gerenciamento de permissões de gravação seria difícil. Por esse motivo, os forks não são necessariamente os mais adequados para o contexto empresarial, onde você pode verificar a identidade do usuário e gerenciar facilmente as permissões usando seu provedor de identidade (IdP), equipes e outras automações. No entanto, algumas equipes ainda usam forks para oferecer suporte a tipos específicos de fluxos de trabalho ou ferramentas. Uma política de fork de repositório ajuda a controlar onde esses forks podem ser criados para que você possa mantê-los organizados e seguros.
Observação para clientes EMU: as configurações da política de fork serão substituídas pela política de criação de repositório que acabamos de discutir se ela estiver configurada para bloquear a criação de repositórios de namespace de usuário. Nesse caso, os membros também não terão permissão para criar fork de um repositório em suas contas de usuário, independentemente da sua política de fork de repositório.
As opções para locais de fork de repositório permitidos são:
Organizações dentro desta empresa: os membros podem criar fork de um repositório para qualquer organização à qual tenham acesso dentro da empresa.
Dentro da mesma organização: os membros podem criar fork de um repositório somente dentro da mesma organização que possui o repositório pai. Essa opção mantém total visibilidade dos forks, em vez de espalhá-los por vários locais diferentes.
Contas de usuário e dentro da mesma organização: os membros podem criar fork de um repositório na mesma organização que seu repositório pai, bem como no namespace do usuário, mas isso apresentará diferenças de acordo com os modelos de usuário. Para empresas da EMU, este é o namespace da conta de Enterprise Managed User, que está dentro da empresa e é controlado por ela. Para empresas não pertencentes à EMU, este é o namespace da conta do usuário individual, que está fora da empresa e de seu controle.
Contas de usuários e organizações dentro desta empresa: essa configuração tem a mesma distinção entre empresas da EMU e de fora da EMU para criar fork de contas de usuários. As empresas da EMU permitem criar fork no namespace da conta de Enterprise Managed User e as empresas não pertencentes à EMU permitem criar fork no namespace da conta do usuário individual. Além disso, os membros podem criar fork de um repositório em qualquer organização dentro desta empresa, não apenas na organização proprietária do repositório pai.
Contas de usuário: para empresas da EMU, os membros podem criar fork de um repositório apenas no namespace da conta de Enterprise Managed User. Para empresas não pertencentes à EMU, os membros podem criar fork de um repositório apenas no namespace da conta do usuário individual . Nos dois casos, os membros não podem criar fork em uma organização. Isso manterá seus espaços da organização livres de forks, mas ainda os permitirá.
Em todos os lugares: os membros podem criar fork de repositórios em qualquer lugar, incluindo contas de usuários, namespaces e qualquer organização, mesmo fora da empresa, para empresas não pertencentes à EMU.
Política de colaboradores externos
Um colaborador externo é alguém que tem acesso a um ou mais repositórios da organização por meio de convite direto, mas não é explicitamente membro da organização, como um consultor ou funcionário temporário. Aprenderemos mais sobre eles no guia sobre equipes, funções e usuários.
Essa política permite selecionar qual nível de administrador pode convidar colaboradores externos para seus repositórios: proprietários de empresas, proprietários de organizações ou administradores de repositórios.
As empresas da EMU não verão essa política, pois todos os utilizadores devem ser provisionados a partir do IdP conectado e não podem ser criados por proprietários ou administradores.
Embora exigir que os proprietários de empresas ou organizações convidem colaboradores externos centralize a administração e o controle sobre o acesso dos colaboradores, isso também pode causar gargalos. Por outro lado, permitir que administradores de repositórios individuais gerenciem esses convites concede permissão de convite a mais usuários, mas pode significar um controle mais flexível sobre quem recebe acesso de colaborador.
Política de nome de branch padrão
Essa política define o nome do branch padrão para todos os repositórios em todas as suas organizações. Talvez você queira alterar o nome padrão devido a diferentes fluxos de trabalho ou porque suas integrações exigem um nome de branch padrão específico.
Ao contrário de algumas outras políticas, isso pode ser substituído no nível de repositório, a menos que você selecione Enforce across this enterprise.
Mudança, exclusão e transferência de visibilidade do repositório e políticas de exclusão de emissão
Todas essas políticas regem de forma semelhante se você deseja permitir que usuários com permissões de administrador de repositório executem essas ações potencialmente destrutivas ou perturbadoras ou se deseja limitar essas ações aos proprietários da organização, que sempre terão esses recursos administrativos para todos os repositórios. Habilite essa opção para permitir que os administradores do repositório executem cada tipo de atividade ou desabilite-a para manter a atividade restrita aos proprietários da organização.
Durante o processo inicial de implementação do GitHub, criamos outra organização do GitHub fora da produção para testar nossas políticas e configurações. Como as partes interessadas estão espalhadas pela empresa, convidamos diversos representantes de diferentes equipes da organização, onde eles puderam testar vários processos de automação e fazer experimentos com a plataforma conforme a configurávamos. Eles formaram um grupo de teste das partes interessadas para coletar feedback, que foi fornecido à equipe de implementação do GitHub para ajudar a refinar nossas políticas e configurações antes de disponibilizá-las para o restante da organização.
Políticas do GitHub Projects
As políticas desta seção regem o uso de Projetos GitHub, a ferramenta de gerenciamento de projetos integrada e centrada no desenvolvedor do GitHub. Como opção, os administradores podem desabilitar o uso do Projetos em uma ou mais organizações e controlar as alterações de visibilidade do projeto. Isso pode ajudar com implementações em fases ou se você quiser permitir o uso de outras ferramentas de gerenciamento de projetos.
Configuração do GitHub Connect
GitHub Connect é um serviço que habilita determinados recursos ao permitir o compartilhamento limitado de dados entre o GitHub Enterprise Cloud e o GitHub Enterprise Server, a oferta empresarial auto-hospedada do GitHub. Se você usa GitHub Enterprise Server, você pode habilitar e configurar esta funcionalidade nesta seção.
Configurações Enterprise
Perfil Enterprise
Nesta seção, você pode definir e alterar o nome de exibição, a descrição, o URL do site e a localização da sua empresa. Essas informações são mostradas a todos os membros da empresa na página de perfil da conta Enterprise.
Há também uma segunda guia nesta página onde é possível definir rodapés, que serão exibidos aos usuários na parte inferior de todas as páginas no contexto Enterprise conectado. Eles podem ser usados para exibir notificações legais necessárias ou outros dados que devem estar permanentemente visíveis para o usuário do GHEC.s. Como acontece com qualquer texto de anúncio, tenha cuidado ao usá-los para exibir apenas as informações necessárias para evitar ruído visual extra.
Domínios verificados e aprovados
A verificação e aprovação de domínios controlam quais domínios têm permissão para receber notificações por email de sua empresa ou organização. A verificação de domínio requer acesso ao registro DNS do domínio (ou seja, domínios de propriedade de sua empresa), enquanto a aprovação de domínio pode ser usada para domínios que você não controla, mas que ainda deseja incluir na lista de permissões, como aqueles de fornecedores ou contratados.
Os domínios verificados (não aprovados) também exibirão um selo Verificado no perfil de cada organização que os lista como o URL nas informações do perfil da organização. Isso pode adicionar legitimidade pública adicional às páginas da sua organização.
Nenhum desses recursos é muito útil para empresas e organizações da EMU, considerando os endereços de e-mail padronizados que usam e a falta de presença pública, por isso a maioria das empresas da EMU não configura a verificação de domínio.
Anúncios
Nesta seção, é possível criar banners de anúncios globais, que aparecerão no topo de cada página corporativa. Para evitar fadiga de alerta e ruído visual, recomendamos que você utilize esse recurso apenas quando for absolutamente necessário e utilize as opções de data de validade e rejeição sempre que possível.
Suporte
Por padrão, o seu plano GHEC inclui suporte Enterprise. O suporte Enterprise fornece suporte baseado em tíquetes 24 horas por dia, 7 dias por semana, composto por engenheiros de suporte do GHEC. Você também pode ter adquirido ou ter direito ao suporte premium, que inclui alguns benefícios adicionais.
Embora qualquer usuário do GitHub possa criar tíquetes de suporte, proprietários de empresas e gerentes de cobrança têm automaticamente um direito de suporte, que lhes permite criar, visualizar e comentar em tickets de suporte associados à sua conta Enterprise. Os proprietários de empresas também podem adicionar esses direitos de suporte a até 20 usuários regulares em organizações pertencentes à sua conta Enterprise.
Os Administradores empresariais e usuários com direito a suporte podem abrir e gerenciar seus tíquetes de suporte do GitHub por meio do portal de suporte Enterprise.
Relatórios de conformidade
Sua equipe de segurança precisará se manter atualizada com a documentação de conformidade mais recente enquanto você analisa, integra e mantém o GitHub como um de seus parceiros fornecedores. Fornecemos nossos relatórios SOC mais recentes, atestados de terceiros e procedimentos de operações de negócios autorrelatados como documentos de autoatendimento na página de administração corporativa para download.
A seguir: Gerencie seus serviços baseados em faturamento, licenciamento e consumo
Com muitas de nossas políticas essenciais e permissões padrão agora configuradas, é hora de dar uma olhada nas configurações relacionadas a serviços de cobrança, licenciamento e consumo, como GitHub Actions e Codespaces.