Azure Arc 対応サーバーの ID とアクセス管理

この記事では、適切な ID とアクセス管理を通じて Azure Arc 対応サーバーをセキュリティで保護するための実用的なガイダンスを提供します。 ハイブリッド インフラストラクチャを保護するために、マネージド ID の構成、ロールベースのアクセス制御の実装、サービス プリンシパルの安全なデプロイについて説明します。 Id 管理システムは、Azure Arc 対応サーバーをセキュリティで保護するために不可欠です。 次の参照アーキテクチャは、ID、ロール、およびアクセス許可がどのように連携するかを示しています。

マネージド ID の構成

システム割り当てマネージド ID は、資格情報を格納せずに、Azure Arc 対応サーバーに対してセキュリティで保護された認証を提供します。 Azure Connected Machine エージェントは、サーバーのオンボード中にこれらの ID を自動的に作成しますが、既定ではアクセス許可がないため、Azure リソースにアクセスするには明示的な Azure RBAC ロールの割り当てが必要です。

1. マネージド ID アクセスの正当なユース ケースを特定します。 サーバー上のアプリケーションでは、Key Vault や Storage などの Azure リソースを呼び出すために、特定のアクセス トークンが必要です。 セキュリティギャップを回避するためのアクセス許可を付与する前に、これらのリソースのアクセス制御を計画します。

2. マネージド ID エンドポイントへの特権ユーザー アクセスを制御します。 Windows 上のローカル管理者または Hybrid Agent Extensions Applications グループ のメンバーと Linux 上の himds グループは 、アクセス トークンを要求できます。 これらのグループのメンバーシップを制限して、Azure リソースへの不正アクセスを防ぎます。

3. マネージド ID のロールベースのアクセス制御を実装します。 Azure RBAC を使用して、マネージド ID に最低限必要なアクセス許可のみを付与します。 定期的なアクセス レビューを実行して、アクセス許可が適切であることを確認し、未使用のアクセスを削除します。

ロールベースのアクセス制御を適用する

ロールベースのアクセス制御により、ユーザー特権が制限され、セキュリティ リスクが軽減されます。 共同作成者や所有者などの広範なロールを持つユーザーは、拡張機能をデプロイし、Azure Arc 対応サーバーへの管理アクセス権を取得して、潜在的なセキュリティの脆弱性を作成できます。

1. ロールの割り当てに最小特権の原則を適用します。 ユーザー、グループ、アプリケーションは、タスクに必要な最小限のアクセス許可のみを受け取る必要があります。 共同作成者、所有者、Azure 接続マシン リソース管理者などのロールは、サーバーへのルート アクセスを効果的に委任できる広範なアクセス権を付与します。

2. サーバー登録には、Azure Connected Machine Onboarding ロールを使用します。 このロールにより、ユーザーは、より広範な管理アクセス許可を付与することなく、サーバーを Azure Arc にオンボードできます。 このロールは、拡張機能の管理やサーバーの削除ではなく、Arc リソースの作成と読み取りに必要なアクセス許可のみを提供します。

   オンボード ロールを持つサービス プリンシパルを作成する

3. 監視データへのアクセスをセキュリティで保護します。 Azure Arc 対応サーバーへの読み取りアクセスでは、Log Analytics エージェントによって収集されたログ データを公開できます。 Log Analytics ワークスペースに RBAC コントロールを適用して、機密性の高い運用データを表示できるユーザーを制限します。

また、Azure Monitor Log Analytics ワークスペースに送信される可能性のある機密データについても検討してください。データ自体に同じ RBAC 原則を適用します。 Azure Arc 対応サーバーへの読み取りアクセスは、Log Analytics エージェントによって収集され、関連付けられている Log Analytics ワークスペースに格納されたログ データへのアクセスを提供できます。

ID とアクセスの責任を計画する

組織が明確にすることで、セキュリティのギャップや運用上の競合を防ぐことができます。 ロール定義を明確にすると、適切なユーザーが Azure Arc 対応サーバーのオンボードと管理に適切なアクセス権を持つことができます。

