Melhores práticas para proteger contas

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 Server, ele poderá fazer alterações maliciosas no seu código ou no processo de compilação. Dessa forma, seu primeiro objetivo deve ser dificultar que alguém tome a sua conta e as contas de outros usuários de da sua instância do GitHub Enterprise Server.

Centralizar autenticação

Se você é o administrador do site do sua instância do GitHub Enterprise Server, simplifique a experiência de logon para os usuários escolhendo um método de autenticação que se conecta ao seu IdP (provedor de identidade) existente, como o CAS, o SAML ou o LDAP. Isso significa que eles não precisam mais lembrar de uma senha adicional para GitHub.

Alguns métodos de autenticação também são compatíveis com a comunicação de informações adicionais para GitHub Enterprise Server, por exemplo, de quais grupos o usuário é integrante ou sincronizando chaves criptográficas para o usuário. Esta é uma excelente maneira de simplificar a sua administração à medida que a sua organização cresce.

Para saber mais informações sobre os métodos de autenticação disponíveis para GitHub Enterprise Server, confira "Sobre o gerenciamento de identidades e acesso".

Configurar autenticação de dois fatores

A melhor maneira de melhorar a segurança da sua conta pessoal ou do sua instância do GitHub Enterprise Server é 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.

Se você é o administrador do site do sua instância do GitHub Enterprise Server, talvez possa configurar a 2FA para todos os usuários da sua instância. A disponibilidade de 2FA no GitHub Enterprise Server depende do método de autenticação que você usa. Para obter mais informações, confira "Centralizar a autenticação".

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 usuários de a instância . A disponibilidade das políticas de 2FA em GitHub Enterprise Server depende de como usuários efetuam a autenticação para acessar sua instância.

Se você entrar no sua instância do GitHub Enterprise Server por meio de um IdP externo usando o SSO CAS ou SAML, não poderá configurar a 2FA no GitHub Enterprise Server. Alguém com acesso administrativo ao seu IdP deve configurar a autenticação 2FA para o IdP.
Se você entrar em sua instância do GitHub Enterprise Server por meio de um diretório LDAP externo, você poderá exigir a autenticação 2FA para sua empresa em GitHub Enterprise Server. Se você permitir a autenticação integrada para usuários fora do seu diretório, os usuários individuais poderão habilitar a autenticação 2FA, mas você não poderá exigir a autenticação 2FA para sua empresa.

Para saber mais, confira "Aplicando políticas para configurações de segurança na sua empresa".

Configure a sua conta pessoal

Observação: dependendo do método de autenticação que um administrador do site tenha configurado para sua instância do GitHub Enterprise Server, talvez você não consiga habilitar a autenticação 2FA na sua conta pessoal.

O GitHub Enterprise Server 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 Server.

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 obter mais informações, 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

Observação: dependendo do método de autenticação que um administrador do site tenha configurado para sua instância do GitHub Enterprise Server, 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:

Conectar a GitHub Enterprise Server usando chaves SSH

Existem outras maneiras de interagir com GitHub Enterprise Server além de entrar no site. Muitas pessoas autorizam o código que enviam por push para GitHub com uma chave privada SSH. Para obter mais informações, 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 obter mais informações, 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 obter mais informações, 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 obter mais informações, confira "Sobre autoridades certificadas de SSH".