Azure 統合サービス ランディング ゾーン アクセラレータの ID とアクセス管理に関する考慮事項
この記事は、ID およびアクセス管理のための Azure ランディング ゾーンの設計領域に関する Azure ランディング ゾーンの記事で提供されているガイダンスに基づいています。 次の記事で提供されるガイダンスは、Azure 統合サービス (AIS) のデプロイに固有の ID とアクセス管理に関連する設計上の考慮事項と推奨事項を特定するのに役立ちます。 AIS がミッション クリティカルなプラットフォームをサポートするためにデプロイされている場合、Azure ランディング ゾーンの設計領域に関するガイダンスも設計に含める必要があります。
ID およびアクセス管理 (IAM) の概要
この記事の目的上、ID およびアクセス管理 (IAM) は、Azure 内でリソースをデプロイまたは保守するために使用できる認証と承認のオプションを指します。 実際には、Azure portal または Resource Manager API を使用してリソースを作成、更新、削除、管理するためのアクセス許可を持つ ID の特定が含まれます。
IAM は、サービスを呼び出してアクセスできる ID を定義するエンドポイント セキュリティとは別の考慮事項です。 エンドポイント セキュリティについては、このシリーズの別のセキュリティに関する記事を参照してください。 ただし、2 つの設計領域が重複する場合があります。Azure 内の一部のサービスでは、エンドポイントへのアクセスは、リソースへのアクセスを管理するために使用されるのと同じ RBAC 制御によって構成されます。
設計上の考慮事項
職務の分離と運用効率を考慮して、デプロイするリソースの Azure リソース管理の境界を決定します。
チームで実行するよう求める Azure の運用および管理アクティビティを確認します。 デプロイする AIS リソースとその使用方法を検討します。 組織内での役割の最適な配分を決定します。
設計の推奨事項
統合サービス リソースにマネージド ID を使用します。この推奨事項の詳細な説明については、このシリーズのセキュリティに関する記事を参照してください。
統合サービス リソースへの認証には Microsoft Entra ID を使用します。
組織内のロールに必要なアクセスのレベルを検討し、ロール別の最小特権の原則を適用します。 これらのロールには、プラットフォーム所有者、ワークロード所有者、Devops エンジニア、システム管理者などを含めることができます。
最小特権の原則を使用して、AIS アプリケーションを管理および保守するために必要なロールを検討します。 この件に関する質問を以下に示します。
Application Insights、Log Analytics、ストレージ アカウントなどのソースからログ ファイルを表示する必要があるのは誰ですか?
誰もが元の要求データ (機密データを含む) を表示する必要がありますか?
元の要求データはどこから表示できますか (たとえば、会社のネットワークからのみ)?
ワークフローの実行履歴を表示できるのは誰ですか?
失敗した実行を再送信できるのは誰ですか?
API Management サブスクリプション キーにアクセスする必要があるのは誰ですか?
Service Bus トピックまたはサブスクリプションの内容を表示できる、またはキュー/トピックメトリックを確認できるのは誰ですか?
Key Vault を管理できる必要があるのは誰ですか?
Key Vault でキー、シークレット、証明書を追加、編集、または削除できる必要があるのは誰ですか?
Key Vault でキー、シークレット、または証明書を表示して読み取れる必要があるのは誰ですか?
既存の組み込み Microsoft Entra ロールとグループは、特定した要件に対応しますか?
アクセスを制限するため、または組み込みのロールではアクセスが十分にロックダウンされない場合にアクセス許可に関する細分性を高めるためのカスタム ロールを作成します。 たとえば、ロジック アプリのコールバック URL へのアクセスには 1 つのアクセス許可が必要ですが、その種類のアクセスに対する組み込みのロールは、"共同作成者" または "所有者" 以外に存在しません。これらのロールでは範囲が広すぎます。
Azure Policy を使用して、特定のリソースへのアクセスを制限したり、会社のポリシーへの準拠を強制したりすることを確認します。 たとえば、暗号化されたプロトコルを使用する API Management API のデプロイのみを許可するポリシーを作成できます。
Azure 上の AIS の運用と管理に関連する一般的なアクティビティを確認し、RBAC のアクセス許可を適切に割り当てます。使用可能なアクセス許可の詳細については、「リソース プロバイダー操作」を参照してください。
一般的な Azure 管理アクティビティの例には次のようなものがあります。
| Azure リソース | Azure リソース プロバイダー | アクティビティ |
|---|---|---|
| App Service プラン | Microsoft.Web/serverfarms | 読み取り、結合、再起動、VNet 接続の取得 |
| API 接続 | Microsoft.Web/connections | 更新、確認 |
| Logic Apps と Functions | Microsoft.Web/sites | 読み取り、開始、停止、再起動、スワップ、構成の更新、診断の読み取り、VNet 接続の取得 |
| 統合アカウント | Microsoft.Logic/integrationAccounts | アセンブリの読み取り/追加/更新/削除、マップの読み取り/追加/更新/削除、スキーマの読み取り/追加/更新/削除、契約の読み取り/追加/更新/削除、パートナーの読み取り/追加/更新/削除 |
| Service Bus | Microsoft.ServiceBus | 読み取り、接続文字列の取得、DR 構成の更新、キューの読み取り、トピックの読み取り、サブスクリプションの読み取り |
| ストレージ アカウント | Microsoft.Storage/storageAccounts | 読み取り、変更 (ワークフロー実行履歴など) |
| API Management | Microsoft.ApiManagement | ユーザーの登録/削除、API の読み取り、承認の管理、キャッシュの管理 |
| KeyVault | Microsoft.KeyVault/vaults | コンテナーの作成、アクセス ポリシーの編集 |
次のステップ
重要な設計領域を確認し、アーキテクチャの完全な考慮事項と推奨事項を作成します。