「バックアップソリューションでありながら、”ランサムウェア対策に強いRubrik”という位置づけも認知されだした印象がありますが、実際のところいかがでしょうか？」

「ありがたいことに、特にランサムウェア対策要員として、弊社でも多くのお問合せをいただいております。お客様自身がランサムウェアに感染してしまったケースや、同業他社が感染したニュースも多く取り上げられているため、対策を強化しようと検討を進める企業様が多いようです」

「実際にNetworldでもお問合せはもちろん、実績もかなり増えています。バックアップ製品として展開されるRubrikですが、肝心のバックアップ機能のアップデート状況はどうでしょう？」

「新興系のバックアップベンダーとして2014年に設立して9年、日本進出から5年以上が経過していますが、かなり進歩していると自負しています。バックアップにおける国内実績も順調ですね。

中でもセキュリティおよびランサムウェア対策機能に関しては、早い段階から取り組んできましたから、特に最近ではその点が多くのお客様に評価され始めているという認識です」

「”ランサムウェア対策に強いRubrik”を実案件からも掘り下げていきますと、吉田さんとわたしで担当した案件の中には、まさにランサムウェア感染真っ最中！な対応事例なんかもありましたよね？」

「ありましたね。お客様のファイルサーバーがランサムウェアによって暗号化されてしまって、データ復旧中にRubrikを導入した事例でした。復旧したそばですぐにバックアップおよび、データ保護を実施できるとして、お客様にはすぐに導入を決定していただきましたね」

「もし暗号化される前に導入していたら、また違った対処ができたかもしれないと思っていたのですが、このあたりのRubrikの優位性を教えていただけますか？」

「暗号化に対するRubrikの強みですね。そのようなケースでは、Rubrikの『ふるまい検知』が有効です。Rubrikでは、日々のバックアップを時系列に沿って分析できます。あるファイルが編集、追加されたなどの挙動を機械学習による分析で比較し、今までにない異常な動きがあればアラートを出したり、具体的にファイルを特定・一覧化・対処したりすることが可能です」

「この図を見ると、RubrikさんのSaaSサービス上でデータが分析されるようですが…実データをSaaSに送る必要があるのでしょうか？」

「SaaS環境では、あくまでふるまいだけを分析しています。いわゆるメタデータ（属性情報）は送りますが、実データをクラウド上に送る必要はないので、安心してお使いいただけます」

「実は『クラウドにアップロードしなきゃいけないの？』と誤解されるお客様も多いのですが、メタデータのみなら安心ですね」

「ちなみに吉田さん、『ふるまい検知機能』って検証できるのでしょうか？」

「はい。今回はファイルを暗号化するツールを特別に利用して、ふるまい検知機能の検証をしてみました」

「ファイル暗号化…大丈夫ですか？」

「この暗号化ツール…実はRubrikさんから提供していただいたものなんです」

「Rubrikでは、過去のランサムウェアの攻撃方式を検証し、Rubrikの機能がただしく動作するかを常にシミュレートしています。本ツールはシミュレート結果をもとにし、ユーザーに提供するために作成したシミュレーターです」

「なるほど、ちょっとドキッとしちゃいました(笑)PoC環境にも役立ちそうなシミュレーターも提供されているんですね」

「はい。実際の攻撃に寄せることで、対策準備も本番と同じ感覚で進められるので、皆さんよく活用されていらっしゃいます」

「ではさっそく検証の中身を見ていきましょう。まず、検証環境ですが、このようにファイルサーバーの中にオフィス系のファイルが複数入っています」

「今回は、このファイルサーバーのバックアップを、暗号化の前後で取得（仮想マシン単位）して、ふるまい検知機能を検証します。

1. ① 暗号化前に1回目のバックアップ
2. ② 暗号化
3. ③ 暗号化後に２回目のバックアップ

という３工程で、ふるまい検知がどう働くかを見ていきます」

「暗号化前後の差異、つまりファイルが暗号化されていることを、暗号化前と後のバックアップでただしく比較検出できるかどうかを確認するというわけですね。結果はどうなったのでしょう？」

「はい、結果はこちらです」

「先ほどのデモで、暗号化される前のデータをあっさり探し出してくれたかと思うのですが、これは管理者にとって非常にありがたい機能ですね」

「はい。今回はデモとして1台のサーバーだけでしたが、複数のサーバーを利用しているときなどはデータの検索がとても大変です。どのファイルをいつの地点まで戻せばいいのかを自動で提示してくれるのは、すばらしい機能かと思います」

「あまり他社さんでは見かけない機能ですが、Rubrikさん独自の機能でしょうか？」

「そうですね。先ほどの画面ではファイル単位で戻す例でしたが、たとえばVMをまるごと戻すケースでも、どの地点まで戻せばいいかを一覧で提示してくれます。RECOVERY FULL SNAPSHOTリンクから進んでいただけると…」

「ここでは過去に取得したバックアップの一覧が表示されます。最新のバックアップはオレンジのマークがついていますが、これはランサムウェアによって暗号化されたファイルを含んでいるというしるしです」

「17日のところに勲章のようなベンチマークがついていますが、17日以降が危険性をはらんでいるということで、17日より前のものであれば安全なデータを復旧できることを示しています。これをRubrikでは『サジェスティッドリストア』と呼んでいます。つまり有効リストアの提案ということですね」

「これならファイル単位でなくVMまるごとリストアしたほうが早い場合などでも、どの地点から復旧すべきかがすぐにわかるというわけですね」

