第9章 データベースのセキュリティ

9.1 なぜDBが最終目的地なのか

報道される情報漏えい事故——「顧客情報◯十万件が流出」——の多くは、おおよそ次のような攻撃チェーンをたどっています。

① フィッシングメール ──→ ② 社員の端末に侵入
                                │(端末に保存されたパスワードや接続情報を収集)
                                ▼
                        ③ 社内サーバーへ横展開
                                │(管理者権限の奪取)
                                ▼
                        ④ データベースに到達 ──→ ⑤ 全件を抜き取り(漏えい)

①〜③はすべて準備です。攻撃者が本当に欲しいもの——売れる個人情報、脅迫に使える機密、暗号化して身代金を要求できる基幹データ——は、④のデータベースの中にあります。第1章で「DBは会社で一番狙われる場所」と述べた理由がこれです。

この構造から、重要な結論が2つ導けます。

• DBの防御は多層防御の「最後の砦」 — メール対策や端末防御(入門コースで学んだ領域)が破られたあとでも被害を最小化できるのは、DB自身の防御だけです。
• 「社内からのアクセスだから安全」は成立しない — 攻撃チェーンの④は社内ネットワークの内側から行われます。境界の内側でも認証・権限・記録を要求する設計が必要です。

9.2 SQLインジェクション — 攻める側の視点から守る

第8章でプレースホルダを「絶対条件」と学びました。ここではなぜそれが効くのかを、攻撃の原理から理解します。ログイン処理を文字列連結で書いてしまった脆弱なコードを見てください。

# 脆弱なログイン処理(教材用。絶対に真似しないこと)
sql = (f"SELECT * FROM users "
       f"WHERE name = '{name}' AND password = '{password}'")
cur.execute(sql)

攻撃者はパスワード欄に、古典的な文字列 ' OR '1'='1 を入力します。すると組み立てられるSQLはこうなります。

SELECT * FROM users
WHERE name = 'admin' AND password = '' OR '1'='1'

OR '1'='1' は常に真なので、パスワードを知らなくても全行がマッチしてログインが成立します。入力した文字列がデータではなく「SQLの構文」として解釈されてしまった——これがSQLインジェクションの本質です。同じ原理で、UNION SELECT による他テーブルの抜き取りや、; DROP TABLE のような破壊も狙われます。

対策は3層で重ねる

SQLインジェクション対策は1つではなく、層で考えます。

第2層・第3層は「第1層をやり忘れた箇所があっても被害を防ぐ」ための保険であって、プレースホルダの代わりにはなりません。逆に、プレースホルダを徹底していても、入力検証には「不正なデータを業務ロジックに入れない」という独自の価値があります。

9.3 アカウントと権限管理

侵入されたとき・アカウントが乗っ取られたときの被害を決めるのは、そのアカウントが何をできたかです。ここで効くのが、セキュリティの基本原則である最小権限の原則(必要最小限の権限だけを与える)です。

考えてみてください。Webアプリが日常業務でDBに対して行うのは、SELECT・INSERT・UPDATE・(場合により)DELETEだけです。テーブルを削除する DROP も、他人に権限を与える GRANT も、アプリの通常動作には不要です。それなのにアプリ用アカウントに管理者権限を与えていると、SQLインジェクションが1か所あっただけで「全テーブル削除」まで許してしまいます。

SQLiteは1ファイル=1DBでアカウント機能を持たないため、ここはMySQL風の例で考え方を示します(PostgreSQLなどでもほぼ同じです)。

-- アプリ用アカウントを作り、必要な操作だけ許可する
CREATE USER 'app'@'10.0.1.%' IDENTIFIED BY '(強いパスワード)';
GRANT SELECT, INSERT, UPDATE, DELETE ON company.* TO 'app'@'10.0.1.%';

-- 集計・閲覧しかしない帳票ツールには読み取り専用アカウント
CREATE USER 'report'@'10.0.2.%' IDENTIFIED BY '(強いパスワード)';
GRANT SELECT ON company.* TO 'report'@'10.0.2.%';

