5.5. データベースセキュリティ

1. 概要

　データベースセキュリティとは、データベースシステムに対する不正アクセス、不正利用、破壊などの脅威から、格納されている重要なデータを保護するための技術や対策のことを指します。現代の企業や組織において、データベースは顧客情報、財務情報、知的財産などの重要な情報資産を保管する中核システムとなっており、こうしたデータの漏洩や改ざんは、ビジネスの継続性や信頼性に深刻な影響を与える可能性があります。

　特に、クラウドコンピューティングやIoTの普及に伴い、データベースへのアクセス経路が多様化し、セキュリティリスクも増大しています。そのため、多層的なセキュリティ対策を実装し、継続的な監視と改善を行うことが重要です。

graph TD
    A[物理セキュリティ層] -->|保護| B[OSセキュリティ層]
    B -->|保護| C[データベースセキュリティ層]
    C -->|保護| D[アプリケーションセキュリティ層]
    D -->|保護| E[ネットワークセキュリティ層]
    
    style A fill:#f9f9f9,stroke:#333,stroke-width:2px
    style B fill:#f1f1f1,stroke:#333,stroke-width:2px
    style C fill:#e8e8e8,stroke:#333,stroke-width:2px,color:red,stroke-dasharray: 5 5
    style D fill:#e1e1e1,stroke:#333,stroke-width:2px
    style E fill:#d9d9d9,stroke:#333,stroke-width:2px
    
    classDef layer font-size:14px,text-align:center,padding:10px;
    class A,B,C,D,E layer
    
    subgraph データベースセキュリティの実装
    F[データベース暗号化] 
    G[アクセス制御]
    H[バックアップ]
    I[監査ログ]
    J[ブロックチェーン技術]
    end
    
    C --> F
    C --> G
    C --> H
    C --> I
    C --> J

図1: データベースセキュリティの多層防御モデル

2. 詳細説明

2.1. データベース暗号化

　データベース暗号化とは、データベース内のデータを暗号化することで、万が一データが不正に取得された場合でも、暗号キーがなければ内容を解読できないようにする技術です。

2.1.1. 暗号化の種類

• 透過的データ暗号化（TDE）：データベースファイル全体を暗号化
• カラムレベル暗号化：特定の列（個人情報など）のみを暗号化
• アプリケーションレベル暗号化：データベースに格納する前にアプリケーション側で暗号化

2.1.2. 暗号化キーの管理

• マスターキーと暗号化キーの階層構造
• キーローテーション（定期的なキーの更新）
• キーの安全な保管方法（HSM：Hardware Security Module）

データベース暗号化方式の比較

暗号化方式	特徴	利点	欠点	適用例
透過的暗号化(TDE)	DB全体を暗号化	アプリケーション変更不要 導入が比較的容易	パフォーマンス低下 すべてのデータが対象で選択不可	全体保護が必要な場合 法令遵守のため
カラム暗号化	特定列のみ暗号化	重要データの選択的保護 パフォーマンス影響が限定的	アプリケーション変更必要 検索・インデックス構築に制約	個人情報保護 機密データのみの保護
アプリケーション暗号化	DB格納前に暗号化	高度な制御可能 DBMSに依存しない	実装複雑 アプリケーション変更が必須	最高レベルの保護要件 マルチプラットフォーム要件

表1: データベース暗号化方式の比較

2.1.3. 実装例

Oracle Database TDEの実装例

-- マスターキーの作成
ALTER SYSTEM SET ENCRYPTION KEY IDENTIFIED BY "strong_password";

-- テーブル全体の暗号化
CREATE TABLE customer_data (
    id NUMBER,
    name VARCHAR2(100),
    credit_card VARCHAR2(20)
) ENCRYPT;

-- 特定カラムのみの暗号化
CREATE TABLE customer_data (
    id NUMBER,
    name VARCHAR2(100),
    credit_card VARCHAR2(20) ENCRYPT
);

2.2. データベースアクセス制御

　データベースアクセス制御は、データベースに対するアクセスを適切に制限し、権限のある利用者のみが必要な操作を行えるようにする仕組みです。

2.2.1. 認証と認可

