アプリケーションのアクセス許可戦略の開発

  • [アーティクル]

ゼロ トラスト原則を使用して開発する方法については、「リソースにアクセスするための承認の取得」と「委任されたアクセス許可戦略の開発」に関するページを確認した後、この記事を参照してください。 Microsoft ID プラットフォームを使用してアプリケーションを認証および承認し、アクセス許可と同意を管理する場合は、資格情報管理に対するアプリケーションのアクセス許可アプローチを定義します。

ユーザーが関与していない場合、アプリケーションには、アプリケーションの特定のユーザーに付与されているのと同じアクセス許可が常に付与されるため、有効なアクセス許可モデルはありません。

  • アプリは、アクセス許可を要求しているアプリであることを証明します。 アプリケーションは、次のいずれかのメソッドで独自の ID を証明します。

  • アプリには常に事前に管理者の同意が必要です。 アプリケーションは、.default スコープを使用してこのアクセス許可を要求します。 管理者がアプリケーションに割り当てるアクセス許可を要求します。 特定のスコープの名前付けに関係なく、既定ではこれらのアクセス許可はすべてのユーザーに適用されます。

  • ユーザーのトランス機能。 既定では、User.ReadWrite.All により、Calendar.Read であってもアプリケーションですべてのユーザー プロファイル を更新できます。 アプリケーションのアクセス許可として、アプリケーションはテナント内のすべてのユーザーのカレンダーを読み取ることができます。

  • アプリに付与されるアクセス許可は、常に使用されるアクセス許可です。 委任されたアクセス許可とは異なり、アプリケーションのアクセス許可は、特定のユーザーが実行できることによって制限されません。

アプリケーションのアクセス許可の制限

アプリケーションをグローバル アクセス未満に制限する方法は 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 年など) を使用し、期限切れにならないようにします。

  • 証明書とシークレットを定期的にロールオーバーして、アプリケーションで回復性を構築し、緊急ロールオーバーによる停止を回避します。

次のステップ