セキュア・バイ・デザイン 安全なソフトウェア設計

備考

Dan Bergh Johnsson氏、Daniel Deogun氏、Daniel Sawano氏の3人は数十年に渡ってセキュリティと開発の分野に従事してきた経験を持つ人たちです。彼らはエンジニアであり、開発においてセキュリティが二の次となりがちなことを理解しています。そこで彼らは設計の質を高めることに意識を向けセキュリティの向上が期待できるシステム開発の習慣をまとめ上げていきました。これらの習慣はエンジニアが日々の作業を行う際に簡単に心掛けられるものになっています。著者らはそれぞれ国際的なスピーカーとしての地位を確立し、質の高い開発やセキュリティが主題となるカンファレンスによく登壇しています。

［翻訳］須田智之（すだともゆき）
10年以上おもにSI企業にシステムエンジニアとして携わり、それ以降はフリーランスに。企業向けのシステム開発のかたわら、個人での開発、および、記事や書籍の執筆や翻訳も行っている。

関連ページ

• サポートサイト　https://book.mynavi.jp/supportsite/detail/9784839975999.html
• 原著サイト　https://www.manning.com/books/secure-by-design
• サンプルコード（code.zipがダウンロードされます）　https://www.manning.com/downloads/2054

目次

第1部　導入編
第1章 なぜ、設計がセキュリティにおいて重要なのか？
1.1 セキュリティを機能（feature）ではなく心配事（concern）として捉えること
1.2 設計（design）とは何か？
1.3 セキュリティにおける従来のアプローチとその欠点
1.4 設計（design）による安全性の向上
1.5 文字列、 XML、 そして、 Billion Laughs 攻撃への対応

第2章 ちょっと休憩『: ハムレット』の悲劇
2.1 ビジネス・ルールの観点における完全性（integrity）の問題
2.2 浅いモデリング（shallow modeling）
2.3 深いモデリング（deep modeling）


第2部　基礎編
第3章 ドメイン駆動設計の中核を成すコンセプト
3.1 深い理解を得るためのツールとしてのモデル
3.2 モデルをコード上で表現するための構成要素
3.3 境界づけられたコンテキスト（bounded context）
3.4 異なるコンテキスト間でのやり取り

第4章 安全性を確立する実装テクニック
4.1 不変性（immutability）
4.2 契約（contract）を使った速やかな失敗（fail-fast）
4.3 妥当性確認（validation）

第5章 ドメイン・プリミティブ（domain primitive）
5.1 ドメイン・プリミティブ（domain primitive）と不変条件（invariant）
5.2 Read-Onceオブジェクト（一度しか読み込めないオブジェクト）
5.3 ドメイン・プリミティブによってもたらされるセキュリティ
5.4 汚染解析（taint analysis）

第6章 状態の完全性（integrity）の保証
6.1 エンティティを使った状態の管理
6.2 正しい状態で生成されるエンティティ
6.3 エンティティの完全性（integrity）

第7章 状態の複雑さの軽減
7.1 部分的不変エンティティ（partially immutable entity）
7.2 状態オブジェクト（state object）
7.3 エンティティ・スナップショット（entity snapshot）
7.4 エンティティ・リレー（entity relay）

第8章 セキュリティを意識したデリバリ・パイプライン
8.1 デリバリ・パイプラインの利用
8.2 設計をより安全なものにする単体テスト
8.3 機能トグル（feature toggle）のテスト
8.4 セキュリティに関するテストの作成と自動化
8.5 可用性（availability）のテスト
8.6 設定の妥当性確認（validation）

第9章 安全性を考えた処理失敗時の対策
9.1 処理が失敗したときの対応に使われる例外
9.2 例外を使わない処理失敗時の対応
9.3 可用性（availability）の設計
9.4 不正なデータの対応

第10章 クラウド的考え方によるメリット
10.1 Twelve-Factor App とクラウド・ネイティブの2つのコンセプト
10.2 環境に格納された構成情報（configuration）
10.3 状態のない（stateless）独立したプロセスとしてのアプリケーションの稼働
10.4 ログをファイルに残すことの危険性
10.5 システム管理（administration）プロセス
10.6 サービス検出（service discovery）と負荷分散（load balance）
10.7 エンタープライズ・セキュリティの3つの「R」

第11章 ちょっと休憩：保険料の支払いなしに成立してしまった保険契約
11.1 店頭での保険販売（デジタル化の前）
11.2 複数のサービスへの分割
11.3 新たな種類の支払い方法の追加
11.4 交通事故、未払いの保険料、そして、裁判
11.5 何が間違いだったのかを理解する
11.6 全体像の把握
11.7 マイクロサービス・アーキテクチャにおける注意点


第3部　応用編
第12章 レガシー・コードへの適用
12.1 レガシー・コードのどの部分にドメイン・プリミティブを適用するのか？
12.2 メソッドやコンストラクタの曖昧な引数
12.3 ログにおける未検査の文字列
12.4 過保護な実装
12.5 DRY （Don’t Repeat Yourself）原則の誤解
12.6 ドメイン固有の型における不十分な妥当性確認（validation）
12.7 テストだけで十分なのか？
12.8 不完全なドメイン・プリミティブ

第13章 マイクロサービスでの指針
13.1 マイクロサービスとは何か？
13.2 境界づけられたコンテキスト（bounded context）を表すサービス
13.3 異なるサービスを行き来する機密性の高いデータ
13.4 マイクロサービスにおけるログ

第14章 最後に：セキュリティを忘れるべからず！
14.1 セキュリティを意識したコード・レビュー
14.2 最新のセキュリティに関する情報の把握
14.3 侵入テスト（penetration test）の実施
14.4 セキュリティの分野についての学習
14.5 セキュリティ・インシデントに対する仕組み