Sobre este guia
Este guia descreve as mudanças de maior impacto que você pode fazer para aumentar a segurança da conta. Cada seção descreve uma alteração que você pode fazer em seus processos para melhorar a segurança. As mudanças de maior impacto estão listadas primeiro.
Qual o risco?
A segurança da conta é fundamental para a segurança da sua cadeia de suprimento. Se um invasor conseguir tomar a sua conta em GitHub Enterprise Cloud, ele poderá fazer alterações maliciosas no seu código ou no processo de compilação. Assim, seu primeiro objetivo deve ser dificultar que alguém assuma o controle de sua conta e das contas de outros membros de sua organização ou empresa.
Centralizar autenticação
Se você é proprietário de uma empresa ou uma organização, configure a autenticação centralizada com o SAML. Embora você possa adicionar ou remover integrantes manualmente, é mais simples e mais seguro configurar um logon único (SSO) e SCIM entre GitHub Enterprise Cloud e seu provedor de identidade (IdP) SAML. Isso também simplifica o processo de autenticação para todos os integrantes da sua empresa.
Você pode configurar a autenticação SAML para uma conta corporativa ou da organização. Com o SAML, você pode conceder acesso às contas pessoais dos membros de sua empresa ou organização no GitHub por meio de seu IdP, ou você pode criar e controlar as contas que pertencem à sua empresa usando o Enterprise Managed Users. Para saber mais, confira Sobre o gerenciamento de identidades e acesso.
Depois de configurar a autenticação do SAML, quando os integrantes solicitarem acesso aos seus recursos, eles serão direcionados para o seu fluxo de SSO para garantir que sejam reconhecidos pelo seu IdP. Se não forem reconhecidos, o seu pedido será recusado.
Alguns IdPs são compatíveis com um protocolo denominado SCIM, que pode prover ou desprovisionar automaticamente o acesso em GitHub Enterprise Cloud quando você fizer alterações no seu IdP. Com o SCIM, você pode simplificar a administração à medida que a sua equipe cresce, e você pode revogar rapidamente o acesso às contas. O SCIM está disponível para organizações individuais em GitHub Enterprise Cloud, ou para empresas que usam Enterprise Managed Users. Para saber mais, confira Sobre o SCIM para organizações.
Configurar autenticação de dois fatores
Note
A partir de março de 2023, o GitHub exigiu que todos os usuários que contribuem com código do GitHub.com habilitem uma ou mais formas de autenticação de dois fatores (2FA). Se você estiver em um grupo qualificado, deve ter recebido um email de notificação quando esse grupo foi selecionado para inscrição, marcando o início de um período de registro de 45 dias para o 2FA. E você deve ter visto banners solicitando seu registro no 2FA no GitHub.com. Se você não recebeu uma notificação, é porque não fazia parte de um grupo de quem é exigido habilitar o 2FA, embora seja altamente recomendável.
Para obter mais informações sobre a distribuição de registro 2FA, confira esta postagem no blog.
A melhor maneira de melhorar a segurança de suas contas é configurar a autenticação de dois fatores (2FA). As senhas por si só podem ser comprometidas por serem adivinhadas, por serem reutilizadas em outro local que foi comprometido, ou por engenharia social, como phishing. A 2FA dificulta muito mais o comprometimento das suas contas, mesmo que um invasor tenha sua senha.
Como prática recomendada, para garantir segurança e um acesso confiável à sua conta, você sempre deve ter pelo menos duas credenciais com um segundo fator registradas em sua conta. Credenciais extras garantem que, mesmo que você perca o acesso a uma credencial, você não ficará impedido de acessar sua conta.
Além disso, você deve preferir chaves de acesso e chaves de segurança em vez de aplicativos autenticadores (chamados de de aplicativos TOTP) e evitar o uso de SMS sempre que possível. Os aplicativos 2FA e TOTP baseados em SMS são vulneráveis a phishing e não fornecem o mesmo nível de proteção que chaves de acesso e chaves de segurança. O SMS não é mais recomendado, de acordo com as diretrizes de identidade digital NIST 800-63B.
Se as contas de serviço em sua organização tiverem sido selecionadas para o registro de 2FA pelo GitHub, os tokens e as chaves continuarão funcionando após o prazo final sem interrupção. Somente o acesso ao GitHub por meio da interface do usuário do site será bloqueado até que a conta tenha habilitado a 2FA. É recomendável configurar o TOTP como segundo fator para contas de serviço e armazenar o segredo do TOTP exposto durante a instalação no gerenciador de senhas compartilhadas da sua empresa, com acesso aos segredos controlado por meio do SSO.
Se você é o proprietário de uma empresa, configure uma política que exija a 2FA para todas as organizações pertencentes à sua empresa.
Se você for um proprietário da organização, poderá exigir que todos os integrantes da organização habilitem a 2FA.
Para saber mais sobre como habilitar a 2FA em sua própria conta, confira Configurar a autenticação de dois fatores. Para saber mais sobre como exigir 2FA em sua organização, confira Exigindo a autenticação de dois fatores na sua organização.
Configure sua conta corporativa
Os proprietários da empresa podem exigir a autenticação 2FA para todos os integrantes da a instância empresa. A disponibilidade das políticas de 2FA em GitHub Enterprise Cloud depende de como integrantes efetuam a autenticação para acessar sua recursos da empresa.
Se sua empresa usar o Enterprise Managed Users ou a autenticação SAML for imposta para sua empresa, você não poderá configurar a 2FA no GitHub Enterprise Cloud. Alguém com acesso administrativo ao seu IdP deve configurar a autenticação 2FA para o IdP.
Para saber mais, confira Sobre SAML para IAM empresarial e Aplicando políticas para configurações de segurança na sua empresa.
Configure a sua conta pessoal
Note
Dependendo do método de autenticação que o proprietário de uma empresa tiver configurado, talvez você não consiga habilitar a autenticação 2FA em sua conta pessoal.
O GitHub Enterprise Cloud dá suporte a várias opções para 2FA e, embora qualquer um deles seja melhor do que nada, a opção mais segura é uma credencial WebAuthn. O WebAuthn requer um autenticador, como uma chave de segurança de hardware FIDO2, um autenticador de plataforma como o Windows Hello, um telefone Apple ou Google ou um gerenciador de senhas. É possível, apesar de ser difícil, fazer phish de outras formas de 2FA (por exemplo, quando alguém pede para ler a sua senha de um único dígito). No entanto, o WebAuthn é muito mais resistente a phishing, pois o escopo do domínio está integrado ao protocolo, o que evita que credenciais de um site que represente a página de login sejam usadas no GitHub Enterprise Cloud.
Ao configurar o 2FA, você sempre deve baixar os códigos de recuperação e configurar mais de uma credencial 2FA. Isso garante que o acesso à sua conta não depende de um único dispositivo. Para saber mais, confira Configurar a autenticação de dois fatores e Configurar métodos de recuperação da autenticação de dois fatores.
Configurar a conta da sua organização
Note
Dependendo do método de autenticação que o proprietário de uma empresa tiver configurado, talvez você não consiga exigir a autenticação 2FA para sua organização.
Se você for proprietário de uma organização, você poderá ver quais usuários não estão habilitados com 2FA, poderá ajudá-los a configurá-la e, em seguida, exigir a autenticação 2FA para sua organização. Para guiar você nesse processo, consulte:
- Ver se os usuários da organização habilitaram a 2FA
- Preparar para exigir autenticação de dois fatores na organização
- Exigindo a autenticação de dois fatores na sua organização
Conectar a GitHub Enterprise Cloud usando chaves SSH
Existem outras maneiras de interagir com GitHub Enterprise Cloud além de entrar no site. Muitas pessoas autorizam o código que enviam por push para GitHub com uma chave privada SSH. Para saber mais, confira Sobre o SSH.
Assim como a senha da sua conta, se um invasor conseguir obter sua chave SSH privada, ele poderá representar você e enviar um código malicioso por push a qualquer repositório ao qual você tenha acesso de gravação. Se você armazenar sua chave SSH privada em um disco, é uma boa ideia protegê-la com uma senha. Para saber mais, confira Trabalhar com frase secreta da chave SSH.
Outra opção é gerar chaves SSH em uma chave de segurança de hardware. Você pode usar a mesma chave que você está usando no 2FA. É muito difícil comprometer as chaves de segurança de hardware remotamente, porque a chave SSH privada permanece no hardware e não pode ser acessada diretamente por meio do software. Para saber mais, confira Gerando uma nova chave SSH e adicionando-a ao agente SSH.
As chaves SSH com suporte de hardware são bastante seguras, mas a exigência de hardware pode não funcionar para algumas organizações. Uma abordagem alternativa é usar chaves SSH válidas por um curto período de tempo. Mesmo que a chave privada seja comprometida, ela não poderá ser explorada por muito tempo. Este é o conceito por trás da execução da sua própria autoridade de certificação SSH. Embora essa abordagem fornece a você um grande controle sobre como os usuários efetuam a autenticação e também vem com a responsabilidade da própria manutenção de uma autoridade certificada de SSH. Para saber mais, confira Sobre autoridades certificadas de SSH.