Was ist ein entwicklerverwaltetes Servicekonto?

Zuletzt aktualisiert

17. Feb. 2025
Als PDF speichern

Entwicklern, die Anwendungen unter Verwendung von Datenverbindungskomponenten erstellen, empfehlen wir, die neue Funktion Entwicklerverwaltete Servicekonten (DMSA) zu nutzen, um Procore-Administratoren die Möglichkeit zu geben, Datenverbindungsanwendungen in ihren Unternehmenskonten einfach zu installieren und bereitzustellen. Die DMSA-Funktion ermöglicht es Entwicklern, die genauen Tool-Berechtigungen auf Unternehmens- und Projektebene festzulegen, die erforderlich sind, damit ihre Anwendung auf der Procore-Plattform ordnungsgemäß läuft. Unternehmensadministratoren legen fest, auf welche Projekte die Anwendung mit diesen Berechtigungen zugreifen kann. Entwickler nutzen DMSAs, um eine bequemere und sicherere Alternative zu herkömmlichen Servicekonten anzubieten. Unternehmensadministratoren profitieren von DMSAs durch ein verbessertes Anwendungsmanagement und einen besseren Einblick in die Anwendungsnutzung.

Alle traditionellen Servicekonten werden am 31. Dezember 2024auslaufen.

Traditionelle Servicekonten wurden am 9. Dezember 2021 eingestellt. Ab dem 1. Oktober 2024 werden wir die Erstellung neuer Konten für traditionelle Dienstleistungen nicht mehr zulassen. Bestehende traditionelle Servicekonten sind bis zum 31. Dezember 2024 weiterhin funktionsfähig.

In Übereinstimmung mit diesem Zeitplan müssen Entwickler von Datenverbindungsanwendungen, die derzeit herkömmliche Dienstkonten verwenden, ihre Anwendungen aktualisieren,um Dateiname="">Entwicklerverwaltete Dienstkonten zu verwenden<a target="_blank" title=" " href.path="//faq/what-is-developer-managed-service-account" href., und die Kunden müssen diese aktualisierten Anwendungen vor dem Ablaufdatum installieren. Alle Datenverbindungsanwendungen, die bis zum Ablaufdatum nicht migriert wurden, funktionieren nicht mehr. Alle auf dem Procore-App Marketplace aufgeführten Anwendungen, die keine unterstützte Methode für den Zugriff auf die Procore API verwenden, werden bis zum Ablaufdatum entfernt. Siehe Migration von Datenverbindungsanwendungen zur Verwendung von DMSAs für zusätzliche Informationen.

Vorteile der Verwendung von Developer Managed Service Accounts (DMSAs)

Es gibt eine Reihe von Vorteilen, die durch die Verwendung von DMSAs gegenüber herkömmlichen Servicekonten erzielt werden können:

Vereinfachte App-Verwaltung – DMSAs werden von Unternehmensadministratoren mithilfe der App-Management-Funktion im Unternehmensadmin-Tool installiert und verwaltet. Der mit dem DMSA verknüpfte Verzeichnisbenutzer wird automatisch als Teil des Installationsprozesses der Anwendung erstellt. Bei herkömmlichen Servicekonten müssen Unternehmensadministratoren das Konto und seine Zugriffsberechtigungen manuell erstellen und verwalten, was zusätzliche Kommunikation und Koordination mit dem Drittanbieter-Entwickler erfordert, um die Anwendung zu installieren und zu konfigurieren.
Sicherere Berechtigungsverwaltung - Alle erforderlichen Tool-Berechtigungen auf Unternehmensebene und Projektebene für eine bestimmte DMSA-Anwendung werden in einem Anwendungsmanifest definiert, das während des Installationsvorgangs auf Ihr Unternehmenskonto angewendet wird. Wenn eine Anwendung neue Funktionen enthält und eine aktualisierte Version veröffentlicht, kann der Entwickler über den Upgrade-Prozess neue Berechtigungen anfordern, die überprüft und genehmigt werden.
Verbesserte Projektzugriffskontrolle - Während des Installations- und Konfigurationsprozesses wählen die Unternehmensadministratoren genau aus, welche Projekte die DMSA-Anwendung verwenden darf. Bei herkömmlichen Servicekonten wird der Projektzugriff manuell vom Unternehmensadministrator konfiguriert und verwaltet, was zeitaufwändig und kostspielig sein kann und möglicherweise weniger sicher ist, wie unten beschrieben.
Besserer Einblick in die Anwendungsnutzung - Da DMSAs mithilfe von App Management installiert werden, haben Unternehmensadministratoren einen Sichtbarkeit der Anwendungsnutzung in Form von Anwendungsmetriken wie der Anzahl der API-Anfragen, welche Benutzer eine Anwendung installiert und/oder verwendet haben, welche Projekte eine Anwendung verwenden dürfen und mehr. Bei herkömmlichen Servicekonten werden solche Metriken weder erfasst noch sind sie zugänglich.

