Visão Geral do Oracle Operator Access Control
Saiba como controlar, auditar e revogar o acesso da equipe de serviço da Oracle à sua infraestrutura usando o Oracle Operator Access Control.
- O que é Oracle Operator Access Control?
O Oracle Operator Access Control permite conceder, auditar e revogar o acesso que a Oracle tem ao seu Exadata Infrastructure, o Exadata Infrastructure que hospeda um Oracle Autonomous Database no Exadata Cloud@Customer e o Autonomous Exadata VM Cluster (máquinas virtuais clientes implantadas no Oracle Autonomous Database no Exadata Cloud@Customer) administrados pela Oracle, além de obter relatórios de auditoria de todas as ações executadas por um operador humano, quase em tempo real. - Termos Associados ao Operator Access Control
Saiba mais sobre quais termos são usados com o Operator Access Control. - Quais Opções de Controle o Oracle Operator Access Control Fornece?
Você cria políticas que especificam qual conjunto de Ações os operadores podem executar em sua infraestrutura. - Aplicação de Ações no Operator Access Control
Saiba como aplicar controles nas operações que um operador Oracle pode executar em seu ambiente. - Limites do Operator Access Control
O Operator Access Control é uma solução projetada para auditoria e conformidade do acesso da Oracle, não uma solução de conformidade de finalidades gerais. - Atribuições de Job da Tenancy do Cliente do Operator Access Control
Para estabelecer o controle de acesso do operador, configure políticas de controle de acesso e estabeleça grupos de usuários responsáveis por gerenciar e monitorar o acesso à sua infraestrutura. - Encaminhando Logs de Auditoria do Operator Access Control a Sistemas SIEM
Você pode optar por encaminhar os logs de auditoria do Operator Access Control diretamente do Exadata Cloud@Customer para os sistemas SIEM (Security Information and Event Management) no seu data center.
O que é Oracle Operator Access Control?
O Oracle Operator Access Control permite conceder, auditar e revogar o acesso que a Oracle tem ao seu Exadata Infrastructure, o Exadata Infrastructure que hospeda um Oracle Autonomous Database no Exadata Cloud@Customer e o Autonomous Exadata VM Cluster (máquinas virtuais clientes implantadas no Oracle Autonomous Database no Exadata Cloud@Customer) administrados pela Oracle, além de obter relatórios de auditoria de todas as ações executadas por um operador humano, em tempo real.
Oracle Operator Access Control para Exadata Cloud@Customer
- Você é responsável por ações em suas máquinas virtuais e pelo gerenciamento diário de bancos de dados e aplicativos executados nas suas máquinas virtuais.
- A Oracle é responsável pelos componentes de infraestrutura: energia, sistema operacional bare-metal, hipervisores, Exadata Storage Servers e outros aspectos do ambiente de infraestrutura.
No entanto, se você tiver requisitos regulamentares para auditar e controlar todos os aspectos do gerenciamento do sistema, o modelo de responsabilidade compartilhada criará um problema. Você precisa provar aos seus reguladores que está no controle completo dos seus sistemas e está operando seus sistemas de acordo com essas regulamentações de conformidade.
Como você pode controlar e auditar todas as ações executadas em componentes de infraestrutura por qualquer operador ou software em seus sistemas? Como você pode manter o mesmo nível de auditorias e controle de acesso aos seus sistemas e fornecer os registros de auditoria necessários para auditorias regulatórias internas ou externas em todos os seus sistemas? Para resolver esse problema, a Oracle fornece o Oracle Operator Access Control como solução para restringir o acesso irrestrito dos operadores Oracle aos seus sistemas.
Operator Access Control para Oracle Autonomous Database no Exadata Cloud@Customer
O Operator Access Control foi expandido de modo a fornecer controles para máquinas virtuais clientes implantadas no Oracle Autonomous Database no Exadata Cloud@Customer. Semelhante ao controle de acesso do Operador para a Infraestrutura do Exadata Cloud@Customer, os clientes agora podem impor controles de acesso do operador Oracle em seus clusters de Máquina Virtual Autônoma implantados no Exadata Cloud@Customer.
- Provisionamento de recursos do Autonomous Database
- Backup de bancos de dados
- Recuperação de um banco de dados
- Aplicação de patches upgrade
- Dimensionamento
- Monitoramento da integridade do serviço
- Auditoria
- Alertas e Notificações
O cliente não tem acesso ao sistema operacional cliente, acesso sys/system a seus bancos de dados contêineres ou acesso aos logs do sistema. E o cliente está limitado a monitorar a integridade e o desempenho dos aplicativos e a segurança deles em todos os níveis. Por outro lado, os operadores Oracle, como gerentes, têm acesso completo e sem restrições a todos os componentes, incluindo acesso raiz ao hipervisor e às VMs clientes.
O modelo de responsabilidade compartilhada do banco de dados autônomo apresenta vários desafios operacionais para clientes regulamentados que precisam manter o controle de todos os dados e infraestrutura, independentemente do fornecedor e do modelo de implantação (local, hospedado ou na nuvem). Os clientes regulamentados passam por seu próprio exame de conformidade e formulam suas próprias diretrizes de segurança que podem levar anos para fortalecer e colocar em prática.
Isso vale especialmente para os clientes corporativos da Oracle que são altamente regulamentados e executam seus sistemas mais críticos, seus aplicativos mais sensíveis à segurança no sistema Oracle. Para resolver esse problema, a Oracle fornece o Oracle Operator Access Control como solução para restringir o acesso irrestrito dos operadores Oracle aos seus sistemas.
Oracle Operator Access Control para Oracle Cloud Infrastructure
O Oracle Operator Access Control é um sistema de auditoria de conformidade que permite manter um gerenciamento rigoroso e trilhas de auditoria de todas as ações executadas por um operador Oracle na infraestrutura.
- Conceder acesso à sua infraestrutura, incluindo quem pode acessar a infraestrutura, quando o sistema pode ser acessado e por quanto tempo a equipe da Oracle pode acessar o sistema.
- Exibir e salvar um relatório quase em tempo real de todas as ações que um operador Oracle executa em seu sistema.
- Limitar o acesso, incluindo a limitação de quais ações um operador Oracle pode executar em seu sistema.
- Revogar o acesso, incluindo o acesso que você concedeu anteriormente.
Operator Access Control para o Compute Cloud@Customer
A infraestrutura do Compute Cloud@Customer se baseia no princípio de que o cliente é o 'usuário' das VMs e dos serviços que ele cria e executa na infraestrutura, e a Oracle é o 'gerente' da própria infraestrutura. Por 'gerenciamento' significa tarefas típicas, como atualização, aplicação de patches e monitoramento para os componentes de infraestrutura.
O cliente não tem acesso a instâncias de SO virtuais ou bare-metal de infraestrutura em componentes de infraestrutura nem software de gerenciamento que são executados nessas instâncias. Por outro lado, o Oracle Ops, como gerente, tem acesso completo e sem restrições a todos os componentes, incluindo acesso raiz ao hypervisor e Servidores de Plano de Controle.
Esse modelo apresenta vários desafios operacionais para clientes regulamentados que precisam manter o controle de todos os dados e infraestrutura, independentemente do fornecedor e do modelo de implantação (local, hospedado ou na nuvem). Os clientes regulamentados passam por seu próprio exame de conformidade e formulam suas próprias diretrizes de segurança que podem levar anos para fortalecer e colocar em prática. Isso vale especialmente para os clientes corporativos da Oracle que são altamente regulamentados e executam seus sistemas mais críticos, seus aplicativos mais sensíveis à segurança no sistema Oracle.
O Operator Access Control foi estendido para dar suporte a esses objetivos de conformidade do cliente e permitir que eles traga seus bancos de dados de missão crítica para o Oracle Cloud, de forma que os clientes acabem por controlar o acesso a seus sistemas dedicados.
Tópico pai: Visão Geral do Oracle Operator Access Control
Termos Associados ao Operator Access Control
Saiba mais sobre quais termos são usados com o Operator Access Control.
Operador: Um funcionário da Oracle que é membro de uma tenancy do grupo de operadores (grupo Ops) no Oracle Cloud Infrastructure (OCI). Por exemplo, um operador pode ser um funcionário da Oracle no grupo Exadata Cloud@Customer_ops ou no grupo ExaCS_ops. A tenancy do grupo Ops é um conjunto de tenancies no OCI que têm permissão para administrar os controles de operação. Os grupos Ops e os operadores que são membros desses grupos não têm qualquer privilégio padrão diferente da capacidade de solicitar acesso à infraestrutura. Os grupos e a associação nos grupos de operadores são rigorosamente controlados pela Oracle.
Usuário: Um usuário do OCI da tenancy em cujo sistema Exadata Cloud@Customer os controles são colocados.
Camada do Exadata Infrastructure: Várias camadas físicas ou operacionais do sistema Exadata. No momento, definido como Servidor de Plano de Controle, Host, VM Convidada, servidores de célula, switches e ILOM.
Ação: Um conjunto nomeado e predefinido de comandos, arquivos ou redes que pode ser acessado em uma determinada camada. A Oracle define as ações.
Controle do Operador: Uma entidade definida pelo cliente, que contém um agrupamento de ações pré-aprovadas, e ações que exigem aprovação explícita do grupo de aprovação para permitir acesso. O grupo de aprovadores é um grupo de usuários padrão do IAM que lista o conjunto de usuários que têm permissões para aprovar ou revogar o acesso.
Atributos do Operador: Em determinados casos, o controle do operador pode definir critérios para os operadores que têm permissão para acessar a infraestrutura.
Designação de Controle de Operador: Esse é o processo pelo qual um sistema Exadata Cloud@Customer é anexado a um controle de operador nomeado. Em determinado momento, somente um controle do operador pode ser aplicado em um sistema Exadata Cloud@Customer. A designação pode ser permanente ou por uma duração específica. Se um controle do operador não for designado a um sistema Exadata Cloud@Customer, o sistema Exadata Cloud@Customer será executado com um controle de operador padrão que permite todo o acesso necessário para diagnósticos e manutenção.
Solicitação de Acesso: A solicitação de acesso é o processo pelo qual um operador solicita permissão para acessar uma infraestrutura Exadata identificada. A infraestrutura Exadata é identificada pelo OCID. A solicitação identifica a ação exigida pelo operador.
Aprovar/Rejeitar Solicitação de Acesso: A aprovação/rejeição de acesso é o processo pelo qual um usuário competente, conforme determinado pelo controle do operador implantado na infraestrutura Exadata, pode conceder ou rejeitar uma solicitação de acesso.
Revogar Solicitação de Acesso: Um usuário competente pode revogar uma solicitação de acesso a qualquer momento. Essa ação remove imediatamente as sessões do operador conectado à infraestrutura Exadata com base nessa solicitação de acesso.
Solicitação de Acesso em Revisão: Confirme uma Solicitação de Acesso do Operador Oracle Gerada e informe ao solicitante que a solicitação de acesso está sendo revisada.
Tópico pai: Visão Geral do Oracle Operator Access Control
Quais Opções de Controle o Oracle Operator Access Control Fornece?
Você cria políticas que especificam qual conjunto de operadores de Ações podem ser executados em sua infraestrutura.
Uma Ação coloca restrições sobre o que um operador Oracle tem permissão para fazer na infraestrutura gerenciada pela Oracle. Essas restrições incluem controle sobre a execução de comandos shell do sistema operacional e scripts Oracle. As ações também colocam restrições à capacidade dos operadores Oracle de executar arquivos binários, scripts shell e scripts Perl ou Python que estão fora do escopo da função definida pela Ação. Quando você concede permissões por meio de uma Ação, cada ação executada por um operador Oracle é registrada em log. Você pode auditar os logs como parte da sua política de requisitos de restrição MAC.
Política é um conjunto de ações que você especifica para implementar restrições de MAC (Mandatory Access Control) na capacidade de os operadores Oracle executarem manutenção nos sistemas. Para definir suas políticas, esta é uma lista de controles de acesso específicos que você pode aplicar por meio de Ações:
- Configure controles de operador para gerenciamento de operadores Oracle:
- Controles do operador para restringir perfis de acesso em um determinado tipo de recurso em sua tenancy. Por exemplo, você pode configurar políticas distintas para recursos como sua máquina virtual (VM), o servidor de banco de dados de infraestrutura Oracle, o servidor de plano de controle ou a rede InfiniBand. Além disso, você pode configurar políticas para associar controles de acesso a um grupo de recursos em sua tenancy.
- Configure um grupo administrador de usuários associados a cada controle do operador. Os membros desses grupos podem aprovar, alterar ou negar solicitações de acesso em um recurso no qual você implantou um controle do operador.
- Configure Ações para acesso a recursos que você define como pré-aprovados, sem precisar configurar um grupo de usuários administrativos para controlar o acesso.
- Especifique a autorização de solicitação obrigatória antes de permitir acesso a recursos. Por exemplo:
- Quando um conjunto de ações é marcado como pré-aprovado, qualquer solicitação de acesso que especifique apenas um subconjunto dessas ações será automaticamente aprovada e a equipe da Oracle poderá acessar os componentes de infraestrutura.
- Quando uma política de acesso não está definida como pré-aprovada, o acesso aos compartimentos é negado à equipe Oracle até que você conceda explicitamente solicitações de acesso.
- Revogue o acesso à sua infraestrutura que você concedeu anteriormente:
- Os limites de tempo automáticos revogam qualquer acesso que você conceda a um recurso. Quando você concede uma solicitação de acesso, um operador Oracle recebe um ID de usuário exclusivo para o acesso concedido por tempo limitado. Quando esse limite de tempo é atingido, todo o acesso da Oracle ao seu sistema relacionado à solicitação de acesso aprovada é revogado. Se for necessário mais tempo, um operador Oracle poderá enviar uma solicitação de extensão.
- Revogue manualmente o acesso que já foi concedido a um recurso antes da expiração do acesso concedido anteriormente.
- Audite todas as ações que um operador humano executa em seus recursos:
-
Todas as entradas e comandos do teclado executados pelo agente humano são auditados. Você obtém acesso total a todos os logs de auditoria do Linux.
Você pode solicitar a auditoria de um operador humano Oracle específico em seu sistema.
Observação
A identidade do operador humano não está disponível para você como cliente Oracle. No entanto, o sistema Oracle Operator Access Control mantém registros de serviço do operador humano para que a Oracle possa correlacionar o operador humano com uma solicitação de acesso específica que você concedeu para serviço em sua tenancy. Se você suspeitar de ação maliciosa e exigir uma auditoria, a Oracle poderá usar essa solicitação para revisar todas as ações do operador humano específico que executou as ações permitidas por uma solicitação de acesso.
-
Tópico pai: Visão Geral do Oracle Operator Access Control
Aplicação de Ações no Operator Access Control
Saiba como aplicar controles nas operações que um operador Oracle pode executar em seu ambiente.
- O que é Aplicação de Ações?
As Ações do Operator Access Control limitam os privilégios que o operador tem ao executar comandos, acessar recursos e alterar o estado do sistema. - Ações do Controle de Acesso do Operador: Exadata Infrastructure
As ações definem as operações que um operador pode executar na infraestrutura do Exadata Cloud@Customer que são limitadas a servidores de host, célula e Control Plane Servers. - Ações do Controle de Acesso do Operador: Cluster de VMs Autônomas
Além do Acesso Total ao Sistema, use as gaiolas de acesso limitado, Diagnósticos e Manutenção para exibir logs e executar tarefas relacionadas ao serviço. - Ações do Controle de Acesso do Operador: Compute Cloud@Customer
Ocasionalmente, os operadores autorizados precisam acessar recursos para fazer upgrade do Compute Cloud@Customer, solucionar problemas ou ajudar a resolver um problema.
Tópico pai: Visão Geral do Oracle Operator Access Control
O que é Aplicação de Ações?
As Ações do Operator Access Control limitam os privilégios que o operador tem ao executar comandos, acessar recursos e alterar o estado do sistema.
Uma Ação define as permissões, o recurso e o acesso de alteração do sistema que um operador Oracle recebe para executar uma determinada faixa de tarefas para funções administrativas específicas em uma infraestrutura Exadata em um ambiente gerenciado usando o Operator Access Control. Os comandos que uma Ação permite podem ser comandos do Oracle Linux ou comandos do servidor de célula.
Os recursos aos quais uma Ação concede acesso são arquivos e rede. As alterações no sistema correspondem a uma alteração de estado no sistema operacional ou a uma alteração de estado no software em execução nesses sistemas. A alteração de estado é uma consequência de reinicializações ou modificações de configuração.
A aplicação de ações se baseia em Solicitações de Acesso aprovadas, que configuram uma política limitada por tempo, cujas alterações você deseja permitir que um operador Oracle implemente, conforme definido por um conjunto de Ações concedidas aos operadores. Cada solicitação de acesso cria uma credencial de usuário temporária na infraestrutura do Exadata. A política de acesso definida é baseada nas Ações aprovadas na Solicitação de Acesso, anexada ao usuário temporário criado.
As aplicações de Ações geralmente são uma função do sistema operacional. Uma política de aplicação de Ações é criada para uma instância do sistema operacional, como em todos os hosts, servidores de célula e Servidores de Plano de Controle. As Ações concedidas com uma política são removidas depois que a Solicitação de Acesso se torna inválida, porque a Solicitação de Acesso está fechada ou porque a tarefa de administração está concluída, foi revogada ou expirou.
A aplicação de Ações pode ser aplicada a outra infraestrutura, como um sistema operacional, ou a outro software, como cellcli.
Tópico pai: Aplicação de Ações no Operator Access Control
Ações do Operator Access Control: Exadata Infrastructure
As ações definem as operações que um operador pode executar na infraestrutura do Exadata Cloud@Customer que são limitadas a hosts, servidores de célula e Servidores de Plano de Controle.
As ações se aplicam à infraestrutura do Exadata Cloud@Customer como um todo. As ações controlam as ações do operador Oracle em várias camadas do Exadata Cloud@Customer. As camadas controladas na versão atual são servidores de célula, Domínio de Gerenciamento (host) e Servidores de Plano de Controle. As ações são organizadas pelos requisitos, o que leva à solicitação de ações e ao impacto crítico que essas ações potencialmente geram.
As ações traduzem as permissões do Oracle Linux no sistema Exadata Cloud@Customer de destino. As permissões são categorizadas em privilégios do sistema de arquivos, privilégios de execução de comando e privilégios su ou sudo. As ações são categorizadas pela natureza da alteração que pode ser feita pelo operador no sistema Exadata Cloud@Customer.
- Ação: Somente Servidor de Plano de Controle (CPS)
Somente Servidor de Plano de Controle (CPS), que é identificado comoINFRA_CPS_ONLY, destina-se a ser usado apenas para diagnosticar e resolver problemas de CPS. A equipe da Oracle é impedida de acessar componentes além do CPS, incluindo servidores de célula e sistema operacional do host (Dom0). - Ação: Diagnóstico do Sistema
Identificado comoINFRA_DIAGe deve ser usado para diagnosticar qualquer problema na camada de infraestrutura do Exadata Cloud@Customer. - Ação: Manutenção do Sistema com Privilégios de Reinicialização
Identificado comoINFRA_UPDATE_RESTART, destina-se a ser usado em cenários de acesso do operador que exigem uma alteração da configuração do sistema ou uma reinicialização do sistema. - Ação: Manutenção do Sistema com Acesso a Dados/Privilégios de Controle de VM
Manutenção do Sistema com Acesso a Dados/Privilégios de Controle de VM, que é identificado comoINFRA_HYPERVISOR, deve ser usado em cenários de diagnóstico e manutenção nos quais o gerenciamento de VMs no host é obrigatório. - Ação: Acesso Total ao Sistema
, que é identificado comoINFRA_FULLpermite acesso às contas-raiz nos componentes de infraestrutura.
Tópico pai: Aplicação de Ações no Operator Access Control
Ação: Control Plane Server (CPS) Somente
Somente CPS (Control Plane Server), que é identificado como INFRA_CPS_ONLY, deve ser usado para diagnosticar e resolver problemas de CPS. A equipe da Oracle é impedida de acessar componentes além do CPS, incluindo servidores de célula e sistema operacional do host (Dom0).
Tabela 1-1 Ações Ativadas com INFRA_CPS_ONLY
| Nome da Ação |
Somente CPS (Control Plane Server) |
| Identificador da Ação |
|
| Privilégios do Operador |
Privilégio de Usuário do Linux: Não raiz É possível su para carteira raiz: Sim Pode su em: Nenhum sudo usuário + lista de comandos: Limitado à lista fornecida acima Privilégios do servidor de célula: Não Sistema operacional do host (Dom0): Não Privilégios de Rede: Não Lista de comandos executáveis: Esses comandos podem ser executados diretamente no prompt do Bash.
Diretórios e arquivos com acesso explícito de Leitura e Gravação:
Comandos Especiais do Operator Access Control: Comandos de gaiola para exibir ou modificar (leitura, leitura/gravação) arquivos ou diretórios mencionados acima:
|
Ação: Diagnósticos do Sistema
O Diagnóstico do Sistema, identificado como INFRA_DIAG, deve ser usado para diagnosticar qualquer problema na camada de infraestrutura do Exadata Cloud@Customer.
O diagnóstico envolve leitura de logs, execução de diagnósticos e monitoramento de comandos. Esta ação também se destina a corrigir problemas com agentes de diagnóstico no sistema Exadata Cloud@Customer. A correção envolve reiniciar daemons de diagnóstico com parâmetros potencialmente modificados.
A ação Diagnóstico do Sistema não apresenta riscos de exposição de dados do cliente e riscos de baixa disponibilidade.
- O operador use
cat,grepe assim por diante para ler arquivos de log do sistema operacional, software de infraestrutura e software de orquestração na nuvem. - O operador execute comandos de diagnóstico do Oracle Linux, como
topenetstat. - Em servidores de célula, também permite que o operador execute comandos
cellclipara obter informações de diagnóstico. - O operador acesse o gerenciamento da infraestrutura de orquestração na nuvem no Control Plane Server com a capacidade de reiniciar todos os daemons no Control Plane Server.
Tabela 1-2 Ações Ativadas com INFRA_DIAG
| Nome da Ação |
Diagnóstico do Sistema |
| Identificador da Ação |
|
| Privilégios do Operador |
Privilégio de usuário do Oracle Linux: Não raiz. É possível alternar de su para root: Não carteira raiz: Sim Pode su em:
Executar como raiz:
Privilégios do Servidor de Célula: Agir como monitor de célula. Privilégios de Rede: Pode usar SSH em todos os hosts, servidores de célula e Servidores de Plano de Controle. O nome do usuário é o mesmo em todos eles. Lista de comandos executáveis:
Diretórios e arquivos com acesso explícito de Leitura e Gravação:
|
Ação: Manutenção do Sistema com Privilégios de Reinicialização
A Manutenção do Sistema com Privilégios de Reinicialização, identificada como INFRA_UPDATE_RESTART, deve ser usada em cenários de acesso do operador que exigem uma alteração na configuração do sistema ou uma reinicialização do sistema.
Os cenários INFRA_UPDATE_RESTART geralmente são para manutenção. No entanto, pode haver cenários de diagnóstico em que essa ação também é necessária. As alterações de configuração do sistema envolvem alterações de configuração de rede, de hardware e do sistema operacional, como montagens, inodes, ulimits, ou alterações de configuração de software de orquestração da nuvem. A inicialização do sistema autoriza o operador Oracle a reiniciar o sistema operacional (host, servidor de célula), a reiniciar subsistemas específicos, como a rede, e a reiniciar discos de célula.
Cuidado:
Lembre-se de que a ação Manutenção do Sistema com Privilégios de Reinicialização permite reinicializações de componentes de infraestrutura (servidores de banco de dados, servidores de armazenamento e servidores de plano de controle) e impede o acesso a VMs do cliente, dados do cliente e o serviço de auditoria de infraestrutura.- Permite que o operador Oracle execute atividades de manutenção do sistema com privilégios
root. O operador não pode se tornarroot, mas pode executar comandos de manutenção comoroot. - Não permite que o operador altere os parâmetros de auditoria nem acesse os logs de auditoria. No entanto, a ação permite que o operador coloque off-line todo o sistema Exadata Cloud@Customer.
- Permite que os operadores alterem a configuração do sistema operacional por meio de alterações permanentes. Por exemplo, o operador Oracle pode alterar
/etc/ parameters. - Permite que o operador Oracle inicie processos de daemon e gerencie discos de célula usando o privilégio de administrador de células
cellclinos servidores de célula. - Permite que o operador Oracle acesse e gerencie a infraestrutura de orquestração da nuvem no Control Plane Server, com a capacidade para reiniciar todos os daemons no Control Plane Server.
Herança: Todos os privilégios de Diagnóstico do Sistema
Tabela 1-3 Ações Ativadas com INFRA_UPDATE_RESTART
| Nome da Ação |
Manutenção do Sistema com Privilégios de Reinicialização |
| Identificador da Ação |
|
| Privilégios do Operador |
Igual ao privilégio de Diagnóstico do Sistema + o seguinte: É possível alternar de su para root: Não carteira raiz: Sim Pode su em:
Executar como raiz:
Privilégios do servidor de célula: Privilégios de Rede: Pode usar SSH em todos os hosts, servidores de célula e Servidores de Plano de Controle. O nome do usuário é o mesmo em todas essas camadas Lista de comandos executáveis:
Diretórios e arquivos com acesso explícito de Leitura e Gravação:
|
Ação: Manutenção do Sistema com Privilégios de Acesso a Dados/Controle de VM
Manutenção do Sistema com Privilégios de Acesso a Dados / Controle de VM, que é identificado como INFRA_HYPERVISOR, deve ser usado em cenários de diagnóstico e manutenção nos quais o gerenciamento de VMs no host é obrigatório.
A ação Manutenção do Sistema com Privilégios de Acesso a Dados/Controle de VM deve ser usada em cenários de diagnóstico e manutenção nos quais o gerenciamento de VMs no host é obrigatório. Todos os dados na VM Convidada são tratados como dados do cliente. Como o gerenciamento de VMs envolve a capacidade de acessar os dados da VM, essa ação potencialmente apresenta risco aos dados. No entanto, essa ação não permite acesso às chaves TDE dos dados armazenados nos servidores de célula. O gerenciamento de VMs é obrigatório nos casos em que há problemas com a infraestrutura de software de VMs ou em que uma configuração de VMs precisa ser modificada. A configuração envolve o aspecto externo das VMs, como as redes anexadas, os discos anexados ou os recursos (CPU, Memória) alocados.
A Manutenção do Sistema com privilégios de acesso aos Dados/controle de VM impede o acesso ao subsistema de auditoria de infraestrutura.
- Permite que o operador execute comandos de gerenciamento Xen/KVM com privilégios
root. O operador não pode se tornarroot. Esta ação só se aplica ao host. - Herda os privilégios da ação "Manutenção do Sistema com Privilégios de Reinicialização".
- Não permite que o operador altere os parâmetros do sistema operacional do host ou dos servidores de célula. No entanto, isso permite que o operador faça shutdown da VM Convidada e altere significativamente a configuração da VM Convidada.
Herança: Todos os privilégios da Manutenção do Sistema com Reinicialização.
Tabela 1-4 Ações Ativadas com INFRA_HYPERVISOR
| Nome da Ação |
Manutenção do Sistema com Privilégios de Acesso a Dados/Controle de VM |
| Identificador da Ação |
|
| Privilégios do Operador |
Igual aos privilégios de "Manutenção do Sistema com Reinicialização" + o seguinte: Privilégio de usuário do Oracle Linux: Não raiz. É possível alternar de su para root: Não carteira raiz: Sim Pode su em: Executar como raiz:
Privilégios do Servidor de Célula: Privilégios de Rede: Pode usar SSH em todos os hosts, servidores de célula e Servidores de Plano de Controle. O nome do usuário é o mesmo em todos eles. Lista de comandos executáveis:
Diretórios e arquivos com acesso explícito de Leitura e Gravação:
|
Ação: Acesso Total ao Sistema
O Acesso Total ao Sistema, identificado como INFRA_FULL, permite o acesso às contas root nos componentes de infraestrutura.
A ação Acesso Total do Sistema deve ser usada quando o acesso total à infraestrutura do Exadata Cloud@Customer é obrigatório. O acesso é sempre limitado a camadas de VM não Convidadas. Acesso total aqui significa os privilégios raiz em cada instância do sistema operacional no sistema Exadata Cloud@Customer, diferente de VMs Convidadas.
A ação Acesso Total ao Sistema permite que o operador se torne o usuário raiz na infraestrutura. Isso permite que o operador acesse e modifique qualquer registro de memória, qualquer arquivo, qualquer dispositivo e o subsistema de auditoria.
Tabela 1-5 Ações Ativadas com INFRA_FULL
| Nome da Ação |
Acesso Total ao Sistema |
| Identificador da Ação |
|
| Privilégios do Operador |
Privilégio de Usuário do Linux: Não raiz É possível fazer su para carteira raiz: Não Diretórios Legíveis: Todos Arquivos Legíveis: Todos Diretórios Graváveis: Todos Arquivos Graváveis: Todos Lista de comandos executáveis: Todos É possível fazer su em: usuário sudo + lista de comandos: Sem restrição Privilégios do servidor de célula: Privilégios de Rede: Pode usar SSH em todos os hosts, servidores de célula e Servidores de Plano de Controle. O nome do usuário é o mesmo em todos eles. Além disso, estabeleça conexão com |
Ações do Operator Access Control: Cluster de VMs Autônomas
Além do Acesso Total ao Sistema, use as gaiolas de acesso limitadas, Diagnóstico e Manutenção, para exibir logs e executar tarefas relacionadas ao serviço.
- Ação: Acesso Total ao Sistema do Cluster de VMs do Autonomous Exadata
O Acesso Total ao Sistema do Cluster de VMs do Autonomous Exadata, que é identificado comoAVM_FULL, será usado raramente se nenhum dos privilégios de acesso inferior puder resolver o problema. - Ação: Diagnóstico do Sistema de Cluster de VMs do Autonomous Exadata
Diagnósticos do Sistema de Cluster de VMs do Autonomous Exadata, que são identificados comoAVM_SYS_DIAG, devem ser usados para exibir logs. - Ação: Manutenção do Sistema de Clusters de VMs do Autonomous Exadata
A Manutenção do Sistema de Clusters de VMs do Autonomous Exadata, que é identificada comoAVM_SYS_MAINT, deve ser usada para fazer alterações relacionadas ao serviço.
Tópico pai: Aplicação de Ações no Operator Access Control
Ação: Acesso Completo ao Sistema do Cluster de VMs Autônomas do Exadata
O Acesso Total ao Sistema do Cluster de VMs do Autonomous Exadata, que é identificado como AVM_FULL, será usado raramente se nenhum dos privilégios de acesso mais baixos puder resolver o problema.
A ação Acesso Total ao Sistema do Cluster de VMs do Autonomous Exadata deve ser usada quando o acesso total às VMs Convidadas for necessário. Acesso total aqui significa os privilégios root para as VMs Convidadas.
A ação Acesso Total ao Sistema apresenta riscos extremos de disponibilidade e exposição de dados, que podem ser persistentes. A ação também oferece a capacidade de impedir a exportação de logs de auditoria do sistema.
Tabela 1-6 Ações Ativadas com AVM_FULL
| Nome da Ação |
Acesso Total ao Sistema |
| Identificador da Ação |
|
| Privilégios do Operador |
Privilégio de Usuário do Linux: Não raiz É possível fazer su para Colocado no cage com a operação chroot: Não Diretórios Legíveis: Todos Arquivos Legíveis: Todos Diretórios Graváveis: Todos Arquivos Graváveis: Todos Lista de comandos executáveis: Todos É possível fazer su em: usuário sudo + lista de comandos: Sem restrição |
Ação: Diagnóstico do Sistema de Cluster de VM do Autonomous Exadata
O Autonomous Exadata VM Cluster System Diagnostics, que é identificado como AVM_SYS_DIAG, deve ser usado para exibir logs.
A ação Diagnóstico do Sistema de Cluster de VMs do Autonomous Exadata deve ser usada para exibir logs. Um perfil somente leitura, que permite acesso somente leitura não privilegiado ao sistema. Esta ação é usada para determinar possíveis problemas com o sistema operacional e o software em execução nele. A maioria dos comandos não raiz estaria disponível neste modo. Não há comandos privilegiados disponíveis nesta ação. Os operadores não têm permissão para sudo como oracle, opc ou grid, mas terão um conjunto de comandos listados em branco que podem ser executados como esse usuário do operador dinâmico.
Tabela 1-7 Ações Ativadas com AVM_SYS_DIAG
| Nome da Ação |
Diagnóstico do Sistema de Cluster de VM do Autonomous Exadata |
| Identificador da Ação |
|
| Escopo |
VM Convidada |
| Privilégios do Operador |
Privilégio de Usuário do Linux: Não raiz Pode su para root, oracle, opc, grid: Não Colocado no cage com a operação chroot: Sim Diretórios Legíveis:
Diretórios Graváveis: Locais legíveis de log de aplicativo restrito:
Arquivos de configuração legíveis:
Acesso de saída à rede: Nenhum Comandos do sistema operacional na lista negra:
Lista de comandos executáveis: Os comandos |
Limitar o Acesso do Operador a um Autonomous Container Database (ACD) Aprovado pelo Cliente Específico
Restrinja o acesso a um ACD específico em um cluster de VMs autônomas nas gaiolas de diagnóstico e manutenção.
Os operadores podem especificar se precisam:
- Acesso somente SSH ao cluster de VMs autônomas sem acesso SQL aos ACDs. Nesse caso, todo acesso SQL aos ACDs será bloqueado.
- Acesso SSH ao cluster de VMs autônomas e acesso SQL aos ACDs. Se selecionar ambos, eles deverão selecionar um ou mais ACDs.
O cliente recebe uma solicitação de aprovação com os detalhes aos quais os operadores estão solicitando acesso. Dessa forma, o cliente pode ter certeza de que os operadores terão acesso ao ACD correto. Depois que o cliente aprovar a solicitação de acesso, os operadores obterão acesso SQL somente aos ACDs para os quais eles foram aprovados.
O atributo Request Reason exibirá a quais ACDs os operadores estão solicitando acesso.
Ação: Manutenção do Sistema de Cluster de VMs do Autonomous Exadata
A Manutenção do Sistema de Cluster de VMs do Autonomous Exadata, que é identificada como AVM_SYS_MAINT, deve ser usada para fazer alterações relacionadas ao serviço.
A ação Manutenção do Sistema de Cluster de VMs do Autonomous Exadata deve ser usada para fazer alterações relacionadas ao serviço. Esta ação é usada para iniciar e interromper serviços e executar verificações de integridade do serviço. A maioria dos comandos relacionados ao serviço está disponível nesse modo. O operador terá acesso aos logs, mas não terá permissão para su para oracle, opc ou grid.
Tabela 1-8 Ações Ativadas com AVM_SYS_MAINT
| Nome da Ação |
Manutenção do Autonomous Exadata VM Cluster System |
| Identificador da Ação |
|
| Escopo |
VM Convidada |
| Privilégios do Operador |
Privilégio de Usuário do Linux: Não raiz Pode su para root, oracle, opc, grid: Não Colocado no cage com a operação chroot: Sim Diretórios legíveis:
Diretórios graváveis: Nenhum Locais legíveis de log de aplicativo restrito:
Arquivos de configuração legíveis:
Acesso de saída à rede: Nenhum Comandos do sistema operacional na lista negra:
Aliases de comando: Lista de comandos executáveis: A execução de comandos relacionados ao serviço está disponível no estado em que se encontra, mas sem alternar para o usuário Consulte os exemplos fornecidos a seguir.
Scripts a serem executados conforme abaixo com aliases.
|
Limitar o Acesso do Operador a um Autonomous Container Database (ACD) Aprovado pelo Cliente Específico
Restrinja o acesso a um ACD específico em um cluster de VMs autônomas nas gaiolas de diagnóstico e manutenção.
Os operadores podem especificar se precisam:
- Acesso somente SSH ao cluster de VMs autônomas sem acesso SQL aos ACDs. Nesse caso, todo acesso SQL aos ACDs será bloqueado.
- Acesso SSH ao cluster de VMs autônomas e acesso SQL aos ACDs. Se selecionar ambos, eles deverão selecionar um ou mais ACDs.
O cliente recebe uma solicitação de aprovação com os detalhes aos quais os operadores estão solicitando acesso. Dessa forma, o cliente pode ter certeza de que os operadores terão acesso ao ACD correto. Depois que o cliente aprovar a solicitação de acesso, os operadores obterão acesso SQL somente aos ACDs para os quais eles foram aprovados.
O atributo Request Reason exibirá a quais ACDs os operadores estão solicitando acesso.
Ações do Operator Access Control: Compute Cloud@Customer
Ocasionalmente, os operadores autorizados precisam acessar recursos para atualizar o Compute Cloud@Customer, solucionar problemas ou ajudar a resolver um problema.
- Ação: Acesso Total da Infraestrutura do Compute Cloud@Customer
O Acesso Total da Infraestrutura do Compute Cloud@Customer é identificado comoCCC_SYS_ADMIN_FULL_ACCESS.
Tópico pai: Aplicação de Ações no Operator Access Control
Ação: Acesso Total da Infraestrutura do Compute Cloud@Customer
O Acesso Total à Infraestrutura do Compute Cloud@Customer é identificado como CCC_SYS_ADMIN_FULL_ACCESS.
Tabela 1-9 Ações Ativadas com CCC_SYS_ADMIN_FULL_ACCESS
| Nome da Ação |
Acesso Total ao Sistema |
| Identificador da Ação |
|
| Privilégios do Operador |
Privilégio de Usuário do Linux: Não raiz É possível fazer su para Colocado no cage com a operação chroot: Não Diretórios Legíveis: Todos Arquivos Legíveis: Todos Diretórios Graváveis: Todos Arquivos Graváveis: Todos Lista de comandos executáveis: Todos É possível fazer su em: |
Limites do Operator Access Control
O Operator Access Control é uma solução projetada para auditoria e conformidade de acesso da Oracle, não uma solução de conformidade com finalidades gerais.
O Operator Access Control só faz auditoria de usuários autorizados criados no contexto de uma solicitação de acesso associada a um Oracle Operator Access Control. Veja a seguir uma lista de exemplos de ações de auditoria e controle de conformidade que o Operator Access Control não trata.
- O Operator Access Control só controla as camadas que a Oracle possui. Por exemplo, o Operator Access Control controla o acesso ao Servidor de Banco de Dados Exadata físico e ao Exadata Storage Server.
- O Operator Access Control não controla ações de automação, incluindo as ações que são executadas como
root, ou outros usuários de automação altamente privilegiados, incluindo acesso de automação baseado em proxy. - O Operator Access Control só oferece controles no nível de Ações definidas. As próprias Ações controlam o acesso a um aplicativo no nível do sistema operacional.
- O Operator Access Control não é um serviço de auditoria geral. Ele só audita usuários autorizados criados no contexto de uma solicitação de acesso associada a um Controle do Operador.
- O Operator Access Control só controla camadas distintas nos sistemas Exadata Cloud@Customer. Ele não oferece controles em entidades externas do Oracle Cloud Infrastructure, como switches, ou outro software de plano de controle.
Tópico pai: Visão Geral do Oracle Operator Access Control
Atribuições de Job da Tenancy do Cliente para o Operator Access Control
Para estabelecer o controle de acesso do operador, configure políticas de controle de acesso e estabeleça grupos de usuários responsáveis por gerenciar e monitorar o acesso à sua infraestrutura.
- Criação de Controle do Operador para Administradores de Política
Administradores de política são os usuários que têm permissões para configurar políticas de controle do operador (chamadas Controle do Operador). - Como as Solicitações de Acesso do Operador São Aprovadas
Veja como você pode gerenciar aprovações de controle do operador configurando um regime do IAM (Identity and Access Management) usando políticas do Oracle Operator Access Control. - Como o Acesso do Operador é Auditado
Saiba como os logs são capturados e como você pode auditar as atividades do operador.
Tópico pai: Visão Geral do Oracle Operator Access Control
Criação de Controle do Operador para Administradores de Política
Administradores de política são os usuários que têm permissões para configurar políticas de controle do operador (chamadas de Controle do Operador).
Para criar o controle de acesso do operador em sua infraestrutura, a primeira etapa é criar administradores de política de Controle do Operador que desenvolvam e criem o conjunto de controles do operador que você deseja usar para os administradores de frota da tenancy.
Normalmente, quando você cria controles do operador, divide a infraestrutura do Exadata em grupos de controle de acesso com base em várias dimensões:
- Crítico para os Negócios: Sistemas críticos, sistemas menos críticos, sistemas de desenvolvimento
- Segurança ou Conformidade: Sistemas com necessidades de conformidade específicas e outros
- Grupos de Usuários: Quais grupos de usuários (geralmente com a atribuição de administrador de frota) você deseja tornar responsáveis por um conjunto de sistemas Exadata
Alguns exemplos dos grupos de usuários responsáveis por um conjunto de sistemas Exadata:
- Departamentos verticais, cujos aplicativos dependem de um conjunto de sistemas Exadata.
- Sistemas compartilhados entre diversos departamentos, por cuja administração um departamento de TI é responsável.
Normalmente, você cria compartimentos em sua infraestrutura com base em critérios de criticidade, conformidade regulatória e gerenciamento de grupos de usuários, porque os compartimentos formam os limites administrativos lógicos no Oracle Cloud Infrastructure. Geralmente, cada compartimento tem um grupo de usuários que recebe privilégios de gerenciamento no compartimento. Por esse motivo, o Administrador de Política deve criar tantos controles do operador quanto houver compartimentos mantendo as infraestruturas Exadata.
Além de controles do operador específicos para compartimentos, você também deve criar uma política adicional, chamada DEFAULT_OPERATOR_CONTROL, que você pode usar para criar novos conjuntos de sistemas Exadata em novos compartimentos, para os quais você pode criar outro conjunto de usuários administrativos.
Tópicos Relacionados
Como as Solicitações de Acesso do Operador São Aprovadas
Veja como gerenciar aprovações de controle do operador configurando um regime do IAM (Identity and Access Management) usando as políticas do Oracle Operator Access Control.
Os administradores de tenancy para Controles do Operador de um sistema Oracle Cloud são membros do grupo de administradores de Controles do Operador. Você recebe solicitações de controle do operador para acesso ao Oracle Cloud Infrastructure. Para dar suporte aos seus requisitos de conformidade regulatória, você pode controlar o acesso à sua infraestrutura. Você pode especificar que algumas ações estejam sempre no status aprovadas automaticamente e especificar que outras ações devem receber aprovação para que a Oracle possa executar operações de manutenção do sistema em sua tenancy. Quando você concede acesso ao sistema, esse acesso é automaticamente limitado a uma duração padrão. Você também pode especificar que as operações devem ocorrer em um período específico estabelecido por você.
Exemplo 1-1 Controles do Operador para uma política do Oracle Cloud Infrastructure IAM
Você pode definir controles detalhados sobre as permissões concedidas no sistema.
Por exemplo, suponha que você tenha dois grupos de sistemas Exadata Cloud em um compartimento nos quais você é o administrador da tenancy. Como parte da sua política do serviço IAM, você criou dois conjuntos distintos de sistemas Exadata: o primeiro grupo de sistemas tem todas as configurações de Política do Operador definidas como pré-aprovado e o segundo grupo de sistemas não tem uma Política do Operador configurada como pré-aprovada.
Você também criou dois grupos de usuários: PRE_APPROVED_POLICY_USERS e EXPLICIT_APPROVED_POLICY_USERS. Os grupos de Controle do Operador são identificados pela tag fornecida: O namespace optctl tem dois grupos de Controle do Operador. Um é identificado pela tag pre-approved-exacc. O segundo grupo é identificado pela tag explicit-approved-exacc. Assim, em geral, você tem um conjunto de servidores em que todas as ações são pré-aprovadas e um conjunto de servidores em que nenhuma ação é pré-aprovada.
Em seguida, em seu compartimento, suponha que você tenha estabelecido um conjunto de recursos do Exadata Cloud, cada um representando um nível de ações permitidas:
system_diagespecifica permissões de ações para diagnosticar qualquer problema na camada de infraestrutura do Exadata Cloud@Customer, como leitura de logs e execução de comandos de diagnóstico e monitoramento. Você concede aos membros dessa política a açãoINFRA_DIAG.system_mainespecifica permissões de ações para executar diagnóstico e manutenção do sistema, mas também a opção para reiniciar o sistema. Você concede aos membros dessa política a açãoINFRA_UPDATE_RESTART, mas a autorização é definida como especificar autorização.system_allconcede permissões completas de privilégios de administração do sistema, incluindo o uso irrestrito desudo. Você concede aos membros dessa política a açãoINFRA_FULL. Você não tem um grupo de políticas criado com essa Ação.
Para os recursos nos quais você configurou a política system_diag, você marcou como pré-aprovadas todas as atividades de administração permitidas por essa ação. Você especificou que os membros do grupo PRE_APPROVED_POLICY_USERS recebem acesso para usar system_diag com o status pré-aprovado na tenancy
Em seguida, suponha que um operador Oracle com associação de grupo PRE_APPROVED_POLICY_USERS solicite acesso a um servidor, mas solicita a ação INFRA_UPDATE_RESTART porque uma ação de manutenção requer uma reinicialização. O operador Oracle ainda deve solicitar acesso para a Ação que permite que um operador reinicie o sistema como parte de uma ação de manutenção. Você concede acesso à política system_main, mas todas as ações que exigem esse acesso de política exigem aprovação.
Observe que, a qualquer momento, como administrador, independentemente das associações de grupos existentes ou da aprovação, você pode revogar o acesso ao operador. Se você remover um operador Oracle da associação do grupo, o operador não terá acesso ao sistema.
Como o Acesso do Operador é Auditado
Saiba como os logs são capturados e como você pode auditar as atividades do operador.
Os logs de auditoria são coletados usando o subsistema
auditd no kernel do Linux. Para adicionar regras do Operator Access Control para coletar os logs, reinicialize o sistema Exadata depois de designar um Controle do Operador pela primeira vez. Não é necessário reinicializar o sistema Exadata para as designações subsequentes.
Extensão de Logs de Auditoria Capturados
- Logs de evento de ciclo de vida
- Log de comando
O primeiro sendo eventos de ciclo de vida; o segundo, os comandos executados pelo operador nos hosts de destino.
Logs de Evento de Ciclo de Vida
O serviço Operator Access Control captura eventos de log-in e log-out somente para usuários autorizados do serviço Operator Access Control e não captura eventos de log-in de automação.
Log de Comando
O serviço de Controle de Acesso do Operador captura todos os comandos executados por usuários autorizados em um shell. Ele captura a entrada do comando sem nenhuma redação e não captura a saída do comando. Ele também captura todos os comandos shell executados usando scripts shell.
netstat -an | grep 8080searchlog.sh nesse caso também são capturados../searchlog.sh –process "cellservice"su foi feito. Por exemplo, depois de fazer log-in, se o usuário autorizado auth_user_123 executar os comandos a seguir, o serviço de Controle de Acesso do Operador irá capturar todos esses comandos.su - celladmin
tail -n 10 /var/log/messagesRegistro em Log do Teclado
Além disso, os logs de comando também podem ser capturados no formato de log do teclado. O registro em log do teclado captura cada tecla que os operadores digitam em seus computadores. Ele não tem muitas finalidades práticas para capturar o registro em log do teclado, mas há casos em que os requisitos regulatórios precisam capturá-lo.
Itens Não Registrados em Log
O serviço de Controle de Acesso do Operador não registra comandos de automação nem eventos de ciclo de vida. Embora esse serviço registre em log todos os comandos emitidos para o shell diretamente ou por meio da chamada de scripts shell, ele não registrará as ações executadas pelos arquivos binários. Portanto, se um operador fizer log-in no servidor de célula e depois entrar em um shell cellcli, os logs serão limitados a capturar somente os comandos de shell cellcli. O serviço Operator Access Control não registra em log comandos executados no cellcli.
Formato de Logs de Auditoria
Os logs de auditoria são formatados como texto JSON. Os logs de auditoria são categorizados em duas partes: os dados brutos e os dados interpretados. Os dados brutos não são compreensíveis fora do contexto de uma máquina Linux na qual o log foi capturado. Por exemplo, os dados brutos não se referem a nomes de usuário do Linux; em vez disso, se referem a identificadores internos. O mapeamento do identificador para o usuário só pode ser feito na máquina Linux em que o log foi capturado.
Além da interpretação, o formato também define o contexto fornecendo o "ID da solicitação de acesso" nos logs.
Logs de Evento de Ciclo de Vida
Os dois exemplos a seguir fornecem o formato do log de auditoria para eventos de ciclo de vida. Os exemplos mostram um evento de login e logout. O nome de usuário utilizado para esse log-in é "USERNAME".
Exemplo 1-2 Log de Eventos de Log-in
{
"layer": "CPS",
"req_auth_id": "1",
"srchost": "dhcp-10-191-235-63.vpn.example.com",
"res": "success'",
"desthost": "10.191.235.63",
"pid": "89736",
"tty": "/dev/pts/2",
"host": "scaqae08dv0605m",
"time": "Thu Oct 29 03:20:22 2020",
"raw_data": "type=USER_LOGIN msg=audit(10/29/2020 03:20:22.091:10777414) : pid=89736 uid=root auid=USERNAME ses=75141 msg='op=login id=USERNAME exe=/usr/sbin/sshd hostname=dhcp-10-191-235-63.vpn.example.com addr=10.191.235.63 terminal=/dev/pts/2 res=success' \n",
"event": "login",
"loginid": "USERNAME"
}Exemplo 1-3 Log de Eventos de Log-out
{
"layer": "CPS",
"req_auth_id": "1",
"srchost": "dhcp-10-191-235-63.vpn.example.com",
"res": "success'",
"desthost": "10.191.235.63",
"pid": "90456",
"tty": "ssh",
"host": "scaqae08dv0605m",
"time": "Thu Oct 29 03:20:35 2020",
"raw_data": "type=USER_LOGOUT msg=audit(10/29/2020 03:20:35.855:10777438) : pid=90456 uid=root auid=USERNAME ses=75142 msg='op=login id=USERNAME exe=/usr/sbin/sshd hostname=dhcp-10-191-235-63.vpn.example.com addr=10.191.235.63 terminal=ssh res=success' \n",
"event": "logout",
"loginid": "USERNAME"
}Log de Comando
Os logs de comando são mais elaborados. Eles fornecem informações sobre o comando, os parâmetros do comando do usuário efetivo que está executando o comando. Os comandos também têm uma hierarquia no sentido de que uma execução de script de shell terá primeiro um bash -c registrado em log e, em seguida, os comandos de script.
Exemplo 1-4 Execução de Comando
{
"layer": "CPS",
"req_auth_id": "1",
"title": "ls\u0000/",
"raw_data": "type=PROCTITLE msg=audit(10/29/2020 03:20:29.418:10777424) : proctitle=ls / \ntype=PATH msg=audit(10/29/2020 03:20:29.418:10777424) : item=1 name=/lib64/ld-linux-x86-64.so.2 inode=1182648 dev=f9:00 mode=file,755 ouid=root ogid=root rdev=00:00 nametype=NORMAL \ntype=PATH msg=audit(10/29/2020 03:20:29.418:10777424) : item=0 name=/usr/bin/ls inode=1189225 dev=f9:00 mode=file,755 ouid=root ogid=root rdev=00:00 nametype=NORMAL \ntype=CWD msg=audit(10/29/2020 03:20:29.418:10777424) : cwd=/ \ntype=EXECVE msg=audit(10/29/2020 03:20:29.418:10777424) : argc=2 a0=ls a1=/ \ntype=SYSCALL msg=audit(10/29/2020 03:20:29.418:10777424) : arch=x86_64 syscall=execve success=yes exit=0 a0=0xfff6d0 a1=0xff42d0 a2=0xfff960 a3=0x7ffc1dd337e0 items=2 ppid=90474 pid=90764 auid=USERNAME uid=USERNAME gid=USERNAMg euid=USERNAME suid=USERNAME fsuid=USERNAME egid=USERNAMg sgid=USERNAMg fsgid=USERNAMg tty=pts2 ses=75141 comm=ls exe=/usr/bin/ls key=(null) \n",
"args": [],
"rec_id": "10777424",
"tty": "pts2",
"host": "scaqae08dv0605m",
"time": "Thu Oct 29 03:20:29 2020",
"loginid": "USERNAME"
}O título do campo fornece o comando que foi executado. Os dados brutos fornecem muito mais informações.
Frequência de Coleta
O serviço Operator Access Control coleta os logs conforme e quando os eventos acontecem, timestamps e envia os logs para o serviço de registro em log periodicamente. Ele tenta enviar os logs a cada 30 segundos intervalos.
Acessando Logs de Auditoria
Você pode acessar logs de auditoria por meio do serviço Logging. Para obter mais informações, consulte Visão Geral do Serviço Logging.
O JSON mostrado na seção 2 está disponível no serviço Logging. Use sua tenancy para acessar o serviço Logging. Os logs são postados no compartimento no qual o Controle do Operador foi criado. Os logs são marcados para o Controle do Operador.
Políticas de Retenção de Logs de Auditoria
Os logs de auditoria são mantidos na tenancy do usuário; portanto, o serviço de Controle de Acesso do Operador não controla o ciclo de vida dos logs de auditoria. Você pode controlar a duração do período de retenção. No entanto, se esse serviço não conseguir enviar os logs para a tenancy do usuário, ele tentará reter os logs até a extensão permitida pelas configurações do Exadata. O período de retenção é considerável, ou seja, em dias ou mais.
Encaminhando Logs de Auditoria do Operator Access Control para os Sistemas SIEM
Você pode optar por encaminhar logs de auditoria do Operator Access Control diretamente do Exadata Cloud@Customer para os sistemas SIEM (Security Information and Event Management) no seu data center.
Para melhorar seu gerenciamento de segurança, você pode transmitir logs de auditoria para o serviço Logging do OCI e para os sistemas SIEM em seus data centers. Para transmitir esses logs de auditoria para sistemas SIEM, é utilizado o syslog sobre TCP.
- Implantando um Servidor Syslog no Data Center
Para receber logs de auditoria do Exadata Cloud@Customer, implante um servidor Syslog em seu data center. O servidor Syslog pode ser da sua escolha. A maioria dos sistemas Linux vem comrsyslog. - Exemplo de Configuração do Servidor Syslog
Para ver como você pode configurar um servidor Syslog de sua escolha, use este exemplo. - Testando a Conectividade entre o CPS e o Servidor Syslog
Certifique-se de ter fornecido um endereço IP ou nome de host válido para o servidor Syslog. - Exemplo de Logs de Auditoria
Como administrador, veja exemplos dos logs de auditoria recebidos com segurança do Servidor de Plano de Controle.
Tópico pai: Visão Geral do Oracle Operator Access Control
Implantando um Servidor Syslog no Data Center
Para receber logs de auditoria do Exadata Cloud@Customer, implante um servidor Syslog em seu data center. O servidor Syslog pode ser da sua escolha. A maioria dos sistemas Linux vem com rsyslog.
Você só pode encaminhar logs de auditoria para um servidor Syslog para cada sistema Exadata Cloud@Customer de destino. A Oracle só suporta comunicação segura e usa TLS para segurança de transmissão. O Servidor de Plano de Controle estabelece conexão com o servidor Syslog e entrega todos os logs de auditoria por TCP seguro. Para estabelecer confiança entre o Servidor de Plano de Controle e o servidor Syslog, use um arquivo de certificado CA do servidor Syslog no formato PEM. A extensão do arquivo deve ser .pem, .cer ou .crt. Para obter mais informações sobre configuração, consulte Exemplo de Configuração do Servidor Syslog.
O log contém elementos já descritos no capítulo Managing and Searching Logs with Operator Access Control. Deve haver a garantia de que o formato seja compatível com os parsers de log syslog e audit-d. Veja o exemplo de log de auditoria.
O envio de logs de auditoria para sistemas SIEM é feito da melhor forma possível. Enquanto o Servidor de Plano de Controle repete o envio de logs no caso de falhas de rede, os pacotes podem ser eliminados silenciosamente nos limites. Nesses casos, os logs que aparecem no serviço Logging do OCI são a referência.
Para encaminhar logs de auditoria, designe pelo menos um Controle do Operador ao sistema Exadata Cloud@Customer indefinidamente (ALWAYS ASSIGNED).
Tópicos Relacionados
Exemplo de Configuração do Servidor Syslog
Para ver como você pode configurar um servidor Syslog de sua escolha, use este exemplo.
- Abra uma porta de rede para receber logs remotos.
Observação
As regras de saída do servidor Syslog devem estar abertas para a Porta Syslog. Por exemplo, se a porta 6514 for usada para Syslog, a regra de Segurança de Saída deverá estar em vigor para permitir que o tráfego atinja o Syslog pelo Cluster de VMs Autônomas. - Ative a criptografia no servidor Syslog para obter comunicação remota.
- (Opcional) Gere e transfira um certificado raiz para comunicação segura.
O exemplo a seguir é para configurar um servidor
rsyslog (v 8.24) em uma máquina com o Oracle Linux 7. A configuração está disponível geralmente em /etc/rsyslog.conf. Somente as seções relevantes são abordadas nesse exemplo.
Para esse exemplo, a porta de listening é 10514. Há várias fontes disponíveis na Internet para ajudar você a criptografar o tráfego do Syslog. Uma boa referência é Encrypting Syslog Traffic with TLS (SSL) [short version] - rsyslog 8.18.0.master documentation.
# rsyslog configuration file (8.24.0 - /etc/rsyslog.conf - Oracle Linux 7)
# For more information see /usr/share/doc/rsyslog-*/rsyslog_conf.html
# If you experience problems, then see http://www.rsyslog.com/doc/troubleshoot.html
#### MODULES $ModLoad imuxsock # provides support for local system logging (e.g. via logger command)# Provides TCP syslog reception
$ModLoad imtcp
$InputTCPServerRun 10514
...# certificate files
$DefaultNetstreamDriverCAFile /var/gnutls1/ca.pem
$DefaultNetstreamDriverCertFile /var/gnutls1/cert.pem
$DefaultNetstreamDriverKeyFile /var/gnutls1/key.pem$ModLoad imtcp # load TCP listener$InputTCPServerStreamDriverMode 1 # run driver in TLS-only mode
$InputTCPServerStreamDriverAuthMode anon # client is NOT authenticated
#$InputTCPServerStreamDriverAuthMode x509/name # client is NOT authenticated
$InputTCPServerRun 10514 # start up listener at port 10514
...Testando a Conectividade entre o CPS e o Servidor Syslog
Certifique-se de ter fornecido um endereço IP ou nome de host válido para o servidor Syslog.
- Para validar se o servidor Syslog pode receber logs, execute o comando
ncpara o servidor e a porta do Syslog de qualquer host da sua rede que tenha acesso ao servidor Syslog.nc syslog server host syslog port - Para garantir que o caminho entre o Exadata Cloud@Customer e o servidor Syslog seja válido, faça ping no endereço IP do Servidor de Plano de Controle do Exadata Cloud@Customer. Para obter o endereço IP do Servidor de Plano de Controle (CPS, Control Plane Server), entre em contato com o administrador da rede.
Tópicos Relacionados
Exemplo de Logs de Auditoria
Como administrador, veja exemplos dos logs de auditoria recebidos com segurança do Servidor de Plano de Controle.
Quando você transmite logs para o servidor Syslog, muitos cabeçalhos e a formatação JSON são omitidos. Os exemplos a seguir mostram a natureza dos dados enviados por meio do Syslog.
Exemplo 1-5 1
Apr 12 07:38:22 scaqar05dv0511m opctl: type=USER_LOGIN msg=audit(04/12/2021 07:38:05.752:1742859) :
pid=65327
uid=root
auid=830916abb78e4157b9e45b641e34fcf6 ses=32770
msg='op=login id=830916abb78e4157b9e45b641e34fcf6
exe=/usr/sbin/sshd
hostname=localhost.localdomain
addr=127.0.0.1
terminal=/dev/pts/3 res=success'Exemplo 1-6 2
Apr 12 07:38:22 scaqar05dv0511m opctl: type=USER_LOGOUT msg=audit(04/12/2021 07:38:08.802:1742867) :
pid=65327
uid=root
auid=830916abb78e4157b9e45b641e34fcf6
ses=32770
msg='op=login
id=830916abb78e4157b9e45b641e34fcf6 exe=/usr/sbin/sshd
hostname=?
addr=?
terminal=/dev/pts/3 res=success'Tópicos Relacionados