データを最初に保護する: Database Vaultデプロイメントへの実際的なアプローチ (2026/06/01)

データを最初に保護する: Database Vaultデプロイメントへの実際的なアプローチ (2026/06/01)

https://www.ateam-oracle.com/protect-the-data-first-a-pragmatic-approach-to-database-vault-deployment

投稿者：Gian Sartor

Oracle Database Vault (DV) は、Oracle Database スタックの中で最も誤解されているセキュリティ機能の 1 つです。

多くのDBAは「職務分掌」という言葉を聞くと、Database Vaultによって運用が阻害され、パッチ適用が複雑化し、SYSがロックダウンされ、アプリケーションチームから無数のチケットが発行されるだろうと即座に考えます。確かに、そうした懸念の一部は理解できます。

多くのOracle環境では、日常的な管理において依然としてSYSDBAアクセスに大きく依存しています。一部の組織では、自動化フレームワーク、運用スクリプト、監視プラットフォーム、プロビジョニングシステム、デプロイメントパイプラインなど、すべてSYSがほぼすべての操作を実行できることを前提としたシステムを採用しています。

そしてDatabase Vaultが有効になると、長年問題なく機能していた自動化が突然機能しなくなります。DBAはこれまでと同じようにデータベースを操作できなくなり、簡単なタスクを完了するためだけに、いくつもの面倒な手順を踏まなければならなくなります。フラストレーションが溜まり、DBAチームは不満を募らせます。

よくあるのは（そして私は何度も見てきましたが）、Database Vaultが全くデプロイされないか、あるいは不適切にデプロイされた後、ひっそりと無効化されるかのどちらかです。

もちろん、どちらの結果も好ましいものではありませんが、実際には、Database Vaultは、侵害されたDBA認証情報を含む、特権を持つ内部関係者による機密データの不正アクセスからデータを保護するために利用できる最も強力な制御手段の1つです。問題はテクノロジーそのものではなく、組織の現在の運用慣行と衝突し、導入初期段階でかなりの運用上の摩擦を生じさせることです。

この記事の目的は、運用への影響を最小限に抑えつつ、有意義なセキュリティ価値を提供する、実践的なデータベースボールトの導入モデルを読者に解説することです。

Database Vaultが存在する理由

従来、Oracleの特権ユーザーは、データベース内のほぼすべてのセキュリティ境界を効果的に回避することができました。SYSDBAアクセス権があれば、次のようなことが可能でした。

  • どの表でも読み取ってください
  • スキーマを変更する
  • 自分に特権を与えよう
  • 監査を無効にする
  • セキュリティ上重要なパラメータを変更する
  • バックドアユーザーを作成する
  • あなたを止めるためのコントロールを無効にする

そのモデルは、現代のコンプライアンスフレームワークや現代の脅威モデルとはうまく整合しません。今日、組織は以下のことを想定する必要があります。

  • 特権的な認証情報は盗まれる可能性がある
  • 内部脅威は現実のものである
  • 管理者アカウントは、無制限のデータアクセス権限を常に信頼できるとは限りません。
  • 規制枠組みは、職務分掌をますます要求するようになっている

ここでDatabase Vaultが非常に役立ちます。組織がトークン化やフィールドレベル暗号化ソリューションを導入しようとするのをよく見かけますが、これは特権ユーザーがデータベース内の機密データにアクセスするのを防ぐ唯一の方法だと考えているからです。特権アカウントをデータから遠ざけるためにデータをトークン化する必要はありません。Database Vaultを使えばそれが可能です。Database Vaultはデータベースにネイティブに組み込まれており、トークン化よりもパフォーマンスが高く、正しく導入すればより簡単に展開できます。

Database Vaultは、特権アクセスに関するポリシーベースの制御機能を提供します。最も重要なのは、SYSなどの強力なアカウントから機密性の高いスキーマやデータを保護できることです。これにより、たとえ強力なシステム権限を既に持っているユーザーであっても、誰が何を実行できるかを制御できるようになります。

では、データベースボールトを有効にした直後には何が起こるのでしょうか？

導入における課題のほとんどはここから始まります。Database Vaultが有効になると、Oracleは即座に一連のデフォルトの保護機能と制限を適用します。運用上の最大の衝撃は、SYSがアカウント管理機能をはじめ、日常業務に不可欠と考えられる多くの機能を失うことです。

SYSへの即時的な影響

