Verificação de segredo

As credenciais expostas em sistemas de engenharia fornecem oportunidades facilmente exploráveis para invasores. Para se defender dessa ameaça, a GitHub Advanced Security para Azure DevOps verifica credenciais e outros conteúdos confidenciais no código-fonte. A proteção por push também impede que as credenciais sejam vazadas em primeiro lugar.

A verificação secreta de seus repositórios verifica se todos os segredos que já podem existir no código-fonte em todo o histórico e a proteção por push impede que novos segredos sejam expostos no código-fonte.

O GitHub Advanced Security para Azure DevOps funciona com o Azure Repos. Se você quiser usar o GitHub Advanced Security com repositórios do GitHub, consulte o GitHub Advanced Security.

Sobre alertas secretos de verificação

Quando a Segurança Avançada está habilitada, ela verifica repositórios de segredos emitidos por uma grande variedade de provedores de serviços e gera alertas de verificação secreta.

Se o acesso a um recurso exigir credenciais emparelhadas, a verificação secreta criará um alerta somente quando ambas as partes do par forem detectadas no mesmo arquivo. O emparelhamento garante que os vazamentos mais críticos não fiquem ocultos atrás de informações sobre vazamentos parciais. A correspondência de pares também ajuda a reduzir falsos positivos, pois ambos os elementos de um par devem ser usados juntos para acessar o recurso do provedor.​​​​​​​

A guia Segurança Avançada no Repos>Advanced Security no Azure DevOps é o hub para exibir seus alertas de segurança. Selecione a guia Segredos para exibir alertas secretos de verificação. Você pode filtrar por estado e tipo de segredo. Você pode navegar até um alerta para obter mais detalhes, incluindo diretrizes de correção. Depois de habilitar a Segurança Avançada, uma verificação começa para o repositório selecionado, incluindo todos os commits históricos.. Com o tempo, os alertas começarão a aparecer à medida que a verificação progride.

Não haverá impacto nos resultados se as ramificações forem renomeadas – pode levar até 24 horas até que o novo nome seja exibido.

Para corrigir os segredos expostos, invalide a credencial exposta e crie uma nova em seu lugar. O segredo recém-criado deve ser armazenado com segurança de uma maneira que não o envie diretamente de volta para o código. Por exemplo, o segredo pode ser armazenado no Azure Key Vault. A maioria dos recursos tem uma credencial primária e secundária. O método para rolar uma credencial primária versus uma credencial secundária é idêntico, a menos que indicado de outra forma.

Gerenciar alertas de verificação de segredo

Visualizando alertas de um repositório

Qualquer pessoa com permissões de colaborador para um repositório pode exibir um resumo de todos os alertas de um repositório na guia Segurança Avançada em Repositório. Selecione na guia Segredos para exibir todos os alertas de verificação de segredo.

Se a Segurança Avançada for habilitada recentemente para seu repositório, você poderá ver um cartão indicando que a Segurança Avançada ainda está verificando seu repositório.

Depois que a verificação for concluída, todos os resultados serão exibidos. Um único alerta é gerado para cada credencial exclusiva detectada em todos os branches e histórico do repositório. Não há filtros de branch, pois eles são acumulados em um alerta.

Os segredos de não provedor podem ser visualizados selecionando "Outro" na lista suspensa de confiança na guia de verificação de segredo.

Detalhes do Alerta

Quando você navega para um alerta, um modo de exibição de alerta detalhado é exibido e revela mais detalhes sobre a localização e fornece diretrizes de correção específicas para resolver o alerta.

Seção	Explicação
Location	A seção Locais detalha o(s) caminho(s) em que a verificação secreta descobriu a credencial vazada. Pode haver vários locais ou várias commits no histórico que contêm a credencial vazada. Todos esses locais e commits são exibidos nos Locais com um link direto para o trecho de código e confirmação em que ele foi identificado.
Recomendação	A seção de recomendação contém diretrizes de correção ou link para diretrizes de correção de documentação de terceiros para a credencial identificada.
Fechar o alerta	Não há nenhum comportamento de autofixo para alertas secretos de verificação. Todos os alertas de verificação secreta devem ser atestados manualmente conforme corrigido na página de detalhes do alerta. Selecione o botão Fechar para verificar se o segredo foi revogado.
Severidade	Todos os alertas de verificação de segredo são definidos como críticos. Qualquer credencial exposta é potencialmente uma oportunidade para um ator mal-intencionado.
Localizando detalhes	O tipo de credencial e regra usados para localizar a credencial são listados nos detalhes de Localização na barra lateral da página de detalhes do alerta.

Com segredos de não provedor, a marcação Confiança: outro também aparece pelo selo de gravidade na exibição de detalhes do alerta.

Corrigindo alertas de verificação de segredo

Cada segredo tem etapas de correção exclusivas para guiá-lo sobre como revogar e regenerar um novo segredo em seu lugar. Os detalhes do alerta compartilham etapas ou documentação específicas para cada alerta.

Um alerta de verificação secreta permanece aberto até ser fechado. Para atestar que um alerta de verificação secreta foi corrigido:

1. Navegue até o alerta que você deseja fechar e selecione o alerta.
2. Selecione a lista suspensa Fechar alerta .
3. Se ainda não estiver selecionado, selecione Corrigido.
4. Selecione Fechar para enviar e fechar o alerta.

Descartando alertas de verificação secreta

