セキュリティレビューで赤点を取るDB設計あるある

システム開発の重要なプロセスの一つ、「セキュリティレビュー」。特に、アプリケーションの心臓部とも言えるデータベース（DB）設計に対するレビューは、顧客情報やビジネスデータといった重要な情報資産をいかに安全に守るかという観点から、非常に厳しい目で行われます。

開発者としては、機能要件を満たすことに集中するあまり、セキュリティの観点が後回しになってしまう…なんてこともあるかもしれません。そして、いざレビューを受けてみると、「これはダメですね」「ここ、重大なリスクがありますよ」と、手厳しい指摘、いわゆる「赤点」をもらってしまう…。そんな経験、あるいはヒヤリとした経験がある方もいるのではないでしょうか？

この記事では、セキュリティレビューにおいて、「またこのパターンか…」と思われがちな、DB設計における典型的な問題点、いわゆる「あるある」をピックアップし、なぜそれがセキュリティ上「赤点」なのか、どのようなリスクを孕んでいるのか、そしてどうすればレビューをクリアできる堅牢な設計ができるのかを解説していきます。

なぜDB設計がセキュリティレビューで重要視されるのか？

そもそも、なぜデータベース設計がこれほどまでにセキュリティレビューで重要視されるのでしょうか？

• 機密情報の「最後の砦」だから: データベースは、顧客の個人情報、クレジットカード情報、パスワード、会社の財務データ、営業秘密など、漏洩したり改ざんされたりした場合の影響が計り知れない、極めて機密性の高い情報が集中する場所です。ここが破られれば、被害は甚大になります。
• 攻撃者の最終目的地だから: Webアプリケーションの脆弱性（SQLインジェクションなど）を突いた攻撃や、サーバーへの不正侵入など、多くのサイバー攻撃の最終的な目的は、データベースに格納された価値ある情報を盗み出すこと、あるいは破壊することです。
• 後工程での修正コストが大きいから: 設計段階でのセキュリティ考慮漏れは、開発が進んだ後工程で発覚すると、修正に多大な時間とコストがかかります。最悪の場合、根本的なアーキテクチャ変更が必要になることも。そのため、設計段階でのレビューが極めて重要になるのです。

これは赤点！ セキュリティレビューで指摘されるDB設計あるある

それでは、具体的にどのようなDB設計がセキュリティレビューで「赤点」の烙印を押されてしまうのでしょうか？ よくある「あるある」な指摘ポイントを見ていきましょう。

あるある①：パスワードや機密情報の「平文」保存

これは、最も基本的でありながら、最も致命的な「あるある」です。 ユーザーのパスワード、クレジットカード番号、マイナンバー、APIキー、秘密の質問の答えといった機密情報を、何の加工もせずにそのまま（平文で）データベースのテーブルに保存してしまっているケース。

• なぜ赤点か？: 万が一、データベースサーバーへの不正アクセスや、バックアップデータの漏洩が発生した場合、これらの機密情報が攻撃者に丸見えになってしまいます。パスワードが漏洩すれば不正ログインされ放題、クレジットカード情報が漏洩すれば不正利用され放題です。
• どうすべきか？:
  • パスワード: 絶対に平文で保存してはいけません。必ずハッシュ化（元に戻せない形に変換）し、さらにソルト（ユーザーごとに異なるランダムな文字列）を付加して、レインボーテーブル攻撃への耐性も高める必要があります。bcryptやArgon2といった実績のあるハッシュアルゴリズムを使用しましょう。
  • その他の機密情報: 必要性に応じて、データベースレベル、あるいはアプリケーションレベルで適切に暗号化して保存します。暗号化キーの管理も非常に重要です。

あるある②：なんでもかんでも「とりあえずVARCHAR(255)」

電話番号、郵便番号、性別コード、ステータスコードなど、本来は桁数や形式、取りうる値がある程度決まっているはずのデータに対して、深く考えずに汎用的な可変長文字列型（VARCHAR）を、しかも最大長で（例: VARCHAR(255)）設定してしまうケース。

• なぜ赤点か？:
  • 不正なデータの混入: 本来数値しか入らないはずのフィールドに文字列が入ったり、想定外の長い文字列が入力されたりする可能性があります。
  • 入力値検証の甘さ: データベースレベルでの型チェックや桁数チェックが効かなくなるため、アプリケーション側でのバリデーションがより重要になりますが、そこにも漏れがあると不正データが登録されてしまいます。
  • SQLインジェクションのリスク増: 不適切なデータ型は、SQLインジェクション攻撃の足がかりを与えてしまう可能性もあります。
