Es habitual que las Organizations utilicen cuentas compartidas entre varias personas para gestionar su presencia en las redes sociales. Pero el desafío para los equipos de TI y seguridad es cómo garantizar el uso adecuado de estas cuentas. El secuestro de una cuenta en redes sociales o la vulneración de credenciales pueden causar daños significativos a la imagen y la reputación de una marca.
Compartir la contraseña únicamente con el equipo de redes sociales y no cambiarla nunca no es una estrategia eficaz. Algunos equipos pueden optar por utilizar un gestor de contraseñas para permitir que los miembros del equipo accedan a las credenciales compartidas, y eso puede ser todo lo que necesite.
En este artículo analizamos las formas en que Okta puede ayudar a controlar el acceso a las cuentas compartidas de los servicios de redes sociales. Son, en orden creciente de madurez:
- Uso de aplicaciones de Secure Web Authentication (SWA) en Okta con cuentas compartidas
- Uso de cuentas de servicio SaaS manuales en Okta Privileged Access
- Uso de cuentas de servicio SaaS automatizadas en Okta Privileged Access
- Uso de la cuenta compartida de Okta en Okta Privileged Access para una cuenta compartida federada
Los analizaremos en las siguientes secciones.
Uso de aplicaciones de Secure Web Authentication (SWA) en Okta con cuentas compartidas
Okta tradicionalmente trabaja con una combinación de cuentas federadas y no federadas. Las cuentas federadas utilizan protocolos de inicio de sesión único (SSO) federados, como Security Assertion Markup Language (SAML) y OpenID Connect (OIDC), y no requieren contraseñas. Las cuentas no federadas son las cuentas heredadas de ID de usuario/contraseña almacenadas en el repositorio de la aplicación SaaS y a las que se accede mediante solicitudes de inicio de sesión o pasando las credenciales a través de encabezados HTTP.
Cuando hablamos de cuentas que se comparten y se utilizan para administrar plataformas, normalmente nos referimos a estas últimas. Aquí es donde entran en juego las aplicaciones de Secure Web Authentication. El mecanismo SWA asociará las credenciales con una aplicación en Okta, y cuando un usuario seleccione el mosaico, el complemento del navegador inyectará las credenciales.
A continuación se muestra una aplicación de LinkedIn definida en Okta con SWA como método de inicio de sesión.
De todas las opciones para las credenciales, el ejemplo utiliza "Los usuarios comparten un único nombre de usuario y contraseña establecidos por el administrador." Estas son las credenciales compartidas que utiliza el equipo de marketing para acceder a LinkedIn. Cuando la aplicación se configura en Okta, el administrador debe conocer e introducir el nombre de usuario y la contraseña de la aplicación. Pero los usuarios no tienen por qué hacerlo.
Cuando uno de los usuarios asignados haga clic en el icono de LinkedIn en su panel de control, el complemento del navegador recuperará el nombre de usuario y la contraseña almacenados y los insertará en la pantalla de inicio de sesión de la aplicación.
Al igual que con cualquier aplicación en Okta, las asignaciones pueden ser a nivel individual y/o grupo.
Lo ideal sería asignar el acceso a una aplicación mediante credenciales compartidas a través de un grupo. A continuación, podría aplicar controles en torno a la pertenencia a grupos. Podría usar reglas de grupo para vincular la pertenencia a un grupo con un atributo del perfil de usuario (por ejemplo, Departamento = Marketing).
Pero aún mejor sería utilizar los controles de Okta Identity Governance para gestionar la pertenencia a grupos. Puede usar la función Solicitar acceso para obligar a los usuarios a solicitar acceso al grupo o a la aplicación con un flujo de aprobación (por ejemplo, aprobación del gerente) y una restricción de tiempo (por ejemplo, acceso otorgado solo por dos horas). Puede utilizar la función de certificación de acceso para validar periódicamente que quienes tienen acceso aún lo necesitan.
Tenga en cuenta que no existe una rotación automática de la contraseña de la cuenta de redes sociales; el valor almacenado en Okta debe permanecer sincronizado con el de la aplicación. Cuando se cambia la contraseña de la aplicación, la contraseña almacenada en Okta debe actualizarse para que coincida. Pero basta con que un único administrador lo sepa, y no es necesario compartir la contraseña actualizada con todo el equipo. Esta no es una solución perfecta, pero proporciona mayor seguridad que compartir la contraseña entre los miembros de un equipo por correo electrónico o en un trozo de papel.
Uso de cuentas de servicio SaaS manuales en Okta Privileged Access
Okta ha introducido recientemente en acceso anticipado una nueva Artículo destacado para gestionar cuentas compartidas para aplicaciones SaaS en Okta Privileged Access. Esto significa que las credenciales para aplicaciones SaaS, como las cuentas compartidas utilizadas para administrar plataformas de redes sociales, se pueden almacenar en la bóveda de Okta Privileged Access, y se puede aplicar una política para controlar quién puede acceder a las credenciales y qué proceso deben seguir para revelarlas (por ejemplo, aprobación de acceso justo a tiempo, proporcionar autenticación multifactor).
Este Artículo destacado tiene dos modos:
- Manual, donde las credenciales estáticas (nombre de usuario y contraseña) se almacenan en la bóveda y reflejan las credenciales de la aplicación. Cuando se actualizan las credenciales de la aplicación, es necesario actualizar la bóveda para que coincida.
- Automático, cuando la integración de Okta Integration Network (OIN) para la aplicación admite el aprovisionamiento, de modo que Okta Privileged Access puede ser el gerente de la contraseña de esa cuenta de redes sociales.
Las plataformas de redes sociales como Facebook y LinkedIn se basan en un enfoque manual: es necesario almacenar credenciales estáticas y configurar una política para controlar cómo se pueden revelar.
Dado que Okta no realizará el inicio de sesión para la aplicación manual, esta se define como una aplicación ficticia en Okta (es decir, una aplicación de marcadores, y está oculta en los paneles de usuario). A continuación, las credenciales compartidas se almacenan como cuentas de servicio en Okta.
Con la cuenta compartida almacenada en Okta y asignada en Okta Privileged Access, los usuarios (según la política) pueden revelar el nombre de usuario y la contraseña.
Utilizan la IU de Okta Privileged Access para encontrar la aplicación SaaS.
Luego, seleccione la cuenta.
Es posible que existan controles asociados a la cuenta, como la aprobación de acceso justo a tiempo o la autenticación multifactor. Luego, pueden revelar las credenciales, que se pueden copiar y pegar en el formulario de inicio de sesión de la aplicación de redes sociales.
En comparación con el método SWA anterior, este método sí revela la contraseña al usuario final, y como la contraseña no se rota automáticamente, existe el riesgo de que la anoten y la compartan. Necesitaría un proceso para cambiar periódicamente la contraseña en la plataforma de redes sociales y actualizar la copia en la bóveda.
Este enfoque también implica que se puede ejercer un mayor control sobre el acceso a la credencial. El enfoque SWA se limitaba a los controles de pertenencia a grupo, mientras que este enfoque también puede aplicar controles adicionales como MFA y la aprobación de acceso.
Este método aún no cuenta con el complemento para navegador que permite la inyección automática de credenciales, a diferencia del método SWA.
Uso de cuentas de servicio SaaS automatizadas en Okta Privileged Access
La segunda opción para usar cuentas de servicio SaaS en Okta Privileged Access es donde la contraseña de esas cuentas se puede administrar desde Okta a través de la integración de Okta Integration Network para la aplicación. Se basa en:
- Que cuente con una integración que soporte SCIM
- Dicha integración ha sido probada para dar soporte a la función de rotación de contraseñas mediante Okta Privileged Access.
La lista actual de aplicaciones SaaS que dan soporte a esta gestión automática de contraseñas se encuentra aquí. En el momento de redactar este texto (enero de 2025), la única aplicación de redes sociales en la lista es Workplace de Facebook (aunque también se podría considerar Google Workspace, y algunas otras, para gestionar el acceso a las redes sociales).
El mecanismo es el mismo que el descrito anteriormente, con la salvedad de que la contraseña de la cuenta compartida se rotará (se cambiará en Okta y se aprovisionará en la aplicación) después de su uso y de forma cíclica. De esta forma, solo Okta Privileged Access conoce la contraseña. El usuario revelará la contraseña para copiarla y pegarla en la pantalla de inicio de sesión de la aplicación, pero una vez que la haya usado, se reemplazará, por lo que no tiene sentido anotarla y compartirla.
Dado que Okta Privileged Access gestiona la contraseña y la rota después de su uso, también puede emplear un sistema de acceso exclusivo, de modo que solo un usuario pueda acceder a la contraseña a la vez. Además de restringir el acceso a la cuenta compartida a un solo usuario, esto significa que cualquier registro de auditoría puede vincular a un usuario individual de Okta con las acciones de la cuenta compartida.
Obviamente, este método es más seguro que los dos anteriores, ya que no hay una contraseña estática que se pueda compartir.
Uso de la cuenta compartida de Okta en Okta Privileged Access para una cuenta compartida federada
El último enfoque que se puede utilizar consiste en que la cuenta utilizada para administrar la plataforma de redes sociales sea una cuenta federada (sin contraseña, se utiliza el inicio de sesión único federado para conectarse de forma segura a la cuenta) que se comparte. No es necesario compartir ninguna contraseña, pero el acceso a la cuenta requiere un proveedor de identidades como Okta para iniciar el inicio de sesión único y proporcionar los token correspondientes. Pero, ¿cómo se gestiona el acceso a estas cuentas en Okta?
Podría tener un usuario dedicado en Okta vinculado a la aplicación de redes sociales, y ese usuario es el único usuario de Okta que puede acceder a la aplicación. La única forma en que los usuarios pueden acceder a la aplicación de redes sociales es al realizar el inicio de sesión en Okta como ese usuario especial y haciendo clic en el icono. ¿Pero entonces volvemos al problema de tener una contraseña compartida para acceder a la cuenta de usuario especial de Okta? No necesariamente.
La nueva Artículo destacado de cuenta de servicio SaaS también incluye las cuentas de Okta. Podría configurar el usuario de redes sociales de Okta y Okta Privileged Access como se indicó anteriormente, de modo que las credenciales para iniciar sesión en Okta como ese usuario de redes sociales se muestren de la misma manera que vimos anteriormente. El usuario accedería a Okta Privileged Access, revelaría la cuenta de usuario especial de redes sociales de Okta y usaría las credenciales para iniciar sesión en Okta como ese usuario, haría clic en el icono de redes sociales y accedería a la aplicación. Cuando terminan, devuelven la cuenta de Okta y se rota la contraseña.
En teoría, podría agrupar varias cuentas de redes sociales federadas bajo una única cuenta de Okta y gestionar el acceso de esta manera.
Consulte “Administración y uso de cuentas compartidas de Okta con Okta Privileged Access” para obtener más detalles sobre este mecanismo.
Con este método, no se gestiona la contraseña de la cuenta de redes sociales (ya que está federada y no tiene una), sino la contraseña de la cuenta de Okta que permite el inicio de sesión único (SSO) en esa cuenta de redes sociales federada.
Conclusión
En Okta existe un abanico de enfoques para gestionar cuentas compartidas en redes sociales.
Por un lado, tenemos el mecanismo de Secure Web Authentication (SWA) existente, que permite que el administrador almacene un nombre de usuario y una contraseña compartidos, los cuales serán insertados en el inicio de sesión de la aplicación mediante el complemento del navegador. Esto presenta algunas limitaciones de seguridad.
Además, está el uso del nuevo Artículo destacado de cuentas de servicio SaaS en Okta Privileged Access, que almacenará las credenciales de redes sociales en la bóveda y permitirá que los usuarios autorizados las utilicen con los controles adecuados, como requerir la aprobación de un gerente en el momento en que necesiten usar la cuenta. Cuando la integración admita la rotación de contraseñas, Okta Privileged Access gestionará la contraseña de estas cuentas.
Una última opción es cuando la plataforma de redes sociales da soporte a cuentas federadas, pero se desea compartir estas cuentas con varios usuarios. En este caso, podría crear un usuario especial de Okta para estas cuentas federadas y utilizar el Artículo destacado Cuentas de servicio de Okta de Okta Privileged Access para otorgar acceso a estos usuarios especiales de Okta según sea necesario, con los controles adecuados.
Estas opciones representan una serie de consideraciones de seguridad, y el enfoque que elija dependerá de la plataforma de redes sociales, su política de cuentas compartidas y el nivel de riesgo que su organización esté dispuesta a asumir. Incluso si utiliza un gestor de contraseñas, las nuevas funciones de Okta Privileged Access pueden resultarle útiles para mejorar la seguridad y reducir el riesgo.
