マルチクラウド環境におけるOracle AI Databaseのランサムウェア・リカバリ設計パターン (2026/09/29)

マルチクラウド環境におけるOracle AI Databaseのランサムウェア・リカバリ設計パターン (2026/09/29)

https://www.ateam-oracle.com/multicloud-ransomware-recovery

投稿者：Tal Altman | Director, OCI Networking Specialists and Security Programs

 Kasey Parker | Cloud Architect, Oracle Database@[Multicloud]
 Bryan Grenn | Database, Infrastructure & Cloud Solutions Architect
 Mimi Mukherjee | Master Principal Solution Engineer
 Jorge Cortes Cano

はじめに

ランサムウェアからの復旧は、高可用性 (HA) や災害復旧 (DR) とは異なります。HA と DR は、インフラストラクチャやリージョンの障害発生後もサービスを維持しますが、ランサムウェアからの復旧は、本番データや管理制御が侵害された可能性がある場合に、正常なコピーを復元します。このブログでは、マルチクラウド環境における Oracle AI Database の 2 つの復旧パターンについて説明します。(1) 同一テナントの復旧環境、(2) テナント間復旧環境です。

注：このブログの対象範囲は、マルチクラウドにおけるランサムウェアからの復旧です。マルチクラウドのHA（高可用性）やDR（災害復旧）については詳しく説明しません。マルチクラウドに関する詳細は、Oracleのマルチクラウド向け最大可用性アーキテクチャ（MAA）ガイドを参照してください。このブログで説明する概念の多くは、OCI（組織クラウドインフラストラクチャ）を使用しているOracle Databaseのお客様にも当てはまります。OCIにおけるランサムウェアからの復旧に関するベストプラクティスについては、「OCIテナントにサイバーレジリエンス機能を組み込む」を参照してください。

このブログでは、ランサムウェアの脅威から身を守るために顧客が活用できる設計パターンを紹介します。今後のブログでは、より詳細な実践ガイドをお届けします。

Oracle AI Databaseは、 Amazon Web Services（AWS）、Microsoft Azure、Google Cloud（GCP）などのクラウドサービスプロバイダー（CSP）で利用可能になり、「Oracle AI Database in Multicloud」として知られています。アプリケーションスタックは、データベースのレイテンシの増加に敏感な場合が多く、特にデータベースがスタックの他の部分と同じ場所に配置されていない場合は、パフォーマンスが著しく低下する可能性があります。この問題を解決するために、Oracle AI Database in Multicloudは、AWS、Azure、GCP内に物理インフラストラクチャを共存させます。お客様は、選択したCSP内でOracleサービスへのクラウドネイティブアクセスを提供できるようになりました。

ランサムウェアからの復旧が必要な理由は何ですか？

サイバー脅威がますます一般的になるにつれ、医療、金融サービス・保険（FSI）、エネルギー、政府機関などの業界に影響を与えるランサムウェア復旧に関する規制要件が複数存在します。DORA、NIS2、NYDFSなどの規制では、保護されたバックアップ、分離された復旧、テスト済みの復元、取締役会レベルの責任が重視されています。また、多くの顧客は、重要なインフラストラクチャに対して論理的なランサムウェア復旧エアギャップを構築するという、取締役会レベルまたは経営幹部レベルの指示にも対応しなければなりません。

OracleのZero Data Loss Recovery Appliance（ZDLRA）は、10年以上にわたり、オンプレミスのミッションクリティカルなワークロードを保護し、トランザクションレベルの保護、リカバリの自動化、バックアップの不変性、高可用性を提供してきました。クラウド環境、特にOracleのマルチクラウドデータベース製品では、Zero Data Loss Autonomous Recovery Serviceがマネージドサービスとして同様の機能を提供します。ポリシーベースの保持、暗号化されたバックアップ、異常検出、リカバリ検証といった機能を提供します。オプションの保持ロック機能により、保持期間が終了するまでバックアップの変更や削除が防止されます。主なメリットは以下のとおりです（ただし、これらに限定されません）。

  • テナント分離 – Oracleが管理するテナントは、論理的なエアギャップを提供します。
  • 透過的データ暗号化（TDE）によるバックアップ暗号化
  • バックアップの不変性と職務分掌
  • リアルタイムのデータ保護でサイバー攻撃の影響を最小限に抑える
  • データ損失リスクを低減し、RPOを1秒未満に抑える
  • データベースを考慮した異常検知と復旧の検証

