「セキュア・バイ・デザイン」補習編（6章〜9章）

デッドライン読書会で読みきれなかった「セキュア・バイ・デザイン」の残りを読んでいます。範囲は、6章〜9章としました。補習編は複数回続きそう。

https://amzn.to/3GXRzQ0
amzn.to

6章 状態の完全性（integrity）の保証

  • 引数なしコンストラクタの危険性
    • 引数なしコンストラクタはsetterメソッドを使って初期化することを想定している。ただしsetterメソッドによる初期化はコードによって完全に初期化が完了したことを保証できないため、ビジネスルールを満たさないオブジェクトが生成される可能性が高い。
  • エンティティ作成の方法には複雑さに適応する順に以下が考えられる
    • 必須項目についてはコンストラクタで定義する
    • フルーエント・インタフェース
public Account withCreditLimit(Money creditLimit){
    this.creditLimit = creditLimit;
    return this;
}
...
Account account = new Account(...).withCreditLimit(limit);
  • （つづき）
    • 不変条件を各メソッドの最後に課して制御する
    • ビルダー・パターン
      • ビルダーをオブジェクトを生成するまでの手順が複数回あるコンストラクタのようなものとして捉える。（読んでてそう思ったらそう書いてあった）

7章 状態の複雑さの軽減

エンティティが管理する状態が複雑になると、実装も複雑となる。エンティティが扱う状態の複雑さを軽減する４つのパターンを解説するのがこの章。エンティティが扱われる環境が、大規模なのか否か、単一スレッドなのか複数スレッドなのかでどのパターンを利用するかを検討する。

  • 部分的不変エンティティ(partially immutabnle entity)
  • 状態オブジェクト(state object)
  • エンティティ・スナップショット(entity snapshot)
    • ReadとWriteを分離する。読み込みはエンティティ・スナップショット、書き込みはドメイン・サービス。
  • エンティティ・リレー(entity relay)
    • 状態を分類してエンティティで管理できるサイズに分割する。それを組み合わせる（リレーさせる）。
    • エンティティ・リレーを工夫すれば複数の状態を管理しやすくなるが適用に当たっては条件がある：フェーズ単位では一方通行で進むこと、フェーズ間の出入り口の状態は一つであること、あまりに多くの状態がないこと。
    • もし上記を満たさないときは、現在のモデルがどうしてこれほどまでに複雑なのかドメイン・エキスパートと議論するのがおすすめ。

8章 セキュリティを意識したデリバリ・パイプライン

セキュリティに関するテストをどのようにデリバリ・パイプラインに組み込むかを議論。

  • 異常値テストにおける「ファジング」
    • 書籍内で、wfuzzという異常値テストのテストデータ生成ツールの説明があった。ファジングという言葉は初耳。
    • IPAでもファジングの手引があった。丁寧に説明されているので参考になる。
Wfuzz: The Web fuzzer — Wfuzz 2.1.4 documentation
wfuzz.readthedocs.io
404 Not Found（お探しのページ・ファイルが見つかりませんでした。） | IPA 独立行政法人 情報処理推進機構
情報処理推進機構（IPA）の「404 Not Found（お探しのページ・ファイルが見つかりませんでした。）」に関する情報です。
www.ipa.go.jp
  • 機能トグル
    • 新旧機能や開発用機能/本番用機能の切り替え等に用いるテクニック。ソフトウェアとして脆弱なポイントになりやすいため（またミスしやすいため）、トグルのパターンに対する自動テストによる検証が重要。また本番環境における機能トグルの監視も重要。
  • 可用性の確保におけるドメインDoS攻撃
    • ドメイン・ルールを利用したDoS攻撃。例えばホテルのキャンセルポリシーを悪用し、宿泊の予約を大量に行い、キャンセル料が発生する直前に一斉キャンセルする。これによって本物の顧客をそのホテルに宿泊予約をしづらくする。
  • 設定の妥当性確認
    • セキュリティの欠陥を生み出す設定の間違いは、大きく分けて下記になる。
      • 設定に対しての意図しない変更
      • 設定に対しての意図した変更
      • 設定についての誤解

9章 安全性を考えた処理失敗時の対策

  • 処理の失敗を想定可能な結果として設計する。
    • 本書のビジネスロジックの失敗処理（例えば、送金メソッドを呼ぶ場合に残高が不足している）において、ビジネス例外（例えば、throw new AccountExceptiib(account balance)）で扱う説明が多かった（読んでてちょっと違和感があった）。が、9.2.2にて「想定可能な失敗処理は非例外で扱うべし」と説明があった。
  • 可用性の設計
    • サーキットブレーカー
    • バルクヘッド（隔壁）
      • システムを隔壁で分割して、一箇所の障害が複数箇所へ伝搬することを防ぐ考え方。ロケーションレベル（システムを地理的に分散配置する）、インフラレベル（サービスの役割に応じてインスタンスを分ける）、コードレベル（プーリングやキューを隔壁と見立てる）のそれぞれのレベルで考えることができる。
  • 間接的インジェクション攻撃（間接的（2次的）攻撃）
    • システムの裏側にあるシステム、例えば、システム監視ツールを狙って攻撃すること。フロントのシステムに対して悪意のある文字列を送信しその結果をログに落とさせる。そのログをバックエンドのシステム監視ツールで閲覧したときにインジェクション攻撃が成り立つようにすること。
    • ↑ということがあるので、受け取ったデータをログ等へ出力するには十分な配慮をする必要がある。…どうしたら良いんだろう・・・。

コメント

タイトルとURLをコピーしました