Qu'est-ce qu'un compte de service géré par les développeurs ?

Dernière mise à jour
Enregistrer en tant que PDF

Pour les développeurs qui créent des applications utilisant des composants de connexion de données, nous recommandons d'utiliser la nouvelle fonction Developer Managed Service Accounts (DMSA) en tant qu'approche simplifiée pour fournir aux administrateurs Procore la possibilité d'installer et de provisionner facilement les applications de connexion de données dans leurs comptes d'entreprise. La fonction DMSA permet aux développeurs de spécifier les autorisations exactes des outils au niveau entreprise et projet qui sont nécessaires pour que leur application fonctionne correctement sur la plateforme Procore. Les administrateurs de l'entreprise définissent les projets auxquels l'application peut accéder à l'aide de ces autorisations. Les développeurs utilisent les DMSA pour offrir une alternative plus pratique et plus sûre aux comptes de service traditionnels. Les administrateurs de l'entreprise tirent profit des DMSA en améliorant la gestion des applications et la visibilité sur leur utilisation.

Tous les comptes de services traditionnels expireront le 31 décembre2024.

Les comptes de service traditionnels ont été abandonnés le 9 décembre 2021. À partir du 1er octobre 2024, nous ne permettrons plus la création de nouveaux comptes de service traditionnels. Les comptes de service traditionnels existants continueront de fonctionner jusqu'au 31 décembre 2024.

C'est pourquoi, les développeurs d'applications de connexion de données qui utilisent actuellement les comptes de services traditionnels doivent mettre à jour leurs applications pour utiliser les comptes de services gérés par les développeurs, et les clients doivent installer ces applications mises à jour avant la date d'expiration. Toutes les applications de connexion de données qui n'ont pas été migrées à la date d'expiration cesseront de fonctionner. Toute application répertoriée sur l'App Marketplace Procore qui n'utilise pas de méthode prise en charge pour accéder à l'API Procore sera supprimée à la date d'expiration. Voir Migrer les applications de connexion de données pour utiliser les CSGD pour plus d'informations.

Avantages de l'utilisation des comptes de services gérés par le développeur (DMSA)

L'utilisation des DMSA par rapport aux comptes de service traditionnels présente un certain nombre d'avantages :

Gestion simplifiée des applications - Les DMSA sont installés et gérés par les administrateurs de l'entreprise à l'aide de la fonction Gestion des applications de l'outil Admin de l'entreprise. L'utilisateur de l'annuaire associé au DMSA est automatiquement créé dans le cadre du processus d'installation de l'application. Avec les comptes de service traditionnels, les administrateurs de l'entreprise doivent créer et gérer manuellement le compte et ses autorisations d'accès, ce qui nécessite une communication et une coordination supplémentaires avec le développeur tiers pour installer et configurer l'application.
Gestion des autorisations plus sécurisée - Toutes les autorisations d'outil requises au niveau entreprise et au niveau projet pour une application DMSA donnée sont définies dans un manifeste d'application qui est appliqué à votre compte d'entreprise pendant le processus d'installation. Lorsqu'une application intègre de nouvelles fonctionnalités et publie une version mise à jour, le développeur peut demander de nouvelles autorisations via le processus de mise à niveau pour être révisées et approuvées.
Contrôle d'accès au projet amélioré - Au cours du processus d'installation et de configuration, les administrateurs de l'entreprise sélectionnent exactement les projets que l'application DMSA est autorisée à utiliser. Avec les comptes de service traditionnels, l'accès au projet est configuré et géré manuellement par l'administrateur de l'entreprise, ce qui peut prendre du temps et de l'argent, et peut être moins sécurisé, comme décrit ci-dessous.
Meilleure visibilité sur l'utilisation des applications : les DMSA étant installés à l'aide de la gestion des applications, les administrateurs de l'entreprise ont une visibilité sur l'utilisation des applications sous la forme de mesures d'application telles que le nombre de demandes d'API, les utilisateurs qui ont installé et/ou utilisé une application, les projets autorisés. utiliser une application, et plus encore. Avec les comptes de service traditionnels, ces mesures ne sont ni collectées ni accessibles.

