この記事について
昨今ランサムウェアという単語は、耳にタコができるほど業界を飛び交っております。というのも、昨今では、残念ながら犯罪者側が有利な状況が存在します。ダークウェブでは、この瞬間においても、ランサムウェアキットが月額$100程度で販売されています（なんとサポート付き！）。約2/3の被害者は身代金を支払っても、データが完全に復号できずという状況です。一方で、被害に遭われた企業や組織の内、半分以上の方々は、事前に取得したバックアップデータからの復旧に成功しています。
このような状況を背景に、NetAppの技術を活用することで「もっと効率的に！もっと高速にできる！」という点を知っていただきたく思い、以前ハンズオンイベントを開催いたしました。この記事では当日使用したハンズオン環境の技術的な解説をしていきます。
使用したソリューション
・Amazon FSx for NetApp ONTAP（以降、FSxNと記載）: https://aws.amazon.com/jp/fsx/netapp-ontap/
・NetApp Cloud Insights(Secure) : https://cloud.netapp.com/ja/cloud-insights
ハンズオンの内容
事前準備
| 関連部位 | 作業 |
|---|---|
| EC2(AD) | 参加者人数分のユーザー作成 |
| EC2(Jump Host, Attacker) | 参加者人数分のインスタンス作成 |
| FSx for NetApp ONTAP | FSxN, SVM, 参加者人数分のボリュームの作成 |
| FSx for NetApp ONTAP | FSxNの作成に伴い、SVMをAD参加させる |
| EC2(AD) | 各ユーザーからFSxNのボリュームにアクセスできるようマウントパスを通しておく |
| FSx for NetApp ONTAP | 各ユーザに割り振られたボリュームに大量のファイルを作成しておく |
| EC2(Attacker) | ランサムウェア攻撃をシュミレートするスクリプトの配置 |
当日のプログラム
| 説明 | |
|---|---|
| 1 | 事前準備の最後で配置したスクリプトを起動する |
| 2 | 事前準備で作成したデータファイルが、速攻で暗号化されていく |
| 3 | Cloud Secure(NetAppのセキュリティ監視ツール)が、感染したユーザーの異常行動を検知し、ユーザの権限を凍結 |
| 4 | 暗号化が途中で止まる |
| 5 | データファイルの論理的なバックアップイメージである「Snapshot」を元に、暗号化されたファイルを復旧してい |
実際に攻撃を受けてから、ファイルを完全復旧する所まで一貫して体験いただくことによって、有事の際でも迷うことなく復旧のオペレーションに取り掛かかれるようコンテンツを組みました。
環境概要
今回のハンズオンで使用したAWSの環境はざっくりこんな感じです↓
ネットワーク
VPCとサブネット
AWS環境という事で、今回のハンズオン用に新規でネットワークを構成しました。
VPCの中にインターネットへ接続できるPublic Subnetと、接続無しのPrivate Subnetを配置しています。
加えて、Public Subnetが外と通信できるようにInternet Gatewayと、Route Tableも作成し、サブネットに繋げています。
セキュリティグループ
セキュリティグループはPublic SubnetとPrivate Subnet用に各一つ、加えて今回使用したFSxN用に一つと計3つ作成しています。
Ingress/Egressについては各要件(主にCloud Secureの通信要件)に合わせて構成しています。
| セキュリティグループ | Ingress | Egress |
|---|---|---|
| Public Subnet-sg | VPC内CIDR + Cloud Secure 通信要件* + RDP用使用する端末のIPアドレス | すべて許可(0.0.0.0/0) |
| Private Subnet-sg | VPC内CIDR | すべて許可(0.0.0.0/0) |
| FSxN-sg | VPC内CIDR | すべて許可(0.0.0.0/0) |
Cloud Secure 通信要件*について詳しくは以下のリンクからのwhite paperの下の方を参照ください。
https://docs.netapp.com/us-en/cloudinsights/concept_cs_agent_requirements.html#cloud-network-access-rules
EC2
Jump Host
その名の通り、踏み台サーバーを各ユーザーごとに作成しています。Jump HostにRDPし、そこから更にAttackerのインスタンスにRDPします。RDP接続にインターネット接続が必要となるため、Public Subnetに配置しています。
感染用Windowsサーバ
最小権限の原則に基づいて、AttackerはPrivate Subnetに配置しています。ランサムシミュレーション後は使用しないので、本当に必要最低限で。
(最小権限の原則とは、コンピューティング環境において、正当な目的に必要とされる情報と計算資源のみにアクセスできるように制限する設計原則です。)
Active Directoryサーバ
こちらも本番中はRDPなどしないので、Private Subnetに配置しています。準備段階では頻繁に接続するので、ADのEC2でRDP接続する用に、もう一台AD専用のJump Hostがあっても便利です(私は作りました。)
Cloud Secure Agent
今回のデモの肝にあたるCloud Secureの攻撃検知を行うために、ネットワーク内にCloud Secureのエージェントを配置する必要があります。本元のCloud Secureに検知報告をしなければいけないため、Public Subnetに配置しています。使用するEC2のスペックは少々高性能なものが要求されます。主なポイントは以下です。
| コンポーネント | 要件 |
|---|---|
| OS | Red Hat Enterprise Linux 7/8 or CentOS 7/8 or Ubuntu 20~22 |
| CPU | 4 CPU cores |
| Memory | 16GB RAM |
| 容量 | 最低35GB(ログ含めると50GB) |
詳しくはCloud Secureスペック要件の上の方を参照ください。
https://docs.netapp.com/us-en/cloudinsights/concept_cs_agent_requirements.html#cloud-network-access-rules
ストレージ
Amazon FSx for NetApp ONTAP
使用したストレージはAWSが提供しているフルマネージド型サービスのファイルシステムです。
なぜEC2にくっついているEBSを使わなかったというと、暗号化されたファイルの復旧にsnapshotを使用するからです。
snapshotといっても、ごく一般的なものではなく、NetAppが技術特許を取得している論理的なデータのバックアップイメージのsnapshotです。
ポインタ情報のみで完結するため、他のsnapshot技術と比較し、迅速な取得と復元、容量効率に優れた保管が可能です。
NetAppのsnapshotの詳しい仕組みは以下URLからご参照ください。
https://www.netapp.com/media/19746-ds-2477.pdf