Activación de operaciones de seguridad

La seguridad se encuentra entre las principales preocupaciones cuando las empresas empiezan el proceso de adopción de la nube.

Dado que el desarrollo en la nube es rápido, tanto el director de seguridad de la información (CISO) como los equipos relacionados suelen hacer preguntas sobre la seguridad antes de desplegar la primera carga de trabajo en la nube. Las preguntas pueden incluir los siguientes ejemplos:

• ¿Cómo sabemos si se producen errores de configuración y actividades arriesgadas en la nube?
• ¿Cómo acortamos el tiempo de respuesta cuando ocurre un incidente?
• ¿Cómo se aplican las mejores prácticas de seguridad?
• ¿Cómo podemos integrar las operaciones en la nube en nuestras prácticas de seguridad existentes?
• ¿Cómo podemos estar al día con los nuevos servicios y las mejores prácticas?
• ¿Cómo cumplimos las normativas de conformidad?

Para obtener más información, consulte La misión del CISO centrado en la nube.

Activación anticipada de equipos de operaciones de seguridad

Una parte esencial de la incorporación a OCI es colaborar con sus equipos de seguridad al comienzo de su iniciativa de adopción de la nube. Colabore con sus equipos de plataformas y operaciones para incluir prácticas de seguridad en la nube en todas las operaciones.

Para la mayoría de las organizaciones, la adopción de la nube implica una curva de aprendizaje alta y un gran cambio de cultura que abarca varios equipos. Obtenga el compromiso temprano de sus equipos de seguridad cibernética durante la fase de planificación y arquitectura, en lugar de después, para que pueda ayudar a los equipos a diseñar y alinear los procesos con un entendimiento común de las funciones y limitaciones de los servicios en la nube. Con la opinión temprana de los equipos de plataforma y aplicaciones, los procesos de gestión de seguridad son más propensos a ser un activador y protector de su iniciativa en la nube, en lugar de un bloqueo tardío.

Uso de Cloud Guard

Cloud Guard es un servicio en la nube que ayuda a los usuarios a supervisar, identificar, lograr y mantener una postura de seguridad sólida en el Oracle Cloud. Utilice el servicio para examinar sus recursos de OCI en busca en busca de deficiencias de seguridad relacionadas con la configuración, y los operadores y usuarios de OCI para detectar actividades arriesgadas. Tras la detección, Cloud Guard puede ofrecer sugerencias, prestar asistencia o tomar medidas correctivas, en función de la configuración.

• Cloud Guard utiliza "recetas" de detector y responsable de respuesta gestionadas por Oracle o por el usuario. Las recetas son combinaciones de reglas que identifican o responden a diferentes condiciones.
• Puede dirigir compartimentos de OCI con recetas del detector para que Cloud Guard pueda detectar recursos mal configurados y actividades poco seguras en los inquilinos.
• Cloud Guard proporciona a los administradores de seguridad visibilidad para establecer prioridades y resolver problemas de seguridad en la nube.
• Las incoherencias de seguridad se pueden solucionar automáticamente con recetas de seguridad listas para usar para que pueda ampliar de forma rápida y eficaz las operaciones de seguridad.
• Puede integrar los detalles de eventos de Cloud Guard, como el umbral de problema alcanzado o el problema detectado, con procesos existentes mediante el servicio OCI Notifications. Por ejemplo, Notifications puede enviar mensajes de correo electrónico o Slack, o activar la automatización mediante funciones de OCI personalizadas.
• Las recetas gestionadas por Oracle proporcionan una línea base excelente porque OCI las mantiene actualizadas con las últimas reglas. Su equipo de políticas de seguridad (equipo verde) puede ajustar aún más estas reglas para ajustarlas mejor a las necesidades de su organización mediante la clonación de recetas gestionadas por Oracle para crear recetas gestionadas por el usuario, incluida la desactivación de una regla, la revisión de un nivel de riesgo, etc.

Preste atención a la hora de elegir la región de informes

Al activar Cloud Guard, se le solicita que seleccione una región de informes. Tenga en cuenta las siguientes consecuencias de la elección de la región de informes:

• La región de informe que seleccione compromete a su organización a cumplir con todos los requisitos legales del país en el que se aloje dicha región de informe.
• Después de activar Cloud Guard, no se puede cambiar la región de informe sin desactivar y volver a activar Cloud Guard.
• Al desactivar Cloud Guard, se pierden todas las personalizaciones y los problemas existentes, incluido su historial, y debe restaurarlas manualmente.
• Todas las llamadas a la API, excepto en el caso de READ, se deben realizar en la región de informes. Asegúrese de tomar la mejor decisión para su región de informes antes del inicio de los pasos para Activar Cloud Guard.

Planificación de la Asignación de los Destinos a los Compartimentos

