Workload Security使ってみた
目次
- はじめに
- Workload Securityとは
- 構成
3-1 構成図
3-2 製品動作 - 導入手順
4-1 構築概要
4-2 エージェントサーバ設定
4-3 エージェントサーバのセットアップ
4-4 User Directory Collectorsの作成
4-5 Data Collectorsの作成 - 動作確認
5-1 監査機能
5-2 攻撃シミュレーション - まとめ
1. はじめに
こんばんは。入社4年目のKです。
突然ですが、皆様はランサムウェア対策できていますでしょうか？
ランサムウェアとは、感染したシステム内のデータを暗号化し、復号のための身代金を要求する悪意のあるソフトウェアのことです。
ランサムウェア攻撃は、近年ますます巧妙化し、企業や個人にとって重大な脅威となっています。
この種の攻撃は、組織の業務停止や個人情報漏洩を引き起こし、多大な損害をもたらします。
したがって、ランサムウェア対策は情報セキュリティ戦略の中で極めて重要な位置を占めています。
今回はランサムウェア対策(特に侵入後検知)サービスである、NetApp社のWorkload Securityの構築と動作確認してみましたので、ご紹介します。
2. Workload Securityとは
Workload Security(旧：Cloud Secure)とは、インフラを可視化できるクラウドインフラ監視ツールであるCloud Insightsの機能の1つです。
管理ポータル画面では、ファイルに対するアクセスユーザ、操作(Read/Writeなど)、アクセス元IPアドレス、アクセス日時などがリアルタイムで表示されます(実際の画面は5章の動作確認でご紹介します)。
また、高度な機械学習と異常検出機能により、「Potential Attacks」と「Warnings」の2つの区別で異常なオペレーションを検出し、それに対して管理者への通知やSnapshotの取得などが実施できます。
3. 構成
3-1 構成図
今回構築を行った環境の構成図です。
必要なコンポーネントは下記の通りです。
・ドメインコントローラ
・エージェントサーバ
・NetApp FAS
3-2 製品動作
ファイル操作が行われると、NetApp FASはファイル名やアクセスの内容、アクセスしたユーザ情報などのデータの送信を行います。
そして、取得したデータの解析と分析を行います。ユーザデータについては、エージェントサーバが 12時間ごとに取得しており、Cloud Insightsにて、同期された情報を保持します。
4. 導入手順
4-1 構築概要
以下の流れで構築を行いました。
※本検証では⑥の手順まで実施
<Point>
GUI上での難しい操作がなく、ONTAPに関する基本的な用語を押さていれば導入は難しくないと感じました。今回の構築では、エージェントサーバの構築から開始して2時間程度で構築ができました。
4-2 エージェントサーバ設定(表番号①)
注：OSの初期セットアップについては本稿では割愛させていただきます。エージェントサーバの詳細な要件については下記をご確認ください。
公開情報
https://docs.netapp.com/ja-jp/cloudinsights/concept_cs_agent_requirements.html
一部抜粋
| コンポーネント | Linux 要件 | 備考 |
| オペレーティングシステム | ・Red Hat Enterprise Linux 7.x、8.x 64ビット、SELinux ・CentOS 8 Stream (64-bit), SELinux ・OpenSUSE Leap 15.3から15.5 (64-bit) ・Oracle Linux 8.6 – 8.8, 9.1から9.2 (64-bit) ・Red Hat Enterprise Linux 8.6から8.8, 9.1から9.2 (64-bit), SELinux ・Rocky 9.2 (64-bit), SELinux ・SUSE Linux Enterprise Server 15 SP3から15 SP3 (64-bit) ・Ubuntu 20.04 LTSまたは22.04 LTS (64-bit) | 専用のサーバを使用することが推奨されています。 |
| CPU | 4 個の CPU コア | |
| メモリ | 16GB の RAM | |
| 使用可能なディスクスペース | /opt/netapp 36 GB | 推奨はされていませんが、Cloud Insights acquisition unitやエージェントと共存することが可能です。 その場合は、下記が要件となります。 50-55 GB /opt/netapp 25-30 GB /var/log/netapp 25 GB |
| ネットワーク | ・100 Mbps~1 Gbpsイーサネット接続 ・静的IPアドレス ・すべてのデバイスへのIP接続 ・ワークロードセキュリティインスタンスへの必要なポート（80または443） |
今回は、以下のスペックでVMware ESXi上にサーバを構築しました。
OS ：CentOS 7 ※現在はサポートが終了しているので別OSを推奨
CPU ：4コア
メモリ ：16GB
ディスク ：50GB
準備として「unzip」が必要となるのでインストールしておきます。
yum install unzip 4-3 エージェントサーバのセットアップ(表番号②～④)
Cloud Insightsにアクセスし、[Set up Workload Security]をクリックします。
セットアップの流れが表示されます。
確認後、[Hide This Page]をクリックします。
Agentの画面が表示されるので、[+ Agent]をクリックします。
インストール用のコマンドをコピーして、エージェントサーバ上で実行します。
今回構築した環境ではプロキシを利用していないため、インストール用のコマンドのみ実行しました。
エージェントが登録されました。[Status]が[Connected]になっていることを確認します。
構築後に[・・・]から名前を変更することが可能でしたので、[kensyo]に変更しました。
公開情報
https://docs.netapp.com/ja-jp/cloudinsights/task_cs_add_agent.html
4-4 User Directory Collectorsの作成(表番号⑤)
[User Directory Collectors]タブに移動し、ドメインコントローラと連携をします。
[+ User Directory Collector] をクリックします。
[Active Directory]を選択します。
以下を入力し作成を行います。
Name
・任意のコネクター名
Agent
・「4-3 エージェントサーバのセットアップ」の手順で構築したエージェント
Server IP/Domain Name
・ドメインコントローラのIPアドレスまたはFQDN
Forest Name
・フォレスト名
BIND DN
・ユーザ情報の問い合わせに必要となるユーザ
・Domain Read Only以上の権限が必要
・ドメイン\ユーザ名の形式で入力
BIND Password
・「Bind DN」で指定したユーザのパスワード
その他の項目はすべてデフォルト値で作成しました。
[Status]が[Running]になっていることを確認します。
公開情報
https://docs.netapp.com/ja-jp/cloudinsights/task_config_user_dir_connect.html
4-5 Data Collectorsの作成(表番号⑥)
[Data Collectors]タブに移動し、ONTAPと連携をします。
[+ Data Collector] をクリックします。
今回はNetApp FASのデータを取得するため、[ONTAP SVM]を選択します。
他にもFSxNやCVOと連携することも可能です。
以下を入力し作成を行います。
Name
・任意のコネクター名
Agent
・「4-3 エージェントサーバのセットアップ」の手順で構築したエージェント
Connect via Management IP for
・クラスタIPかSVMのIPどちらでアクセスするかを指定
※今回はクラスタ管理IPを指定
SVM Name
・SVMの名前
※名前が不明な場合は下記コマンドで確認が可能
vserver showCluster management IP Address
・クラスタ管理IP
※IPが不明な場合は下記コマンドで確認が可能
network interface show -role cluster-mgmtUsername
・クラスタにアクセスするためのユーザ名を指定
<Point>
公開ドキュメントにも記載がありますが、弊社の環境でもクラスタ管理管理者によるアクセスができませんでした。
クラスタ管理管理者ユーザがワークロードセキュリティを使用してONTAP SVMデータコレクタにアクセスできない場合は、次のコマンドに示すロールを持つ「csuser」という新しいユーザを作成できます。
そのため、手順に従いユーザを作成しました。
security login role create -role csrole -cmddirname DEFAULT -access readonly
security login role create -role csrole -cmddirname "vserver fpolicy" -access all
security login role create -role csrole -cmddirname "volume snapshot" -access all -query "-snapshot cloudsecure_*"
security login role create -role csrole -cmddirname "event catalog" -access all
security login role create -role csrole -cmddirname "event filter" -access all
security login role create -role csrole -cmddirname "event notification destination" -access all
security login role create -role csrole -cmddirname "event notification" -access all
security login role create -role csrole -cmddirname "security certificate" -access all
security login create -user-or-group-name csuser -application ontapi -authmethod password -role csrole
security login create -user-or-group-name csuser -application ssh -authmethod password -role csrolePassword
・「Username」で指定したユーザのパスワード
Filter Shares Name
・この後のパラメータと組み合わせて監視対象の共有やボリュームを指定することが可能
Share Names
・監査対象の共有を指定
・カンマ区切りで複数指定することが可能
※名前が不明な場合は下記コマンドで確認が可能
cifs share show -fields share-nameVolume Names
・監査対象のボリュームを指定
・カンマ区切りで複数指定することが可能
※名前が不明な場合は下記コマンドで確認が可能
volume show -fields volume
公開情報
https://docs.netapp.com/ja-jp/cloudinsights/task_add_collector_svm.html
5. 動作確認
5-1 監査機能
Alerts
選択した期間内に発生した攻撃および警告の総数、およびその期間内に発生した攻撃または警告のリストがグラフで表示されます。
Forensics
ファイルに対して実行されるアクションが表示されます。
Policies
攻撃および警告が発生した際に、アクセスの停止やSnapshotの取得を設定することが可能です。
5-2 攻撃シミュレーション
NetApp社が公開しているシミュレーションを行い、アラートを発報しました。
テスト用のファイルを作成し、シミュレーションスクリプトを使用して、それらを暗号化するといったものです。
注意点として、短期間に同じユーザで複数回実施すると、警告されないようです。
ユーザに対してランサムウェア攻撃を生成した後、別のユーザに切り替えて追加の攻撃を生成します。
Workload Security はユーザの動作を学習し、同じユーザに対して短期間にランサムウェア攻撃が繰り返されても警告しません。
実際に検知をするとメールが届きます。
6. まとめ
今回はWorkload Securityをご紹介させていただきました。
導入も簡単で、管理ポータル上に利用状況がグラフで表示されるため、視覚的に分かりやすく、非常に便利なサービスだと感じました。
今回は、アラート検知時のアクセスの制御やSnapshot作成の検証ができなかったので、またの機会に確認してみようと思います。
1ヶ月のトライアルもできるので、興味がある方はぜひ実際に利用してみてください。