• 認証（Authentication）：ユーザーの身元確認
• 認可（Authorization）：ユーザーに対する権限の付与
• 多要素認証：パスワードだけでなく、生体認証やワンタイムパスワードなどを組み合わせる

2.2.2. アクセス制御モデル

• DAC（任意アクセス制御）：所有者がアクセス権を設定
• MAC（強制アクセス制御）：システム全体でのセキュリティポリシーに基づく制御
• RBAC（役割ベースアクセス制御）：ユーザーの役割や職務に応じた権限付与

graph TD
    subgraph DAC[任意アクセス制御 - DAC]
        A1[データ所有者] -->|権限を付与| B1[一般ユーザー]
        A1 -->|権限を管理| C1[リソース]
    end
    
    subgraph MAC[強制アクセス制御 - MAC]
        A2[セキュリティ管理者] -->|ポリシー適用| B2[全ユーザー/リソース]
        D2[機密レベル] -->|制約| B2
    end
    
    subgraph RBAC[役割ベースアクセス制御 - RBAC]
        A3[ユーザー] -->|割り当て| B3[ロール]
        B3 -->|付与| C3[権限]
        C3 -->|アクセス| D3[リソース]
    end
    
    style DAC fill:#f5f5f5,stroke:#333,stroke-width:1px
    style MAC fill:#f0f0f0,stroke:#333,stroke-width:1px
    style RBAC fill:#e5e5e5,stroke:#333,stroke-width:1px,color:#333
    
    classDef title font-weight:bold;
    class DAC,MAC,RBAC title
    
    classDef node fill:#fff,stroke:#333,stroke-width:1px,color:#333;
    class A1,B1,C1,A2,B2,D2,A3,B3,C3,D3 node

図2: アクセス制御モデルの比較図

2.2.3. 最小権限の原則

• 必要最小限の権限のみを付与
• 職務分掌：一人のユーザーに過度な権限を集中させない

2.2.4. 実装例

PostgreSQLでのRBACの実装例

-- ロールの作成
CREATE ROLE app_readonly;
CREATE ROLE app_readwrite;
CREATE ROLE app_admin;

-- 権限の付与
GRANT SELECT ON ALL TABLES IN SCHEMA public TO app_readonly;
GRANT SELECT, INSERT, UPDATE ON ALL TABLES IN SCHEMA public TO app_readwrite;
GRANT ALL PRIVILEGES ON ALL TABLES IN SCHEMA public TO app_admin;

-- ユーザーにロールを割り当て
GRANT app_readonly TO analyst_user;
GRANT app_readwrite TO developer_user;
GRANT app_admin TO admin_user;

2.3. データベースバックアップ

　データベースバックアップは、データの破壊や損失に備えて定期的にデータのコピーを作成・保存する仕組みです。セキュリティインシデント発生時の復旧手段として重要な役割を果たします。

2.3.1. バックアップの種類

• フルバックアップ：データベース全体のコピー
• 差分バックアップ：前回のフルバックアップ以降の変更のみ
• 増分バックアップ：前回のバックアップ以降の変更のみ
• ログバックアップ：トランザクションログのバックアップ

2.3.2. バックアップ戦略

• RPO（Recovery Point Objective）：許容できるデータ損失の最大時間
• RTO（Recovery Time Objective）：許容できるシステム停止の最大時間
• オフサイトバックアップ：災害対策としての遠隔地保管

バックアップ戦略の選択ガイド

要件	推奨バックアップ方式	バックアップ頻度	保持期間	RPO / RTO
大規模・重要DB	フル+増分+ログ	フル:週1回 増分:日次 ログ:時間単位	1年以上	RPO: 数分 RTO: 数時間
中規模DB	フル+差分	フル:週1回 差分:日次	3ヶ月以上	RPO: 24時間 RTO: 12時間
小規模・低更新DB	フルのみ	週1回または月1回	1ヶ月以上	RPO: 1週間 RTO: 24時間
クリティカルシステム	フル+ログ+レプリケーション	フル:日次 ログ:リアルタイム レプリケーション:リアルタイム	3年以上	RPO: ほぼゼロ RTO: 数分

