2023-12-11

Nutanixにおける「STIG」や「SCMA」の紹介～後編～

AHV CVM Nutanix STIG SCMA Prism Central

※このブログの内容は個人の見識や見解をもとに作成しています。参考にされる場合は自己責任でご活用ください。また、このブログで紹介している製品や機能を使用される場合は、メーカードキュメントの手順に従い実施することを推奨します。

前回の記事では、NutanixにおけるSTIGの実装やレポート発行、セキュリティダッシュボードなどを紹介しました。今回はセキュリティチェック&自動修復機能としてNutanixに標準搭載されている「SCMA」について紹介します。

1. SCMAとは
2. SCMAポリシーの設定状況の見かた
3. 実際に修復してくれるか確認
おわりに

1. SCMAとは

SCMA（自動セキュリティ設定管理 - Security Configuration Management Automation）は、クラスター内のCVMやAHVといったコンポーネントがSTIGなどのセキュリティベースラインを遵守しているかを定期的にモニタリングしており、ベースラインから逸脱している場合は自動修復してくれる機能です。

この機能はNutanixに標準搭載されており、内部で勝手に稼働しているものですので、普段は特に意識する必要はありません。

<参考>
SCMA Implementation
https://portal.nutanix.com/page/documents/details?targetId=Nutanix-Security-Guide-v6_5:sec-security-scma-implementation-wc-c.html

2. SCMAポリシーの設定状況の見かた

SCMAの設定状況はnCLIやセキュリティダッシュボードにて確認できます。nCLIでは、例えば以下コマンドを実行すると、CVMのセキュリティ設定に関わる内容が確認できます。

[nutanix@cvm]$ ncli cluster get-cvm-security-config

実行結果は以下の通りです。例えばSCMAの実行スケジュールがHOURLYになっていることなどが確認できます。

[nutanix@cvm]$ ncli cluster get-cvm-security-config

Enable Aide : false
Enable Core : true
Enable High Strength P... : false
Enable Banner : false
Enable SNMPv3 Only : false
Schedule : HOURLY
Enable Kernel Core : true
SSH Security Level : DEFAULT
Enable Lock Status : false
IP Restriction State : NORMAL
SSH whitelisted addres... :

[nutanix@cvm]$

また、AOS 6.6以降およびPrism Central pc.2022.9以降で使用できるセキュリティダッシュボードの「Security Hardening」ウィジェットでも、SCMA実行のスケジュールが確認できます。

この項目をクリックすると、AHVとCVM個別にSCMA実行のスケジュール設定を変更することができます。

3. 実際に修復してくれるか確認

CVMやAHVの設定がセキュリティベースラインを逸脱すると、SCMAは本当に元のベースラインに設定を戻してくれるのかを確認してみます。

今回は、パスワードの最低文字数の設定をわざとベースラインから外れるように変更してみます。RHELのSTIGガイドラインでは15文字以上のパスワード設定が必要ですが、Nutanixでのデフォルトは最低8文字以上となります。

現在の最低文字数の設定は以下のコマンドで確認できます。

[nutanix@cvm]$ grep minlen /etc/security/pwquality.conf

実行結果は以下の通りです。今回はデフォルト値の8となります。

[nutanix@cvm]$ grep minlen /etc/security/pwquality.conf
minlen = 8

[nutanix@cvm]$

このように、パスワードのセキュリティレベルの設定は「/etc/security/pwquality.conf」に記述されていますので、これをviエディタなどで直接編集します。今回はデフォルト値の「8」⇒「6」に変更してみます。

[nutanix@cvm]$ sudo vi /etc/security/pwquality.conf

#Configuration for systemwide password quality limits
#Defaults:
#
====中略======
#Minimum acceptable size for the new password (plus one if
#credits are not disabled which is the default). (See pam_cracklib manual.)
#Cannot be set to lower value than 6.
minlen = 6
#

====中略======
[nutanix@cvm]$

これで、ユーザパスワードの最低文字数は6文字に設定されました。あとは、次のSCMAチェックまでしばらく放置するだけです。

この記事ではあまりリアル感は伝わらないかもしれませんが、しばらく置いてから再度設定ファイルを確認してみると、以下のようにデフォルト値の「8」に戻されていました。

[nutanix@cvm]$ grep minlen /etc/security/pwquality.conf
minlen = 8

[nutanix@cvm]$

おわりに

いかがでしたでしょうか？「SCMA」はSTIGなどにもとづいたNutanixのセキュリティベースラインを自動チェックしてくれる機能であり、ベースラインからの逸脱があると自動で設定を修復してくれるため、一定のセキュリティレベルを維持し続けてくれることがお分かりいただけたかと思います。