• どうすべきか？:
  • データの性質に合わせて、最も適切なデータ型（INTEGER, NUMERIC, DATE, BOOLEAN, CHAR(桁数) など）を選択します。
  • 桁数や文字数を可能な限り具体的に制限します。
  • 必要であれば、CHECK制約などを使って、取りうる値の範囲をデータベースレベルで制限することも有効です。

あるある③：推測可能なIDを主キーに：「サロゲートキー？何それ？」

ユーザーIDにメールアドレスやログインIDを、社員IDに社員番号を、注文IDに日付連番を… といったように、外部から推測可能だったり、それ自体が何らかの意味を持つ値を、そのままテーブルの主キー（Primary Key）として使用してしまうケース。

• なぜ赤点か？: これらのIDが、WebアプリケーションのURLパラメータ（例: /users/user@example.com/profile や /orders/20250415001）などに含まれてしまうと、攻撃者はIDを推測・変更することで、他のユーザーの情報や注文情報などを不正に閲覧・操作できてしまう可能性があります（これはIDOR: Insecure Direct Object Referencesと呼ばれる深刻な脆弱性です）。
• どうすべきか？:
  • テーブルの主キーには、それ自体に意味を持たない、連番（シーケンス）やランダムな文字列（UUID/GUIDなど）といった代理キー（サロゲートキー）を使用することを強く推奨します。
  • 外部に公開する必要があるIDは別途用意し、内部的な主キーとは分離します。

あるある④：個人情報だだ漏れ？ 過剰なカラム設計

「将来的に必要になるかもしれないから」「とりあえず入れておこう」といった理由で、現時点の機能要件では全く使わない個人情報や、機密性の高い情報を、念のためにカラムとして定義してしまうケース。あるいは、正規化が不十分で、関連性の低い情報が一つのテーブルに詰め込まれているケース。

• なぜ赤点か？: その機能を利用するアプリケーションやユーザーには、本来必要のない情報にまでアクセス権を与えてしまうことになります。もしそのアプリケーションに脆弱性があったり、アカウントが侵害されたりした場合、漏洩する情報の範囲が不必要に拡大してしまいます。個人情報保護の観点からも、必要最小限の原則はデータ項目レベルでも適用されるべきです。
• どうすべきか？:
  • そのテーブル、そのカラムが、本当にその機能・目的にとって必要不可欠な情報なのかを厳密に検討します。
  • 必要になった時点でカラムを追加する、あるいは関連性の高い情報ごとに適切にテーブルを分割（正規化）することを検討します。

あるある⑤：「誰がやったか分からない」ログ設計の不備

ユーザー情報、注文情報、商品情報など、重要なデータが変更された際に、「誰が」「いつ」「どのレコードに対して」その操作（作成、更新、削除）を行ったのかを追跡するための情報が、テーブル設計に含まれていないケース。

• なぜ赤点か？:
  • 監査証跡（Audit Trail）が残せない: 不正なデータ操作や、意図しないデータの変更が発生した場合に、原因を究明したり、責任の所在を特定したりすることが極めて困難になります。
  • 内部統制やコンプライアンス要件を満たせない: 多くの規制やガイドラインでは、重要なデータ操作に関する監査証跡の記録が求められます。
• どうすべきか？:
  • 重要なデータを扱うテーブルには、作成者ID、作成日時、最終更新者ID、最終更新日時といったカラムを設け、アプリケーション側でこれらの情報を記録するように設計します。
  • より厳密な監査が必要な場合は、変更履歴を別のテーブルに記録する（履歴テーブル）、あるいはデータベースのトリガーや監査ログ機能を利用することも検討します。

あるある⑥：SQLインジェクション脆弱性の温床？

これは直接的なテーブル設計の問題ではありませんが、関連する「あるある」です。例えば、EAV（Entity-Attribute-Value）モデルのように極端に非正規化された設計や、ユーザー入力をそのままSQL文の一部として組み立てることを前提としたような複雑なストアドプロシージャなどは、結果的にアプリケーション側でのSQLインジェクション対策（プレペアドステートメントの利用など）を困難にし、脆弱性を生み出す原因となることがあります。

• どうすべきか？: アプリケーション側で安全なデータベースアクセス（プレペアドステートメントやO/Rマッパーの適切な利用）を前提とした、可能な限りシンプルで正規化されたテーブル設計を心がけるべきです。

あるある⑦：バックアップ・リストア考慮漏れ

システムの可用性や耐障害性に関わる設計の考慮漏れです。

