メインコンテンツまでスキップ
Procore

開発者管理サービス アカウントとは何ですか?

  1. 最後の更新
  2. PDFとして保存

データ接続コンポーネントを使用してアプリケーションを構築する開発者には、Procore 管理者が会社アカウントにデータ接続アプリケーションを簡単にインストールしてプロビジョニングできるようにする合理的なアプローチとして、新しい開発者管理サービス アカウント (DMSA) 機能を活用することをお勧めします。DMSA 機能を使用すると、開発者は、アプリケーションを Procore プラットフォーム上で適切に実行するために必要な、正確な会社とプロジェクトのレベルのツール権限を指定できます。会社管理者は、どのプロジェクトでアプリケーションがこれらの権限を使用してアクセスできるかを定義します。開発者は DMSA を利用して、従来のサービス アカウントに代わるより便利で安全な代替手段を提供します。会社管理者は、アプリケーション管理の改善とアプリケーションの使用状況の可視性の向上を通じて、DMSA の恩恵を受けます。

開発者管理サービス アカウント (DMSA) を使用する利点

従来のサービス アカウントに替えて DMSA を使用すると、次のような多くの利点が得られます。

  • 簡素化されたアプリ管理 - DMSA は、会社管理者ツールのアプリ管理機能を使用して、会社管理者によってインストール、管理されます。DMSA に関連付けられたディレクトリ ユーザーは、アプリケーションのインストール プロセスの一環として自動的に作成されます。従来のサービスアカウントでは、会社管理者がアカウントとそのアクセス権限を手動で作成、管理する必要があり、アプリケーションをインストールして構成するには、サード パーティ開発者との追加の通信と調整が必要です。

  • より安全な権限管理 - 特定の DMSA アプリケーションに必要な会社レベルとプロジェクトレベルのツール権限はすべて、インストール プロセス中に会社アカウントに適用されるアプリケーション マニフェストで定義されます。アプリケーションに新しい機能が組み込まれ、更新されたバージョンがリリースされると、開発者はアップグレード プロセスを通じてレビューおよび承認を受ける新しい権限をリクエストできます。

  • プロジェクト アクセス制御の改善 - インストールと構成のプロセス中に、会社管理者はどのプロジェクトで DMSA アプリケーションの使用を許可するのかを正確に選択します。従来のサービス アカウントでは、プロジェクト アクセスは会社管理者によって手動で構成、管理されますが、これには時間と費用がかかる可能性があり、以下で説明するように安全性が低い場合があります。

  • アプリケーションの使用状況に関するより良い見識 - DMSA はアプリ管理を使用してインストールされるため、会社管理者は、API リクエストの数、どのユーザーがアプリケーションをインストールや使用したか、どのプロジェクトがアプリケーションの使用を許可されているか、などのアプリケーションのメトリクスの形式でアプリケーションの使用状況の視程を持つことができます。従来のサービス アカウントでは、このようなメトリクスは収集されず、アクセスもできません。

従来のサービス アカウントに関連するリスク

従来のサービス アカウントを利用するアプリケーションのインストールと使用には、次のリスクが伴います。

  • API 認証情報の安全でない送信 - 従来のサービス アカウントは会社管理者によって Procore で手動で作成されるため、統合構成を正常に完了するには、生成された API 認証情報 (client_id と client_secret) の一意のセットを開発者に返す必要があります。残念ながら、この機密情報の送信は、電子メール、テキスト メッセージ、等の安全でない手段を通じて行われる可能性があり、会社データが脆弱になる可能性があります。

  • 使用状況データの欠如 - 従来のサービスアカウントが侵害された場合、アカウントは使用状況データを生成しないため、アカウントがどこで使用されているかを追跡することが困難です。

  • 人的エラーの可能性 - 従来のサービス アカウントに関連付けられた権限を手動で構成、管理する必要があるため、エラーが発生しやすく、アプリケーションの予期しない動作につながる可能性があります。

DMSA は従来のサービスアカウントとどう違うのですか?

DMSA と従来のサービスアカウントの主な違いをいくつか紹介します。

  開発者が管理するサービスアカウント 従来のサービスアカウント
アカウントを作成する
  • DMSA に関連付けられたディレクトリ ユーザーは、会社やプロジェクト ディレクトリのツールで自動的に作成されます。
  • 従来のサービス アカウントは、会社管理者が手動で作成、管理する必要があります。
認証
  • 単一の認証情報セット (client_id、client_secret) は、アプリケーションがインストールされているすべての会社にアクセスするために使用されます。
  • 管理者によって会社内に作成された各サービス アカウントには一意の認証情報のセットがあり、統合の成功のためには開発者と手動で調整する必要があります。
権限
  • 必要な権限は開発者によってアプリケーション マニフェストで定義され、インストール中に自動的に適用されます。
  • 各サービスアカウントの権限は、会社管理者が手動で構成する必要があります。
プロジェクト構成
  • インストール中に、どのプロジェクトで DMSA アプリケーションの実行を許可するのかを選択できます。アプリケーションをインストールしたら、必要に応じて許可されたプロジェクトを追加または削除できます。
  • プロジェクトへのアクセスは、会社管理者が手動で構成、管理する必要があります。
アプリ管理
  • DMSA 対応アプリケーションは、アプリ マーケットプレースから、またはカスタム インストールとして簡単にインストールできます。アンインストール/再インストールに使用される会社管理者ツール (アプリ管理)。
  • 従来のサービス アカウントのインストールと管理は、全面的に会社管理者が手動で処理する必要があります。

DMSA を使用するアプリケーションをインストールすると、アカウントには何が表示されますか?

