Configurar a verificação 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. Você precisa do GitHub Advanced Security for Azure DevOps ou, se estiver usando a experiência autônoma, da Proteção Secreta do GitHub para Azure DevOps habilitada.

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

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

Pré-requisitos

Para obter mais informações sobre permissões de Segurança Avançada, consulte Gerenciar permissões de Segurança Avançada.

Sobre alertas de varredura secreta

Quando você ativa especificamente a Segurança Avançada ou a Proteção Secreta, ela verifica os repositórios em busca de segredos emitidos por vários provedores de serviços e gera alertas de varredura 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 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. Navegue 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.

Renomear ramos não afeta os resultados. No entanto, pode levar até 24 horas para 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

Selecione o separador Segredos para visualizar todos os alertas de varredura de segredos.

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.

Para segredos que não são do provedor, a tag Confiança: outra também aparece junto à etiqueta de gravidade na visualização dos 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 um alerta, execute as seguintes etapas:

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.

Você pode abrir manualmente qualquer alerta descartado anteriormente.

Torne os segredos comprometidos seguros

Uma vez que um segredo é guardado num repositório (por exemplo, GitHub ou Bitbucket), 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, armazene o novo segredo com segurança e garanta que ele nunca seja armazenado como texto sem formatação. Uma opção é usar o Azure Key Vault ou outras soluções de gerenciamento secreto.

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 pode não bloquear versões mais antigas de certos 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 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, o erro a seguir indicará que seu envio 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, o seguinte bloco de erro será exibido, o que impede que você envie 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.

Remova o segredo do arquivo sinalizado e, em seguida, remova o segredo do histórico de confirmação. Se o segredo sinalizado for um espaço reservado ou um segredo de exemplo, atualize o segredo falso para adicionar a cadeia de caracteres Placeholder antes 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

Não ignore segredos sinalizados porque isso 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 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.

Sobre as verificações de validade

As verificações de validade secretas ajudam a priorizar alertas, indicando se um segredo detetado ainda é utilizável. Para tipos de segredo com suporte, o GitHub Advanced Security for Azure DevOps pergunta automaticamente ao provedor emissor se a credencial está ativa, não sendo necessária uma alternância de recurso separada quando a verificação de segredos estiver habilitada.

Ter o pacote GitHub Advanced Security for Azure DevOps ou a proteção Secret habilita automaticamente as verificações de validade.

O que você ganha

• Verificação automática de tipos secretos de parceiros suportados (sem configuração extra).
• Status mostrado na lista de alertas de varredura secreta e no painel de detalhes.
• Filtragem por status de validação para que você possa se concentrar em segredos ativos.
• Opcionalmente, você pode executar uma verificação de validade "sob demanda" para o segredo na exibição de alerta.

Significados do status

Fluxo de trabalho típico

1. Status de Validação do Filtro = Active para exibir alertas de maior risco.
2. Para cada segredo ativo, abra o alerta e siga as etapas de Recomendações e Correção fornecidas na exibição de alerta.
3. Use a verificação sob demanda após a correção para confirmar as alterações de status.
4. Endereço Segredos desconhecidos em seguida—tente novamente a verificação sob demanda ou trate como ativo se os dados forem confidenciais.
5. Feche alertas de acordo com sua política depois de concluir as etapas de correção no alerta.

Verificação a pedido

Use "verifique segredo" (no detalhe do alerta) depois de seguir as suas Recomendações e Remediação ou quando uma tentativa anterior retorna Desconhecido. O timestamp é atualizado quando completado.

Artigos relacionados

• Solucionar problemas de análise de dados sensíveis
• Saiba mais sobre padrões de varredura secretos
• Configurar a análise de código
• Configurar a análise de dependências
• Saiba mais sobre o GitHub Advanced Security for Azure DevOps