次回はAHVやCVMのセキュリティ強化機能などについて書いてみたいと思います。

2023-12-07

Nutanixにおける「STIG」や「SCMA」の紹介～前編～

AHV CVM Nutanix STIG

Nutanixにおける「STIG」や、それに準拠するためにNutanixがCVMに搭載している「SCMA」について紹介します。Nutanixのセキュリティ実装についての理解にぜひご活用ください。前編では、STIGについて解説します。

1. STIGとは
2. STIGレポートの発行
3. Prism Centralの「セキュリティダッシュボード」でSTIGポリシーの確認
おわりに

1. STIGとは

STIG（Security Technical Implementation Guide - セキュリティ技術導入ガイド）とは、アメリカ国防総省のセキュリティ機関である国防情報システム局（DISA - Defense Information Systems Agency）が公開しているセキュリティ強化のためのガイドラインです。WindowsやLinuxといったOSに限らず、VMwareやNutanixなど様々なベンダー製品に対して、セキュリティベースラインとその設定手順が提供されています。各ベンダーはこのベースラインに準拠しつつ、独自のカスタマイズを加えて製品のセキュリティレベルを最適化しています。

STIGのガイドラインはDISAのサイトで一般公開されており、誰でも見ることができます。
https://public.cyber.mil/stigs/

▽リンク先のドキュメントライブラリで例えば「nutanix」と検索すると、Nutanix AOSでのSTIG実装ガイドやその手順がダウンロードできます。

▽また「Red Hat」で検索すると、RHEL用のSTIGも公開されています。

▽これらをダウンロードしたものの中に、XML文書（+XSL）がありますので適切なブラウザ設定で展開すると以下のようなガイドが確認できます。これがSTIGの生のガイドラインです。

▽スクロールして中身を確認すると、例えば以下のような項目と手順が確認できます。

このような細かい設定内容がこのドキュメントでは100項目以上公開されています。

▽また、NutanixのコアコンポーネントであるCVMやAHVはCentOSであるため（AOS 6.5時点）、RHELのSTIGが導入されています。RHELのSTIGについては例えば以下のような内容が公開されています。

NutanixはSTIGの導入について以下のページで紹介しており、RHELのSTIGにおける独自の実装についても言及していますので、併せてご確認ください。
DISA STIG Guidance Reference
https://portal.nutanix.com/page/documents/details?targetId=Nutanix-compliance-for-RHEL-STIGs-v6_5:Nutanix-compliance-for-RHEL-STIGs-v6_5

2. STIGレポートの発行

AOS 6.6以降では、CVMからのコマンド操作でSTIGのレポートを作成することができます。手順に従ってレポートを発行すると以下のようなテキストファイルやHTMLベースのレポートが作成され、STIGの遵守状況を確認することが可能です。

テキストファイル

HTMLファイル

コマンドラインでのSTIGレポート発行方法については以下をご参照ください。

Generating STIG Compliance Report
https://portal.nutanix.com/page/documents/details?targetId=Nutanix-Security-Guide-v6_7:sec-stig-report-create-pe-ncli-t.html

3. Prism Centralの「セキュリティダッシュボード」でSTIGポリシーの確認

AOS 6.6以降およびPrism Central pc.2022.9以降が導入されている場合は、Prism Central Webコンソールにて「セキュリティダッシュボード」が利用可能です。

▽セキュリティダッシュボードのSTIGポリシーウィジェットにて、STIGの準拠状況が確認できます。以下画面の例では、RHELのSTIGガイドラインのうち18項目が設定されていない（Failed）ことを示しています。

▽さらに中身を見てみると、RHEL STIGのどの項目がFailedとなっているのか確認できます。

Nutanixのデフォルト設定では、RHEL STIGのすべての項目に準拠するようにガチガチの設定でクラスターが構成されるわけではありませんが、利用者にて後で設定変更する際には、何が設定されていないのかが視覚的に見やすいので便利です。

Security Dashboard
https://portal.nutanix.com/page/documents/details?targetId=Nutanix-Security-Guide:mul-security-dashboard-overview-pc.html

おわりに

いかがでしたでしょうか？前編では、NutanixにおけるSTIGの実装について紹介しました。みなさまのNutanix製品理解の一助となれば幸いです。後半では、SCMAについて解説します。

次回: Nutanixにおける「STIG」や「SCMA」の紹介～後編～

2023-10-02

