Azure Arc検証【後編】｜他クラウドの仮想マシンをAzure Arcで管理してみた

クラウドインテグレーションサービス部の古村です。

前回の記事（前編）では、オンプレ環境やマルチクラウドのマシンをAzure Arcへ接続して、MicrosoftあるいはAzureの機能をAzure上の仮想マシンと同じように利用するための手順を紹介しました。

後編となる本記事では、Azure Arcを活用した、より実践的な管理機能の活用例を3点紹介します。

• Microsoft Defender for Endpointによる保護
• Update Managementによるパッチ管理
• Azure Policyによる設定管理

Microsoft Defender for Endpointによる保護

最初に紹介するのは、Microsoft Defender for Endpointによるサーバー保護機能です。

マルウェア検知のテスト用ファイルをAzure Arc接続マシン上にダウンロードして、脅威検知機能が動作することを確認してみます。

Microsoft Defender for Endpointについて

Microsoft Defender for Endpoint（MDfE）とは脅威検出や防止、保護といった機能を持つ、エンドポイントセキュリティプラットフォームです。

今回、Azure Arcを検証した環境では、Microsoft Defender for ServersのPlan1を有効にしています。上記を有効にしているとAzure上の仮想マシンにMDfEエージェントが自動導入されてセキュリティ管理の対象となりますが、Azure Arc接続マシンも同様に管理対象となります。

Azure Arcへの接続後、しばらく経ってからAzure Arc接続マシンの「拡張機能」画面を確認してみます。MDfEオンボードのための拡張機能である"MDE.Linux（Windowsの場合は、MDE.Windows）"が導入されていることが分かります。

脅威検知機能の動作確認

MDfEの機能の一つ、「エンドポイントでの検出と対応（EDR：Endpoint Detection and Response）」機能が正常に動作することを確認してみます。動作確認のために、Azure Arc接続マシン上で「EICARテストファイル」のダウンロードを実施します。このファイルは、マルウェア対策ソフトがウイルスと検知するシグネチャが含まれる特殊なファイルで、マルウェア対策ソフトの動作確認などに使われます。

※ EICAR Standard Anti-Virus Test File

まずは、MDfEのデフォルト設定ではリアルタイム保護機能が無効となっているため、"mdatp config"コマンドで有効化します。

wgetコマンドでEICARテストファイル（eicar.com）のダウンロードを試してみます。通常であれば、2回目のlsコマンドでダウンロードしたはずのファイルが表示されるはずですが、対象ファイルが表示されていません。MDfEのリアルタイム保護機能が働き、EICARテストファイルが削除されたことが分かります。

動作比較のため、MDfE未導入サーバーでの動作も確認してみました。こちらはEICARテストファイル（eicar.com）が残存したままとなります。

セキュリティポータルからの確認

MDfEが機能したことを確認するため、Microsoft 365 Defenderポータルへアクセスしてみます。以下のように、EICARテストファイルの検知イベントが表示されています。

※ ホーム - Microsoft 365 セキュリティ

Azure Arcを通して、Azure以外で稼働するサーバーや仮想マシンに対してもMicrosoftが提供するセキュリティ対策/サーバー保護機能を利用できます。また、オンプレ環境やAzureで既にMDfEを利用・運用している場合、AWSのEC2など他クラウドで稼働している仮想マシンも同じ運用に乗せることができるため、監視運用の負荷軽減やナレッジの活用などのメリットがあります。

Update Managementによるパッチ管理

続いて紹介するのは、Update Managementによるパッチ管理機能です。Azure Arc接続マシンに対して評価および更新を実施して、実際にAzure Arc接続マシン上のプログラムが更新されることを確認してみます。

Update Managementについて

Update Managementは、オペレーティングシステムの更新プログラムがあるかの評価、もし更新があった場合の反映指示などを行えます。これにより、運用担当者は各仮想マシンやサーバーへログインせずに、オペレーティングシステムの更新プログラムを管理することが可能となり、パッチ管理のための負担を軽減できます。

Azure上の仮想マシンだけではなく、Azure Arc接続マシンも管理対象にすることが可能です。

Update Managementの動作確認（評価）

Update Managementにおけるパッチ管理には大きく「評価」と「更新」のステップがあります。まずは、Azure Arc接続マシンに対して、更新可能なプログラムがないか「評価」を実施します。

Azure PortalからUpdate Managementを開きます。「マシン」の画面を表示して、対象マシンを選択した状態で「更新プログラムの確認」をクリックします。評価中は更新/アップデートができないというメッセージが表示されますが「今すぐ更新」をクリックします。

評価を開始後、処理が終わるまでしばらく待ちます。評価が完了すると、「更新状態」列に更新プログラムの有無および件数が表示されます。

