Migrar permissões do SOAR para o IAM

Compatível com:

Google SecOps SOAR

Este documento orienta os clientes unificados do Google Security Operations e os usuários independentes do SOAR que precisam migrar o ambiente dos grupos de permissões do SOAR para o Google Cloud Identity and Access Management (IAM) para controle de acesso. Para um tutorial em vídeo desse procedimento, consulte o vídeo sobre a migração do IAM do SOAR.

Observação : a ferramenta de migração pode ajudar você a propor novas vinculações personalizadas do IAM para as permissões atuais de Configurações do SOAR. Para mais informações, consulte RBAC de recursos.

O processo de verificação do console do Google Cloud automatiza a transição das permissões do SOAR para o Google Cloud IAM seguindo estas etapas principais:

• Lê as configurações de permissões atuais, incluindo grupos de permissões personalizados e atribuições de usuários.
• Gera papéis personalizados do IAM que replicam os grupos de permissões atuais.
• Mapeia usuários e grupos atuais para papéis do IAM recém-criados para garantir que todos os privilégios de acesso sejam mantidos.
• Cria políticas do IAM para vincular usuários e grupos aos papéis atribuídos.

Antes de começar

Antes de iniciar a migração, confirme se os seguintes requisitos foram atendidos:

• Se você é um cliente unificado do Google SecOps, use o Cloud IAM para gerenciar papéis e permissões no lado do SIEM da plataforma. Para mais informações, consulte Migrar o RBAC legado para o RBAC de recursos.

• Verifique se você está usando a mesma identidade (e-mail ou conta) para o console do Google Cloud e o SOAR.

• Mapeamento de grupos do IdP: se você estiver usando a federação de identidade de colaboradores para autenticação, verifique se todos os usuários estão associados a grupos do provedor de identidade (IdP) na página Mapeamento de grupos. Para informações sobre o mapeamento de grupos do IdP, consulte Mapear usuários na plataforma. A ferramenta de migração usa esses mapeamentos para criar um script que vincula e-mails de usuários ou grupos a principais do IAM.

• Mapeamento de grupos de e-mail: se você estiver usando o Cloud Identity para autenticação, verifique se todos os usuários estão associados a grupos de e-mail na página Mapeamento de grupos. Para informações sobre o mapeamento de e-mails, consulte Mapear usuários na plataforma usando o Cloud Identity. A ferramenta de migração usa esses mapeamentos para criar um script que vincula e-mails de usuários ou grupos a principais do IAM.

• Opcional: chave de API do SOAR. Se você não tiver permissões do SOAR para mapear o usuário atual na página Mapeamentos de grupos, peça a um administrador do SOAR para fornecer uma chave de API do SOAR e use-a para gerar os scripts.

O administrador do SOAR precisa seguir as etapas do procedimento abaixo:

1. Na plataforma do Google SecOps, acesse Configurações do SOAR > Avançado > Grupos de permissões (chaves de API).
2. Crie um grupo de permissões, verificando se o módulo Configurações e as opções em "Configurações" estão todos marcados.
3. Acesse Configurações do SOAR > Avançado > Chaves de API.
4. Adicione uma nova chave de API e selecione o grupo de permissões que você criou.
5. Copie a chave de API gerada.

• Permissões: confirme se você tem as permissões necessárias:

  • Administrador da API Chronicle
  • Administrador de serviço do Chronicle
  • Administrador do Chronicle SOAR

Aviso: depois de ativar o IAM, todos os papéis predefinidos do Chronicle serão ativados com permissões do SOAR. O administrador da API do Chronicle agora vai incluir permissões de administrador do SOAR. Se você não quiser que os principais (usuários/grupos) atribuídos aos papéis predefinidos do Chronicle tenham permissões do SOAR ou se quiser limitar as permissões deles, recomendamos que você os atribua a uma função personalizada que exclua explicitamente as permissões do SOAR.

Após a migração, se houver problemas não resolvidos, clique em Desativar IAM para reverter a migração de grupos de permissões para papéis do IAM. Os papéis e as vinculações do IAM recém-criados não serão excluídos.

Para ver uma lista completa das permissões necessárias para cada papel, consulte Permissões do IAM necessárias.

Há duas maneiras de migrar as permissões do SOAR:

• Como usar a CLI do Google Cloud
• Como usar o Terraform

Migrar permissões de SOAR usando a Google Cloud CLI

Para migrar suas permissões do SOAR para o IAM do Google Cloud , siga estas etapas:

