「サーバーがどこにあるか」なんて、もう気にしなくていい。
こんにちは!「LINUX工房」管理人の「リナックス先生」です。
前回は、AppLockerと監査ログによるサーバーの要塞化(セキュリティ硬化)について学びました。
サーバー単体の守りは完璧です。
しかし、視点を広げて「インフラ全体」を見たとき、皆さんはこんな状況に陥っていませんか?
「社内の物理サーバーはvCenterで管理し、クラウドはAWSコンソールとAzureポータルを行ったり来たり。
パッチ当ての状況も、スプレッドシートで別々に管理していて、どれが最新か分からない……」
先生、まさに地獄です!
上司から「全サーバーのセキュリティパッチ適用状況を出せ」って言われたんですけど、オンプレのWSUSと、AWSのSystems Managerと、AzureのUpdate Managerの画面をスクショしてExcelに貼る作業で一日が終わりました。
LinuxならAnsibleで統一できますけど、Windowsが混ざるともうカオスで……。
「全サーバーが1つの画面に並ぶ」なんて夢のような話、ないですよね?
コウ君、その夢、叶うわよ。
Microsoftが提供する「Azure Arc(アジュール アーク)」を使えばね。
これは、オンプレミスのサーバーだろうが、AWSのEC2だろうが、全てを「Azureのリソース」として扱えるようにする技術よ。
物理的な場所に関係なく、Azureの強力な管理機能をあらゆるサーバーに「延長」できるの。
今回もウィンドウズ先生に、ハイブリッドクラウドの真髄を教えてもらいましょう!
はい、ウィンドウズ先生です。
Azure Arcは、単なる「監視ツール」ではありません。
オンプレミスのサーバーに「Azure上のID(Managed Identity)」を与え、Azure Policyで設定を強制し、Azure Monitorでログを収集する。
つまり、「あなたのデータセンターをAzureの一部にする」技術です。
Linuxエンジニアの皆さんも、これを使えば SSH も RDP も不要で、ブラウザから全てのサーバーを管理できるようになりますよ。
本記事では、Azure Arcの仕組み、オンボーディング手順、Azure Policyによる構成管理、そしてWindows Admin Centerを使ったリモート管理までを徹底解説します。
🟥 Windows Server【上級】講座(全12回)カリキュラム
現在地:【第11回】ハイブリッドクラウド管理。Azure Arcによるオンプレミスサーバーのクラウド化
- 【第1回】Pacemakerと何が違う?Windowsクラスタリング(WSFC)の仕組みと構築手順
- 【第2回】ネットワークサービスの要。DHCP冗長化とIPAMによるIPアドレス管理
- 【第3回】DNSの深淵。スプリットブレインDNS、ゾーン転送、DNSSECの構築
- 【第4回】証明書基盤 (AD CS)。OpenSSL使いが知るべきエンタープライズPKI
- 【第5回】リモートアクセスの要塞。RDS (Remote Desktop Services) とVDI入門
- 【第6回】Infrastructure as Code (IaC)。PowerShell DSCによる構成管理の自動化
- 【第7回】Software Defined Storage。記憶域スペースダイレクト (S2D) の構築
- 【第8回】バックアップと災害復旧。Windows Server BackupとVSSの深層
- 【第9回】ID連携の架け橋。AD FS (Federation Services) とSAML/OIDC連携
- 【第10回】セキュリティの硬化。AppLockerと監査ログによる要塞化
- 【第11回】ハイブリッドクラウド管理。Azure Arcによるオンプレミスサーバーのクラウド化
- 【第12回】マイグレーション戦略。FSMO移行、OSインプレースアップグレードの極意
※入門編(全8回)の復習はこちら:Windows Server入門講座 アーカイブ
目次
第1章:Azure Arcとは? ARMの投影技術
Azureには、すべてのリソース(VM、DB、Networkなど)を管理する司令塔「ARM (Azure Resource Manager)」が存在します。
Azure Arcは、Azureの外にあるサーバーに専用エージェントを入れ、ARMに「これはAzureのVMですよ」と認識させる(投影する)技術です。
何ができるようになるのか?
- インベントリ管理: オンプレ、AWS、GCPのサーバーが、Azureポータルの一覧に並びます。タグ付けや検索も可能です。
- ポリシー適用: 「パスワードの複雑性を満たしていないサーバー」などをAzure Policyで検知・是正できます。
- 監視統合: Azure Monitor (Log Analytics) にログを集約し、ダッシュボードで可視化できます。
- マネージドID: オンプレサーバーにAzure ADのIDが付与され、Key VaultなどのAzureリソースへ「鍵なし」でアクセス可能になります。
ネットワーク要件
ここが最大の特徴です。
「インバウンド(受信)ポートの開放は一切不要」です。
エージェントが内側からAzureへ向けて、HTTPS (443) のアウトバウンド通信を行うだけです。
VPNや専用線(ExpressRoute)がなくても、インターネットに繋がっていれば管理可能です。
第2章:実践!オンプレミスサーバーのオンボーディング
実際に、手元のWindows ServerをAzure Arcに接続(オンボーディング)してみましょう。
※事前にAzureサブスクリプションが必要です(無料枠で試せます)。
1. インストールスクリプトの生成
- Azureポータルで「Azure Arc」→「サーバー」→「追加」をクリック。
- 「単一サーバーの追加」を選択し、「スクリプトの生成」へ進みます。
- リソースグループ(例:
Arc-OnPrem-RG)とリージョン(例:Japan East)を選択。 - OSは「Windows」を選択。
- 画面にPowerShellスクリプトが表示されるのでコピーします。
2. サーバーでの実行
オンプレミスのサーバーでPowerShellを管理者として開き、コピーしたスクリプトを実行します。
# インストールスクリプトの例(一部抜粋) Invoke-WebRequest -Uri "https://aka.ms/azcmagent-windows" -OutFile "AzureConnectedMachineAgent.msi" msiexec.exe /i AzureConnectedMachineAgent.msi /qn & "$env:ProgramW6432\AzureConnectedMachineAgent\azcmagent.exe" connect ` --resource-group "Arc-OnPrem-RG" ` --tenant-id "your-tenant-id" ` --location "japaneast" ` --subscription-id "your-subscription-id"
実行中、ブラウザ認証を求められるので、AzureのIDでログインします。
(大規模展開の場合は、サービスプリンシパルを使った非対話ログインも可能です)
3. 接続確認
コマンドが成功すると、Azureポータルのリソースグループ内に、そのサーバーが「Server – Azure Arc」という種類のリソースとして表示されます。
これで、あなたのサーバーはAzureの一部になりました。
💡 プロのトラブルシューティング
接続できない場合、ほとんどの原因はプロキシやファイアウォールです。azcmagent check コマンドを実行すると、必要なエンドポイントへの接続性をチェックしてくれます。
ホワイトリストに *.his.arc.azure.com などを追加する必要があります。
第3章:ガバナンスの強制。Azure Policyと拡張機能
繋いだだけでは「見えるだけ」です。
ここからAzureの力を注入していきます。
Arc対応サーバーには、Azure VMと同様に「拡張機能 (Extensions)」をインストールできます。
Azure Monitor Agent (AMA) の導入
ポータルから「拡張機能」→「追加」で AzureMonitorWindowsAgent を選択します。
これにより、OS内のイベントログやパフォーマンスデータが、Azure上の「Log Analyticsワークスペース」に自動転送されるようになります。
第7回で苦労したイベントビューアの解析も、Azure上のKQL(Kusto Query Language)を使えば一瞬です。
![]() |
イラストでそこそこわかるLinux 第2版 コマンド入力からネットワークのきほんのきまで 新品価格 |
Azure Policyによる設定強制
「パスワードの有効期限を無期限にしてはいけない」「特定のレジストリ設定を固定したい」。
これを実現するのが Azure Policy の「ゲスト構成 (Guest Configuration)」機能です。
DSC(第6回参照)の技術をベースにしており、ポリシー違反を検知するだけでなく、自動修復(DeployIfNotExists)させることも可能です。
オンプレ、AWS、Azure、すべての環境に対して統一したセキュリティ基準を強制できます。
第4章:更新管理の統合。Azure Update Manager
第6回で「WSUSは非推奨」という話をしました。
その移行先として最適なのが、Arcと統合された「Azure Update Manager」です。
Azure Update Managerのメリット
- インフラ不要: WSUSサーバーを立てる必要がありません。
- 一元管理: WindowsもLinuxも、Azure VMもオンプレ機も、1つの画面でパッチ適用状況が見えます。
- スケジュール実行: 「毎月第3土曜日のAM2:00に再起動ありで適用」といったスケジュールをクラウド側で定義できます。
- 即時適用: ゼロデイ脆弱性が見つかった時、ボタン一つで全台に緊急パッチを配布できます。
コスト感
Azure Arc自体の基本機能は無料ですが、Update ManagerやPolicyなどの付加機能は従量課金(サーバー1台あたり月額数百円程度)です。
しかし、WSUSサーバーの維持管理コスト(電気代、ディスク代、人的コスト)を考えれば、十分に安上がりです。
第5章:VPN不要のリモート管理。WAC in Azure
「サーバーの調子が悪い。イベントログを見たいが、今は出先でVPNが繋がらない……」
そんな時、Azure Arcのキラー機能「Windows Admin Center (WAC) in Azure」が火を噴きます。
WACとは?
従来の「サーバーマネージャー」をモダンなWebベースにした管理ツールです。
通常はオンプレミスにWebサーバーとして立てますが、Azure Arcを使うと、Azureポータルの中にWACの画面が埋め込まれます。
魔法のような接続体験
- Azureポータルで対象のArcサーバーを開く。
- メニューから「Windows Admin Center」を選択。
- 「接続」ボタンを押す。
これだけで、ブラウザの中にサーバーのデスクトップ(に近い管理画面)が表示されます。
PowerShellコンソールも、リモートデスクトップも、ファイル操作も、レジストリ編集も、すべてブラウザ内で完結します。
ポート開放もVPNも不要です。 Arcエージェントが張ったリバース接続を通るからです。
💡 プロの視点:SSHアクセスも可能
2022年頃から、Azure Arc経由でのSSH接続機能も追加されました。az ssh arc --resource-group ... --name ...
このコマンドを叩くだけで、プライベートIPしか持たないオンプレミスのLinuxサーバーに、インターネット経由で安全にSSH接続できます。
踏み台サーバー(Bastion)すら不要になる革命的機能です。
第6章:LinuxエンジニアのためのArc活用術
「Windowsの話ばかりだけど、Linuxはどうなの?」
実は、Azure ArcはLinux(Ubuntu, RHEL, SUSE等)にも完全対応しています。
Linuxでのメリット
- Key Vault連携: アプリケーション内の「DBパスワード」や「APIキー」を、ローカルの
.confファイルに書かずに済みます。ArcのマネージドIDを使って、Azure Key Vaultから安全に取得できます。 - Run Command: Azureポータルから、オンプレLinuxに対してシェルスクリプトを流し込めます。「全台で特定のプロセスを再起動したい」といった時に便利です。
- Custom Script Extension: AnsibleのPullモードのように、Azure上のスクリプトをダウンロードして実行させることができます。
まとめ:境界のないインフラへ
お疲れ様でした!
上級編第11回は、Azure Arcによるハイブリッドクラウド管理について解説しました。
今回の重要ポイント:
- Azure Arcは、あらゆる場所のサーバーをAzureリソースとして管理する技術。
- インバウンドポート開放不要。HTTPSアウトバウンドのみで動作する。
- WSUSは廃止し、Azure Update Managerへ移行するのが現代の最適解。
- WACを使えば、VPNなしでブラウザからサーバー内部を操作できる。
「クラウドかオンプレか」という議論はもう古いです。
Azure Arcを使えば、オンプレミスは「Azureの特別なリージョン(自社データセンター)」になります。
物理的な制約から解放され、統一されたガバナンス下でインフラを管理する。
これが次世代のインフラエンジニアの姿です。
さて、いよいよ次回で本講座も最終回です。
最後は、これまでの知識を総動員して行う一大イベント、「マイグレーション(移行)」です。
Windows Server 2016/2019 から 2022/2025 への移行、そしてFSMOの役割移動。
絶対に失敗できない本番作業の手順書を、最後に完成させましょう。
次回、最終回(第12回)は「マイグレーション戦略。FSMO移行、OSインプレースアップグレードの極意」です。
ADの移行、ファイルサーバーのデータ移行、そして古いOSをその場でアップグレードするインプレースアップグレードの是非まで、現場のノウハウを詰め込んでお届けします。お楽しみに!
▼ ハイブリッド環境を構築する ▼
Azure Arcを試す
「おすすめVPS」
クラウド×オンプレの二刀流
「ITエンジニア転職」


コメント