Oracleデータベース最強のランサムウェア対策！ZRCVとは？

こんにちは。クラウドサービス部の石井です。

多くの企業でデータを取り扱うためにデータベース製品を使用していると思います。しかし、データベースには多くの種類があり、どの製品を利用するかは悩ましいところではないでしょうか。処理性能やコストを気にされる方が多いと思いますが、近年ではランサムウェアなどのサイバー犯罪からデータを守るという点も意識される方が多いと思います。

今回はOracle Cloud Infrastructure（以下、OCI）のOracle Databaseで利用できるランサムウェア対策のバックアップ、リカバリ機能Zero Data Loss Autonomous Recovery Serviceについて紹介します。

Zero Data Loss Autonomous Recovery Service（ZRCV）とは

Oracle Database Autonomous Recovery Service（自律型リカバリ・サービス：RCV）は、OCIのOracle Databaseにのみ提供されるフル・マネージド型のデータ保護サービスです。

バックアップ・リカバリに特化したアプライアンス製品であるOracle Zero Data Loss Recovery ApplianceとOracle Recovery Manager（RMAN）の機能を組み合わせたサービスで、リアルタイム・データ保護を有効にした状態はZero Data Loss Autonomous Recovery Service（ZRCV）と呼びます。

このZRCVは、従来のオブジェクト・ストレージへのバックアップとは少し異なる方法でバックアップを取得することで、バックアップ取得時の本番環境への影響を最小化する仕組みになっています。また、ランサムウェア対策を強く意識したサービスとなっており、攻撃者を近づけないような制御や、迅速に被害直前の状態まで復旧できる仕組みが備わっています。

ここからは具体的にどういうことができる機能か紹介していきます。

バックアップにおけるタスクのほとんどをZRCV上で実施

従来のバックアップでは週に一度フルバックアップを取得し、日次で差分増分バックアップを取得します。対してZRCVは、初回にフルバックアップを取得し、それ以降は常に差分増分でのバックアップとなります。これによりバックアップ時の本番環境への影響を最小限に抑えられます。

また、オブジェクト・ストレージ・バックアップの場合は、バックアップファイルの破損を確認するためには、手動でバックアップファイルを読み込み、データベース上で検証する必要があります。対してZRCVは、バックアップやREDOログの取得時に自動的にZRCV側でファイルの検証を行い、バックアップファイルの破損の有無を確認します。

このように、ZRCVではバックアップにおけるタスクのほとんどをZRCV上で実施することで本番データベースへの影響を最小限にし、さらにその処理を自動で実施することでユーザの作業コストを下げつつ、完全性の保たれたバックアップを保持することが可能です。

ユーザがアクセスできない領域にバックアップデータを保管

バックアップの取得自体は通常のRMANを利用しますが、バックアップの保存先がZRCV上となっており、ユーザにはアクセスできない領域にバックアップデータが保管されます。そのため、万が一データベースサーバに侵入された場合でも、RMANコマンドでバックアップファイルを削除されることはありません。

バックアップファイルは指定期間削除不可

従来のオブジェクト・ストレージへのバックアップの場合、OSにログインしRMANから即座にバックアップを削除できます。しかし、ZRCVに保管されたバックアップファイルは、RMANから削除しようとすると保護ポリシーに指定された期間（最短14日）はORA-64766が返ります。そのため、万が一OCIコンソールに侵入されたとしてもバックアップファイルを守ることができます。

RMAN> delete backup ;
delete backup ;
allocated channel: ORA_SBT_TAPE_1
channel ORA_SBT_TAPE_1: SID=206 device type=SBT_TAPE
channel ORA_SBT_TAPE_1: RA Library (RANRTP7) SID 275275959D21E804E0639F00000AA3E5
RMAN-06918: warning: allocated SBT channel to the Recovery Appliance in NOCATALOG mode
allocated channel: ORA_DISK_1
channel ORA_DISK_1: SID=65 device type=DISK
 
List of Backup Pieces
BP Key  BS Key  Pc# Cp# Status      Device Type Piece Name
------- ------- --- --- ----------- ----------- ----------
2       2       1   1   AVAILABLE   SBT_TAPE    02379ppi_2_1_1_NEWZRCV
3       3       1   1   AVAILABLE   SBT_TAPE    03379ppp_3_1_1_NEWZRCV
～中略～
699     699     1   1   AVAILABLE   SBT_TAPE    mv3aj0hd_735_1_1_NEWZRCV
700     700     1   1   AVAILABLE   SBT_TAPE    c-134048861-20241120-0b
 
