Oracle Cloud Guard añade 18 detectores de acceso, TLS y recuperación
Oracle anunció 18 nuevas reglas de Cloud Guard para revisar bases de datos expuestas, TLS, redes, credenciales, backups e imágenes y versiones de OKE. Deben incorporarse a una receta y asignarse al ámbito de recursos; un hallazgo requiere validar la configuración, no presume un incidente.
Oracle anunció el 24 de octubre 18 nuevos detectores de configuración para Cloud Guard, el servicio de postura de seguridad de Oracle Cloud Infrastructure (OCI). La tanda busca identificar exposición de bases de datos y almacenamiento, cifrado débil, reglas de red demasiado abiertas, permisos para crear credenciales, copias no habilitadas y desviaciones de imagen o versión en cargas de trabajo. El anuncio describe comprobaciones de configuración, no una vulnerabilidad explotada ni una remediación automática de los recursos.
No es un único control más estricto: Oracle agrupa 18 reglas en seis áreas. Tres revisan accesibilidad de bases de datos; tres miran protección contra borrado y backups; cuatro cubren Transport Layer Security (TLS) y suites de cifrado en balanceadores; dos inspeccionan listas de seguridad de red; cuatro señalan capacidades de credenciales y enlaces de Object Storage; y dos comprueban imágenes aprobadas y versiones de Kubernetes. La utilidad está en mirar el recorrido completo de los datos, pero la existencia de un detector no significa que el hallazgo se dé en todas las cuentas.
Del endpoint de base de datos al plano de red
En bases de datos, Cloud Guard separa la falta de endpoint privado en Autonomous Database de la exposición pública de Autonomous Database y MySQL DB System. Esas condiciones no son equivalentes: Oracle advierte que un servicio sin endpoint privado no queda automáticamente demostrado como público. La regla de exposición pública requiere revisar también el camino real de red, las subredes y las reglas efectivas; antes de retirar una ruta existente conviene probar DNS y acceso de clientes.
Los cuatro detectores de balanceador comparan las políticas del listener y la conexión con el backend: buscan protocolos anteriores a TLS 1.2 o ausencia de SSL en el tramo backend, además de suites de cifrado predefinidas que Oracle considera prohibidas. Las suites personalizadas no entran en esa evaluación, así que una política propia necesita revisión aparte. Otros dos detectores marcan puertos no públicos accesibles desde cualquier origen y listas de salida abiertas a cualquier destino; endurecerlas puede cortar dependencias legítimas, por lo que toca identificar flujos y probar antes de cerrar.
-InfraCrew dice: El TLS del listener puede estar impecable mientras el salto al backend conserva el protocolo viejo; el balanceador también tiene dos lados.-
Protección de datos, credenciales y cargas de trabajo
Tres reglas apuntan a recuperación: protección contra borrado desactivada en MySQL y backups automáticos no habilitados en MySQL o PostgreSQL. La protección de borrado reduce el riesgo de eliminar un DB System, pero no evita un DROP TABLE ni sustituye una copia. Un detector que vea el backup activado tampoco certifica retención adecuada, inmutabilidad o restauración viable: Oracle recomienda verificar que las tareas terminan y probar la recuperación.
-InfraCrew dice: «Backup enabled» es una casilla de configuración; el restore sigue siendo la prueba que separa un plan de una esperanza.-
Las cuatro alertas de gestión de identidades y accesos (IAM) observan quién puede crear tokens de autenticación, claves secretas de cliente y credenciales de base de datos, además de las solicitudes preautenticadas (PAR) de Object Storage. Las primeras tres detectan capacidades habilitadas, no demuestran que se haya emitido o robado una credencial. Una PAR puede ser legítima, pero cualquiera que conserve su URL obtiene el acceso concedido; hay que revisar propietario, alcance y caducidad, y comprobar integraciones antes de deshabilitar permisos de creación.
Los dos controles restantes buscan imágenes de Compute no autorizadas y clústeres de Oracle Kubernetes Engine (OKE) fuera de las versiones admitidas. Para imágenes, Oracle pide definir qué es aprobado por compartimento; una excepción legítima debe pasar por control de cambios, no por una aprobación informal que se vuelva permanente. En OKE, una actualización requiere revisar compatibilidad de API, complementos y grupos de nodos; actualizar el plano de control no actualiza por sí solo las cargas de trabajo.
-InfraCrew dice: Deshabilitar la creación de secretos no revoca los que ya existen; las credenciales antiguas también tienen su propia lista de salida.-
Activarlos requiere receta y alcance
Cloud Guard no instala un agente en cada VM: los detectores son reglas gestionadas por el servicio y se agrupan en una receta de detectores. La documentación de OCI permite clonar recetas predeterminadas, habilitar o deshabilitar reglas por separado y limitar su alcance mediante condiciones. Oracle recomienda probar estos controles en una receta de configuración, clonar la receta gestionada por Oracle y activar las reglas necesarias en una versión administrada por el cliente.
Después hay que asociar la receta a un target, el ámbito de Cloud Guard que cubre los compartimentos y recursos que se van a revisar. El anuncio recomienda empezar en staging o pruebas, comprobar que el target incluye los recursos previstos y asignar los hallazgos a sus responsables. También advierte que un compartimento solo admite una receta en ese flujo: si se reemplaza la ya asociada al target, revisa antes qué controles del baseline dejarían de ejecutarse.
El plazo tampoco es instantáneo. Oracle indica que los problemas pueden aparecer hasta 24 horas después de aplicar la receta, y ese tiempo describe la detección, no una corrección automática. Para el equipo de plataforma, el trabajo útil es validar cada señal contra conectividad, permisos e historial de backup, y tramitar los cambios con pruebas de servicio antes de endurecer políticas en producción.
El matiz final evita convertir el catálogo en un contador de incidentes: son indicadores de configuración por investigar. Una base sin endpoint privado no prueba exposición, una regla de credenciales no acredita robo y tener backups activados no demuestra recuperación. Cloud Guard amplía dónde mirar; el diagnóstico y el cambio siguen dependiendo del contexto de la cuenta.
Diccionario de la Crew
Oracle Cloud Infrastructure (OCI) — Plataforma cloud de Oracle; los recursos se organizan en regiones y compartimentos.
Cloud Guard — Servicio de OCI que identifica posibles problemas de configuración y actividad mediante reglas de detección.
Transport Layer Security (TLS) — Protocolo criptográfico que protege la comunicación entre clientes, balanceadores y servicios.
IAM — Gestión de usuarios, grupos, políticas y credenciales en OCI.
PAR — Solicitud preautenticada; enlace de Object Storage que concede a quien lo tiene el acceso definido a un objeto o bucket.
Oracle Kubernetes Engine (OKE) — Servicio administrado de Kubernetes de OCI.
Receta de detectores — Conjunto de reglas que define qué configuraciones de recursos evalúa Cloud Guard.
Target — Configuración de Cloud Guard que determina los compartimentos y recursos cubiertos por una receta.