-- 与えすぎた権限は取り消す
REVOKE DELETE ON company.* FROM 'app'@'10.0.1.%';

ポイントは3つです。

• 用途ごとにアカウントを分ける — アプリ用・帳票用・管理者用。帳票ツールが読み取り専用アカウントで動いていれば、そのツールが乗っ取られてもデータは書き換えられません。
• 接続元も絞る — 上の例の 'app'@'10.0.1.%' は「この IPアドレス帯からしか接続できない」という指定です。パスワードが漏れても、外部からは接続できません。
• 共有アカウントを禁止する — 「部署のみんなでadmin/共通パスワード」は、①漏えい時に全員のパスワード変更が必要、②監査ログを見ても誰の操作か特定できない、の二重で最悪です。1人(1アプリ)に1アカウントが原則です。

9.4 暗号化 — 保存時と通信時

権限管理を破られた場合や、物理的にディスク・ファイルを盗まれた場合に備えるのが暗号化です。場面ごとに整理します。

そして最重要の例外がパスワードです。ユーザーのパスワードは「暗号化」して保存してはいけません。暗号化は復号できてしまうからです。正解は、復元できない一方向の変換であるソルト付きハッシュ(Python × セキュリティ入門コースの第12章で学んだ、ユーザーごとに異なるソルトを付けてハッシュ化する方式)で保存し、ログイン時は「入力を同じ方式でハッシュ化して比較」します。DBが丸ごと漏えいしても、元のパスワードがすぐには判明しない状態を保つのが目的です。

9.5 監査ログとバックアップ

監査ログ — 「誰が・いつ・何をしたか」

防御をすり抜けられたときに、被害範囲の特定と原因究明を可能にするのが監査ログです。最低限「誰が(アカウント)・いつ・どこから(接続元)・何をしたか(実行SQLや対象テーブル)」を記録し、DB管理者自身も改ざんできない場所(別サーバーのログ基盤など)へ転送します。9.3節の「共有アカウント禁止」はここに直結します——アカウントが個人単位でなければ、ログがあっても犯人をたどれません。

バックアップ — リストア訓練までがバックアップ

ランサムウェア(データを暗号化して身代金を要求する攻撃)への最後の対抗手段はバックアップです。定石は3-2-1ルール——コピーを3つ持ち、2種類の媒体に分け、1つはオフサイト(遠隔地)に置く。さらにランサムウェア対策としては、ネットワークから切り離されたオフライン保管(あるいは書き換え不可のストレージ)を1つ含めることが重要です。攻撃者はバックアップサーバーも探して暗号化しにきます——オンラインで常時つながっているバックアップは「4本目の人質」になりかねません。

まとめ

• 攻撃チェーン(フィッシング→端末→サーバー→DB)の最終目的地はデータベース。DBの防御は多層防御の最後の砦であり、「社内からだから安全」は成立しない
• SQLインジェクションは入力が「SQLの構文」として解釈されることで成立する。対策はプレースホルダ(根本)+入力検証+WAFの3層。ORMでも生SQLの文字列連結は同罪
• 最小権限の原則: アプリ用アカウントにDROPやGRANTは不要。用途ごとにアカウントを分け、接続元を絞り、共有アカウントは禁止
• 暗号化は通信時(TLS)・保存時・カラム単位の3場面。ただしパスワードは暗号化ではなくソルト付きハッシュで保存する
• 監査ログは「誰が・いつ・何をしたか」を改ざんできない場所へ。バックアップは3-2-1ルール+オフライン保管+リストア訓練までがセット
• 本番データを開発環境に持ち出さない。必要ならマスキングかダミーデータ生成で代替する

練習問題

import sqlite3

DB_PASSWORD = "P@ssw0rd123"   # 管理者アカウントのパスワード

def login(name, password):
    conn = sqlite3.connect("app.db")
    cur = conn.cursor()
    cur.execute(f"SELECT * FROM users WHERE name = '{name}' "
                f"AND password = '{password}'")
    return cur.fetchone() is not None

cur.execute(
    "SELECT * FROM users WHERE name = ? AND password_hash = ?",
    (name, hash_password(password, salt)),
)