Teams アプリのアクセス許可と、Teams アプリによってアクセスされる情報について理解する
Teams アプリは、機能によっては、ユーザーまたはorganizationの情報にアクセスして意図したとおりに機能する場合とアクセスできない場合があります。
- 一部のアプリでは、organizationの情報へのアクセスを求めないため、承認は必要ありません。 ユーザーは、管理者の承認または同意なく、そのようなアプリからorganizationの情報がセキュリティで保護されているため、このようなアプリを使用できます。
- 一部のアプリでは、organizationまたはユーザーの情報を機能させたり、情報を処理したりする必要があります。 このようなアプリは、そのようなアプリが組織の情報にアクセスすることを許可しない限り機能しません。
アプリのコンプライアンス、セキュリティ、およびデータ処理の情報を評価し、アプリがユーザーが使用できるようにする前に、アプリによって要求されたアクセス許可も理解する必要があります。 そのためには、アクセス許可、同意、および使用可能なコントロールについて理解する必要があります。
アクセス許可を使用すると、アプリは特権リソースにアクセスし、ユーザーに代わって行動できます。 これにより、開発者はユーザーの生産性を向上させる豊富な機能をアプリに作成できます。 アクセス許可、そのスコープ、および影響について明確に理解する必要があります。 Teams 管理センターのアプリの詳細ページで、アプリのすべてのアクセス許可とその詳細情報を提供します。
アクセス許可を使用してアプリがorganizationの情報にアクセスする方法
Teams では、同意なしにorganizationまたはユーザーの情報にアクセスできないようにセーフガードが提供されます。 アプリが情報にアクセスするには、次のアクションが実行される必要があります。
- アプリ開発者は、アプリの作成時にアクセス許可と アプリ機能を 宣言します。
- 管理者は、管理ポータルでアプリに必要なアクセス許可を理解し、分析します。
- データ アクセスは 2 つの方法で付与されます。 アプリが Teams に追加されると、基本的な情報へのアクセスを含むいくつかの基本的な機能へのアクセスが付与されます。 同意を付与すると、アプリは、同意を要求したアプリのアクセス許可に基づいて、ユーザーとorganizationまたはその両方のデータへのアクセスを受け取ります。
アプリによるデータ アクセスと必要なアクセス許可について理解する
アプリケーションは、次の 2 つの方法でorganizationの情報にアクセスできます。
- 委任されたアクセス: アプリケーションは、ユーザーの代わりにリソースにアクセスします。 このアクセスには、委任されたアクセス許可が必要です。 アプリケーションは、ユーザーが自分でアクセスできる情報にのみアクセスできます。
- アプリケーション アクセス: アプリケーションは、サインインしたユーザーがいない場合、特定のユーザーがサインインすることが望ましくない場合、または必要なデータのスコープを 1 人のユーザーに限定できない場合に、独自に動作します。 このアクセスには、アプリケーションのアクセス許可が必要です。 同意が付与されている場合、アプリケーションは、アクセス許可が関連付けられているデータにアクセスできます。
| 管理考慮事項 | 委任されたアクセス許可 | アプリケーションのアクセス許可 |
|---|---|---|
| アプリが情報にアクセスする方法 | サインインしているユーザーの代わりに。 | 独自に、独自の ID を使用します。 |
| アクセスされる情報 | アプリに対する同意が付与されているアクセス許可と、サインインしているユーザーがアクセス権を持つそのアクセス許可に関連付けられている情報。 | 同意されたアクセス許可が関連付けられている情報 |
| 同意できるロール | 構成に応じて管理者またはユーザーまたはグループの所有者Microsoft Entra ID | 管理者のみ |
| ユーザーが同意できる | ユーザーは、Microsoft Entra ID構成に応じて同意できます | 管理者のみが同意できます |
アプリごとに、そのアクセス許可が管理センターのアプリの詳細ページに一覧表示されます。
| アプリのアクセス許可の種類 | アクセス コンテキスト | 宣言ソース | 同意が必要なのはいつですか? | 誰が同意できますか? |
|---|---|---|---|---|
| Graph とレガシ エンドポイント アクセスのMicrosoft Entra ID | 委任 | Microsoft Entra ID | アプリのサインイン | グローバル 管理、クラウド 管理、アプリケーション 管理 |
| Graph とレガシ エンドポイント アクセスのMicrosoft Entra ID | アプリケーション | Microsoft Entra ID | アプリのサインイン | グローバル 管理、クラウド 管理、アプリケーション 管理 |
| チーム、チャット、ユーザーの情報のための RSC | 委任 | アプリ マニフェスト ファイル | チームへのアプリの追加、チャット、会議 | リソース所有者 |
| チーム、チャット、ユーザーの情報のための RSC | アプリケーション | アプリ マニフェスト ファイル | チームへのアプリの追加、チャット、会議 | リソース所有者 |
| その他のアクセス許可とデータ アクセス | SDK を介して委任される | マニフェスト プロパティで定義する | クライアントにアプリを追加する | 同意はインストール時に暗黙的に指定されます |
可能な場合は、より低い特権ロールを使用してタスクを実行することをお勧めします。 グローバル管理者ロールは、必要な場合にのみ使用します。
管理者がアプリのすべてのアクセス許可を確認できる場所
アプリによって要求されたすべての種類のアクセス許可の詳細は、アプリの詳細ページの [アクセス許可] タブにあります。 必要に応じて、.csv ファイル内のすべてのアクセス許可をダウンロードして、さらに分析することもできます。
- A: アプリのすべてのアプリケーション アクセス許可。
- B: アプリのすべての委任されたアクセス許可。
- C: アプリによってアクセスされるユーザーとデータとの基本的な機能と相互作用
アプリの使用を許可する方法については、「Teams アプリの アクセス許可に対する同意の付与と管理」を参照してください。
アクセス許可のMicrosoft Entra ID
Microsoft Graph を使用すると、開発者はorganizationの Microsoft 365 の情報とデータにアクセスできますが、適切なMicrosoft Entra IDのアクセス許可を使用する必要があります。 アプリは、これらのアクセス許可を事前に宣言し、管理者は、アプリが情報にアクセスする前に、これらのアクセス許可に同意する必要があります。 Teams アプリでこのようなアクセス許可に管理者の同意を与えた場合、組織のすべての許可されたユーザーがアプリを使用し、アプリが組織の情報にアクセスできるようにします。 これらのアクセス許可は、Microsoft Entra ID ポータルで定義されます。
アプリ開発者は、アプリが動作するために必要な情報を取得できるように、さまざまな Graph API から適切なアクセス許可を選択します。 これらのアクセス許可に同意を付与する前に、アプリによって要求された特定のアクセス許可を表示できます。 これは、アプリのアクセス許可に同意を付与することの影響を評価するのに役立ちます。 Microsoft Entra IDアクセス許可を表示するには、次の手順に従います。
Teams 管理センターにアクセスし、[ Teams アプリ>管理アプリ] ページを 開きます。
必要なアプリを検索し、その名前を選択してアプリの詳細ページを開きます。
[ アクセス許可 ] タブを選択し、[ アクセス許可と同意の確認] を選択します。
ダイアログで、アプリに必要なアクセス許可を表示します。 ダイアログで使用できる情報の詳細については、 同意プロンプトで使用可能な情報を参照してください。
使用可能なすべてのアクセス許可の完全な一覧については、「 Microsoft Graph のアクセス許可リファレンス」を参照してください。
リソース固有の同意アクセス許可
Teams のリソースには、チーム、チャット、またはユーザーを指定できます。 これらのアクセス許可を使用すると、アプリは特定のリソースのみの情報にアクセスできます。 RSC アクセス許可を使用すると、アプリは組織全体の情報へのアクセスを要求する必要がないため、そのアクセス範囲を制限できます。 これらの RSC アクセス許可は、アプリのマニフェスト ファイルで定義されます。 これらのアクセス許可に同意できるのは、リソースにアクセスできるユーザーのみです。 開発者は、アプリ マニフェスト ファイル内のアプリ自体でこれらのアクセス許可を定義します。
RSC アクセス許可を使用すると、ユーザーはスコープ固有の情報についてアプリに同意できます。 このような同意により、アプリはチームまたはチャットの情報にのみアクセスして変更できます。 このようなアプリは、追加されていないチャットやチームの情報にアクセスできません。 RSC アクセス許可の例には、チャネルの作成および削除、チームの設定の取得、チャネル タブの作成および削除があります。
RSC のアクセス許可は、アプリのアクセス許可のスコープを、組織全体の情報にアクセスできる組織全体の Graph アクセス許可ではなく、特定のリソースに制限します。 RSC アクセス許可を適用できるリソースは、チャットと会議、チームとチャネル、ユーザーです。
RSC のアクセス許可は、Microsoft Entra IDではなく、アプリ マニフェストで定義されます。 チームにアプリを追加するときに、RSC アクセス許可に同意を付与します。 詳細については、「リソース固有の同意 (RSC)」を参照してください。
アプリの RSC アクセス許可を表示するには、次の手順に従います。
- Teams 管理センターにアクセスし、[ Teams アプリ>管理アプリ] に移動します。
- 目的のアプリを検索し、アプリ名を選択してアプリの詳細ページに移動し、[ アクセス許可 ] タブを選択します。
- [ リソース固有の同意 (RSC) アクセス許可] で、アプリによって要求された RSC アクセス許可を確認します。
Teams でのアプリの機能
開発者は、Teams アプリを作成するときに、開発フレームワークで定義されているいくつかの機能を使用します。 これらの機能は、アプリで使用できる高度な機能です。 たとえば、アプリには、ユーザーと会話するボットを含めることができます。 アプリが機能を使用すると、いくつかの基本的な特権が自動的に付与されます。 たとえば、ボットを含むアプリがユーザーに許可されている場合、ボットはメッセージを送受信できます。 これらの特権は、アプリ開発者がアプリに追加した機能に基づいてアプリに存在し、有効にするために同意を必要とするアクセス許可ではありません。 開発者はこれらのアクセス許可を明示的に定義しませんが、開発者がアプリ機能をビルドすると、これらのアクセス許可が暗黙的に追加されます。
管理者は、Teams アプリを管理しますが、その機能は管理しません。 Teams アプリには、 アプリが主要なユース ケースを実行し、いくつかのタスクを実行できるようにする機能があります。 機能は SDK によって提供され、アプリのインストール時に同意が暗黙的に示されます。 機能に関連付けられているアプリで実行できるタスクは、管理者の同意を必要とするアクセス許可とは異なります。管理者は、アプリでできることと、次の機能に基づいてユーザーと対話する方法を検討する必要があります。
注意
アプリが複数のユース ケースに対応する複雑なアプリでない限り、アプリは以下のすべての機能を使用しない場合があります。 アプリで実行できるタスクは、アプリ開発者が使用する機能によって異なります。
ボットおよびメッセージングの拡張機能
次の種類のユーザー操作、必要なアクセス許可、ボットとメッセージング拡張機能によるデータ アクセスについて検討します。
ボットは、ユーザーからメッセージを受信し、それらに返信できます。 ボットは、ユーザーがその名前でボットを明示的にメンションするチャットでのみメッセージを受信します。 このデータは、企業ネットワークを離れます。
ユーザーがボットにメッセージを送信すると、ボットはユーザーに直接またはプロアクティブなメッセージをいつでも送信できます。
一部のボットはメッセージのみを送信します。 これらは通知専用ボットと呼ばれ、ボットは会話エクスペリエンスを提供しません。
チームに追加されたボットは、チーム内のチャネルの名前と ID の一覧を取得できます。
チャネル、個人用チャット、またはグループ チャットで使用する場合、アプリのボットはチーム メンバーの基本的な ID 情報にアクセスできます。 情報には、名、姓、ユーザー プリンシパル名 (UPN)、電子メール アドレスが含まれます。
アプリのボットは、ボットと対話していない場合でも、チーム メンバーに直接またはプロアクティブなメッセージを送信できます。
ボットであるアプリの設定と機能に応じて、個人用チャットでのみファイルを送受信できます。 グループ チャットやチャネルではサポートされていません。
ボットは、ボットが追加されるチーム、またはボット アプリを追加するユーザーにのみアクセスできます。
ユーザーがボットと会話するとき、ボットがユーザーの ID を格納している場合、ユーザーのダイレクト メッセージはいつでも送信できます。
必要に応じて、ユーザーまたは管理者がボットをブロックできます。 Microsoft は、ストアからボットを削除することもできます。 アプリの検証と検証チェック により、Teams ストアで高品質のアプリを使用でき、ボットがユーザーをスパムしないようにします。
ボットは、アプリが追加されたチーム メンバーの基本的な ID 情報を取得して格納したり、個人またはグループ チャットの個々のユーザーに対して保存したりできます。 これらのユーザーに関する詳細情報を取得するには、ボットがMicrosoft Entra IDにサインインする必要があります。
ボットは、チーム内のチャネルの一覧を取得して格納できます。 このデータは、企業ネットワークを離れます。
既定では、ボットはユーザーに代わって行動することはできませんが、ボットはユーザーにサインインを求めることができます。ユーザーがサインインするとすぐに、ボットには他のタスクを実行できるアクセス トークンがあります。 タスクは、ボットとユーザーがサインインする場所によって異なります。ボットは、
https://apps.dev.microsoft.com/に登録されたMicrosoft Entra アプリであり、独自のアクセス許可のセットを持つことができます。ファイルがボットに送信されると、ファイルは企業ネットワークを離れます。 ファイルの送受信には、ファイルごとにユーザーの承認が必要です。
ボットは、ユーザーがチームに追加または削除されるたびに通知されます。
ボットには、ユーザーの IP アドレスやその他の参照元情報は表示されません。 すべての情報は Microsoft から提供されています。 (1 つの例外があります。ボットが独自のサインイン エクスペリエンスを実装している場合、サインイン UI にはユーザーの IP アドレスと参照元情報が表示されます)。
一方、メッセージング拡張機能では、ユーザーの IP アドレスと参照元情報を確認できます。
注意
- ボットに独自のサインインがある場合、ユーザーが初めてサインインすると、別の同意エクスペリエンスが発生します。
- ユーザーは、アプリで使用できる
botIdでアプリを検索できます。 ユーザーはアプリ名を表示できますが、そのようなボットと対話することはできません。
タブ
タブは、Teams 内で実行中の Web サイトです。 会議、チャット、またはチャネルのタブとして使用できます。
タブのユーザー操作またはデータ アクセスの種類を次に示します。
ブラウザーまたは Teams でタブを開くユーザーはまったく同じです。 Web サイト自体は、organizationの情報に単独でアクセスできません。
タブには、現在のユーザーのサインイン名と UPN、現在のユーザーのMicrosoft Entra オブジェクト ID、存在する Microsoft 365 グループの ID (チームの場合)、テナント ID、ユーザーの現在のロケールなど、実行されているコンテキストも取得されます。 ただし、これらの ID をユーザーの情報にマップするには、タブでユーザーを Microsoft Entra ID にサインインさせる必要があります。
コネクタ
コネクタは、外部システムでイベントが発生したときにチャネルにメッセージを投稿します。 コネクタに必要なアクセス許可は、チャネルにメッセージを投稿できることです。 コネクタのオプションのアクセス許可は、メッセージに返信するためのアクセス許可です。 一部のコネクタでは、アクション可能なメッセージがサポートされています。これにより、ユーザーは対象の応答をコネクタ メッセージに投稿できます。 たとえば、GitHub の問題に対する応答を追加したり、Trello カードに日付を追加したりします。 次の種類のユーザー操作、必要なアクセス許可、およびコネクタによるデータ アクセスについて検討します。
コネクタ メッセージを投稿するシステムは、誰に投稿しているか、メッセージを受け取るユーザーを知りません。 受信者に関する情報は公開されません。 Microsoft は実際の受信者であり、organizationではありません。 Microsoft は、チャネルへの実際の転記を行います。
コネクタがチャネルにメッセージを投稿する場合、データが企業ネットワークから離れることはない。
アクション可能なメッセージをサポートするコネクタには、IP アドレスと参照元の情報も表示されません。この情報は Microsoft に送信され、以前にコネクタ ポータルで Microsoft に登録された HTTP エンドポイントにルーティングされます。
コネクタがチャネル用に構成されるたびに、そのコネクタ インスタンスの一意の URL が作成されます。 そのコネクタ インスタンスが削除された場合、URL は使用できなくなります。
コネクタ メッセージに添付ファイルを含めることはできません。
コネクタ インスタンス URL は、シークレットまたは機密として扱う必要があります。 URL を持つすべてのユーザーは、その URL に投稿できます。 必要に応じて、チーム所有者はコネクタ インスタンスを削除できます。
必要に応じて、管理者は新しいコネクタ インスタンスの作成を禁止し、Microsoft はコネクタ アプリのすべての使用をブロックできます。
送信 Webhook
チーム所有者またはチーム メンバーは、送信 Webhook を作成します。 送信 Webhook は、ユーザーからメッセージを受信し、それらに返信できます。 次の種類のユーザー操作、必要なアクセス許可、送信 Webhook によるデータ アクセスを検討します。
送信 Webhook はボットに似ていますが、特権はボットより少なくなります。 ボットと同様に、明示的にメンションする必要があります。
送信 Webhook が登録されると、シークレットが生成されます。これにより、送信 Webhook は、送信者が悪意のある攻撃者ではなく、Microsoft Teams であることを確認できます。 このシークレットはシークレットのまま維持する必要があります。アクセス権を持つすべてのユーザーは、Microsoft Teams になりすますことができます。 シークレットが侵害された場合は、送信 Webhook を削除して再作成し、新しいシークレットを生成してください。
シークレットを検証しない送信 Webhook を作成することはできますが、そうしないことをお勧めします。
メッセージの受信と返信以外に、送信 Webhook は多くのことを行うことはできません。たとえば、メッセージをプロアクティブに送信できず、ファイルを送受信できず、メッセージの受信と返信以外にボットが行うことができる操作を実行することはできません。