Do you really want to delete the above objects (enter YES or NO)? yes
deleted backup piece
backup piece handle=+RECO/NEWZRCV_84M_NRT/AUTOBACKUP/2024_10_21/s_1182926632.315.1182926633 RECID=286 STAMP=1
182926632
Deleted 1 objects
 
RMAN Command Id : 2024-11-20T05:17:43
RMAN Command Id : 2024-11-20T05:17:43
RMAN-00571: ===========================================================
RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS ===============
RMAN-00571: ===========================================================
RMAN-03009: failure of delete command on ORA_SBT_TAPE_1 channel at 11/20/2024 05:31:28
ORA-19509: failed to delete sequential file, handle="bh386d9l_369_1_1_NEWZRCV", parms=""
ORA-27027: The SBT REMOVE operation returned an error.
ORA-19511: non RMAN, but media manager or vendor specific failure, error text:
   KBHS-01404: See trace file /u01/app/oracle/diag/rdbms/newzrcv_84m_nrt/NEWZRCV/trace/sbtio_59396_1400286885
66720.log for details
KBHS-00719: Error 'recovery appliance Error'; ORA-64766: backup deletion using RMAN prevented by protection
 
  
RMAN>

被害にあう直前の状態までリカバリ可能

悪意を持った攻撃によりデータを破壊された場合だけでなく、データベース本体のストレージに障害が発生した場合、バックアップファイルの存在する時点までしかリカバリできません。従来のオブジェクト・ストレージへのバックアップの場合、アーカイブ・REDOログ、オンラインREDOログの情報は失われてしまいます。

対してZRCVはData Guardと同様にREDO情報が生成されたらZRCVへREDO情報が転送される仕組みのため、常に最新の情報がバックアップされます。そのため、被害にあう直前、データベース本体のストレージに障害が発生する直前までリカバリが可能です。

	ストレージ・バックアップ	RCV	ZRCV
バックアップの保管先	オブジェクト・ストレージ	自律型リカバリ・サービス	自律型リカバリ・サービス
バックアップの取得方法	週に一度フルバックアップ 日次で差分増分バックアップ	初回のみフルバック 日次で差分増分バックアップ	初回のみフルバック 日次で差分増分バックアップ
バックアップの破損の有無チェック	ユーザが実施	自動で実施	自動で実施
バックアップファイルの保持期間	即時削除可能	最短14日	最短14日
アーカイブログのバックアップ取得タイミング	BaseDB：1時間ごと ExaDB-D：30分ごと	BaseDB：1時間ごと ExaDB-D：30分ごと	随時
DB本体のストレージが破損した場合のリカバリポイント	アーカイブログの最終バックアップ時点（最大BaseDBで1時間前、ExaDB-Dで30分前）	アーカイブログの最終バックアップ時点（最大BaseDBで1時間前、ExaDB-Dで30分前）	障害発生直前

自律型リカバリ・サービスの利用料金

自律型リカバリ・サービスの料金は、緻密な見積もりが難しく、バックアップを取得するファイル、方式の違いや、圧縮されるファイルの違いなどから従来のオブジェクト・ストレージへのバックアップと単純な料金比較を行えません。

しかし、概ねRCVはオブジェクト・ストレージと同等か安い、ZRCVはオブジェクト・ストレージと同等か少し高くなっています。実際にどの程度の金額になるかはCost Estimatorを使って計算して確認してください。

※ Cloud Cost Estimator | Oracle 日本

オブジェクト・ストレージへのバックアップの計算は、カテゴリ「Storage」から「オブジェクト・ストレージ」を選択してください。ファイルサイズは、オブジェクト・ストレージに格納されるバックアップファイルの総容量を入力します。

例えば21日分のバックアップを取得している場合は、フルバックアップ3回分、日次増分18日分、REDOログ21日分の合計サイズとなります。これらのファイルは圧縮して格納されるため、圧縮後のサイズを入力します。

自律型リカバリ・サービスの計算は、カテゴリ「Oracle Database」から「Oracle Database Autonomous Recovery Service」を選択してください。ファイルサイズは、入力フォーマットに沿って、1回分のフルバックアップサイズ、日次増分サイズ、日次REDOログサイズを入力します。自律型リカバリ・サービスは実際に保持される容量で課金されるわけではないため、圧縮前のファイルサイズを入力します。