Risiken im Zusammenhang mit traditionellen Servicekonten

Die Installation und Verwendung von Anwendungen, die herkömmliche Servicekonten verwenden, birgt die folgenden Risiken:

Ungesicherte Übertragung von API-Anmeldeinformationen - Da ein herkömmliches Servicekonto in Procore manuell von einem Unternehmensadministrator erstellt wird, muss der eindeutige Satz der generierten API-Anmeldedaten (client_id und client_secret) dem Entwickler zurückgegeben werden, um die Einrichtung der Integration erfolgreich abzuschließen. Die Übertragung dieser sensiblen Informationen kann leider über ungesicherte Mittel wie E-Mail, Textnachricht usw. erfolgen, wodurch Unternehmensdaten potenziell anfällig werden.
Fehlende Nutzungsdaten – Wenn ein herkömmliches Servicekonto kompromittiert wird, ist es schwierig nachzuvollziehen, wo es verwendet wird, da das Konto keine Nutzungsdaten generiert.
Potenzial für menschliches Versagen – Die Anforderung, die mit einem herkömmlichen Servicekonto verbundenen Berechtigungen manuell zu konfigurieren und zu verwalten, kann fehleranfällig sein und zu unerwartetem Anwendungsverhalten führen.

Wie unterscheidet sich ein DMSA von einem herkömmlichen Servicekonto?

Hier sind einige der Hauptunterschiede zwischen DMSAs und traditionellen Servicekonten.

	Entwicklerverwaltete Servicekonten	Traditionelles Servicekonto
Kontoerstellung	Ein mit der DMSA verbundener Adressbuchnutzer wird automatisch im Unternehmens- und/oder Projektadressbuch erstellt.	Ein herkömmliches Servicekonto muss manuell von einem Unternehmensadministrator erstellt und verwaltet werden.
Autorisierung	Ein einziger Satz von Anmeldedaten (client_id, client_secret) wird für den Zugang zu allen Unternehmen verwendet, in denen die Anwendung installiert ist.	Jedes Servicekonto, das in einem Unternehmen von einem Administrator erstellt wird, verfügt über eindeutige Anmeldedaten, die für eine erfolgreiche Integration eine manuelle Abstimmung mit dem Entwickler erfordern.
Berechtigungen	Die erforderlichen Berechtigungen werden vom Entwickler im Anwendungsmanifest festgelegt und bei der Installation automatisch angewendet.	Die Berechtigungen für jedes Servicekonto müssen manuell von einem Unternehmensadministrator konfiguriert werden.
Projektkonfiguration	Während der Installation können Sie auswählen, in welchen Projekten die DMSA-Anwendung laufen darf. Sobald die Anwendung installiert ist, können Sie nach Bedarf zulässige Projekte hinzufügen oder entfernen.	Der Projektzugang muss vom Unternehmensadministrator manuell konfiguriert und verwaltet werden.
App-Verwaltung	DMSA-fähige Anwendungen lassen sich problemlos über den App Marketplace oder als benutzerdefinierte Installation installieren. Unternehmensadministrator-Tool (App Management) für die Deinstallation/Neuinstallation verwendet.	Alle Aspekte der herkömmlichen Einrichtung und Verwaltung von Servicekonten müssen manuell von einem Unternehmensadministrator durchgeführt werden.