今回は80件の更新プログラムが検出された「i-096167ed7c25a630a(Ubuntu 20.04)」の詳細を確認してみます。リンクをクリックすることで更新が必要なプログラムの一覧が表示されます。例えば、perl関連だと以下のプログラムで更新が必要と出力されています。

実際に対象マシンへログインして、"apt list -upgradable"コマンドでアップデート可能なプログラムを確認してみても、同様のプログラムが表示されます。

root@ip-10-51-3-100:~# apt list --upgradable | grep perl
 
WARNING: apt does not have a stable CLI interface. Use with caution in scripts.
 
libperl5.30/focal-updates,focal-security 5.30.0-9ubuntu0.4 amd64 [upgradable from: 5.30.0-9ubuntu0.3]
perl-base/focal-updates,focal-security 5.30.0-9ubuntu0.4 amd64 [upgradable from: 5.30.0-9ubuntu0.3]
perl-modules-5.30/focal-updates,focal-security 5.30.0-9ubuntu0.4 all [upgradable from: 5.30.0-9ubuntu0.3]
perl/focal-updates,focal-security 5.30.0-9ubuntu0.4 amd64 [upgradable from: 5.30.0-9ubuntu0.3]
root@ip-10-51-3-100:~#

Update Managementの動作確認（更新）

それでは、Update Managementから更新プログラムのインストールを実行してみます。

先ほどの評価と同様の対象マシンを選択した状態にしてから、「1回限りの更新」をクリックします。メッセージが表示されますが、「Install Now」で次へ進みます。

アップデート対象のマシンが表示されます。「次へ」をクリックします。

更新プログラムの選択画面が表示されます。「更新プログラムの分類で選択」から、更新対象とするプログラムのカテゴリーを選択できます（「セキュリティ更新プログラムと緊急更新プログラム」、「他の更新プログラム」など）。今回はデフォルトのまま、「次へ」をクリックします。

再起動オプションとメンテナンス期間を設定します。再起動オプションは「必要に応じて再起動」、「再起動しない」、「常に再起動」から選びます。今回は「必要に応じて再起動」を選択します。メンテナンス期間ではメンテナンスにかけることのできる最大時間を60～235分の間で設定します。この時間を過ぎても完了しなかった場合、更新処理は「失敗」扱いとなります。今回はデフォルトの235分のままとします。

各種設定が済んだら、「次へ」をクリックします。

確認とインストール画面が表示されます。「インストール」をクリックすると、処理が開始します。

更新結果の確認

しばらく経ってから確認すると、保留中の更新プログラムが無いという状態に変更されています。

実際に対象マシンへログインして確認してみます。

"apt list -upgradable"コマンドを実行しても、アップデート可能なプログラムが表示されず、全て更新済みであることが分かります。また"apt-show-versions"コマンドで、perlのバージョンがアップデートされていることが分かります。

root@ip-10-51-3-100:~# date ; apt list --upgradable
Thu Jun 22 01:22:38 UTC 2023
Listing... Done
root@ip-10-51-3-100:~# 
root@ip-10-51-3-100:~# date ; apt-show-versions perl
Thu Jun 22 01:22:43 UTC 2023
perl:amd64/focal-security 5.30.0-9ubuntu0.4 uptodate
root@ip-10-51-3-100:~#

今回は評価および更新を手動で実行しましたが、定期的に実行させるように設定することで、さらに管理の負担を軽減することができます。オンプレ環境やマルチクラウド上のサーバーにおけるパッチ管理をUpdate Managementにより一元化することで、パッチ管理の運用負担を軽減することができ、パッチ適用の漏れや遅れといったリスクの軽減にもつながります。

Azure Policyによる設定管理

最後に紹介するのは、Azure Policyによる設定管理機能です。

Azure Arc接続マシン上の設定ファイルの権限を確認するポリシーを設定して、不適切な権限となっているAzure Arc接続マシンが検知されることを確認してみます。

Azure Policyについて

Azure Policyは、Azure上のリソースに対して「こう設定しておくべき」「こうしたアクションは禁止すべき」といったルールを決める際に使います。例えば「特定のリソースには、
"Department"タグを設定しなくてはならない」などです。これは、セキュリティ規制に沿った運用やコスト管理、利用ルールの遵守などで利用されます。ルール通りに設定されていないリソースの作成を禁止させることや、ルールに沿っていないリソースがあった場合にそれを自動修正させることも可能です。

Azure Policyには組み込みのポリシーやイニシアティブ（ポリシーをグループ化したもの）が用意されており、必要に応じてカスタム定義を作成することも可能です。組み込みのイニシアティブには「NIST SP 800-53」や「PCIDSS」といった規制コンプラアンスに沿った定義も用意されています。