インストール プロセス中に、DMSA を表す会社やプロジェクトのディレクトリ ツールに新しいユーザー記録が作成される場合があります。DMSA 連絡先名は、アプリケーション名が小文字に変換され、ダッシュで区切られ、その後にランダムに生成された 8 文字の ID が続く独自の形式に従います。たとえば、アプリケーション My DMSA Test Appをインストールすると、会社ディレクトリにユーザー my-dmsa-test-app-469b1f7f が作成されます。DMSA アプリケーションのインストールによって作成されたディレクトリ ユーザーを編集または削除しないことが重要です。これによって、アプリケーションの動作に問題が発生する可能性があるためです。

DMSA 権限管理のベスト プラクティス

開発者管理サービス アカウント (DMSA) の権限を管理するには、アプリケーションの機能とアカウントのセキュリティを確保するための慎重な検討が必要です。 以下は、権限を効果的に管理するためのベスト プラクティスと重要な考慮事項です。

  1. プロジェクト メンバーシップの [権限] タブを使用する - プロジェクト メンバーシップの追加や削除など、DMSA プロジェクト アクセスを管理するには、アプリ管理の下にあるアプリケーション内の [権限] タブを利用します。 このオプションは、会社管理者が利用できます。

  2. アプリの更新または再インストール時の権限の再構成 - アプリが更新または再インストールされるたびに、会社管理者は許可されたプロジェクトのリストを再構成する必要があります。 DMSA アクセスを必要とする今後のプロジェクトも、許可リストに手動で追加する必要があります。

  3. 権限テンプレートにディレクトリ ツールを使用する - 一部の管理者は、DMSA 管理を合理化するために、権限テンプレートでディレクトリ ツールを使用します。

    • [すべての新しいプロジェクトに [DMSA ユーザー] を追加する] チェックボックスを有効にすると、DMSA ユーザーが将来のプロジェクトに自動的に追加されるため、権限を簡素化できます。
    • 重要な注意点:アプリが更新または再インストールされても、アプリのマニフェストで定義された権限はディレクトリ ツールの権限テンプレートに自動的に転送されないため、アプリの機能に影響を与える可能性があります。 このずれは手動で調整する必要があります。

  4. DMSA 権限の手動更新を避ける - ディレクトリ ツール内で DMSA 権限を手動で調整することは、不整合を引き起こし、アカウント管理を複雑にする可能性があるため、一般的にはお勧めしません。

  5. DMSA アクセス権を会社レベルのディレクトリ ツールに制限する - DMSA ユーザーに会社レベルのディレクトリ ツールへの管理者レベルのアクセス権を付与しないでください。 このアクセスレベルでは、Procore アカウント内の複数のプロジェクトとツールにわたる変更が許可されるため、組織のワークフローに影響を与える可能性があります。 このレベルのアクセスは、統合に絶対に必要な場合にのみ許可し、その影響を完全に理解してください。

Procore API 認証について

Procore プラットフォーム上に構築されたアプリケーションは、API による認証に業界標準の OAuth 2.0 認証フレームワークを使用します。Procore API は、次の 2 つの認証付与タイプ、または認証フローをサポートします。

  • クライアント認証情報 (DMSA と従来のサービスアカウント) - ほとんどのデータ接続アプリケーションは、API による認証にこの付与タイプを使用します。クライアント認証情報付与タイプでは、Procore API での認証に単一セットの API 認証情報が (DMSA または従来のサービスアカウント経由で) 使用されます。Procore プラットフォーム上のツールとデータへのアクセスは、その 1 つのアカウントに関連付けられた権限設定によって管理されます。その結果、開発者と会社管理者は、アプリケーションがアクセス権のあるツールとプロジェクトを正確に指定できます。これは、データ接続アプリケーションに推奨されるアプローチです。クライアント認証情報の付与タイプの詳細については、「OAuth 2.0 クライアント認証情報の付与タイプの使用」を参照してください。

  • 認証コード (ユーザー ログイン フロー) - ウェブ サーバーとブラウザ ベースのアプリケーションは、多くの場合、API による認証にこの付与タイプを使用します。認証コード付与タイプを使用すると、Procore API で認証するときに、現在ログインしているユーザーに代わってアプリケーションが操作します。このシナリオでは、アプリケーションはログインしているユーザーのアクセス権限を想定し、特定のユーザーが操作を許可されているツール、プロジェクト、またはデータへのアクセス権があります。この付与タイプではアクセス権限の管理が困難になる可能性があるため、データ接続アプリケーションには推奨されません。認証コード付与タイプの詳細については、「OAuth 2.0 認証コード付与フロー」を参照してください。

Procore 会社管理者は、統合で使用される認証付与タイプ (authorization_code (ログイン ユーザーの権限) または client_credentials (サービス アカウント/DMSA の権限)) に関係なく、ディレクトリ ユーザーの権限を管理する最終的な責任を負います。

責任共有セキュリティ モデル

Software as a Service (SaaS) プロバイダーとして、Procore はプラットフォーム セキュリティのコンテキストにおける責任共有モデルに従っています。

  • お客様は、インストールする統合、それらの統合の使用を承認する権限、および Procore が提供するもの以外でこれらの統合に関連付けられたディレクトリ ユーザー (DMSA または従来型) に加えた変更に対して責任を負います。

  • パートナー/開発者は、認証情報の処理、API を呼び出すコード、およびデータで行うことに責任を負います。顧客は、開発者が使用するキーを開発者に提供します。

  • Procore は、開発者に OAuth 経由で顧客の権限をリクエストする手段を提供し、顧客にアプリケーションをインストール、管理できる機能を提供する責任があります。