Recommended
More Related Content
What's hot
What's hot (20)
Viewers also liked
Viewers also liked (20)
Similar to RDBにおけるバリデーションをリレーショナルモデルから考える
Similar to RDBにおけるバリデーションをリレーショナルモデルから考える (19)
More from Mikiya Okuno
More from Mikiya Okuno (12)
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 基礎の基礎から よくある間違いを 指摘しつつ 応用まで