Puede reducir la superficie de ataque en la nube auditando cada permiso persistente en sus plataformas en la nube y de identidad, eliminando el acceso innecesario
Las cuentas privilegiadas son una invitación permanente para los atacantes, con credenciales para robar y permisos de los que hacer un uso indebido. Cuando los derechos administrativos están persistentemente activos, ya sea que se estén usando o no, las cuentas privilegiadas amplían significativamente la superficie de ataque. El privilegio permanente cero (ZSP) reduce ese riesgo al garantizar que ningún usuario tenga acceso elevado permanente. En su lugar, los privilegios se solicitan para una tarea específica, se otorgan por un tiempo limitado, se aprueban mediante un flujo de trabajo definido y se revocan automáticamente cuando expira el periodo aprobado. ZSP refleja un cambio más amplio en la seguridad moderna, reemplazando el acceso permanente por el acceso temporal para reducir lo que un atacante puede explotar. Keeper ayuda a aplicar ZSP al otorgar acceso justo a tiempo (JIT) y revocarlo automáticamente cuando expira el periodo aprobado, pasando a los usuarios de cero privilegios exactamente al acceso que necesitan y luego de regreso a cero automáticamente.
Siga leyendo para conocer la importancia del ZSP, cómo funciona en Keeper y dónde Keeper lo aplica en todos los entornos.
Por qué los privilegios permanentes son un riesgo de seguridad
Una cuenta privilegiada que permanece activa indefinidamente les da a los atacantes un objetivo duradero: las credenciales no expiran, el acceso está disponible constantemente y no hay un momento determinado en el que se retiren esos derechos. Si los atacantes roban o comprometen una de estas cuentas, heredan los privilegios permanentes en su totalidad.
El mayor problema es el radio de impacto, ya que una cuenta comprometida con acceso permanente rara vez se limita al sistema para el que fue destinada. Los atacantes utilizan los privilegios permanentes para moverse lateralmente a través de los entornos, alcanzando servidores, bases de datos y recursos en la nube adicionales a su paso. Lo que puede comenzar como una sola credencial comprometida puede convertirse rápidamente en un punto de apoyo en toda su infraestructura si el usuario cuenta con acceso permanente. Cuando los privilegios son permanentes, el acceso no está vinculado a una solicitud, tarea o periodo específico, lo que no deja un registro claro de por qué alguien pudo acceder a un sistema en un momento determinado. Esa ambigüedad hace que investigar los incidentes de seguridad relacionados con privilegios permanentes y demostrar el cumplimiento sea mucho más difícil.
Cómo funciona el privilegio permanente cero en Keeper
Keeper ayuda a aplicar ZSP a través de Keeper Privileged Cloud, lo que extiende el marco de acceso justo a tiempo de KeeperPAM a sus proveedores de identidad y aplicaciones federadas. En lugar de aprovisionar derechos de administrador permanentes, Keeper Privileged Cloud otorga acceso elevado solo cuando se solicita, solo durante un periodo aprobado y solo bajo los controles de flujo de trabajo que usted defina. Los usuarios no tienen privilegios por defecto y los elevan a través de un proceso controlado y auditable, para luego volver a cero cuando se finaliza la tarea. A continuación, se muestra cómo funciona ZSP en la práctica para Keeper.
Configurar las políticas de acceso
En un registro de PAM Cloud, los administradores definen las reglas de interacción mediante la configuración del acceso justo a tiempo y del flujo de trabajo. Esto incluye si una solicitud necesita aprobación, quién puede aprobarla, cuánto dura el acceso una vez otorgado y a qué rol se eleva al usuario. Esta configuración ayuda a determinar exactamente cómo se solicita, aprueba y limita en el tiempo el acceso privilegiado, lo que garantiza que no se produzca ninguna elevación más allá de los límites que usted establezca.

Compartir registros con usuarios autorizados
Una vez establecida una política, el registro de PAM Cloud se comparte con los usuarios que deberían poder solicitar acceso. Debido a que la elevación se realiza a través de su proveedor de identidad, cada usuario necesita una cuenta tanto en su proveedor de identidad como en el inquilino de Keeper. Con el registro compartido, esos usuarios pueden solicitar acceso elevado cuando una tarea lo requiera, sin mantener ningún privilegio permanente mientras tanto.
Revisar y aprobar solicitudes
Cuando un usuario necesita acceso, puede solicitarlo directamente desde su bóveda de Keeper o la Keeper Commander CLI. Los aprobadores designados reciben notificaciones en tiempo real a través de herramientas como Slack, Teams, Jira y ServiceNow, y pueden aprobar o denegar una solicitud desde cualquier cliente de Keeper, de modo que las solicitudes no se quedan esperando a que alguien esté frente a su escritorio. Según la política, los aprobadores también pueden requerir una justificación y un número de ticket antes de conceder el acceso, vinculando cada elevación a un motivo documentado.