Risques associés aux comptes de services traditionnels

L'installation et l'utilisation d'applications qui utilisent des comptes de service traditionnels comportent les risques suivants :

Transmission non sécurisée des informations d'identification de l'API - Étant donné qu'un compte de service traditionnel est créé manuellement dans Procore par un administrateur de l'entreprise, l'ensemble unique d'informations d'identification d'API générées (client_id et client_secret) doit être renvoyé au développeur afin de terminer la configuration de l'intégration. La transmission de ces informations sensibles peut malheureusement se produire par des moyens non sécurisés tels que les e-mails, les SMS, etc., laissant les données de l'entreprise potentiellement vulnérables.
Manque de données d'utilisation : si un compte de service traditionnel est compromis, il est difficile de savoir où il est utilisé, car le compte ne génère pas de données d'utilisation.
Potentiel d'erreur humaine : l'exigence de configurer et de gérer manuellement les autorisations associées à un compte de service traditionnel peut être sujette à des erreurs et entraîner un comportement inattendu de l'application.

En quoi un DMSA diffère-t-il d'un compte de service traditionnel ?

Voici quelques-unes des principales différences entre les DMSA et les comptes de service traditionnels.

	Compte de service gérés pour les développeurs	Compte de service traditionnel
Création de compte	Un utilisateur de l'annuaire associé au DMSA est automatiquement créé dans l'outil Annuaire de l'entreprise et/ou du projet.	Un compte de services traditionnel doit être créé et géré manuellement par un administrateur de l'entreprise.
Autorisation	Un seul ensemble d'informations d'identification (id_client, secret_client) est utilisé pour accéder à toutes les entreprises où l'application est installée.	Chaque compte de services créé dans une entreprise par un administrateur possède un ensemble unique d'informations d'identification, ce qui nécessite une coordination manuelle avec le développeur pour une intégration réussie.
Autorisations	Les autorisations requises sont définies par le développeur dans le manifeste de l'application et sont appliquées automatiquement lors de l'installation.	Les autorisations pour chaque compte de service doivent être configurées manuellement par un administrateur de l'entreprise.
Configuration du projet	Pendant l'installation, vous pouvez sélectionner les projets dans lesquels l'application DMSA est autorisée à s'exécuter. Une fois l'application installée, vous pouvez ajouter ou supprimer les projets autorisés selon les besoins.	L'accès au projet doit être configuré et géré manuellement par l'administrateur de l'entreprise.
Gestion des applications	Les applications compatibles DMSA sont facilement installées à partir de l'App Marketplace ou en tant qu'installation personnalisée. L'outil Admin de l'entreprise (gestion des applications) est utilisé pour la désinstallation et la réinstallation.	Tous les aspects de l'installation et de la gestion traditionnelles des comptes de service doivent être gérés manuellement par un administrateur de l'entreprise.

Qu'est-ce que je verrai dans mon compte après avoir installé une application qui utilise un DMSA ?

Au cours du processus d'installation, un nouvel enregistrement d'utilisateur peut être créé dans l'outil Annuaire de l'entreprise et/ou du projet qui représente le DMSA. Le nom du contact DMSA suit un format distinct avec le nom de l'application converti en minuscules et séparé par des tirets suivis d'un identifiant de huit caractères généré de manière aléatoire. Par exemple, l'installation de l'application Mon application de test DMSA créerait l'utilisateur my-dmsa-test-app-469b1f7f dans l'annuaire de l'entreprise. Il est important de ne pas modifier ni supprimer les utilisateurs de l'annuaire créés par les installations d'applications DMSA, car cela pourrait entraîner des problèmes de fonctionnement de l'application.