Was wird in meinem Konto angezeigt, nachdem ich eine Anwendung installiert habe, die eine DMSA verwendet?

Während des Installationsvorgangs kann ein neuer Benutzerdatensatz im Unternehmens- und/oder Projektadressbuch-Tool erstellt werden, der die DMSA darstellt. Der DMSA-Kontaktname folgt einem bestimmten Format, bei dem der Anwendungsname in Kleinbuchstaben umgewandelt und durch Bindestriche getrennt wird, gefolgt von einer achtstelligen, zufällig generierten ID. Wenn Sie zum Beispiel die Anwendung My DMSA Test App installieren, wird der Benutzer my-dmsa-test-app-469b1f7f im Unternehmensadressbuch angelegt. Es ist wichtig, dass Sie Verzeichnisbenutzer, die von DMSA-Anwendungsinstallationen erstellt wurden, nicht bearbeiten oder löschen, da dies zu Problemen mit dem Betrieb der Anwendung führen kann.

Bewährte Praktiken für das DMSA-Berechtigungsmanagement

Die Verwaltung von Berechtigungen für ein Developer Managed Service Account (DMSA) erfordert sorgfältige Überlegungen, um die Anwendungsfunktionalität und die Kontosicherheit zu gewährleisten. Im Folgenden finden Sie bewährte Praktiken und wichtige Überlegungen für eine effektive Verwaltung von Berechtigungen.

Verwenden der Registerkarte "Berechtigungen" für die Projektmitgliedschaft - Um den DMSA-Projektzugriff zu verwalten, einschließlich des Hinzufügens oder Entfernens von Projektmitgliedschaften, verwenden Sie die Registerkarte Berechtigungen in der App unter App-Verwaltung. Diese Option steht Unternehmensadministratoren zur Verfügung.
Neukonfiguration von Berechtigungen bei App-Update oder Neuinstallation - Jedes Mal, wenn eine App aktualisiert oder neu installiert wird, müssen Unternehmensadministratoren die Liste der zulässigen Projekte neu konfigurieren. Zukünftige Projekte, die einen DMSA-Zugang erfordern, müssen ebenfalls manuell in die zulässige Liste aufgenommen werden.
Verwenden des Adressbuch-Tools für Berechtigungsvorlagen - Einige Administratoren verwenden das Adressbuch-Tool mit einer Berechtigungsvorlage, um die DMSA-Verwaltung zu optimieren:
- Wenn Sie das Kontrollkästchen "[DMSA-Benutzer] zu allen neuen Projekten hinzufügen" aktivieren, können Berechtigungen vereinfacht werden, indem der DMSA-Benutzer automatisch zu zukünftigen Projekten hinzugefügt wird.
- Wichtiger Hinweis: Wenn eine App aktualisiert oder neu installiert wird, werden die im Manifest der App definierten Berechtigungen nicht automatisch in die Berechtigungsvorlage im Adressbuchtool übertragen, was sich möglicherweise auf die Funktionalität der App auswirkt. Diese Fehlausrichtung sollte manuell abgeglichen werden.
Vermeiden Sie manuelle Aktualisierungen von DMSA-Berechtigungen - Von der manuellen Anpassung der DMSA-Berechtigungen innerhalb des Adressbuch-Tools wird im Allgemeinen abgeraten, da dies zu Inkonsistenzen führen und die Kontoverwaltung erschweren kann.
Beschränken Sie den DMSA-Zugriff auf das Adressbuch-Tool auf Unternehmensebene- Vermeiden Sie es, dem DMSA-Benutzer Admin-Zugriff auf das Adressbuch-Tool auf Unternehmensebene zu gewähren. Diese Zugriffsebene ermöglicht Änderungen über mehrere Projekte und Tools in Ihrem Procore-Konto hinweg, was sich auf die Arbeitsabläufe Ihres Unternehmens auswirken kann. Erlauben Sie diese Zugriffsebene nur, wenn dies für die Integration unbedingt erforderlich ist, und stellen Sie sicher, dass Sie die Auswirkungen gründlich verstehen.