ランサムウェアからの復旧設計パターン

現在、マルチクラウド環境のOracle AI Databasesで顧客が利用しているランサムウェア復旧設計パターンは2つあります。

  1. 同じテナントの回復
  2. テナント間の回復

それでは、両方のパターンについてさらに詳しく見ていきましょう。

図1 – 同一テナント復旧モデル

「同一テナント」リカバリーモデルでは、お客様は 1 つの Oracle AI Database 環境を使用し、トラフィックを異なるネットワークに分割します。上の図は、マルチクラウド環境における Oracle AI Database の例を示しています。本番データベースには、独自の本番 VCN があります。Exadata データベースの場合は、クライアントサブネットとバックアップサブネットを事前に定義する必要があります。さらに、Autonomous Recovery Service は、プライベートエンドポイントとプライベート DNS ビューを使用して、バックアップサービスへの接続を提供します。セキュリティリストでは、リカバリーサービスが TCP/2484 (SQL*Net) および TCP/8005 (HTTPS バックアップ) を介してデータベースと通信できるようにする必要があります。このサービスの要件の詳細については、Autonomous Recovery Service チェックリストを参照してください。

バックアップインフラストラクチャはOracleが管理しており、顧客が直接アクセスできない別の環境にあります。本番環境が侵害された場合、運用チームは上記の図に示す事前プロビジョニング済みのランサムウェアリカバリVCNを利用できます。必要なネットワーク接続が確立されるように、ランサムウェアリカバリVCNにはExadata Cloud InfrastructureおよびAutonomous Recovery Serviceのバックアップサブネットが既にデプロイされている必要があります。Autonomous Recovery Serviceを使用すると、データベース管理者またはバックアップ管理者は、本番データベースをリカバリ環境のExadata VMクラスタにリカバリすることを選択できます。実際のサイバー脅威が発生した場合、たとえば、クラウド管理者は本番VCNからネットワーク接続を削除し、その間にDBAはランサムウェアリカバリVCNで復元されたデータベースの整合性を検証することができます。

サイバー攻撃後、顧客は次のいずれかを選択できます。

(a) データベースを本番環境に復元し、ネットワーク接続を復旧する

（b）ランサムウェアリカバリVCNを新しい本番環境として推進し、必要に応じてネットワーク接続（DRG、LPG、サービスゲートウェイなど）を構築する。 

クロステナント設計パターンの詳細

図2 – 複数テナント向け設計パターン

Autonomous Recovery Serviceのネイティブ機能はほとんどの顧客のニーズを満たしますが、一部の顧客は、(1)本番環境用と(2)ランサムウェア復旧用の2つの別々のサブスクリプションとテナントを備えた「エアギャップ」ランサムウェア復旧環境を必要とします。

注：以下の設計パターンはテストおよび検証済みで正常に動作しますが、自律型リカバリーサービスの完全自動化機能ではありません。このアーキテクチャを実装する場合は、Oracleのアカウントチームにご相談ください。

デザインの詳細：

ステップ 1 – 準備 – 本番データベースを保護し、データを収集します。Autonomous Recovery Service を使用して本番データベースを保護し、バックアップが保持ロックで保護されていることを確認します。ランサムウェアリカバリークリーンルームへのリカバリーを容易にするために、データベース OCID と、各データベースに関連付けられている KMS キー OCID (顧客管理キーを使用している場合) の両方を収集する必要があります。 

クリップボードにコピーされました
エラー: コピーできませんでした
oci db database list \
--compartment-id <your-compartment-ocid> \
--query "data[*].{DB_Name: \"db-name\", DB_OCID: id, KMS_Key_ID: \"kms-key-id\",
Vault_ID: \"vault-id\"}" \
--output table

これは必要最低限​​の情報であり、本番環境またはランサムウェア復旧環境でローカルに収集できます。また、新しいテナントでデータベースとクラスタを作成するために必要な最新の構成情報も保持しておく必要があります。

  • 現在のデータベースソフトウェアのバージョン。 
  • 十分なストレージが割り当てられるように、DBのサイズを調整します。 
  • VMのサイジングと構成 

