関連サイト
本書の関連ページが用意されています。
内容紹介
プログラミングの質を高めることで、セキュリティを向上させることができる― 著者らの考えを様々な形で試し検証を行い、本書「セキュア・バイ・デザイン（Secure by Design）・安全なソフトウェア設計」にまとめました。
本書はEric Evans氏のドメイン駆動設計（Domain-Driven Design: DDD）に関する考えの影響を大きく受けています。設計の中心にセキュリティを取り込む考え、ドメイン駆動セキュリティ（Domain-Driven Security）という名のコンセプトを生み出しこの考えを実際に開発に導入し、発展させてきました。
対象読者はソフトウェア開発者（C言語、JavaやC#など基本的なプログラミング技術を習得済みの方）ですが、特定の言語やフレームワークに依存しすぎないよう、主にセキュリティにおいて重要だと思うものだけを含めるようにしています。全体的なプログラミング・スキルを向上したかったり、既存のプログラムをさらに「安全」なものにしなくてはならなかったりするのであれば、本書はまさにあなたにとっての一冊となることでしょう。
第1部: 導入編
セキュア・バイ・デザインについて実例と共に見ていきます。セキュリティと開発についてどのように考え、それらが組み合わさるのか。あわせてどこで問題が起こりやすいのかと何ができるのかを分析します。
第2部: 基礎編
ソフトウェアの作成におけるセキュア・バイ・デザインの基盤を構築する設計の原則、考え、コンセプトについて学んでいきます。
第3部: 応用編
多くの開発者は「セキュア・バイ・デザイン」をレガシー・コードに適用することが難しいと感じる傾向があります。レガシー・コードの改善、モノリシック・アーキテクチャでよく起こる問題、マイクロサービス・アーキテクチャについて見ていきます。
書誌情報
- 著者: Dan Bergh Johnsson, Daniel Deogun, Daniel Sawano, 須田智之
- 発行日: 2021-09-24 (紙書籍版発行日: 2021-09-24)
- 最終更新日: 2021-09-24
- バージョン: 1.0.0
- ページ数: 560ページ(PDF版換算)
- 対応フォーマット: PDF
- 出版社: マイナビ出版
対象読者
著者について
Dan Bergh Johnsson
Dan Bergh Johnsson氏、Daniel Deogun氏、Daniel Sawano氏の3人は数十年に渡ってセキュリティと開発の分野に従事してきた経験を持つ人たちです。彼らはエンジニアであり、開発においてセキュリティが二の次となりがちなことを理解しています。そこで彼らは設計の質を高めることに意識を向けセキュリティの向上が期待できるシステム開発の習慣をまとめ上げていきました。これらの習慣はエンジニアが日々の作業を行う際に簡単に心掛けられるものになっています。著者らはそれぞれ国際的なスピーカーとしての地位を確立し、質の高い開発やセキュリティが主題となるカンファレンスによく登壇しています。
Daniel Deogun
Daniel Sawano
須田智之
10年以上おもにSI企業にシステムエンジニアとして携わり、それ以降はフリーランスに。企業向けのシステム開発のかたわら、個人での開発、および、記事や書籍の執筆や翻訳も行っている。
目次
第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 セキュリティ・インシデントに対する仕組み