Documentación de Oracle Cloud Infrastructure

Visión general de Oracle Operator Access Control

Descubra cómo controlar, auditar y revocar el acceso del personal del servicio de Oracle a su infraestructura mediante Oracle Operator Access Control.

¿Qué es Oracle Operator Access Control?

Oracle Operator Access Control le permite otorgar, auditar y revocar el acceso que tiene Oracle a la infraestructura de Exadata, la infraestructura de Exadata que aloja una instancia de Oracle Autonomous Database en Exadata Cloud@Customer y el cluster de VM de Exadata autónomo (máquinas virtuales de cliente desplegadas en la instancia de Oracle Autonomous Database en Exadata Cloud@Customer) administrados por Oracle, así como obtener informes de auditoría de todas las acciones realizadas por un operador humano casi en tiempo real.

Oracle Operator Access Control para Exadata Cloud@Customer

El servicio Oracle Exadata Cloud@Customer es un sistema de responsabilidad compartida:
  • Usted es responsable de las acciones en las máquinas virtuales, y de la gestión diaria de las bases de datos y las aplicaciones que se ejecutan en las máquinas virtuales.
  • Oracle es responsable de los componentes de la infraestructura: alimentación, sistema operativo con hardware dedicado, hipervisores, servidores Exadata Storage Server y otros aspectos del entorno de infraestructura.

Sin embargo, si tiene requisitos normativos para auditar y controlar todos los aspectos de la gestión del sistema, el modelo de responsabilidad compartida crea un problema. Debe probar a sus reguladores que tiene el control absoluto de sus sistemas y que está operando sus sistemas en conformidad con esas regulaciones de conformidad.

¿Cómo puede controlar y auditar todas las acciones que realiza cualquier operador o software de los sistemas en los componentes de la infraestructura? ¿Cómo puede mantener el mismo nivel de auditorías y control de acceso a los sistemas, y proporcionar los registros de auditoría necesarios para las auditorías normativas internas o externas en los sistemas? Para solucionar este problema, Oracle proporciona Oracle Operator Access Control como solución para restringir el acceso sin restricciones a los sistemas por parte de los operadores de Oracle.

Operator Access Control para Oracle Autonomous Database en Exadata Cloud@Customer

Operator Access Control se ha ampliado para proporcionar controles para las máquinas virtuales de cliente desplegadas en Oracle Autonomous Database en Exadata Cloud@Customer. Al igual que el control de acceso de operador para la infraestructura de Exadata Cloud@Customer, los clientes ahora pueden imponer controles de acceso de operador de Oracle en sus clusters de máquina virtual autónomos desplegados en Exadata Cloud@Customer.

La entrega de la instancia de Autonomous Database en una infraestructura dedicada (tanto en OCI como en Cloud@Customer) se basa en el principio de que el cliente es el "usuario" de la base de datos y Oracle es el "gestor". Cuando hablamos de "gestión" nos referimos a las tareas típicas de administrador de base de datos o DBA, como las siguientes:
  • Aprovisionamiento de recursos de Autonomous Database
  • Copia de seguridad de bases de datos
  • Recuperación de una base de datos
  • Aplicación de parches y actualizaciones
  • Escalado
  • Supervisión del estado del servicio
  • Auditoría
  • Alertas y notificaciones

El cliente no tiene acceso al sistema operativo cliente, acceso sys/system a sus bases de datos de contenedores o acceso a los logs del sistema. Además, el cliente se limita a supervisar el estado y el rendimiento de las aplicaciones, así como la seguridad de las aplicaciones en todos los niveles. Por otra parte, los operadores de Oracle, como gestores, tienen acceso completo y sin restricciones a todos los componentes, incluido el acceso root al hipervisor y las máquinas virtuales cliente.

El modelo de responsabilidad compartida para la base de datos autónoma plantea varios desafíos operativos a los clientes regulados que deben mantener el control de todos los datos e infraestructura independientemente del proveedor y el modelo de despliegue (local, alojado o en la nube). Los clientes regulados se someten a su propio control de cumplimiento y formulan sus propias directrices de seguridad que pueden llevar años endureciendo y poniendo en práctica.

Esto se aplica especialmente a los clientes empresariales de Oracle que están muy regulados y ejecutan sus sistemas más críticos, las aplicaciones que conllevan más riesgos para la seguridad en Oracle. Para solucionar este problema, Oracle proporciona Oracle Operator Access Control como solución para restringir el acceso sin restricciones a los sistemas por parte de los operadores de Oracle.

Oracle Operator Access Control para Oracle Cloud Infrastructure

Oracle Operator Access Control es un sistema de auditoría de conformidad que le permite mantener la gestión del cierre y las pistas de auditoría de todas las acciones que realiza un operador de Oracle en la infraestructura.

Oracle Operator Access Control le permite hacer lo siguiente:
  • Otorgar acceso a la infraestructura, incluidos quién puede acceder a la infraestructura, cuándo se puede acceder al sistema y durante cuánto tiempo puede acceder el personal de Oracle al sistema.
  • Ver y guardar un informe en tiempo casi real de todas las acciones que realiza un operador de Oracle en el sistema.
  • Limitar el acceso, incluida la limitación de las acciones que puede realizar un operador de Oracle en el sistema.
  • Revocar el acceso, incluido el acceso que ha otorgado anteriormente.

Control de acceso de operador para Compute Cloud@Customer

La infraestructura de Compute Cloud@Customer se basa en el principio de que el cliente es el "usuario" de las máquinas virtuales y los servicios que crea y ejecuta en la infraestructura, y Oracle es el "gestor" de la infraestructura en sí. Por 'gestionar' se entiende tareas típicas como la actualización, la aplicación de parches y la supervisión de los componentes de infraestructura.

El cliente no tiene acceso a instancias de SO virtuales o de hardware dedicado de infraestructura en componentes de infraestructura ni al software de gestión que se ejecuta en estas instancias. Por otra parte, Oracle Ops, como gestora, tiene acceso completo y sin restricciones a todos los componentes, incluido el acceso root al hipervisor y los servidores del plano de control.

Este modelo plantea varios desafíos operativos a los clientes regulados que deben mantener el control de todos los datos e infraestructura independientemente del proveedor y el modelo de despliegue (local, alojado o en la nube). Los clientes regulados se someten a su propio control de conformidad y formulan sus propias directrices de seguridad que pueden tardar años en endurecerse y ponerse en práctica. Esto se aplica especialmente a los clientes empresariales de Oracle que están muy regulados y ejecutan sus sistemas más críticos, las aplicaciones que conllevan más riesgos para la seguridad en Oracle.

El control de acceso de operador se ha ampliado para respaldar estos objetivos de conformidad de clientes y permitirles llevar sus bases de datos esenciales a Oracle Cloud, de modo que los clientes puedan controlar en última instancia el acceso a sus sistemas dedicados.

Términos asociados a Operator Access Control

Obtenga información sobre los términos que se utilizan con Operator Access Control.

Operador: empleado de Oracle que es miembro de un arrendamiento de grupo de operadores (grupo Ops) en Oracle Cloud Infrastructure (OCI). Por ejemplo, un operador puede ser un empleado de Oracle en el grupo Exadata Cloud@Customer_ops o el grupo ExaCS_ops. El arrendamiento del grupo Ops es un juego de arrendamientos en OCI que pueden administrar controles de operación. Los grupos Ops y los operadores que son miembros de estos grupos no tienen ningún privilegio por defecto que no sea la capacidad de solicitar acceso a la infraestructura. Oracle controla estrictamente los grupos y la pertenencia a los grupos de operadores.

Usuario: usuario de OCI del arrendamiento en cuyo sistema Exadata Cloud@Customer se ubican los controles.

Capa de infraestructura de Exadata: varias capas del sistema físico u operativo del sistema de Exadata. Actualmente, se define como Servidor de plano de control, Host, VM de invitado, servidores de celdas, conmutadores e ILOM.

Acción: juego predefinido de comandos, archivos o redes con nombre al que se puede acceder en una capa determinada. Oracle define acciones.

Control de operador: entidad definida por el cliente que contiene una agrupación de acciones preaprobadas y acciones que requieren aprobación explícita del grupo de aprobación para permitir el acceso. El grupo de aprobadores es un grupo de usuarios de IAM estándar que muestra el juego de usuarios que tienen permisos para aprobar o revocar el acceso.

Atributos de operador: en algunos casos, el control de operador puede definir criterios para los operadores que tienen permiso para acceder a la infraestructura.

Asignación de control de operador: es el proceso mediante el cual un sistema Exadata Cloud@Customer se asocia a un control de operador con nombre. En un momento dado, solo se puede aplicar un control de operador en un sistema Exadata Cloud@Customer. La asignación puede ser permanente o con una duración específica. Si no se asigna un control de operador a un sistema Exadata Cloud@Customer, el sistema Exadata Cloud@Customer se ejecuta con un control de operador por defecto que permite todo el acceso necesario para el diagnóstico y el mantenimiento.

