Azure AD アプリ管理メソッド ポリシーにより、アプリケーションのセキュリティのポスチャが強化される

洗練された、忍耐強く計画され、実行された攻撃に関するニュースを聞くのは一般的ですが、全体像を見ると、それらは主に例外です。実際、多くの侵害は、単一の重要な要素(人的要因)と、その固有の資質の1つである怠惰のためだけに可能です。開発者は確かにここで例外ではありません。アプリケーションの「秘密」を保存することであっても、利便性のためにベストプラクティスやコーディング基準を無視することは、人生の事実となっています。

ある 最近の研究 何千ものAPIキーと暗号秘密がパブリックコードリポジトリに流出し、この問題がどれほど広範囲に及んでいるかを示しています。これは、最も経験の浅い「スクリプトキディ」でさえも利用できる攻撃ベクトルを表しています。

マイクロソフト 365 は免除されません。何年もの間、人々は自動化されたタスクとワークフローの資格情報をプレーンテキストで保存してきました。多要素認証、条件付きアクセス ポリシー、およびセキュリティの既定値の出現は、この問題をある程度解決するのに役立ちます。管理者は、ユーザーのコンテキストで実行されるタスクに対して最新の認証方法を適用するツールを持っていますが、サービス プリンシパル/アプリケーションの前の作業は、これまでのように、同じコントロールの対象ではありません。

この問題に対処するために、マイクロソフトは、一連の機能をリリースする準備ができています。この記事では、セット内の機能の 1 つである Azure AD アプリケーション認証方法ポリシーについて説明します。

Azure AD アプリ認証メソッド ポリシーとは何ですか?

つまり、Azure AD アプリの認証方法ポリシーは、テナント内のアプリケーション およびサービス プリンシパル オブジェクトによって使用される認証方法を制御するための構成オブジェクトです。ポリシーは、アプリケーション作成プロセスのどの側面も、アプリケーションに付与されたアクセス許可に影響を与えるものではなく、すでに使用可能なさまざまなコントロールによってカバーされます。

アプリ認証方式ポリシーには、すべてのアプリケーションおよびサービス プリンシパル オブジェクトをカバーする既定のテナント全体のポリシー (有効にした場合) と、管理者が特定のオブジェクトを作成して割り当てることができるカスタム ポリシーのセットの 2 種類があります。現在利用可能な制限の種類には、次のようなものがあります。 パスワード追加を使用すると、新しいクライアント シークレットの作成が防止され、 パスワードライフタイムを指定すると、クライアント シークレットの有効期間の上限が制限されます。どちらの種類の制限でも、適用日を追加で構成し、指定した日時以降に作成されたオブジェクトのみにスコープを制限できます。

続きを読む: Azure AD でのパスワードなし認証の実現

既定のアプリ認証メソッド ポリシーの構成

現在、アプリ認証メソッドポリシーは Graph API を使用して構成されています。既定のテナント全体のポリシーは、各テナントで事前に作成されます。ただし、この設定は無効になっており、制限は構成されません。現在の構成を確認するには、 /ベータ/ポリシー/デフォルトApp管理ポリシー グラフ API エンドポイント、 ポリシー.読み取り.すべて アクセス許可は十分です。図 1 は、グラフ エクスプローラー ツールを使用したテナント全体のポリシーの既定の状態を示しています。

単一の場合のみ ポリシーを設定します。 オブジェクトはテナントに存在できます。ザ アプリケーションの制限 そして サービスプリンシパルの制限 セクションでは、ディレクトリ内のすべてのアプリケーションまたはサービス プリンシパル オブジェクトに適用される制限を定義します。どちらのタイプも、 構成 オブジェクトを含むオブジェクトは、 パスワード資格情報の構成 オブジェクトを使用し、制限と関連プロパティを詳細に説明します。

設定を更新するには、Graph API を使用してポリシーにパッチを適用します。この操作には、 アプリケーション構成 許可。図 2 は、デフォルト ポリシーを有効にするコマンドを示し、2021 年 8 月以降に作成されたすべてのアプリケーション オブジェクトに対して新しいパスワード資格情報 (クライアント シークレット) が追加されないようにします。

既定のポリシー構成のテスト

実行後PATCH 要求を適用するには、ポリシー設定を確認して変更を確認する必要があります。図 3 では、テナント全体のポリシーが、種類の制限で有効になっていることがわかります。 パスワード追加 2021 年 8 月以降に作成されたアプリケーション オブジェクトに対して構成されます。この構成では、新しく作成されたアプリケーションにクライアント シークレットが追加されるのを防ぐことができます。同時に、このポリシーは、サードパーティ製アプリ (サービス プリンシパル) に影響を与えません。 サービスプリンシパルの制限*:

*もう一つ興味深いのは、図 1 に示されている “null" 値と比較して、ランダムな GUID “id" 値が生成されたポリシーです。