自律型リカバリ・サービスの設定準備

ここからはZRCVの設定方法について紹介します。今回は以下のように、リカバリ・サービス用のサブネットと、データベースを作成するサブネットを分けて構成する場合について紹介しますが、リカバリ・サービス用のサブネットにデータベースを作成することも可能です。

事前準備

Service Limit設定

Autonomous Recovery Serviceで使用するリソースは以下2つです。

• リカバリ・ウインドウに使用されたAutonomous Recovery Serviceの領域（GB）
  (Space Used for Recovery Window (GB))
• Autonomous Recovery Serviceで保護されたデータベース数
  (Protected Database Count)

このリソースの現在のサービス制限および使用状況を確認し、必要に応じてリソース制限の引上げリクエストを出してください。

ポリシー設定

自律型リカバリ・サービスを使うにあたり、IAMグループおよび関連するサービスに対するポリシーを設定する必要があります。これらは、コンソールでポリシー・ビルダーを使用して作成することもでき、以下の3つのテンプレートが用意されています。

※ ここでは自動リカバリ・サービスに関連するポリシーについてのみ紹介します。サブネットやデータベースを作成するために必要なポリシーは割愛します。

• 自律型リカバリ・サービスですべてを行う機能
  自動バックアップ構成のリソースを作成するためのデータベース・サービスと自律型リカバリ・サービスの機能
• ユーザに自律型リカバリ・サービスで保護ポリシーを管理させる
  自律型リカバリ・サービスで保護ポリシーを作成、更新および削除する機能
• ユーザに自律型リカバリ・サービス・サブネットを管理させる
  自律型リカバリ・サービスでリカバリ・サービス・サブネットを作成、更新および削除する機能

「自律型リカバリ・サービスですべてを行う機能」では以下のポリシーを設定します。いずれもテナント・レベルのポリシーのため、ルート・コンパートメントにポリシーを作成してください。

ポリシー・ステートメント	目的
Allow service database to manage recovery-service-family in tenancy	OCI Databaseサービスが、テナンシ内の保護されたデータベース、保護ポリシーおよびリカバリ・サービス・サブネットにアクセスできるようにします。
Allow service database to manage tagnamespace in tenancy	OCIデータベース・サービスがテナンシのタグ・ネームスペースにアクセスできるようにします。
Allow service rcs to manage recovery-service-family in tenancy	リカバリ・サービスが、テナンシ内の保護されたデータベース、リカバリ・サービス・サブネットおよび保護ポリシーにアクセスして管理できるようにします。
Allow service rcs to manage virtual-network-family in tenancy	リカバリ・サービスが、テナンシ内の各データベースVCNのプライベート・サブネットにアクセスして管理できるようにします。プライベート・サブネットは、データベースとリカバリ・サービス間のバックアップのネットワーク・パスを定義します。
Allow group <group name> to manage recovery-service-family in tenancy	指定したグループのユーザがすべてのリカバリ・サービス・リソースにアクセスできるようにします。指定したグループに属するユーザは、保護されたデータベース、保護ポリシーおよびリカバリ・サービス・サブネットを管理できます。

「ユーザに自律型リカバリ・サービスで保護ポリシーを管理させる」では以下のポリシーを設定します。このポリシーは保護ポリシーを所有するコンパートメントに作成します。

なお、「recovery-service-policy」は「recovery-service-family」に含まれるリソースのため、「manage recovery-service-family」のポリシーを有している場合は設定不要です。

ポリシー・ステートメント	目的
Allow group <group name> to manage recovery-service-policy in compartment <compartment name>	指定したグループ内のすべてのユーザが、リカバリ・サービスで保護ポリシーを作成、更新および削除できるようにします。

「ユーザに自律型リカバリ・サービス・サブネットを管理させる」では以下のポリシーを設定します。このポリシーはリカバリ・サービス・サブネットを所有するコンパートメントに作成します。

なお、こちらの「recovery-service-subnet」も「recovery-service-family」に含まれるリソースのため、「manage recovery-service-family」のポリシーを有している場合は設定不要です。

ポリシー・ステートメント	目的
Allow Group <group name> to manage recovery-service-subnet in compartment <compartment name>	指定したグループ内のすべてのユーザがリカバリ・サービス・サブネットを作成、更新および削除できるようにします。

