Las cuentas locales en aplicaciones en la nube y SaaS (cuentas de usuario creadas directamente dentro de las aplicaciones en lugar de a través de Okta) representan un riesgo significativo para las organizaciones. Estas cuentas aumentan la superficie de ataque, lo que brinda a los actores de amenazas más oportunidades de explotar las vulnerabilidades y obtener acceso no autorizado a datos confidenciales y sistemas críticos.
Los equipos de seguridad luchan por obtener visibilidad de las cuentas locales y su postura de seguridad debido a la propiedad fragmentada, la complejidad del entorno y la falta de herramientas. Después de detectar las cuentas locales, quieren priorizar las más críticas y procesables primero y reducir proactivamente el riesgo asegurando una remediación automatizada y optimizada.
La realidad de la administración de cuentas locales: es complicado
Idealmente, todos los usuarios de aplicaciones posteriores deben ser administrados por un almacén de usuarios central en el proveedor de identidad (IdP), como Okta Lifecycle Management. Sin embargo, muchas organizaciones todavía crean con frecuencia cuentas locales, ya sea porque no han implementado estas funciones de centralización o porque sus procesos de automatización y cumplimiento están incompletos, lo que resulta en una falta de sincronización integral entre el IdP y las aplicaciones posteriores.
Algunas de las brechas de administración más comunes con las cuentas locales incluyen:
- Autenticación insegura: las cuentas locales no están sujetas a las políticas centralizadas de autenticación multifactor (MFA), las actualizaciones periódicas de contraseñas y las políticas de sesión basadas en el riesgo (como el cierre de sesión universal) aplicadas por Okta.
- Acceso inseguro: los empleados que han sido desvinculados o aquellos que han cambiado de rol aún pueden conservar el acceso.
- Privilegios excesivos: debido a que las cuentas locales son menos visibles y están excluidas de las revisiones de acceso, tienden a tener privilegios excesivos, carecen de propietarios claros y permanecen activas incluso si no se utilizan.
- Falta de monitoreo: la actividad de la cuenta local a menudo no se monitorea en comparación con las cuentas administradas centralmente, por lo que las actividades no autorizadas no son detectadas por el SOC y los incidentes no se pueden prevenir ni solucionar de manera efectiva.
Como resultado, estas brechas pueden afectar significativamente su superficie de ataque de seguridad de identidad y convertirse en:
- Objetivos principales para los ataques: los actores de amenazas pueden explotar estas vulnerabilidades para obtener acceso no autorizado a datos críticos e infligir daños.
- Infracciones de cumplimiento: los puntos ocultos comunes en la auditoría incluyen permitir el acceso no autorizado, no implementar los controles de autenticación adecuados y la segregación insuficiente de las tareas, todo lo cual es crucial para marcos como SOX, SOC2, PCI-DSS, NIST y CIS.
¿Cómo pueden los equipos de seguridad manejar mejor las cuentas locales?
Entonces, ¿qué pueden hacer los equipos de seguridad modernos? La respuesta es aplicar un marco simple, centrado en la postura de identidad, que establece la siguiente secuencia de pasos:
- Prevención: Elimine la creación de cuentas locales implementando el aprovisionamiento de la administración del ciclo de vida.
- Visibilidad continua: Tenga un inventario completo y actualizado de sus identidades más valiosas.
- Detección proactiva: Identificar automáticamente las cuentas locales y los desvíos de SSO.
- Recopilar contexto para la priorización:
- ¿Está en uso la cuenta de usuario o sus privilegios?
- ¿Está protegido por las políticas de autenticación de aplicaciones posteriores?
- ¿Cuál es el radio de explosión?
- ¿Qué métodos de inicio de sesión están configurados (por ejemplo, clave API) además de nombre de usuario-contraseña, o ¿está configurado el SSO además del inicio de sesión local?
- Remediación
Seleccione un plan de remediación con una compensación entre la reducción inmediata del riesgo y la minimización de la fricción comercial.- Deshabilitar cuenta local:
- Inmediatamente
- Después de la campaña de revisión de acceso (por ejemplo, con Okta Identity Governance)
- Mantenga habilitada la cuenta local pero reduzca el riesgo.
- Eliminar permisos privilegiados (mantener al usuario habilitado)
- Restablecer la contraseña
- Habilitar MFA en la aplicación posterior
- Reemplace el usuario local con un usuario administrado por IdP.
- Deshabilitar cuenta local:
¿Cómo puede ayudar Okta?
Con Okta Identity Security Posture Management, Okta proporciona una solución general que puede ayudarlo a reducir el riesgo de seguridad relacionado con las cuentas locales de Cloud/SaaS. Estas son las 3 capacidades críticas principales para los equipos de seguridad:
- Los equipos de TI pueden configurar la gestión del ciclo de vida para garantizar una prevención optimizada de la creación de cuentas locales por diseño.
- Los equipos de seguridad pueden usar Identity Security Posture Management para confiar, pero verificar las configuraciones del equipo de TI. Pueden obtener visibilidad de las cuentas locales con contexto sobre su alineación de controles de seguridad y priorizar las que más importan.
- Los equipos de seguridad y de TI pueden configurar Okta Workflows para garantizar la corrección automática de los nuevos problemas detectados para que no se pierda ningún riesgo crítico.
Okta Identity Security Posture Management es parte del Okta Secure Identity Commitment: el plan a largo plazo de Okta para liderar la industria en la lucha contra los ataques de identidad. Estamos comprometidos a brindarles a los clientes los productos y servicios que necesitan para proteger la identidad en el panorama de amenazas en constante cambio actual.
Estamos aquí para ayudarlo, así que póngase en contacto con su gerente de producto hoy mismo para ver cómo Okta Identity Security Posture Management puede ayudarlo a mejorar su administración de la postura de seguridad de identidad y reducir el riesgo de sufrir una infracción.
