アプリケーションのアクセス許可戦略の策定
ゼロ トラストの原則を使用して開発を学習する場合は、「リソースにアクセスするための承認の取得」と「委任されたアクセス許可戦略の策定」を確認した後、この記事を参照してください。 Microsoft ID プラットフォームを使用してアプリケーションを認証および承認し、アクセス許可と同意を管理する場合は、資格情報管理に対するアプリケーションのアクセス許可アプローチを定義します。
ユーザーが関与していない場合、アプリケーションには常に割り当てられたアクセス許可が付与されるため、有効なアクセス許可モデルはありません。
アプリは、アクセス許可を要求しているアプリであることを証明します。 アプリケーションは、次のいずれかの方法で自分の ID を証明します:
- 証明書(最適なオプション)、または
- 高度なシークレット管理システム内のシークレット、または
- Azure でサービスを開発する場合は、Azure リソースのマネージド ID を使用し、次の「アプリケーション資格情報の管理」セクションを確認します。
アプリには常に事前に管理者の同意が必要です。 アプリケーションは、
.defaultスコープでこのアクセス許可を要求します。 管理者がアプリケーションに割り当てるアクセス許可を要求します。ユーザーのトランス機能。 既定では、
User.ReadWrite.Allでは、アプリケーションですべてのユーザーのプロファイルを更新できます。 アプリケーションのアクセス許可として、アプリケーションはテナント内のすべてのユーザーのプロファイルを読み取って更新できます。アプリに付与されるアクセス許可は、常に使用されるアクセス許可です。 委任されたアクセス許可とは異なり、アプリケーションのアクセス許可は、特定のユーザーが実行できることによって制限されません。
アプリケーションのアクセス許可を制限する
アプリケーションをグローバル アクセス未満に制限する方法は 3 つあります。
Microsoft Teams アプリには リソース固有の同意 (RSC) があり、アプリケーションは企業内のすべてのチームにアクセスするのではなく、特定のチームにアクセスできます。 RSC は、アプリで API エンドポイントを使用し、特定のリソースを管理できるようにする Microsoft Teams と Microsoft Graph API の統合です。 そのアクセス許可モデルを使用すると、Teams とチャットの所有者は、アプリケーションが Teams とチャットのデータにアクセスして変更することに同意できます。
Microsoft Exchange 管理者は、PowerShell スクリプトを使用して、特定のメールボックスへのアプリ アクセスを制限する Exchange アプリケーション ポリシーを作成できます。 特定のアプリケーションを
Calendar.ReadまたはMail.Readアクセスで特定のメールボックスに制限することができます。 これにより、たとえば、1 つのメールボックスのみを読み取ったり、1 つのメールボックスからのみメールを送信したりでき、社内のすべてのユーザーからメールを送信できない自動化を構築できます。SharePoint には、特定のスコープとして Sites.Selected があり、アプリケーションで SharePoint にアクセスするための詳細なアクセス許可を許可します。 他のアクセス許可の 1 つではなくアプリケーションの
Sites.Selectedを選択すると、既定では、アプリケーションで SharePoint サイト コレクションにアクセスできません。 管理者は、サイトのアクセス許可エンドポイントを使用して、アプリケーションに読み取り、書き込み、または読み取りと書き込みのアクセス許可を付与します。
アプリケーションの資格情報を管理する
資格情報の検疫により、アプリケーションは潜在的な侵害から迅速に回復することができます。 次のベスト プラクティスでは、ダウンタイムを回避し、正当なユーザーに影響を与えながら、検出と修復を実行するアプリケーションを開発する方法について説明します。 これらの推奨事項は、セキュリティ インシデントに対応するための準備における侵害想定のゼロ トラストの原則をサポートします。
コードと構成からすべてのシークレットを削除します。 Azure プラットフォームを使用している場合は、キー コンテナーにシークレットを配置し、Azure リソース用マネージド ID を使用してアクセスします。 セキュリティ侵害が発生した場合にシークレットローテーションを処理するコードの回復性を高めます。 IT 管理者は、アプリケーションを停止したり、正当なユーザーに影響を与えたりすることなく、シークレットと証明書を削除およびローテーションできます。
シークレットを管理するためのセキュリティで保護されたプロセスがない限り、クライアント シークレットの代わりに証明書を使用します。 攻撃者は、クライアント シークレットの安全性が低下し、漏えいしたシークレットの使用状況を追跡するのが困難であることを認識しています。侵害された場合は、証明書をより適切に管理および取り消すことができます。 シークレットを使用する場合は、セキュリティで保護されたタッチなしの展開とロールオーバー プロセスを構築または使用します。 有効期限が設定されているシークレット (1 年、2 年など) を使用し、期限切れにならないようにします。
証明書とシークレットを定期的にロールオーバーして、アプリケーションで回復性を構築し、緊急ロールオーバーによる停止を回避します。
次のステップ
- 「リソースにアクセスするための承認の取得」は、アプリケーション用にリソースのアクセス許可を取得するときにゼロ トラストを確保する最善の方法を理解するのに役立ちます。
- 「委任されたアクセス許可戦略の策定」は、アプリケーションのアクセス許可を管理するための最適なアプローチを実装し、ゼロ トラスト原則を使用して策定するのに役立ちます。
- 承認のベスト プラクティスは、アプリケーションに最適な承認、アクセス許可、および同意モデルを実装するのに役立ちます。
- 「管理者の同意が必要なアクセス許可を要求する」では、アプリケーションのアクセス許可に管理者の同意が必要な場合のアクセス許可と同意エクスペリエンスについて説明します。
- API 保護では、登録を通じて API を保護し、アクセス許可と同意を定義し、ゼロ トラストの目標を達成するためのアクセスを強制するためのベスト プラクティスについて説明します。
- 「ユーザーがいない場合にアプリケーション ID 資格情報を提供する」では、Azure リソース用マネージド ID が Azure 上のサービス (非ユーザー アプリケーション) に対するクライアント資格情報のベスト プラクティスである理由について説明します。