SYSにどのような変更がありますか？変わらないもの
ユーザーの作成/変更/削除はできません運用パラメータについては、引き続きALTER SYSTEMを使用できます。
プロファイルの作成/変更/削除ができません起動/シャットダウンは可能です
セキュリティ上重要な特定のパラメータについては、システムを変更できません。RMANのバックアップ/リストアは引き続き実行可能です。
テーブルスペース、リドゥログ、インフラストラクチャは引き続き管理できます

この挙動は多くのDBAを驚かせます。重要なのは、Database Vaultは通常のデータベース管理を妨げようとしているのではなく、セキュリティ境界を弱める可能性のある操作を特に標的にしているということです。例えば、次のような操作です。

  • 不正ユーザーの作成
  • 特権の付与
  • 監査を無効にする
  • 保護されたスキーマの変更
  • 職務分離規制の回避

Database Vault がデフォルトで有効にするもの

Database Vaultを有効にすると、Oracleは自動的にいくつかのデフォルトレルム、コマンドルール、およびポリシーをインストールします。これらは、データベースを保護し、職務分掌を実装することでセキュリティ境界を強化することを目的としています。

この記事の後半で説明するように、この職​​務分担が主に以下のデータベース ボールト ロール（DV_OWNER、DV_ACCTMGR、DV_PATCH_ADMIN）によって強制されていることを理解することが成功の鍵となります。以下の表は、これら 3 つのロールが何に使用されるかを理解するのに役立ちます。

DVの役割責任操作例
DVオーナーセキュリティポリシー管理レルムの作成/変更/削除、コマンドルール、ポリシーの設定、レルム内のユーザーの認証
DV_ACCTMGRユーザーアカウント管理ユーザーの作成/変更/削除、プロファイル、パスワードのリセット、セッションの作成権限の付与
DV_PATCH_ADMIN（通常は一時的に付与される）データベースインフラストラクチャALTER SYSTEM、RMAN、パッチ適用、起動/停止

Database Vaultは、Oracleが提供するロールからいくつかの強力な権限を永久に取り消す機能も備えています。

例としては以下のようなものがあります。

役割特権剥奪
DBAユーザーになる、任意のジョブを作成する、任意のプログラムを実行する、スケジューラを管理する、キュー管理権限
IMP_FULL_DATABASEユーザーになり、キュー管理権限を取得します。
EXECUTE_CATALOG_ROLELogMinerおよびファイル転送パッケージの複数の権限
SCHEDULER_ADMINあらゆるジョブの作成、あらゆるプログラムの実行、スケジューラの管理

取り消されていないSELECT ANY TABLEこと、および Database Vault がアプリケーション スキーマを自動的に保護しないことに注意してください。つまり、SYS は、Database Vault コントロールによって明示的に保護されていないアプリケーション スキーマに対してクエリを実行できます。これらのアプリケーション スキーマを保護するには、通常レルムを作成する必要があり、Database Vault を有効にした後に顧客がレルムを作成する必要があります。

特に、SYSが依然としてほぼすべての業務に使用されており、自動化がSYSへの無制限のアクセスを前提としており、チーム内でまだ成熟した職務分担プロセスが確立されていない組織では、なぜそのような導入の摩擦が生じるのかは、今となってはかなり明白であるはずだ。

初日から完全な職務分掌を実現するのは非現実的であり、また、それが人々がDatabase Vaultを使いたい主な理由でもありません。ですから、それにこだわる必要はありません。より良いアプローチは、段階的に導入を進め、アプリケーションデータを保護しつつ、導入時の摩擦を軽減することです。

低摩擦展開モデル

実際には、Database Vault ロールを SYS に付与することは可能であり、これは Oracle でサポートされている構成です。理想的かと言われればそうではありませんが、役に立つかと言われれば間違いなく役に立ちます。

ここで、SYSオペレーションマトリックスが非常に役立ちます。

Oracle 19cに対するテストの結果、以下のことが判明しました。

