Power Platform
Pour tout ce qui est transverse à l’ensemble des services de Microsoft Power Platform.
Abonné:
- Organisé par
-
-
Bonnes pratiques sur le propriétaire des flux / applications
-
Bonnes pratiques sur le propriétaire des flux / applications
Hello la commu PPFC, 🧢
Je me posais une question et j’aurais besoin de vos retours d’expérience.
Sur chacun des projets Power Platform que j’ai implémenté chez des clients, j’ai toujours utiliser des comptes de services qui servent aux développements des différentes ressources du projet.
Ces comptes sont à chaque fois propriétaire des flux / applications. Cela évite de le lier à un user qui peut être amené à quitter l’entreprise ou à être supprimé par erreur. Cela implique d’avoir des comptes de services avec des droits assez important.Par exemple, pour un projet, un compte de service doit avoir accès à :
- l’admin Sharepoint
- à Entra ID (création/modification/suppression de groupes via Power Auto).
Ce compte dispose de privilège assez important. Comment faire en sorte que ces comptes soit suffisamment robustes pour éviter tout problème de sécurité ?
Comment gérez vous ce type de sujets avec vos clients ou au sein de vos organisation ?
Je suis preneur des bonnes pratiques et de vos retours d’expérience
-
4 Réponses
-
Hello,
Dans la mesure du possible je recommande de segmenter au maximum les droits admin et de ne surtout pas tout mettre sur un seul compte.
On ne peut bien entendu pas mettre de stratégie de renouvellement de mdp, sous peine d’avoir une maintenance ingérable.
Le MFA est suffisant : pour un compte admin power platform uniquement et pour lequel le nombre de personne ayant accès au compte est maîtrisé
Si le compte admin doit avoir des droits admin sur d’autres outils, j’aurai tendance à recommander :
- mise en place d’un accès conditionnel : utilisation sur site uniquement ou via une VM
- Limiter au strict minimum le nombre de personnes ayant accès au compte (et enregistrées sur le MFA)
- Que ce compte soit dédié à ce type de besoin qui nécessite une multiplicité d’accès admin (avoir un autre compte de service moins verrouillé mais limité à power platform)
-
Merci beaucoup pour les infos David 🤜🤛
-
Bonjour
De notre côté les pro devs (les membres de la DSI qui font de la Power Platform) sont system admin des environnements de DEV et de REC afin d’être autonomes pour aider les citizen et utiliser les pipelines pour déployer
On a un compte de service par environnement (Dev, Recette, Prod) et ce compte de service n’est géré que par l’architecte.
- On a de l’accès conditionnel : il faut être sur un PC de la société pour accéder aux ressources de l’entreprise, y compris la Power Platform
- Il n’y a pas de MFA ni d’expiration du mot de passe => @DavidZed l’activation du MFA ne pose aucun problème pour l’exécution des scheduled flows ?
- L’architecte change tous les mois les mots de passe des comptes de service (stockés dans un coffre).
- Les comptes de service ne servent qu’à exécuter des cloud flows, dataflows et à faire les 1er déploiements des solutions (car les objets ont pour propriétaire leur 1er déployeur)
- Les devs sont propriétaires des flux et des apps en DEV, c’est maintenant assez rapide de les réassigner s’ils quittent l’entreprise
- Sur des cas particuliers on confie un compte de service à un développeur pour qu’il investigue sur un incident en production mais c’est rare et on change le mot de passe ensuite
-
Trés intéréssant ! Merci pour ton retour d’experience Jean-Rémy 🤩
Connectez-vous pour répondre.