Solicitud de acceso: la solicitud de acceso es el proceso mediante el cual un operador solicita permiso para acceder a una infraestructura de Exadata identificada. La infraestructura de Exadata se identifica mediante OCID. La solicitud identifica la acción que necesita el operador.

Aprobación/rechazo de solicitud de acceso: la aprobación/rechazo de acceso es el proceso mediante el cual un usuario competente determinado por el control de operador desplegado en la infraestructura de Exadata puede otorgar o rechazar una solicitud de acceso.

Revocación de solicitud de acceso: un usuario competente puede revocar una solicitud de acceso en un momento determinado. Esta acción elimina de inmediato las sesiones del operador conectadas a la infraestructura de Exadata en función de esta solicitud de acceso.

Solicitud de acceso en revisión: confirma una solicitud de acceso de operador de Oracle emitida y comunica al solicitante que se está revisando la solicitud de acceso.

¿Qué opciones de control proporciona Oracle Operator Access Control?

Puede crear políticas que especifiquen qué juego de operadores de acciones puede realizar en la infraestructura.

Una acción impone restricciones sobre lo que un operador de Oracle puede hacer en la infraestructura gestionada por Oracle. Estas restricciones incluyen el control sobre los comandos de shell del sistema operativo en ejecución, la ejecución y los scripts de Oracle. Las acciones también establecen restricciones en la capacidad de los operadores de Oracle para ejecutar binarios, scripts de shell y scripts de Perl o Python que están fuera del ámbito de la función definida por la acción. Al otorgar permisos mediante una acción, se registra cada acción que realiza un operador de Oracle. Puede auditar los logs como parte de su política de requisitos de restricción de MAC.

Una política es un juego de acciones que debe especificar para implementar restricciones de control de acceso obligatorio (MAC) en la capacidad de los operadores de Oracle para realizar el mantenimiento en los sistemas. Para definir las políticas, se muestra a continuación una lista de controles de acceso específicos que puede aplicar mediante acciones:

  1. Configurar controles de operador para la gestión de operadores de Oracle:
    • Controles de operador para restringir los perfiles de acceso en un determinado tipo de recurso del arrendamiento. Por ejemplo, puede configurar políticas independientes para recursos como la máquina virtual (VM), el servidor de base de datos de infraestructura de Oracle, el servidor de plano de control o la red InfiniBand. Además, puede configurar políticas para asociar controles de acceso a un grupo de recursos de su arrendamiento.
    • Configure un grupo de administradores de usuarios asociados a cada control de operador. Los miembros de estos grupos pueden aprobar, cambiar o denegar solicitudes de acceso en un recurso en el que haya desplegado un control de operador.
    • Configure acciones para el acceso a recursos que defina como preaprobadas sin necesidad de configurar un grupo de usuarios administrativos para controlar el acceso.
  2. Especificar la autorización de solicitud obligatoria para poder permitir cualquier acceso a los recursos. Por ejemplo:
    • Cuando un juego de acciones se marca como preaprobado, cualquier solicitud de acceso que especifique solo un subjuego de dichas acciones se aprobará automáticamente y el personal de Oracle podrá acceder a los componentes de la infraestructura.
    • Cuando una política de acceso no está definida en preaprobada, se deniega al personal de Oracle el acceso a los compartimentos hasta que otorgue explícitamente solicitudes de acceso.
  3. Revocar el acceso a la infraestructura que haya otorgado previamente:
    • Los límites de tiempo automáticos revocan cualquier acceso que haya otorgado a un recurso. Al otorgar una solicitud de acceso a un operador de Oracle, se le otorga un identificador de usuario único para el acceso que le ha otorgado durante un tiempo limitado. Cuando se alcanza ese límite de tiempo, se revoca todo el acceso de Oracle al sistema relacionado con la solicitud de acceso aprobada. Si se necesita más tiempo, el operador de Oracle puede enviar una solicitud de extensión.
    • Revoque de forma manual el acceso que se ha otorgado a un recurso antes de que caduque el acceso que se ha otorgado anteriormente.
  4. Auditar todas las acciones que realiza un operador humano en sus recursos:

    • Se auditan todas las entradas y comandos de teclado que ejecuta el actor humano. Puede obtener acceso completo a todos los logs de auditoría de Linux.

      Puede solicitar una auditoría de un operador humano de Oracle específico en el sistema.

      Nota

      La identidad del operador humano no está disponible para usted como cliente de Oracle. Sin embargo, el sistema Oracle Operator Access Control mantiene registros de servicio del operador humano, de modo que Oracle pueda correlacionar el operador humano con una solicitud de acceso específica que haya otorgado para el servicio en su arrendamiento. Si sospecha de una acción maliciosa y necesita una auditoría, Oracle puede utilizar esa solicitud para revisar todas las acciones del operador humano específico que ha realizado las acciones permitidas mediante una solicitud de acceso.

Aplicación de acciones en Operator Access Control

Obtenga información sobre la aplicación de controles en las operaciones que puede realizar un operador de Oracle en su entorno.

Tema principal: Visión general de Oracle Operator Access Control

¿Qué es la aplicación de acciones?

En Operator Access Control, las Acciones limitan los privilegios que tiene el operador en la ejecución de comandos, el acceso a recursos y el cambio del estado del sistema.

Una acción define los permisos, los recursos y el acceso de cambio del sistema que se otorga a un operador de Oracle para realizar un determinado rango de tareas para funciones administrativas específicas en una infraestructura de Exadata dentro de un entorno gestionado mediante Operator Access Control. Los comandos que permite una acción pueden ser comandos de Oracle Linux o del servidor de celdas.

Los recursos para los que una acción otorga acceso son los archivos y la red. Los cambios del sistema corresponden a un cambio de estado en el sistema operativo o a un cambio de estado en el software que se ejecuta en esos sistemas. El cambio de estado es una consecuencia de los reinicios o las modificaciones de configuración.

La aplicación de acciones se basa en Solicitudes de acceso aprobadas, las cuales definen una política de tiempo limitado cuyos cambios desea que un operador de Oracle pueda implementar, según se ha definido en un juego de acciones otorgadas a los operadores. Cada solicitud de acceso crea una credencial de usuario temporal en la infraestructura de Exadata. La política de acceso que defina se basa en las acciones que apruebe en la solicitud de acceso, que se adjunta al usuario temporal creado.

Las aplicaciones de acciones suelen ser una función del sistema operativo. Se crea una política de aplicación de acciones para una instancia del sistema operativo, por ejemplo, en todos los hosts, servidores de celdas y servidores de plano de control. Las acciones otorgadas con una política se eliminan cuando la solicitud de acceso deja de ser válida, ya sea porque se cierra la solicitud de acceso o porque la tarea de administración se ha completado, revocado, o ha caducado.

La aplicación de acciones se puede aplicar a diferentes infraestructuras, como un sistema operativo, o a otro software, como cellcli.

Acciones de Operator Access Control: Infraestructura de Exadata

Las acciones definen las operaciones que un operador puede realizar en la infraestructura de Exadata Cloud@Customer, que están limitadas al host, el servidor de celdas y los servidores de plano de control.

Las acciones se aplican a la infraestructura de Exadata Cloud@Customer en general. Las acciones controlan las acciones del operador de Oracle en varias capas de Exadata Cloud@Customer. Las capas controladas en la versión actual son los servidores de celdas, el dominio de gestión (host) y los servidores de plano de control. Las acciones están organizadas por los requisitos, lo que conduce a la solicitud de acciones y al impacto crítico que estas acciones pueden generar.

Las acciones convierten los permisos de Oracle Linux en el sistema de destino Exadata Cloud@Customer. Los permisos se clasifican en privilegios del sistema de archivos, privilegios de ejecución de comandos y privilegios su o sudo. Las acciones se clasifican por la naturaleza del cambio que puede efectuar el operador en el sistema Exadata Cloud@Customer.

  • Acción: Sólo servidor de plano de control (CPS)
    Sólo servidor de plano de control (CPS), que se identifica como INFRA_CPS_ONLY, está destinado a utilizarse para diagnosticar y resolver problemas de CPS únicamente. El personal de Oracle no puede acceder a los componentes más allá del CPS, incluidos los servidores de celdas y el sistema operativo host (Dom0).
  • Acción: Diagnóstico del sistema
    El diagnóstico del sistema, que se identifica como INFRA_DIAG, está destinado a utilizarse para diagnosticar cualquier incidencia en la capa de infraestructura de Exadata Cloud@Customer.
  • Acción: Mantenimiento del sistema con privilegios de reinicio
    El mantenimiento del sistema con privilegios de reinicio, que se identifica como INFRA_UPDATE_RESTART, está destinado a utilizarse para escenarios de acceso de operador que requieren un cambio de configuración del sistema o un reinicio del sistema.
  • Acción: Mantenimiento del sistema con privilegios de acceso a datos/control de VM
    Mantenimiento del sistema con privilegios de acceso a datos/control de VM, que se identifica como INFRA_HYPERVISOR, está destinado a utilizarse para escenarios de diagnóstico y mantenimiento en los que se requiere la gestión de VM en el host.
  • Acción: Acceso completo al sistema
    El acceso completo al sistema, que se identifica como INFRA_FULL, permite el acceso a las cuentas raíz en los componentes de infraestructura.

