6.3データベースの信頼性とセキュリティ

データベースは企業活動の中核データを預かる以上、「壊れても復旧できる」信頼性と「正当な者だけがアクセスできる」セキュリティの両方を設計に組み込む必要があります。DBAには、許容できるデータ損失量（RPO）や復旧時間（RTO）といった事業要件からバックアップ方式・冗長化構成を逆算して設計する能力、そして最小権限の原則に基づきアクセス制御・暗号化・監査を組み合わせて設計する能力が求められます。この節ではその設計判断の型を学びます。

6.3.1バックアップとリカバリ

• フルバックアップ＝ある時点のデータベース全体を丸ごと複製する方式。復元は単純だが、取得に時間・容量を要する。差分バックアップ＝直前のフルバックアップ以降に変更された部分をすべて複製する方式。復元は「フル＋最新の差分」の2世代で済むが、差分のサイズは日を追うごとに増える。増分バックアップ＝直前のバックアップ（フルまたは増分）以降に変更された部分のみを複製する方式。各回のバックアップは小さく高速だが、復元には「フル＋全ての増分を順番に」適用する必要があり復元時間が長くなりやすい。
• ログ先書き（WAL）と組み合わせたバックアップ運用では、フルバックアップに加えてトランザクションログ（アーカイブログ）を継続的に保存しておくことで、障害直前の任意の時点まで復元するポイントインタイムリカバリが可能になる。バックアップ方式の選定は、許容できる復旧時間（RTO：Recovery Time Objective）と許容できるデータ損失量（RPO：Recovery Point Objective）という事業要件から逆算する。

6.3.2RAIDとホットスタンバイ

• RAID＝複数のディスクを組み合わせて信頼性・性能を高める技術。RAID1（ミラーリング）は同じデータを2台に複製し1台の故障まで耐えるが実効容量は半分。RAID5はデータとパリティ（誤り訂正情報）を複数ディスクに分散配置し、1台の故障までデータを復元できる（実効容量は台数-1台分）。RAID6はパリティを二重化し2台までの同時故障に耐えられる。RAIDは信頼性向上の技術であり、バックアップの代替にはならない（論理的な誤削除やデータ破損はRAIDでは救えない）。
• ホットスタンバイ＝待機系サーバを常に稼働状態（データ同期済み）にしておき、現用系に障害が起きたら即座に（自動または手動で）切り替える構成。待機系を起動していないコールドスタンバイより切り替え時間（RTO）が短い。データベースでは現用系の変更をリアルタイムに待機系へ反映する仕組み（レプリケーションの応用）が前提となる。

6.3.3アクセス制御・暗号化・監査ログ

• GRANT/REVOKE＝SQLのDCL（データ制御言語）で権限を付与・剥奪する文。ユーザーやロールに対しテーブル単位・列単位・操作単位（SELECT/INSERT/UPDATE/DELETE等）で必要最小限の権限のみを与える最小権限の原則が基本方針。開発者に本番DBの全権限を与えるのではなく、業務に必要な操作だけを許可するロールベースアクセス制御（RBAC）が実務では一般的。
• TDE（Transparent Data Encryption：透過的データ暗号化）＝データファイルやバックアップファイルをディスク上で暗号化し、盗難・不正コピーされても内容を読み取れなくする仕組み。アプリケーションからは透過的（アプリ側の変更不要）に動作する点が特徴で、通信経路の暗号化（TLS）とは保護対象が異なる（TDEは保存データ＝at rest、TLSは通信中データ＝in transit）。監査ログ＝誰が・いつ・何のデータに・どんな操作をしたかを記録し、不正アクセスの検知や事後追跡、コンプライアンス対応に用いる。
• SQLインジェクション＝アプリケーションがユーザー入力をそのままSQL文に連結して実行することで、攻撃者が意図しないSQL（例：' OR '1'='1のような条件常真化や、追加のDROP文等）を注入し、認証回避・不正なデータ取得・改ざんを引き起こす攻撃。根本的な対策はプレースホルダ（バインド機構）を使ったプレースホルダ化（パラメータ化クエリ）で、入力値をSQL文の構文要素としてではなくデータとしてバインドすることで注入を防ぐ。入力値のエスケープ処理や最小権限のDB接続アカウントは補助的な多層防御になる。

ある金融系サービスのDBAが、新規の顧客情報データベースの信頼性・セキュリティ設計を任されたとします。まず事業要件として「障害発生時、データ損失は5分以内（RPO 5分）、復旧は30分以内（RTO 30分）」という厳しい水準が求められています。単純な毎日1回のフルバックアップだけでは障害直前までの変更が失われRPOを満たせないため、フルバックアップ＋継続的なトランザクションログ保存によるポイントインタイムリカバリを採用し、直前の任意の時点まで復元できる体制を作ります。さらにRTO 30分という短い目標に対しては、バックアップからの復元では到底間に合わないため、ホットスタンバイ構成（待機系を常時同期させ即座に切替可能にする）を導入し、ディスク故障そのものへの耐性としてはRAID5（1台の故障までデータを保持）を採用します——ただしRAIDは論理的なデータ破損やヒューマンエラーには無力なので、バックアップ体制を廃止する理由にはならないと判断します。アクセス制御では、開発者が本番DBに直接SELECT文を投げてトラブルシューティングする文化があったため、GRANTで開発者ロールには必要な表のSELECTのみを許可し、更新権限は最小限の運用アカウントに限定する最小権限の原則を徹底します。顧客の氏名・口座情報等の機密データについては、万が一バックアップメディアが盗難・紛失しても内容を読み取れないようTDEでデータファイル・バックアップファイルを暗号化し、加えて誰がいつ顧客データにアクセスしたかを監査ログで記録し、金融規制対応の証跡とします。最後に、顧客向けWebアプリのログイン画面で入力値をSQL文に文字列連結していたことが判明したため、SQLインジェクションのリスクがあると判断し、プレースホルダを使ったパラメータ化クエリへの改修を最優先で指示します——エスケープ処理だけでは新たな入力パターンへの対応漏れが生じやすく、根本対策として不十分だからです。このように、事業要件（RPO/RTO）からバックアップ・冗長化方式を逆算し、最小権限・暗号化・監査・パラメータ化クエリを多層で組み合わせるのが実務の信頼性・セキュリティ設計です。

6.3.4この節のまとめ

• バックアップ方式は事業要件のRPO/RTOから逆算。差分は復元2世代、増分は復元に全増分を順次適用
• RAIDはディスク故障耐性でバックアップの代替にならない。ホットスタンバイは即座切替でRTO短縮
• 最小権限の原則でGRANT設計、TDEで保存データを暗号化、SQLインジェクションの根本対策はパラメータ化クエリ