Si necesita configurar destinos para permitir que los diferentes compartimentos se supervisen de forma diferente, tenga en cuenta las siguientes directrices al asignar destinos a compartimentos:

• Todos los compartimentos de un destino heredan la configuración de ese destino. Los ajustes de las reglas de detector y responsable de respuesta de un destino se aplican al compartimento de nivel superior asignado a ese destino y a cualquier compartimento subordinado que se encuentre debajo de él en la jerarquía de compartimentos. Si desea excluir algunos compartimentos de la supervisión, cree destinos bajo el nivel raíz y no incluya el compartimento raíz en ningún destino.
• Si se define un destino dentro de un destino existente, se puede sobrescribir la configuración heredada. Dentro de un destino existente, puede asignar un compartimento que se encuentre por debajo del compartimento de nivel superior de dicho destino a un nuevo destino. Puede cambiar los valores de las reglas de detector y responsable de respuesta del nuevo destino y esos valores se aplican al compartimento de nivel superior asignado a ese destino y a todos los compartimentos subordinados que haya debajo de él en la jerarquía de compartimentos.

Decisiones clave de diseño

La siguiente información describe la decisión de diseño clave:

• Región de informes de Cloud Guard, que no se puede cambiar sin desactivar Cloud Guard

• Defina la estrategia inicial de excepciones y objetivos de nivel superior:

  • ¿Se puede excluir cualquier compartimento de la supervisión de Cloud Guard, como un sandbox o PoC?

    Si no es así, defina el destino inicial en el compartimento raíz para asegurarse de que todo el arrendamiento está bajo supervisión sin excepción.

    En caso afirmativo, solo cree el destino de Cloud Guard en el compartimento no raíz para permitir la excepción.

• Evalúe las recetas de respuesta y el ámbito de aplicación aplicable.

• Flujo operativo de la supervisión de Cloud Guard, por ejemplo:
  • ¿Quién puede modificar recetas y destinos?
  • ¿Quién debe llevar a cabo las acciones correctivas cuando no se aplica la respuesta automática?

Evaluación y uso de Security Zones con Cloud Guard

Cloud Guard detecta una configuración incorrecta y las zonas de seguridad ayudan a evitar que se produzcan estos problemas.

Una zona de seguridad se crea asociando un compartimento a una receta de zona de seguridad. Al crear y actualizar recursos en una zona de seguridad, OCI valida estas operaciones con respecto a la lista de políticas definida en la receta de zona de seguridad. Si se infringe alguna política de zona de seguridad, se deniega la operación. Sin embargo, los recursos existentes que se hayan creado antes de la zona de seguridad también podrían infringir las políticas. OCI Security Zones se integra con Cloud Guard para identificar infracciones de políticas en los recursos existentes.

Oracle gestiona una sola receta predefinida denominada recte de máxima seguridad, que incluye todas las políticas de zona de seguridad disponibles. Debido a que las políticas de la receta de máxima seguridad son relativamente estrictas y no se se pueden personalizar, la organización debe tenerlas en consideración para cargas de trabajo adecuadas solo tras evaluar conjuntamente la zona del área de seguridad con el arquitecto de la aplicación. Cree sus propias recetas de seguridad cuando sea necesario.

Principios de seguridad

En general, las políticas de las zonas de seguridad se ajustan a los siguientes principios de seguridad básicos:

• Los recursos de una zona de seguridad no se pueden mover a un compartimento fuera de la zona de seguridad porque podría ser menos seguro.
• Todos los componentes necesarios para un recurso en una zona de seguridad también deben estar ubicados en la misma zona de seguridad. Los recursos que no estén en una zona de seguridad podrían ser vulnerables y los recursos de una zona de seguridad diferente podrían tener una estrategia de seguridad menos estricta. Por ejemplo, una instancia informática en una zona de seguridad no puede utilizar un volumen de inicio que no esté en la misma zona de seguridad.
• Los recursos de una zona de seguridad no deben ser accesibles desde la red Internet pública.
• Los recursos de una zona de seguridad se deben cifrar con claves gestionadas por el cliente.
• Se debe realizar una copia de seguridad regular y automática de los recursos de una zona de seguridad.
• Los datos de una zona de seguridad se consideran con privilegios y no se pueden copiar fuera de la zona de seguridad porque podrían ser menos seguros.
• Los recursos de una zona de seguridad solo pueden utilizar configuraciones y plantillas aprobadas por Oracle. Consulte Políticas de zona de Seguridad para obtener detalles

Relación con los destinos de Cloud Guard

• Al crear una zona de seguridad para un subcompartimento cuyo compartimento principal ya esté en una zona de seguridad, Cloud Guard realiza las siguientes tareas:
  1. Crea un destino de zona de seguridad independiente para el subcompartimento.
  2. Agrega las recetas de detector gestionadas por Oracle por defecto al nuevo destino de zona de seguridad.