「そうですね。もちろんこれだけですべて安心というわけではありませんが、一つの判断材料としていただいてよいかと思います。特に台数が増えれば増えるほど有効なので、大規模環境などにも役立つ機能です」

「スピーディにリストアするという意味では、インスタントリカバリという機能もあるとお聞きしています」

「はい。リストア対象かどうかを判断するまでの時間短縮は、先ほどのふるまい検知で行っていただきます。そこから先の、実際の復旧までの時間短縮に関しては、インスタントリカバリ機能が有効です。これは、Rubrikを一時的にストレージに見立てて、直接VMを起動させることができる機能です」

「あるべきところにデータを戻す前に、まず復旧させてサービスを継続させたいときに活用できる機能ですね」

「そうです。その後、落ち着いたタイミングで、ストレージvMotion機能などを使ってデータをあるべき場所に戻します。インスタントリカバリ機能によって、サービスを停止させることなく、VMを数分で起動させることができます」

「ちなみに、Rubrikをストレージとして見立てたあとも、データが更新されることもあるかと思いますが、その更新差分データはどこに書き込まれるのでしょうか？」

「Rubrik内のSSD領域に書き込まれていきます」

「データをあるべき場所に戻す場合には、更新分も反映した状態で戻すことが可能です。ただし、バックアップデータは取得した状態を保持することが大切なので、バックアップデータ自体は更新されません」

「なるほど…もう少し踏み込んだところを聞かせてください。SSD領域に差分データが書き込まれるとのことですが、実際何台分くらいのVMを同時に立ち上げられるのでしょうか？複数のVMを同時に起動させているユーザーも多いと思いますが」

「Rubrikでは２つのモデルを展開しており、SSD小モデルで同時起動台数…」

「ここからは、具体的にRubrik内にどのように保存されるかというお話ですが、たとえば我々がパッチファイルと呼んでいる、追記のみ可能（削除・編集不可）な独自ファイルを作成してそこにバックアップデータを保存するという方式も可能です」

「このパッチファイルはRubrikが特許を取っているものですが、一度書いたデータは上書きされず、別のファイルとしてデータを追記し、それを参照して最終的に合致させるという手法がとられています」

「なるほど…その手法だと、容量が足りなくなったりしませんか？」

「ポリシーに沿ってデータの保存期間（日数単位）を設定可能なので、ユーザー様に合った形で設定していただければと思います」

「サイジング次第ということですね」

「そういうことですね。さらにパッチファイルで保存したデータを取り出す際の整合性も、フィンガープリントという仕組みで保証しています」

「フィンガープリントとは英語で『指紋』のことを指しますが、要するにデータの並びを数値化するチェックサムと、中のデータを比較し、整合したらデータ取り出し、万が一不整合なら修正（ロールバック）するという仕組みになっています」

「そもそもイミュータビリティな環境を作れるかつ、データの整合性も担保できると」

「はい。パッチファイルによる独自ファイルシステムで改ざん防止を図っているので、入ってきたデータと外に出るデータで変更が生じていることはそうそうないかと思いますが、万が一の対策として整合性を担保しています」

「最近のランサムウェアは、パスワードやIDを盗み取り、まるで人間のようにふるまって、正面から堂々と侵入してくるケースも多いと聞きます。Rubrikさんでは、どのような認証方式を採用しているのでしょうか？」

「一番簡単なのは、スマホと連動したOTP（ワンタイムパスワード）ですね。スマホに送られてくる一時的にしか利用できないパスワードを入力してからでないと、ログインできない方式も採用されています」

「あとはSSO（シングルサインオン）連携も可能です。SSO機能をもったサードパーティツールと連携することで、シングルサインオンによるボーダーフリーなログインを実現できます」

「なるほど、認証機能も充実しているというわけですね。一方で、たとえばわたしがRubrikの管理者だったとして、ワンタイムパスワードやシングルサインオンなども容易に突破した場合、かんたんに悪事を働けてしまうと思うんですね。

もはやランサムウェア対策やウイルス対策の域を超えた話になるかもしれませんが、そのような悪意ある管理者にはどうすることもできないのでしょうか？」

「Rubrikには、2パーソンルールというものが存在します。2パーソンルールを有効にすることで、1人ではデータ削除や設定変更ができないような仕様にすることが可能です。手順も簡単で、2パーソンルールを承認するか否認するかだけのアカウントに対してリクエストを送り、承認者はそれを許可あるいは禁止するだけです」

「承認者は必ずしもIT部門である必要はなく、自由に選定していただいて構いません。Rubrikでは人員教育なども考慮して、ランサム対策を実施していただきたいと思っています」

「実際に2パーソンルールのようすを、検証動画で確認していきましょう」

「ここまですればクリーンな状況を保てると思いますが…最悪も最悪な状況を考えたとして、2パーソンルールも突破されてデータを削除されてしまったら、さすがにどうすることもできない…ですよね？」

「最後の砦ですが、Rubrikでは、削除されたデータを一定期間保持しており、またそれを要請によって復旧させることが可能です」

「なるほど。ただそれって管理者が実行できてしまっては意味がないのでは…？」

「はい。なので、この作業でリカバリを実行できるのはRubrikによるメーカーサポートのみです。権限を持っている人でも実行することはできません」

「それなら安心ですね。これはどういったフローで実行されるのでしょうか？」

「今回はデータを完全削除してからRubrikさんのサポートによって復旧するまでも検証しているので、こちらの動画で…」