Análise de segredos

As credenciais expostas em sistemas de engenharia oferecem oportunidades facilmente exploráveis para os atacantes. Para se defender contra essa ameaça, o GitHub Advanced Security for Azure DevOps verifica se há credenciais e outros conteúdos confidenciais em seu código-fonte. A proteção por push também evita que quaisquer credenciais sejam vazadas em primeiro lugar.

A verificação secreta do repositório verifica quaisquer segredos que já possam existir no código-fonte ao longo do histórico e a proteção por push impede que novos segredos sejam expostos no código-fonte.

O GitHub Advanced Security for Azure DevOps funciona com o Azure Repos. Se você quiser usar a Segurança Avançada do GitHub com repositórios do GitHub, consulte Segurança Avançada do GitHub.

Sobre alertas de varredura secreta

Quando a Segurança Avançada está ativada, verifica os repositórios em busca de segredos emitidos por uma grande variedade de fornecedores de serviços e gera alertas de análise secreta.

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

A guia Segurança Avançada em Repos>Segurança Avançada no Azure DevOps é o hub para exibir seus alertas de segurança. Selecione a guia Segredos para exibir alertas de varredura secreta. Você pode filtrar por estado e tipo secreto. Você pode navegar até um alerta para obter mais detalhes, incluindo orientações de correção. Depois de ativar a Segurança Avançada, é iniciada uma verificação para o repositório selecionado, incluindo todas as confirmações históricas. Com o tempo, os alertas começarão a aparecer à medida que a verificação progride.

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

Para corrigir segredos expostos, invalide a credencial exposta e crie uma nova em seu lugar. O segredo recém-criado deve então ser armazenado de forma segura de uma forma que não o empurre diretamente de volta para o código. Por exemplo, o segredo pode ser armazenado no Cofre da Chave do Azure. 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, salvo indicação em contrário.

Gerenciar alertas de varredura secreta

Visualizando alertas para um repositório

Qualquer pessoa com permissões de colaborador para um repositório pode visualizar um resumo de todos os alertas para um repositório na guia Segurança Avançada em Repos. Selecione na guia Segredos para visualizar todos os alertas de varredura secreta.

Se a Segurança Avançada tiver sido ativada recentemente para o repositório, poderá ver um cartão indicando que a Segurança Avançada ainda está a analisar o repositório.

Quando a verificação estiver concluída, todos os resultados serão exibidos. Um único alerta é gerado para cada credencial exclusiva detetada, em todas as ramificações e histórico do repositório. Não há filtros de ramificação, pois eles são agrupados em um alerta.

Os segredos que não são do provedor podem ser visualizados selecionando "Outros" na lista suspensa de confiança na guia de verificação secreta.

Detalhes do alerta

Quando você navega para um alerta, uma exibição de alerta detalhada é exibida, revela mais detalhes sobre a localização e fornece orientações específicas de correção para resolver o alerta.

Section	Explicação
Location	A seção Locais detalha o(s) caminho(s) onde a verificação secreta descobriu a credencial vazada. Pode haver vários locais ou várias confirmações no histórico que contêm a credencial vazada. Todos esses locais e confirmações são exibidos em Locais com um link direto para o trecho de código e confirmá-lo 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 alerta	Não há comportamento de correção automática para alertas de varredura secreta. Todos os alertas secretos de varredura devem ser atestados manualmente, conforme corrigido através da página de detalhes do alerta. Selecione o botão Fechar para verificar se o segredo foi revogado.
Gravidade	Todos os alertas secretos de varredura são definidos como críticos. Qualquer credencial exposta é potencialmente uma oportunidade para um ator mal-intencionado.
Encontrar detalhes	O tipo de credencial e a regra usados para localizar a credencial estão listados na barra lateral da página de detalhes do alerta.

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

Corrigindo alertas secretos de varredura

Cada segredo tem etapas de remediação exclusivas para guiá-lo através de como revogar e regenerar um novo segredo em seu lugar. O detalhe do alerta compartilha etapas ou documentação específicas para cada alerta.

Um alerta de varredura secreto permanece aberto até ser fechado. Para atestar que um alerta de varredura secreta foi corrigido:

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

Descartando alertas secretos de varredura

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

Para descartar um alerta:

1. Navegue até o alerta que deseja fechar e selecione o 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 feche o alerta.
6. O estado de alerta muda de Aberto para Fechado e exibe o motivo da demissão.

Qualquer alerta anteriormente descartado pode ser reaberto manualmente.

Proteger segredos comprometidos

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

• Para um token de acesso pessoal do Azure DevOps comprometido, exclua o token comprometido, crie um novo token e atualize todos os serviços que usam o token antigo.
• Para todos os outros segredos, verifique primeiro se o segredo confirmado no Azure Repos é válido. Em caso afirmativo, crie um novo segredo, atualize todos os serviços que usam o segredo antigo e exclua o segredo antigo.
• Identifique todas as ações tomadas pelo token comprometido nos recursos da sua empresa.

Ao atualizar um segredo, certifique-se de armazenar o novo segredo de forma segura e garantir que ele seja sempre acessado e nunca armazenado como texto sem formatação. Uma possibilidade pode ser através do Azure Keyvault ou de outras soluções de gestão secretas.

Proteção secreta contra push

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

Sobre alertas de proteção por push

Os alertas de proteção por push são alertas de usuário relatados pela proteção por push. Atualmente, a verificação secreta como proteção push verifica os 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 poderá criar um alerta somente quando ambas as partes do par forem detetadas no mesmo arquivo. O emparelhamento garante que os vazamentos mais críticos não fiquem escondidos atrás de informações sobre vazamentos parciais. A correspondência de pares também ajuda a reduzir os falsos positivos, uma vez que ambos os elementos de um par devem ser usados juntos para acessar o recurso do provedor.

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

Proteção contra push a partir da linha de comando

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

Proteção push a partir da interface web

A proteção push também funciona a partir da interface web. Se um segredo for identificado em uma confirmação, você verá o seguinte bloco de erro que o impede de enviar as alterações:

O que fazer se o push for bloqueado

A proteção por push bloqueia segredos encontrados em arquivos de texto sem formatação que geralmente são (mas não estão limitados a) arquivos de texto, como código-fonte ou arquivos de configuração JSON. Estes segredos são armazenados em texto simples. Se um agente mal-intencionado obtém acesso aos arquivos e eles são publicados em um repositório público, os segredos são utilizáveis por qualquer pessoa.

É recomendável remover o segredo do arquivo sinalizado e, em seguida, 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 preceder a cadeia de caracteres Placeholder na frente do segredo falso.

Se o segredo foi 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. Faça push das suas alterações novamente.

Se o segredo tiver sido adicionado mais atrás no histórico, edite as consolidações usando uma nova base interativa:

1. Use git log para determinar em que consolidação consolidou primeiro o segredo.
2. Execute uma rebase interativa: git rebase -i [commit ID before credential introduction]~1
3. Identifique a consolidação a editar, mudando pick para edit na primeira linha do texto que aparece no editor.
4. Remova o segredo do código.
5. Consolide a alteração com git commit --amend.
6. Termine a rebase executando git rebase --continue.

Empurrar 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, deverá removê-lo de todo o histórico de ramificações antes de tentar enviar as alterações novamente.

Se você acredita que um segredo bloqueado é um falso positivo ou seguro para empurrar, você pode ignorar a proteção push. Inclua a cadeia de caracteres skip-secret-scanning:true na mensagem de confirmação. Mesmo que você ignore a proteção por push, um alerta de varredura secreta é gerado na UX de alerta assim que o segredo é enviado.