日本の東京や大阪リージョンではまだ使えませんが、Oracle Database@AzureやOracle Database@Google CloudなどのマルチクラウドOracle Databaseでは、上記を除き追加で必要なポリシーがあります。もし日本ではないリージョンを使用中の方でマルチクラウドOracle Databaseで自律型リカバリ・サービスを利用する場合はマニュアルもしくはポリシー・ビルダーを参考にポリシーを追加してください。

※ リカバリ・サービスの構成｜Oracle Cloud Infrastructureドキュメント

サブネットの作成

今回はデータベース用のサブネットと、リカバリ・サービス用のサブネットを作成します。リカバリ・サービス用サブネットの要件は以下の通りです。

項目	要件
サブネット・タイプ	推奨はプライベートだが、パブリックにも作成可能
サブネット・サイズ	/24（推奨）

リカバリ・サービス操作にはIPv6対応サブネットはサポートされていないため、IPv4のみのサブネットを選択する必要があります。サブネットのプレフィックスは/24が推奨されています。

セキュリティ・リストの設定

リカバリ・サービスで使用されるサブネットに対し、以下のイングレス・ルールが登録されたセキュリティ・リストを設定します。

ソースCIDR	IPプロトコル	ソース・ポート範囲	宛先ポート範囲
データベースが存在するVCNのCIDR	TCP	All	8005
データベースが存在するVCNのCIDR	TCP	All	2484

自律型リカバリ・サービスの設定

ここからは自律型リカバリ・サービス特有の設定を行っています。

リカバリ・サービス・サブネットの登録

リカバリ・サービス・サブネットによりVCN内のリカバリ・サービス操作のネットワーク分離が可能になります。そのため、リカバリ・サービスで使用するサブネットをリカバリ・サービス・サブネットに登録する必要があります。

リカバリ・サービス・サブネットはVCNごとに1つしか作成できませんが、VCNの内の複数のサブネットを登録できるため、1つのVCN内に複数のリカバリ・サービス用のサブネットを用意することもできます。

ナビゲーション・メニューから、「Oracle Database」 -> 「データベース・バックアップ」を選択し、データベース・バックアップのページを表示します。左側にある「リカバリ・サービス・サブネット」をクリックし、リカバリ・サービス・サブネットの一覧を表示したら、「リカバリ・サービス・サブネットの登録」をクリックします。必要事項を入力したら「登録」ボタンをクリックし、リカバリ・サービス・サブネットを登録します。

名前	リカバリ・サービス・サブネットの名前
コンパートメント	リカバリ・サービス・サブネットを作成するコンパートメントを指定
仮想クラウド・ネットワーク	自律型リカバリ・サービスを使用するDBが存在する仮想クラウド・ネットワークを指定
サブネット	リカバリ・サービス・サブネットに登録するサブネットを指定、複数選択可能

保護ポリシーの作成（オプション）

次に、保護ポリシーを作成します。保護ポリシーはリカバリ・サービスによって保護されるバックアップ保持期間を設定します。デフォルトでは以下の4つが用意されているため、これらを使用する場合は作成不要です。

• Platinum：95日
• Gold：65日
• Silver：35日
• Bronze：14日

保護ポリシーでは保持ロック機能を使用して、バックアップ保持期間をロックできます。これにより偶発的な変更やランサムウェアなどからバックアップを保護します。保持ロックは一度有効化すると無効にできません。また、保持期間の変更は延長のみが許可されています（最大95日）。保持ロックを完全に有効化するまでに最低14日の遅延が義務付けられているため、例えば1月1日に保持ロックを有効化する場合は1月15日以降を指定する必要があります。遅延期間内であれば保持期間の増減、ロックの無効化が可能です。

ナビゲーション・メニューから、「Oracle Database」 -> 「データベース・バックアップ」を選択し、データベース・バックアップのページを表示します。左側にある「保護ポリシー」をクリックし、保護ポリシーの一覧を表示したら、「保護ポリシーの作成」をクリックします。必要事項を入力したら「作成」ボタンをクリックし、保護ポリシーを作成します。

名前	保護ポリシーの名前
コンパートメント	保護ポリシーを作成するコンパートメントを指定
バックアップ保持期間（日）	バックアップ保持期間を指定（日数）、最小14日、最大95日
保持ロックの有効化	保持ロックを有効化する場合に選択、有効化する場合は永続的にロックするまでの猶予期間を指定（最低14日）
データベースと同じクラウド・プロバイダにバックアップを格納します	Oracle Database@Azureや@Google Cloudなどを使用して、ソース・データベースが別のクラウドにプロビジョニングされている場合において、バックアップをデータベースと同じく別のクラウドに保管する場合はここにチェックをつける、保護ポリシー作成後の変更は不可