Grundlegendes zur Procore API-Authentifizierung

Anwendungen, die auf der Procore-Plattform basieren, verwenden das Branchenstandard OAuth 2.0 Authorization Framework für die Authentifizierung mit der API. Die Procore API unterstützt die folgenden zwei Arten von Autorisierungen, Erteilungen oder Authentifizierungsabläufen:

Client Credentials (DMSAs und herkömmliche Servicekonten) – Die meisten Datenverbindungsanwendungen verwenden diesen Gewährungstyp für die Authentifizierung mit der API. Mit dem Gewährungstyp "Client Credentials" wird ein einziger Satz von API-Anmeldedaten (über ein DMSA- oder herkömmliches Servicekonto) zur Authentifizierung bei der Procore API verwendet. Der Zugriff auf Tools und Daten auf der Procore-Plattform wird durch die Berechtigungseinstellungen geregelt, die mit diesem einen Konto verbunden sind. Auf diese Weise können Entwickler und Unternehmensadministratoren genau die Tools und Projekte angeben, auf die eine Anwendung Zugriff hat. Dies ist der bevorzugte Ansatz für Datenverbindungsanwendungen. Weitere Informationen zum Grant-Typ für Client-Anmeldeinformationen finden Sie unter Verwendung des OAuth 2.0-Client-Credentials-Grant-Typs.
Autorisierungscode (Benutzeranmeldefluss) – Webserver und browserbasierte Anwendungen verwenden diesen Gewährungstyp häufig für die Authentifizierung mit der API. Mit dem Autorisierungscode-Grant-Typ arbeitet die Anwendung bei der Authentifizierung mit der Procore API im Namen des aktuell angemeldeten Benutzers. In diesem Szenario nimmt die Anwendung die Berechtigungen des angemeldeten Benutzers an und hat Zugriff auf alle Tools, Projekte oder Daten, mit denen ein bestimmter Benutzer interagieren darf. Da die Berechtigungsgovernance bei diesem Gewährungstyp eine Herausforderung darstellen kann, wird sie für Datenverbindungsanwendungen nicht empfohlen. Weitere Informationen zum Autorisierungscode-Grant-Typ finden Sie unter OAuth 2.0 Authorization Code Grant Flow.

Procore-Unternehmensadministratoren sind letztendlich für die Verwaltung der Berechtigungen ihrer Adressbuchbenutzer verantwortlich, unabhängig von der Art der Berechtigungserteilung, die von einer Integration verwendet wird - authorization_code (Berechtigungen des angemeldeten Benutzers) oder client_credentials (Servicekonto/DMSA-Berechtigungen).

Sicherheitsmodell der geteilten Verantwortung

Als Software-as-a-Service (SaaS)-Anbieter verfolgt Procore ein Modell der geteilten Verantwortung im Zusammenhang mit der Plattformsicherheit.

Die Kunden sind verantwortlich für die Integrationen, die sie installieren, die Berechtigungen, die sie für die Verwendung dieser Integrationen genehmigen, und alle Änderungen, die sie an den Verzeichnisbenutzern (DMSA oder traditionell) vornehmen, die mit diesen Integrationen verbunden sind und über das hinausgehen, was Procore bietet.
Partner/Entwickler sind für den Umgang mit Anmeldedaten, den Code, der die API aufruft, und was sie mit den Daten tun, verantwortlich. Der Kunde stellt den Entwicklern die Schlüssel zur Verfügung, die von den Entwicklern verwendet werden können.
Procore ist dafür verantwortlich, Entwicklern die Möglichkeit zu geben, Berechtigungen von Kunden über OAuth anzufordern, und Kunden die Möglichkeit zu geben, Anwendungen zu installieren und zu verwalten.

Auslaufen traditioneller Servicekonten