Oracle Data Safe

解決する課題

• データベースのセキュリティ設定が安全かどうかを継続的に評価したい
• 過剰なユーザー権限・ロールを棚卸しし、最小権限化したい
• DB の**操作ログ（監査証跡）**を収集し、不審なアクティビティを検知したい
• 個人情報などの機密データがどこにあるかを発見し、リスクを把握したい
• 開発・検証環境に渡すデータをマスキングし、本番の機密値を伏せたい

主要概念と用語

• ターゲットデータベース: Data Safe が評価・監査の対象として登録する DB。Autonomous Database、Base Database、Exadata、さらにオンプレや他クラウドの Oracle DB も登録可能
• Security Assessment（セキュリティ評価）: DB の構成・パラメータ・権限などを CIS 等のベンチマークと照らし、リスクを「高・中・低・評価」で提示する診断機能
• User Assessment（ユーザー評価）: DB ユーザーの権限・ロール・最終ログインなどを分析し、高権限ユーザーや休眠アカウントなどのリスクを可視化
• Activity Auditing（アクティビティ監査）: ターゲット DB の監査証跡を収集・保持し、レポートやアラートを生成する機能
• Audit Trail / Audit Policy: 収集対象となる監査証跡と、DB 側で有効化する監査ポリシー。重要操作を選んで記録する
• Alert（アラート）: 監査イベントが条件に合致したときに通知される警告（例: 管理者ログインの失敗、権限昇格）
• Data Discovery（機密データ検出）: 列の名前やデータパターンから個人情報などの機密データを自動検出し、機密データモデルとして整理
• Data Masking（データマスキング）: 検出した機密列を、参照整合性を保ちつつ別の値に置換して非機密化する機能

仕様・制限・クォータ

• リージョン単位のサービスで、各リージョンのテナンシで有効化して利用する
• ターゲット DB への接続にはプライベートエンドポイントやオンプレ接続コネクタなどを用い、ネットワーク経路に応じて構成する
• 監査データには保持期間の概念があり、オンライン保持と長期保持（アーカイブ）で扱いが分かれる。長期保持は追加の対象となる
• マスキングは原則コピー（非本番）環境に対して実行する想定で、本番データそのものを破壊的に書き換える用途ではない
• 評価ベンチマークは CIS や Oracle のセキュリティガイドラインなどに基づき、対応範囲は DB の種別・バージョンにより異なる
• 変動しうる料金体系・保持上限・対象 DB バージョンの詳細は公式ドキュメントで都度確認する

内部の仕組み

Data Safe はエージェントレス寄りのマネージドサービスで、登録したターゲット DB に対し、専用のサービスユーザー（Data Safe 用アカウント）を介して評価・監査・検出を実行します。Security Assessment と User Assessment は、DB のディクショナリやパラメータ、権限情報を読み取り、ベンチマークと突き合わせてリスクスコアを算出します。

Activity Auditing では、ターゲット DB 側で有効化された監査ポリシーが生成する監査証跡を Data Safe が定期的に収集し、サービス側のリポジトリに集約します。集約された監査データに対してアラートルールを評価し、条件に合致すればアラートを生成します。Data Discovery は列メタデータとサンプルデータのパターンマッチで機密列を推定し、その結果を機密データモデルとして保持します。Data Masking はこの機密データモデルを入力に、マスキング定義（フォーマット）を適用して値を置換します。

設計パターン / ベストプラクティス

• 全ターゲット DB に Security Assessment / User Assessment を定期実行し、リスクの増減をベースラインと比較して逸脱を検知
• 重要操作（管理者ログイン、権限付与、スキーマ変更など）に絞って DB 側の監査ポリシーを有効化し、ノイズを抑えつつ重要イベントを確実に記録
• 高リスクや規制対象のイベントにはアラートを設定し、通知サービスと連携して運用フローに乗せる
• 非本番環境を作る際は Data Discovery で機密列を特定 → Data Masking で置換を標準手順化し、開発者に本番の機密値を渡さない
• 機密データモデルとマスキング定義を再利用し、環境払い出しのたびに一貫したマスキングを適用
• ターゲット登録はコンパートメントと IAM ポリシーでスコープを限定し、評価・監査の権限を運用ロールごとに分離

運用・監視

• セキュリティ/ユーザー評価はスケジュール実行し、前回比較（ドリフト）で設定の劣化を早期発見
• アラートは重大度に応じて振り分け、通知サービス経由で担当チームへエスカレーション
• 監査データはオンライン保持と長期保持を使い分け、コンプライアンス要件に合わせて保持期間を設定
• レポート機能で監査サマリやコンプライアンス状況を定期出力し、監査対応の証跡とする
• ターゲット接続が失敗する場合は、プライベートエンドポイント・セキュリティリスト・サービスユーザー権限を確認

コスト

具体的な料金は DB 種別やリージョン、利用機能の組み合わせで変動するため、正式な見積もりは公式の料金情報で確認してください。

セキュリティ

• Data Safe へのアクセスは OCI IAM ポリシーで制御し、評価・監査・マスキングの権限を用途ごとに分離して最小権限を徹底
• ターゲット DB との通信はプライベートエンドポイント等で経路を限定し、公開ネットワークへの露出を避ける
• Data Safe 自身の操作は OCI Audit に記録され、誰がいつ評価・マスキングを行ったかを追跡可能
• 機密データはマスキングにより非本番環境へ漏らさず、本番データのコピー運用と組み合わせてブラスト半径を限定

Well-Architected の観点

• セキュリティ: 設定診断（Security/User Assessment）で構成リスクを継続評価し、監査で操作証跡を確保、機密データ検出・マスキングでデータ保護を実現する。予防・検知・データ保護の3層を1サービスで支援し、Well-Architected のセキュリティ柱に直接寄与する

試験で問われるポイント

関連サービス・比較

機密データ検出だけを取り出せば AWS Macie が近い相当ですが、Macie が主に S3 のデータを対象とするのに対し、Data Safe はOracle DB に特化し、評価・監査・マスキングまで一気通貫で扱う点が異なります。

ハンズオン / CLI例

# 1. ターゲットデータベースを Data Safe に登録（Autonomous Database を例に）
oci data-safe target-database create \
  --compartment-id <compartment-ocid> \
  --display-name prod-adb-target \
  --database-details '{
    "databaseType": "AUTONOMOUS_DATABASE",
    "infrastructureType": "ORACLE_CLOUD",
    "autonomousDatabaseId": "<autonomous-db-ocid>"
  }'

# 2. 登録済みターゲット一覧を確認
oci data-safe target-database list \
  --compartment-id <compartment-ocid>

# 3. セキュリティ評価を実行（DB 設定のリスク診断）
oci data-safe security-assessment create \
  --compartment-id <compartment-ocid> \
  --target-id <target-database-ocid> \
  --display-name prod-security-assessment

# 4. ユーザー評価を実行（権限・休眠アカウントの診断）
oci data-safe user-assessment create \
  --compartment-id <compartment-ocid> \
  --target-id <target-database-ocid> \
  --display-name prod-user-assessment

# 5. 監査証跡の収集を開始（Activity Auditing）
oci data-safe audit-trail start \
  --audit-trail-id <audit-trail-ocid>