ステップ2 – ランサムウェアリカバリーテナンシーが本番テナンシーにアクセスできるように、クロステナンシーIAMポリシーを設定します。詳細については、OCI製品ドキュメントのクロステナンシーアクセスポリシーに関する項目を参照してください。また、リカバリーサービス製品ドキュメントの必須要件チェックリスト  に記載されている必要なIAMポリシーも確認してください。

ステップ2.1 – 承認（ランサムウェア回復OCIテナント内）

クリップボードにコピーされました
エラー: コピーできませんでした
Define tenancy Production as <Production ocid>

Endorse group <identity domain name>/<RcsAdminGroup group name> to manage recovery-service-family in tenancy Production

OCI VaultをTDEの顧客管理キーとして使用し、リカバリ環境内のExadata VMクラスタ用に動的グループを作成する必要がある場合は、以下のポリシーステートメントが必要です。

クリップボードにコピーされました
エラー: コピーできませんでした
Endorse group <identity domain name>/<RcsAdminGroup group name> to use key-delegate in tenancy Production

Endorse group <identity domain name>/<RcsAdminGroup group name> to use keys in tenancy Production

Endorse dynamic-group <identity domain name>/<dynamic group name of the exadata vmcluster in recovery environment> to manage keys in tenancy Production

Endorse dynamic-group <identity domain name>/<dynamic group name of the exadata vmcluster in recovery environment> to read vaults in tenancy Production

ステップ2.2 – 承認（本番環境OCIテナンシー）

クリップボードにコピーされました
エラー: コピーできませんでした
Define tenancy RansomwareRecovery as <RansomwareRecovery ocid>

Define group RcsAdminGroup as <RcsAdminGroup ocid in RansomwareRecovery>

Admit group RcsAdminGroup of tenancy RansomwareRecovery to manage recovery-service-family in compartment id <compartment ocid of protected database>

OCI Vault を TDE の顧客管理キーとして使用し、これらのステートメントで参照される動的グループが、リカバリ環境の Exadata VM クラスタのランサムウェアリカバリ OCI テナントで作成された動的グループである場合は、以下のポリシーステートメントが必要です。

クリップボードにコピーされました
エラー: コピーできませんでした
Define dynamic-group RcvVMC as <Dynamic group ocid in RansomwareRecovery>

Admit group RcsAdminGroup of tenancy RansomwareRecovery to use key-delegate in compartment id <compartment ocid of OCI Vault and Keys >

Admit group RcsAdminGroup of tenancy RansomwareRecovery to use keys in compartment id <compartment ocid of OCI Vault and Keys >

Admit dynamic-group RcvVMC of tenancy RansomwareRecovery to manage keys in compartment id <compartment ocid of OCI Vault and Keys >

Admit dynamic-group RcvVMC of tenancy RansomwareRecovery to read vaults in compartment id <compartment ocid of OCI Vault and Keys >

ステップ2.3 – RCVポリシーを有効にする（両方のテナントでリカバリサービスを有効にするため）

クリップボードにコピーされました
エラー: コピーできませんでした
Allow group RcsAdminGroup to manage recovery-service-protected-database in compartment <protected_db_compartment>

Allow group RcsAdminGroup to manage recovery-service-subnet in compartment <recovery_service_subnet_compartment>

Allow group RcsAdminGroup to manage virtual-network-family in compartment <vcn_compartment>

ステップ3 – APIを使用して新しいデータベースを作成します。

本番環境が侵害された場合、運用チームは事前にプロビジョニングされたネットワークとインフラストラクチャを活用して、主要な本番環境をミラーリングすることができます。ランサムウェアリカバリテナントで復旧を行う前に、すべての本番コンポーネントを作成し、自律型リカバリサービスへのアクセスを構成する必要があります。最後に正常に取得されたバックアップポイントを特定する必要があります。攻撃の種類と深刻度によっては、これは最後に受信したバックアップである場合もあれば、攻撃前のポイントである場合もあります。最後に正常に取得されたリカバリポイントによって、必要なデータベースの復元およびリカバリ方法が決まります。 

OCI Python SDK のCreateDatabaseFromAnotherDatabaseメソッドを使用すると、 最新のバックアップ、または特定の正常な時点に復元およびリカバリできます。特定のバックアップに復元する場合は、OCI Python SDK のCreateDatabaseFromBackupメソッドを利用できます。

