Les entreprises utilisent couramment des comptes partagés entre plusieurs personnes pour gérer leur présence sur les réseaux sociaux. Mais la difficulté pour les équipes IT et les équipes sécurité consiste à veiller à la bonne utilisation de ces comptes. Le détournement d’un compte sur les réseaux sociaux ou la compromission d’identifiants peut causer des dommages importants à l’image et à la réputation d’une marque.
Partager le mot de passe uniquement avec l’équipe en charge des réseaux sociaux et ne jamais le modifier n’est pas une stratégie efficace. Certaines équipes peuvent choisir d’utiliser un gestionnaire de mots de passe afin de permettre aux membres de l’équipe d’accéder à des identifiants partagés, ce qui peut suffire selon vos besoins.
Dans cet article, nous examinons comment Okta peut aider à contrôler l’accès aux comptes partagés pour les services de réseaux sociaux. Voici, par ordre croissant de maturité :
- Utilisation des applications Secure Web Authentication (SWA) dans Okta avec des comptes partagés
- Utilisation de comptes de service SaaS manuels dans Okta Privileged Access
- Utilisation de comptes de service SaaS automatisés dans Okta Privileged Access
- Utilisation d’un compte partagé Okta dans Okta Privileged Access pour un compte partagé fédéré
Nous les examinerons dans les sections suivantes.
Utilisation des applications Secure Web Authentication (SWA) dans Okta avec des comptes partagés
Okta gère traditionnellement un ensemble de comptes fédérés et non fédérés. Les comptes fédérés utilisent des protocoles de SSO fédéré, tels que Security Assertion Markup Language (SAML) et OpenID Connect (OIDC), et n’impliquent pas de mots de passe. Les comptes non fédérés correspondent aux anciens comptes utilisateur avec identifiant et mot de passe, stockés dans le référentiel de l’application SaaS et accessibles via des invites de connexion ou en transmettant des identifiants dans les en-têtes HTTP.
Lorsqu’il est question de comptes partagés et utilisés pour administrer des plateformes, on parle généralement de ces derniers. C’est ici que les applications Secure Web Authentication entrent en jeu. Le mécanisme SWA associera des identifiants à une application dans Okta, et lorsque l’utilisateur sélectionne la tuile, le plugin du navigateur injectera les identifiants.
L’exemple suivant présente une application LinkedIn définie dans Okta, avec SWA comme méthode de connexion.
Parmi toutes les options d’identifiants, l’exemple utilise « Les utilisateurs partagent un nom d’utilisateur et un mot de passe uniques définis par l’administrateur ». Il s’agit des identifiants partagés utilisés par l’équipe marketing pour accéder à LinkedIn. Lorsque l’application est configurée dans Okta, l’administrateur doit connaître et saisir le nom d’utilisateur et le mot de passe de l’application. Mais les utilisateurs n’ont pas besoin de le faire.
Lorsqu’une des personnes assignées clique sur la tuile LinkedIn dans son tableau de bord, le plugin du navigateur extrait le nom d’utilisateur et le mot de passe enregistrés, puis les renseigne dans l’écran de connexion de l’application.
Comme pour toute application dans Okta, les attributions peuvent se faire au niveau individuel et/ou au niveau du groupe.
Idéalement, vous attribueriez l’accès à une application en utilisant des identifiants partagés via un groupe. Vous pourriez ensuite appliquer des contrôles relatifs à l’appartenance au groupe. Vous pourriez utiliser les règles de groupe pour lier l’appartenance à un groupe à un attribut du profil utilisateur (par exemple, Département = Marketing).
Encore mieux : utiliser les contrôles Okta Identity Governance pour gérer l’appartenance aux groupes. Vous pouvez utiliser la fonction Demander l’accès pour obliger les utilisateurs à demander l’accès au groupe ou à l’application via un workflow d’approbation (par exemple, validation par le manager) et une restriction temporelle (par exemple, accès accordé uniquement pendant deux heures). Vous pouvez utiliser la fonction Certification des accès pour valider régulièrement que les personnes disposant d’un accès en ont toujours besoin.
Veuillez noter qu’il n’existe aucune rotation automatique du mot de passe pour le compte de réseau social ; la valeur enregistrée dans Okta doit rester synchronisée avec celle présente dans l’application. Lorsque le mot de passe de l’application est modifié, le mot de passe enregistré dans Okta doit être mis à jour. Mais un seul administrateur a besoin de le savoir, et le mot de passe mis à jour n’a pas besoin d’être partagé avec une équipe. Ce n’est pas une solution parfaite, mais elle offre une meilleure sécurité que le partage du mot de passe entre les membres d’une équipe par e-mail ou sur un morceau de papier.
Utilisation de comptes de service SaaS manuels dans Okta Privileged Access
Okta a récemment lancé en Early Access une nouvelle fonctionnalité permettant de gérer les comptes partagés pour les applications SaaS dans Okta Privileged Access. Cela signifie que les identifiants des applications SaaS, comme les comptes partagés utilisés pour gérer des plateformes de réseaux sociaux, peuvent être stockés dans le coffre-fort Okta Privileged Access, et qu’une politique peut être appliquée pour contrôler qui peut accéder aux identifiants et quelles étapes doivent être suivies pour révéler ces identifiants (par exemple, approbation d’accès en flux tendu (JIT), fourniture d’une authentification multifacteur).
Cette fonctionnalité propose deux modes :
- Manuel, où les identifiants statiques (nom d’utilisateur et mot de passe) sont stockés dans le coffre-fort et reflètent les identifiants dans l’application. Lorsque les identifiants de l’application sont mis à jour, le coffre-fort doit être mis à jour.
- Automatique, lorsque l’intégration Okta Integration Network (OIN) pour l’application prend en charge le provisioning, afin qu’Okta Privileged Access puisse gérer le mot de passe des comptes de ce réseau social.
Les plateformes de réseaux sociaux comme Facebook et LinkedIn reposent sur une approche manuelle : vous devez stocker des identifiants statiques et configurer une politique pour contrôler la manière dont ils peuvent être révélés.
Comme Okta n’effectuera pas la connexion pour l’application manuelle, celle-ci est définie comme une application factice dans Okta (c’est-à-dire une application de signet, masquée dans les tableaux de bord des utilisateurs). Les identifiants partagés sont ensuite stockés en tant que comptes de service dans Okta.
Avec le compte partagé stocké dans Okta et attribué dans Okta Privileged Access, les utilisateurs (selon la politique) peuvent afficher le nom d’utilisateur et le mot de passe.
Ils utilisent l’interface Okta Privileged Access pour trouver l’application SaaS.
Puis, il sélectionnent le compte.
Des contrôles peuvent être associés au compte, comme une approbation d’accès en flux tendu (JIT) ou une authentification multifacteur. Ils peuvent ensuite afficher les identifiants, qui peuvent être copiés et collés dans le formulaire de connexion de l’application de réseau social.
Comparée à l’approche SWA précédente, cette méthode révèle le mot de passe à l’utilisateur final et, comme le mot de passe n’est pas automatiquement renouvelé, il existe un risque que la personne concernée l’écrive et le partage. Vous auriez besoin d’un processus permettant de modifier régulièrement le mot de passe sur la plateforme de réseaux sociaux et de mettre à jour la copie dans le coffre-fort.
Cette approche permet également d’exercer un contrôle accru sur l’accès à l’identifiant. L’approche SWA se limitait au contrôle de l’appartenance à un groupe, tandis que cette approche permet également d’appliquer des contrôles supplémentaires tels que la MFA et l’approbation des accès.
Cette approche ne dispose pas encore du plugin navigateur permettant l’injection automatique des identifiants, contrairement à l’approche SWA.
Utilisation de comptes de service SaaS automatisés dans Okta Privileged Access
La deuxième option pour utiliser des comptes de service SaaS dans Okta Privileged Access consiste à gérer le mot de passe de ces comptes depuis Okta grâce à l’intégration Okta Integration Network pour l’application. Prérequis :
- Disposer d’une intégration compatible avec SCIM
- Cette intégration a été testée pour prendre en charge la fonction de rotation des mots de passe avec Okta Privileged Access.
Consulter la liste actuelle des applications SaaS qui prennent en charge cette gestion automatique des mots de passe. Au moment de la rédaction (janvier 2025), la seule application de réseau social figurant dans la liste est Workplace by Facebook (même si l’on pourrait considérer Google Workspace, ainsi que certaines autres, comme des solutions permettant de gérer l’accès aux réseaux sociaux).
Le mécanisme est identique à celui décrit ci-dessus, à la différence près que le mot de passe du compte partagé sera renouvelé (modifié dans Okta et transmis à l’application) après son utilisation et selon un cycle défini. De cette façon, seul Okta Privileged Access connaît le mot de passe. L’utilisateur affichera le mot de passe afin de le copier-coller dans l’invite de connexion de l’application, mais une fois le mot de passe utilisé, il est remplacé. Il n’y a donc aucun intérêt à le noter ou à le partager.
Comme Okta Privileged Access gère le mot de passe et le renouvelle après utilisation, une règle d’utilisation exclusive peut être imposée, de sorte qu’un seul utilisateur à la fois puisse accéder au mot de passe. En plus de limiter l’accès au compte partagé à un seul utilisateur, cela permet à toute piste d’audit d’associer un utilisateur Okta individuel aux actions du compte partagé.
Il s’agit évidemment d’une approche plus sécurisée que les deux précédentes, puisqu’aucun mot de passe statique ne peut être partagé.
Utilisation d’un compte partagé Okta dans Okta Privileged Access pour un compte partagé fédéré
La dernière approche possible consiste à utiliser un compte fédéré (sans mot de passe, l’authentification unique fédérée est utilisée pour se connecter de manière sécurisée au compte) pour gérer la plateforme de réseaux sociaux, ce compte étant partagé. Il n’y a pas de mot de passe à partager, mais l’accès au compte nécessite un fournisseur d’identité comme Okta pour initier l’authentification unique et transmettre les tokens appropriés. Mais comment gérer l’accès à ces comptes dans Okta ?
Vous pouvez avoir un utilisateur dédié dans Okta associé à l’application de réseaux sociaux, et cet utilisateur est le seul utilisateur Okta pouvant accéder à l’application. La seule façon pour les utilisateurs d’accéder à l’application de réseaux sociaux est de se connecter à Okta en tant que cet utilisateur spécifique et de cliquer sur la tuile. Mais dans ce cas, revient-on au problème d’avoir un mot de passe partagé pour accéder au compte utilisateur Okta spécial ? Pas nécessairement.
La nouvelle fonctionnalité de compte de service SaaS couvre également les comptes Okta. Vous pouvez configurer l’utilisateur Okta pour les réseaux sociaux et Okta Privileged Access comme indiqué ci-dessus, afin que les identifiants permettant de se connecter à Okta en tant qu’utilisateur des réseaux sociaux soient révélés de la même manière que précédemment. L’utilisateur se rendrait dans Okta Privileged Access, afficherait le compte utilisateur Okta spécial pour les réseaux sociaux et utiliserait les identifiants pour se connecter à Okta en tant que cet utilisateur, cliquerait sur la tuile des réseaux sociaux et serait connecté à l’application. Lorsqu'il a terminé, il restitue le compte Okta et le mot de passe est renouvelé.
Vous pourriez, en théorie, regrouper plusieurs comptes de réseaux sociaux fédérés sous un seul compte Okta et gérer l’accès de cette manière.
Pour en savoir plus sur ce mécanisme, consultez Gestion et utilisation des comptes partagés Okta avec Okta Privileged Access.
Dans cette approche, vous ne gérez pas le mot de passe du compte de réseau social (puisqu’il est fédéré et n’en possède pas), mais plutôt le mot de passe du compte Okta qui vous permet d’utiliser le SSO pour accéder à ce compte de réseau social fédéré.
Conclusion
Il existe différentes approches pour gérer les comptes de réseaux sociaux partagés dans Okta.
À une extrémité, nous avons le mécanisme Secure Web Authentication (SWA) existant, qui permet à l’administrateur d’enregistrer un nom d’utilisateur et un mot de passe partagés, puis de les injecter dans la connexion de l’application via le plugin du navigateur. Cela présente certaines limites en matière de sécurité.
Il y a également l’utilisation de la nouvelle fonctionnalité SaaS comptes de service dans Okta Privileged Access, qui permet de stocker les identifiants des réseaux sociaux dans le coffre-fort et d’en autoriser le retrait par des utilisateurs habilités, avec des contrôles adaptés, comme l’exigence d’une validation par un responsable au moment où ils doivent utiliser le compte. Lorsque l’intégration prend en charge la rotation des mots de passe, Okta Privileged Access gérera le mot de passe de ces comptes.
Une dernière approche s’applique lorsque la plateforme de réseaux sociaux prend en charge les comptes fédérés, mais que vous souhaitez partager ces comptes avec plusieurs utilisateurs. Dans ce cas, vous pouvez créer un utilisateur Okta spécifique pour ces comptes fédérés et utiliser la fonctionnalité des comptes de service Okta Privileged Access afin d’accorder l’accès à ces utilisateurs Okta spécifiques selon les besoins, avec les contrôles appropriés.
Ces options couvrent un éventail de considérations en matière de sécurité, et l’approche que vous retiendrez dépendra de la plateforme de réseaux sociaux, de sa gestion des comptes partagés et de l’appétence au risque de votre organisation. Même si vous utilisez un gestionnaire de mots de passe, les nouvelles fonctionnalités d’Okta Privileged Access peuvent présenter un intérêt pour renforcer la sécurité et réduire les risques.
