デッドライン読書会の進捗が著しく悪かったので、補習を実施中…。前編分を読み切ったのでその感想をば。対象の書籍はセキュア・バイ・デザインです。
Bitly
2章 ちょっと休憩:「ハムレット」の悲劇
- 浅いモデリング(P.57)
- 開発現場でよく起きていそうなモデリング。その場しのぎのモデリングのことを深いモデリングに対して浅いモデリングと呼ぶ。例えば、ユーザーから要件をヒアリングする行為のみからデータモデリングをすると浅いモデリングになりそう。
- 例:本の冊数をなんとなくintで表現する。ISBN値をなんとなくstringで表現する。
- コードを書くことではなく、ドメインを理解すること(P.63)
- 深いモデリングを行う意味は「どのようにコードを書くか」ではなく、「この概念をどうすれば理解できるか」の試行錯誤の過程。
3章 ドメイン駆動設計の中核をなすコンセプト
ドメイン駆動設計において本書で基盤として必要となる重要な概念について解説。
- ドメイン駆動設計のとりあえずの入門書として「Quickly」がある。日本語訳もある。
- https://www.infoq.com/jp/minibooks/domain-driven-design-quickly
- DRYの原則は構文的な重複を避けるのではなく、意味的な重複を避けることを指している。
- 「異なるコンテキストでのやりとり」での注意点
4章 安全性を確立する実装テクニック
実装テクニックとして、3つをあげる。
- 不変性:immutability
- 設計に不変性を導入すれば、オブジェクトの状態を意図せず変更されることがなくなるため、自然とセキュリティの向上を見込める。
- 速やかな失敗:fail-fast
- コード上で契約として事前条件、事後条件を定義し、条件に合致しない場合は速やかに失敗する。
事前条件の確認としてApache Commons LangのValidateを利用しているが、ここで重要な点として以下。
例外を発生させた不正なデータを繰り返し使わないことです。(略)ログに出力するようなことをしていると、そのことが脆弱性となることがあります。
P.145 4.2 契約(contract)を使った速やかな失敗(fail-faset)
- 妥当性確認:validation
- 妥当性確認を実施する順番
- オリジン(発生源)
- サイズ
- 字句的内容
- 構文
- 意味
- 妥当性確認を実施する順番
5章 ドメイン・プリミティブ
- ドメイン・プリミティブ
- 安全性の高い実装テクニックと値オブジェクトを組み合わせたもの。
- 不変条件はオブジェクトの生成時に確認される
- ドメイン・プリミティブは保持する値が有効である場合だけ存在できる
- 基本データ型やStringなどの汎用的な型ではなく、ドメイン・プリミティブを利用する
- コンテキスト境界に気をつける
- ドメイン・プリミティブ・ライブラリーを整備する
- ドメイン・プリミティブ・ライブラリーってコードとしてはどう管理されるんだろうか。
- 安全性の高い実装テクニックと値オブジェクトを組み合わせたもの。
- Read-Onceオブジェクト
- 機密性の高いデータを意図したとおりに1回だけ利用できるようにするパターン
- 複製やシリアライズ化をできないように制御する
- 確証バイアス
- 「ここまで見てきたコードは問題がない」と脳が認識してしまうと、「このあとも問題ないだろうな」と思い込んでしまう。
確証バイアス(かくしょうバイアス、英: confirmation bias)とは、認知心理学や社会心理学における用語で、仮説や信念を検証する際にそれを支持する情報ばかりを集め、反証する情報を無視または集めようとしない傾 向のこと。
https://ja.wikipedia.org/wiki/確証バイアス
- 汚染解析(taint analysis)
- 汚染させたデータを入力させて、動的解析することにより、そのデータがどうコード中を遷移するのかを検証する。
- 通常の動的解析ツールはこういった汚染解析をしていると言うんだろうか。
コメント