上記の手順2では、TDEウォレットのパスワードやリカバリに必要なOCI Vaultキーマテリアルへのアクセスなど、ソースデータベースの暗号化情報への必要なアクセス権を取得しました。データベースOCIDとともに、Autonomous Recovery Serviceバックアップから復元するために必要な情報を提供します。サイバーテナント内の復元先を特定するには、新しいデータベースホームOCID、復元先のテナントとリージョン、および新しいデータベース管理者パスワードを指定する必要があります。 

これはPythonやTerraformで実装できます。今後のブログでは、以下の点についてさらに詳しく解説します。

  • CreateDatabaseFromBackup APIを使用してRansowmare Recoveryテナンシーに復旧するための詳細な手順。
  • OCI Vaultやストレージレプリケーション技術など、検討すべき概念についてさらに詳しく解説します。

適切な回復パターンを選択する

同一テナントパターンは、ネットワークとワークロードの分離を実現し、運用上の複雑さを軽減しますが、本番環境と管理上の境界を共有します。一方、クロステナントパターンは、リカバリリソースの管理上の分離を追加しますが、追加の設定と運用要件が発生します。

以下の表は、これらのトレードオフをまとめたものです。お客様は、脅威モデル、復旧目標、規制要件、運用準備状況、およびリスク許容度に最も合致するパターンを選択する必要があります。どのパターンを選択する場合でも、定期的な復旧テストを通じて検証し、文書化されたインシデント対応計画に組み込む必要があります。

考慮同じ賃貸契約クロステナント
最適なフィット感よりシンプルな復旧作業行政上の分離要件の強化
行政上の隔離より低いより高い
運用上の複雑性より低いより高い
自動化アプローチコンソールUIおよび/またはAPI顧客が開発したAPIスクリプト
復旧インフラ同一テナント内の別ネットワーク個別の復旧テナントとネットワーク
アイデンティティの妥協境界共有正しく設計されていれば別々に投与される

最後に

このブログ記事の推奨事項に従って進める場合は、マルチクラウド環境で代表的な Oracle AI Database ワークロードを選択し、リカバリが成功した状態を定義し、IT、セキュリティ、データベース、およびアプリケーションチームを初日からプロセスに参加させてください。概念実証環境と UAT 環境を使用して、Autonomous Recovery Service による完全なリカバリ ワークフローを練習します。これには、テナント間の IAM 権限、OCI Vault/TDE キーへのアクセス、ネットワーク接続の確認から、リカバリ後にアプリケーションが正常に動作することの検証までが含まれます。結果をリカバリの目標と比較して測定し、障害シナリオをテストして、得られた知見を明確で再現可能な実行手順書にまとめます。

本番環境に移行する前に、別のチームメンバーがランブックを正しく実行できることを確認し、確立された変更管理プロセスを通じて検証済みの構成と自動化を推進してください。そして、継続的に練習を重ねてください。パイロット運用の成功は重要なマイルストーンですが、定期的な復旧訓練こそが、最も重要な局面で行動するための自信を築く鍵となります。

お読みいただきありがとうございます。この記事が、マルチクラウド環境におけるOracle AIデータベースのランサムウェア復旧手順書を作成するための実践的な出発点となることを願っています。

コメント

コメントを投稿

このブログの人気の投稿

Oracle Database 19cサポート・タイムラインの重要な更新 (2024/11/20)

イメージ
Oracle Database 19cサポート・タイムラインの重要な更新 (2024/11/20) https://mikedietrichde.com/2024/11/20/important-update-to-oracle-database-19c-support-timelines/ 長い沈黙は、私が隠れているという意味ではありません。つまり、今はとても忙しいということです。そして、より少ない旅行で、私はあなたのコメントにもブログと返信するより多くの時間を持っていることを願っています。それでも、Oracle Database 19cサポート・タイムラインの非常に重要な更新について説明します。 * 更新された内容 2024年11月19日現在、Oracle Database 19cのサポート・タイムラインが調整されています。 MOSノート: 742060.1 – 現在のデータベース・リリースのリリース・スケジュールを見ると、新しい日付が表示されます。 Premier Support、2029年12月31日まで 2030年1月1日から2032年12月31日までの拡張サポート 2033年1月1日から2034年12月31日までのアップグレード・サポート これは知ることがとても大切です。 他のリリースの更新はありますか。 MOSノートの終わりにある変更ログ: 742060.1 – 現在のデータベース・リリースのリリース・スケジュールでは、Oracle Database 21cの最新の更新も確認できます。このリリースのPremier Support期間は、2027年7月31日まで延長されました。 また、Oracle Database 23aiのパッチ適用終了日は2032年12月31日に設定されています。 Lifetime Support Policy 更新は、Oracle Technology Productsの Oracle Lifetime Support Policy (6ページ)でも確認できます。 From: Oracle Lifetime Support Policy for Oracle Technology Product s – page 6 – Nov 19, 2024 特に、次の表に示す制限事項に注意してください。 Oracle Database 1...
続きを読む