Nutanix File Analytics の監査データ保持期間（v3.3.0時点）

Nutanix Filesのデータ分析や監査データの確認ツールとして使用可能な「File Analytics」の監査データ保持期間は最大1年間です。（v3.3.0時点）

1年間を超えるデータは、欲しいデータをCSVで定期的にエクスポートして保存するといった事を検討する必要があります。

以上。

2023-09-25

HYCUのバックアップチェーンについて

HYCU Nutanix

2023-09-13

Nutanix Moveで仮想マシンをAHVからAWS EC2へ移行してみる

AHV AOS AWS Nutanix Move

今回はNutanix AHV上の仮想マシンをAWS EC2へ移行してみます。

今回の環境

4ノードのNutanix AHVクラスター
プラットフォーム: NX-1465-G5
AOS: 6.5.3.5 LTS
Move: 4.9.1
移行対象VM: Windows Server 2019

今回の作業イメージは以下の通りです。

1. 移行対象のVMに対する事前準備

仮想マシンをAWSへ移行するためにはいくつかの要件や事前準備項目があります。ドキュメントから抜粋したものを以下に示しました。（Move 4.9.1時点）

サポートされるOS
- Windows Server 2012 R2, 2016, 2019
- RHEL 6.8 ～ 6.10、7.3 ～ 7.5
- CentOS 6.8 ～ 6.10、7.3 ～ 7.5
- Ubuntu 14.04, 16.04, 18.04
WinRM, RDP, SSH を有効化（Windowsの場合）
Nutanix Guest Tools（NGT）をインストール

※要件や制限事項の詳細は以下リンク先をご確認ください。
▽Migration Considerations
https://portal.nutanix.com/page/documents/details?targetId=Nutanix-Move-v4_9:top-migration-considerations-ahv-aws-c.html

2. AWS側の準備

AWS EC側では、リージョンやアベイラビリティゾーン、移行先のネットワーク（VPC）などを事前に準備しておく必要があります。また、Moveへの環境登録時にはAWSアカウントの「アクセスキー ID」と「シークレットアクセスキー」が必要となります。

MoveからAWSに対して操作を実行しますので、登録時に使用するAWSアカウントには、IAMにて特定の権限（許可）を持たせておく必要があります。

多くの場合、管理者権限を持つアカウントであれば対応できるかと思いますが、Moveのドキュメントでは許可ポリシーで必要な権限のリストがJSONで公開されていますので、必要に応じてAWSユーザーに権限を持たせておきます。

▽許可ポリシー作成の画面

Nutanixで公開されているJSONは以下をご参照ください。
▽Requirements (AHV to AWS)
https://portal.nutanix.com/page/documents/details?targetId=Nutanix-Move-v4_9:top-requirements-ahv-aws-r.html

3. Move VMのデプロイ

Nutanix Moveは仮想アプライアンスとして提供されており、移行元のAHVクラスター上に仮想マシンとしてデプロイして使用します。

Moveのデプロイ方法については以下記事をご参照ください。
Nutanix MoveをAHVへデプロイしてみる（Prism GUI編） - NutaNice Xperience

4. Moveへの環境登録

デプロイしたMoveのWebコンソール画面から移行元AHVと移行先AWSを登録します。

AHV環境の登録方法は以下記事をご参照ください。
MoveでのAHV環境の登録

AWS環境の登録方法は以下記事をご参照ください。
MoveでAWS環境の登録

5. 移行プランの作成

環境の登録ができたら移行プランを作成します。
▽Moveコンソールにて「Create a Migraton Plan」をクリックします。

▽移行プランに名前を付けて「Proceed」をクリックします。

▽以下のように設定していきます。

▽続いて移行対象の仮想マシンを選択します。今回は「MovetoAWS」という名前のWindows Server2019仮想マシンを選択しました。ちなみに、NGTが対象のVMにインストールされていない場合、この時点で仮想マシンを選択できない仕様となります。

▽次の画面で移行元AHVネットワークと移行先AWSネットワーク設定をします。移行先のAWSでは、ネットワークとサブネット、セキュリティグループを選択します。

▽続いて準備モードで今回は「Automatic」を選択します。

▽Windowsの管理者権限のあるアカウントのID／PWを入力します。※複数の仮想マシンでID／PWが異なる場合は「Change settings」から個別に入力することも可能です。

▽今回はプライオリティを「Medium」に設定します。AWS移行後にパブリックIPアドレスを持たせたい場合は「Create Public IP Address」にチェックを入れます。ちなみに「Schedule Data Seeding」では、移行対象の仮想マシンスナップショットのレプリケーションを開始する日時を指定することができます。

