 本記事は 新人ブログマラソン2024 の記事です。 |
皆さん、こんにちは！USiZEサービス部第一課の黄です。
これまでの記事では、Rubrikのランサムウェア対策や機密データ検知など、主要な機能についてご紹介してきました。
「まだ読んでいない！」という方は、ぜひ以下の記事もあわせてご覧ください。
さて、今回は少し視点を変えて、「Rubrikとクラウドサービスの連携」にフォーカスしたいと思います。
Rubrikは複数のクラウドプラットフォーム（例：AWS、GCP、VMWare）との連携も対応していますが、
今回は特に利用者の多い「AWSとの連携」に絞ってご紹介します。
Rubrikをクラウド環境で活用したいと考えている方は、ぜひ最後までチェックしてみてください！
RubrikとAWS連携の概要
AWSでは、EC2、S3やRDSなどの多様なリソースを RSC（Rubrik Security Cloud）上でまとめて保護・管理することが可能です。
今回の記事では、EC2インスタンスのバックアップ管理を中心にご紹介していきます。
上図は、RSCを使ってAWSのEC2をバックアップ・管理する流れをまとめたものです。
大きく「一次バックアップ」と「二次バックアップ」の 2 段階に分かれます。
RubrikはAPI経由でEC2インスタンスに対してバックアップデータを取得します。
EC2 の AMI（Amazon Machine Image）や EBS（Elastic Block Store） に保存されます。
ただし、AMI や EBS は ストレージコストが高めで、長期保存には不向きというデメリットがあります。
Rubrik Exocompute（次の章で説明）により、取得したバックアップデータをS3バケットにアーカイブすることで、コストを大幅に抑えながら長期保存することが可能になります。
※ S3 は「安くたくさん保存できる場所」とイメージしてもらえるとわかりやすいかもしれません。
RubrikとAWS連携の検証レポート
本章では、上の図にある一次バックアップから二次バックアップまでの一連の流れを、実際の操作手順・設定画面のスクリーンショットとともに、わかりやすく紹介していきます。
大きな流れとしては、以下の3ステップで構成されています：
-
Rubrik と AWS アカウントの連携
-
一次バックアップの取得
-
二次バックアップの取得
この流れに沿って、それぞれのステップを以下で詳しくご紹介していきます。
1. Rubrik と AWS アカウントの連携
まずは、RSC上でAWSアカウントを登録します。
RSC の「ワークロードの追加」画面から AWS EC2 を選択すると、下図のように 2 種類の登録方法が表示されます。
-
CloudFormation テンプレート（CFT）を使用する方法
-
手動で IAM ロールなどを設定する方法
今回の検証では、より便利な CFT を使用する方法 を選択しました。
次に、RSC 上で登録したい AWS アカウント と リージョン（Region） を設定すると、Rubrik 側で CloudFormation テンプレート（CFT）が自動生成されます。
CloudFormation テンプレート（CFT）をダウンロードし、AWSのCloudFormationにアップロードしてスタックを作成します。
上の図に示すように、Rubrikから作成してくれたCFTに三つの項目があります。
-
CrossAccountRole：Rubrik が AWS リソースにアクセスするための IAM ロールです。
-
EC2ProtectionPolicy：EC2 のバックアップを実行するために必要な権限を定義したポリシーです。
-
RubrikSecurityCloudNotifier：AWS アカウントの連携情報を Rubrik 側に通知するための仕組みです。
スタックの作成が完了すると、Rubrik 側で連携が自動的に完了し、RSC 上にも登録済みとして反映されます。
2. 一次バックアップの取得
次は、一次スナップショットの取得についてご説明します。
前章のRubrikとAWS アカウントの連携により、すでに AWS アカウントとの接続は完了しており、CloudFormation テンプレート（CFT）を通じてRSC側に EC2 操作の権限も付与されています。
この上で AWS 上に EC2 インスタンスを作成すると、自動的に RSC に反映され、管理対象として一覧に表示されます（下図参照）。
※ kou-test-rubrikは事前にAWS側で作成されたEC2インスタンスです。
RSC の画面上からkou-test-rubrikをクリックして、「オンデマンドスナップショット」を実行するだけで、スナップショットの取得が可能です。
この操作により、Rubrik が自動で EC2 の AMI および EBS のスナップショットを作成してくれます。
API ベースで処理されるため、特別な手作業や設定は必要ありません。
少し時間が経つと、下図のように、EC2のAMIやEBS スナップショットが AWS 上に作成されていることが確認できます。
同時にRSC上にもバックアップデータとして反映されます。
3. 二次バックアップの取得
実際、一次バックアップの取得だけでも、RSC 上でバックアップを扱うことは可能です。
ただし、一次スナップショットでは EC2 の AMI や EBS をそのまま保持するため、保存期間が長くなると コストが高くなるという課題があります。
この課題を解決するために用意されているのが、二次バックアップです。簡単に説明すれば、取得したバックアップデータをS3などのストレージにアーカイブすることで、コストを抑えながら長期保管を実現する仕組みです。
二次スナップショットを利用するには、Rubrik 側でいくつかの設定が必要です。主に以下の3点になります：
-
Rubrik Exocompute の設定
-
アーカイブ先の設定
-
SLA ドメインの設定
Rubrik Exocompute の設定
設定方法については、「Rubrik と AWS アカウントの連携」の章と同様に、RSC 側で CloudFormation テンプレート（CFT）を生成し、それを AWS 側で CloudFormation のスタックを更新することで完了します。
上図に示すように、先ほど連携した「test-kou」AWSアカウントについては、Exocomputeがまだ設定していません。
そのため、既に連携済みの AWS アカウントに対して、Exocomputeを操作するための権限を付与する必要があります（下図参照）。
権限の管理方法としては、以下の 2 つのオプションがあります：
-
Rubrik Managed：Rubrik が EKS を自動的に作成・管理します
- Custom Managed：自分たちで用意した既存の EKS クラスタを使用します
今回はRubrik Managedを選択しました。
次には、自動的に生成されたCFTにより、AWS 側で CloudFormation のスタックを更新します。
更新が完了すると、上図のように CFT によって 4 つの新しいリソースが自動で作成されます。
それぞれ Rubrik が一時的に処理用サーバー（EKS）を起動し、必要な操作を実行するために使われるものです。
AWS側での作成が完了すると、RSC 側にもExocomputeが自動的に反映されます。
※ 上図のとおり、Exocompute の設定には VPC の情報も含まれています。設定時にどの VPC を使うかは任意で選べますが、今回は検証で一次バックアップの段階と同じVPCを指定しました。
アーカイブ先の設定
次に、二次バックアップとしてバックアップデータをどこに保管するかを設定します。
保管先には、オンプレミスのストレージやクラウド上の S3 バケットなどを選択できますが、今回の検証では AWS S3 を指定しました。
具体的な操作は、大きく2つのステップに分かれます。
- AWS アカウントに対して S3 関連の操作権限を付与します。
- その後、RSC 上でアーカイブ先として S3 バケットを設定します。
※ S3 バケットは Rubrik 側で自動的に AWS に作成されるため、ユーザーが手動で準備する必要はありません。
まず、既存の「test-kou」AWSアカウントに対して、S3 関連の操作権限を付与します。
今回の検証では S3 をアーカイブ先として選択するため、下図のように「クラウドネイティブロケーション」を選択します。
次に、生成された CFT を用いて CloudFormation のスタックを更新すると、下図のように新たな権限が 1 つ追加されていることが確認できます。
※ 「CloudNativeArchivalLocationPolicy」と呼ばれますが、今回はアーカイブ先として S3 を選択しているため、実際には S3 の操作に関する権限です。
権限追加した後に、RSC側でアーカイブ先（S3 バケット）を設定します。
上図に示されている「kou-test-s3」は、RSC 側で設定したアーカイブ先の名前です。一方、「rubrik-kou-test-location」は、AWS 側に自動作成されるS3バケットの名称になります。
また、S3バケットに保存されるオブジェクト（今回の場合はバックアップデータ）については、6種類のストレージクラスから選択できます。
ただし、S3 のバックアップデータ以外の用途では、上位 4 種類のみが選択可能です。
なお、ストレージクラスは上にあるものほど高コストで、下に行くほど低コストになります。
設定が完了すると、AWS 側にも正しく反映されていることが、下図から確認できます。
現時点では Exocompute がまだ動作していないため、S3 バケットの中身は空のままです。Exocompute を動かすには、SLA ドメインの設定が必要です。
SLAドメインの設定
SLAドメインをEC2インスタンスに適用することで、Exocomputeが実際に動作し、バックアップデータのアーカイブ処理が実行されるようになります。
まずは、SLAドメインを新規作成します。
SLAドメインの設定対象として「AWS EC2/EBS」を選択します。
※ 対象によって設定できる項目が異なるため、適切な対象を選ぶ必要があります。
次に、バックアップデータを取得する頻度と、保持期間を設定します。
※ 保持期間は、一次バックアップ・二次バックアップに関係なく、バックアップデータ全体の保存期間を指します。
あらかじめ指定したバックアップ全体の保持期間は 7 日間のため、
ローカルストレージ（一次バックアップの保存先：AMI や EBS）での保持期間も 0～7 日の範囲で設定できます。
今回は「1日」を設定しました。
つまり、バックアップデータは取得後、1 日間 AMI や EBS に保存され、その後自動的に削除される形になります。
なお、今回は検証のため、「インスタントアーカイブ」をクリックしたため、バックアップデータ取得のタイミングで、すぐに二次バックアップ先（S3 バケット）にもアーカイブされます。
あわせて、先ほど作成したアーカイブ先「kou-test-s3」もここで指定します。
最後、SLAドメインの名前を設定します。
バックアップの結果確認
ここまでの設定で、一次バックアップから二次バックアップまでの準備がすべて完了しました。
あとは、作成した SLA ドメインを対象の EC2 インスタンスに割り当てるだけで、Rubrik が自動的に一次バックアップ（AMI・EBS スナップショット）を取得します。さらに Exocompute を経由して、バックアップデータを指定した S3 バケットにアーカイブしてくれます。
まず、指定したEC2インスタンス「test-kou」に対して、SLAドメインを割り当てます。
SLAドメインを割り当てた後、しばらくすると画面上に反映されます。
AWS側の S3 バケットにバックアップデータのオブジェクトが作成されていることが確認できます。
設定した保存クラスについても、下図のように確認可能です。
RSC側でも下図通り、一次バックアップおよび二次バックアップの取得状況が反映されており、それぞれの処理が正しく実行されたことを確認できます。
まとめ
今回は、Rubrik と AWS の連携に関する検証内容を整理してご紹介しました。
少し内容が多く、読みづらく感じられた方もいらっしゃるかもしれませんが、最後までご覧いただきありがとうございました。
今回は EC2 インスタンスのバックアップデータ管理に絞ってご説明しましたが、実は S3 や RDS など他の AWS リソースについても、基本的な手順は大きく変わりません。
ご興味のある方は、ぜひ参考にしていただければと思います。