Observação
O acesso a essa página exige autorização. Você pode tentar entrar ou alterar diretórios.
O acesso a essa página exige autorização. Você pode tentar alterar os diretórios.
As credenciais expostas em sistemas de engenharia fornecem oportunidades facilmente exploráveis para invasores. Para se defender dessa ameaça, a Segurança Avançada do GitHub para Azure DevOps verifica credenciais e outros conteúdos confidenciais em seu código-fonte. A proteção por push também impede que as credenciais sejam vazadas em primeiro lugar. Você precisa da Segurança Avançada do GitHub para o Azure DevOps ou, se estiver usando a experiência autônoma, a Proteção Secreta do GitHub para Azure DevOps habilitada.
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. Para usar a Segurança Avançada do GitHub com repositórios do GitHub, consulte a Segurança Avançada do GitHub.
Pré-requisitos
| Categoria | Requisitos |
|---|---|
| Permissões | – Para exibir um resumo de todos os alertas de um repositório: permissões de colaborador para o repositório. – Para ignorar alertas na Segurança Avançada: permissões de administrador do projeto . – Para gerenciar permissões em Segurança Avançada: Membro do grupo Administradores de Coleção de Projetos ou Segurança Avançada: gerenciar a permissão de configurações definida como Permitir. |
Para obter mais informações sobre permissões de Segurança Avançada, consulte Gerenciar permissões de Segurança Avançada.
Sobre alertas secretos de verificação
Quando você habilita a Segurança Avançada ou a Proteção Secreta especificamente, ela examina repositórios em busca de segredos emitidos por vários 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. Navegue 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 todas as confirmações históricas. Com o tempo, os alertas começarão a aparecer à medida que a verificação progride.
Renomear branches não afeta o resultado. No entanto, pode levar até 24 horas para 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
Selecione a guia Segredos para exibir todos os alertas de verificação de segredo.
Se a Segurança Avançada tiver sido 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 |
|---|---|
| Localização | A seção Locais detalha os caminhos 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 que não são da Microsoft 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:
- Navegue até o alerta que você deseja fechar e selecione o alerta.
- Selecione a lista suspensa Fechar alerta .
- Se ainda não estiver selecionado, selecione Corrigido.
- Selecione Fechar para enviar e fechar o alerta.
Descartando alertas de verificação secreta
Para ignorar um alerta, execute as seguintes etapas:
- Navegue até o alerta que você deseja fechar e selecione no alerta.
- Selecione a lista suspensa Fechar alerta .
- Se ainda não estiver selecionado, selecione Risco aceito ou Falso positivo como o motivo do fechamento.
- Adicione um comentário opcional à caixa de texto Comentário .
- Selecione Fechar para enviar e fechar o alerta.
- O estado de alerta muda de Abrir para Fechado e exibe o motivo da demissão.
Você pode abrir manualmente qualquer alerta descartado anteriormente.
Tornar os segredos comprometidos seguros
Depois que um segredo é adicionado a um repositório, o segredo é comprometido. A Microsoft recomenda as seguintes ações para segredos comprometidos:
Importante
Recomendamos os tokens mais seguros do Microsoft Entra em vez de tokens de acesso pessoal de maior risco. Saiba mais sobre nossos esforços para reduzir o uso do PAT. Examine nossas diretrizes de autenticação para escolher o mecanismo de autenticação correto para suas necessidades.
- 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, armazene o novo segredo com segurança e verifique se ele nunca será armazenado como texto sem formatação. Uma opção é usar o Azure Key Vault ou 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 poderá 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 por 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 sua 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 seus commits contiverem um segredo identificado, o seguinte erro será exibido, indicando que o 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, o seguinte bloco de erros será exibido, o que impede que você envie suas alterações por push:
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.
Remova o segredo do arquivo sinalizado e 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 anexar a cadeia de caracteres Placeholder 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:
- Remova o segredo do código.
- Confirme as alterações usando
git commit --amend - 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:
- Use
git logpara determinar qual confirmação você primeiro cometeu o segredo. - Execute uma troca de base interativa:
git rebase -i [commit ID before credential introduction]~1 - Identifique seu commit para editar alterando
pickparaeditna primeira linha do texto que aparece no editor. - Remova o segredo do código.
- Faça o commit da alteração com
git commit --amend. - Conclua o rebase executando
git rebase --continue.
Enviar por push um segredo bloqueado
Não ignore os segredos sinalizados porque fazer 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 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.
Sobre verificações de validade
As verificações de validade secreta ajudam você a priorizar alertas indicando se um segredo detectado ainda é utilizável. Para tipos de segredos com suporte, a Segurança Avançada do GitHub para Azure DevOps pergunta automaticamente ao provedor emissor se a credencial está ativa, não sendo necessário alternar nenhum recurso separado uma vez que a verificação de segredos está habilitada.
Ter o GitHub Advanced Security para Azure DevOps ou a proteção de segredos habilita automaticamente as verificações de validade.
O que você obtém
- Verificação automática para tipos de segredo de parceiro com suporte (sem configuração extra).
- Status mostrado na lista de alertas de verificação secreta e no painel de detalhes.
- Filtrando 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 no modo de exibição de alerta.
Significados de status
| Situação | Meaning | Ação |
|---|---|---|
Active |
O provedor confirmou que o segredo ainda é utilizável. | Abra o alerta e siga as etapas de Recomendações e Remediação. |
| Unknown | Nenhum sinal definitivo de atividade; pode estar inativo ou a verificação falhou devido ao serviço, à rede ou a outros erros inesperados. | Trate como possivelmente ativo; tente novamente a verificação ou rotacione se for sensível. |
Fluxo de trabalho típico
- Filtrar status de validação =
Activepara exibir alertas de maior risco. - Para cada segredo ativo, abra o alerta e siga as etapas de Recomendações e Correção fornecidas no modo de exibição de alerta.
- Use a verificação sob demanda após a correção para confirmar as alterações de status.
- Aborde os segredos desconhecidos a seguir – reverifique sob demanda ou trate como ativo se os dados forem sensíveis.
- Feche alertas de acordo com sua política depois de concluir as etapas de correção no alerta.
Verificação sob demanda
Use "verificar segredo" (nos detalhes do alerta) depois de seguir suas Recomendações & Correção ou quando uma tentativa anterior retornou Desconhecido. O carimbo de data/hora é atualizado na conclusão.