Perguntas comuns sobre como proteger contêineres

Você poderá usar o Azure Policy Configure Microsoft Defender for Containers to be enabled, para habilitar o Defender para contêineres em escala. Você também poderá ver todas as opções disponíveis para habilitar o Microsoft Defender para contêineres.

Sim.

Não. Há suporte somente para os clusters do AKS (Serviço de Kubernetes do Azure) que usam conjuntos de dimensionamento de máquinas virtuais para os nós.

Não. O AKS é um serviço gerenciado e não há suporte para o processamento dos recursos de IaaS. A extensão VM do Log Analytics não é necessária e pode resultar em preços extras.

Você pode usar seu workspace do Log Analytics seguindo as etapas na seção Atribuir um workspace personalizado deste artigo.

Não recomendamos excluir o workspace padrão. O Defender para contêineres usa os workspaces padrão para coletar dados de segurança dos clusters. O Defender para contêineres não poderá coletar dados, e algumas recomendações e alertas de segurança ficarão indisponíveis, se você excluir o workspace padrão.

Para recuperar o workspace padrão, remova e reinstale o sensor do Defender. A reinstalação do sensor do Defender cria um workspace padrão.

Dependendo da região, o workspace padrão do Log Analytics pode estar em vários locais. Para verificar sua região, consulte Onde o workspace padrão do Log Analytics foi criado?

O sensor do Defender usa o workspace do Log Analytics para enviar dados dos clusters do Kubernetes ao Defender para Nuvem. O Defender para Nuvem adiciona o workspace do Log Analytics e o grupo de recursos como um parâmetro para uso pelo sensor.

No entanto, se sua organização tiver uma política que exija uma marca específica nos recursos, isso poderá fazer com que a instalação do sensor falhe durante a fase de criação do grupo de recursos ou do workspace padrão. Se isso falhar, você poderá:

• Atribuir um workspace personalizado e adicionar qualquer marca exigida pela organização.

  ou

• Se a empresa exigir que você marque o recurso, navegue até essa política e exclua os seguintes recursos:

  1. O grupo de recursos DefaultResourceGroup-<RegionShortCode>
  2. O workspace DefaultWorkspace-<sub-id>-<RegionShortCode>

  RegionShortCode é uma cadeia de caracteres de 2 a 4 letras.

O Defender para contêineres extrai a imagem do registro e a executa em uma área restrita isolada com o Gerenciamento de Vulnerabilidades do Microsoft Defender para ambientes multinuvem. O verificador extrai uma lista de vulnerabilidades conhecidas.

O Defender para Nuvem filtra e classifica as descobertas do verificador. Quando uma imagem está íntegra, o Defender para Nuvem a marca como tal. O Defender para Nuvem gera recomendações de segurança apenas para as imagens que têm problemas a serem resolvidos. Notificando você apenas quando há problemas, o Defender para Nuvem reduz o potencial de alertas informativos indesejados.

Para identificar eventos de pull executados pelo verificador, execute as seguintes etapas:

1. Pesquise eventos de pull com o UserAgent do AzureContainerImageScanner.
2. Extraia a identidade associada a esse evento.
3. Use a identidade extraída para identificar eventos de pull do verificador.

• Recursos não aplicáveis são recursos para os quais a recomendação não pode dar uma resposta definitiva. A guia não aplicável inclui motivos para cada recurso que não pôde ser avaliado.
• Recursos não verificados são recursos agendados para serem avaliados, mas que ainda não o foram.

Algumas imagens podem reutilizar as marcas de uma imagem que já foi digitalizada. Por exemplo, você pode reatribuir a marca "Mais recente" sempre que adicionar uma imagem a um resumo da mensagem. Nesses casos, a imagem 'antiga' ainda existe no registro e ainda pode ser puxada pelo resumo da mensagem. Se a imagem tiver descobertas de segurança e for extraída, ela vai expor vulnerabilidades de segurança.

Atualmente, o Defender para Contêineres pode verificar imagens somente no ACR (Registro de Contêiner do Azure) e no ECR (Registro de Contêiner Elástico do AWS). Não há suporte para registro de imagem de contêiner interno do Registro do Docker, Registro de Artefato da Microsoft/Registro de Contêiner da Microsoft e ARO (Red Hat OpenShift no Azure). As imagens devem primeiro ser importadas para o ACR. Saiba mais sobre Como importar imagens de contêiner para um registro de contêiner do Azure.

Sim. Os resultados ficam na API do REST de subavaliações. Além disso, você pode usar o ARG (Azure Resource Graph), a API semelhante ao Kusto para todos os seus recursos: uma consulta pode buscar uma verificação específica.