• No se realizan cambios en el destino existente de Cloud Guard para el compartimento principal.
• Un único compartimento no puede estar en varias zonas de seguridad y tampoco puede estar en varios destinos de Cloud Guard.

Decisión de diseño clave

• Evalúe las políticas de zona de seguridad.
• Defina el ámbito aplicable, como los módulos no orientados a Internet, y los procesos de aplicación, como los embebidos, al principio del ciclo de vida de desarrollo para evitar el bloqueo de implementación en etapas posteriores.

Supervisión de vulnerabilidades con la exploración normal

OCI Vulnerability Scanning Service ayuda a mejorar su estrategia de seguridad en OCI comprobando de forma rutinaria posibles vulnerabilidades de los hosts. El servicio genera informes con métricas y detalles sobre las conclusiones.

El servicio Scanning de vulnerabilidades puede identificar varios tipos de problemas de seguridad en instancias informáticas e imágenes del contenedor:

• Los puertos que se dejen abiertos involuntariamente pueden ser un posible vector de ataque a sus recursos en la nube, o bien permiten a los hackers aprovechar otras vulnerabilidades.
• Paquetes del sistema operativo que requieren actualizaciones y parches para abordar las vulnerabilidades.
• Configuraciones del sistema operativo que los hackers pueden aprovechar.
• Referencias estándar del sector que se publican por el Centro para la seguridad informática (CIS)..

La exploración de vulnerabilidades comprueba si los hosts cumplen las referencias de la sección 5 (Acceso, autenticación y autorización) definidas para Distribución independiente de Linux.

Al crear un repositorio en Oracle Cloud Infrastructure Registry (también conocido como Container Registry), la exploración de imágenes está activada por defecto en el repositorio. Cada vez que se transfiere una imagen al repositorio, se explora la imagen para buscar vulnerabilidades de seguridad en la base de datos de exposiciones y vulnerabilidades comunes (CVE). Container Registry vuelve a explorar automáticamente cualquier imagen del repositorio que haya cambiado desde la exploración anterior.

El equipo de seguridad también puede utilizar la receta del detector para la configuración por defecto de Cloud Guard para detectar y responder a las vulnerabilidades que identifica el servicio Vulnerability Scanning.

Orígenes de vulnerabilidad

Vulnerability Scanning detecta vulnerabilidades en las siguientes plataformas y utiliza los siguientes orígenes de vulnerabilidad.

Consideraciones

• Debido a que la exploración de Windows no incluye datos OVAL, no recomendamos que confíe únicamente en OCI Vulnerability Scanning para garantizar que las instancias de Windows estén actualizadas y seguras.
• No recomendamos utilizar el servicio Vulnerability Scanning para identificar problemas en sistemas de base de datos (DB) de máquina virtual (VM) y, a continuación, modificar el sistema operativo para abordar cada problema. En su lugar, siga las instrucciones de actualización de un sistema de base de datos para aplicar las últimas actualizaciones de seguridad al sistema operativo.
• No puede utilizar el servicio Vulnerability Scanning en hosts que no se hayan creado directamente con el servicio OCI Compute, como Oracle Exadata Database Service on Dedicated Infrastructure o el servicio Database. Utilice las funciones proporcionadas con esos servicios para garantizar que los hosts tengan las últimas actualizaciones de seguridad.

Archivado de logs e integración de SIEM

El registro es esencial para que los analistas de seguridad detecten posibles infracciones de seguridad o usos internos incorrectos de la información.

Con Oracle Cloud Infrastructure Logging, los analistas pueden acceder a los logs desde recursos de OCI, incluida información del diagnóstico crítico que describe el rendimiento y el Acceso a los recursos. Logging es un panel único altamente escalable y totalmente gestionado para todos los logs del arrendamiento.

Por defecto, los logs de Audit se mantienen durante 365 días. Con el hub de conector de servicio de OCI, puede archivar logs en almacenamiento inmutable durante más rato para cumplir los requisitos de conformidad de algunos sectores regulados. Mediante un patrón similar, los logs se pueden integrar con herramientas de gestión Splunk y QRadar de terceros, como el servicio OCI Streaming.

Decisión de diseño clave

• Período de archivado de logs obligatorio: ¿es suficiente con 365 días? ¿O necesita conservarla aún más mediante el uso de almacenamiento inmutable?
• Necesidad de integración de SIEM existente: ¿hay necesidad de integración con cualquier solución de SIEM existente?

Leer más

• Orientación de diseño para la integración de SIEM
• Implementar un sistema SIEM mediante un pipeline sin servidor que exporte logs de auditoría a Splunk
• Ingestión de logs de Oracle Cloud Infrastructure en Microsoft Azure Sentinel mediante OCI Functions

Implantación de referencia

• Zona de llegada principal del marco de adopción de la nube
• Proteja sus cargas de trabajo en la nube mediante zonas de seguridad