• バックアップ時間の現実性: 画像や動画などの大容量バイナリデータ（BLOB/CLOB）を無計画にデータベース内に格納すると、データベース全体のサイズが肥大化し、バックアップやリストアに非現実的なほど長い時間がかかってしまうことがあります。
• リストアの困難さ: テーブル間に複雑すぎる外部キー制約や循環参照などが存在すると、障害発生時にデータを正しい順序でリストアすることが非常に困難になる場合があります。
• どうすべきか？: 大容量データはファイルストレージに格納し、DBにはそのパス情報のみを保存するなどの検討が必要です。また、設計段階で障害発生時のリカバリシナリオを想定し、リストアが可能な設計になっているかを確認することも重要です。

「赤点」回避のために：設計段階からセキュリティを意識する

これらの「赤点あるある」を回避し、セキュリティレビューを自信を持ってクリアするためには、開発プロセスの初期段階、つまりDB設計の段階からセキュリティを意識することが不可欠です。

セキュリティ・バイ・デザイン（Security by Design）

機能要件を満たすだけでなく、設計を始める最初の段階から、潜在的なセキュリティ脅威（情報漏洩、不正アクセス、データ改ざんなど）を洗い出し、それらに対する防御策を設計に組み込んでいくという考え方です。セキュリティを「後付け」で対策しようとすると、手遅れになったり、多大なコストがかかったりします。

最小権限の原則（データアクセス権限設計）

テーブル設計だけでなく、そのデータベースにアクセスするアプリケーションやユーザーアカウントの権限も、必要最小限に絞ることを前提として設計します。アプリケーションAはテーブルXにSELECTとINSERTだけできれば良い、ユーザーBはテーブルYの特定のカラムだけSELECTできれば良い、といった具体的なアクセス要件を考慮します。

適切なデータ型と制約の活用

前述の通り、データの特性に合わせた最適なデータ型を選択し、桁数制限やCHECK制約などを積極的に活用して、データベース自身が持つデータ整合性維持機能を最大限に利用します。

機密データの暗号化・ハッシュ化

どのデータが機密情報にあたるのかを明確にし（データ分類）、その機密レベルに応じて、保存時に適切な暗号化やハッシュ化を施す設計を行います。パスワードはハッシュ化＋ソルト、これは絶対です。

監査証跡の設計

誰が、いつ、どのデータに対して重要な操作を行ったのかを追跡できるように、作成・更新者情報や日時を記録するカラムを標準的に設けることを設計ルールとします。

設計レビューの徹底

作成したER図やテーブル定義書、設定した制約などについて、必ずチーム内で、できればデータベースやセキュリティに詳しいメンバーを交えてレビューを行います。複数の目でチェックすることで、自分だけでは気づかなかった問題点や考慮漏れを発見できます。

セキュリティレビューは「敵」ではない

最後に、セキュリティレビューに対する心構えについてです。レビューで厳しい指摘を受けると、落ち込んだり、レビュー担当者を「敵」のように感じてしまったりするかもしれません。

しかし、セキュリティレビューは、あなたの設計の欠点を探すためのものではありません。リリース前に潜在的なリスクを発見し、より安全で信頼性の高いシステムをユーザーに届けるための、非常に重要な品質保証プロセスなのです。指摘は、あなたの設計をより良くするための貴重なフィードバックであり、学びの機会と捉えましょう。指摘された内容を真摯に受け止め、なぜそれが問題なのかを理解し、改善していく。その繰り返しが、あなたをより優れたエンジニアへと成長させてくれるはずです。

まとめ

データベース設計は、単にデータを格納する器を作る作業ではありません。それは、システムの根幹を支え、最も重要な情報資産を守るための要塞を築く作業でもあります。機能要件を満たすことばかりに目を向けていると、気づかぬうちにセキュリティ上の重大な欠陥を作り込んでしまう可能性があります。

パスワードの平文保存、不適切なデータ型の使用、推測可能なIDの主キー利用、過剰なカラム設計、ログ設計の不備…。これらのセキュリティレビューで「赤点」を取りがちな「あるある」を反面教師とし、設計の初期段階からセキュリティ・バイ・デザインの考え方を取り入れ、具体的な対策を講じることが、堅牢なシステムを構築するための鍵となります。

セキュリティレビューは、あなたの設計を守り、強化するためのプロセスです。指摘を恐れず、むしろ学びと改善のチャンスと捉え、自信を持ってレビューに臨めるような、そして何よりもユーザーが安心して利用できるような、セキュアなデータベース設計を目指していきましょう。