OperationSYSデフォルト+ DV_ACCTMGR+ DV_PATCH_ADMIN+ DV_OWNER+ すべての役割
ユーザーを作成するブロックされました許可された許可されたブロックされました許可された
ユーザーの変更（ロック/ロック解除/パスワード）ブロックされました許可された許可されたブロックされました許可された
ユーザーを削除ブロックされました許可された許可されたブロックされました許可された
プロファイルの作成／変更／削除ブロックされました許可された許可されたブロックされました許可された
レルム保護されていないスキーマに対するDDL許可された許可された許可された許可された許可された
レルム保護スキーマに対するDDLブロックされましたブロックされましたブロックされましたブロックされましたブロックされました
DVコントロールの管理
（DBMS_MACADM）		ブロックされましたブロックされましたブロックされました許可された許可された
システム変更（通常パラメータ）許可された許可された許可されたブロックされました許可された
システムの変更（DV保護パラメータ）ブロックされましたブロックされましたブロックされましたブロックされましたブロックされました
DV保護されていないスキーマに対するSELECT許可された許可された許可された許可された許可された
DVで保護されたオブジェクトに対するSELECTブロックされましたブロックされましたブロックされましたブロックされましたブロックされました
起動／停止許可された許可された許可された許可された許可された
RMANバックアップ/リストア許可された許可された許可された許可された許可された

DVロールをSYSに再付与することで、運用上の互換性が大幅に回復します。しかし、いくつかの重要な保護機能は依然として残っています。

SYSにすべての主要なDVロールを付与した後でも：

データベースのデプロイメントモデルやバージョン（12c、19c、26ai、マルチテナント、Autonomous DBなど）は多岐にわたり、Database Vaultの設定方法も様々です。必ずご自身の環境でテストと検証を行ってください。

SYSにDVロールを付与する際の明らかな懸念事項

SYSが以下の状態である場合：

  • DV_OWNER
  • DV_ACCTMGR
  • DV_PATCH_ADMIN

SYSを悪用する者を阻止する手段は実際には存在しない。中でも最も危険なロールはDV_OWNERである。このロールがあれば、SYSはレルムを有効化/無効化したり、レルムの承認済み参加者として新規ユーザーを追加してレルムを完全にバイパスしたりすることが可能になる。

これら3つの役割すべてにおいて、特権管理者は以下のことが可能です。

  • レルムを無効にする
  • レルムを変更して、一時的に保護を弱める。例えば、レルムから保護されたオブジェクトを削除する。
  • 自分自身のために新しいユーザーを作成し、それを承認された参加者として追加する
  • ポリシーをシミュレーションモードに切り替える

そこで問題となるのは、我々が引き起こしたリスクを軽減するために何ができるか、ということだ。

実践的なリスク軽減戦略

組織が初期展開フェーズでDVロールをSYSに再付与することを選択した場合、補償制御はオプションではなく必須事項となります。以下にいくつかの提案を示します。

Oracleユーザーとして直接SSH接続することはできません

ほとんどの組織は既にこのルールを徹底していると思いますが、もしあなたの組織がそうでないなら、すぐに始めてください。ユーザーが「oracle」というユーザーとしてSSH接続を許可されている場合、そのアクティビティを実際の人物にまで遡って追跡することは非常に困難になります。匿名性とセキュリティは両立しません。

すべてのシステムアクティビティを監査する

データベースが従来型の監査を使用している場合は、SYS 操作の監査を有効にする必要がありますALTER SYSTEM SET AUDIT_SYS_OPERATIONS = TRUE SCOPE=SPFILE;が、統合監査に切り替えている場合は、SYS 操作は自動的に監査されます。また、Database Vault 用の事前定義済み統合監査ポリシーがこちらとこちらにありますので、確認して使用してください。

あらゆるレルムの変更を警告する

これを実現するには、監査記録を中央リポジトリに転送するか、中央リポジトリに収集し、そこでアラートを設定する必要があります。以下の変更はすべて

  • レルム
  • コマンドルール
  • ポリシー
  • ルールセット
  • DV認証状態

監査記録とアラートを即座に生成する必要があります。SYSが午前2時にレルムを変更した場合、セキュリティチームはすぐにそれを知る必要があります。

ポリシーステート変更に関するアラート

ポリシーが新しい状態に移行するたびに：

  • ポリシーがシミュレーションモードに切り替わると
  • ポリシーが無効になっている場合
  • ポリシーが作成または有効化されたとき

積極的に監査および監視を行うべきである。

現実的な前進の道

多くの環境では初日から職務分掌を完全に実現することは不可能であり、それをすぐに強制しようとすると、デプロイメントが失敗することが多いことは既に確認済みです。とはいえ、有効化後にこれらのデータベース ボールト ロールを SYS に付与することはプロジェクトの終わりではなく、実際にはフェーズ 1 に過ぎません。ここでは、段階的なアプローチがどのようなものになるかについて、もう少し詳しく説明しました。100% 完成しているわけではありませんが、開始するには十分でしょう。

