RDBにおけるバリデーションをリレーショナルモデルから考える
- 3. 自己紹介 ● MySQL サポートエンジニア – 日々のしごと ● トラブルシューティング全般 ● Q&A 回答 ● パフォーマンスチューニング など ● ライフワーク – 自由なソフトウェアの普及 ● オープンソースではない ● ブログ – 漢のコンピュータ道 – http://nippondanji.blogspot.com/ 今日は個人として 参加しています。
- 5. SQL インジェクション ● ≠RDB の問題 – アプリケーションが意図しない SQL を生成してしまう問題 – アプリケーションの問題 – RDB 側でバリデーションは要らない、アプリでやってくれ。 話が終わった！！
- 6. 入力バリデーション ● ≠RDB の問題 – アプリケーションが意図しないデータを受け付けてしまう 問題 – アプリケーションの問題 – RDB 側でバリデーションは要らない、アプリでやってくれ。 話が終わった！！ またもや
- 8. 制約（ Constraint ） ● 制約とは、評価した結果真となるべき条件式。 ● Type Constraint – データ型が満たすべき条件 – ≒ ドメインの定義 ● Database Constraint – データベース内のデータが満たすべき条件 – 外部キーは Database Constraint の一種
- 9. ドメイン ● ドメイン＝リレーショナルモデルにおけるデータ型 – 属性（≒カラム）が取りうる値の集合 ● 属性の値は、ドメインの要素のひとつであると考える – 平たく言うと、属性の値は予めドメインに登録されている とされたものだけであるという考え – そうなるようにドメインを設計する
- 10. ドメインは究極のホワイトリスト！ ● ドメイン＝属性が取り得る値の集合 – 値は想定されたもののみ – 集合の要素の一つを取ってくるだけ – つまり、ホワイトリスト ● 事前に判明している値なら、どれを取っても安全なはず だが現実は 甘くない！！
- 11. どうやってドメインを表現するか ● 実際にドメインを集合として表現することは不可能に近い – 特に文字列で表現するデータが難しい ● データサイズが大きい ● ドメインの要素数が膨大になる ● 列挙できるがデータサイズが大きいもの – 住所 etc ● 未知の値が多すぎて対処できないもの – 人名、商品名、部品の名称 etc ● フリーダム過ぎるもの – メールアドレス、アカウント名、コメント etc
- 12. 妥協案＝ドメインを制約で表現 ● SQL 上で使用できるツール – CHECK 制約 – CREATE TYPE – トリガー（ CHECK 制約がない製品で） – テーブル＋外部キー制約 ● 制約≒テーブルへ格納するデータをフィルタリングする
- 13. データの危険性 ● ロジックで値をフィルタリングする以上、ホワイトリストには成 り得ない – 格納されている値は安全ではないかも知れない – 攻撃用のコードが仕組まれているかも・・・・ ● XSS 、 CSRF 、セカンドオーダー SQL インジェクション etc バリデーションが 必要では！？
- 14. DB の出力⇒アプリへの入力 ● アプリケーションへ入力されたデータは適切にバリデー ションしましょう。 ● バリデーション≠ RDB の問題 – アプリケーションが意図しないデータを受け付けてしまう 問題 – アプリケーションの問題 – RDB 側でバリデーションは要らない、アプリでやって くれ。 ● RDB でやるべきことは制約 – ≒RDB へ格納するデータのフィルタリング
- 15. ドメインの設計は超重要 ● 正しいデータ型を使えばアプリケーションによるバリデーショ ンの手間が軽減される ● 数値は数値型を – 数値を文字列で格納するべからず！ – 数値型ならバリデーション不要 ● CHECK 制約で取り得る値の範囲を絞り込む – 安全であることが保証されていると GOOD!! ● 英数字のみの文字列など – 正規表現を活用 ● フリーダムなデータはアプリ側で確実にバリデーションを
- 16. （余談）本当に正しい値か？ ● もし仮にホワイトリスト方式でドメインを実装しても、この問い は完全には消え去らない – ユーザーが間違った値を選択してしまう可能性がある – Database Constraint で軽減できるが限界はある ● 最終的にデータが正しいかどうかを確かめるのは、アプリ ケーションの運用者 – 確認するのは管理権限を持ったユーザー – ユーザーに身分証の提示を依頼する等 ● 氏名、年齢、住所、電話番号 – 実際に機能するかどうか確かめる ● メールアドレス、 SMS ● 運用設計は重要 – 確認にはコストがかかる – 重要なデータにコストをかける ● 正しさが重要でないデータもたくさんある
- 17. SQL ≠ リレーショナルモデル
- 18. SQL≠ リレーショナルモデル リレーショナルモデル ● 集合論（述語論理）に基づ くデータモデル ● 全て集合：見出し、組、本 体、ドメイン ● 集合演算に基づく各種操 作が定義されている SQL ● リレーショナルモデルに基 づいたデータベース操作言 語 ● SELECT に各種リレーション の演算が盛り込まれている ● リレーショナルモデル以外 のデータの扱いおよび操作 も可能 – NULL – 重複 – カーソル
- 19. リレーショナルモデルでは 表現できないものがある ● グラフ ● ツリー ● 行列 ● 履歴 ● 全文検索 ● 正規表現 ● ソート ● 集計 ● 空間データ etc etc
- 20. リレーショナルモデルの 外側の世界 ● 現実世界のアプリケーション – リレーショナルモデルに適合するデータと、そうでない データが入り乱れている。 – リレーショナルモデルには定石がある – リレーショナルモデル以外の領域に決定的なやりかた （ DB 設計、クエリの書き方等）はない ● 創意工夫が必要 ● 外側の世界ではリレーショナルモデルを無理に実践すべき ではない！！ – そもそも無理 – うまく行ったように見えても技術的負債に ● 両者の境界線を見極めることが重要 – リレーショナルモデルで解決できる部分はリレーショナル モデルを適用すべし！！ – そうでない部分はリレーショナルモデルを適用してはなら ない！！
- 21. RDB における 制約とバリデーション ● 制約：リレーショナルモデルの世界 – ドメインを近似する（ Type Constraint ） – データの整合性を保つ（ Database Constraint ） ● バリデーション：リレーショナルモデルの外側の世界 – アプリケーションと同じようにバリデーションが必要 ● プロシージャ内で使用する値を検証する ● リレーショナルでないデータ ● リレーショナルでない各種操作の実行後 – 部分文字列 – 文字列の結合 – ただし、実際には SELECT で取得した文字列を使って動 的にクエリを組み立てない限り、 RDB 内部で問題になる ことはない。 ● プロシージャ内で PREPARE するべからず
- 22. まとめ ● RDB にあるのは制約 – バリデーションではない ● RDB まわりでバリデーションが必要になるところ – RDB からの出力＝アプリケーションへの入力 ● バリデーションはアプリケーション側の課題 – リレーショナルモデルに沿わないデータやロジック ● プロシージャ内で PREPARE するべからず バリデーションについて考えるときも、 リレーショナルモデルについての理解は 大切だと思います。
- 23. 宣伝：新書籍の紹介 ● リレーショナルデータベース実践入門 – リレーショナルモデル、 SQL 、そして DB 設計が主なテーマの書籍です。 – どうやってリレーショナルデータベースを使いこなすか！ ● リレーショナルモデル基礎編 – SQL とリレーショナルモデル – 述語論理とリレーショナルモデル – 正規化 1: 関数従属性 – 正規化 2: 結合従属性 – 直交性 – ドメインの設計 etc ● アプリケーション開発実践編 – 履歴 – グラフ – インデックスの設計 – ウェブアプリケーションのためのデータ構造 etc 基礎の基礎から よくある間違いを 指摘しつつ 応用まで