アプリケーションIDとアクセス管理
この記事では、アプリケーションの所有者と開発者がクラウドネイティブアプリケーションのidとアクセス管理を設計するために使用できる考慮事項と推奨事項について説明します。
チームがクラウドネイティブアプリケーションを移行または作成する場合は、アプリケーションの認証とアクセスの要件を考慮する必要があります。 これらの要件により、ユーザーがアプリケーションに対して認証する方法と、アプリケーションリソースが相互に認証する方法が決まります。たとえば、webアプリケーションがSQLデータベースにアクセスする場合などです。
プラットフォームの自動化とDevOpsの設計領域では、アプリケーションチームがワークロードをサブスクリプションの販売に移行することをお勧めします。 サブスクリプション販売プロセスの一環として、アプリケーションチームは、適切なサブスクリプションを作成できるように、プラットフォームチームにIDとアクセスの要件を提供する必要があります。 アプリケーション所有者は、個々のアプリケーションのIDとアクセスの管理を担当します。 プラットフォームチームが提供する一元化されたサービスを使用して、アプリケーションを管理する必要があります。
設計上の考慮事項
アプリケーションへの不正アクセスのリスクを軽減するには、次の考慮事項を設計に組み込みます。
OAuth 2.0、OpenID Connect、JSON Webトークン (JWT) 、SAML (Security Assertion Markup Language) など、いくつかの認証と承認の標準があります。 アプリケーションに使用する認証と承認の標準を決定します。
プラットフォームチームにアプリケーションランディングゾーンを要求する場合は、次の質問をすることで、適切なサブスクリプションを作成してもらうことができます。
エンドユーザーはどのようにしてアプリケーションを認証し、アプリケーションにアクセスしますか。
アプリケーションで使用されるリソースとサービスに対してロールベースのアクセス制御 (RBAC) のアクセス許可が必要なユーザー。
既存の組み込みロールは、コントロールプレーンとデータプレーンアクセスの両方のRBACアクセス要件に対応していますか。または、新しいカスタムロールを作成する必要がありますか。
プラットフォームチームは、アプリケーションで問題を引き起こす可能性のあるコンプライアンスポリシーを実装しましたか。
どのアプリケーションコンポーネントが相互に通信する必要がありますか。
プラットフォームランディングゾーンにデプロイされている共有リソース (Microsoft Entra Domain Servicesなど) にアクセスするための要件はありますか。
Azure Key VaultとマネージドID
パブリッククラウドリソースのセキュリティ侵害は、多くの場合、コードやその他のテキストに埋め込まれている資格情報の漏えいによって発生します。 マネージドIDとKey Vaultを使用してプログラムによるアクセスを実装し、資格情報の盗難のリスクを軽減することができます。
アプリケーションまたはワークロードで資格情報を安全に格納するサービスが必要な場合は、Key Vaultを使用してシークレット、キー、証明書を管理できます。
コードに資格情報が含まれないようにするために、Azure VMでマネージドIDを使用して、Microsoft Entra ID認証をサポートする任意のサービスに対して認証を行うことができます。 詳細については、 「VMでAzureリソースのマネージドIDを使用してアクセストークンを取得する」 を参照してください。
マネージド ID は、アプリケーションとリソースが Microsoft Entra ID 認証をサポートするリソースに接続するときに使用する、自動的に管理される ID プリンシパルを提供します。 アプリケーションは、マネージドIDを使用して、資格情報を管理することなくMicrosoft Entra IDトークンを取得できます。
システムが割り当てた、またはユーザーが割り当てたマネージド ID を使用できます。
サービス プリンシパルとマネージド ID が Azure リソースにアクセスする方法はよく混同されます。 2つの違いを理解するには、 「サービスプリンシパルの明確化—マネージドID」を参照してください。
可能な場合は、サービスプリンシパルとMicrosoft Entra IDアプリの登録を使用するのではなく、マネージドIDを使用して認証をサポートします。 サービスプリンシパルとアプリの登録を作成するには、アプリケーション管理者またはアプリケーション開発者のRBACロールが必要です。 これらの特権ロールは、通常、プラットフォームチームまたはIDチームに割り当てられます。 マネージドIDを使用すると、プラットフォームチームがアプリケーションチームのサービスプリンシパルとアプリの登録を作成する必要がなくなります。
マネージド ID を使って、Microsoft Entra 認証をサポートする任意のサービスの認証を受けることができます。 ただし、すべてのサービスで、他のサービスにアクセスするためのマネージドIDがサポートされているわけではありません。 一部のサービスでは、資格情報の保存が必要になる場合があります。 資格情報は安全に保存し、他のサービスとの資格情報の共有を避け、最小限の特権の原則に従う必要があります。 詳細については、 「マネージドIDを使用して他のサービスにアクセスできるAzureサービス」 を参照してください。
Azure仮想マシン (VM) でマネージドIDを使用して、Microsoft Entra ID認証をサポートする任意のサービスに対する認証を行うことができます。 詳細については、 「VMでAzureリソースのマネージドIDを使用してアクセストークンを取得する」 を参照してください。
マネージドIDを持つリソースをサブスクリプションとリージョン間で移動するには制限があります。 たとえば、データ主権上の理由から、リソースの合併、取得、または本国送還のために、サブスクリプション間またはリージョン間でリソースを移動する場合があります。
Azureリソースにユーザー割り当てIDまたはシステム割り当てIDがある場合、そのリソースを別のAzureサブスクリプションまたはリージョンに転送することはできません。 リソースを移動する前に、マネージドIDを削除する必要があります。 移動後に、マネージドIDを再作成してリソースに割り当てる必要があります。 詳細については、「新しいリソース グループまたはサブスクリプションへのリソースの移動」を参照してください。
サブスクリプションをあるディレクトリから別のディレクトリに移動した場合、マネージドIDは保持されません。 リソースを移動してから、マネージドIDを手動で再作成する必要があります。
ユーザーRBACロールの割り当てと同様に、マネージドIDにリソースへのアクセス権を付与するときは、最小限の特権の原則に従います。
外部ユーザー
外部ユーザー、顧客、またはパートナーがリソースにアクセスできるように設定するシナリオを評価できます。 これらのシナリオにMicrosoft Entra B2BまたはAzure Active Directory B2C (Azure AD B2C) の構成が含まれるかどうかを判断します。 詳細については、 「Microsoft Entra External IDの概要」 を参照してください。
設計の推奨事項
アプリケーションのIDとアクセスの管理を設計するときは、次の推奨事項を考慮してください。
OpenID Connect
アプリケーションチームが継続的インテグレーションと継続的デリバリー (CI/CD) パイプラインを使用してプログラムでアプリケーションをデプロイする場合は、Azureサービスに対するOpenID Connect認証を構成します。 OpenID Connectは、一時的な資格情報のないトークンを使用してAzureサービスに対する認証を行います。 詳細については、 「電源管理の使用」 を参照してください。
OpenID Connectがサポートされていない場合は、サービスプリンシパルを作成し、インフラストラクチャまたはアプリケーションコードをデプロイできるようにするために必要なアクセス許可を割り当てます。 詳細については、トレーニングモジュール 「サービスプリンシパルを使用してAzureデプロイパイプラインを認証する」 を参照してください。
属性ベースのアクセス制御
アクセスをさらに制限し、データへの不正アクセスを防ぐには、Azure Blob Storageなど、サポートされている場合は属性ベースのアクセス制御 (ABAC) を使用します。
仮想マシンへのアクセス
可能な場合は、Microsoft Entra ID IDを使用して、Azure仮想マシンへのアクセスを制御します。 ローカル認証の代わりにMicrosoft Entra IDを使用して、Microsoft Entra条件付きアクセス、監査ログ、Microsoft Entra多要素認証 (MFA) を利用して、仮想マシンへのアクセスを提供します。 この構成により、攻撃者が安全でないローカル認証サービスを悪用するリスクが軽減されます。 詳細については、 「Microsoft Entra IDとOpenSSHを使用してAzureのLinux仮想マシンにログインする」 および 「パスワードレスを含むMicrosoft Entra IDを使用してAzureのWindows仮想マシンにログインする」 を参照してください。
Microsoft ID プラットフォーム
開発者がクラウドネイティブアプリケーションを構築する場合、アプリケーションのIDプロバイダーとして開発者向けMicrosoft IDプラットフォームを使用する必要があります。 Microsoft IDプラットフォームは、OpenID Connect標準に準拠した認証サービスを提供します。開発者はこのサービスを使用して、次のような複数のIDタイプを認証できます:
Microsoft Entra ID を通じてプロビジョニングされる職場または学校アカウント
個人用 Microsoft アカウント (Skype、Xbox、Outlook.com)
Microsoft Entra IDを使用したソーシャルアカウントまたはローカルアカウント
Microsoft IDプラットフォームのベストプラクティスと推奨事項のチェックリストには、アプリケーションとMicrosoft IDプラットフォームを効果的に統合するためのガイダンスが記載されています。
マネージド ID
資格情報を使用する必要のないAzureリソース間のアクセスを有効にするには、マネージドIDを使用します。
さまざまな環境またはアプリケーション間で資格情報またはマネージドIDを共有しないでください。 たとえば、同じアプリケーションであっても、運用リソースと開発/テストリソースにIDを使用しないでください。 侵害されたテストインスタンスが運用データに影響を与える可能性を減らすために、アプリケーションのインスタンスごとに個別の資格情報を作成します。 また、資格情報を分離すると、不要になったときに資格情報を簡単に取り消すことができます。
マネージドIDを大規模に使用する必要がある場合は、各リージョンのリソースの種類ごとにユーザー割り当てマネージドIDを使用します。 この方法により、IDのチャーンを防ぐことができます。 たとえば、Azure Monitorエージェントでは、監視対象のAzure VMでマネージドIDが必要です。これにより、Microsoft Entra IDによって大量のIDが作成 (および削除) される可能性があります。 ユーザー割り当てマネージドIDを1回作成し、複数のVMで共有することができます。 この推奨事項を実装するには、Azure Policyを使用します。
Key Vault
Key Vaultを使用して、アプリケーションが使用するシークレット、キー、証明書を管理できます。
シークレット (データプレーン) および管理アクセス (コントロールプレーン) へのアクセスを管理するには、RBACを使用します。
Key Vaultへのアプリケーションアクセスを制御するには、マネージドIDを使用します。
各リージョンのアプリケーション環境(開発・試作・生産)ごとに個別のキーコンテナーを使用する必要があります。 RBACを使用して、シークレット、キー、証明書 (データプレーン操作) へのアクセスと、Key Vault (コントロールプレーン) へのアクセスを管理します。 アプリケーションシークレットを含むキーコンテナーをアプリケーションランディングゾーンにデプロイします。
Microsoft Entra アプリケーション プロキシ
Microsoft Entra IDを介してオンプレミス認証を使用するアプリケーションにリモートでアクセスするには、Microsoft Entraアプリケーションプロキシを使用します。 Microsoft Entraアプリケーションプロキシは、古い認証プロトコルを使用するアプリケーションを含む、オンプレミスのWebアプリケーションへの安全なリモートアクセスを提供します。 Microsoft Entra IDにシングルサインオンした後、ユーザーは外部URLまたは内部アプリケーションポータルを介してクラウドアプリケーションとオンプレミスアプリケーションの両方にアクセスできます。
Microsoft Entraアプリケーションプロキシは、単一インスタンスとしてMicrosoft Entra IDテナントに展開できます。 構成には、アプリケーション管理者またはグローバル管理者の特権を持つMicrosoft Entra IDロールが必要です。 組織でサブスクリプションの民主化をロール割り当てモデルとして使用している場合、アプリケーション所有者がMicrosoft Entraアプリケーションプロキシを構成するために必要なアクセス許可を持っていない可能性があります。 この場合、プラットフォームチームは、アプリケーション所有者のMicrosoft Entraアプリケーションプロキシを構成する必要があります。
十分なアクセス許可を持つCI/CDデプロイパイプラインを使用する場合、アプリケーション所有者はMicrosoft Graph APIを使用してMicrosoft Entraアプリケーションプロキシを構成できます。
アプリケーションでKerberosなどのレガシプロトコルを使用している場合は、アプリケーションランディングゾーンにMicrosoft IDプラットフォームサブスクリプションのドメインコントローラーへのネットワーク接続があることを確認します。
次のステップ
フィードバック
以下は間もなく提供いたします。2024 年を通じて、コンテンツのフィードバック メカニズムとして GitHub の issue を段階的に廃止し、新しいフィードバック システムに置き換えます。 詳細については、「https://aka.ms/ContentUserFeedback」を参照してください。
フィードバックの送信と表示