では、ポリシーはアプリにどのような影響を与えるのでしょうか。ポリシーには施行日があるため、この日付より前に作成されたアプリには適用されません。新しく作成されたアプリケーションの場合、ポリシーはクライアント シークレットの追加をブロックします。代わりに、開発者はより安全な証明書資格情報メソッドを使用する必要があります。ブロックには、Azure AD 管理ポータルの警告バナーによってフラグが付き、 新しいクライアント シークレット ボタンが無効になります:

アプリ認証メソッド管理ポリシーで細かく設定する

既定のテナント全体のポリシーは、組織内のすべてのアプリケーションおよびサービス プリンシパル オブジェクトに適用されます。これは、基本的なレベルのコンプライアンスを確保するための素晴らしい方法です。ただし、場合によっては、より詳細なアプローチが必要になる場合があります。要件に対応するために、Microsoft はカスタムの “リソース" ポリシーをサポートしており、特定のアプリまたはサービス プリンシパルに割り当ててテナント全体のポリシーを上書きできます。

カスタム ポリシーは、既定ではテナントに存在しません。 /ベータ/ポリシー/アプリ管理ポリシー エンドポイント。カスタム ポリシーを作成するには、POST 要求を /ベータ/ポリシー/アプリ管理ポリシー エンドポイント, アプリケーション構成 権限。要求には、以下を含める必要があります。 表示名, 形容 そして 制限 要素を使用し、後者は強制するコントロールを定義します。たとえば、図 5 は、Graph Explorer を使用して、クライアント シークレットに許可される最大有効期間に制限を設定した新しいポリシーを作成する方法を示しています。

作成後のカスタム ポリシーは、プレースホルダに過ぎません。制限を適用するには、ポリシーを特定のオブジェクトに割り当てる必要があります。アプリケーション または/サービスプリンシパル エンドポイント, を参照して、 ポリシーId (図 5 は、ポリシーの作成に対する応答の一部として示されています) ポリシーを管理します。 たとえば、新しく作成したポリシーをアプリケーション オブジェクトに割り当てる アプリ1を使用するには、図 6 に示すコマンドを使用します。

ポリシーを割り当てた後、次の 証明書と秘密 Azure AD 管理センターでアプリのページ (図 7)カスタム ポリシーはテナント全体のポリシーよりも優先されるため、ここで最初に気付くのは、新しいクライアント シークレットを追加できることです。

ただし、ポリシーの上に表示されるポリシーの制限に従って、シークレットの有効期間を設定することしかできません。 クライアント シークレットの追加 硝子。ポリシーと競合する値はグレー表示されます。

その他の詳細と概要

ここまでは、アプリ認証メソッド ポリシーがサービス プリンシパル オブジェクトに適用される方法については説明していません。組織で使用するアプリケーションの大半はサードパーティ製のアプリケーションであり、ディレクトリ内のサービス プリンシパル オブジェクトを介して表されるため、これは重要なシナリオです。

のセットの定義 サービスプリンシパルの制限 テナント全体のポリシー内で、またはカスタム ポリシーを作成し、必要に応じてサービス プリンシパル オブジェクトに割り当てることで、組織はサードパーティアプリケーションで使用される認証方法の品質をある程度制御できます。次に、ISV がベストプラクティスをより速く採用できるようになります。

アプリケーション認証方式ポリシーは優れた機能ですが、パブリック プレビューに残っている点に注意してください。現時点では、すべての設定は Graph API を介して行われていることを既に述べましたが、これは一部の管理者に対して後ずれになる可能性があります。ただし、機能が GA に到達すると、Azure AD 管理センターでこれらのコントロールを構成できる必要があります。

今後、マイクロソフトはコントロールを追加し、現在のバージョンの機能の限定的な範囲に対処する予定です。これらのコントロールには、有効期間や発行者の制限など、キー資格情報 (証明書) の制限が含まれる可能性があります。その他のアイデアは、特定のアプリケーションで構成可能な資格情報の数を制限する機能や、複数のアプリケーション間で資格情報の再利用を防止するなど、よりエキゾチックなものなど、浮動しています。

つまり、アプリケーション認証方式ポリシーは、Microsoft 365 のお客様がアプリケーション資格情報を管理するためのベスト プラクティスを遵守するとともに、ISV にも同じことを行う必要があるとのプレッシャーを強いるのに役立ちます。今後は、多くの組織で実施される標準的な構成に変わると予想されます。

また、これはマイクロソフトがこの分野で起動することを計画している複数の機能の1つに過ぎないことにも言及する価値があります。これには、既に利用可能な アプリガバナンス、サービス プリンシパルのサインイン、SharePoint Online でのスコープのアクセス許可のサポート、クライアント資格情報フローの条件付きアクセスのようなコントロールなど。

これらの機能の大部分は長く延滞していると主張できますが、少なくとも Azure AD 統合アプリケーションに関しては、脅威の状況を改善する上での重要性と影響を誇張することはできません。