あらゆるソース環境からのOracleワークロードにOCIサイバー・リカバリを実装
このリファレンス・アーキテクチャは、サイバー・インシデント後のビジネス・サービスのリカバリ検証、フォレンジック分析およびリストアのための制御された環境を提供します。
本番ワークロードは、OCI、Oracleマルチクラウド・データベース・サービス、別のハイパースケーラまたはオンプレミス・インフラストラクチャで実行できます。いずれの場合も、サイバー・リカバリ・ボールトは別のOCIテナンシにデプロイされ、独立したリカバリ・コントロール・プレーンとして操作されます。
このアーキテクチャは、Oracle AI Databaseと従来のOracleデータベース・デプロイメントの両方を含む、Oracleデータベースに依存するOracleアプリケーション・エステート用に設計されています。データベースは多くの場合、レコードのプライマリ・システムですが、使用可能なリカバリには、サービスの再構成に必要なアプリケーション・アーティファクトの最小セットも必要です。これらのアーティファクトには、アプリケーション層バックアップ、構成ファイル、共有ファイル・システム、デプロイメント・マニフェスト、ミドルウェア構成、コンテナ・イメージ、データベース・ウォレット、暗号化メタデータおよびリカバリ・ランブックを含めることができます。
サイバー・ボールトはストレージ・ターゲットであり、制御された検証およびリカバリ環境です。不変バックアップ・コピーはOracle Cloud Infrastructure Object Storageに保持されますが、重要な差別化要因は、選択したリカバリ・ポイントが使用可能であることを証明するために必要なプロセス、自動化、コンピュート、データベース・リストア・ターゲット、スキャン・ツールおよびクリーンルーム環境がボールトに含まれていることです。
このアーキテクチャでは、別のサイバー・リカバリ・テナンシが、不変のコピーを格納し、本番からエア・ギャップを保ち、広範な本番信頼をボールトに拡張するのではなく、サイバー・リカバリ・テナンシ内からコピー操作を開始します。個別のサイバー・リカバリ・テナンシ、ボールト側の同期、不変のOCIオブジェクト・ストレージ・バケット、ウイルス対策スキャン、署名検証、クリーンルーム・テストをコア設計原則として使用します。
目的は、バックアップを保持するだけでなく、バックアップが次のものであることを確認することです。
- リカバリ可能
- 改ざんから解放
- マルウェアから解放
このアーキテクチャの違い
多くのサイバー・リカバリ・サービスは、マネージド・サービスまたはマネージド・プロバイダ・テナンシにバックアップ・コピーを格納し、それらのバックアップ・オブジェクトをマルウェア用にスキャンすることに重点を置いています。このアプローチは有用ですが、Oracleワークロードでは不完全です。
このアーキテクチャはさらに進みます。OCIボールトには、顧客管理ボールト・テナンシ内の検証プロセスが含まれているためです。ボールトは、データベースを一時的にリストアし、Oracleネイティブ検証を実行し、ユーザー定義のSQL検証スクリプトを実行し、アプリケーションの整合性を検証し、リカバリ・ポイントを使用できるという証拠を生成できます。
この区別は、バックアップは次のようになる可能性があるため重要です。
- 存在しますが、復元できません
- 不変ですが、格納される前にすでに破損しています
- マルウェアはスキャンされますが、アプリケーション・データ・レイヤーで論理的に改ざんされます。
- 技術的にリストア可能ですが、ウォレット、構成、ファイル・システムまたはミドルウェア・アーティファクトがありません
- データベースに一貫性があるが、アプリケーションには一貫性がない
通常、ストレージ専用またはスキャン専用サービスは、一時的にリストアされたOracle Database内のビジネス・データを検証できません。このOCIベースのボールトは可能です。
Oracleワークロードの場合、アーキテクチャは複数のレイヤーで検証されます。
- バックアップ・ファイルの整合性:ボールトは、オブジェクトの存在、オブジェクト・サイズ、チェックサム、メタデータおよび保存ステータスを検証します。
- Oracleデータベースのリカバリ可能性: RMANの検証では、バックアップ・ピースが完全でリストア可能であることを確認します。Oracle RMAN
validate、restore... validateおよびvalidate backupsetは、欠落または破損したファイル、物理破損、構成されている場合の論理破損およびバックアップ・セットのリストア可能性をチェックできます。 - 一時的にリストアされたデータベース検証:クリーン・ルームは、選択したデータベースをリストアし、ワークロード固有の検証を実行します。検証には、コントロール合計、照合残高、行数ベースライン、高価値のトランザクション・サンプル、スキーマ・ドリフト、無効なオブジェクト、アプリケーション構成表、期間ステータス、ユーザーおよびロールのベースライン、またはその他のビジネス不変条件をチェックするカスタムSQLスクリプトを含めることができます。これらのチェックは、改ざんが発生したことがないことを数学的に証明するものではありませんが、バックアップ・オブジェクト・スキャンで検出できない本番データの改ざんの重要なクラスを検出できます。
- アプリケーション・レベルの検証:ボールトは、リカバリされたデータベースがビジネス・サービスの再開に必要な最小限のアプリケーション・スタックで動作することを検証します
- 操作リカバリ・エビデンス:ボールトには、検証レポート、リストア・ログ、SQL検証結果、スキャン結果およびクリーンルーム・テスト結果が保持されたエビデンスとして格納されます。
サイバー・リカバリ・パイプライン-oracle.zip#GUID-17034D86-DC64-4F72-B26C-E42B9A34C3BC
- バックアップ生成: データベース、アプリケーションおよびインフラストラクチャ・バックアップは、本番テナンシに作成されます。
- セキュアなイングレスおよび検証: バックアップはボールトに安全に転送されます。マニフェストとチェックサムが検証されます。
- 不変ストレージ: バックアップは、保持ルールを使用してOCIオブジェクト・ストレージ・バケットに格納され、必要に応じてロックされます。
- RMAN検証: RMAN VALIDATEおよびクロスチェック操作によって、バックアップの整合性とリカバリ可能性が検証されます。
- 一時リストア・クリーン・ルーム: バックアップは、ボールト・テナンシ内の分離されたクリーン・ルーム環境にリストアされます。
- カスタムSQL検証: ワークロード固有のSQLスクリプトは、データの正確性、リコンシリエーションおよびビジネス・ルールを検証します。
- アプリケーション検証: アプリケーション・サービスが開始され、煙テストによって機能と統合が検証されます。
- スキャン: AVと脆弱性: ClamAVなどのマルウェア・スキャンと、OCI Vulnerability Scanning Serviceなどの脆弱性スキャンが実行されます。
- リカバリ・エビデンスと承認: 結果が収集され、エビデンスが保存され、リカバリ・ポイントの使用が承認されます。
主な成果:
- バックアップが存在し、変更されていない
- RMANを使用してバックアップをリストアできます。
- データはビジネス・ルールで検証されます。
- アプリケーションで機能が検証されます。
- リスクがスキャンされ、報告される
- 回復ポイントは証明され、承認されます
目的
アーキテクチャは、リカバリ・アーティファクトが次のようになっていることを確認する必要があります。
- リカバリ可能:データベースのバックアップおよびアプリケーション・アーティファクトは、お客様が管理するクリーン・ルームにリストアできます。
- 改ざん防止:バックアップ・オブジェクトは、Oracle Cloud Infrastructure Object Storageの保存ルールによって保護されます。時間制限保持ルールは、構成された期間の変更と削除を防止し、ロックされた保持ルールは、必須ロック遅延後に元に戻せません。ロックされた保持ルールは、テナンシ管理者またはOracle Supportでも削除できません。
- 独立して制御:ボールト・テナンシは、保持されているバックアップ・アーティファクトを所有します。本番管理者および本番自動化では、レコードのボールト・コピーを広範または永続的に制御することはできません。
- 検証済:ボールトは、確定的整合性、リストア、データベース、SQLおよびアプリケーション・レベルのチェックを実行します。
- ソース・プラットフォーム間でのポータブル:同じボールト・パターンは、ソースがOracle Cloud Infrastructure Object Storageにコピーできる顧客制御バックアップ・アーティファクトを生成できる場合に、OracleワークロードがOCI、別のハイパースケーラ、Oracleマルチクラウド・データベース・サービス、またはオンプレミス・インフラストラクチャのいずれから発生するかに適用されます。
目的は、破壊的またはランサムウェアイベント後に最小限の生存可能な企業を回復させることです。このアーキテクチャは、重要な業務再開に必要な最小限のOracleバックアップ・システム・セットを保持し、検証します。
最小生存会社(MVC)
最小限の実行可能な企業は、サイバー攻撃後に重要な業務を継続するために必要なビジネス・サービス、アプリケーション、データベース、ユーザー、統合および運用プロセスの最小セットです。サイバー・リカバリ・アーキテクチャでは、MVCの概念は、クリーン・ルームで最初にどのワークロードをリストアし、完全なエンタープライズ・リカバリを開始する前にビジネス機能を検証する必要があるかを優先順位付けするのに役立ちます。このソリューションは、IT資産全体を即座に回復しようとするのではなく、重要な事業運営を維持し、財務および規制上の義務を維持し、管理された事業継続性をサポートするために必要なコア・システムを迅速に回復することに重点を置いています。MVCの概念は、英国国家サイバー・セキュリティ・センター(NCSC)サイバー・アセスメント・フレームワーク(CAF)と密接に連携しており、サイバー・インシデント後の重要なビジネス機能とサービスの特定と回復を強調しています。このMVCは、より広範なエンタープライズ・リカバリを継続しながら、重要な運用を維持するために必要な最小限のビジネス機能、アプリケーション、データ、ユーザーおよび運用プロセスを表します。
次に、最小実行可能な会社(MVC)回復モデルのフェーズを一覧表示します。
-
フェーズ1: アクセスとコア・プラットフォームの確立
- 基本的なサービスをリストアして、安全なアクセスと基本的な操作を実現
- Identity & Access Management(IAM)
- ネットワーキングおよび接続(DNS、VPN、要塞)
- セキュリティと監視(ロギング、クラウド・ガード)
- オブジェクト・ストレージ・アクセス(サービス・ゲートウェイ/PE)
結果:重要なワークロードを回復するために確立された安全なアクセス。
-
フェーズ2: コア・データとデータベースのリストア
- ビジネスクリティカルな機能に必要なコア・データベースとデータ・サービスを復元
- 重要なOracle Databases(ERP、財務、人事など)
- データベース・インフラストラクチャ(ASM、リスナー、TDEウォレット)
- キー・データ・ストア(アイデンティティ、参照データ)
- バックアップ検証(RMAN検証)
結果:コア・データおよびデータベースは利用でき、検証されます。
-
フェーズ3: 重要なアプリケーションのリストア
- 運用に必要な最小限のアプリケーションとサポート・サービスを復元します。
- アプリケーション・サーバー(ERP、ミドルウェア、ポータル)
- 統合サービス(インタフェース、API、キュー)
- 共有ファイル・システム(構成、アップロード)
- 依存性(Redis、MQ、キャッシュなど)
結果:重要なアプリケーションが稼働し、統合されています。
-
フェーズ4: ビジネスおよび業務の検証
- ビジネスプロセスを検証し、MVCを操作する機能を確認します
- カスタムSQL検証(ビジネス・ルール、照合)
- アプリケーション・スモーク・テスト(キー機能およびトランザクション)
- ユーザー・アクセスの検証(ロール、権限)
- 運用準備状況(モニタリング、アラート、ジョブ)
結果:ビジネスプロセスは検証され、MVC内で動作します。
-
フェーズ5: 拡張と完全リカバリ
- リカバリを追加システムに拡張し、エンタープライズ機能をフルにリストア
- レポートとアナリティクス
- 非クリティカルなアプリケーションおよびワークロード
- DRから本番(必要な場合)
- 最適化と拡張(パフォーマンス、容量)
結果:完全なエンタープライズ機能が復元されます。
主な原則:
- ビジネス成果の優先順位付け: 事業運営に不可欠なものにフォーカスします。
- フェーズでのリカバリ: 小さく開始し、検証してから展開します。
- 継続的に検証: 先に進む前に各フェーズが機能することを証明します。
- 安全な運用: 分離、アクセス制御、監視を維持します。
- Evidence Everything: 結果を記録し、監査エビデンスを保持します。
MVCは次の機能を提供します。
- 高速リカバリ: 操作に必要な最小限に焦点を当てます。
- リスクの軽減: リカバリ中のエクスポージャと複雑さを制限します。
- コストの削減: 必要な場合にのみリカバリします。
- ビジネス継続性: 重要な業務と規制上の義務を維持します。
- 完全リカバリへのパス: 制御および検証された方法で拡張します。
アーキテクチャ
図oci-cyber-recovery-workloads-arch.pngの説明
oci-cyber-recovery-workloads-arch-oracle.zip#GUID-562C8D8A-0AE0-4FB5-B26F-8C63CB5533A2
この図は、OCIで本番ソースとして実行されているOracleワークロードを示しています。同じアーキテクチャが適用されるのは、Oracleワークロードが別のハイパースケーラー、Oracleマルチクラウド・データベース・サービスまたはオンプレミスで実行される場合です。ソース側のバックアップおよび転送メカニズムのみが変更されます。サイバー・ボールト、不変ストレージ、検証パイプライン、スキャン・パイプラインおよびクリーン・ルームは、OCIに残ります。
本番環境では、データベース、アプリケーション、ファイル・システム、イメージおよび構成アーティファクトが作成されます。Vault自動化は、これらのアーティファクトを個別のOCIサイバー・リカバリ・テナンシにコピーします。不変のOCIオブジェクト・ストレージ・バケットは、保持されるアーティファクトを保持ルールで保護します。確定的検証パイプラインは、オブジェクトの整合性、バックアップの完全性、RMANリカバリ性およびリストアされたデータベースの一貫性をチェックします。クリーン・ルームは、選択したデータベースおよびアプリケーション・コンポーネントを一時的にリストアし、カスタムSQL検証およびアプリケーション・スモーク・テストを実行し、リカバリ・エビデンスを格納します。ClamAVやOCI Vulnerability Scanningなどのオプションのスキャン・ツールは、ファイルベースのアーティファクト、ホストおよびコンテナ・イメージを検査します。オプションの分析では、ボールト・テレメトリで異常を分析できますが、ベースライン・アーキテクチャは確定的検証と制御されたリストア・テストに依存します。
アーキテクチャには次の環境が含まれます。
- 本番環境
- Vaultイングレス環境
- 不変ボールトストレージ
- 確定的検証環境
- クリーンルームの検証と回復環境
- オプションの拡張分析およびAI異常検出環境
本番環境
本番Oracleワークロードは、次のいずれかの場所で実行できます。
- OCI
- Oracle AI Database@Azure
- Oracle AI Database@Google Cloud
- Oracle AI Database@AWS
- 別のハイパースケーラー
- オンプレミス・インフラストラクチャ
アーキテクチャでは、いずれの場合も同じ原則が使用されます。本番環境では、OCIサイバー・リカバリ・テナンシにコピーできる顧客制御バックアップ・アーティファクトを生成または公開する必要があります。
Oracleデータベースの場合、優先アーティファクトはRMAN互換バックアップで、顧客は自分で制御してリストアできます。Oracle applicationsの場合、追加のアーティファクト(アプリケーション・バイナリ、ミドルウェア構成、共有ファイル・システム、デプロイメント・マニフェスト、証明書、ウォレット、キー、運用ランブックなど)を保持する必要があります。
このアーキテクチャでは、Oracle Database Zero Data Loss Autonomous Recovery Serviceはレコードのサイバー・ボールト・コピーとして位置付けられません。リカバリ・サービスは、運用データベース保護、ほぼゼロのRPO目標、およびサービス管理のリストア・ワークフローに役立ちますが、ここでの主な要件は、個別のOCIサイバー・リカバリ・テナンシに格納された顧客管理バックアップ・アーティファクトです。サイバー・リカバリ・テナンシは、お客様の制御下でバックアップ・アーティファクトを個別に所有、保持、検証およびリストアできる必要があります。リカバリ・サービスでは、基礎となるバックアップ・ファイルへの直接アクセスは提供されません。また、リカバリ・サービスで保護されたバックアップは、独立したサイバー・リカバリ・テナンシにエクスポートおよびリストアするのではなく、同じ本番テナンシ内でリストアされるように設計されています。このアーキテクチャは、独立したクリーン・ルームでリストアおよび検証できるボールト所有の不変バックアップ・コピーに依存するため、この設計では、リカバリ・サービスをバックアップ・ソースまたはレコード・ボールト・コピーとして使用しないでください。
Vaultイングレス環境
ボールト・イングレス・レイヤーは、サイバー・リカバリ・テナンシで実行されます。本番または中間ソースの場所からのバックアップ・アーティファクトの制御された取込みを実行します。
優先パターンはvault-initiated copyです。本番環境では、特定のバックアップ場所への範囲が狭い読取りアクセス権が付与され、ボールト・テナンシで実行されている自動化によって、新しいアーティファクトがボールトにプルされます。このパターンは、生産からボールトへの永続的な広範な信頼関係を回避します。
OCIソース・テナンシの場合、ボールトは、クロステナンシのIAMポリシーおよびOCIオブジェクト・ストレージのコピー操作と、サイバー・リカバリ・テナンシ内から開始された同期スクリプトを使用して、新しいバックアップ・オブジェクトをサイバー・リカバリ・テナンシにコピーできます。
OCI以外のソースの場合、パターンは次のいずれかの方法を使用できます:
- RMANは、制限されたOracle Cloud Infrastructure Object Storageイングレス・バケットに直接書き込みます。
- ソース側の自動化により、バックアップ・アーティファクトが制限されたOCIイングレス・バケットに書き込まれます。
- 一時的なランディング・バケットが使用され、ボールト所有の自動化によって、アーティファクトが保持される不変ストレージにコピーされます。
- 必要な場合は、専用のプライベート接続、VPN、Oracle Cloud Infrastructure FastConnectまたは顧客承認の転送ツールが使用されます。
ほとんどの設計では、イングレス・バケットをレコードの最終ボールト・コピーとして扱わないでください。より安全なモデルは、イングレスをランディング領域または隔離領域として処理し、初期完全性およびメタデータ・チェック後に不変のボールト・ストレージにボールト所有のコピーを実行することです。
不変Vaultストレージ
ボールトは、リカバリ・アーティファクトをプライベートOracle Cloud Infrastructure Object Storageバケットに格納します。保存ルールは、必要な保存期間の変更および削除を防ぐために使用されます。ロックされた保持ルールは、顧客が管理者耐性の不変性を必要とする場所で使用されます。
次の一般的なバケット・レイアウトを使用します。
- イングレス・バケット 新しくコピーされたアーティファクトを受け取ります。アクセスは厳しく制限されています。設計によっては、保存期間が短いか、またはない場合があります。
- 不変データベース・バックアップ・バケット。 RMANバックアップ・ピース、アーカイブ・ログ、制御ファイル・バックアップ、SPFILEバックアップおよびデータベース・バックアップ・マニフェストを格納します。
- 不変アプリケーション・アーティファクト・バケット。 アプリケーション層のバックアップ、構成バンドル、デプロイメント・マニフェスト、ミドルウェア構成、ファイル・システム・エクスポート、コンテナ・マニフェストおよびリカバリ・スクリプトを格納します。
- マニフェストと証拠バケット。 バックアップ・マニフェスト、ハッシュ・レポート、検証ログ、RMAN検証出力、SQL検証結果、マルウェア・スキャン結果、脆弱性スキャン・レポート、クリーンルーム・リストア・レポートおよびオペレータ承認を格納します。
- ステージング・バケットをリストアします。 リストア前にアーティファクトをステージング、解凍、スキャンまたは変換する必要がある場合にクリーンルーム・ジョブで使用されます。
- オプションの2番目のリージョン・コピー・バケット。 地域生存のために使用される。このコピーを独立した不変性と区別します。独立して保持される不変コピーを顧客が要求する場合は、レプリケーション・セマンティクスにのみ依存するのではなく、別の制御されたコピー・プロセスを2番目の保持バケットに使用します。
確定的検証環境
確定的検証は、アーキテクチャのベースライン機能です。すべてのデプロイメントに決定的検証を含めます。
ベースライン検証パイプラインには、次のチェックが含まれます。
- オブジェクトとマニフェストの検証
各バックアップサイクルは、次の内容を記録するマニフェストを生成する必要があります。
- ソースシステム
- データベース名
- DBID
- インカーネーション
- バックアップ・タグ
- バックアップの開始時間および終了時間
- オブジェクト名
- オブジェクト・サイズ
- チェックサムまたはハッシュ
- 暗号化の依存関係
- Walletまたはキー依存性
- 保存期間
- アプリケーション・アーティファクトの依存性
- クリーンルーム検証ステータス
Vault自動化は、マニフェストをボールトにコピーされたオブジェクトと比較します。欠落しているオブジェクト、予期しないオブジェクト数、サイズの不一致、チェックサムの不一致および予期しないタイムスタンプの変更によりアラートが発生する必要があります。
- 保存およびストレージ・ポリシーの検証
ボールトは、次の要件を検証します。
- バケットはプライベートです
- 保持ルールが存在します
- ポリシーが必要な場合、保持ルールはロックされます
- 暗号化とお客様のポリシー
- 承認済のボールト自動化のみが不変バケットに書き込むことができます
- 承認済の検証およびリカバリ・ロールのみが保持されたオブジェクトを読み取ることができます
- Oracle Cloud Guardの結果を確認する
- Oracleデータベース・バックアップの検証
ボールトは、データベース・バックアップにRMANネイティブ検証を使用します。
RMANは、バックアップ・セットを検証し、欠落または破損したバックアップ・ピースをチェックし、バックアップをリストアできることを確認し、使用されるコマンドおよびオプションに応じて物理的および論理的な破損をチェックできます。
正確なコマンド・セットは、データベースのバージョン、バックアップ方法、リストア・ターゲット、リカバリ・カタログの設計および顧客ポリシーによって異なります。
- 一時的にリストアされたデータベース検証
一時データベース・リストアの検証では、バックアップ・オブジェクトのみを格納およびスキャンするサイバー・ソリューションとこのアーキテクチャが区別されます。
定義済の間隔で、クリーン・ルームは、保持されたボールト・バックアップから選択したデータベースをリストアします。リストア後、検証パイプラインは一時データベースに対してユーザー定義のSQLチェックを実行します。
アプリケーション固有のワークロードの場合は、正常なビジネス不変条件をチェックするSQL検証スクリプトを追加できます。たとえば、消込合計、元帳残高、取引件数、期間ステータス、参照データ・チェック、アプリケーション・プロファイル・オプション、インタフェース・キュー・ステータス、その他のワークロード固有の管理などがあります。
目的は、バックアップをリストアできることを証明することだけではありません。目的は、本番データがバックアップが作成される前に操作された可能性があることを示す兆候を検出することです。この機能は、Oracle ERP、EPM、金融サービス、およびその他のデータベース中心のアプリケーション環境において重要です。
- 定期的なアプリケーション・テスト
クリーンルームは、ビジネスの回復を証明するために必要な最小限のアプリケーションサービスを定期的に開始またはシミュレートします。
アプリケーション検証には次のチェックを含めることができます。
- アプリケーション・サービスの起動
- ミドルウェアの起動
- リスナーおよび接続チェック
- アプリケーションのログイン・チェック
- バッチ・スケジューラ・チェック
- 統合エンドポイント・チェック
- クリティカル・レポートの実行
- クリティカル・トランザクションの読取り専用検証
- リカバリ受入れ基準との比較
目標は、選択したリカバリ・ポイントがワークロードの完全リカバリをサポートできることを証明することです。
- ボールトでのスキャン
スキャンを含めますが、マルウェア・スキャン、脆弱性スキャンおよびデータベース検証を区別します。
- ClamAVによるマルウェアスキャン
ベースライン・マルウェア・スキャン・オプションでは、OCI ComputeにデプロイされたClamAV、OCI Oracle Cloud Infrastructure Container Instancesまたはボールト・テナンシ内のKubernetes Engineを使用できます。ClamAVは、トロイの木馬、ウイルス、マルウェア、その他の悪意のある脅威を検出するためのオープンソースのウイルス対策エンジンであり、コマンドラインユーティリティ、オンデマンドスキャナ、スキャナーデーモン、および署名の更新が含まれています。
このアーキテクチャでは、ClamAVはOCIマネージド・サービスではありません。ClamAVは、ボールト内のOCIインフラストラクチャで実行される、顧客管理のオープン・ソース・スキャナです。これは、アプリケーション・アーカイブ、スクリプト、エクスポートされたファイル・システム、コンテナ・レイヤーおよびその他のファイルベースのアーティファクトのフリーまたは低コストのベースライン・スキャナとして使用できます。
ClamAVまたはその他のマルウェア・スキャン・ソリューションは、Oracle Databaseバックアップの十分な検証として配置しないでください。データベース・バックアップの検証では、RMANおよびクリーン・ルームのリストア・テストが使用されます。
- OCI脆弱性スキャン
ホストおよびコンテナ・イメージに対するOCIネイティブの脆弱性チェックには、OCI Vulnerability Scanning Serviceを使用します。Oracleのドキュメントでは、OCI Vulnerability Scanningがホストおよびコンテナ・イメージの脆弱性を定期的にチェックし、メトリック、詳細および修正情報をレポートに提供していると述べています。
Kubernetes Engineおよびコンテナ化されたOracleアプリケーション・スタックの場合、必要なイメージをOracle Cloud Infrastructure Registryに格納し、イメージ・スキャンを有効にします。Oracle Cloud Infrastructure Registryイメージ・スキャンでは、OCI脆弱性スキャンが使用されます。有効なリポジトリにプッシュされたイメージは脆弱性をスキャンされ、新しい脆弱性がCVEデータベースに追加されるとリポジトリが再スキャンされます。
- オプションのサード・パーティ・スキャナ
お客様は、ボールトに他のマルウェア、脆弱性、またはコンテナ・セキュリティ・スキャナを実装できます。これらのスキャナは、OCI Compute、Kubernetes Engine、Oracle Cloud Infrastructure Container Instances、Oracle Cloud Infrastructure Functions、またはマーケットプレイス提供のアプライアンスなどのOCIサービスで実行し、同じボールト分離モデルに従います。
スキャン・パイプラインを追加として処理します。スキャンは、マルウェアおよび既知の脆弱性を識別できますが、RMAN検証、SQLデータ検証、クリーンルーム・リストアまたはアプリケーション・スモーク・テストに代わるものではありません。
クリーンルームの検証と回復環境
クリーン・ルームは、サイバー・リカバリ・テナンシ内の分離されたOCI VCNです。クリーン・ルームは、制御されたリストア、データベース検証、マルウェア・スキャン、脆弱性スキャン、SQL検証、アプリケーション・スモーク・テストおよび緊急リカバリに使用されます。
このアーキテクチャでは、生産信頼境界をクリーン・ルームに拡張することはありません。アクセスは、期限付きで監査され、承認されたリカバリ演算子に制限される必要があります。クリーン・ルームでは、プライベート・サブネット、エグレス制限、OCIオブジェクト・ストレージへのプライベート・アクセス、および厳密に管理された管理アクセスを使用する必要があります。
クリーンルームは、次の2つの動作モードをサポートしています。
- 検証・モード
検証モードは、スケジュールされたリカバリの実行時に使用されます。選択したデータベースおよびアプリケーション・コンポーネントをリストアし、確定的チェックを実行し、エビデンスを格納してから、一時リソースを停止またはリセットします。
検証モードでは、次の項目がテストされます。
- RMANリストア
- データベースのオープン
- SQL検証スクリプト
- アプリケーションの接続性
- ミドルウェアの起動
- 選択済ビジネス・プロセス
- 必要なウォレット、証明書およびキーの可用性
- リカバリ時間の測定
- オペレータ・ランブックの精度
- リカバリ・モード
リカバリ・モードは、実際のサイバー・イベント中に使用されます。クリーン・ルームは、ワークロードをプロモート、再構築またはユーザーに接続する前に、最小限の実行可能な会社をリストアおよび検証するためのステージング環境になります。
リカバリ・モードでは、次の操作がサポートされます。
- リカバリ・ポイントの選択
- データベースおよびアプリケーション・アーティファクトのリストア
- 必要に応じてフォレンジック検査
- マルウェアと脆弱性のスキャン
- SQLの改ざん検出チェック
- ビジネス所有者検証
- 制御されたネットワーク・オープン
- クリティカル・サービスのステージング・リカバリ
AI異常検出環境
AIベースの異常検出はオプションの拡張であり、リカバリ・アーキテクチャのベースライン要件ではありません。
ベースライン・リカバリ・プロセスは、マニフェスト・チェック、チェックサム検証、RMAN検証、SQL検証、クリーンルーム・リストア、アプリケーション・スモーク・テストなどの確定的検証制御に依存する必要があります。これらの制御は、監査が容易であり、繰り返し可能な結果を生成し、環境を回復できるという直接的な証拠を提供します。
運用の成熟度、テレメトリ品質、ガバナンス・プロセスがサポートする場所に、オプションの分析または異常検出エンクレーブを追加できます。このエンクレーブは、次のようなボールト・ローカル・テレメトリおよびバックアップ・メタデータを分析できます。
- バックアップ頻度の変更によるバックアップ・サイズの変更
- コピー・ジョブの失敗によるバックアップ・サイクルの欠落
- 検証失敗
- チェックサムの不一致
- RMANエラー
- SQL検証失敗
- 保持ルールの変更
- 異常なオブジェクト読取り
- 失敗した管理アクション
- Oracle Cloud Guardの結果
- クリーンルーム・リストア期間の変更
- コンテナ・イメージ・バージョンに予期しない変更があります
この拡張レイヤーは、リカバリ環境内に保持されているテレメトリおよびメタデータを分析します。ライブ生産トラフィックを検査しません。その目的は、異常を強調表示し、調査に優先順位を付けることですが、リカバリ承認は、決定的な検証結果および適切なアプリケーションまたはビジネス所有者による受入れに基づいて維持されます。
レコメンデーション
- OCIソース・ワークロードに関する考慮事項
OCIで本番を実行する場合、ソース・エステートには、データベース、コンピュート・インスタンス、ブロック・ボリューム、ブート・ボリューム、ファイル・システム、Kubernetes Engine永続ボリュームおよびコンテナ・イメージを含めることができます。
- データベース・バックアップ
Oracle Cloud Infrastructure Object Storageで操作可能なバックアップ・アーティファクトを生成する、顧客制御のRMANまたはサービス・ツールを使用します。アーティファクトは、サイバー・リカバリ・テナンシにコピーされ、保存ルールによって保護されます。
- ブロック・ボリュームのバックアップ
ブート以外のブロック・ボリュームの場合、Oracle Cloud Infrastructure Block Volumesバックアップによって、アプリケーション・データ・ボリューム、ミドルウェア・ボリュームまたはカスタム・ソフトウェア・ボリュームを保護できます。ボールトの設計では、それらのボリュームをクリーンルームに復元する機能を保持する必要があります。
-
ブート・ボリュームのバックアップとカスタム・イメージ
OCIブート・ボリュームの場合、ブート可能イメージの本番テナンシの外部でドキュメント化されたエクスポート・パスは、ブート・ボリュームを使用するインスタンスからカスタム・イメージを作成し、そのカスタム・イメージをOCIオブジェクト・ストレージにエクスポートすることです。
したがって、OCI本番のブート可能なアプリケーション・サーバーの場合、ボールト・パターンは次のとおりです:
- インスタンスからカスタム・イメージを作成します。
- カスタム・イメージをOCIオブジェクト・ストレージにエクスポートします。
- エクスポートされたイメージ・オブジェクトをサイバー・リカバリ・テナンシにコピーします。
- OCIオブジェクト・ストレージ保存ルールを使用して、エクスポートされたイメージ・オブジェクトを保護します。
- クリーンルームの検証または回復中にイメージをインポートまたは使用します。
Oracleのカスタム・イメージ・エクスポート・ドキュメントでは、エクスポートされたイメージは、イメージの作成時にVMまたはベア・メタル・インスタンスのブート・ボリュームおよびメタデータのコピーであり、そのエクスポートによって、指定されたOCIオブジェクト・ストレージの場所にデータがコピーされます。エクスポート形式には、VMDK、VHD、VDI、QCOW2およびOCIイメージ形式が含まれます。
アプリケーション層ブート・ボリュームには、多くの場合、重要なバイナリ、オペレーティング・システム構成、エージェント、スクリプトおよびミドルウェア・インストールの詳細が含まれます。
-
Oracle Cloud Infrastructure File Storage
共有アプリケーション・ファイル・システムの場合、Oracle Cloud Infrastructure File StorageスナップショットまたはOCI Object Storageへのファイル・レベルのバックアップ・エクスポートを使用します。選択したパターンは、アプリケーションの整合性を保持し、クリーンルームのリストアをサポートする必要があります。
-
Kubernetes Engineとコンテナ化されたアプリケーション・スタック
Kubernetes EngineベースのOracleアプリケーション・スタックの場合、次の項目を保持します:
- Kubernetesマニフェスト
- Helmチャートまたはデプロイメント・テンプレート
- コンテナ・イメージ
- 永続ボリューム・バックアップまたはスナップショット
- アプリケーション・シークレットのリカバリ・プロセス
- イングレスおよびサービス定義
- データベースの接続構成
- イメージスキャンレポート
Oracle Cloud Infrastructure Registryのコンテナ・イメージにOCI Vulnerability Scanning Serviceを使用し、必要に応じて、ファイル・レベルのアーティファクトのClamAVまたはサードパーティ・スキャナを追加します。
考慮事項
-
OCIの外部で実行されるOracleワークロードの場合、ボールト原則は変更されません。本番環境では、OCIサイバー・リカバリ・テナンシが所有、保持、検証およびリストアできる顧客制御アーティファクトを生成する必要があります。
Oracleデータベースの場合、これは通常、RMAN互換のバックアップ・ピースがOracle Cloud Infrastructure Object Storageに書き込まれるか、制御された転送プロセスを介してOracle Cloud Infrastructure Object Storageにコピーされることを意味します。
-
OCIの外部で実行されるアプリケーション層の場合、お客様は次のアーティファクトをエクスポートまたはパッケージ化する必要があります:
- 必要な場合は仮想マシン・イメージ
- アプリケーション・バイナリ
- ミドルウェア構成
- ファイル・システムのバックアップ
- Kubernetesマニフェスト
- コンテナ・イメージ
- シークレット・リカバリ手順
- 証明書とウォレット
- ランブック
クリーンルームのリストア要件に基づいて、ターゲット形式を選択します。OCIクリーン・ルームでこれらのバックアップを顧客制御下にリストアできない場合、ボールトは不透明なプロバイダ管理バックアップのみを保持できません。
-
サイバー・リカバリ・コントロール・プレーンとしての検証済リカバリ: OCIサイバー・リカバリ・ソリューションは、別のOCIテナンシ内に顧客制御の検証およびリカバリ・プラットフォームを提供するため、バックアップ専用またはスキャン専用のサイバー・リカバリ・ソリューションとは異なります。
ボールトは、バックアップを保持するだけでなく、バックアップをリストアし、検証し、適用可能なアーティファクトをスキャンし、OracleネイティブのRMANチェックを実行し、一時的にリストアされたデータベースに対してユーザー定義のSQL検証を実行し、アプリケーションの準備状況を検証し、リカバリ可能性の監査可能なエビデンスを生成します。