Tema principal: Aplicación de acciones en Operator Access Control

Acción: solo servidor del plano de control (CPS)

Solo servidor de plano de control (CPS), que se identifica como INFRA_CPS_ONLY, está destinado a utilizarse para diagnosticar y resolver problemas de CPS únicamente. El personal de Oracle no puede acceder a los componentes más allá del CPS, incluidos los servidores de celdas y el sistema operativo host (Dom0).

Tabla 1-1 Acciones activadas con INFRA_CPS_ONLY

Nombre de la Acción

Sólo el servidor del plano de control (CPS)
Identificador de acción

INFRA_CPS_ONLY
Privilegios de Operador

Privilegio de usuario de Linux: no root

Puede su para root: no

chroot cárcel: sí

Puede utilizar su en: ninguna

sudousuario + lista de comandos: limitada a la lista proporcionada anteriormente

privilegios del servidor de celdas: no

Sistema operativo del host (Dom0): no

Privilegios de red: no

Lista de comandos ejecutables:

Estos comandos se pueden ejecutar directamente desde el indicador de Bash.

  • Alias:
    • sudols
    • sudocp
    • sudocat
    • sudotail
    • sudohead
    • sudovi
    • sudorm
    • systemctl
    • reboot
    • ifconfig
    • lsof
    • docker
    • ipmitool
    • dbmcli
    • traceroute
    • tcptraceroute
    • journalctl
    • exacloud
    • du
    • imageinfo
    • imagehistory
    • arping
    • curl
    • tcpdump
    • crontab
    • sundiag.sh
    • sosreport
    • ethtool
  • Comandos especiales soportados:
    • rootexec /root/alarm_detail.sh
    • rootexec /root/alerthistory.sh
    • rootexec /root/blackout.sh
    • rootexec /root/quarantine_ack.sh
    • rootexec /root/stateless_ack.sh
    • rootexec /root/stateless_alert.sh
    • rootexec /etc/keepalived/manual-switchover.sh

Directorios y archivos con acceso de lectura y escritura explícito:

  • Lectura y Escritura:
    • /u01/
    • /opt/oci/exacc/
  • Sólo Lectura:
    • /var/log/
    • /opt/oracle.cellos/
    • /usr/local/nessus/results/
    • /opt/nessus/var/nessus/logs/

Comandos especiales de control de acceso de operador:

Comandos de jaula para ver o modificar (lectura, lectura/escritura) archivos o directorios mencionados anteriormente:

  • sudols
  • sudocp
  • sudocat
  • sudotail
  • sudohead
  • sudovi
  • sudorm
Acción: Diagnóstico del sistema

Diagnóstico del sistema, que se identifica como INFRA_DIAG, está destinado a utilizarse para diagnosticar cualquier incidencia en la capa de infraestructura de Exadata Cloud@Customer.

El diagnóstico implica leer logs, ejecutar diagnósticos y supervisar comandos. Esta acción también está destinada a corregir incidencias con agentes de diagnóstico en el sistema Exadata Cloud@Customer. La corrección implica reiniciar los daemons de diagnóstico con parámetros potencialmente modificados.

Nota

La acción Diagnóstico del sistema no plantea riesgos de exposición de datos de clientes ni riesgos de baja disponibilidad.
La acción Diagnóstico del sistema permite lo siguiente:
  • El operador puede utilizar cat, grep, etc. para leer los archivos log del sistema operativo, el software de infraestructura y el software de orquestación en la nube.
  • El operador puede ejecutar comandos de diagnóstico de Oracle Linux, como top y netstat.
  • En los servidores de celdas, también permite al operador ejecutar comandos cellcli para obtener información de diagnóstico.
  • El operador puede acceder a la gestión de la infraestructura de orquestación en la nube en el servidor de plano de control con la capacidad de reiniciar todos los daemons en el servidor de plano de control.

Tabla 1-2 Acciones activadas con INFRA_DIAG

Nombre de la Acción

Diagnóstico del sistema
Identificador de acción

INFRA_DIAG
Privilegios de Operador

Privilegio de usuario de Oracle Linux: no root.

Puede usar su para cambiar a root: no

chroot cárcel: sí

Puede utilizar su en:
  • Celda: cellmonitor
  • Host: dbmmonitor
  • Servidor del plano de control:
    • ecra
    • exawatcher
    • dbmsvc