またいくつかのポリシーはAzure Arc接続マシンにも適用することが可能です。Azure Arc接続マシンに適用できるポリシーは一覧^※から確認できます。

※ Azure Arc 対応サーバーの組み込みポリシー定義 - Azure Arc | Microsoft Learn

Azure Policyの割り当て

Azure Policyにより、Azure Arc接続マシンの設定内容をチェックできることを試します。

今回はサーバー上の設定に関するポリシーのうち、ビルドインポリシーとして用意してある「passwdファイルへのアクセス許可が0644に設定されていないLinuxマシンを監査する」のポリシーを適用してみます。対象ファイルが、"オーナーのみが読み書き可能でそれ以外は読み取り専用"となっていることを確認するポリシーです。

ポリシーの定義画面を表示して、左上の「割り当て」ボタンをクリックします。

基本設定画面が表示されます。スコープにはサブスクリプション単位、あるいはリソースグループ単位で選択します。「次へ」をクリックします。

詳細設定画面が表示されます。デフォルト設定のまま、「次へ」をクリックします。

パラメータの設定画面が表示されます。「Arcに接続されたサーバーを含める」は"true"に設定して、「次へ」をクリックします。

修復設定画面が表示され、マネージドIDの作成有無を聞かれます。今回は検知のみで自動修復は設定しないため、マネージドIDの作成は不要です。そのまま「次へ」をクリックします。

非準拠メッセージ（リソース作成者にポリシー準拠していない理由などを伝えるためのカスタムメッセージ）の設定画面になります。今回は非準拠メッセージの設定は不要なので、そのまま「次へ」をクリックします。

確認および作成画面が表示されます。「作成」ボタンをクリックし、ポリシーをリソースグループに割り当てます。

30分ほど経過すると、ポリシーの準拠状況が更新されます。この段階では2台のサーバー中、2台が準拠というステータスとなります。

Azure Policyでの設定検知確認

上記で割り当てたポリシーを違反した際に、検知できるかを確認するため、「i-096167ed7c25a630a(Ubuntu 20.04)」の仮想マシン上のpasswdファイルの権限を"666"（対象ファイルは全ユーザーによる書き込みが可能）へ変更してみます。

root@ip-10-51-3-100:~# date ; ls -l /etc/passwd
Thu Jun 22 06:32:33 UTC 2023
-rw-r--r-- 1 root root 1989 Jun 16 04:05 /etc/passwd
root@ip-10-51-3-100:~# 
root@ip-10-51-3-100:~# date ; chmod a+w /etc/passwd
Thu Jun 22 06:32:42 UTC 2023
root@ip-10-51-3-100:~# 
root@ip-10-51-3-100:~# date ; ls -l /etc/passwd
Thu Jun 22 06:32:46 UTC 2023
-rw-rw-rw- 1 root root 1989 Jun 16 04:05 /etc/passwd
root@ip-10-51-3-100:~#

設定変更してからしばらく待つと、設定変更したサーバーがポリシー未準拠というステータスとなります。

Azure Arc接続サーバーへAzure Policyを適用する際の注意点

利用する際の注意点として、Azure Policy自体は費用がかからない機能ではあるのですが、Azure Arc接続マシンをAzure Policyでの管理対象とする場合は別途コストがかかります。Azure Arc接続マシンが起動している（接続している）時間に応じて、1リソースにつき$6.00/月（記事執筆時点）が課金される点に注意してください（なお、オフラインとなっている期間は課金されません）。

※ 価格 - Azure Policy | Microsoft Azure

おわりに

今回の記事ではAzure Arcを通して、MicrosoftあるいはAzure管理機能のうち「セキュリティ対策」「パッチ管理」「ポリシー管理」をAWSのEC2に対しても有効にできることを検証しました。

Azure Arcによって各環境に分散しているサーバーの一元管理が容易となります。特に、既にAzureを利用済みでMDfEによるセキュリティ対策やAzure Policyによるポリシー運用の枠組みが固まっている環境においては、他クラウドやオンプレミス環境もAzureと同様に運用していくことが可能になるため、運用手順の共通化や効率化などAzure Arcによる恩恵を大きく受けることができます。

前後編にわたり、Azure Arcへの接続から管理機能の有効化の流れを記載させていただきました。もしご興味をお持ちいただけましたら、この記事を参考にAzure Arcを実際に試してみてはいかがでしょうか。

本記事ではAzure Arcを取り上げさせていただきましたが、ラックではお客様のシステム環境の課題に合わせて、適切なソリューション/サービスを提案させていただきます。マルチクラウドやハイブリッドクラウドのシステム構成に関するお悩みがございましたら、ぜひラックまでお問い合わせください。