ミリ秒の問題: BCCグループとOCIが市場データ・パフォーマンスを再定義する方法(AWSに対するベンチマークを使用) (2025/11/13)

イメージ
ミリ秒の問題: BCCグループとOCIが市場データ・パフォーマンスを再定義する方法(AWSに対するベンチマークを使用) (2025/11/13) https://blogs.oracle.com/cloud-infrastructure/post/milliseconds-matter-bcc-group-and-oci-vs-aws 投稿者： Steven Riley | Senior Cloud Architect William Bierds | Business Analyst and Systems Engineer - BCC Group International Travis Liles | Master Principal Cloud Architect Puru Patel | Cloud Architect - FSI これは、BCC グループと Oracle Cloud Infrastructure (OCI) 間の市場データ パートナーシップを紹介するブログ シリーズの第 2 部です。   はじめに 金融市場データアプリケーションは、トレーダー、金融機関、そして市場参加者が情報に基づいた意思決定を行えるよう、リアルタイムデータを提供することで、取引エコシステムにおいて重要な役割を果たしています。 前回のブログ で述べたように、取引環境において最適なパフォーマンスを確保するには、市場データを超低レイテンシかつ高い信頼性で配信する必要があります。 今日の急速に変化する金融市場において、クラウドは市場データ・アプリケーションにとって強力な推進力として台頭しています。適切なネットワークとインフラストラクチャがあれば、企業は実行時間の短縮、可用性の向上、そして堅牢なセキュリティを実現できます。しかし、企業によるクラウド導入は遅れており、ワークロードのクラウド移行計画を中止しているケースもあります。そこで、BCCグループとOracle Cloud Infrastructure（OCI）のパートナーシップが注目されています。 BCCグループは、主力市場データアプリケーションであるONE PlatformをOCI上に導入しました。このブログでは、以下の点について説明します。 このパートナーシップがなぜこれほど相乗効果をもたらすのかを探る OC...
続きを読む

Oracle DatabaseをOCI Object Storageの不変バケットにバックアップする理由と方法 (2024/05/27)

イメージ
Oracle DatabaseをOCI Object Storageの不変バケットにバックアップする理由と方法 (2024/05/27) https://database-heartbeat.com/2024/05/27/backup-oss-immutable/ はじめに Oracle Databaseは、オンプレミス、Oracle Cloud、Oracleクラウド以外、マルチクラウド環境など、あらゆる場所で実行されます。Oracle CloudおよびOracle Database@Azureで実行されているOracle Databaseサービスの場合、自動バックアップが使用可能になり、Autonomous Recovery Serviceに推奨されます。これにより、デフォルトで不変性が提供されます。他の場所で実行されているOracle Databaseでは、災害が発生した場合や クラウド・アカウントが誤って削除された場合 のみ、OCI Object Storageに(追加の)バックアップを作成することを検討してください。同僚の Connerが書いた ように、これはポインティングではなく、ディザスタ・リカバリ戦略を強化することを検討するオプションを提供します。 OCI Object Storageのデータは、可用性ドメインまたはフォルト・ドメイン全体でデフォルトで3方向ミラー化され、ハードウェアおよびデータセンターの障害に対する冗長性と保護を提供します。また、バックアップを 不変 バケットに格納し、期限付き保持ルールで制御して、指定した期間におけるデータの変更または削除から保護できます。 OCI用のOracle Database Cloud Backup Module では、OCI Object StorageバケットへのRMANバックアップを直接開始できます。このブログ投稿では、OCI Object Storageの不変バケットへのRMANバックアップを構成および開始するステップについて説明します。 環境 Oracle Cloud以外で実行されている顧客管理Oracle Database 「sales_db_backups」という名前の不変バケット: データベース・バックアップを格納するための保持ルールおよびルール・ロックで構成されたOCI Object Sto...
続きを読む