Para verificar um tipo de imagem, você precisa usar uma ferramenta que possa verificar o manifesto da imagem bruta, como o skopeo, e inspecionar o formato da imagem bruta.

• Para o formato Docker v2, o tipo de mídia do manifesto seria application/vnd.docker.distribution.manifest.v1+json ou application/vnd.docker.distribution.manifest.v2+json, conforme documentado aqui.
• Para o formato de imagem OCI, o tipo de mídia de manifesto seria application/vnd.oci.image.manifest.v1+json e o tipo de mídia de configuração application/vnd.oci.image.config.v1+json, conforme documentado aqui.

Há duas extensões que fornecem a funcionalidade de CSPM sem agente:

• Avaliações de vulnerabilidade de contêineres sem agente: fornece avaliações de vulnerabilidade de contêineres sem agente. Saiba mais sobre a Avaliação de vulnerabilidade de contêineres sem agente.
• Descoberta sem agente para Kubernetes: fornece descoberta baseada na API de informações sobre a arquitetura de cluster, objetos de carga de trabalho e configuração do Kubernetes.

Para integrar várias assinaturas ao mesmo tempo, você pode usar esse script.

Se você não vir os resultados de seus clusters, verifique as seguintes perguntas:

• Você temclusters parados?
• Seus grupos de recursos, assinaturas ou clusters estão bloqueados ? Se a resposta para qualquer uma dessas perguntas for sim, confira as respostas nas perguntas a seguir.

Não oferecemos suporte nem cobramos por clusters parados. Para obter o valor dos recursos sem agente em um cluster parado, você pode executar novamente o cluster.

Sugerimos que você desbloqueie o grupo de recursos/assinatura/cluster bloqueado, faça as solicitações relevantes manualmente e, em seguida, bloqueie novamente o grupo de recursos/assinatura/cluster fazendo o seguinte:

1. Habilite o sinalizador de recurso manualmente por meio da CLI usando o Acesso Confiável.

   “az feature register --namespace "Microsoft.ContainerService" --name "TrustedAccessPreview” 
   

2. Execute a operação de vinculação na CLI:

   az account set -s <SubscriptionId> 
   az extension add --name aks-preview 
   az aks trustedaccess rolebinding create --resource-group <cluster resource group> --cluster-name <cluster name> --name defender-cloudposture --source-resource-id /subscriptions/<SubscriptionId>/providers/Microsoft.Security/pricings/CloudPosture/securityOperators/DefenderCSPMSecurityOperator --roles  "Microsoft.Security/pricings/microsoft-defender-operator" 
   

Para clusters bloqueados, você também pode seguir as seguintes etapas:

• Remova o bloqueio.
• Execute a operação de associação manualmente fazendo uma solicitação de API. Saiba mais sobre recursos bloqueados.

Saiba mais sobre as versões do Kubernetes com suporte no Serviço de Kubernetes do Azure (AKS).

Pode levar até 24 horas para que as alterações reflitam no grafo de segurança, nos caminhos de ataque e no gerenciador de segurança.

As etapas a seguir removerão a recomendação de registro único da plataforma Trivy e adicionarão as novas recomendações de registro e runtime da plataforma MDVM.

1. Abra o conector AWS apropriado.
2. Abra a página Configurações do Defender para contêineres.
3. Ative a Avaliação de Vulnerabilidade de Contêiner sem Agente.
4. Conclua as etapas do assistente de conector, incluindo a implantação do novo script de integração no AWS.
5. Exclua manualmente os recursos criados durante a integração:
   • Bucket S3 com o prefixo defender-for-containers-va
   • Cluster ECS com o nome defender-for-containers-va
   • VPC:
     • Marcar name com o valor defender-for-containers-va
     • CIDR de sub-rede de IP 10.0.0.0/16
     • Associado ao grupo de segurança padrão com a marca name e o valor defender-for-containers-va que tem uma regra de todo o tráfego de entrada.
     • Sub-rede com a marca name e o valor defender-for-containers-va na VPC defender-for-containers-va com a sub-rede IP CIDR 10.0.1.0/24 usada pelo cluster ECS defender-for-containers-va
     • Gateway de Internet com a marca name e o valor defender-for-containers-va
     • Tabela de rotas – Tabela de rotas com a marca name e o valor defender-for-containers-va e com estas rotas:
       • Destino: 0.0.0.0/0; Destino: Gateway de Internet com a marca name e o valor defender-for-containers-va
       • Destino: 10.0.0.0/16; Destino: local

Para obter avaliações de vulnerabilidade para imagens em execução, habilite a Descoberta sem agente para Kubernetes ou implante o sensor do Defender nos clusters do Kubernetes.

Próximas etapas

Saiba mais sobre o Defender para Contêineres