1. No console do Google Cloud , acesse as configurações de administração do Google SecOps.
2. Clique na guia Migração do IAM do SOAR.
3. Na seção Migrar vinculações de papéis, copie os comandos da Google Cloud CLI. Quando for preciso especificar uma nova condição, selecione 2. Nenhuma. .
4. Na barra de ferramentas do Google Cloud , clique em Ativar o Cloud Shell.
5. Na janela do terminal, cole os comandos da Google Cloud CLI e pressione Enter.
6. Verifique se os scripts foram executados corretamente.
7. Volte ao console do Google Cloud e, na seção Concluiu esta tarefa, clique em Ativar IAM.

Migrar permissões do SOAR usando o Terraform

Para migrar suas permissões do SOAR para o Google Cloud IAM usando o Terraform, siga estas etapas:

1. No console do Google Cloud , acesse as configurações de administração do Google SecOps.
2. Clique na guia Migração do IAM do SOAR.
3. Na seção Migrar vinculações de papéis, copie os comandos da Google Cloud CLI.
4. Acesse o repositório do Terraform e mapeie os comandos da Google Cloud CLI para os equivalentes do Terraform. A tabela a seguir mapeia o comando de criação de papel personalizado da Google Cloud CLI com os comandos do Terraform.

Sinalização do gcloud	Argumento do Terraform	Observações
ROLE_ID (Posicional)	role_id	No Terraform, não inclua o prefixo projects/PROJECT_ID/roles/. Use apenas a string de ID (por exemplo, myCustomRole).
--project	project	O ID do projeto em que o papel personalizado está definido.
--title	title	Um título legível por humanos para o papel.
--description	description	Um resumo da finalidade e das permissões do papel.
--permissions	permissions	gcloud aceita uma string separada por vírgulas. O Terraform requer uma lista de strings: ["perm.a", "perm.b"].
--stage	stage	Valores válidos: ALPHA, BETA, GA, DEPRECATED, DISABLED, EAP.

Observação: verifique se cada --flag da linha de comando está pareada corretamente com o argumento correspondente no bloco de recursos do Terraform.

Exemplo de mapeamento da Google Cloud CLI para o Terraform

Comando da Google Cloud CLI:

gcloud iam roles create SOAR_Custom_managedUser_google.com --project="{customer project}" 
--title="SOAR Custom managedUser Role" 
--description="SOAR Custom role generated for IDP Mapping Group ManagedUser" 
--stage=GA 
--permissions=chronicle.cases.get

Comando do Terraform:

resource "google_project_iam_custom_role" "{terraform_name}" {
  role_id     = "SOAR_Custom_managedUser_google.com"
  title       = "SOAR Custom managedUser Role"
  project     = "{customer project}"
  stage       = "GA"
  permissions = [
    #This is an example!
    "chronicle.cases.get"
  ]
}

Vinculações de política do IAM (atribuir papéis)

Ao usar Google Cloud CLI projects add-iam-policy-binding, você concede um papel específico a um membro específico (usuário, conta de serviço ou grupo). A tabela a seguir mapeia os comandos da Google Cloud CLI com os comandos do Terraform. Mapeie os comandos para atribuir papéis do IAM.

Sinalização do gcloud	Argumento do Terraform	Observações
PROJECT_ID (Posicional)	project	O ID do projeto de destino.
--member	member	A identidade principal (por exemplo, user:email, serviceAccount:email, group:email).
--role	role	O ID do papel. Use o caminho completo para papéis personalizados (projects/ID/roles/NAME) e o nome curto para papéis padrão (roles/NAME).

Exemplo de atribuição de papel

Comando da Google Cloud CLI:

gcloud projects add-iam-policy-binding
 {customer project}
--member="user:[e-mail]" 
--role="projects/{customer project}/roles/SOAR_Custom_managedUser_google.com"

Comando do Terraform:

resource "google_project_iam_member" "{terraform_name}" {
  project = "{customer project}"
  role    = "projects/{customer project}/roles/SOAR_Custom_managedUser_google.com"
  member  = "user:[e-mail]"
}

Observação : o Google não recomenda o uso de google_project_iam_binding (a "vinculação" no singular corresponde ao nome do comando da Google Cloud CLI), porque isso vai remover qualquer outra pessoa que tenha esse papel se ela não estiver listada no seu código. Use google_project_iam_member.

Importante: a coluna Grupo de permissões continua sendo exibida na página Mapeamento de grupos após a migração para compatibilidade com versões anteriores da API SOAR legada. Não exclua essas atividades. A coluna será removida automaticamente até 31 de março de 2027, sem impacto para o cliente.

Migração de postagem

Depois de mudar para as permissões do IAM, cada comando curl usado para chamar uma API precisa ser enviado com uma conta de serviço mapeada (mapeada em grupos de mapeamento de IDP) ou com um usuário que tenha feito login na plataforma pelo menos uma vez.

Perguntas frequentes

• Para uma lista detalhada de problemas e práticas recomendadas, consulte as Perguntas frequentes sobre a migração de papéis do IAM.