Kumatora の技術ブログ

先日、セキュア・バイ・デザインで紹介されているドメイン・プリミティブについての記事を書きました。

📄セキュア・バイ・デザインを学ぶ ~ ドメイン・プリミティブ / domain primitive ~

セキュア・バイ・デザイン 安全なソフトウェア設計 を読み終わったので、備忘録も兼ねて紹介されていた設計手法を簡単にまとめてみます

優れた設計を行うことで、気が付かないうちにセキュリティに関する多くのバグを取り除くことができるのだ。という主張の下に、堅牢で安全な設計手法を紹介してくれる本です。

その設計手法の一つとして、先日紹介したドメイン・プリミティブなどがあげられています。

📄セキュア・バイ・デザインを学ぶ ~ ドメイン・プリミティブ / domain primitive ~

セキュリティを主題にした本ですが、セキュリティの攻撃手法・対策というよりは、堅牢で安全な設計手法を紹介してくれている本です。

機密性・完全性・可用性・責任追跡性・保証性、とセキュリティの問題を広く扱っているので、インフラ面含めいろんな分野の設計手法が出てきます。

DDD をもとにした考え方もよく出てくるので、DDD についても理解が深まるのも良い点でした。

バグを減らせる設計手法を広く知りたいという方に最適です。

• 不変性（immutability）
  • 特にマルチスレッド下で可変オブジェクトは問題が起きやすい
  • 不変なオブジェクトを使うことで以下ができる
    • データの完全性を高める
    • 可用性の問題を減らす
• 契約（contract）を使った速やかな失敗（fail-fast）
  • 実行時に事前条件を満たさない場合は速やかに失敗させる
• 妥当性確認（validation）
  • 確認の種類として「オリジン（発生源）・サイズ・字句的内容（lexical content）・構文（syntax）・意味（semantics）」がある
  • 確認不可が低い順に並んでいるので、左にあるものから順に確認するのが望ましい

• 不変条件（invariant）
  • オブジェクトが生成されてから消滅するまで状態がどのように変わったとしても常に「真」とならなければならない条件のこと
  • 安全性を高める

• ドメイン・プリミティブ（domain primitive）
  • 📄セキュア・バイ・デザインを学ぶ ~ ドメイン・プリミティブ / domain primitive ~
  • 値オブジェクトに不変条件を導入し、値を安全に使えるようにする
• Read-Once オブジェクト
  • 機密性の高い値は一度だけしか読み取れないようにし、意図しない読み取りを防ぐ（ログに出してしまうなど）

• 引数なしコンストラクタの危険性
  • 初期値の代入は、コンストラクタによってすることを徹底する
    • setter で初期値を入れることをしない
  • 複雑な条件を持つオブジェクトの初期化をどうするか
    • ビルダー・パターン（builder pattern）
      • 初期化のための Builder クラスを用意する
      • フルーエント・インターフェースと組み合わせると読みやすくなる
    • フルーエント・インターフェース（fluent interface）
      • メソッドチェーンを使用しながら、文章のように読みやすいメソッドを作るパターン
• 可変オブジェクトの参照渡しを避ける
  • 複製して渡す
  • 読み取り専用にして渡す
• 部分的不変エンティティ（partially immutable entity）
  • 値を変えてはならないフィールドは不変にする
• 状態オブジェクト（state object）
  • エンティティの状態を、クラスとして設計しオブジェクトにして扱う
• エンティティ・スナップショット（entity snapshot）
  • 書き込み用のエンティティと読み込み用のエンティティを分ける
  • 読み込み用のエンティティは、書き込み用のエンティティから構築する
• エンティティ・リレー（entity relay）
  • 状態遷移を複数のフェーズに分け、分割したフェーズごとに別のエンティティを使うことで、エンティティの生存期間を短くする
  • 一旦終わったら戻らないような単位でフェーズを分けるのが望ましい

• 単体テスト
  • 正常値・異常値・境界値・異常値テストをする
• 機能トグル（feature toggle）のテスト
  • 事故りやすいことを認識した上でうまく付き合う
  • 機能トグルについての自動テストを作る
• セキュリティについても自動テストする
  • 擬似本番環境の用意
  • 可用性のテスト
  • 設定のテスト

• ビジネス例外（ドメイン・ルールの違反）と技術的例外（技術的なエラー）を分ける
  • 技術的例外に関する情報は、ユーザーに知らせないべき
    • エラークラスを分ける
  • 機密性のあるビジネスデータをエラーログに含めないべき
• 例外を使わず、結果オブジェクトを使う
  • 専用のオブジェクトを使うことによって情報を絞ることができる

• サーキット・ブレイカー（回路遮断器）
  • 一定回数失敗したらその環境へのリクエストを遮断する
• バルクヘッド（隔壁）
  • 一つのシステムが機能しなくなっても、他のシステムに影響が出ないようにする
  • ロケーションレベル・インフラレベル・コードレベルの分割がある

• セキュリティ的にも有益なクラウド的考え方
  • Twelve-Factor App
  • クラウド・ネイティブ
• エンタープライズ・セキュリティの3つの「R」
  • Rotate（定期的な変換）ー シークレットを数分もしくは数時間おきに変える
  • Repave（作り直し）ー サーバやアプリケーションを数時間おきに作り直す
  • Repair（修復）ー パッチが入手可能になったら、できるだけ早く適用する

ぜひ興味が湧いたら本を読んでみてください。

• セキュア・バイ・デザイン 安全なソフトウェア設計 Dan Bergh Johnsson (著), Daniel Deogun (著), Daniel Sawano (著), 須田智之 (翻訳)

📄セキュア・バイ・デザインを学ぶ ~ ドメイン・プリミティブ / domain primitive ~