表2: バックアップ戦略の選択ガイド

2.3.3. 実装例

MySQLのバックアップと復元の例

-- フルバックアップの作成
mysqldump --all-databases --single-transaction --master-data=2 > full_backup.sql

-- 差分バックアップの作成（バイナリログの位置を利用）
mysqlbinlog --start-position=123456 mysql-bin.000001 > diff_backup.sql

-- バックアップからの復元
mysql < full_backup.sql
mysql < diff_backup.sql

2.4. ログの取得

　データベースの活動を記録したログを取得・保存することで、不正アクセスの検出や、インシデント発生時の原因調査（フォレンジック）に役立てることができます。

2.4.1. 監査ログの種類

• 認証ログ：ログイン・ログアウトの記録
• DDLログ：データベース構造の変更記録
• DMLログ：データ操作の記録
• システムログ：データベースシステムの動作記録

2.4.2. ログ管理のポイント

• ログの改ざん防止（書き換え不可能な媒体への保存、デジタル署名）
• 適切な保存期間の設定（法令遵守、内部ポリシー）
• ログの定期的な分析と異常検知

flowchart LR
    A[ログ収集] --> B[集中保存]
    B --> C[前処理・正規化]
    C --> D[パターン分析]
    D --> E[異常検知]
    E --> F[アラート発報]
    F --> G[対応・調査]
    G --> H[改善措置]
    H --> A
    
    subgraph 収集元
    Z1[認証ログ]
    Z2[DDLログ]
    Z3[DMLログ]
    Z4[システムログ]
    end
    
    Z1 & Z2 & Z3 & Z4 --> A
    
    style A fill:#f9f9f9,stroke:#333
    style B fill:#f9f9f9,stroke:#333
    style C fill:#f9f9f9,stroke:#333
    style D fill:#f9f9f9,stroke:#333
    style E fill:#ffffcc,stroke:#333,stroke-width:2px
    style F fill:#ffdddd,stroke:#333,stroke-width:2px
    style G fill:#ddffdd,stroke:#333
    style H fill:#ddddff,stroke:#333
    
    classDef logSource fill:#f1f1f1,stroke-dasharray:5 5,stroke:#666;
    class Z1,Z2,Z3,Z4 logSource

図３: データベース監査ログの分析フロー

2.4.3. 実装例

SQL Serverの監査設定例