Para ignorar alertas na Segurança Avançada, você precisa das permissões apropriadas. Por padrão, somente os administradores de projeto podem ignorar alertas de Segurança Avançada. Para mais informações sobre permissões de Segurança Avançada, consulte Gerenciar permissões de Segurança Avançada.

Para ignorar um alerta:

1. Navegue até o alerta que você deseja fechar e selecione no alerta.
2. Selecione a lista suspensa Fechar alerta .
3. Se ainda não estiver selecionado, selecione Risco aceito ou Falso positivo como o motivo do fechamento.
4. Adicione um comentário opcional à caixa de texto Comentário .
5. Selecione Fechar para enviar e fechar o alerta.
6. O estado de alerta muda de Abrir para Fechadoe exibe o motivo da demissão.

Qualquer alerta que tenha sido descartado anteriormente pode ser reaberto manualmente.

Protegendo segredos comprometidos

Depois que um segredo é confirmado em um repositório, o segredo é comprometido. A Microsoft recomenda as seguintes ações para segredos comprometidos:

• Para obter um token de acesso pessoal do Azure DevOps comprometido, exclua o token comprometido, crie um token e atualize todos os serviços que usam o token antigo.
• Para todos os outros segredos, primeiro verifique se o segredo com o Azure Repos comprometido é válido. Nesse caso, crie um segredo, atualize todos os serviços que usam o segredo antigo e, em seguida, exclua o segredo antigo.
• identifique todas as ações executadas pelo token comprometido nos recursos da sua empresa.

Ao atualizar um segredo, certifique-se de armazenar o novo segredo com segurança e verifique se ele é sempre acessado e nunca armazenado como texto sem formatação. Uma possibilidade pode ser por meio do Azure Keyvault ou de outras soluções de gerenciamento de segredos.

Proteção por push secreta

A proteção por push verifica os pushes de entrada em busca de segredos de alta confiança e impede que o push passe. Uma mensagem de erro exibe todos os segredos identificados para removê-los ou continuar enviando os segredos por push, se necessário.

Sobre os alertas de proteção por push

Os alertas de proteção por push são alertas de usuário relatados pela proteção relatada. A verificação secreta como uma proteção por push atualmente verifica repositórios em busca de segredos emitidos por alguns provedores de serviços.

Se o acesso a um recurso exigir credenciais emparelhadas, a verificação secreta criará um alerta somente quando ambas as partes do par forem detectadas no mesmo arquivo. O emparelhamento garante que os vazamentos mais críticos não estejam ocultos por trás de informações sobre vazamentos parciais. A correspondência de pares também ajuda a reduzir falsos positivos, pois ambos os elementos de um par devem ser usados juntos para acessar o recurso do provedor.

A proteção push pode não bloquear versões mais antigas de determinados tokens, pois esses tokens podem gerar um número maior de falsos positivos do que a versão mais recente. A proteção por push também pode não bloquear tokens herdados. Para tokens como Azure Storage Keys, a Segurança Avançada só dá suporte a tokens criados recentemente, não a tokens que correspondem aos padrões herdados.

Proteção por push da linha de comando

A proteção por push é criada nativamente no Git do Azure DevOps. Se suas commits contiverem um segredo identificado, você verá um erro de que seu push foi rejeitado.

Proteção por push da interface da Web

A proteção por push também funciona na interface da Web. Se um segredo for identificado em uma confirmação, você verá o seguinte bloco de erro que o impedirá o pushing de suas alterações:

O que fazer se o push foi bloqueado

A proteção por push bloqueia segredos encontrados em arquivos de texto sem formatação que geralmente são (mas não limitados a) arquivos de texto, como código-fonte ou arquivos de configuração JSON. Esses segredos são armazenados em texto sem formatação. Se um agente mal-intencionado obtiver acesso aos arquivos e eles forem publicados em um repositório público, os segredos poderão ser usados por qualquer pessoa.

É recomendável remover o segredo do arquivo sinalizado e remover o segredo do histórico de confirmação. Se o segredo sinalizado for um espaço reservado ou um segredo de exemplo, é recomendável que você atualize o segredo falso para anexar a cadeia Placeholder de caracteres na frente do segredo falso.

Se o segredo tiver sido adicionado em sua confirmação anterior imediata, altere a confirmação e crie uma nova confirmação:

1. Remova o segredo do código.
2. Confirme as alterações usando git commit --amend
3. Envie suas alterações por push novamente.

Se o segredo tiver sido adicionado mais adiante no histórico, edite suas commits usando uma troca de base interativa:

1. Use git log para determinar qual confirmação você primeiro cometeu o segredo.
2. Execute uma troca de base interativa: git rebase -i [commit ID before credential introduction]~1
3. Identifique seu commit para editar alterando pick para edit na primeira linha do texto que aparece no editor.
4. Remova o segredo do código.
5. Faça o commit da alteração com git commit --amend.
6. Conclua o rebase executando git rebase --continue.

Enviar por push um segredo bloqueado

Ignorar segredos sinalizados não é recomendado porque ignorar pode colocar a segurança da sua empresa em risco. Se você confirmar que um segredo identificado não é um falso positivo, remova o segredo de todo o histórico do branch antes de tentar enviar suas alterações por push novamente.

Se você acredita que um segredo bloqueado é um falso positivo ou seguro para enviar por push, você pode ignorar a proteção por push. Inclua a cadeia de caracteres skip-secret-scanning:true na sua mensagem de confirmação. Mesmo se você ignorar a proteção por push, um alerta de verificação secreta será gerado na experiência do usuário do alerta depois que o segredo for enviado por push.