セキュア・バイ・デザイン 第1章 なぜ、設計がセキュリティにおいて重要なのか？
===
###### tags: `セキュア・バイ・デザイン読書会`

# Discord開始位置

-

# 自己紹介

- なかじま（J.Nakajima）
- ファシリ役
- タイムキーパー役
- こばやし（t2_Kobayashi）
- 読み上げ役

# 参加の仕方

- マイクはいつでもONにして、話に参加して結構です。
- テキストチャットでも、コメントやリアクションでどんどん参加してください！ラジオ担当が拾っていきます。
- 聞いているだけの方もOKです！

# ディスカッションをより豊かにするためのグランドルール

- 参加者は毎回任意
- 今回は不参加、次回は参加をするといった気軽な感じ
- 途中参加も断然OK! まずは聞くだけでも大丈夫です！
- フィードバックを恐れない
- マサカリは怖いと思いますが、アウトプットからのフィードバックを受け、学びを深めていきましょう
- アウトプット7割：インプット3割の気持ちで臨みましょう！
- 経験の有る無しは気にしない
- 自分はDDDとかセキュリティに詳しくないから……と気後れする必要はないです
- 堂々と意見や疑問を語りましょう
- ページ数と同時に、節のタイトルやキーワードを言って頂けるとスムーズです
- 電子書籍で読んでいるとページ数ではわからないため
- 話していない人が、率先してメモしましょう
- このHackMDはみんなのものです。どんどん書いていきましょう:+1: :+1:
- 気になる質問や同感するものには :+1: を末尾につけてください。

# タイムテーブル

| 時間 | 所要時間 | 内容 |備考 |
| -------- | -------- | -------- | -------- |
| 19:50- | - | 集合開始 | |
| 20:00-20:15 | 15分 | 当日の流れとグランドルールの共有 | |
| 20:15-20:25 | 10分 | 感想記入&HackMDに書かれた皆さんの感想・気づき・疑問をもっと掘り下げたいものを、 :+1: 付けていく | |
| 20:25-21:55 | 90分 | 本の節ごとにディスカッション（ここでも適宜、HackMDに気づきとか書いていってもらっていいです） | |
|21:55-22:00 | 5分 | 次回開催日と読む範囲決めてクローズ | |

## :tada:下に感想などを書いていって下さい。どんな些細なことでもOKです。:tada:

---

# 第1章序文
## 目安の時間
- 10分

## 感想・気づき

