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