Otorgar y revocar el acceso automáticamente
Una vez aprobada una solicitud, el Keeper Gateway realiza la elevación en el proveedor de identidad o recurso de destino, otorgando al usuario la membresía de grupo, rol o derecho configurados para que obtenga el acceso que permite la política. Cuando expira la duración aprobada, el Keeper Gateway revoca automáticamente ese acceso, eliminando la membresía o asignación temporal y devolviendo al usuario al ZSP. También registra cada elevación que solicitó acceso, quién la aprobó y cuándo comenzó y finalizó, para que los equipos de seguridad y cumplimiento tengan un registro claro y por solicitud de cómo se concedió y utilizó el acceso privilegiado.
Dónde Keeper aplica privilegios permanentes cero
Keeper no limita el ZSP a un solo sistema o tipo de cuenta. El mismo marco del acceso justo a tiempo se aplica dondequiera que exista acceso privilegiado en su entorno, desde los proveedores de identidad con los que se autentican sus usuarios hasta los recursos en la nube, las bases de datos y las máquinas detrás de ellos.
En todos los proveedores de identidad
Keeper Privileged Cloud amplía el acceso justo a tiempo a través de los proveedores de identidad existentes, incluidos AWS IAM, Microsoft Entra ID, Google Cloud a través de Google Identity, Okta y Active Directory. Keeper otorga y revoca privilegios directamente dentro de su infraestructura existente, por lo que la elevación se realiza donde ya se encuentran sus cuentas, sin interrumpir la forma en que los usuarios se autentican. El proveedor de identidad sigue siendo su fuente de referencia, mientras que Keeper simplemente controla cuándo se eleva a un usuario a un grupo con privilegios y cuándo se le elimina de él.
Ese alcance no es solo para las plataformas en sí, sino que también incluye aplicaciones que federan el acceso y la autorización a través de estos proveedores de identidad. Las aplicaciones federadas también pueden usar Keeper para el control de acceso, lo que permite a los usuarios aplicar el mismo modelo de acceso justo a tiempo a las aplicaciones posteriores en las que los equipos inician sesión todos los días.
En la nube, bases de datos y máquinas
Dado que ZSP no es solo un problema de la consola en la nube, KeeperPAM aplica el mismo marco de elevación de privilegios más allá de sus proveedores de identidad. Con los registros PAM Cloud, PAM Database y PAM Machine, puede ampliar el acceso por tiempo limitado a recursos en la nube, bases de datos y máquinas individuales, aplicando el mismo ciclo de vida a la infraestructura detrás de la capa de identidad.
Además de la elevación, Keeper Gateway también rota las credenciales privilegiadas de modo que no permanezcan como objetivos estáticos, y en el caso de bases de datos y máquinas, puede aprovisionar cuentas efímeras, inyectando las credenciales del lado del servidor para que el usuario nunca las maneje directamente. Todo esto se encuentra dentro de la arquitectura de conocimiento cero de Keeper, lo que significa que las credenciales y los secretos permanecen cifrados de extremo a extremo y nunca se exponen a Keeper ni a nadie más. En conjunto, la rotación automatizada y el conocimiento cero garantizan que incluso las credenciales que permiten el acceso privilegiado no persistan como materiales que un atacante pueda robar y explotar.
Minimice su superficie de ataque con Keeper
El privilegio permanente cero solo funciona si se aplica de manera consistente, y ahí es precisamente donde Keeper Privileged Cloud destaca. Con Keeper, los equipos de seguridad tienen una forma auditable de otorgar acceso privilegiado bajo demanda y revocarlo automáticamente, a través de los proveedores de identidad y la infraestructura que ya utilizan. Los administradores obtienen un control demostrable sobre quién puede acceder a qué y cuándo; los usuarios obtienen el acceso que necesitan sin esperar el aprovisionamiento manual ni conservar derechos que no necesitan.
Solicite una demostración de KeeperPAM para ver el acceso justo a tiempo y la revocación automática en su entorno.
Preguntas frecuentes
¿En qué se diferencia el privilegio permanente cero del privilegio mínimo?
El privilegio mínimo limita a los usuarios únicamente a los permisos que requiere su rol, pero esos permisos suelen ser permanentes, por lo que permanecen activos independientemente de que se utilicen o no. El privilegio permanente cero lleva la idea del privilegio mínimo un paso más allá: no hay ningún nivel de acceso predeterminado; los privilegios se otorgan únicamente cuando se solicitan y aprueban, y se revocan cuando finaliza la tarea. En pocas palabras, el privilegio mínimo limita la cantidad de acceso que puede tener un usuario, pero ZSP reduce el tiempo durante el cual lo conserva, idealmente a ninguno hasta que sea necesario. Lea nuestro blog para obtener más información sobre el privilegio permanente cero frente al privilegio mínimo.
¿Qué proveedores de identidad admite Keeper?
Keeper Privileged Cloud aplica el acceso justo a tiempo en AWS IAM, Microsoft Entra ID, Google Cloud a través de Google Identity, Okta y Active Directory. Las aplicaciones que federan el acceso y la autorización a través de estas plataformas también pueden usar Keeper para el control de acceso, por lo que el mismo modelo de acceso justo a tiempo se extiende a las otras aplicaciones conectadas a sus proveedores de identidad.
¿Cómo acceden los usuarios a los recursos después de la aprobación?
Una vez aprobada una solicitud de acceso, los usuarios pueden acceder al recurso a través del aislamiento remoto del navegador de Keeper para una sesión segura basada en navegador o continuar utilizando sus flujos de trabajo actuales, como el portal de acceso de AWS o la CLI de AWS. En cualquier caso, el acceso dura solo el tiempo justificado y se revoca automáticamente después del periodo aprobado.