- > P.4 バックログにあるセキュリティに関するタスクはビジネス要求を満たす機能のタスクよりも優先度が低く設定され、いつまでも残り続けていました。そして、最終的には、このプロジェクトは時間的な余裕がなくなってしまい、ユーザが必要とする機能をまずは揃えることが安全性よりも重要になってしまいました。
- [discord](https://discord.com/channels/432531367427964929/911610565103845387/921724726362132520)
- 結構あるあるな気がする。:+1: :+1: :+1: :+1::+1::+1:
- 上記のようにユーザー価値を実現しないが品質を高めるタスクは後回しにされがち
- 今の現場では上記のような理由でリファクタリングをタスクとして出さないと決めず、各ユーザーストーリーの中で少しずつやっているので、セキュリティも同じように取り込むようにすることだと思った

- > P.5 その考え方とは、開発者はセキュリティそのものに目を向けるのではなく、設計(design)に目を向ける、というものです。
- 設計をやるタイミングでセキュリティをやる、というよりは、DDDというアプローチで考えて自然とセキュリティを向上させるといった感じかな :+1::+1:

- 歴史的に (?) 「関心事」と訳されてきた *concern* が「心配事」ですね
- 関係ないですけど「かんしんじ」と「しんぱいごと」。日本語的にはどっちもわかりにくくて、日本語難しいなぁと思ってます:+1:

## 疑問

-------------------------------------

# 1.1 セキュリティを機能(feature)ではなく心配事(concern)として捉えること
## 目安の時間
- 26分

## 感想・気づき

- > p.7 この話からわかることは、セキュリティがいかに機能として見られているか、と言うことです。先ほどの例では、強力な錠前をつけることで安全になると想定していたわけですが、実際には、錠前の機能だけで安全を確立することはできませんでした。
- セキュリティの対応を考えても、後で利用側が利便性を考えてセキュリティが機能しない状態になると言うのはこの例だけでなく、時々ある話。

- > P.7 技術的なことに関しては、犯人たちが一貫して銀行の脆弱だった部分を責めたことについて注目すべきでしょう。
- [discord](https://discord.com/channels/432531367427964929/911610565103845387/921727336993402890)
- セキュリティ機能ではなく、脆弱な部分を攻撃するのが基本。 :+1: :+1::+1::+1: :+1::+1::+1:

- > P.11 本当の意味で安全性を確立するためには、セキュリティを機能として考えることをやめなければなりません。そうではなく、セキュリティを横断的な心配事、つまり、様々な機能にまたがって懸念される心配事としてみなければならないのです。
- [discord](https://discord.com/channels/432531367427964929/911610565103845387/921728300680896523)
- まさにその通りですね。
- 「強力な鍵前をつけること」というオーダーであれば、そういうことが起こってしまうのも納得。:+1::+1::+1: :+1:

- > P.7 セキュリティを機能として扱うのではなく、心配事として見ることで、より良い結果に繋がるようになります。例えば、もし、銀行がセキュリティを心配事として捉えていた場合、その銀行は「どうしたら、泥棒がお金を持ち去ることは防げるようになるのか？」を考えるようになります
- 機能と心配事の違い。ユーザーストーリーのどうしたらユーザーに価値が届くのか？と考えるのに近いのかも:+1:

- 機能として考えるのではなく、心配事で考えることによって、「ログイン画面を実装すればセキュリティが担保される」といった思考に陥りにくいといったことをこの章では言っているのかな

- > P.13 しかしながら、それとは別の方法があります。その方法とは、セキュリティを開発者の作業やソフトウェアの設計に組み込む、というものです:+1:
- セキュア・バイ・デザインを実践する動機

- > 可用性は取得可能なデータを必要なときに取得できることを意味する要素である - p.12
- [discord](https://discord.com/channels/432531367427964929/911610565103845387/921729801641938995)
- 可用性(Availability)、が大事なのは異論ないけれど、それは「セキュリティ」の範囲の話なの？と初見思った :+1: :+1:
- 調べてみると、「情報セキュリティ」というカテゴリにとってデータへの不正アクセスは関心事の一部であってイコールではないという理解が（少なくとも、そちらの方面では）一般的なよう:+1:
- https://en.wikipedia.org/wiki/Information_security
- > It typically involves preventing or reducing the probability of unauthorized/inappropriate access to data, or the unlawful use, disclosure, disruption, deletion, corruption, modification, inspection, recording, or devaluation of information.
- ↑の出典も見ておこうと飛んだら、リンク先では *Wikipedia says* とか書いてるのは、いったいどういうギャグなんだ（おかげで、この説明を真に受けて良いのか迷った）
- [ここの記事](https://www.geeksforgeeks.org/what-is-information-security/) だと、可用性が損なわれるケースの例として「サービス妨害攻撃(Denial of service attack)」を上げている
- 例えばDos攻撃でサーバーダウンして重要データにアクセスできないとか、ウイルスの侵入によって機密データが全て暗号化されて内容を確認できなくなったとか、そういう例を考えると、可用性が（情報）セキュリティにおいて重要な位置を締めていることも頷ける
- 脚注で提示されている[John Wilander と Jens Gustavssonの論文(p.9)](https://www.ida.liu.se/labs/pelab/publications/documents/2005/08_wilander_sreis.pdf) でも、 *4 Field Study of Eleven Requirements Specifications* で上げられている11のセキュリティ要求事項の中に「可用性(Availability)」が含まれている(Wilander, Gestavsson p.3~4):+1:
- 地方病院のカルテ情報がランサムにかかって、暗号化されたみたいな記事があった気がしますが、これは完全性？？、それとも可用性？？:+1::+1:
- https://www.nikkei.com/article/DGXZQOUE071OK0X01C21A1000000/
- このケースでは可用性と機密性どちらが重要？
- 暗号化によってアクセスできなくなる、というケースは、可用性の侵害と完全性の侵害を両面含んでいるという風に言えそうな気もするし、データのガワが加工されただけで中身は無事だから可用性の問題と限定することもできそうではある（CIAの三者はグラデーションであって、A or Bと明確に峻別できるとは限らない、という話はあったりするのだろうか）
- 「データは公開される」ってことが本当であれば、機密性にも危害が及んでいそう

## 疑問

-------------------------------------

# 1.2 設計(design)とは何か？
## 目安の時間
- 26分

## 感想・気づき
- p9 「あるユーザーがアップロードした写真の中に・・・、別のユーザーが何らかの手段でこの写真へのダウンロードリンクを直接入手」
- AWS環境で画像を保存してる、S3がパブリックで公開されていたりすると発生しそう :+1::+1::+1::+1::+1: :+1:

- > 一般的に、「設計」という言葉はあまり深く考えずに使われており、誰と話しているのか、そしてどの文脈で使われているのかによって意味が異なります。(...)本書における「設計」という言葉の意味を理解することで、本書で扱うトピックやコンセプトをさらに深く理解できるようになるはずです。(...)本書では、「どのような行為が設計の行為なのか？」という質問の答は、ソフトウェア開発で行われるすべての行為が設計の行為であり、これらすべての行為が設計プロセスの一部として行われていると考えています。 - p.13~15
- [discord](https://discord.com/channels/432531367427964929/911610565103845387/921735221353803796)
- 定義とともに、「あまり深く考えずに使われて」いるという指摘も同意:+1::+1::+1::+1::+1::+1:
- にも関わらず、ここでの「設計」はどういう意味・意図・範囲で使われているのかを深く考える/確認することなく会話したり書籍を呼んだりすると、「設計」に含める範囲の食い違いから、「何を言っているのかわからない」という事態に陥りがちだと思う:+1:
- 「設計」という言葉が曖昧に使われている状況を指摘しつつ、その上で本書で扱う定義を明確に（しかも、「これが真の"設計"なのだ」と大言壮語することもなく、淡々と）提示しているのは、非常に好感:+1:

- > P.15 「どのような行為が設計の行為なのか？」という質問の答えは、ソフトウェア開発で行われるすべての行為が設計の行為であり、これらすべての行為が設計プロセスの一部として行われていると考えています
- [discord](https://discord.com/channels/432531367427964929/911610565103845387/921737673952067615)
- 同意。アーキテクチャレベルで考えることも、if文やforループをどのようにやるかなどの実装レベルで考えることや、ドメインモデルの抽出など、どれもそう :+1::+1::+1::+1::+1::+1::+1: :+1:
- 設計などは芸術という表現をどこかの本で読んだ気がしますが、それがしっくりきました。

## 疑問

- > P.15 ソフトウェア開発において、能動的な意思決定が求められる行為はすべて設計プロセスの一部だと見なされるべきであり、このような行為を設計と呼んでも過言ではありません。
- [discord](https://discord.com/channels/432531367427964929/911610565103845387/921732662190805012)
- 本書では設計を非常に（あるいは最も）広く捉えていますが、それらの個々の意思決定の質が高まることで、徐々にセキュアになるということなのだろうか？:+1::+1::+1::+1: :+1:

-------------------------------------

# 1.3 セキュリティにおける従来のアプローチとその欠点
## 目安の時間
- 26分

## 感想・気づき

- > P.16 セキュリティの優先度をもっとも高くする、ということがよく行われます。
- [discord](https://discord.com/channels/432531367427964929/911610565103845387/921739200443846676)
- やっています。が、全社スローガン止まりで実態としては機能していないのでは、とハッとさせられました。:+1::+1::+1::+1::+1::+1:

- > P.17 問題となる箇所は、ユーザ名を文字列として受け取っているところで、この部分を利用してXSS攻撃が行われる可能性があります。
- [discord](https://discord.com/channels/432531367427964929/911610565103845387/921741453649117184)
- 最初読んだときは、XSSは出力時のコンテキストの問題なのでUserクラスとはレイヤーが違う問題であり、なんか無理やりな例のような感じがしました。しかし、usernameのとりうる範囲が無駄に広すぎるという設計上の問題が、それを解決することでXSSのリスクも減らすことは事実であり、セキュア・バイ・デザイン（が何かまだ把握できていませんが）の例として妥当なものなのかなと思いました。 :+1::+1::+1:
- アプリケーション要件としてusernameに使える文字種を定義することで、副次的にXSSやSQLインジェクションの対策になるという話がこの先出てくると想像して読みました。すべての開発者に高度なセキュリティ知識を求めるのは難しいため、XSSやSQLインジェクションを知らなくても（そのぐらいは知っておけと言われそうですが、一例として考えてください）セキュアなアプリケーションになるように設計しようと主張していると捉えました。:+1::+1::+1::+1::+1::+1:
- p.24をカンニング(is 何)しちゃうと、だいたい↑の想像で合ってるっぽい

- 従来のアプローチがすべての経路でセキュリティを担保するブラックリスト的なやり方だと、ビジネス・ロジックと一緒にセキュリティも意識しなければいけないし、未知のことを知らなければならないといった矛盾に立ち向かわないといけなくなる。 :+1:
- まだ先に出てくる話だろうけど、DDDのアプローチを導入することで、UserNameが取りうる値を定義してそれ以外は許容しないといった形にすれば自然とセキュリティが向上してくるってことだと思った

- > P.20 「知ることができないことを知らなくてはならない」
- 未知の脅威に備えるために、今見えている範囲を綺麗にする、みたいな話かな、とてもわかる:+1::+1::+1:

- > P.16 OWASP Top10 について熟知することが求められます
- SonarQube のような静的解析ツールではそれらがカバーされているというのは、本書のセキュア・バイ・デザインの本論とはずれるかもしれないけど、そういう仕組みを入れること自体も、「能動的な意思決定」の補助になるんだなあと思いました
- https://www.sonarqube.org/features/security/owasp/
- https://yamory.io/blog/2021-owasp-top-10/
- > 新しいカテゴリーの「安全でない設計」が4位になっています。シフトレフトを進めていくためには、Secure by Designの原則に不可欠なコーディング前の活動が重要であるため、OWASP Top 10のカテゴリーとしても含まれるようになりました。「安全でない設計」の追加は、今回の変更の中でも最も大きなものだと感じていますし、OWASP 20th Anniversaryのプレゼンテーションの中でも最も物議を醸すものだと発言しています。
- 今改めて読むと、これが New で入っているのがタイムリーな気がしました..

## 疑問

-------------------------------------

# ===================後半(1/8)はこちらから===================

-------------------------------------

# 1.4 設計（design）による安全性の向上
## 目安の時間
- 40分

## 感想・気づき

- > ここで注目してもらいたいのは、ユーザ名から「<」や「>」などの文字が除外されているのは、Webブラウザ上で描画する際にそれらの文字が使えてしまうとXSS攻撃として使われる可能性があることを考えていたわけではない、ということです。そうではなく、「このコンテキストにおいて、ユーザ名とは何なのか？」ということを熟考した結果なのです。 - p.22
- [discord](https://discord.com/channels/432531367427964929/911610565103845387/929340829519216681)
- セキュリティの観点からではなく、設計の観点からアプローチした例 :+1:
- 「ユーザー名を登録する」「ユーザー名を変更する」と言った機能(feature)ではなく、「ユーザ名とは何であり、どのようであるべきで、どのようであってはならないか」という関心(concern)から分析/検討されている、とも取れるか:+1::+1::+1::+1::+1::+1:
- 一方で、例えば「<」や「>」について、入念な吟味の結果「ユーザ名に含める**べきである**」と判断せざるを得ないようなケース（「ユーザ名でそんなことになるのは決して or 大抵はありえない」と主張するのであれば、ユーザ名ではなく、画面に表示される任意の項目でも良い）の場合、XSSが自ずと防がれるということは無くなると思うが、こうしたケースについてはどうなるのか。
- 「ソフトウェアの開発中にセキュリティについて注意する必要はない、ということを言いたいわけではありません」という前提であり、精々が「セキュリティを常に意識し続ける必要はなくな」るというだけ（p.20）であって、セキュリティを意識する必要は*全く*なくなるわけではない、ということなのだろう :+1::+1::+1::+1:
- このあたりを踏まえると、少なくともセキュア・バイ・デザインというアプローチを「ドメインやアプリケーションの設計に注力すれば、勝手にセキュリティも担保できる」という形で理解するべきではないし、することもできないと思う :+1::+1::+1::+1::+1::+1::+1::+1::+1:
- 精々、「ドメインやアプリケーションの設計に注力すれば、セキュリティに関する問題も同時に*いくらかは*担保できる*ことがある*」という程度に留めるべきか。
- セキュリティおよびセキュリティ技術に関する知見そのものは、依然として要求されることには変わりないだろう。
- 「常に意識し続ける必要はなくなる」というだけで、セキュリティの問題が発生し得るようなケースでは意識しなくてはならないし、そうしたケースに気づくための知見と嗅覚の必要性は、セキュア・バイ・デザインによってはいささかも減じない、と理解するのが妥当だろう。:+1::+1:
- 例えば上記のような、「<」や「>」を表示テキストに含めなくてはならないようなケースでは、それによってXSS脆弱性に対処する必要があるかもしれないことに気づくこと、XSS対策が必要になったら実際に対処できることが、結局は要求されることになる。
- 「<」や「>」も許容しなくてはならないという結論となり、それを踏まえてXSS脆弱性への対処を検討するという流れは、ちょうど「設計を行っているときにセキュリティについて考え」始め、「（場合によってはユーザ名ではなく表示方法に制約を加えるという形で）より堅牢なコードにする」というp.25の流れに対応するものと言えそう。
- こうした点（セキュリティへの知見や嗅覚が不要になるわけではないという点）は、p.28の「設計を意識するアプローチに従来のアプローチや**セキュリティへの明示的な意識を加えて補足する**」という記述からも伺える :+1: :+1::+1::+1:
- よく言われる「安易にString使うな」というのがよくわかる話。

- > P.25 そして、ここで注目して欲しいのが、ここまでの流れの中で、セキュリティについてまだ考え始めてもいないということです。
- あくまでユーザ名とはどんな文字で構成されているべきなのか、をちゃんと突き詰めて考えていった結果、セキュリティが向上している。 :+1: :+1::+1::+1::+1:

- > P.26 ビジネスに関する機能とセキュリティに関する心配事とのあいだで起こっていた衝突がもはや存在しなくなることを意味します。なぜなら、両者の違いがなくなるからです。
- とても良い話。セキュリティは難解なものだと思っていたのが、設計と同一化できるので、知識負荷がだいぶ減る:+1:
- セキュリティは専門家だけのものじゃない、民主化されていくということか

- > ソフトウェア開発の中で設計は自然と行われることである - p.26
- 本書での「設計」が指す範囲は、p.13~15を参照
- > 本書では、「どのような行為が設計の行為なのか？」という質問の答えは、ソフトウェア開発で行われるすべての行為が設計の行為であり、これらすべての行為が設計プロセスの一部として行われていると考えています。(...)そして、これらすべての行為で共通していることに、意思決定を能動的に行っている、ということがあります。(...)設計とは、どのようにシステムを構築するのか、ということを導き原則であり、それは、コードからアーキテクチャまですべてのレベルに適用できるものなのです。 - p.15
- どのようにコードを書くのか、どのようにビジネスロジックを表現するのか、どのような構造にするのか、これらの検討と決定は、本書においてすべて「設計」である
- 「設計」の範囲として、本書の定義より狭いものを想像してしまうと、想像した内容によっては認識の齟齬が起きかねないので、改めて本書で言うところの「設計」を確認しておいた方が良さそうな箇所。:+1::+1:
- 本書のように「設計」の範囲を定めるなら、いわゆる「動けば良い」という態度も、「動くことだけが唯一の価値判断基準であって、その仕組や表現様式や構造は、考慮に値しない」という「意思決定を能動的に行っている」、という点で「設計」の範囲に含めることもできるだろう（「設計を考慮しない」という意思決定、設計判断）:+1::+1::+1:
- だとすると、本書のように「設計」を定めた場合、それは「自然と行われる」というよりは、ほとんど不可避な行為であるようにも見える（[哲学的ゾンビ](https://ja.wikipedia.org/wiki/%E5%93%B2%E5%AD%A6%E7%9A%84%E3%82%BE%E3%83%B3%E3%83%93) のような開発者を考えない限り）

- > P.28 そのため、ユーザ名をJavaの標準に含まれているString型で表現することは、設計として未熟なだけではなく、完全に間違ったことになるのです。そして、このような概念を正確に正しく表現することはどのような開発者であっても自然と行えることであり(後略)
- [discord](https://discord.com/channels/432531367427964929/911610565103845387/929339256202227743)
- (自分の観測範囲だけかもしれませんが)いわゆる値オブジェクト的にクラスとして自然に切り出せる開発者の方が少数派のような...:+1::+1::+1::+1::+1::+1::+1::+1::+1::+1::+1:

- > P.26 セキュリティに関するタスクはバックログに追加されたとしても、そのタスクに割り振られる優先度は他の実施されなければならないタスクと競わなくてはならなくなってしまいます
- [discord](https://discord.com/channels/432531367427964929/911610565103845387/929341901344235522)
- この本を読み始めて、セキュリティの脆弱性を作らないためのシフトレフトをいかにしてしようかと考えるようになりました。セキュリティのバックログアイテムの優先度がビジネス要求の優先度と衝突して進捗しない問題よりも、そもそも自分の経験則だとセキュリティのバックログの作り込みが後工程になることが問題なんだと考えるようになりました。:+1::+1::+1::+1::+1::+1::+1::+1::+1:
- セキュリティのバックログを作り込めるのは、だいたい機能性のテストをしながらバグフィックスをして、コードフリーズをした後に OWASP ZAP のようなツールで全体検査をするときですから、意識下で優先順位が下がるというより、検査が後回しになることが多い印象を持っています。そこで例えば、SonarQubeのような静的解析ツールをビルドパイプラインに組み込んでいると、人によるQA開始前にバックログ化できるから、セキュリティ品質のシフトレフトになる＝優先順位を議論できるリードタイムを得る、ことになりそうだなあと思いました。:+1:
- 設計時にドメイン知識に関心を持ち、製品仕様を点検しながらコードに落とし込んだり、早期に静的解析ツールにかけて機械による検査の補助を受けたり（第８章のデリバリ・パイプラインはこの辺りの話になっていそう）、セキュリティの関心ごとをどう前工程で無意識的に仕組みとしてカバーできるか、というようなアイディアを考えていきたいと思いました。:+1:
- なので、
- > P.27 なぜなら、セキュリティに関する機能を追加するのか、もしくはビジネスに関する機能を追加するのか、というような判断はもはやしなくてもよくなるからです。
- は、さすがに少し極端な展開に、この第1章の時点では思っています。この後読み進める中で、また考えたいと思いました。:+1:
- 一方で、
- > P.28 なぜ、ユーザ名を表すのに、このような複雑な方を単純なString型の代わりに使うようにしたのでしょうか。結論から言うと、開発者は、ドメイン・エキスパートとの話し合いを踏まえて、ビジネスの概念をできるだけ正確に表現することが重要なことを認識したからです。
- は、今自分がDDDに関心がある流れの通り、とても大切な観点なのは間違いがないと思っています（セキュリティ脆弱性があることで、もっとも起こしたくない問題の一つは個人情報の漏洩で、それは外部からのクラッカーの攻撃だけでなく、実装仕様の不具合でも起こるわけですから）。そのような設計の発想があることを知っておくことで、よりビジネスドメインに関心を持つきっかけ、行動を起こしやすくなるのが思想を知ることのモチベーションだと思います。:+1:
- ~~下の1つ目の疑問に、インデントを1つ掘って書いてみた通り、この第1章の時点では、どうにもまだ「設計を重視すると、セキュリティの問題を気にしなくていい・そもそもバックログの優先度の取り合いにすらならないから」は極端な展開に思えたので、自分の考えを整理するために書いてみました。長々とすみません、例を簡易にわかりやすく示して思想の共感を作る導入部・第1章なだけだとは分かっているのですが...~~ すぐ下の *"1.4.3 システムに求められるセキュリティに関する全ての問題に対応できるわけではありません（そして、そのような意図もありません）"* とありました。「様々なアプローチを取り入れること」が大切、と言うことが主題に入っているんだと理解しました。設計によって取り除けるリスクがある、従来のアプローチと比較すると思考の負荷が下がる、と言う話なんだと理解しました。:+1::+1:
- > P.29 セキュリティ対策をどのように（How）行うのかを見る前に、なぜ（why）そのようなことをするのかについて理解する事が重要だと考えているからです
- やっと、うんうん、となりました。
- 「セキュリティリスクを減らすこと」は確かに「より良い設計をすること」や「よりプログラムの変更容易性を作ること、それによって開発のリードタイムを継続的によくすること」よりも、実はビジネス的に理解しやすい時代になってきているのではないかと思っています。前回の読書会で皆さんが対話されていたように、DDDを取り入れていきたいです、の目的に「セキュリティ」の観点が加わるのはビジネス視点と共有しやすい価値になると思いました。:+1::+1:

- > これにより、開発者に課せられていた知識の負荷は軽減され、従来のアプローチによる欠点の1つを回避できたことになります。 - p.26
- 軽減されたのであって、取り除かれたわけではない :+1: :+1::+1:
- 吟味の結果セキュリティ上の対処が避けられない場合は、それを感知する知見は依然として必要
- *常に*考える必要は無くなったかもしれないが、考える必要が*全く*無くなったわけではない
- ここで「回避できた」という「従来のアプローチによる欠点」としては、1.3.1(p.19)が対応する関係になりそうか

- > 設計を中心に考えることで、セキュリティに関して専門家だけではなく、すべてのステークホルダー（利害関係者）が議論に参加できるようになります。 - p.27
- 専門家以外もセキュリティに関する議論に*参加できるようになる*ことがここでは重要なのであって、ドメインエキスパート（あるいはステークホルダー）*がセキュリティ上の問題を特定したり指摘したりする*ことが重要なのではない :+1: :+1:

- > p.27 この中の、セキュリティはあとで対応できると考えてしまうことで注意しなくてはならないことは、必要とされるセキュリティ対策がすでに実装されたものと根本的に異なる設計となっている場合、セキュリティ対策を行えなくなってしまう可能性があることです。
- これが、恐ろしい。(しかも、似たような話最近聞いた...セキュリティ要件が、運用直前になって出てきた話):+1::+1:

- > 開発者は、ドメイン・エキスパートとの話し合いを踏まえて、ビジネスの概念をできるだけ正確に表現することが重要なことを認識したからです。つまり、ユーザ名は制約のないランダムな文字の集まりではなく、そのドメインにおいて正確な意味と目的を持って定義されている概念だったわけです。 - p.28
- ユーザ名として許されること、許さないことが明確に定義され、かつ、許されないことは厳密に拒否する実装となったことで、許されないこととして定められた範囲内で生じるセキュリティ上の問題も、自ずと対処されることになる
- 次の「ドメインを意識することでセキュリティに関するバグを意識せずに取り除く」へもつながる

- > P.29 真に安全なソフトウェアを作成するには、設計を意識するアプローチを取りながらも、同時に、ソフトウェア・セキュリティに関する様々なアプローチを取り入れることが必要なのです。
- [discord](https://discord.com/channels/432531367427964929/911610565103845387/929343871077453934)
- やっぱり設計だけでセキュリティを確保できるわけではないですね。割と妥当な見解に落ち着いてきました。 :+1::+1::+1::+1::+1::+1::+1::+1::+1:
- ようやく納得です。ここまで「設計だけでセキュリティを確保できる？？」と疑心暗鬼でした。
- 少なくともセキュア・バイ・デザインを適用することによって負荷が軽減されるイメージですね

## 疑問

- > P.22 ユーザ名から「<」や「>」などの文字が除外されているのは、Webブラウザ上で描画する際にそれらの文字が使えてしまうとXSS攻撃として使われる可能性があることを考えていたわけではない、ということです。そうではなく、「このコンテキストにおいて、ユーザ名とは何なのか？」ということを熟考した結果なのです。
- [discord](https://discord.com/channels/432531367427964929/911610565103845387/929336420903051354)
- 逆に「<」、「>」が含まれるようなユーザ名があると決定したときにはどうするべきだろう
- その場合に設計としてどう考慮するだろうとは自分も気になりましたが、例えば商品説明文など、「<」をはじめとする文字種類が多い入力値はそもそもよくあるわけで、そうすると結局画面表示時にサニタイジングするような旧来のアプローチに思考が持ってかれてしまうなあと思いました。なので、この第1章ではとてもわかりやすい例を示して、1つ1つのドメイン知識を高めるように、ビジネス要求や製品仕様に関心を持ち、コード設計に集中することを伝えたい導入部分として例を示したのかなと思いました。（あえての投げかけとしての疑問でしたらすみません）
- 含まれるようにするだけかと。 :+1: :+1::+1::+1::+1:

- > このような概念を正確に正しく表現することはどのような開発者であっても自然と行えることであり - p.28
- [discord](https://discord.com/channels/432531367427964929/911610565103845387/929338122410528788)
- 「表現」という範囲に限定された「設計」について、これがあらゆる開発者によって自然と行われているかは、いささか疑義あり:+1::+1::+1::+1:
- コードはあくまで処理の記述であって、そうした概念や概念の表現からは独立したものとして捉える開発者もありうるのでは
- 少なくとも、自身はそういう時期が確実にあった
- コードは処理の記述以外ではありえず、ましてや知識を表現するというような（有る種の）文芸的側面は持ち得ない、というような感覚
- 「コードが知識を表現するという側面を解しない/認めない者は、開発者たり得ない」という、かなり強い主張を暗黙的に前提としてしまっているようにも見える:+1::+1::+1::+1::+1:
- 実際の腹の内は知らないし分からないが、テキスト単独で読む限りは、そのように解する余地は生じてしまっている
- コードが知識を表現するのは当然では？

- > P.30 妥当性確認は次の順番で実施されなくてはならない…●サイズの確認
- 入力値の最大サイズは全て確認すべきなのですが、きちんと行うのは難しいような気がします。みなさん全入力値のサイズを確認してますでしょうか？
-------------------------------------

# 1.5 文字列、XML、そして、Billion Laughs攻撃への対応
## 目安の時間
- 40分

## 感想・気づき

- P.34のTIP、めっちゃ為になるな。

- Postlの法則、初めて知った :+1: :+1::+1:
- https://en.wikipedia.org/wiki/Robustness_principle
- 寛容な読み手（tolerant reader）パターンも
- https://martinfowler.com/bliki/TolerantReader.html
- https://fujiyamaegg.com/microservices-tolerant-reader/
- 基本は、データを受け取る側は自由度を高くして、データを送信する側はプロトコルに厳密に従う方が良いらしい。

- > この問題はXMLの構造的な問題として扱うのではなく、そのXMLを受け取るシステムの妥当性確認の問題として捉えるべきなのです。言い換えると、XMLを受け取るシステムは悪意のあるXMLのブロックをXMLパーサに解析させることなく拒否しなくてはならないのです。 - p.35
- 検証すべきはXMLの構造ではなく、システムにとって妥当な入力形式であるかどうか
- XMLとして不正な構造はXMLの構造的問題として扱うことで、すなわちパーサによる解析を通じて排除できるが、そのXMLが入力としてシステムにとって妥当であるかどうかは、パーサによっては解決しない:+1:
- というのも、そのXMLの構造がシステム的に不都合であっても、XMLの仕様としてはなんの不都合も無いことは十分ありうるから（Billion Laughsはその例）
- したがって、パーサの構文解析に依らない、そのシステムの都合や関心に即した妥当性検証が、構造の検証とは別に必要である:+1::+1::+1::+1:
- また、特にBillions Laughs攻撃のようなケースは、パーサがXMLの構文を解析し、エンティティを展開することによってその攻撃が有効になるから、構文解析をすることなく対応する必要がある
- XML構文として解析することなくXMLがシステムにとって妥当な形式化を検証する手段として、ここでは字句解析（XMLとして解釈される以前のテキストとしての解析）が提示されている

- > P.40 まず、もっとも疑わしいのはエンティティが展開される性質なのですが、その性質自体がエンティティを危険なものにしているわけではりません。そうではなく、結果として消費されるメモリーの量が問題なのです
- いろいろ深堀りをしていくと、根本的な原因が別にあるのがわかって面白い。:+1::+1::+1::+1::+1:
- パーサあたりのメモリ消費量を制限したとしても、結局同時に複数パーサが起動したら意味ないし、そのことについては第9章のところで取扱っているらしい

- 多層セキュリティのたとえ話で、家のフェンス、アラーム、家の鍵を同時に掛けるというのはすごくわかりやすい :+1:

- > P.39 システム間でデータをやり取りする場合、データを受け取る側は自由度を高くし、データを送信する側はプロトコルに厳密に従う事が良いとされているからです。このことは、Postelの法則や寛容な読み手（tolerant reader）パターンで述べられていることであり、この方法やパターンに従うことで、システムの統合が行いやすくなります。例えば、今回のように、必須ではない要素を無視するような寛容な確認にしておけば、仮に、XMLで必須ではない要素に変更があったとしても、XMLのデータを受け取る側は必須の要素の有無を確認することに関して影響を受けることはありません。
- [discord](https://discord.com/channels/432531367427964929/911610565103845387/929348315584286720)
- 勉強になりました。増田さんの「現場で役立つシステム設計の原則」で知った「契約による設計」と「防御的プログラミング」を思い出しました。プログラム間だけでなく、システム間においても活かせる考え方なんだなあと思いました。:+1::+1::+1::+1::+1::+1:
- また人と人のコミュニケーションも、重要でないことをいちいち気にされていたら、物事が進みにくいしなあと気付かされていて、例えば何かをレビューをする時にも、事前に何をなぜ重視しているかの観点をしっかりと示しておいた上で、それ以外の重要ではない点については寛容であれるべきなんだろうと思いました（その事前の明文化が難しいのだとも思いますが）。
- 解釈が妄想のようにかけ離れていきますが、「["他人に期待しない"は"課題の分離"](https://note.com/masuidrive/n/nacda15343971)」を思い出しました。データを話すシステムを作るのは、他人と他人、チームとチーム、だから、あながちこういう設計パターンの背景にそのパターンを利用する人を想像したり、逆にシステムの設計パターンが組織のコミュニケーションにフィードバックされることは多いよなあと、あまり本書と関係ないことを考えてしまいました。

- > 最終的には、OWASPが推奨するXMLパーサの設定、字句的内容の確認、処理場の制約をすべて組み込むことで、Billion Laughs 攻撃などの攻撃をすることが非常に難しくなります。(...)つまり、設計を安全なソフトウェアを作成するための第一のツールとして理容師、設計を意識することで、作成するソフトウェアの安全性を高められるようになるのです。 - p.42
- [discord](https://discord.com/channels/432531367427964929/911610565103845387/929350718467485756)
- p.28「設計を意識するアプローチに従来のアプローチやセキュリティへの明示的な意識を加えて補足する」と通ずる記述
- セキュア・バイ・デザインとは、「ソフトウェア設計の方法によって、セキュリティの問題を自然と解決できる」という思想ではなく、「セキュリティの手法だけでなく、ソフトウェア設計の手法も駆使してセキュリティ上の問題に対処する」という思想である、として理解するのが良さそう:+1::+1::+1::+1::+1:
- ソフトウェア関連のアプローチ総出でセキュリティの問題に対処するアプローチが「セキュア・バイ・デザイン」である、とも言えるか
- こうしてみると、「多層セキュリティ」という見出しも象徴的。セキュリティ手法**のみ**によってでもなく、ソフトウェア設計**のみ**によってでもなく、持ちうる手段の**すべて**を駆使してセキュアの実現を目指す態度:+1::+1::+1::+1:

- > P.43 セキュリティを実装すべき機能（feature）として見るのではなく、対応しなければならない心配事（concern）として見るようにする。.. 開発中に、セキュリティを最優先事項として常に考え続けるようなアプローチは現実的ではなく、より安全なソフトウェアを作成することに繋がる設計（design）のアプローチを採用する方が良い。
- [discord](https://discord.com/channels/432531367427964929/911610565103845387/929351939853004880)
- Userクラスのusernameは極端な例だと初めは思いましたが、モヤモヤと考えながら読み進め、改めてここでこのまとめを読むと、特にこの2つは印象的で大切な考え方なんだなあと1章を読み終えられました。
- > 従来のソフトウェア・セキュリティのアプローチは、開発者に対して、セキュリティの脆弱性について常に考えることを求める一方、ビジネス機能を実装することも同時に求めていたため、様々な問題が起きていた。
- 改めて、この課題はそうだと思い、一方で結果として得られるものが同じだったり、非常に近いものであるなら、セキュリティという大きな関心ごとを、設計・実装・テストなどいくつかに分割して中に隠しておいて、設計は設計をちゃんとしよう（それでセキュリティのリスクは減らせているんだ）と思って、あとでペネトレーションテストもするしと思えれば、それが良いんだろうなと思いました。:+1::+1:
- 例えば商品説明文を入力する画面UIの製品仕様を考えているときに、「"<" が入ってくるのか、XSSのチェックをちゃんとしなきゃ」と心配するより、その商品説明文がなぜ誰の何の課題を解決するのかを考える方が健全だよなあと思いました。:+1:
- ユーザーストーリーに基づく機能のことを考えているときは、機能のことを考える。一方でセキュリティが機能要件としてきた時には、心配事をちゃんと捉える、結局どっちも要求の背景（ビジネス的にどうしてその機能が必要なのかだったり、セキュリティ的には何が心配されているのか；でないとURL直接アクセスのケースを見逃す、前回の話）を知らないといけないんだなあと思いました。:+1::+1::+1::+1::+1:
- 設計レビューから得た知見も蓄積していくことが必要になるのかなと思いました
- https://dxcriteria.cto-a.org/b60ebadfbc084be99ffd0916009f2767

## 疑問

- > もし、このクラスにXMLの意味に関する分析も含めてしまうと、結局、それは、XMLパーサの処理をさせているのと同じことになってしまい、最初の問題に戻ることになるからです。 - p.37
- [discord](https://discord.com/channels/432531367427964929/911610565103845387/929344634335928400)
- ここで言う「最初の問題」は何を指すのか:+1::+1:
- 原文は `Because as soon as semantic analysis is added to a lexical scan, it turns into a parsing process, and that brings everything back to square one.`
- DeepL訳では `というのも、語彙スキャンに意味解析が加わると、すぐに構文解析になってしまい、すべてが振り出しに戻ってしまうからです。`
- ここでの「振り出し」とはなにか
- 「構文解析になってしま」うことで降り出しに戻ってしまうということであるなら、 ここでの「振り出し」は、処理の内容が構文解析であることと関わっているなにか
- この周辺で構文解析に関して言及があるのは、p.35の「この問題はXMLの構造的な問題として扱うのではなく、そのXMLを受け取るシステムの妥当性確認の問題として捉えるべき」という箇所
- これらのことから、ここで言う「最初の問題（振り出し）に戻る」とは、意味的観点からの解析を持ち込むことで、結局XMLの構造を解析する（例えば、エンティティのようなXMLの機能を使って、複数のemailが展開されないか、などを考え出すことになる）ことになり、その結果として問題を「XMLの構造的な問題」として捉える段階まで戻ってしまうことを指すと思われる:+1::+1::+1:

- XMLのエンティティの機能の利便性をあまり理解していない…。同じ値を繰り返し使うような場合は、ファイルサイズを小さくできるということでいいのかな。

- XMLパーサの部分、customerの特定のkeyだけ受け入れる部分はどのレイヤーでやるべきか。
- XMLパーサの技術的なところはGateway、Driver層的なところか。
- でもCustomerというドメイン的なルールもあるしなぁ