Microsoft AzureでAzure Arc-enabled serversを運用している場合、2026年5月7日に更新された「Security overview – Azure Arc」で最初に確認すべき点は、緊急パッチの有無ではなく、Azure Arcを通じてサーバーにどこまで管理操作を許可しているかです。特に、Azure Connected Machine agentの権限、Azure RBAC、Azure Policy、拡張機能のallowlist、Guest Configuration、Run Command、Tier 0資産の扱いを見直す必要があります。公式ページはAzure Arc-enabled serversのセキュリティ上の考慮事項と利用可能な制御を説明するもので、最終更新日は2026年5月7日と表示されています。(Microsoft Learn)
この記事では、Microsoft Azureの「Security overview – Azure Arc」の要点を、管理者や開発者が実際に確認すべき設定、影響範囲、移行・展開時の注意点に絞って整理します。
Azure ArcのSecurity overviewでまず押さえる結論
今回のSecurity overviewは、Azure Arc-enabled serversを「Azureから安全に管理するための前提」を明確にする内容です。Azure Arcは、オンプレミス、他クラウド、エッジ環境などにあるサーバーをAzureの管理プレーンへ接続します。そのため、Azure側の権限設計を誤ると、サーバー側の変更権限に近い影響を持つ可能性があります。
特に重要なのは、次の4点です。
| 確認項目 | 管理者が見るべきポイント | 放置した場合のリスク |
|---|---|---|
| Azure RBAC | Arcリソースに対するOwner、Contributor、Azure Connected Machine Resource Administratorなどの割り当て | Azure経由で拡張機能やRun Commandを使った操作が可能になる |
| 拡張機能 | Azure Monitor Agent、Defender、Custom Script Extensionなどの許可範囲 | 不要な拡張機能からスクリプト実行や設定変更が可能になる |
| エージェント構成 | azcmagent configでローカル制御が適用されているか | Azure Policyだけでは防げない操作が残る |
| Tier 0資産 | ドメインコントローラー、証明機関、重要業務サーバーの分離 | Azureの管理権限が重要基盤の管理権限に近い意味を持つ |
Azure Arcでは、Azure上のサーバー表現が管理の起点になります。拡張機能のインストールなどの操作はAzure上のリソースに対して行われ、それがAzure Connected Machine agentを通じて対象サーバーへ反映されます。Microsoft Learnでは、Azure RBACやAzure Policyでクラウド側の操作を制御できる一方、より強い制御が必要な場合はエージェント側のローカル制御も使うべきだと説明されています。(Microsoft Learn)
2026年5月7日更新で読み取るべき変更点
公開されているGitHub履歴から確認できる範囲では、2026年5月4日に「Service account model」セクションが追加され、その後2026年5月6日に表現調整のコミットが複数入っています。Microsoft Learn上のページでは最終更新日が2026年5月7日と表示されています。したがって、実務上の大きな読みどころは、Azure Connected Machine agentのサービスアカウントモデルが明文化されたことです。(GitHub)
| 変更・整理された内容 | 実務上の意味 | 対応ポイント |
|---|---|---|
| Azure Connected Machine agentはローカルのシステム管理IDで動作する | ドメイン参加済みサービスアカウントや任意のユーザーIDで動かす設計ではない | AD管理アカウントやgMSAで運用する前提の手順書を見直す |
| ドメイン参加済みサービスアカウントや代替IDはサポートされない | 「より安全そうだからドメインアカウントで実行する」という設計は不可 | エージェントの実行ID変更を移行要件に入れない |
| ローカルIDによりドメイン依存を避ける設計である | ワークグループ、ドメイン参加、切断環境などで一貫した動作を狙っている | AD障害時の依存関係を増やさない設計として理解する |
| 資格情報の露出を減らす設計である | パスワード管理や対話的サインインを前提にしない | サービスプリンシパルやオンボーディング資格情報の管理に注力する |
この変更は、サーバー管理者にとって「エージェントをどのアカウントで動かすか」という設計判断を減らす一方で、Azure側の権限管理とローカルエージェント制御の重要性を高めるものです。
Security overviewの基本は「Microsoftの責任」と「利用者の責任」の切り分け
Azure Arc-enabled serversのセキュリティは、Microsoftと利用者の共同責任です。Microsoftはクラウドサービス、Azureに保存されるシステムメタデータ、オプション機能の文書化、エージェント更新の提供を担います。一方、利用者はAzure RBAC、オンボーディングに使う資格情報、エージェントと拡張機能の更新、コンプライアンス判断、サーバー本体の保護を担います。(Microsoft Learn)
ここで見落としやすいのは、Azure Arcを導入しても、サーバーOSやネットワーク、ストレージ、既存の監視・運用プロセスの責任がAzureへ移るわけではない点です。Azure Arcは管理プレーンを拡張する仕組みであり、サーバーそのものを自動的に安全にする製品ではありません。
管理者は、少なくとも次の棚卸しを行うべきです。
| 棚卸し対象 | 確認する内容 |
|---|---|
| Azureサブスクリプション | Arc-enabled serversがどのサブスクリプション、リソースグループに配置されているか |
| Azure RBAC | Owner、Contributor、Arc関連ロールの割り当てと継承 |
| Azure Policy | 拡張機能、Guest Configuration、タグ、診断設定などのポリシー |
| オンボーディング資格情報 | サービスプリンシパルのシークレット、証明書、有効期限、保管場所 |
| エージェント | Azure Connected Machine agentのバージョン、更新方法、ローカル設定 |
| 拡張機能 | インストール済み拡張機能、許可リスト、ブロックリスト |
Azure Connected Machine agentの4つのサービスと確認ポイント
Azure Connected Machine agentは、Azure Arc-enabled serversをAzureへ接続する中心的なコンポーネントです。公式情報では、4つのサービスまたはデーモンの組み合わせとして説明されています。(Microsoft Learn)
| サービス | 主な役割 | セキュリティ上の確認ポイント |
|---|---|---|
| Hybrid Instance Metadata Service（HIMDS） | Azureへの登録、ハートビート、マネージドID操作、ローカルREST APIの提供 | Windowsでは仮想アカウント、Linuxでは標準ユーザーとして動作する。管理者権限で常時動く前提ではない |
| Extension manager | 拡張機能のインストール、構成、更新、削除 | WindowsではLocal System、Linuxではrootで動くため、許可する拡張機能を厳しく管理する |
| Guest configuration | Azure machine configurationポリシーの評価・適用 | enforceモードではサーバー設定を変更し得る。使わない場合は無効化を検討する |
| Azure Arc proxy | エージェントや拡張機能の通信を集約し、Azure Arc Gateway利用時の経路制御を担う | 既定では無効。Azure Arc Gatewayを使う場合のみ構成を確認する |
特に注意すべきなのはExtension managerです。拡張機能の種類によっては、監視や防御だけでなく、スクリプト実行や構成変更にも使えます。セキュリティ目的でAzure Arcを導入したのに、不要な拡張機能を許可したままにすると、管理経路が増えてしまいます。
管理者が確認すべき設定
Azure RBACは「Azure上の権限」ではなく「サーバー操作権限」として見る
Azure Arc-enabled serversでは、Azure上のArcリソースに対する操作がサーバー上の変更につながる場合があります。Tier 0資産では、サブスクリプション管理者や管理グループ管理者を、実質的にローカル管理者に近い影響を持つ立場として扱うべきだと公式情報でも説明されています。(Microsoft Learn)
まず、継承されたロールを含めて確認します。
az role assignment list \
--scope /subscriptions/<subscription-id> \
--include-inherited \
--output table確認時は、次の観点で絞り込みます。
| 観点 | 判断基準 |
|---|---|
| 人のアカウント | 常時Ownerを持つユーザーが多すぎないか |
| グループ | 退職者や異動者が残るグループに強い権限が付いていないか |
| サービスプリンシパル | オンボーディング用の権限が展開後も残っていないか |
| 管理グループ | 上位階層のポリシーやロールがTier 0資産へ意図せず継承されていないか |
Tier 0資産をAzure Arcへ接続する場合は、一般サーバーと同じサブスクリプションに混在させるのではなく、専用サブスクリプションを検討します。親管理グループから継承されるAzure Policyも、対象サーバーに対して意図した動作になっているか確認してください。(Microsoft Learn)
azcmagentでローカル設定を確認する
Azure Connected Machine agentの設定はローカルに保存され、マシンごとに固有です。また、利用できる構成プロパティはエージェントのバージョンによって異なる場合があります。現在の設定確認には、azcmagent config listやazcmagent config infoを使います。(Microsoft Learn)
azcmagent show
azcmagent config list
azcmagent config info extensions.allowlistazcmagent showでは、Azureへの接続状態、Azureリソース情報、依存サービスの状態を確認できます。状態確認だけであれば管理者権限は不要です。(Microsoft Learn)
運用では、次のように台帳化すると確認漏れを減らせます。
| 項目 | 記録例 |
|---|---|
| Agent Status | Connected / Disconnected |
| Agent Last Heartbeat | 最終ハートビート時刻 |
| config.mode | full / monitor |
| extensions.allowlist | 許可している拡張機能 |
| extensions.blocklist | ブロックしている拡張機能 |
| guestconfiguration.enabled | true / false |
| incomingconnections.enabled | true / false |
拡張機能はallowlistを優先して考える
Azure Arc-enabled serversでは、拡張機能のallowlistとblocklistを使って、インストールできる拡張機能を制限できます。allowlistは指定した拡張機能だけを許可し、blocklistは指定した拡張機能だけを拒否します。公式情報では、新しい拡張機能が将来追加された場合も自動的にブロックできるため、allowlistのほうが望ましいとされています。(Microsoft Learn)
例えば、ドメインコントローラーでAzure Monitor AgentとMicrosoft Defender for Serversに必要な拡張機能だけを許可する場合は、次のような構成が考えられます。
azcmagent config set extensions.allowlist "Microsoft.Azure.Monitor/AzureMonitorWindowsAgent,Microsoft.Azure.AzureDefenderForServers/MDE.Windows"ただし、allowlistやblocklistを設定しても、すでにインストール済みの拡張機能は自動削除されません。不要な拡張機能を完全に外すには、Azure側から削除操作を行う必要があります。これは現場でよく起きる誤解です。(Microsoft Learn)
監視やセキュリティ用途だけでAzure Arcを使う場合は、monitor modeも選択肢になります。monitor modeでは、監視・セキュリティ関連の拡張機能に絞られ、システム構成を変更したり任意スクリプトを実行したりする拡張機能がブロックされ、Guest Configuration policy agentも無効化されます。(Microsoft Learn)
azcmagent config set config.mode monitor
azcmagent config list一方で、monitor mode中はallowlistやblocklistを個別に変更できません。独自の許可リストを細かく管理したい場合は、full modeに戻して明示的なallowlistを設定する設計にします。(Microsoft Learn)
Guest Configurationは「見るだけ」ではなく「直す」可能性がある
Guest Configurationは、サーバー上の設定を評価し、ポリシーがenforceモードで構成されている場合は設定を準拠状態へ変更する可能性があります。WindowsではLocal System、Linuxではrootで動作するため、単なる可視化機能として扱うべきではありません。(Microsoft Learn)
Guest Configurationを使わないサーバーでは、無効化を検討します。
azcmagent config set guestconfiguration.enabled false特にTier 0資産では、「誰がAzure Policyを変更できるか」と「そのポリシーがサーバー設定を変更できるか」をセットで確認してください。
リモートアクセスとRun Commandは最小限にする
Run Commandは、Azure CLI、PowerShell、REST APIなどからAzure Arc-enabled servers上でスクリプトやコマンドを実行する機能です。セキュリティパッチ適用や脆弱性対応の自動化に役立つ一方、使える人や対象サーバーを誤ると強力なリモート操作経路になります。(Microsoft Learn)
不要なリモートアクセス機能は、ローカルエージェント制御で無効化します。
azcmagent config set incomingconnections.enabled falseRun Commandについては、Azure RBACで誰が実行できるかを管理しつつ、必要に応じてローカル側でも制限します。公式情報では、Run Commandの実行にはMicrosoft.HybridCompute/machines/runCommands/write権限が関係し、ローカルではRun Command拡張をallowlistまたはblocklistに入れて制御できると説明されています。(Microsoft Learn)
azcmagent config set extensions.blocklist "microsoft.cplat.core/runcommandhandlerwindows"エージェント更新はセキュリティ運用の一部として扱う
Azure Connected Machine agentは、バグ修正、安定性向上、新機能のために定期的に更新されます。公式情報では、Azure Advisorが古いエージェントを検出して更新を推奨すること、WindowsとLinuxで手動または自動更新を選べること、インストール・更新・アンインストール時にサーバー再起動は不要であることが説明されています。(Microsoft Learn)
また、Azure Connected Machine agentは、公式には過去1年以内にリリースされたバージョンがサポート対象とされています。古いバージョンのまま安定稼働しているサーバーでも、セキュリティレビューでは「動いているから問題ない」ではなく、サポート範囲内かどうかを確認してください。(Microsoft Learn)
更新方針は、次のように環境別に分けると現実的です。
| 環境 | 推奨される考え方 |
|---|---|
| 一般的な業務サーバー | 定期メンテナンスで最新バージョンへ追随する |
| 大規模環境 | Azure AdvisorやAzure Policyを使い、更新対象を可視化する |
| Tier 0資産 | 事前検証環境で更新後、短い変更ウィンドウで適用する |
| Azure public cloud環境 | 要件を満たす場合、自動エージェントアップグレードの利用可否を検討する |
自動エージェントアップグレードは、公式情報時点ではAzure Connected Machine agent 1.57以降で構成できるプレビュー機能として説明されています。利用する場合は、本番展開前に対象クラウド、変更管理、監査要件と合うか確認してください。(Microsoft Learn)
開発者・自動化担当者が見直すべき設計前提
Azure ArcのSecurity overviewは、インフラ管理者だけでなく、展開スクリプトやIaCを作る開発者にも関係します。特に、次の前提は見直しが必要です。
| 見直す前提 | 修正すべき方向 |
|---|---|
| エージェントをドメインサービスアカウントで動かす | サポートされないため、ローカルのシステム管理ID前提で設計する |
| Arc接続後にAzure側から何でも設定する | センシティブなサーバーでは、接続前または接続直後にローカル制御を入れる |
| 拡張機能は必要になったら自由に追加する | 事前に必要なpublisher/typeを定義し、allowlistとして管理する |
| Azure Policyだけで制御する | ポリシーを変更できる管理者がいるため、重要サーバーではローカル制御も併用する |
| オンボーディング用サービスプリンシパルを使い回す | 展開後に権限を縮小し、シークレットや証明書を定期的にローテーションする |
Azure Arc agentは、ドメイン参加済みサービスアカウントや任意のユーザー提供IDをサポートせず、構成を変更するサポートされた方法もありません。この設計は、ドメイン依存を避けること、資格情報の露出を減らすこと、マシン単位のセキュリティ境界を保つことを目的としています。(Microsoft Learn)
そのため、移行計画書や設計書に「Azure Arc agent用のADサービスアカウントを作成する」と書いてある場合は、早めに修正してください。
移行・展開時の注意点
レガシーLog Analytics Agentからの移行ではArcとAMAを混同しない
非Azure環境でLog Analytics Agent、MMA、OMSからAzure Monitor Agentへ移行する場合、Azure Arcが必要になります。ただし、Azure Monitor AgentとAzure Connected Machine agentは別物です。非Azure環境では、Connected Machine agentでAzure Arcへ接続し、その上でAzure Monitor Agentを拡張機能として展開する設計になります。(Microsoft Learn)
監視だけを目的にAzure Arcを使う場合は、monitor modeが有効です。Microsoft Learnでも、レガシーLog Analytics Agentからの移行時にmonitor modeが特に重要であり、リモート接続を無効化し、Machine Configuration agentを無効化し、Microsoft管理の拡張機能allowlistを適用すると説明されています。(Microsoft Learn)
移行時は、次の順序で確認すると失敗しにくくなります。
| 手順 | 確認内容 |
|---|---|
| 既存環境の棚卸し | MMA/OMS、Dependency Agent、Hybrid Runbook Worker、Update Managementなどの利用状況 |
| Arc接続の設計 | サブスクリプション、リソースグループ、リージョン、RBAC、サービスプリンシパル |
| エージェント制御 | full modeにするか、monitor modeにするか |
| AMA展開 | Azure Policy、Azure CLI、PowerShell、ARMテンプレートなどの展開方法 |
| 旧エージェント撤去 | 監視データ、アラート、ワークブック、運用手順に影響がないか確認後に実施 |
ネットワークはアウトバウンド443だけで終わらせない
Azure Connected Machine agentは、既定ではAzure ArcへTCP 443のアウトバウンド通信を行います。プロキシを使うこともできますが、公式情報では、通信はすでに暗号化されているため、プロキシがConnected Machine agentをより安全にするわけではないと説明されています。ネットワーク面でさらに保護したい場合は、Azure Arc private link scopeなどの利用を検討します。(Microsoft Learn)
また、Azure public cloudではAzure Arc Gatewayにより必要なエンドポイント数を減らせるとされています。ファイアウォールやプロキシで送信先を厳しく制限している環境では、Arc Gateway、Private Link、必要なサービス タグを事前に確認してください。(Microsoft Learn)
注意したいのは、Azure Arc-enabled serversではLog Analytics gatewayをConnected Machine agentのプロキシとして使えない点です。Azure Monitor Agent側ではLog Analytics gatewayをサポートするケースがあっても、Connected Machine agentの要件とは分けて考える必要があります。(Microsoft Learn)
Tier 0資産は「接続するかどうか」から判断する
ドメインコントローラー、証明機関、極めて重要な業務アプリケーションサーバーなどのTier 0資産もAzure Arcへ接続できます。ただし、公式情報では、望ましい管理機能と許可されたユーザーだけが管理できるよう、追加の注意を払うことが強く推奨されています。(Microsoft Learn)
Tier 0資産では、次のような判断が必要です。
| 判断項目 | 推奨される対応 |
|---|---|
| サブスクリプション | 一般サーバーと分け、専用サブスクリプションを検討する |
| 管理者 | 永続的な管理者を最小限にする |
| 拡張機能 | 必要なものだけをallowlistに入れる |
| Guest Configuration | 使わないなら無効化する |
| リモートアクセス | 使わないなら無効化する |
| Azure Policy | 親管理グループからの継承を含めて確認する |
重要なのは、Azure Arcへの接続自体を目的にしないことです。Microsoft Sentinelへセキュリティログを送る、Microsoft Defender for Serversで保護する、更新管理の対象にするなど、必要な管理目的を先に決め、その目的に必要な機能だけを許可します。
よくある失敗と回避策
| 失敗しやすいポイント | なぜ危険か | 回避策 |
|---|---|---|
| Azure Policyを設定したので安全だと思い込む | Policyを変更できる権限を持つユーザーが制御を外せる可能性がある | 重要サーバーではローカルエージェント制御を併用する |
| allowlist設定後に既存拡張機能も消えたと思う | 既存の拡張機能は自動削除されない | インストール済み拡張機能を別途確認し、不要なものを削除する |
| Custom Script Extensionを放置する | 任意スクリプト実行の経路になり得る | 使わない場合はallowlistから外す、またはblocklistで制限する |
| AgentをADサービスアカウントで動かそうとする | Azure Arc agentのサービスアカウントモデルとしてサポートされない | ローカルのシステム管理ID前提で設計する |
| プロキシを入れれば安全と考える | プロキシ自体は暗号化済み通信をより安全にするものではない | Private LinkやArc Gateway、送信先制御を含めて設計する |
| 古いagentを「動いているから問題ない」と判断する | サポート対象外のバージョンになる可能性がある | Azure Advisorや更新ポリシーで継続的に確認する |
すぐ実施すべき確認チェックリスト
最後に、管理者が今すぐ取りかかるべき項目を整理します。
| 優先度 | 実施内容 | 対象 |
|---|---|---|
| 高 | Arc-enabled serversの一覧を作り、Tier 0資産を分類する | すべてのArc接続済みサーバー |
| 高 | Azure RBACと管理グループ継承を確認する | サブスクリプション、リソースグループ |
| 高 | azcmagent config listでローカル制御を確認する | 重要サーバー |
| 高 | 不要な拡張機能、Run Command、Guest Configurationを制限する | Tier 0、監視専用サーバー |
| 中 | Azure Connected Machine agentのバージョンと更新方法を確認する | すべてのArc接続済みサーバー |
| 中 | オンボーディング用サービスプリンシパルの権限とシークレットを見直す | 展開スクリプト、CI/CD |
| 中 | レガシーLog Analytics AgentからAMAへの移行計画を確認する | 非Azure監視環境 |
| 低 | Azure Arc Gateway、Private Link、プロキシ構成を再評価する | ネットワーク制限が厳しい環境 |
Azure ArcのSecurity overviewを読む目的は、「Azure Arcは安全か」を確認することではありません。正しくは、自社のArc運用がどの管理経路を開いており、その経路を誰が使えるのかを確認することです。
まずはArc-enabled serversの棚卸しを行い、Tier 0資産と監視専用サーバーを分けてください。そのうえで、Azure RBAC、拡張機能allowlist、Guest Configuration、Run Command、agent更新方針を順番に確認すれば、今回の公式情報を実務に落とし込めます。
コメント