フェーズ1

  • Database Vaultを有効にする
  • DVロールをSYSに付与する
  • 独自のカスタムレルムを使用して、最も機密性の高いスキーマを保護します。
  • 監査とアラート機能を実装する

フェーズ2

  • 業務上の責任を分離し始める
  • SYSに依存する既存のDBAプロセスと自動化を見直す
    • 理想的には、SYS はデータベースのパッチ適用または起動/停止操作にのみ使用されるべきです。
  • アカウント管理をSYSから切り離す
  • Oracle Instant ClientをDBサーバーにデプロイし、ORACLE_HOME内のクライアントを使用した継承接続ではなく、このInstant Clientを使用してDBへの接続を開始します。
  • 適切な権限を持つ名前付きDBアカウントの使用を開始します。
  • 名前付きDV_OWNERアカウントを導入する
  • 共有特権アクセスへの依存度を低減する
  • 必要に応じて監査とアラートを調整してください。

フェーズ3

  • SYSからDVロールを取り消す
  • 職務分掌を完全に徹底する
  • 状況に応じたコマンドルールと要素を実装する
  • 必要に応じて監査とアラートを調整してください。

まとめ

Database Vaultは、単なるOracleのセキュリティ機能の一つではありません。Oracle Database内部の特権アクセスモデルを根本的に変えるものであり、導入段階では当然ながら多くの問題を引き起こす可能性があります。

解決策は、Database Vaultを避けることでもなければ、運用上の現実を理解せずに無謀に導入することでもありません。

最良の導入事例は、両方の側面を考慮している。

  • DBAは依然としてデータベースを操作する必要がある
  • セキュリティチームは、特権アクセスに関する効果的な制御を依然として必要としている。

摩擦の少ない導入モデルにより、組織は機密データの保護をすぐに開始し、徐々に職務分掌の完全化へと移行できます。まずはデータの保護を最優先に考えましょう。Database Vaultはまさにそこで真価を発揮します。

SYSが明示的な許可なしに人事、PCI、医療、または財務スキーマを読み取ることができなくなった場合、セキュリティ体制は既に大幅に改善されています。それ以降は、成熟度を高めるための道のりとなります。そして、運用チームが初日からテクノロジーと格闘しない限り、その道のりははるかに容易になります。

コメント

コメントを投稿

このブログの人気の投稿

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 Enterprise Manager 24aiの概要 (2024/12/18)

イメージ
Oracle Enterprise Manager 24aiの概要 (2024/12/18) https://blogs.oracle.com/observability/post/oracle-enterprise-manager-24 投稿者： David Le Roy | Senior Director of Product Management 本日、Oracle Enterprise Manager 24ai(EM 24ai)を発表します。これは、最新のAIを活用した管理テクノロジのパワーを活用して、データ・センターとクラウド全体にOracle Databaseとエンジニアド・システムをさらに充実させる画期的なリリースです。ソフトウェアの ダウンロード が可能になりました。この新しいリリースについてさらに学習するには、2024年12月17日から19日に開催されるOracle Enterprise Manager Technology Forumの年次開催にご 参加 ください。 図1: Oracle Enterprise Manager 24aiの概要 この新しいリリースについてさらに学習するには、2024年12月17日から19日に開催されるOracle Enterprise Manager Technology Forumの年次開催にご参加ください。12月17日午前9時に、エンジニアリング担当エグゼクティブ・バイスプレジデントのWim Coekaerts氏と製品管理担当シニア・バイスプレジデントのMughees Minhas氏が率いるイベント基調講演をご覧ください。基調講演に続き、データベース・パフォーマンス、エンジニアド・システム管理、可用性、セキュリティ、コンプライアンスなどに関するベストプラクティスと新製品機能をカバーする25のテクニカル・セッションが追加されました。オラクルのセッションでは、Oracle製品のエキスパートがお客様の技術的な質問にお答えできるよう、Oracle製品マネージャーや主要なお客様が主導しています。 本日 登録 ! Oracle Enterprise Manager 24aiの新機能 EM 24aiリリースは、お客様がオンプレミスおよびクラウドにデプロイされたOracle DatabaseおよびOracle Exadataフ...
続きを読む