Nesta página, você terá uma visão geral do processo de ativação, que acontece ao ativar o Security Command Center. O objetivo dele é responder a perguntascomuns:
- O que acontece quando o Security Command Center é ativado?
- Por que há um atraso antes do início das primeiras verificações?
- Qual é o tempo de execução esperado para a primeira e para as verificações contínuas?
- Como a alteração dos recursos e das configurações afetará o desempenho?
Visão geral
Ao ativar o Security Command Center pela primeira vez, é preciso concluir um processo de ativação antes que o Security Command Center comece a verificar os recursos. Em seguida, as verificações precisam ser concluídas antes de você visualizar um conjunto completo de descobertas do seu ambiente do Google Cloud.
O tempo que o processo de ativação e as verificações levam para ser concluído depende de um vários fatores, incluindo o número de ativos e recursos em seu e se o Security Command Center está ativado no nível da organização ou o para envolvidos no projeto.
Com as ativações no nível da organização, o Security Command Center precisa repetir algumas etapas do processo de ativação para cada projeto da organização. Dependendo do número de projetos de uma organização, o tempo necessário para o processo de ativação pode variar de minutos a horas. Para organizações com mais de 100.000 projetos, muitos recursos em cada projeto e outros fatores complicadores, a ativação e as verificações iniciais podem demorar mais de 24 horas para serem concluídas.
Com as ativações do Security Command Center no nível do projeto, o processo de ativação é muito mais rápido, porque é limitado ao único projeto em que o Security Command Center está ativado.
Os fatores que podem introduzir latência ao iniciar verificações e processar alterações das configurações e o ambiente de execução das verificações são discutidos nas seções a seguir.
topologia
A figura abaixo apresenta uma ilustração de alto nível do processo deintegração e ativação.
Latência na integração
Antes de as verificações começarem, o Security Command Center descobre e indexa os recursos.
Os serviços indexados são App Engine, BigQuery, Cloud SQL, Cloud Storage, Compute Engine, Identity and Access Management e Google Kubernetes Engine.
Para ativações do Security Command Center no nível do projeto, a descoberta e a indexação ficam limitadas ao único projeto em que o Security Command Center está ativado.
Para ativações no nível da organização, o Security Command Center descobre e indexa recursos em toda a organização.
Durante o processo de integração, são realizadas duas etapas essenciais.
Verificação de recurso
O Security Command Center executa uma verificação inicial de recursos para identificar o número total, local e estado de projetos, pastas, arquivos, clusters, políticas de identidade e acesso, usuários inscritos e outros recursos. Geralmente, esse processo éconcluído em minutos.
Ativação da API
À medida que os recursos são descobertos, o Security Command Center ativa partes do Google Cloud necessárias para que o Security Health Analytics, o Event o Threat Detection, o Container Threat Detection e o Web Security Scanner funcionem. Alguns serviços de detecção exigem que APIs específicas sejam ativadas para projetos protegidos funcionarem.
Ao ativar o Security Command Center no nível do projeto, a ativação da API geralmente demora menos de um minuto.
Com as ativações no nível da organização, o Security Command Center itera todos os projetos selecionados para verificação e ativa as APIs necessárias.
O número de projetos em uma organização determina principalmente a duração dos processos deintegração e ativação. Como as APIs precisam ser ativadas para projetos individualmente, essa costuma ser a tarefa mais demorada, em especial para organizações com mais de 100.000 projetos.
O tempo necessário para ativar serviços em vários projetos é escalonado linearmente. Isso significa que, em geral, demora duas vezes mais para ativar os serviços e as configurações de segurança em uma organização com 30.000 projetos do que em uma com 15.000.
Para uma organização com 100.000 projetos, a integração e a ativação do nível Premium precisam ser concluídas em menos de cinco horas. O tempo pode variar dependendo de muitos fatores, como o número de projetos ou contêineres usados e o número de serviços do Security Command Center ativados.
Latência da verificação
Ao configurar o Security Command Center, você decide quais serviços integrados serão ativados e seleciona os recursos do Google Cloud que serão analisados ou verificados em busca de ameaças e vulnerabilidades. Conforme as APIs são ativadas para projetos, os serviços selecionados começam a ser verificados. A duração dessas verificações também depende do número de projetos em uma organização.
As descobertas nos serviços integrados ficam disponíveis à medida que as verificações iniciais são concluídas. A latência dos serviços é descrita abaixo.
- O Container Threat Detection tem as seguintes latências:
- Latência de ativação de até 3,5 horas para projetos ou organizações recém-integrados.
- Latência de ativação de minutos para clusters recém-criados.
- Latência de detecção de minutos para ameaças em clusters queforam ativados.
A ativação da detecção de ameaças a eventos ocorre em segundos para de detecção. Para detectores personalizados novos ou atualizados, pode levar até 15 minutos para que as alterações entrem em vigor. Na prática, isso normalmente leva menos de 5 minutos.
Para detectores integrados e personalizados, a detecção as latências geralmente são inferiores a 15 minutos, a partir do momento em que um registro é gravado quando uma descoberta está disponível no Security Command Center.
As verificações do Security Health Analytics começam cerca de uma hora após a ativação do serviço. As primeiras verificações do Security Health Analytics podem levar até 12 horas para serem concluídas. Em seguida, a maioria das detecções é executada em tempo real em relação às alterações de configuração de recursos. Exceções estão detalhadas na Latência de detecção do Security Health Analytics.
O VM Threat Detection tem uma latência de ativação de até 48 horas para organizações recém-integradas. Para projetos, a latência de ativação é de até 15 minutos.
A avaliação de vulnerabilidades da Amazon Web Services (AWS) começa a verificar os recursos em uma conta da AWS aproximadamente 15 minutos depois que o modelo do CloudFormation necessário é implantado pela primeira vez na conta. Quando uma vulnerabilidade de software é detectada na conta da AWS, a descoberta correspondente fica disponível no o Security Command Center aproximadamente 10 minutos depois.
O tempo necessário para concluir uma verificação depende do número de instâncias do EC2. Normalmente, uma verificação de uma única instância do EC2 leva menos de 5 minutos.
As verificações do Web Security Scanner podem levar até 24 horas para serem iniciadasapós a ativação do serviço e serem executadas semanalmente após a primeira verificação.
O Security Command Center executa detectores de erro, que detectam erros de configuração relacionados ao Security Command Center e seus serviços. Esses detectores de erros são ativados por padrão e não podem ser desativados. As latências de detecção variam de acordo com o detector de erros. Para saber mais, consulte Erros do Security Command Center.
Os papéis do IAM para o Security Command Center podem ser concedidos no nível da organização, da pasta ou do projeto. A capacidade de ver, editar, criar ou atualizar descobertas, recursos e fontes de segurança depende do nível a que você tem acesso. Para saber mais sobre Para papéis do Security Command Center, consulte Controle de acesso.
Descobertas preliminares
É possível ver algumas descobertas no console do Google Cloud enquanto as verificações iniciais estão ocorrendo, mas antes que o processo de integração seja concluído.
As descobertas preliminares são precisas e acionáveis, mas não são abrangentes. Não é recomendável usar essas descobertas para uma avaliação de conformidade nas primeiras 24 horas.
Verificações subsequentes
As alterações feitas na organização ou no projeto, como mover recursos ou, para ativações no nível da organização, adicionar novas pastas e projetos, geralmente não afetam significativamente o tempo de descoberta de recursos ou o ambiente de execução das verificações. No entanto, algumas verificações prosseguem nas programações definidas, que determinam a rapidez com que o Security Command Center detecta alterações.
- Event Threat Detection e Container Threat Detection: esses serviços são executados em tempo real quando estão ativados e detectam recursos novos ou alterados imediatamente, como clusters, buckets ou registros, em projetos ativados.
- Security Health Analytics: executado em tempo real quando ativado e detecta recursos novos ou alterados em minutos, excluindo as detecções listadas abaixo.
- VM Threat Detection: para a verificação de memória, a VM Threat Detection verifica cada instância de VM
imediatamente após a
criação da instância. Além disso, a VM Threat Detection verifica cada instância de VM a cada 30 minutos.
- Para a detecção de mineração de criptomoedas, a Detecção de ameaças da VM gera uma descoberta por processo, por VM e por dia. Cada descoberta inclui apenas as ameaças associadas ao processo identificado pela descoberta. Se a Detecção de ameaças à VM encontrar ameaças, mas não conseguir associá-las a qualquer processo, então, para cada VM, a Detecção de ameaças a VMs agrupa todas as ameaças não associadas em um uma única descoberta emitida uma vez a cada período de 24 horas. Para ameaças que persistem mais de 24 horas, a Detecção de ameaças à VM gera novas descobertas a cada 24 horas.
- Para a detecção rootkit no modo kernel, que está em pré-lançamento, a detecção de ameaças da VM gera uma descoberta por categoria, por VM, a cada três dias.
Para a verificação do disco permanente, que detecta a presença de malware conhecido, a Detecção de ameaças à VM verifica cada instância de VM pelo menos uma vez por dia.
A avaliação de vulnerabilidades da AWS executa verificações três vezes por dia.
O tempo necessário para concluir uma verificação depende do número de consultas EC2 instâncias. Normalmente, uma verificação de uma única instância do EC2 leva menos de 5 minutos.
Quando uma vulnerabilidade de software é detectada em uma conta da AWS, a descoberta correspondente fica disponível no Security Command Center aproximadamente 10 minutos depois.
Web Security Scanner: executado semanalmente no mesmo dia da verificação inicial. Como é executado semanalmente, o Web Security Scanner não detecta alterações em tempo real. Se você mover um recurso ou alterar um aplicativo, essa alteração poderá não ser detectada por até uma semana. É possível executar verificações sob demanda para verificar recursos novos ou alterados entre as verificações programadas.
Os detectores de erro do Security Command Center são executados periodicamente no modo de lote. As frequências de verificação em lote variam de acordo com o detector de erros. Para saber mais, consulte Erros do Security Command Center.
Latência de detecção do Security Health Analytics
As detecções do Security Health Analytics são executadas periodicamente no modo em lote após a ativação do serviço, bem como quando a configuração de um recurso relacionado é alterada. Depois que o Security Health Analytics estiver ativado, todas as alterações de configuração de recurso relevantes resultarão em descobertas de configuração incorretas. Em alguns casos, as atualizações podem levar vários minutos, dependendo do tipo de recurso e da mudança.
Alguns detectores do Security Health Analytics não são compatíveis com o modo de verificação em tempo real, por exemplo, quando uma detecção é executada com informações fora da configuração de um recurso. Essas detecções, listadas na tabela abaixo, são executadas periodicamente eidentificam erros de configuração em até 12 horas. Leia Vulnerabilidades e descobertas para ver mais detalhes sobre os detectores do Security Health Analytics.
| Detecções do Security Health Analytics que não são compatíveis com o modo de verificaçãoem tempo real |
|---|
| COMPUTE_PROJECT_WIDE_SSH_KEYS_ALLOWED |
| MFA_NOT_ENFORCED (antes chamado de 2SV_NOT_ENFORCED) |
| OS_LOGIN_DISABLED |
| SQL_NO_ROOT_PASSWORD |
| SQL_WEAK_ROOT_PASSWORD |
Simulações de caminho de ataque
As simulações de caminho de ataque são executadas a cada seis horas, aproximadamente. À medida que sua organização do Google Cloud cresce em tamanho ou complexidade, o tempo entre os intervalos pode aumentar.
Quando você ativa o Security Command Center pela primeira vez, as simulações de caminho de ataque usam um conjunto de recursos padrão de alto valor, que inclui todos os tipos de recurso compatíveis na sua organização.
Ao começar a definir seu próprio conjunto de recursos de alto valor criando uma configuração de valor de recursos, é possível que o tempo entre os intervalos de simulação diminua se o número de instâncias de recursos no conjunto de recursos de alto valor for significativamente inferior ao conjunto padrão.
A seguir
- Saiba como usar o Security Command Center no console do Google Cloud.
- Saiba mais sobre os serviços de detecção.