Implications de l'octroi d'autorisations d'administrateur d'annuaire aux applications

Les administrateurs de l'entreprise sont fortement mis en garde contre l'octroi d'un accès administrateur à l'outil Annuaire au niveau entreprise aux applications utilisant des DMSA ou des comptes de service traditionnels. Les applications avec ce niveau d'accès le plus élevé ont la possibilité d'apporter des modifications qui peuvent affecter négativement tous les outils d'un projet entier ou tous les projets de l'ensemble du compte d'entreprise Procore de votre organisation. Bien que certaines applications puissent nécessiter que cela fonctionne, nous vous recommandons d'examiner attentivement la nécessité de l'intégration et de comprendre l'impact avant de l'autoriser.

Comprendre l'authentification API Procore

Les applications construites sur la plate-forme Procore utilisent le cadre d'autorisation OAuth 2.0 standard de l'industrie pour l'authentification avec l'API. L'API Procore prend en charge les deux types d'octroi d'autorisation ou flux d'authentification suivants :

Identifiants du client (DMSA et comptes de service traditionnels) : la plupart des applications de connexion de données utilisent ce type d'octroi pour l'authentification avec l'API. Avec le type d'octroi Identifiants du client, un seul ensemble d'informations d'identification d'API est utilisé (via un compte de service DMSA ou traditionnel) pour s'authentifier auprès de l'API Procore. L'accès aux outils et aux données sur la plateforme Procore est régi par les paramètres d'autorisation associés à ce compte. Par conséquent, les développeurs et les administrateurs de l'entreprise peuvent spécifier les outils et projets exacts auxquels une application a accès. Il s'agit de l'approche préférée pour les applications de connexion de données. Pour plus d'informations sur le type d'octroi des informations d'identification du client, consultez Utilisation du type d'octroi des informations d'identification du client OAuth 2.0 .
Code d'autorisation (flux de connexion de l'utilisateur) : le serveur Web et les applications basées sur un navigateur utilisent souvent ce type d'autorisation pour l'authentification avec l'API. Avec le type d'octroi Code d'autorisation, l'application fonctionne au nom de l'utilisateur actuellement connecté lors de l'authentification avec l'API Procore. Dans ce scénario, l'application assume les autorisations de l'utilisateur connecté et a accès à tout outil, projet ou donnée avec lequel un utilisateur particulier est autorisé à interagir. Étant donné que la gouvernance des autorisations peut être difficile avec ce type d'octroi, elle n'est pas recommandée pour les applications de connexion de données. Pour plus d'informations sur le type d'octroi de code d'autorisation, consultez Flux d'octroi de code d'autorisation OAuth 2.0 .

Les administrateurs de l'entreprise Procore sont ultimement responsables de la gestion des autorisations des utilisateurs de leur annuaire, quel que soit le type d'octroi d'autorisation utilisé par une intégration : code_autorisation (autorisations de l'utilisateur connecté) ou identifiants_client (compte de service/autorisations DMSA).

Modèle de sécurité à responsabilité partagée

En tant que fournisseur de logiciel en tant que service (SaaS), Procore suit un modèle de responsabilité partagée dans le contexte de la sécurité de la plate-forme.

Les clients sont responsables des intégrations qu'ils installent, des autorisations qu'ils approuvent pour l'utilisation de ces intégrations et de toutes les modifications qu'ils apportent aux utilisateurs de l'annuaire (DMSA ou traditionnel) associés à ces intégrations en dehors de ce que Procore fournit.
Les partenaires/développeurs sont responsables du traitement des informations d'identification, du code qui appelle l'API et de ce qu'ils font avec les données. Le client fournit les clés aux développeurs à utiliser par les développeurs.
Procore est chargé de fournir aux développeurs un moyen de demander des autorisations aux clients via OAuth et aux clients la possibilité d'installer et de gérer des applications.

Fin des comptes de services traditionnels