-- サーバーレベルの監査の作成
CREATE SERVER AUDIT SecurityAudit
TO FILE (FILEPATH = 'C:\AuditLogs\')
WITH (ON_FAILURE = CONTINUE);

-- データベースレベルの監査仕様の作成
CREATE DATABASE AUDIT SPECIFICATION UserAccessAudit
FOR SERVER AUDIT SecurityAudit
ADD (SELECT, INSERT, UPDATE, DELETE ON DATABASE::CustomerDB BY dbo)
WITH (STATE = ON);

-- 監査の有効化
ALTER SERVER AUDIT SecurityAudit WITH (STATE = ON);

2.5. ブロックチェーンにおけるセキュリティ関連技術

　ブロックチェーン技術は、分散型台帳として改ざん耐性の高いデータ管理を実現し、データベースセキュリティに新たなアプローチをもたらしています。

図４: ブロックチェーンの基本構造とセキュリティメカニズム

2.5.1. タイムスタンプ

• データの存在証明と時刻証明
• データの順序性の担保
• 非改ざん性の確保

2.5.2. ハッシュ関数

• データの一意性確認
• チェーン構造によるデータの整合性検証
• マークルツリーによる効率的な検証

2.5.3. ゼロ知識証明

• プライバシー保護と検証の両立
• データの内容を明かさずに真正性を証明
• スマートコントラクトでの応用

2.5.4. 実装例と具体的応用

ブロックチェーンを活用したデータの完全性検証

// 簡易的なブロックチェーンでのハッシュ計算と検証
import crypto from 'crypto';

// データのハッシュ値を計算
function calculateHash(data, previousHash, timestamp) {
  const dataString = previousHash + JSON.stringify(data) + timestamp.toString();
  return crypto.createHash('sha256').update(dataString).digest('hex');
}

// 新しいブロックの作成
function createBlock(data, previousBlock) {
  const timestamp = Date.now();
  const previousHash = previousBlock ? previousBlock.hash : '0';
  const hash = calculateHash(data, previousHash, timestamp);
  
  return {
    data,
    previousHash,
    timestamp,
    hash
  };
}

// ブロックチェーンの検証
function validateChain(blockchain) {
  for (let i = 1; i < blockchain.length; i++) {
    const currentBlock = blockchain[i];
    const previousBlock = blockchain[i-1];
    
    // ハッシュの検証
    if (currentBlock.previousHash !== previousBlock.hash) {
      return {valid: false, message: 'ハッシュチェーンが破損しています'};
    }
    
    // データ整合性の検証
    const recalculatedHash = calculateHash(
      currentBlock.data, 
      currentBlock.previousHash, 
      currentBlock.timestamp
    );
    
    if (recalculatedHash !== currentBlock.hash) {
      return {valid: false, message: 'データが改ざんされています'};
    }
  }
  
  return {valid: true, message: 'ブロックチェーンは正常です'};
}

3. 応用例

3.1. 金融機関のデータベースセキュリティ

　金融機関では、顧客の口座情報や取引履歴などの機密性の高いデータを扱うため、特に厳格なデータベースセキュリティ対策が実施されています。具体的には、以下のような対策が一般的です。

• 重要データの暗号化（カード番号、口座番号など）
• 多層防御による不正アクセス防止
• リアルタイム監視と異常検知
• 厳格なアクセス制御と特権ID管理
• ログの長期保存と定期的な監査

実装例: 金融システムにおけるセキュアなトランザクション処理

-- 口座間送金処理の安全な実装例（PostgreSQL）
BEGIN TRANSACTION ISOLATION LEVEL SERIALIZABLE;

-- 送金元の残高確認と更新（楽観的ロック）
UPDATE accounts 
SET balance = balance - 10000, 
    version = version + 1,
    last_updated = NOW()
WHERE account_id = 'A12345' 
  AND balance >= 10000
  AND version = 5
  AND account_status = 'ACTIVE';

-- 更新された行数をチェック
GET DIAGNOSTICS rows_affected = ROW_COUNT;
IF rows_affected = 0 THEN
    ROLLBACK;
    RAISE EXCEPTION '送金元の残高不足または状態が不正です';
END IF;

-- 送金先の更新
UPDATE accounts 
SET balance = balance + 10000,
    version = version + 1,
    last_updated = NOW()
WHERE account_id = 'B67890'
  AND account_status = 'ACTIVE';

-- 監査ログの記録
INSERT INTO transaction_log (
    transaction_id, from_account, to_account, 
    amount, transaction_time, status, ip_address
) VALUES (
    gen_random_uuid(), 'A12345', 'B67890', 
    10000, NOW(), 'COMPLETED', '192.168.1.100'
);

COMMIT;

3.2. 医療情報システムにおけるデータベースセキュリティ

　医療機関では、患者の診療情報など極めて機密性の高い個人情報を管理しています。医療情報システムのデータベースセキュリティでは、以下のような点が重視されます。

• 患者情報の匿名化と暗号化
• 利用者認証と権限管理の厳格化
• アクセスログの取得と監査
• バックアップと災害復旧計画
• 法令遵守（個人情報保護法、医療情報システムのガイドライン）

実装例: 医療データのアクセス制御

-- Oracle Database での医療記録へのアクセス制御
-- ロールの作成
CREATE ROLE doctor_role;
CREATE ROLE nurse_role;
CREATE ROLE admin_role;

-- 権限の付与
GRANT SELECT ON patient_basic_info TO doctor_role, nurse_role;
GRANT SELECT, UPDATE ON medical_records TO doctor_role;
GRANT SELECT ON medical_records TO nurse_role;
GRANT SELECT ON restricted_patient_info TO doctor_role;

-- 仮想プライベートデータベース（VPD）ポリシーの適用
BEGIN
  DBMS_RLS.ADD_POLICY (
    object_schema   => 'hospital',
    object_name     => 'medical_records',
    policy_name     => 'records_access_policy',
    function_schema => 'hospital',
    policy_function => 'get_records_predicate',
    statement_types => 'SELECT, UPDATE',
    update_check    => TRUE
  );
END;

3.3. ブロックチェーン技術のデータベース応用

　従来の中央集権型データベースとは異なるアプローチとして、ブロックチェーン技術を活用したデータ管理が注目されています。

• サプライチェーン管理：製品の追跡と真正性の証明
• 電子投票システム：改ざん困難な投票記録
• 分散型個人情報管理：自己主権型アイデンティティ
• スマートコントラクトによる自動実行と監査証跡

実装例: イーサリアムブロックチェーンでのスマートコントラクト

// 製品トレーサビリティのスマートコントラクト
pragma solidity ^0.8.0;

contract ProductTraceability {
    // 製品情報の構造体
    struct Product {
        string productId;
        string manufacturer;
        uint256 manufactureDate;
        string location;
        string[] transactionHistory;
    }
    
    // 製品IDから製品情報へのマッピング
    mapping(string => Product) public products;
    
    // 製品登録イベント
    event ProductRegistered(string productId, string manufacturer, uint256 timestamp);
    // 製品移動イベント
    event ProductMoved(string productId, string fromLocation, string toLocation, uint256 timestamp);
    
    // 製品の登録
    function registerProduct(
        string memory _productId,
        string memory _manufacturer,
        string memory _location
    ) public {
        require(bytes(products[_productId].productId).length == 0, "Product already exists");
        
        string[] memory history = new string[](1);
        history[0] = string(abi.encodePacked("Manufactured at ", _location));
        
        products[_productId] = Product({
            productId: _productId,
            manufacturer: _manufacturer,
            manufactureDate: block.timestamp,
            location: _location,
            transactionHistory: history
        });
        
        emit ProductRegistered(_productId, _manufacturer, block.timestamp);
    }
    
    // 製品の移動記録
    function moveProduct(
        string memory _productId,
        string memory _toLocation
    ) public {
        require(bytes(products[_productId].productId).length > 0, "Product does not exist");
        
        string memory fromLocation = products[_productId].location;
        
        // 履歴に追加
        string memory newTransaction = string(abi.encodePacked(
            "Moved from ", 
            fromLocation, 
            " to ", 
            _toLocation, 
            " at timestamp ", 
            uint2str(block.timestamp)
        ));
        
        products[_productId].transactionHistory.push(newTransaction);
        products[_productId].location = _toLocation;
        
        emit ProductMoved(_productId, fromLocation, _toLocation, block.timestamp);
    }
    
    // 製品情報の取得
    function getProduct(string memory _productId) public view returns (
        string memory manufacturer,
        uint256 manufactureDate,
        string memory location,
        uint256 historyCount
    ) {
        Product storage product = products[_productId];
        require(bytes(product.productId).length > 0, "Product does not exist");
        
        return (
            product.manufacturer,
            product.manufactureDate,
            product.location,
            product.transactionHistory.length
        );
    }
    
    // uint を string に変換するヘルパー関数
    function uint2str(uint _i) internal pure returns (string memory) {
        if (_i == 0) {
            return "0";
        }
        uint j = _i;
        uint len;
        while (j != 0) {
            len++;
            j /= 10;
        }
        bytes memory bstr = new bytes(len);
        uint k = len;
        while (_i != 0) {
            k = k-1;
            uint8 temp = (48 + uint8(_i - _i / 10 * 10));
            bytes1 b1 = bytes1(temp);
            bstr[k] = b1;
            _i /= 10;
        }
        return string(bstr);
    }
}

4. 例題

例題1

　あるECサイトで顧客の個人情報（氏名、住所、クレジットカード番号）を保管するデータベースに対して、適切なセキュリティ対策を検討します。このケースでクレジットカード情報を保護するために最も効果的なデータベース暗号化の方式はどれか。

1. データベースファイル全体の暗号化
2. クレジットカード番号のカラムのみの暗号化
3. バックアップファイルの暗号化
4. 通信経路の暗号化

例題2

　データベースへのアクセス制御に関する以下の記述のうち、誤っているものはどれか。

1. RBACでは、ユーザーに直接権限を付与するのではなく、ロールに権限を付与し、ユーザーにロールを割り当てる。
2. 最小権限の原則とは、ユーザーに必要最小限の権限のみを付与することで、被害の拡大を防ぐ考え方である。
3. DAC（任意アクセス制御）では、システム管理者のみがアクセス権を設定できる。
4. 多要素認証とは、複数の認証要素（知識、所持、生体情報など）を組み合わせて認証する方式である。

例題3

　データベースバックアップに関する以下の組み合わせのうち、最も適切なものはどれか。

1. RPO（Recovery Point Objective）- システムを復旧させるまでの目標時間
2. フルバックアップ – 前回のバックアップ以降の変更のみを保存
3. オフサイトバックアップ – 同一建物内の別サーバーへのバックアップ
4. トランザクションログバックアップ – 障害発生時点までのデータ復旧に必要

例題4

　ブロックチェーンにおけるセキュリティ関連技術に関する以下の記述のうち、正しいものはどれか。

1. ゼロ知識証明とは、データの内容を相手に全て開示することで真正性を証明する技術である。
2. タイムスタンプは、データが特定の時点で存在したことを証明するための技術である。
3. ハッシュ関数は、入力データから元のデータを容易に復元できることが特徴である。
4. マークルツリーは、ブロックチェーンにおいて各トランザクションを個別に暗号化するための技術である。

例題5

　ある企業の人事データベースセキュリティを強化するために、以下の要件を実現する必要があります。最も適切な対策の組み合わせを選択してください。

【要件】

• 給与情報は人事部と財務部のみがアクセス可能
• 全ての個人情報の変更履歴を追跡可能
• 人事記録の改ざんを防止
• 内部不正者による大量データ取得を検知

1. 透過的データ暗号化、監査ログの取得、ロールベースアクセス制御、異常検知システム
2. カラム暗号化、ロールベースアクセス制御、監査ログの取得、アクセス頻度監視
3. アプリケーション暗号化、任意アクセス制御、定期バックアップ、DDoS対策
4. ファイル暗号化、強制アクセス制御、レプリケーション、アンチウイルス

5. まとめ

　データベースセキュリティの実装技術は、以下の要素から構成されます：

1. データベース暗号化：重要データの機密性を保護し、漏洩時の被害を最小化する。TDE、カラム暗号化、アプリケーション暗号化などの方式があり、保護すべきデータの特性に応じて選択する。
2. データベースアクセス制御：正当な利用者のみにアクセスを許可し、権限の範囲内での操作を保証する。DAC、MAC、RBACなどのモデルがあり、最小権限の原則に基づいて実装する。
3. データベースバックアップ：データ損失に備え、定期的なバックアップと復旧計画を整備する。RPOとRTOを考慮したバックアップ戦略を策定し、オフサイトバックアップを含めた多層的な保護を行う。
4. ログの取得：データベース活動の記録を取得・保存し、不正の検知と原因調査に活用する。認証ログ、DDLログ、DMLログ、システムログなどを取得し、改ざん防止策を講じたうえで定期的な分析を行う。
5. ブロックチェーン技術：タイムスタンプ、ハッシュ、ゼロ知識証明などの技術を活用し、データの完全性と非改ざん性を確保する。分散型台帳としての特性を活かし、高い透明性と追跡可能性を実現する。

　データベースセキュリティは単一の対策ではなく、多層的なアプローチが必要です。技術的対策だけでなく、運用ポリシーの整備や定期的な監査、教育訓練なども含めた総合的なセキュリティ対策が重要です。また、新たな脅威や攻撃手法に対応するため、セキュリティ対策の継続的な見直しと改善が不可欠です。

　最近では、クラウドデータベースの普及に伴い、従来のオンプレミス環境とは異なるセキュリティ対策も重要になっています。また、AI技術を活用した異常検知や、ゼロトラスト・アーキテクチャに基づくセキュリティ設計など、最新のアプローチも取り入れながら、常に進化するリスクに対応していくことが求められています。