▽サマリ画面で設定内容を確認したら「Save and Start」でプランを実行します。すぐに実行したくない場合は「Save」でプランの保存のみも可能です。

6. Seeding（レプリケーション）の実行

▽プランが検証されて、実行に移ると「In Progress」と表示されますので、「In Progress」をクリックしてタスクの実行状況を追跡します。

▽Moveコンソールでは、対象VMのスナップショットが取得され、AWSへレプリケーションされている様子が確認できます。また、AWS EC2のEBSにてレプリケーションされたスナップショットも確認できます。「移行」を実行するまで、最新のスナップショットがデフォルト10分間隔でレプリケーションされ続ける仕組みとなります。

7. Cutover（移行）の実行

移行先に仮想マシンを切り替えたいというタイミングで「Cutover」というボタンをクリックします。「Cutover」を実行すると、移行元の仮想マシンが停止して最後のスナップショットがレプリケーションされたのち、移行先のAWS EC2でインスタンスが作成されます。

リモートデスクトップで接続したところ、移行したWindowsにログインできました。

ちなみに、移行元の仮想マシンは停止しているだけですので、何かの事情で移行元の仮想マシンが必要となった場合はそのまま電源を入れて使用できます。

その他ナレッジ

AWS認証エラーについて

AWS環境の登録時や、移行プランの作成・検証でMoveがAWSにアクセスしているタイミングで以下のようなエラー画面が何度も出てきました。

AWS GetRegionNames failed with error: AuthFailure:~~~~~~~~~

AWSへのアクセス認証に失敗しており、提供されたアクセス情報を検証できないというエラーです。私の場合は、何度も再実行すると、認証が通ったりしましたので、何らかの原因で不安定な状態になっていたのかもしれません。

もし許可ポリシーなども正しく設定しているのに、認証エラーになるといった、同様の事象に遭遇している方がいれば参考にしてみてください。

サポート外のOSについて

Move 4.9.1時点で、ドキュメント上Windows Server 2022はサポート対象外ですが、実際に移行できるのかやってみたところ、移行プラン作成後にサポート対象外としてエラーとなりました。（※自動準備モードでエラーとなるなら、手動モードでスクリプトを準備すればいけるのかもですが...。）

Windows Server 2022はMoveの現行バージョンでは移行できませんので、将来バージョンのリリースを待つか、別の方法を考える必要があります。

移行後のAWS インスタンスタイプについて

移行元AHVでの仮想マシンのvCPUやメモリサイズに応じて、移行先AWSではどのインスタンスタイプが選択されるのかを3パターンに分けて検証したところ以下のようになりました。

移行後のOS側からも、インスタンスタイプ通りのリソースが確認できます。

上記の事から、移行元のvCPU、メモリサイズをカバーするようにAWS EC2側でインスタンスタイプが自動選択されていることが分かります。（移行元よりもリソースが少ないという状態にはならない。）

終わりに

今回はNutanix AHV上の仮想マシンをAWS EC2上へ移行する方法を紹介しました。このようにMoveではパブリッククラウドにも仮想マシンを移行することができますので、皆様の今後のハイブリッド・マルチクラウド戦略にぜひご活用いただければと思います。

<参考>
Move User Guide Ver 4.9.1 > AHV to AWS
https://portal.nutanix.com/page/documents/details?targetId=Nutanix-Move-v4_9:top-ahv-to-aws-vm-migration-c.html

2023-09-12

HYCU Backup Controllerをアップグレードしてみる【Nutanix AHV】

AHV HYCU アップグレード

この記事では、Nutanix AHV環境における、HYCU Backup Controllerのアップグレード方法を紹介します。

今回の環境

AOS: 6.5.3.5 LTS
AHV: 20220304.420
HYCU Backup Controller 更新前: 4.7.1-183
HYCU Backup Controller 更新後: 4.8.0-3273

今回の作業イメージは以下の通りです。

ちなみに既存のHYCUバージョンは以下の通りです。今回は、このHYCUをアップグレードします。

HYCU Backup Controllerのアップグレード

▽はじめに、Nutanix AHV環境のPrism Webコンソールへログインし「イメージ設定」画面で、HYCUの新しいOSディスクイメージファイルをアップロードします。ディスクイメージファイルはHYCUのポータルサイトからダウンロードしてください。一点注意点ですが、イメージファイル名はアップロードするHYCUのバージョン名と必ず同じになるように名前を付けてください。（名前を間違えるとアップグレードに使えません）