1. サーバーのオンボードの責任を定義します。 サーバーをオンボードできるユーザーを特定し、サーバーと Azure の両方で必要なアクセス許可を設定します。 このロールには、サーバー上のローカル管理者アクセス権と適切な Azure アクセス許可が必要です。

2. 継続的な管理責任を割り当てます。 オンボード後に Azure Arc 対応サーバーを管理するユーザーと、Azure サービスから運用データを表示できるユーザーを決定します。 運用上のニーズとセキュリティ要件に基づいて、これらの責任を分離します。

3. サービス プリンシパルの配布を計画します。 異なるビジネス チームがサーバー グループを所有および運用する場合は、複数の Arc オンボード サービス プリンシパルを作成します。 潜在的なセキュリティの公開を制限するために、各プリンシパルを必要最小限のリソース グループにスコープを設定します。

4. エンタープライズ規模の影響を評価します。 ID とアクセス管理の設計領域を確認して、Azure Arc 対応サーバーが Azure ランディング ゾーンの ID 戦略全体とどのように統合されるかを理解します。

セキュリティコントロールを実装する

セキュリティコントロールは、Azure Arc 対応サーバーと、アクセスできるリソースを保護します。 適切な実装により、攻撃対象領域が減少し、セキュリティ ポリシーへの準拠が保証されます。

セキュリティで保護されたサーバーのオンボードを構成します。 セキュリティ グループを使用して、Azure Arc オンボードの特定されたユーザーまたはサービス アカウントにローカル管理者権限を大規模に割り当てます。 この方法では、サーバーフリート全体で一貫したアクセス制御が提供されます。

証明書ベースの認証 (推奨)

証明書を使用してサービス プリンシパルをデプロイします。 サーバーのオンボードには、証明書認証で Microsoft Entra サービス プリンシパル を使用します。 証明書は、より強力なセキュリティを提供し、条件付きアクセス ポリシーをサポートし、資格情報の公開リスクを軽減するため、クライアント シークレットよりも推奨される認証方法です。 各プリンシパルのスコープを、最低限必要なリソース グループまたはサブスクリプションに設定します。

代替認証方法

証明書が使用できない場合は、クライアント シークレットをセキュリティで保護します。 サービス プリンシパルにクライアント シークレットを使用する場合は、有効期間を短くし、定期的にローテーションし、プリンシパルのスコープとアクセス許可を制限してセキュリティの露出を減らします。

ロールの割り当てとアクセス制御

1. 適切なロールの割り当てを適用します。 オンボード操作用のリソース グループ レベルで Azure Connected Machine Onboarding ロールを割り当てます。 Azure でサーバー リソースを管理するチームに 、Azure 接続マシン リソース管理者 ロールを付与します。

2. マネージド ID アクセスを制御します。 サーバー上 のアプリケーションのマネージド ID を 使用して、Microsoft Entra で保護されたリソースにアクセスします。 Microsoft Entra アプリケーションのアクセス許可を使用して、承認されたアプリケーションのみにアクセスを制限します。

3. ID エンドポイントへのローカル アクセスを管理します。 Windows 上の Hybrid agent extension applications セキュリティ グループまたは Linux 上 の himds グループを使用して、Arc 対応サーバーから Azure リソース アクセス トークンを要求できるユーザーを制御します。

Azure のツールとリソース

この包括的なリファレンスは、Azure Arc 対応サーバーの ID とアクセス管理を実装するのに役立ちます。 これらのツールを使用して、セキュリティで保護された認証、ロールベースのアクセス制御、監視を構成します。

次の手順

Azure Arc 環境をセキュリティで保護する準備はできましたか? ネットワーク セキュリティ構成を続行して、ハイブリッド インフラストラクチャの保護を完了します。

Azure Arc 体験を続行する

その他のリソース

• Azure Arc 対応サーバーの概要
• トラブルシューティング ガイド
• Azure Hybrid Cloud のドキュメント