Azure Spring Apps ランディング ゾーン アクセラレータの ID とアクセス管理

  • [アーティクル]

この記事では、Azure Spring Apps でユーザーを認証し、ワークロード リソースへの必要なレベルのアクセス権をユーザーに付与する、設計上の考慮事項とレコメンデーションについて説明します。

一元化されたプラットフォーム チームとアプリケーション チームは、次の内容を十分に理解している必要があります。

  • アプリケーション ランディング ゾーンにデプロイされた Azure Spring アプリ ワークロードへのアクセスを必要とするチームはどれか。
  • ユーザーのロールと責任、およびアクセスが必要なのは誰か。
  • それらの責任を果たすために必要な最小限の特権レベル。

プラットフォーム設計の情報について、詳しくは「Azure の ID 管理とアクセス管理の設計領域」をご覧ください。

ワークロード所有者はこれらのベスト プラクティスに従い、アプリケーション リソースが組織のセキュリティやガバナンスの境界に違反しないようにします。 目標は、デプロイされた Azure Spring アプリとワークロードの関連リソースがセキュリティで保護され、許可されているユーザーのみがアクセスできるようにすることです。 これらのプラクティスに従うと、機密データを保護し、アプリとそのリソースの誤用を防げます。

設計上の考慮事項

  • アプリケーションから他のサービスへのアクセス。 アプリケーションは、ワークロードの一部であるバックエンド サービスに接続するときに、アプリケーション自体を認証する必要があります。 この認証により、未承認のアクセスからサービスが保護されます。 資格情報の格納と管理のオーバーヘッドを防ぐために、Microsoft Entra ID 機能の使用を検討してください。

  • アプリケーションへのアクセス。 ユーザーは、パブリック インターネット経由でアプリケーションに要求を送信する場合があります。 または、プライベートまたはオンプレミスのネットワークから要求が送信される場合があります。 どちらの場合も、クライアント証明書に基づいて、または Microsoft Entra ID を使用してアクセスを認証する必要があります。

    アプリ間の呼び出しを起動するサービス検出メカニズムのテクノロジ オプションを検討してください。 オプションは、Azure Spring Apps レベルにより異なります。

  • リソースへのオペレーター アクセス。 さまざまな責任を持つチーム メンバーがワークロードにアクセスする可能性があります。 たとえば、次のようなユーザーにアクセス権を付与する必要がある場合があります。

    • 運用アクセスが必要なプラットフォーム チーム メンバー。
    • アプリケーションを開発するアプリケーション チーム メンバー。
    • コードとしてのインフラストラクチャ (IaC) でワークロードをデプロイして構成するパイプラインを、ビルドしてリリースする DevOps エンジニア。
    • イシューをトラブルシューティングするサイト信頼性エンジニア。

    アクセスの目的に基づいて、ユーザーに提供する制御レベルを決定します。 最小特権の原則から始めてください。 RBAC ロール割り当てにより、ユーザーに自分の責任に対して適切な権限セットを与え、境界を維持できます。 カスタム ロールを作成する前に、組み込みの RBAC ロールを検討してください。

  • 構成データのアクセス。 Azure Spring Apps のサービス レベル (Basic/Standard または Enterprise) の選択に基づいて、構成サーバーのオプションを決定する必要があります。

    Basic の場合は、サーバー側とクライアント側のサポートを検討してください。 構成サーバー ファイルを格納するには、Azure DevOps、GitHub、GitLab、Bitbucket などの分散システムで外部化された構成を選びます。

    パブリック リポジトリまたはプライベート リポジトリを使用し、その認証メカニズムを選べます。 Azure Spring Apps では、基本的なパスワードまたはトークン ベースの認証と SSH がサポートされています。

    Enterprise の場合、Application Configuration Service for VMware Tanzu の使用を検討してください。これは、1 つ以上の Git リポジトリに定義されたプロパティから設定された Kubernetes ネイティブの ConfigMap リソースを管理できるようにします。

設計の推奨事項

マネージド ID

アプリケーションのマネージド ID を使用して、Microsoft Entra ID を介して認証されるようにします。 すべてのサービスが Microsoft Entra ID のこの機能をサポートしているわけではありません。 詳しくは、「Microsoft Entra 認証をサポートする Azure サービス」をご覧ください。

ユース ケースに適したマネージド ID の種類を決定します。 管理のしやすさとのトレードオフを考慮してください。 たとえば、アプリケーションが複数のリソースにアクセスする必要がある場合は、ユーザー割り当てマネージド ID が推奨されます。 ただし、アクセス許可をアプリケーションのライフサイクルに関連付ける場合は、システムマネージド ID の方が適している可能性があります。

詳細については、「システムまたはユーザー割り当てのマネージド ID を選択する」を参照してください。

組み込みの Azure RBAC ロールを使用して、マネージド ID に必要なアクセス許可の管理を簡略化します。

  • Azure Spring Apps に独自のマネージド ID を使用します。
  • システム割り当てとユーザー割り当てのマネージド ID を別々に使用する。 詳細については、「マネージド ID を使用しているときのベスト プラクティス」を参照してください。
  • Microsoft Entra ID で Privileged Identity Management を使用します。

インターネット通信をセキュリティで保護する

  • 証明機関によって発行された証明書、拡張検証証明書、またはワイルドカード証明書を使用します。
  • 自己署名証明書は、運用前環境でのみ使用します。
  • Azure Key Vault から安全に証明書を読み込みます。

ロール ベースのアクセス制御 (RBAC)

  • カスタム ロールの作成を検討してください。 既定のロールに対して既存のアクセス許可の変更が必要な場合は、最小特権の原則に従ってください。
  • キー、シークレット、証明書、およびアプリケーション構成に対して拡張セキュリティ ストレージを選択します。
  • 自動デプロイのために、CI/CD パイプラインからのデプロイに最低限必要なアクセス許可を持つサービス プリンシパルを設定します。
  • アプリケーション コンソール、システム ログ、イングレス ログ、ビルド ログ、コンテナー イベント ログの診断ログを有効にします。 これらの詳細なログを使用して、アプリの問題を診断し、アクセス要求を監視できます。 これらのログを有効にすると、Azure Monitor アクティビティ ログからサブスクリプション レベルでイベントの分析情報を得られます。

次のステップ

ネットワーク トポロジと接続