高度なコラボレーションを使用してMicrosoft Teams アプリを作成する場合は、顧客のプライバシーとセキュリティに重点を置いてアプリを設計し、広範な使用と導入を確保します。
この記事では、配布を目的とした Teams アプリを構築するときに Microsoft Graph のアクセス許可を使用するためのベスト プラクティスについて説明します。
最小特権の原則を実装する
Microsoft Graph には、アプリが必要なアクセス許可のみを要求できる詳細なアクセス許可が用意されています。 Microsoft Graph では、顧客テナント管理者が、必要以上に多くのアクセス許可を要求するアプリやアプリ機能を承認しない可能性があるため、この機能が提供されます。 アプリに必要な最小限の最小特権のアクセス許可を要求することで、最小特権の原則を適用します。これにより、顧客テナント管理者との信頼が構築されます。
アプリが要求するアクセス許可が少ないほど、顧客のプライバシーに関する懸念は少なくなります。 したがって、より単純な機能が同様の値を提供する一方で、Graph エンドポイントまたはアクセス許可を少なくする必要がある場合は、機能を再検討してください。
Microsoft Graph では、委任されたアクセスとアプリケーション アクセスという 2 種類のアクセス シナリオがサポートされています。 委任されたアクセスでは、アプリはサインインしているユーザーの代わりに Microsoft Graph を呼び出します。 アプリケーション アクセスでは、アプリは、サインインしているユーザーなしで、独自の ID で Microsoft Graph を呼び出します。 リソース固有の同意 (RSC) アクセス許可は、委任されたアクセスとアプリケーション アクセスの両方をサポートしますが、アプリがインストールされているドメインに制限されます。 詳細については、「Microsoft Graph のアクセス許可」を参照してください。
要求されたアクセス許可の特権が低いほど、顧客のプライバシーに関する懸念は少なくなります。 より高いレベルのプライバシーを提供するため、RSC のアクセス許可を優先します。 委任されたアクセス許可を使用すると、サインインしているユーザーに代わってアプリケーションが動作し、ユーザーのスコープ内のデータへのアクセスが制限されます。 RSC または委任されたアクセス許可を使用できない場合は、アプリケーションのアクセス許可を使用する必要があります。 アプリケーションのアクセス許可は、サインインしているユーザーなしでデータへのアクセスを許可するため、プライバシーリスクが最も高まります。
次の例では、最小特権の原則を使用するいくつかのシナリオについて説明します。
サインインしたユーザーのプロファイル情報のみを読み取るアプリには、ユーザーの詳細にアクセスするための最小特権である
User.Readアクセス許可が必要です。User.ReadWriteアクセス許可は不要です。アプリの過剰な特権であるため、ユーザーのプロファイルを変更する必要はありません。サインインしているユーザーなしでテナント グループを読み取るアプリには、アプリケーションのアクセス許可
Group.Read.All必要があります。動的ジョブを管理し、ユーザーの Outlook 予定表と同期して読み取りと更新を行うアプリには、
Calendars.ReadWriteアクセス許可が必要です。Teams ストアで発行されたアプリでは、
AppCatalog.Read.Allを使用してアプリ ID を取得する代わりに、アプリの永続 ID を使用できます。チャットにメッセージを送信するアプリでは、委任された Microsoft Graph アクセス許可ではなく、RSC アクセス許可
ChatMessage.Send.ChatChat.ReadWrite使用できます。
最小特権の原則を適用する方法の詳細については、「最小特権の 原則によるセキュリティの強化 」および「 アクセス許可と同意を通じて ID をセキュリティで保護するアプリの構築」を参照してください。
アクセス許可が制限されているお客様のアプリ価値とユーザー エクスペリエンスを最大化する
テナント管理者は、アプリが依存するアクセス許可をブロックできます。 アプリの価値を最大化するための代替手段を提供することで、これを予測します。 顧客テナントに特定のアクセス許可が付与されていない場合でも、アプリは引き続きユーザーに価値を提供する必要があります。 ブロックされたアクセス許可を必要とする特定の機能のみを使用できません。 アクセス許可がブロックされたときにユーザーの価値を最大化する方法を示す次のシナリオを検討してください。
-
フォールバックの回避策を作成する: 優先機能がブロックされたときに、アクセス許可のない代替手段を準備して、ユーザーが可能な限り最適なエクスペリエンスを受け取られるようにします。 たとえば、
Presence.Read.Allを使用してアプリ内のユーザーの状態を表示し、アクセス許可が拒否された場合は、プレゼンス インジケーターを非表示にして 、不明な 状態からの混乱を避けます。 または、アプリが予定表イベントを作成する場合は、Graph を使用してCalendar.ReadWriteアクセス許可を要求するためのフォールバックとしてディープ リンク メソッドを使用します。 ディープ リンクを使用すると、ユーザーがアクセス許可を付与しない場合でも、 予定表にイベントを追加 する機能を使用できます。 - 機能管理を実装する: トグルやその他の管理ツールを使用して、顧客から付与されたアクセス許可に基づいて機能を調整します。
- ユーザーがインストールしたアプリに対する時間差アクセス許可を検討する: ユーザーがインストールしたアプリの場合は、機能に必要な場合にのみアクセス許可を要求し、ユーザーのプライバシー ポリシーに合わせて調整し、アプリの使用を増やす可能性がある場合に限 り、アクセス許可を要求 することを検討してください。 この方法は、管理者がインストールしたアプリには適していない可能性があります。
アプリの起動と更新を顧客と一緒に管理する
アクセス許可の変更を伴う新しいアプリ バージョンを効果的に管理するには、顧客と通信して信頼を維持し、チャーンを防ぎます。 アプリを更新するときは、次の点を考慮してください。
- アクセス許可の変更をグループ化する: アクセス許可の変更を 1 つのリリースに統合して、更新の頻度と顧客への影響を最小限に抑えます。
- 事前に更新プログラムを管理する: アクセス許可の更新プログラムを事前に計画して伝え、ユーザーが内部承認プロセスを開始できるようにし、アプリ機能の中断を回避します。
必要なアクセス許可を文書化して顧客と共有する
技術関係者とビジネス関係者の両方がアクセスできる形式と言語ですべてのアクセス許可を明確に文書化します。 次の一覧では、アプリ内のアクセス許可の選択肢を明確に文書化するための具体的な提案を示します。
- ユース ケースの説明: アプリのユース ケースとシナリオに直接関連する説明を提供し、各アクセス許可によって追加された値を詳しく説明します。
- ビジュアルを含める: スクリーンショットを使用して、アプリ内のアクセス許可が必要な場所を示します。
- 付与されていないアクセス許可の影響について説明する: 価値の高いシナリオでは、アクセス許可が付与されていない場合のユーザーへの影響について説明します。
- アプリの明確なバージョンを提供する: 公開されたアプリ、Azure AD アプリの登録、ドキュメント用のわかりやすいバージョン管理システムを作成します。 このようなバージョン管理システムを使用すると、お客様は各バージョンの機能と承認を追跡できます。
Teams アプリに推奨されるアプリのインストール、同意、更新プログラムを使用する
顧客テナント管理者は、カスタム インストールと管理システムを使用するアプリよりも、標準の手順に準拠するアプリを信頼します。 次のインストールのベスト プラクティスを検討してください。
- 標準アプリのインストールを提供する: 信頼を維持するには、Microsoft の公式チャネルを使用してアプリを発行し、アプリのインストールに Microsoft の推奨プロセスを使用します。 リンクや複数のアプリなどの代替インストール方法は、顧客の信頼を損なうので使用しないでください。 例外は、特定の Exchange オンライン メールボックス、不足している Outlook メールボックス、または SharePoint コントロールへのアプリケーションのアクセス許可の制限などの状況で適用されます。
-
管理者がインストールしたアプリのユーザーからアプリを非表示にする: 管理者がインストールしたアプリの場合は、アプリ マニフェストの
defaultBlockUntilAdminActionパラメーターを true に設定して、管理者が承認するまで既定でテナント ユーザーからアプリを非表示にすることを検討してください。 この方法は、ユーザーがインストールしたアプリには適していない可能性があります。
アクセス許可を変更した後に発行元の構成証明を更新する
信頼できるエクスペリエンスを提供し、顧客が認識するエクスペリエンスを提供するには、アプリのアクセス許可の変更を反映するように Publisher 構成証明 を更新します。 そうでない場合、Microsoft ドキュメント ページのアクセス許可の一覧は、アプリによって要求されたアクセス許可の一覧とは異なります。 この違いは、顧客の信頼と導入を損ないます。
Teams アプリの Microsoft 365 認定資格
Microsoft 365 プログラムを通じて Teams アプリを認定します。 Microsoft 365 認定資格を使用すると、セキュリティとプライバシーの基準を遵守することに対する献身を確認できます。これにより、顧客の信頼が高まるとともに、アプリとそのアクセス許可の承認プロセスが容易になります。