Ejecutar como root:
  • cat
  • head
  • tail
  • cp para archivos dentro de /var/log/*
  • [CPS]: systemctl

Privilegios del servidor de celdas: actuar como supervisor de celda.

privilegios de red: puede utilizar SSH en todos los hosts, servidores de celdas y servidores de plano de control. El nombre de usuario es el mismo en todos ellos.

Lista de comandos ejecutables:

  • Servidor de plano de control (alias): estos comandos se pueden ejecutar directamente desde el indicador de Bash.
    • systemctl
    • reboot
    • ifconfig
    • lsof
    • docker
    • ipmitool
    • dbmcli
    • traceroute
    • tcptraceroute
    • journalctl
    • exacloud
    • du
    • imageinfo
    • imagehistory
    • arping
    • curl
    • tcpdump
    • crontab
    • sundiag.sh
    • sosreport
    • ethtool
  • Servidor de celdas (alias): estos comandos se pueden ejecutar directamente desde el indicador de Bash.
    • cellcli: comandos de solo lectura
    • sundiag.sh
    • sosreport
    • lspci
    • imageinfo
    • imagehistory
  • Host (alias): estos comandos se pueden ejecutar directamente desde el indicador de Bash.
    • dbmcli: comandos de solo lectura
    • sundiag.sh
    • sosreport
    • virsh: solo opciones de lista
    • xm: solo opciones de lista
    • docker
    • podman
    • imageinfo
    • imagehistory

Directorios y archivos con acceso de lectura y escritura explícito:

  • Servidor del plano de control:
    • Lectura y escritura: /u01/
    • Sólo Lectura:
      • /var/log/
      • /opt/oci/exacc/exacloud/log/
      • /opt/oracle.cellos/
      • /usr/local/nessus/results/
      • /opt/nessus/var/nessus/logs/
    • Comandos especiales de control de acceso de operador: comandos de jaula para ver o modificar (lectura, lectura/escritura) archivos o directorios mencionados anteriormente.
      • sudols
      • sudocp
      • sudocat
      • sudotail
      • sudohead
      • sudovi
      • sudorm
  • Host:
    • Lectura y escritura: ninguna
    • Solo lectura: /var/log/
    • Comandos especiales de control de acceso de operador: comandos de jaula para ver o modificar (lectura, lectura/escritura) archivos o directorios mencionados anteriormente.
      • sudols
      • sudocp
      • sudocat
      • sudotail
      • sudohead
    Los siguientes directorios se asignan en modo de lectura-escritura para que se ejecuten las herramientas; sin embargo, a los operadores de Oracle no se les otorga acceso directo.
    • /var
    • /opt/oracle
  • Servidor de celdas:
    • Lectura y escritura: ninguna
    • Solo lectura: /var/log/
    • Comandos especiales de control de acceso de operador: comandos de jaula para ver o modificar (lectura, lectura/escritura) archivos o directorios mencionados anteriormente.
      • sudols
      • sudocp
      • sudocat
      • sudotail
      • sudohead

    Los siguientes directorios se asignan en modo de lectura-escritura para que se ejecuten las herramientas; sin embargo, a los operadores de Oracle no se les otorga acceso directo.

    • /var
    • /opt/oracle
Acción: Mantenimiento del sistema con privilegios de reinicio

Mantenimiento del sistema con privilegios de reinicio, que se identifica como INFRA_UPDATE_RESTART, está destinado a utilizarse para escenarios de acceso de operador que requieren un cambio de configuración del sistema o un reinicio del sistema.

Los escenarios de INFRA_UPDATE_RESTART suelen ser de mantenimiento. Sin embargo, puede haber escenarios de diagnóstico en los que también sea necesaria esta acción. Los cambios en la configuración del sistema implican cambios en la configuración de la red, cambios en la configuración del hardware, cambios en la configuración del sistema operativo, como montajes, inodes, ulimits o cambios en la configuración del software de orquestación en la nube. El reinicio del sistema permite al operador de Oracle reiniciar el sistema operativo (host, servidor de celdas), reiniciar subsistemas específicos, como la red, y reiniciar discos de celdas.

Atención:

Tenga en cuenta que la acción Mantenimiento del sistema con privilegios de reinicio permite reiniciar los componentes de infraestructura (servidores de base de datos, servidores de almacenamiento y servidores de plano de control) y evita el acceso a las máquinas virtuales del cliente, los datos del cliente y el servicio de auditoría de infraestructura.
La acción Mantenimiento del sistema con privilegios de reinicio:
  • Permite al operador de Oracle realizar actividades de mantenimiento del sistema con privilegios root. El operador no puede convertirse en root, pero puede ejecutar comandos de mantenimiento como root.
  • No permite al operador cambiar los parámetros de auditoría ni acceder a los logs de auditoría. Sin embargo, la acción permite al operador poner todo el sistema Exadata Cloud@Customer fuera de línea.
  • Permite a los operadores cambiar la configuración del sistema operativo mediante cambios permanentes. Por ejemplo, el operador de Oracle puede cambiar /etc/ parameters.
  • Permite al operador de Oracle iniciar procesos de daemon y gestionar los discos de celda con el privilegio de administración de celdas cellcli en servidores de celdas.
  • Permite al operador de Oracle acceder a la gestión de la infraestructura de orquestación en la nube en el servidor de planes de control, con la capacidad de reiniciar todos los datos en el servidor de planes de control.

Herencia: todos los privilegios del diagnóstico del sistema

Tabla 1-3 Acciones activadas con INFRA_UPDATE_RESTART

Nombre de la Acción

Mantenimiento del sistema con privilegios de reinicio
Identificador de acción

INFRA_UPDATE_RESTART
Privilegios de Operador

Igual que el privilegio Diagnóstico del sistema además de lo siguiente:

Puede usar su para cambiar a root: no

chroot cárcel: sí

Puede utilizar su en:
  • exawatcher
  • dbmsvc
  • dbmadmin
  • dbmmonitor en el host
Ejecutar como root:
  • restart
  • ip
  • ifconfig
  • lspci

Privilegios del servidor de celdas: celladmin en el servidor de celdas

privilegios de red: puede utilizar SSH en todos los hosts, servidores de celdas y servidores de plano de control. El nombre de usuario es el mismo en todas estas capas

Lista de comandos ejecutables:

  • Servidor de plano de control (alias): estos comandos se pueden ejecutar directamente desde el indicador de Bash.
    • systemctl
    • reboot
    • ifconfig
    • lsof
    • docker
    • ipmitool
    • dbmcli
    • traceroute
    • tcptraceroute
    • journalctl
    • exacloud
    • du
    • imageinfo
    • imagehistory
    • arping
    • curl
    • tcpdump
    • crontab
    • sundiag.sh
    • sosreport
    • ethtool
  • Servidor de celdas (alias): estos comandos se pueden ejecutar directamente desde el indicador de Bash.
    • reboot
    • sundiag.sh
    • cellcli: todos los comandos
    • lspci
    • imageinfo
    • imagehistory
    • ethtool
    • ipmitool
    • ipmitool_interactive (igual que ipmitool, se puede utilizar cuando se necesita tty)
  • Host (alias): estos comandos se pueden ejecutar directamente desde el indicador de Bash.
    • reboot
    • dbmcli: todos los comandos
    • sundiag.sh
    • virsh: solo opciones de lista
    • xm: solo opciones de lista
    • docker
    • podman
    • imageinfo
    • imagehistory
    • ethtool
    • sosreport

Directorios y archivos con acceso de lectura y escritura explícito:

  • Servidor del plano de control:
    • Lectura y escritura: /u01/
    • Sólo Lectura:
      • /var/log/
      • /opt/oci/exacc/exacloud/log/
      • /opt/oracle.cellos/
      • /usr/local/nessus/results/
      • /opt/nessus/var/nessus/logs/
    • Comandos especiales de control de acceso de operador: comandos de jaula para ver o modificar (lectura, lectura/escritura) archivos o directorios mencionados anteriormente.
      • sudols
      • sudocp
      • sudocat
      • sudotail
      • sudohead
      • sudovi
      • sudorm
  • Host:
    • Lectura y escritura: ninguna
    • Solo lectura: /var/log/
    • Comandos especiales de control de acceso de operador: comandos de jaula para ver o modificar (lectura, lectura/escritura) archivos o directorios mencionados anteriormente.
      • sudols
      • sudocp
      • sudocat
      • sudotail
      • sudohead
    Los siguientes directorios se asignan en modo de lectura-escritura para que se ejecuten las herramientas; sin embargo, a los operadores de Oracle no se les otorga acceso directo.
    • /var
    • /opt/oracle
    • /home/dbmadmin
  • Servidor de celdas:
    • Lectura y escritura: ninguna
    • Solo lectura: /var/log/
    • Comandos especiales de control de acceso de operador: comandos de jaula para ver o modificar (lectura, lectura/escritura) archivos o directorios mencionados anteriormente.
      • sudols
      • sudocp
      • sudocat
      • sudotail
      • sudohead
    Los siguientes directorios se asignan en modo de lectura-escritura para que se ejecuten las herramientas; sin embargo, a los operadores de Oracle no se les otorga acceso directo.
    • /var
    • /opt/oracle
    • /home/celladmin/
Acción: Mantenimiento del sistema con privilegios de acceso a datos/control de VM

Mantenimiento del sistema con privilegios de acceso a datos/control de VM, que se identifica como INFRA_HYPERVISOR, está destinado a utilizarse para escenarios de diagnóstico y mantenimiento en los que se requiere la gestión de VM en el host.

La acción Mantenimiento del sistema con privilegios de acceso a datos/control de VM está destinada a utilizarse para escenarios de diagnóstico y mantenimiento en los que se requiere la gestión de VM en el host. Los datos de la máquina virtual de invitado se tratan como datos de cliente. Dado que la gestión de VM implica la capacidad de acceder a los datos de VM, esta acción podría presentar un riesgo para los datos. Sin embargo, esta acción no proporciona acceso a las claves de TDE de los datos almacenados en los servidores de celdas. La gestión de VM es necesaria en los casos en los que hay problemas con la infraestructura de software de VM o en los que es necesario modificar una configuración de VM. La configuración implica el aspecto externo de las VM, como las redes asociadas, los discos conectados o los recursos (CPU, memoria) asignados.

Nota

El mantenimiento del sistema con privilegios de acceso a datos/control de VM impide el acceso al subsistema de auditoría de infraestructura.
Acción Mantenimiento del sistema con privilegios de acceso a datos/control de VM:
  • Permite al operador ejecutar comandos de gestión de Xen/KVM con privilegios root. El operador no puede convertirse en root. Esta acción solo se aplica al host.
  • Hereda los privilegios de la acción "Mantenimiento del sistema con privilegios de reinicio".
  • No permite al operador cambiar los parámetros del sistema operativo del host ni de los servidores de celdas. Sin embargo, esto permite al operador cerrar la VM de invitado y cambiar significativamente la configuración de la VM de invitado.

Herencia: todos los privilegios del mantenimiento del sistema con reinicio.

Tabla 1-4 Acciones activadas con INFRA_HYPERVISOR

Nombre de la Acción

Mantenimiento del sistema con privilegios de acceso a datos/control de VM
Identificador de acción

INFRA_HYPERVISOR
Privilegios de Operador

Igual que "Mantenimiento del sistema con privilegios de reinicio" además de lo siguiente:

Privilegio de usuario de Oracle Linux: no root.

Puede usar su para cambiar a root: no

chroot cárcel: sí

Puede usar su para cambiar a: celladmin en el servidor de celdas

Ejecutar como root:
  • /usr/sbin/xm
  • /usr/sbin/xentop
  • /usr/sbin/virsh

Privilegios del servidor de celdas: celladmin

privilegios de red: puede utilizar SSH en todos los hosts, servidores de celdas y servidores de plano de control. El nombre de usuario es el mismo en todos ellos.

Lista de comandos ejecutables:

  • Servidor de plano de control (alias): estos comandos se pueden ejecutar directamente desde el indicador de Bash.
    • systemctl
    • reboot
    • ifconfig
    • lsof
    • docker
    • ipmitool
    • dbmcli
    • traceroute
    • tcptraceroute
    • journalctl
    • exacloud
    • du
    • imageinfo
    • imagehistory
    • arping
    • curl
    • tcpdump
    • crontab
    • sundiag.sh
    • sosreport
    • ethtool
  • Servidor de celdas (alias): estos comandos se pueden ejecutar directamente desde el indicador de Bash.
    • cellcli: todos los comandos
    • lspci
    • imageinfo
    • imagehistory
    • ethtool
    • sosreport
    • reboot
    • sundiag.sh
    • ipmitool
    • ipmitool_interactive (igual que ipmitool, se puede utilizar cuando se necesita tty)
  • Host (alias): estos comandos se pueden ejecutar directamente desde el indicador de Bash.
    • dbmcli: todos los comandos
    • sundiag.sh
    • virsh: todas las opciones
    • xm: todas las opciones
    • virsh_interactive: todas las opciones (igual que virsh, se pueden utilizar cuando se necesita tty)
    • xm_interactive: todas las opciones (igual que xm, se pueden utilizar cuando se necesita tty)
    • xentop: todas las opciones
    • vm_maker: todas las opciones
    • docker
    • docker_interactive (igual que docker, se puede utilizar cuando se necesita tty)
    • podman
    • podman_interactive (igual que podman, se puede utilizar cuando se necesita tty)
    • imageinfo
    • imagehistory
    • ethtool
    • sosreport
    • ipmitool
    • ipmitool_interactive (igual que ipmitool, se puede utilizar cuando se necesita tty)
    • ops_console.sh

Directorios y archivos con acceso de lectura y escritura explícito:

  • Servidor del plano de control:
    • Lectura y escritura: /u01/
    • Sólo Lectura:
      • /var/log/
      • /opt/oci/exacc/exacloud/log/
      • /opt/oracle.cellos/
      • /usr/local/nessus/results/
      • /opt/nessus/var/nessus/logs/
    • Comandos especiales de control de acceso de operador: comandos de jaula para ver o modificar (lectura, lectura/escritura) archivos o directorios mencionados anteriormente.
      • sudols
      • sudocp
      • sudocat
      • sudotail
      • sudohead
      • sudovi
      • sudorm
  • Host:
    • Lectura y escritura: ninguna
    • Solo lectura: /var/log/
    • Comandos especiales de control de acceso de operador: comandos de jaula para ver o modificar archivos o directorios (lectura, lectura/escritura) mencionados anteriormente.
      • sudols
      • sudocp
      • sudocat
      • sudotail
      • sudohead

    Los siguientes directorios se asignan en modo de lectura-escritura para que se ejecuten las herramientas; sin embargo, a los operadores de Oracle no se les otorga acceso directo.

    • /var
    • /opt/oracle
    • /home/dbmadmin
  • Servidor de celdas:
    • Lectura y escritura: ninguna
    • Solo lectura: /var/log/
    • Comandos especiales de control de acceso de operador: comandos de jaula para ver o modificar (lectura, lectura/escritura) archivos o directorios mencionados anteriormente.
      • sudols
      • sudocp
      • sudocat
      • sudotail
      • sudohead

    Los siguientes directorios se asignan en modo de lectura-escritura para que se ejecuten las herramientas; sin embargo, a los operadores de Oracle no se les otorga acceso directo.

    • /var
    • /opt/oracle
    • /home/celladmin/
Acción: Acceso completo al sistema

Acceso completo al sistema, que se identifica como INFRA_FULL, permite el acceso a las cuentas raíz de los componentes de infraestructura.

La acción Acceso completo al sistema está destinada a utilizarse cuando se requiere acceso completo a la infraestructura de Exadata Cloud@Customer. El acceso siempre está limitado a capas de VM que no son de invitado. Un acceso completo en este caso significa disponer de privilegios raíz en cada instancia del sistema operativo del sistema Exadata Cloud@Customer, excepto las máquinas virtuales de invitado.

Nota

La acción Acceso completo al sistema permite al operador convertirse en el usuario raíz de la infraestructura. Esto permite al operador acceder y modificar cualquier registro de memoria, cualquier archivo, cualquier dispositivo y el subsistema de auditoría.

Tabla 1-5 Acciones activadas con INFRA_FULL

Nombre de la Acción

Acceso completo al sistema
Identificador de acción

INFRA_FULL
Privilegios de Operador

Privilegio de usuario de Linux: no root

Puede usar su para cambiar a root: sí

chroot cárcel: no

Directorios legibles: todos

Archivos legibles: todos

Directorios de escritura: todos

Archivos de escritura: todos

Lista de comandos ejecutables: todos

Puede usar su para cambiar a: root mediante sudo

usuario sudo + lista de comandos: sin restricciones

Privilegios del servidor de celdas: root y celladmin

privilegios de red: puede utilizar SSH en todos los hosts, servidores de celdas y servidores de plano de control. El nombre de usuario es el mismo en todos ellos. Además, conéctese a root directamente en el host y el servidor de celdas para utilizar exassh

Acciones de control de acceso de operador: Cluster de VM autónomo

Además del acceso completo al sistema, utilice las jaulas de acceso limitado, Diagnóstico y mantenimiento, para ver los logs y realizar tareas relacionadas con el servicio.

Tema principal: Aplicación de acciones en Operator Access Control

Acción: Acceso completo al sistema de cluster de VM de Exadata autónomo

El acceso completo al sistema de cluster de VM de Exadata autónomo, que se identifica como AVM_FULL, rara vez se utilizará si ninguno de los privilegios de acceso inferiores puede resolver el problema.

La acción de acceso completo al sistema de cluster de VM de Exadata autónomo está diseñada para utilizarse cuando se requiere acceso completo a las máquinas virtuales de invitado. El acceso completo aquí significa los privilegios root para las máquinas virtuales de invitado.

Nota

La acción Acceso completo al sistema plantea riesgos extremos de disponibilidad y de exposición de datos, que pueden ser persistentes. Esta acción también proporciona la capacidad de impedir la exportación de logs de auditoría del sistema.

Tabla 1-6 Acciones activadas con AVM_FULL

Nombre de la Acción

Acceso completo al sistema
Identificador de acción

AVM_FULL
Privilegios de Operador

Privilegio de usuario de Linux: no root

Puede usar su para cambiar a root: sí

Enjaulado con chroot: no

Directorios legibles: todos

Archivos legibles: todos

Directorios de escritura: todos

Archivos de escritura: todos

Lista de comandos ejecutables: todos

Puede usar su para cambiar a: root mediante sudo

usuario sudo + lista de comandos: sin restricciones

Acción: Diagnóstico de sistema de cluster de VM de Exadata autónomo

El diagnóstico del sistema de cluster de VM de Exadata autónomo, que se identifica como AVM_SYS_DIAG, se utilizará para ver los logs.

La acción Diagnóstico de sistema de cluster de VM de Exadata autónomo está destinada a utilizarse para ver logs. Un perfil de solo lectura, que permite el acceso de solo lectura sin privilegios al sistema. Esta acción se utiliza para determinar posibles problemas con el sistema operativo y el software que se ejecuta en él. La mayoría de los comandos no raíz estarán disponibles en este modo. No hay comandos con privilegios disponibles en esta acción. Los operadores no pueden ejecutar sudo como oracle, opc o grid, pero tendrán un juego de comandos en la lista blanca que pueden ejecutar como usuario de operador dinámico.

Tabla 1-7 Acciones activadas con AVM_SYS_DIAG

Nombre de la Acción

Diagnóstico de sistema de cluster de VM de Exadata autónomo
Identificador de acción

AVM_SYS_DIAG
Alcance

VM de invitado
Privilegios de Operador

Privilegio de usuario de Linux: no root

Puede su a root, oracle, opc, grid: no

Enjaulado con chroot: sí

Directorios legibles:
  • /proc
  • /sys
  • /tmp
  • /usr/lib64
  • /usr/bin
  • /usr/etc
  • /usr/include
  • /usr/lib
  • /usr/libexec
  • /usr/local
  • /usr/share
  • /opt/nessus
  • /usr/java
  • /var
  • /u01
  • /u02
  • /acfs01
  • /opt/oracle/dcs/log
  • /opt/oracle.ExaWatcher/archive

Los directorios se pueden escribir: /tmp

Ubicaciones legibles de log de aplicaciones restringidas:
  • /etc/oratab
  • /opt/oracle/dcs/log
  • /opt/oracle/dcs/idempotencytoken_jobid_db
  • /u02/oracle.ahf
  • /u02/app/oracle/diag/rdbms
  • /opt/oracle.ExaWatcher/archive
Archivos de configuración legibles:
  • /etc/oratab
  • /opt/oracle/dcs/idempotencytoken_jobid_db
  • /etc/hosts

Acceso a red de salida: ninguno

Comandos del sistema operativo incluidos en la lista negra:
  • dd
  • kdumpctl
  • ipcrm
  • ipcmk

Lista de comandos ejecutables: los comandos ls, cat y tail se admiten en las ubicaciones en las que el usuario dinámico opctl no tiene acceso de lectura

Limitar el acceso del operador a una base de datos de contenedor autónoma (ACD) aprobada por el cliente específica

Restrinja el acceso a un ACD específico en un cluster de VM autónomo en las jaulas de diagnóstico y mantenimiento.

Los operadores pueden especificar si necesitan:

  • Acceso solo SSH al cluster de VM autónomo sin acceso SQL a los ACD. En este caso, se bloqueará todo el acceso SQL a las ACD.
  • Acceso SSH al cluster de VM autónomo y acceso SQL a los ACD. Si seleccionan ambos, deben seleccionar uno o más ACD.

El cliente recibe una solicitud de aprobación con los detalles a los que los operadores solicitan acceso. De esta forma, el cliente puede estar seguro de que los operadores tendrán acceso a la ACD adecuada. Una vez que el cliente aprueba la solicitud de acceso, los operadores obtendrán acceso SQL solo a los ACD para los que se hayan aprobado.

El atributo Request Reason mostrará a qué ACD solicitan acceso los operadores.

Acción: Mantenimiento de sistema de cluster de VM de Exadata autónomo

El mantenimiento del sistema de cluster de VM de Exadata autónomo, que se identifica como AVM_SYS_MAINT, se utilizará para realizar cambios relacionados con el servicio.

La acción de mantenimiento del sistema de cluster de VM de Exadata autónomo está destinada a utilizarse para realizar cambios relacionados con el servicio. Esta acción se utiliza para iniciar y parar servicios, y ejecutar comprobaciones de estado del servicio. La mayoría de los comandos relacionados con el servicio están disponibles en este modo. El operador tendrá acceso a los logs, pero no podrá utilizar su en oracle, opc ni grid.

Tabla 1-8 Acciones activadas con AVM_SYS_MAINT

Nombre de la Acción

Mantenimiento de sistema de cluster de VM de Autonomous Exadata
Identificador de acción

AVM_SYS_MAINT
Alcance

VM de invitado
Privilegios de Operador

Privilegio de usuario de Linux: no root

Puede su a root, oracle, opc, grid: no

Enjaulado con chroot: sí

Directorios legibles:
  • /proc
  • /sys
  • /tmp
  • /usr/lib64
  • /usr/bin
  • /usr/etc
  • /usr/include
  • /usr/lib
  • /usr/libexec
  • /usr/local
  • /usr/share
  • /opt/nessus
  • /usr/java
  • /var
  • /u01
  • /u02
  • /acfs01
  • /opt/oracle/dcs/log
  • /opt/oracle.ExaWatcher/archive

Los directorios se pueden escribir: ninguno

Ubicaciones legibles de log de aplicaciones restringidas:
  • /etc/oratab
  • /opt/oracle/dcs/log
  • /opt/oracle/dcs/idempotencytoken_jobid_db
  • /u02/oracle.ahf
  • /u02/app/oracle/diag/rdbms
  • /opt/oracle.ExaWatcher/archive
Archivos de configuración legibles:
  • /etc/oratab
  • /etc/crontab
  • /opt/oracle/dcs/idempotencytoken_jobid_db
  • /etc/hosts

Acceso a red de salida: ninguno

Comandos del sistema operativo incluidos en la lista negra:
  • dd
  • kdumpctl
  • ipcrm
  • ipcmk

Alias de comandos: {"job_manager" : "/var/opt/oracle/adbd/apps/job_manager/job_manager.py", "backup_api" : "/var/opt/oracle/bkup_api/bkup_api", "service_driver" : "/var/opt/oracle/pylib/DBAAS/service_driver.py"}

Lista de comandos ejecutables: la ejecución de comandos relacionados con el servicio está disponible tal cual, pero sin cambiar al usuario oracle o grid. La ejecución de scripts está soportada mediante alias sin cambiar al usuario oracle o grid.

Consulte los ejemplos que se proporcionan a continuación.

  • crsctl status resource adbd_archive_log_ilkzdar1
  • crsctl check cluster -all
  • crsctl stat res -t
  • crsctl stat res ora.asm -t
  • srvctl status service -db ilkzdar1_cdg1hw
  • srvctl status database -d hr5zxn5l_cdg1bg
  • srvctl status instance -i hr5zxn5l1 -d hr5zxn5l_cdg1bg
  • tfactl blackout add -targettype host -timeout 2h -reason "Testing maint cage" -c
  • dgmgrl
  • asmcmd lsdsk -p

    (No está permitido debido a un posible acceso a la consola del sistema)

  • sysresv

    (No está permitido debido a opciones para eliminar recursos ipc)

  • SQL*Plus está restringido a las consultas seleccionadas. No se admite el cambio a oracle o grid.

    opctl_avm_maint_user01@atpd-exa-suzzm1:~$ execsql ORACLE_UNQNAME is required.Check /etc/oratab opctl_avm_maint_user01@atpd-exa-suzzm1:~$

    opctl_avm_maint_user01@atpd-exa-suzzm1:~$ cat /etc/oratab | grep -v '^\s*$\|^\s*\#' ownwdhci_iad2pn:/u02/app/oracle/product/19.0.0.0/db1916_0_wc139_cl_atksxzha_096_0105:Y +ASM1:/u02/app/19.0.0.0/grid1916_0_wc140_cl_atksxzha_096_1334:Y ay5sq1qf_iad2bp:/u02/app/oracle/product/19.0.0.0/db1916_0_wc141_cl_atksxzha_096_0214:Y dhb2br6k_iad22z:/u02/app/oracle/product/19.0.0.0/db1916_0_wc142_cl_atksxzha_096_0416:Y v001zhgm_iad2zs:/u02/app/oracle/product/19.0.0.0/db1916_0_wc143_cl_atksxzha_096_0419:Y drmgiyo6_iad277:/u02/app/oracle/product/19.0.0.0/db1916_0_wc138_cl_atksxzha_096_0033:Y fflilzax_iad2km:/u02/app/oracle/product/19.0.0.0/db1916_0_wc145_cl_atksxzha_096_0411:Y gytjhr9o_iad2tt:/u02/app/oracle/product/19.0.0.0/db1916_0_wc144_cl_atksxzha_096_0411:Y dqk29prh_iad2hc:/u02/app/oracle/product/19.0.0.0/db1916_0_wc146_cl_atksxzha_096_0416:Y utynogge_iad2p8:/u02/app/oracle/product/19.0.0.0/db1916_0_wc147_cl_atksxzha_096_1213:Y my06yvoe_iad2km:/u02/app/oracle/product/19.0.0.0/db1916_0_wc149_cl_atksxzha_096_1218:Y nfcteuzf_iad2j9:/u02/app/oracle/product/19.0.0.0/db1916_0_wc148_cl_atksxzha_096_1216:Y opctl_avm_maint_user01@atpd-exa-suzzm1:~$

    opctl_avm_maint_user01@atpd-exa-suzzm1:~$ execsql utynogge_iad2p8

    SQL*Plus: Release 19.0.0.0.0 - Production on Thu Oct 6 06:32:11 2022 Version 19.16.0.1.0 Copyright (c) 1982, 2020, Oracle. All rights reserved. Last Successful login time: Thu Oct 06 2022 06:29:09 +00:00 Connected to: Oracle Database 19c EE Extreme Perf Release 19.0.0.0.0 - Production Version 19.16.0.1.0 SQL> SELECT INSTANCE_NAME, STATUS, DATABASE_STATUS FROM V$INSTANCE; INSTANCE_NAME STATUS DATABASE_STATUS ---------------- ------------ ----------------- utynogge1 OPEN ACTIVE SQL> SELECT sys_context('userenv','instance_name') FROM dual; SYS_CONTEXT('USERENV','INSTANCE_NAME') -------------------------------------------------------------------------------- utynogge1 SQL> !whoami SP2-0738: Restricted command "! (HOST)" not available SQL> !ls -ltr SP2-0738: Restricted command "! (HOST)" not available SQL>

Scripts que se van a ejecutar como se indica a continuación con alias.
  • /var/opt/oracle/adbd/apps/job_manager/job_manager.py --get_status adbd_archive_log_ilkzdar1

    Para ejecutar como: job_manager --get_status adbd_archive_log_ilkzdar1

  • /var/opt/oracle/pylib/DBAAS/service_driver.py --dbname=hr5zxn5l_cdg1bg

    Para ejecutar como: service_driver --dbname=hr5zxn5l_cdg1bg

  • /var/opt/oracle/bkup_api/bkup_api --dbname ilkzdar1 list jobs

    Para ejecutar como: backup_api --dbname ilkzdar1 list jobs

Limitar el acceso del operador a una base de datos de contenedor autónoma (ACD) aprobada por el cliente específica

Restrinja el acceso a un ACD específico en un cluster de VM autónomo en las jaulas de diagnóstico y mantenimiento.

Los operadores pueden especificar si necesitan:

  • Acceso solo SSH al cluster de VM autónomo sin acceso SQL a los ACD. En este caso, se bloqueará todo el acceso SQL a las ACD.
  • Acceso SSH al cluster de VM autónomo y acceso SQL a los ACD. Si seleccionan ambos, deben seleccionar uno o más ACD.

El cliente recibe una solicitud de aprobación con los detalles a los que los operadores solicitan acceso. De esta forma, el cliente puede estar seguro de que los operadores tendrán acceso a la ACD adecuada. Una vez que el cliente aprueba la solicitud de acceso, los operadores obtendrán acceso SQL solo a los ACD para los que se hayan aprobado.

El atributo Request Reason mostrará a qué ACD solicitan acceso los operadores.

Acciones de Operator Access Control: Compute Cloud@Customer

En ocasiones, los operadores autorizados necesitan acceder a recursos para actualizar Compute Cloud@Customer, solucionar problemas o ayudar a resolver un problema.

Tema principal: Aplicación de acciones en Operator Access Control

Acción: Acceso completo a la infraestructura de Compute Cloud@Customer

El acceso completo a la infraestructura de Compute Cloud@Customer se identifica como CCC_SYS_ADMIN_FULL_ACCESS.

Tabla 1-9 Acciones activadas con CCC_SYS_ADMIN_FULL_ACCESS

Nombre de la Acción

Acceso completo al sistema
Identificador de acción

CCC_SYS_ADMIN_FULL_ACCESS
Privilegios de Operador

Privilegio de usuario de Linux: no root

Puede usar su para cambiar a root: sí

Enjaulado con chroot: no

Directorios legibles: todos

Archivos legibles: todos

Directorios de escritura: todos

Archivos de escritura: todos

Lista de comandos ejecutables: todos

Puede usar su en: root a través de sudo y ejecutar todos los comandos como usuario root

Límites de Operator Access Control

Operator Access Control es una solución diseñada para la auditoría y la conformidad del acceso de Oracle, no una solución de conformidad de uso general.

Operator Access Control solo audita los usuarios autorizados creados en el contexto de una solicitud de acceso asociada con un control de acceso de operador de Oracle. A continuación se muestra una lista de ejemplos de acciones de control y auditoría de conformidad que Operator Access Control no gestiona.

  • Operator Access Control solo controla las capas que posee Oracle. Por ejemplo, Operator Access Control controla el acceso a los servidores físicos Exadata Database Server y Exadata Storage Server.
  • Operator Access Control no controla las acciones de automatización, incluidas las acciones que se ejecutan como root, ni otros usuarios de automatización con privilegios altos, incluido el acceso de automatización basado en proxy.
  • Operator Access Control solo ofrece controles en el nivel de acciones definidas. Las propias acciones controlan el acceso a una aplicación en el nivel del sistema operativo.
  • Operator Access Control no es un servicio de auditoría general. Solo audita los usuarios autorizados creados en el contexto de una solicitud de acceso asociada a un control de operador.
  • Operator Access Control solo controla las distintas capas de los sistemas Exadata Cloud@Customer. No ofrece controles de entidades externas de Oracle Cloud Infrastructure, como los conmutadores u otro software de plano de control.

Roles de puesto de arrendamiento de cliente de Operator Access Control

Para establecer el control de acceso del operador, debe configurar políticas de control de acceso y establecer grupos de usuarios responsables de gestionar y supervisar el acceso a la infraestructura.

Tema principal: Visión general de Oracle Operator Access Control

Creación de control de operador para administradores de políticas

Los administradores de políticas son los usuarios que tienen permisos para configurar políticas de control de operador (denominadas Control de operador).

Para crear un control de acceso de operador en su infraestructura, el primer paso es crear administradores de políticas de control de operador que desarrollen y creen el juego de controles de operador que desea utilizar para los administradores del conjunto de su arrendamiento.

Normalmente, al crear controles de operador, debe dividir la infraestructura de Exadata en grupos de control de acceso basados en varias dimensiones:

  • Importancia en el negocio: sistemas críticos, sistemas menos críticos, sistemas de desarrollo
  • Seguridad o conformidad: sistemas con necesidades de conformidad específicas y otros
  • Grupos de usuarios: qué grupos de usuarios (normalmente con el rol de administrador de conjuntos) desea que sean responsables de un juego de sistemas Exadata

Algunos ejemplos de grupos de usuarios responsables de un juego de sistemas Exadata:

  • Departamentos verticales, cuyas aplicaciones dependen de un juego de sistemas Exadata.
  • Sistemas compartidos entre varios departamentos, en los que un departamento de TI es responsable de la administración.

Normalmente, los compartimentos se crean en la infraestructura según criterios de importancia, conformidad normativa y gestión de grupos de usuarios, ya que los compartimentos conforman los límites administrativos lógicos en Oracle Cloud Infrastructure. Normalmente, cada compartimento tiene un grupo de usuarios al que se otorgan privilegios de gestión en el compartimento. Por este motivo, el administrador de políticas debe crear el mismo número de controles de operador que de compartimentos existentes que contengan infraestructuras de Exadata.

Además de controles de los operador específicos para compartimentos, también debe crear una política adicional, denominada DEFAULT_OPERATOR_CONTROL, que puede utilizar para crear nuevos juegos de sistemas Exadata en compartimentos nuevos, para los que puede crear un juego diferente de usuarios administrativos.

Cómo se aprueban las solicitudes de acceso de operador

Consulte cómo puede gestionar las aprobaciones de control de operador mediante la configuración de un régimen de Identity and Access Management (IAM) mediante las políticas de Oracle Operator Access Control.

Los administradores de arrendamiento para los controles de operador de un sistema de Oracle Cloud son miembros del grupo de administradores de control de operador para Controles de operador. Recibirá solicitudes de control de operador para acceder a Oracle Cloud Infrastructure. Para respaldar sus requisitos de conformidad normativa, puede controlar el acceso a su infraestructura. Puede especificar que algunas acciones tengan siempre el estado Aprobado automáticamente y especificar que otras acciones deban recibir aprobación para que Oracle pueda realizar operaciones de mantenimiento del sistema en su arrendamiento. Al otorga acceso al sistema, ese acceso se limita automáticamente a una duración de tiempo estándar. También puede especificar que las operaciones deben realizarse dentro del marco temporal determinado que especifique.

Ejemplo 1-1 Controles de operador para una política de IAM de Oracle Cloud Infrastructure

Puede definir controles detallados en los permisos que otorgue en el sistema.

Por ejemplo, supongamos que tiene dos grupos de sistemas de Exadata Cloud en un compartimento en el que es el administrador del arrendamiento. Como parte de la política de IAM, ha creado dos juegos independientes de sistemas Exadata: el primer grupo de sistemas tiene todas las configuraciones de políticas de operador definidas en Preaprobado, y el segundo grupo de sistemas no tiene ninguna política de operador definida en Preaprobado.

También ha creado dos grupos de usuarios: PRE_APPROVED_POLICY_USERS y EXPLICIT_APPROVED_POLICY_USERS. Los grupos de Control de operador se identifican mediante el etiquetado que les proporcione: el espacio de nombres optctl tiene dos grupos de Control de operador. Uno se identifica mediante la etiqueta pre-approved-exacc. El segundo grupo se identifica mediante la etiqueta explicit-approved-exacc. Por tanto, a grandes rasgos, tiene un juego de servidores en el que todas las acciones están preaprobadas, y un juego de servidores en el que no hay ninguna acción preaprobada.

A continuación, en el compartimento, supongamos que ha establecido un juego de recursos de Exadata Cloud, cada uno de los cuales representa un nivel de acciones permitidas:

  • system_diag especifica permisos para que las acciones diagnostiquen cualquier incidencia en la capa de infraestructura de Exadata Cloud@Customer, como la lectura de logs, la ejecución de diagnósticos y la supervisión de comandos. Puede otorgar a los miembros de esta política la acción INFRA_DIAG.
  • system_main especifica permisos para que las acciones realicen el diagnóstico y el mantenimiento del sistema, además de la opción para reiniciar el sistema. Puede otorgar a los miembros de esta política la acción INFRA_UPDATE_RESTART, pero la autorización está definida en Especificar autorización.
  • system_all otorga permisos completos de privilegios de administración del sistema en el sistema, incluido el uso no restringido de sudo. Puede otorgar a los miembros de esta política la acción INFRA_FULL. No tiene ningún grupo de políticas creado con esta acción.

En los recursos en los que ha configurado la política system_diag, ha marcado como Preaprobado todas las actividades de administración permitidas por esa acción. Ha especificado que se otorgue a los miembros del grupo PRE_APPROVED_POLICY_USERS acceso para utilizar system_diag con el estado Preaprobado en el arrendamiento

Supongamos que, posteriormente, un operador de Oracle que es miembro del grupo PRE_APPROVED_POLICY_USERS solicita acceso a un servidor, pero solicita la acción INFRA_UPDATE_RESTART porque una acción de mantenimiento requiere un reinicio. El operador de Oracle debe solicitar acceso para la acción que permite a un operador reiniciar el sistema como parte de una acción de mantenimiento. Puede otorgar acceso a la política system_main, pero todas las acciones que requieren acceso a esta política requieren aprobación.

Tenga en cuenta que, en cualquier momento, como administrador, independientemente de la pertenencia a grupo o la aprobación existentes, puede revocar el acceso al operador. Si elimina un operador de Oracle de la pertenencia a un grupo, el operador no tendrá acceso al sistema.

Cómo se audita el acceso de operador

Descubra cómo se capturan los logs y cómo puede auditar las actividades del operador.

Nota

Los logs de auditoría se recopilan mediante el subsistema auditd en el núcleo de Linux. Para agregar reglas de Operator Access Control para recopilar los logs, debe reiniciar el sistema Exadata después de asignar un control de operador la primera vez. No es necesario reiniciar el sistema Exadata para las asignaciones posteriores.

Extensión de los logs de auditoría capturados

El servicio de control de acceso de operador registra las acciones realizadas por el operador en un sistema controlado. Los logs se capturan para dos categorías amplias.
  • Logs de eventos de ciclo de vida
  • Logs de comandos

El primero son los eventos de ciclo de vida y el segundo son los comandos ejecutados por el operador en los hosts de destino.

Logs de eventos de ciclo de vida

El servicio Control de acceso de operador captura los eventos de conexión y desconexión solo para los usuarios autorizados del servicio Control de acceso de operador y no captura los eventos de conexión de automatización.

Logs de comandos

El servicio de control de acceso de operador captura todos los comandos ejecutados por los usuarios autorizados en un shell. Captura la entrada del comando sin ninguna ocultación y no captura la salida del comando. También captura todos los comandos de shell ejecutados mediante scripts de shell.

Por ejemplo, el servicio de control de acceso de operador captura el siguiente comando: 
netstat -an | grep 8080
Además, también se capturan los comandos que se ejecutan mediante el script de shell searchlog.sh en este caso.
./searchlog.sh –process "cellservice"
Los logs de comandos incluyen comandos ejecutados por un usuario incluso después de que se haya realizado su. Por ejemplo, después de la conexión, si el usuario autorizado auth_user_123 ejecuta los siguientes comandos, el servicio Operator Access Control captura todos estos comandos.
su - celladmin
tail -n 10 /var/log/messages

Registro de teclado

Además, los logs de comandos también se pueden capturar en formato de log de teclado. El registro de teclado captura cada pulsación de tecla que realizan los operadores en sus computadoras. No tiene muchos prácticos capturar el registro de teclado, sin embargo, hay casos en los que los requisitos normativos requieren capturar el registro de pulsaciones de teclas.

Elementos no registrados

El servicio de control de acceso de operador no registra comandos de automatización ni eventos del ciclo de vida. Si bien este servicio registra todos los comandos ejecutados en el shell directamente o mediante la invocación de scripts de shell, no registra las acciones realizadas por los ejecutables binarios. Por lo tanto, si un operador se conecta al servidor de celdas y, a continuación, accede a un shell cellcli, los logs se limitarán a capturar únicamente los comandos de shell cellcli. El servicio de control de acceso de operador no registra los comandos que se ejecutan dentro de cellcli.

Formato de logs de auditoría

Los logs de auditoría tienen el formato de texto JSON. Los logs de auditoría se clasifican en dos partes: los datos no procesados y los datos interpretados. Los datos no procesados no son comprensibles fuera del contexto de la máquina de Linux en la que se capturó el log. Por ejemplo, los datos no procesados no hacen referencia a nombres de usuario de Linux, sino a identificadores internos. La asignación del identificador al usuario solo se puede realizar en la máquina de Linux en la que se capturó el log.

Además de la interpretación, el formato también establece el contexto proporcionando el "identificador de solicitud de acceso" en los logs.

Logs de eventos de ciclo de vida

Los dos ejemplos siguientes proporcionan el formato del log de auditoría para eventos de ciclo de vida. En los ejemplos se muestra un evento de conexión y un evento de desconexión. El nombre de usuario utilizado para esta conexión es "USERNAME".

Ejemplo 1-2 Log de evento de conexión

{
"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"
}

Ejemplo 1-3 Log de evento de desconexión

{
"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"
}

Logs de comandos

Los logs de comandos son más detallados. Proporcionan información sobre el comando, los parámetros del comando y el usuario efectivo que ejecuta el comando. Los comandos también tienen una jerarquía en el sentido de que la ejecución de un script de shell primero tendrá un bash -c registrado y, a continuación, los comandos de script.

Ejemplo 1-4 Ejecución 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"
}

El título del campo proporciona el comando que se ha ejecutado. Los datos no procesados proporcionan mucha más información.

Frecuencia de recopilación

El servicio de control de acceso de operador recopila los logs a medida que se producen los eventos, realiza el registro de hora y envía los logs al servicio de registro periódicamente. Intenta insertar los logs en cada intervalo de 30 segundos.

Acceso a los logs de auditoría

Puede acceder a los logs de auditoría mediante el servicio de registro. Para obtener más información, consulte Visión general de Logging.

El JSON que se muestra en la sección 2 está disponible en el servicio de registro. Utilice su arrendamiento para acceder al servicio de registro. Los logs se publican en el compartimento en el que se ha creado el control de operador. Los logs se etiquetan en el control de operador.

Políticas de retención de logs de auditoría

Los logs de auditoría se retienen en el arrendamiento de usuario y, por lo tanto, el servicio de control de acceso de operador no controla la duración de los logs de auditoría. Puede controlar la duración del período de retención. Sin embargo, si este servicio no ha podido insertar los logs en el arrendamiento de usuario, intentará retener los logs en la medida en que lo permitan las configuraciones de Exadata. El período de retención es considerable, pudiendo ser de días o más.

Reenvío de logs de auditoría de Operator Access Control a sistemas SIEM

Puede optar por reenviar logs de auditoría de Operator Access Control directamente desde Exadata Cloud@Customer a los sistemas de información de seguridad y gestión de eventos (SIEM) de su centro de datos.

Para mejorar la gestión de la seguridad, puede transmitir logs de auditoría al servicio OCI Logging y a los sistemas SIEM de sus centros de datos. Para transmitir estos logs de auditoría a sistemas SIEM, se utiliza syslog sobre TCP.

Tema principal: Visión general de Oracle Operator Access Control

Despliegue de un servidor Syslog en el centro de datos

Para recibir logs de auditoría desde Exadata Cloud@Customer, despliegue un servidor Syslog el centro de datos. El servidor Syslog puede ser el que desee. La mayoría de los sistemas Linux se suministran con rsyslog.

Puede reenviar logs de auditoría a un solo servidor Syslog para cada sistema Exadata Cloud@Customer de destino. Oracle solo soporta la comunicación segura y utiliza TLS para la seguridad de transmisión. El servidor de plano de control se conecta con el servidor Syslog y entrega todos los logs de auditoría mediante TCP seguro. Para establecer la confianza entre el servidor de plano de control y el servidor Syslog, utilice un archivo de certificado de CA del servidor Syslog con formato PEM. La extensión de archivo debe ser .pem, .cer o .crt. Para obtener más información sobre la configuración, consulte Ejemplo de configuración de servidor Syslog.

El log contiene elementos ya descritos en el capítulo Gestión y búsqueda de logs con control de acceso de operador. Se garantiza que el formato es compatible con los analizadores de log syslog y audit-d. Consulte el log de auditoría de ejemplo.

El envío de logs de auditoría a sistemas SIEM se realiza sobre la base del mayor esfuerzo. Mientras que el servidor de plano de control vuelve a intentar el envío de logs en los fallos de red, los paquetes se pueden borrar de forma silenciosa en los umbrales. En estos casos, se toman como referencia los logs que se muestran a través del servicio OCI Logging.

Nota

Para reenviar logs de auditoría, debe asignar al menos un control de operador al sistema Exadata Cloud@Customer indefinidamente (SIEMPRE ASIGNADO).

Ejemplo de configuración de servidor Syslog

Para consultar cómo puede configurar un servidor Syslog de su elección, utilice este ejemplo.

Antes de intentar configurar el servidor Syslog, debe estar preparado para hacer lo siguiente:
  1. Abrir un puerto de red para recibir logs remotos.
    Nota

    Las reglas de salida para el servidor de Syslog deben estar abiertas para el puerto de Syslog. Por ejemplo, si el puerto 6514 se utiliza para Syslog, la regla de seguridad de salida debe estar activa para permitir que el tráfico llegue a Syslog desde el cluster de máquina virtual autónomo.
  2. Activar el cifrado en el servidor Syslog para la comunicación remota.
  3. (Opcional) Generar y transferir un certificado raíz para una comunicación segura.
Nota

El ejemplo que se proporciona a continuación es para configurar un servidor rsyslog (v 8.24) en un equipo con Oracle Linux 7. La configuración suele estar disponible en /etc/rsyslog.conf. En este ejemplo, solo se tratan las secciones relevantes.

Para este ejemplo, el puerto de recepción es 10514. Hay varios orígenes disponibles en Internet para ayudarle a cifrar el tráfico de Syslog. Una buena referencia es 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
...

Prueba de conectividad entre el CPS y el servidor Syslog

Asegúrese de haber proporcionado una dirección IP o un nombre de host válidos para el servidor Syslog.

El servidor Syslog debe poder recibir logs de un cliente Syslog y se debe poder acceder a él desde Exadata Cloud@Customer. Para confirmar la configuración, utilice este procedimiento.
  1. Para validar que el servidor Syslog puede recibir logs, ejecute el comando nc con respecto al servidor Syslog y el puerto Syslog desde cualquier host de la red que tenga acceso al servidor Syslog.
    nc syslog server host syslog port
  2. Para garantizar que la ruta entre Exadata Cloud@Customer y el servidor Syslog es válida, haga ping en la dirección IP del servidor de plano de control de Exadata Cloud@Customer. Para obtener la dirección IP del servidor de plano de control (CPS), póngase en contacto con el administrador de red.

Ejemplo de logs de auditoría

Como administrador, consulte ejemplos de los logs de auditoría recibidos de forma segura desde el servidor de plano de control.

Al transmitir logs al servidor Syslog, se omiten muchas cabeceras y el formato JSON. En los siguientes ejemplos se muestra la naturaleza de los datos enviados a través de Syslog.

Ejemplo 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'

Ejemplo 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'