リカバリ・サービスの有効化（新規作成）

2023年9月より、新規データベース作成時の自動バックアップのデフォルト保存先が自律型リカバリ・サービスになっています。ただし、注意書きに書いている通り、前提条件がすべてそろっていない状態でバックアップの保存先を自律型リカバリ・サービスにしてデータベースを作成しようとするとエラーとなりますので注意してください。

リカバリ・サービスを有効化するにはDBシステム作成時のデータベース・バックアップ構成を以下の通り設定します。他の項目については通常BaseDBを作成するときと同様で、特別な設定はありません。なお、ここでリカバリ・サービスを有効化しなかった場合でも、後から有効化できます。後からリカバリ・サービスを有効化する手順は後述します。

自動バックアップの有効化	チェックをつける
バックアップの保存先	「自律型リカバリ・サービス（推奨）」を選択
保護ポリシー	設定する保護ポリシーを選択
リアルタイム・データ保護	ZRCVにする場合はチェックをつける
データベース終了時の削除オプション	データベース終了時にどのタイミングでバックアップデータを削除するか選択

作成後、データベース詳細画面において、「バックアップの保存先」が「自律型リカバリ・サービス」になっており、「リアルタイム・データ保護」が「無効」の場合はRCV、「有効」の場合はZRCVとなっています。

リカバリ・サービスの有効化（既存のDBに設定）

バックアップ先がオブジェクト・ストレージになっている場合でも、リカバリ・サービスを有効化できます。ここではBaseDBの手順を紹介しますが、ExaDB-Dの場合でもデータベースの詳細画面から同様の手順で変更できます。

ナビゲーション・メニューから、「Oracle Database」 -> 「Oracleベース・データベース・サービス」を選択し、DBシステムの一覧画面を表示します。変更対象のDBシステムを選択し、ページ下部のデータベース名をクリックし、データベース詳細画面を表示します。「自動バックアップの構成」ボタンをクリックし、バックアップの保存先を「オブジェクト・ストレージ」から「自律型リカバリ・サービス（推奨）」に変更することでリカバリ・サービスを有効化できます。

ただし、前提条件が満たされていない場合は、「自律型リカバリ・サービス（推奨）」はグレーアウトされ選択できません。また「自律型リカバリ・サービス（推奨）」を選択後に入力する内容は、新規作成時に選択する項目と同じ内容です。

自律型リカバリ・サービスの設定時のバックアップ、リストア方法

自律型リカバリ・サービスを設定している場合のバックアップ、リストアの操作方法は、従来のオブジェクト・ストレージへのバックアップと同様です。ただし、リストア時の内部の動きが異なります。

従来のオブジェクト・ストレージへのバックアップの場合は、フルバックアップをリストアした後に、差分増分バックアップをリストアして適用する必要があります。対して自律型リカバリ・サービスは、ZRCV内で差分増分バックアップの断面を合成し、最新のフルバックアップに相当する仮想フルバックアップを生成します。そのため、リストア時はこの仮想フルバックアップを復元するだけで済み、リストア時間を短縮できます。

残念ながら、データベース作成直後に少しだけデータを入れた状態ではバックアップ、リストアそれぞれにかかる時間は、自律型リカバリ・サービスとオブジェクト・ストレージへのバックアップでは違いはありませんでしたが、データベースのサイズが大きく、更新が多い場合はリストア時間の短縮を感じられると思います。

おわりに

オンプレミス環境でこの自律型リカバリ・サービスの同等の機能を実装しようとすると、Oracle Zero Data Loss Recovery Applianceを導入する必要があり、費用面から導入のハードルがとても高いサービスでした。しかし、クラウドではアプライアンス製品を購入する必要が無いため、低価格でこのサービスを利用することが可能となっています。

また、フル・マネージド型サービスであり、初期設定を除けば従来のバックアップ、リカバリと同じ操作で利用できるため、このサービスを導入することによる運用負荷もほとんどないと言えます。ぜひ大事なデータを守るためにもこのZRCVを導入してみませんか。

ラックでは、お客様のシステム環境の課題に合わせた、OCI、AWS、Azure、Google Cloudのご提案をしています。マルチクラウドやハイブリッドクラウドも含めたシステム構成に関するお悩みがございましたら、ぜひお気軽にお問い合わせください。