En tant que professionnel de la sécurité, il est intéressant de prendre un peu de recul. Si l’on vous demande quelles sont vos principales sources de stress, vous répondrez sans doute : les données clients, les environnements de production et l’accès au code source. Et les systèmes RH et financiers, dans tout cela ?
Nous sommes tous d’accord sur leur importance, bien sûr. Toutefois, en particulier pour tous ceux d’entre nous qui ont une formation technique, ils passent souvent un peu au second plan. C’est peut-être parce que les systèmes dans notre sphère d’intérêt sont ceux dont nous apprécions davantage la complexité, ou peut-être parce que nous nous attendons à ce que ces systèmes RH et financiers se comportent comme une application parmi d’autres sur le portail SSO, fonctionnant correctement avec notre fournisseur d’identité (IdP).
Or, Workday n’est justement pas une application comme les autres. En réalité, son modèle de sécurité s’étend bien au-delà des limites auxquelles sont contraintes la plupart des applications SaaS. Il possède son propre modèle de sécurité puissant, complexe et souvent invisible qui s’exécute en arrière-plan (pour une bonne raison). De même, il peut présenter des problèmes de configuration que votre fournisseur d’identité ne détectera jamais.
C’est une cible prisée par les acteurs malveillants, donc couramment attaquée, comme nous le constatons sur le terrain. Workday contient des données personnelles sensibles : informations d’identification, paie, comptes bancaires et l’organigramme entier de l’entreprise. Les rapports publiés par l’État du New Jersey, l’Université Brown et l’Université de Washington révèlent une tendance inquiétante : les cybercriminels exploitent activement la faiblesse des contrôles d’identité pour modifier les coordonnées de paiement dans les dossiers du personnel et faire ainsi main basse sur les salaires.
Examinons certains des défis propres à la sécurisation de Workday et déterminons ensemble comment nous pouvons les résoudre définitivement.
Les failles de sécurité du cycle de vie
Pour la plupart des applications SaaS, l’accès est généralement lié au cycle de vie de l’utilisateur au sein de l’entreprise (arrivée-changement de poste-départ). Workday contredit la plupart de ces hypothèses.
Le cycle de vie utilisateur de Workday s’étend au-delà de la chronologie typique allant de l’embauche au licenciement. Les anciens employés doivent accéder à l’application pour récupérer des documents destinés à l’administration fiscale et leurs dernières fiches de paie. Les nouvelles recrues bénéficient souvent elles aussi d’un accès pour accomplir les tâches d’onboarding. Ces contraintes créent des chemins d’accès permanent qui contournent votre gestion habituelle du cycle de vie. Pour une raison similaire, l’accès à ces comptes se produit en dehors du dispositif SSO normal de l’entreprise, en utilisant plutôt une combinaison nom d’utilisateur-mot de passe (avec ou sans MFA).
Lorsque le processus est géré correctement, il est acceptable ; Workday propose d’ailleurs des outils spécifiques à cet effet, tels que le groupe de sécurité Terminee as Self. Néanmoins, ce principe de fonctionnement sort du cadre censé s’appliquer à la plupart des applications SaaS, ce qui peut entraîner de graves lacunes si le système Workday n’est pas configuré de manière rigoureuse.
Par exemple, dans le cas de la plupart des applications SaaS, si l’application est configurée pour vous rediriger vers le fournisseur d’identité (IdP) lors des tentatives d’authentification, il n’est plus possible de s’authentifier directement. Dans Workday, cependant, pour les raisons décrites ci-dessus, il est toujours possible d’accéder à la page d’authentification locale, en contournant le SSO (par exemple, wd5.myworkday.com/company/login.htmld?redirect=n). Or, si les informations d’identification sont mal gérées ou si ce chemin de connexion natif n’applique pas le MFA dans Workday, cela peut créer une porte dérobée qui compromet la sécurité principale de votre IdP. Un attaquant armé d’un mot de passe compromis dispose d’un accès.
Un labyrinthe d’autorisations
Le modèle d’autorisation de Workday est incroyablement granulaire et performant, articulé autour de rôles et de processus métier. Cette caractéristique est nécessaire à son fonctionnement, mais il est conçu pour (et géré par) les équipes des RH et des finances — souvent un angle mort échappant à la visibilité des équipes IT et sécurité.
Le manque de visibilité sur cette structure d’autorisations critique, sur les rôles à privilèges existants et sur les utilisateurs qui les détiennent signifie qu’il est impossible de déterminer avec précision comment les sécuriser.
Ce problème est exacerbé par l’existence d’ISU (Integration System Users, la terminologie de Workday pour les comptes de service). Ces comptes créent d’importants défis :
- Qui peut les créer – Délégation souvent imprécise des droits de création des ISU
- Quels privilèges ils détiennent – Autorisations excessives qui s’accumulent avec le temps
- Qui détient ses identifiants – Accès partagé ou non géré aux clés de compte de service
Cela peut conduire à un problème généralisé où l’on constate la présence d’administrateurs non approuvés. Ainsi, un utilisateur qui avait eu besoin d’un accès spécial pour un projet ponctuel il y a trois ans pourrait encore le détenir. Ces risques peuvent persister pendant des années, sans possibilité de les identifier ou d’y remédier, jusqu’à ce qu’ils soient exposés par une brèche.
Des politiques d’authentification aussi complexes que votre IdP
De nombreuses applications SaaS sont configurées avec une politique d’authentification simple : « S’en remettre au fournisseur d’identité ». Workday, cependant, contient son propre moteur de politiques d’authentification riche et complexe, capable d’appliquer ses propres règles en matière d’accès.
Workday permet de prendre des décisions d’accès très contextuelles de manière native. Vous pouvez créer des règles basées sur l’emplacement réseau, la posture du terminal et les rôles des utilisateurs, puis autoriser ou refuser les types et méthodes d’authentification en fonction de ces critères.
C’est utile dans des scénarios tels que :
- Cycles de vie utilisateurs étendus – Anciens employés accédant à des documents officiels, nouveaux recrutements effectuant l’onboarding
- Accès sensible au contexte – Utilisateurs du Wi-Fi public limités aux tâches en libre-service uniquement
- Environnements multi-IdP – Organisations utilisant des modèles d’identité hub-and-spoke
Bien sûr, pouvoir configurer de telles politiques n’est pas une mauvaise chose. Mais l’existence de ces politiques en dehors du champ de visibilité de l’équipe sécurité, sans oublier la supervision moins rigoureuse qui pourrait leur être appliquée comparée à celles du fournisseur d’identité, peut créer des risques de sécurité en cas d’erreurs de configuration. Par exemple, une politique destinée aux utilisateurs extérieurs à l’entreprise, permettant un accès sans recours au SSO, pourrait accidentellement être appliquée à d’autres utilisateurs.
Du réactif au proactif : sécuriser Workday avec Okta ISPM
Cela nous amène à l’enjeu fondamental derrière tous ces problèmes : vous ne pouvez pas sécuriser ce que vous ne voyez pas.
Endosser la responsabilité de la sécurisation de l’ensemble de l’entreprise nécessite une visibilité claire sur Workday. Cela signifie être capable de comprendre le modèle de sécurité qui le sous-tend, d’exécuter des rapports, d’auditer les autorisations et même d’analyser les politiques d’authentification.
Cette problématique de la visibilité est exactement ce que résout Okta Identity Security Posture Management (ISPM). Plutôt que de laisser les équipes sécurité aveugles à la structure d’autorisations interne de Workday, ISPM surveille en permanence votre tenant, transformant le labyrinthe complexe d’identités de Workday en un point de contrôle unique.
Votre position de sécurité n’est alors plus réactive mais proactive et vous offre une série d’avantages :
- Éliminer les angles morts : ISPM offre une vue à 360° de chaque identité. Il ne se contente pas de voir les utilisateurs actifs, il supervise les anciens employés (licenciés), les utilisateurs locaux ne provenant pas du fournisseur d’identité et les ISU automatisés. De cette façon, les accès permanents n’échappent pas à la détection.
- Appliquer le principe du moindre privilège : ISPM identifie les comptes à privilèges excessifs (pour les utilisateurs humains et les ISU) en mappant leur accès à des domaines de données spécifiques. Cela vous permet de repérer ces comptes de service avec des droits d’administrateur obsolètes et de révoquer leur accès avant que cela ne pose problème.
- Détecter et sécuriser les identités non humaines : ISPM détecte automatiquement les comptes de service et les ISU qui ont été créés dans votre système Workday. ISPM affiche immédiatement les accès dont ils disposent, détecte les identifiants non renouvelés, les autorisations élevées et les comptes inactifs.
- Réduire la surface d’attaque : ISPM signale automatiquement les comptes avec des politiques d’authentification faibles (par exemple, des mots de passe anciens ou l’absence de MFA) et identifie les comptes inutilisés ou orphelins qui présentent un risque de sécurité immédiat.
Le résultat est un environnement Workday hautement sécurisé, conforme et supervisé en permanence.
Vous souhaitez plus de visibilité sur vos applications les plus critiques ?
L’intégration d’ISPM à Workday est disponible dès maintenant en Early Access. Contactez votre représentant Okta pour découvrir comment ISPM peut associer des informations de sécurité modernes à votre infrastructure d’identités la plus critique. Pour en savoir plus, consultez la page okta.com/products/identity-security-posture-management.
