Alguns Recursos Comuns
À medida que você se prepara para personalizar o Oracle Cloud Guard, há vários recursos comuns em mais de uma área.
Você pode visualizar esses recursos nas seções a seguir antes de começar a personalizar o Cloud Guard ou pode seguir links de tarefas específicas cujas informações são úteis.
Visão Geral das Receitas
Entenda as diferenças entre receitas gerenciadas pela Oracle e gerenciadas pelo usuário, como funcionam as receitas gerenciadas pelo usuário e quais definições podem ser alteradas nos níveis de receita e destino.
As três seções abaixo também aparecem em Sobre Receitas do Respondedor do OCI e Sobre Receitas do Detector do OCI.
Entenda as diferenças entre essas duas categorias de receitas.
Para detectores e respondedores, o Cloud Guard fornece um rico conjunto de receitas gerenciadas pela Oracle para:
- Detectores de Atividade do OCI
- Detectores de configuração do OCI
- Detectores do OCI Container Security Config
- Detectores de Segurança da Instância do OCI
- Detectores de Ameaças do OCI
- Respondedores
Embora você possa usar as receitas gerenciadas pela Oracle como estão, provavelmente desejará fazer alterações para adaptá-las às necessidades específicas do seu ambiente. Especificamente, talvez você queira alterar o nível de risco associado a algumas regras e desativar outras regras. Para fazer esses tipos de alterações, primeiro clone a receita para fazer uma cópia gerenciada pelo usuário e, em seguida, faça alterações na cópia.
Se novas regras do detector forem adicionadas a uma receita gerenciada pela Oracle, as regras serão adicionadas automaticamente a todas as cópias gerenciadas pelo usuário (clonadas) dessa receita, com os valores padrão da origem gerenciada pela Oracle. Em seguida, você pode modificar a configuração da nova regra nas cópias gerenciadas pelo usuário da receita.
A tabela a seguir mostra um exemplo de três regras do detector da receita gerenciada pela Oracle e como uma cópia gerenciada pelo usuário pode ser modificada. As alterações das regras gerenciadas pelo usuário são mostradas em negrito:
| Receita Gerenciada pela Oracle | Receita Gerenciada pelo Usuário | |||
|---|---|---|---|---|
| Regra | Status | Nível de Risco | Status | Nível de Risco |
| O bucket é público | ATIVADO | ALTO | DESABILITADOS | ALTO |
| Chave KMS não alternada | ATIVADO | MÉDIO | ATIVADO | ALTO |
| A instância tem endereço IP público | ATIVADO | CRÍTICO | ATIVADO | CRÍTICO |
Você pode clonar a mesma receita gerenciada pela Oracle quantas vezes precisar, para criar cópias gerenciadas pelo usuário e ajustadas para finalidades especiais. Alguns motivos para ter diferentes receitas podem incluir:
- Tratamento diferente para cargas de trabalho de produção e não de produção.
- Operações ou processos de notificação distintos para recursos em diferentes compartimentos.
- Requisitos regionais para recursos em alguns compartimentos.
- Diferentes tipos de recursos que exigem regras diferentes para configuração ou atividade.
Entenda como uma receita gerenciada pelo usuário mantém laços com a receita gerenciada pela Oracle da qual ela foi clonada.
- Quando você clona uma receita gerenciada pela Oracle, isso cria uma cópia gerenciada pelo usuário. A cópia gerenciada pelo usuário é exatamente como a original gerenciada pela Oracle, mas você pode personalizá-la.
As alterações feitas na cópia clonada, incluindo alterações nas definições de regra, não afetam a receita original do detector ou do respondedor.
- Não é possível alterar tudo nas receitas gerenciadas pelo usuário. Para regras individuais, você pode alterar o nível de risco e pode ativar e desativar a regra e alterar seu nível de risco. Não é possível excluir regras ou adicionar novas regras.
- Para usar uma receita gerenciada pelo usuário, adicione-a a um destino. Um destino só pode ter uma receita de cada tipo adicionada a ele: detectores de configuração, detectores de atividade e respondedores. Se um destino já tiver uma receita do tipo que você deseja adicionar, será necessário remover essa receita para poder adicionar outra do mesmo tipo. Consulte Editando um Destino do OCI e Suas Receitas Anexadas.
- O Cloud Guard mantém suas receitas gerenciadas pelo usuário em sincronia com as receitas gerenciadas pela Oracle originais. Qualquer nova regra adicionada à receita gerenciada pela Oracle original é adicionada automaticamente às cópias clonadas. E qualquer melhoria feita nas regras na receita gerenciada pela Oracle original é refletida automaticamente nas mesmas regras nas cópias clonadas.
- Observe as novas regras que estão sendo adicionadas às receitas gerenciadas pelo usuário. Qualquer nova regra adicionada é desativada por padrão. Examine as novas regras de perto para ver se você deseja ativá-las. Monitore as Notas da Versão do Cloud Guard para obter essas atualizações.
- Monitorar a lista de regras que você desativou em uma receita gerenciada pelo usuário para ver se alguma precisa ser ativada. Com o passar do tempo, você pode desejar começar a usar algumas receitas que desativou anteriormente. Monitore as Notas da Versão do Cloud Guard para obter essas atualizações.
Entenda como o Oracle Cloud Guard separa as definições de receita em dois níveis e como atualizar diferentes definições para receitas do detector e do respondedor gerenciadas pela Oracle ou gerenciadas pelo usuário (clonadas) nesses dois níveis.
O Cloud Guard separa as definições que você pode configurar para as regras do detector e do respondedor em dois grupos, nível de receita e nível de destino. Você acessa esses níveis em páginas distintas.
Se você não entender os detalhes, o gerenciamento de receitas do detector e do respondedor no Oracle Cloud Guard pode se tornar confuso. A seção Referência de Receita do Detector no final desta seção resume as informações de todos os tipos de receitas, quando acessadas na página Destinos ou nas respectivas páginas de receitas.
Quando você atualiza uma receita gerenciada pela Oracle, as atualizações são aplicadas automaticamente a todas as receitas gerenciadas pelo usuário clonadas com base nela. Independentemente da página que você iniciar quando alterar uma receita, as alterações permanecerão quando você acessar a receita, começando na outra página.
- As definições de Nível de Receita são de natureza estratégica. Ou seja, eles têm o impacto mais amplo, afetando todos os destinos aos quais a receita está anexada. Essas definições devem exigir o nível mais alto de permissões para fazer alterações.
- Princípio de segurança: As definições de receita têm amplo impacto no Cloud Guard e, portanto, menos usuários devem ter permissão para alterar definições nesse nível.
- Definições que você pode alterar no nível da receita:
- Detectores:
- Status (ativar ou desativar regra, somente gerenciado pelo usuário).
- Risk Level (somente gerenciado pelo usuário).
- Labels (somente gerenciado pelo usuário).
- Definição de Entrada (se aplicável à regra).
- Definições de Grupo Condicional.
- Responsáveis:
- Status (ativar ou desativar regra, somente gerenciado pelo usuário).
- Detectores:
- Escopo: Alterações feitas nas regras de detector e de respondedor no nível de receita:
- Alterações de Status (ative ou desative regras):
- Só pode ser feito para receitas gerenciadas pelo usuário (clonadas).
- Aplicar globalmente a todos os destinos nos quais o detector ou o respondedor já foi adicionado ou foi adicionado posteriormente.
- Definições de Grupo Condicional:
- Forneça os valores padrão para todos os destinos em que a receita do detector ou do respondedor é adicionada posteriormente.
- Depois que uma receita é adicionada a um destino, as alterações nas definições do Grupo Condicional só podem ser feitas nesse destino.
- Instruções de Política (somente para regras do respondedor, no nível de destino):
- A ativação de uma instrução de política é global, aplicando-se a todas as regras do respondedor que exigem a política, nos níveis de receita e de destino.
- Você só precisa ativar uma política uma vez em uma tenancy.
- Alterações de Status (ative ou desative regras):
- Acesso: Acesse as regras do detector e do respondedor nas páginas de receita, Destinatário ou Destinatário, para alterar essas definições conforme descrito acima.
- As definições no Nível de Destino são de natureza "tática". Ou seja, eles impactam um único destino apenas; portanto, podem exigir um nível mais baixo de permissões para fazer alterações.
- Princípio de segurança: Os destinos tendem a ter um impacto menor, afetando apenas um subconjunto de seus compartimentos; assim, mais usuários poderão alterar as definições nesse nível.
- Definições que você pode alterar no nível de destino:
- Detectores:
- Grupos Condicionais (somente gerenciados pelo usuário).
- Responsáveis:
- Status (ativar ou desativar regra, somente gerenciado pelo usuário).
- Definições de Entrada, para ativar ou desativar a Notificação Pós-Remediação (se aplicável à regra).
- Altere o Trigger de Regra entre Ex executar automaticamente e perguntar antes....
- Altere outras definições (por exemplo, ative ou desative Instruções de Política Obrigatórias e Notificação de Remediação).
- Detectores:
- Escopo: As alterações feitas nas regras de detector e respondedor no nível de destino se aplicam a:
- Geralmente, as alterações se aplicam ao destino atual. As alterações não afetam as definições nos destinos aos quais o detector ou o respondedor já foi adicionado. Depois que as receitas forem adicionadas a um destino, qualquer alteração adicional nas definições desse destino deverá ser feita no mesmo destino. As alterações feitas posteriormente no nível da receita atualizam automaticamente a receita anexada ao destino.
- Para ativar as políticas obrigatórias e ativar e desativar notificações de remediação (ambas somente para receitas do respondedor), as alterações fornecem os valores padrão de todos os destinos aos quais o detector ou respondedor é adicionado posteriormente.
- Acesso: Acesse as regras do detector e do respondente na página Destinos para alterar essas definições conforme descrito acima.
- Resumo de Limitações Importantes - algumas definições só podem ser alteradas no nível de receita ou de destino ou somente em receitas gerenciadas pela Oracle ou pelo usuário:
- Detectores:
- Status (ativar ou desativar regra) - somente em receitas gerenciadas pelo usuário, no nível da receita.
- Nível de Risco - somente em receitas gerenciadas pelo usuário, no nível da receita.
- Labels - somente na receita gerenciada pelo usuário, no nível da receita.
- Responsáveis:
- Status (Ativar ou Desativar regras) - somente na receita gerenciada pelo usuário, no nível da receita.
- Definições de Entrada, para ativar ou desativar a Notificação Pós-Remediação (se aplicável à regra) - somente no nível de destino (para receitas gerenciadas pela Oracle e pelo usuário).
- Acionador de Regra (entre Executar Automaticamente e Perguntar antes...) - somente no nível de destino (para receitas do respondedor gerenciadas pela Oracle e pelo usuário).
- Detectores:
A tabela a seguir resume quais definições de regra de detector e respondedor você pode alterar nos níveis de receita e de destino, para receitas gerenciadas pela Oracle e pelo usuário.
|
Tipos de Alterações (abaixo) |
Alterações de Receita do Detector Feitas em... | Alterações de Receita do Respondedor Feitas em... | ||||||
|---|---|---|---|---|---|---|---|---|
| Gerenciado pela Oracle | Gerenciado pelo Usuário (Clonado) | Gerenciado pela Oracle | Gerenciado pelo Usuário (Clonado) | |||||
| Página Receitas | Página Destinos | Página Receitas | Página Destinos | Página Receitas | Página Destinos | Página Receitas | Página Destinos | |
| Status (Ativar e Desativar Regras) | Não | Não | Sim | Não | Não | Não | Sim | Não |
| Nível de Risco | Não | Não | Sim | Não | N/A | N/A | N/A | N/A |
| Labels | Não | Não | Sim | Não | N/A | N/A | N/A | N/A |
| Definições de Entrada | Sim | Não | Sim | Não | Não | Sim | Não | Sim |
| Grupos condicionais | Sim | Sim | Sim | Sim | Não | Sim | Não | Sim |
| Ative Instruções de Política | N/A | N/A | N/A | N/A | Não | Sim | Não | Sim |
| Acionador de Regra (Manual ou Execução Automática) | N/A | N/A | N/A | N/A | Não | Sim | Não | Sim |
| Notificação de Remediação (Definição) | N/A | N/A | N/A | N/A | Não | Sim | Não | Sim |
| Para obter Informações, consulte: | Tópico | Tópico | Tópico | Tópico | Tópico | Tópico | Tópico | Tópico |
Você mapeia uma hierarquia de compartimentos para um destino. As receitas do detector anexadas ao destino monitoram os recursos na hierarquia de compartimentos.
Se um compartimento tiver outros compartimentos abaixo dele, as regras da receita do detector se aplicarão automaticamente a todos os compartimentos de nível inferior na hierarquia.
Quando uma hierarquia de compartimentos tiver receitas do detector aplicadas a compartimentos em diferentes níveis, sempre que as regras entrarem em conflito, as regras da receita do detector aplicadas em um nível inferior substituirão as regras de qualquer receita do detector aplicada em um nível superior. Isso se aplica ao compartimento no qual uma receita do detector é aplicada e a todos os compartimentos abaixo dele.
Há quatro níveis nos quais é possível modificar os campos dentro de uma receita de detector e suas regras de detector. Cada uma tem seu próprio conjunto de restrições.
A precedência das regras de receita do detector aplicadas nesses diferentes níveis é semelhante à precedência de uma hierarquia de compartimentos: sempre que houver conflito de regras, aquelas de nível mais específico (maior número na lista abaixo) substituem as de nível mais amplo (menor número na lista abaixo).
- Oracle: Quando o Cloud Guard precisa atualizar ou criar novas receitas gerenciadas pela Oracle, elas estão disponíveis a todos os tenants.
- Tenant: São alterações que só se aplicam a um tenant específico.
- Esses campos podem ser modificados no nível do tenant para uma receita gerenciada pela Oracle:
- Labels (só pode ser adicionado)
- Configuração (também chamadas Definições)
- Condições
- Estes campos não podem ser modificados no nível do tenant para uma receita gerenciada pela Oracle:
- Status (ativado/desativado)
- Nível de Risco
- Esses campos podem ser modificados no nível do tenant para uma receita não gerenciada pela Oracle:
- Status (ativado/desativado)
- Nível de Risco
- Labels
- Configuração (também chamadas Definições)
- Condições
- Esses campos podem ser modificados no nível do tenant para uma receita gerenciada pela Oracle:
- Destino: São alterações aplicáveis apenas a um destino específico.
- Esses campos podem ser modificados no nível de destino para receitas gerenciadas e não gerenciadas pela Oracle:
- Condições
- Esses campos podem ser modificados no nível de destino para uma receita não gerenciada pela Oracle:
- Status (ativado/desativado)
- Nível de Risco
- Labels
- Configuração (também chamadas Definições)
- Esses campos podem ser modificados no nível de destino para receitas gerenciadas e não gerenciadas pela Oracle:
- Subcompartimentos de um destino: São alterações aplicáveis apenas a um compartimento selecionado na árvore descendente de um destino.
- Esses campos podem ser modificados no nível de destino para receitas gerenciadas e não gerenciadas pela Oracle:
- Condições
- Esses campos podem ser modificados no nível de destino para uma receita não gerenciada pela Oracle:
- Status (ativado/desativado)
- Nível de Risco
- Labels
- Configuração (também chamadas Definições)
- Esses campos podem ser modificados no nível de destino para receitas gerenciadas e não gerenciadas pela Oracle:
Usando Grupos Condicionais com Regras de Receita
Os grupos condicionais permitem que você defina rapidamente o escopo cuja regra de detector ou respondedor deve ser ativada.
Grupos condicionais para detectores
Um grupo condicional define parâmetros que você especifica para limitar o escopo de situações nas quais a violação de uma regra do detector realmente dispara um problema:
- Para detectores de configuração, os grupos condicionais permitem a inclusão ou exclusão de recursos específicos do monitoramento.
- Para detectores de atividade, os grupos condicionais permitem limitar os detectores de atividade a determinados espaços de IP, regiões, usuários, grupos ou recursos.
- Para implementar grupos condicionais, quando você estiver modificando uma regra de receita do detector:
- Selecione o Parâmetro, o Operador e a Lista Personalizada ou uma Lista Gerenciada.
- Insira uma ou mais entradas para o Valor a ser correspondido.
- Para definir uma condição em um parâmetro diferente de tags, siga estas etapas:
- Para definir uma condição em tags, siga estas etapas:
- Na lista Parâmetro, selecione Tags.
- Selecione um Operador (Em ou Não Em).
Se você selecionar Em, a regra afetará apenas os itens marcados com uma das tags que estão na lista fornecida.
Se você selecionar Não Está Em, a regra afetará apenas os itens que não estão marcados com uma das tags que estão na lista fornecida.
- selecione Selecionar tags.
- Na caixa de diálogo Selecionar tags, defina uma condição para tags definidas ou de formato livre:
Para definir uma condição para tags definidas, selecione um Namespace de tag diferente de Nenhum, selecione uma Chave de tag e, em seguida, selecione ou informe o Valor de tag:
Para definir uma condição para tags de formato livre, para Namespace de tag, selecione Nenhum para Namespace de tag, informe uma Chave de tag e, opcionalmente, informe o Valor de tag.
Adicione mais tags conforme necessário.Observação
Quando você especificar várias tags, a regra só será imposta se todas as condições forem atendidas.
- Você pode adicionar uma condição para um único recurso e entrada de cada vez usando uma lista personalizada ou adicionar vários recursos e entradas de uma só vez usando listas gerenciadas.
Exemplo: Você tem 10 Instâncias de Computação. Duas instâncias (Instance1 e Instance2) devem ser públicas; portanto, você não deseja que a regra "A instância é acessível ao público" dispare problemas nessas instâncias. Você pode usar grupos condicionais para excluir essas duas instâncias, usando listas personalizadas ou listas gerenciadas.
Com as receitas do detector e do respondedor, algumas regras têm opções de Parâmetro que exigem que você digite uma ou mais entradas de Valor válidas. A lista a seguir fornece links para as origens dos valores válidos para cada tipo de parâmetro. Quando os links não estiverem disponíveis, uma breve explicação de como localizar valores válidos será fornecida.
- IPV4: Partes do Endereço IPv4
- IPV6: Partes do endereço IPv6
- Cidade: Não há um padrão internacional para nomes ou códigos de cidade. O Cloud Guard usa os nomes reais de cidade e não está disponível uma lista completa de nomes de cidade com suporte.
- Estado ou província: Códigos de Estado ou província ISO 3166-2
- País: Códigos alfa-2 ISO 3166-1, conforme mostrado na Lista de códigos de país ISO 3166
- Nome do usuário: Conforme exibido na console do Oracle Cloud Infrastructure
- OCID do Recurso: ID do recurso, conforme exibido na tela da console do OCI para o recurso
- Região: Uma das regiões com suporte do OCI listadas em Sobre Regiões e Domínios de Disponibilidade
- Tags: Você pode usar tags para organizar e listar recursos com base em suas necessidades de negócios. Consulte Visão Geral do Serviço Tagging.
Use listas personalizadas quando o número de itens a serem correspondidos for pequeno e você esperar que não vá precisar reutilizar a mesma lista várias vezes.
- Abra a página de detalhes da receita do detector em que a regra "A instância é acessível ao público" está ativada.
Consulte Editando uma Receita do Detector do OCI Gerenciada pelo Usuário.
- Na página de detalhes da receita do detector, em Regras do Detector, localize a linha da regra "A instância é acessível ao público".
- No final direito dessa linha, abra o menu Ações
e selecione Editar. - Na seção Editar Regra do Detector, Grupo Condicional:
- Defina Parâmetro como OCID da Instância.
- Defina Operador como Não em.
- Defina Lista como Lista Personalizada.
- Em Valor, digite o OCID para Instance1.
- selecione Adicionar Condição.
- Na nova linha de condição:
- Defina Parâmetro como OCID da Instância.
- Defina Operador como Não em.
- Defina Lista como Lista Personalizada.
- Em Valor, digite o OCID para Instance2.
- selecione Salvar.
A regra "A instância está acessível ao público" agora monitora a configuração pública de todas as instâncias, exceto Instance1 e Instance2.
Use listas gerenciadas quando o número de itens a serem correspondidos for grande ou você precisar reutilizar a mesma lista várias vezes.
- Primeiro, crie uma lista gerenciada de OCIDs de instância que contenha os OCIDs de Instance1 e Instance2.
Consulte Criando uma Lista Gerenciada.
Vamos supor que você nomeie essa lista como "OCIDs da Instância de Computação Pública".
- Abra a página de detalhes da receita do detector em que a regra "A instância é acessível ao público" está ativada.
Consulte Editando uma Receita do Detector do OCI Gerenciada pelo Usuário.
- Na página de detalhes da receita do detector, em Regras do Detector, localize a linha da regra "A instância é acessível ao público".
- No final direito dessa linha, abra o menu Ações e selecione Editar.
- Na seção Editar Regra do Detector, Grupo Condicional:
- Defina Parâmetro como OCID da Instância.
- Defina Operador como Não em.
- Defina Lista como Lista Gerenciada.
- Em Valor, selecione o nome da lista gerenciada que você criou ("OCIDs da Instância de Computação Pública" no exemplo da etapa 1).
- selecione Salvar.
A regra "A instância está acessível ao público" agora monitora a configuração pública de todas as instâncias, exceto Instance1 e Instance2.
Observação
Qualquer OCID de Instância de Computação que você adicionar à sua lista gerenciada no futuro também será excluído do monitoramento.
Usando Listas Gerenciadas e Personalizadas com Regras de Receita
As listas gerenciadas permitem que você defina rapidamente o escopo ao qual uma regra de receita deve ser aplicada, incluindo ou excluindo uma lista predefinida de parâmetros. As listas personalizadas permitem que você digite uma lista curta de parâmetros para a mesma finalidade.
Exemplo: Se uma instância de computação tiver um endereço IP público, você deverá disparar um problema. Mas você tem algumas instâncias que devem ter endereços IP públicos e não quer que essas instâncias disparem problemas.
- Crie uma lista gerenciada contendo todos os OCIDs de recursos das instâncias de computação que devem ter endereços IP públicos.
Consulte Criando uma Lista Gerenciada.
- Designe esta lista gerenciada como entrada de Grupo Condicional para a regra do detector de configuração "A instância tem um IP público".
Consulte Editando uma Receita do Detector do OCI Gerenciada pelo Usuário.
Exemplo: Se a atividade iniciada por endereços IP suspeitos específicos criar um bucket ou uma instância, você vai querer disparar um problema.
- Crie uma lista gerenciada contendo os endereços IP suspeitos conhecidos.
Consulte Criando uma Lista Gerenciada.
- Designe essa lista gerenciada como entrada de Grupo Condicional para a regra de detector "Atividade de IP Suspeito".
Consulte Editando uma Receita do Detector do OCI Gerenciada pelo Usuário.
Como alternativa, se você souber que os buckets ou as instâncias só deverão ser criados com base em determinados endereços IP confiáveis, poderá:
- Crie uma lista gerenciada de endereços IP confiáveis.
- Em seguida, use o operador "Not In" na entrada Grupo Condicional para a regra de detector "atividade de IP suspeito".