セキュア・バイ・デザイン 端書き＆目次
===
###### 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:

---

# 本書によせて〜表紙のイラストについて（P.iii〜P.xvii）
## 目安の時間
- 60分

## 感想・気づき

- P.iv `undefined` とか `null` で登録するのはエンジニアとしての義務ですよね

- > P.iv 通常であれば、単なる妥当性確認の欠落として扱われるバグを、過度の文字数のデータ入力をすることでアプリケーション・サーバをクラッシュさせるDoS攻撃につながる脆弱性として報告してきたわけです
- わかりすぎる、そのシステムの理解度で報告するレベルの判断が違いそう

- > ドメインの概念やビジネス・ルールをいかに忠実にモデリングしているかに懸かっています - p.v
- ここでの「忠実」は「写像を作れ」という意味としてではなく、それらを正確に反映したモデルを定義せよ、というぐらいの意味として解釈:+1::+1:

- > P.v セキュリティは開発者が選択したデータの型の中にあり、そのデータの型をどのようにコードで表現するかに懸かっています。同様に、セキュリティは開発時に使われるドメインの用語の中に有り、ドメインの概念やビジネス・ルールをいかに忠実にモデリングしているのかに懸かっています。そして、セキュリティは、ビジネス・ドメインとそのドメインに属する顧客の要望に応えるために開発したツールとのあいだにある認識の差を減らすことで得られるものなのです。
- [discord](https://discord.com/channels/432531367427964929/911610565103845387/916663695747211294)
- セキュリティをそういう風に考えたことがなかったので、とても新鮮:+1::+1::+1::+1::+1::+1::+1::+1:
- 著者がどうしてそう思ったのかは、本書を読み進めていけばわかるんだろうな
- 基本データ型**そのまま**使うのが怖くなりますね。入力(コンストラクタやメソッドの引数)が正しいか必ず判断しないとね

- Passwordクラス内のコンストラクタ内で文字数制限を掛けて、不正なインスタンスが作られないようにするっていうのは、コーディング時のバグを発生させないという理由でやったほうが良いと認識していたが、そこにセキュリティの観点が拡張される感じがしている:+1::+1::+1::+1:

- > こうして、ドメイン・エキスパートはシステムを作りあげていく中で生じる間違いや矛盾や思い込み、さらには、現実を反映していない様々な部分を指摘するようになります。 - p.v
- [discord](https://discord.com/channels/432531367427964929/911610565103845387/916666954062901349)
- このあたり、「ドメイン・エキスパートもそうした箇所を気づき指摘できるようになる」というのが肝要なのであって、「そうしたことを気づいたり指摘するのはドメイン・エキスパートの仕事である」という主張はしていない、というのは注意して読んでおいた方が良いかも:+1::+1::+1::+1:
- DDDまわりでよく見る「そんなドメイン・エキスパートなんていない」話を回避する意味で
- エンジニア自身がそうした指摘をすることは引き続きして良くて、エンジニア以外にもそうした可能性が開かれることを強調しているのだろう
- なぜそこだけ強調しているかと言えば、「エンジニアがそういう指摘をするのは当たり前でしょ」という前提があるとか、そこがキャッチーだから強調しただけとか、色々想像はできる

- > 浅い設計（shallow design）
- この用語を積極的に使っていきたい :+1::+1:

- > P.vi 唯一信頼できるエラー・ハンドリングの方法は「クラッシュさせることだ！（Let it crash!）」
- なるほど。これがFail fastの話に繋がっていくのだろうか:+1:
- これはActorプログラミングの基本原理のひとつです。

- > p.vi この「クラッシュ させること」を避けることで経験する複雑さ
- [discord](https://discord.com/channels/432531367427964929/911610565103845387/916669483094016041)
- エラーハンドリングがコードの大半を占めていて、本質的な処理が見えにくくなったり、エラーハンドリングが複雑であるがゆえにバグを埋め込んでしまったりすることはしばしばあって、そういうところからセキュリティホールが生まれてしまうこともある。クラッシュさせられるなら、無理を通すよりもその方が安心できる。:+1::+1::+1:

- > P.？(PDF版P.2) プログラミングの質を高めることで、セキュリティを向上させる
- この一文にこの書籍の本質・コアが詰められている感じました。大変良いキャッチフレーズかつ明快な言葉だなと思います。:+1::+1:

- > また、私たち開発者はコンポーネントが小さいほどテストが簡単になることを知っています。(...)しかしながら、私達は何百何千もの小さなコンポーネントで構成されたシステムを稼働し、そうすることで、どのような影響がセキュリティにあるのか、ということについては、最近、理解し始めたに過ぎません - p.vi
- 信頼できる小さなコンポーネントを集めたからといって、自ずからシステム全体がセキュアになるとは限らず、実際どうなるかは非自明で、そしてそうした知見は最近ようやく溜まってきたに過ぎない、というお話
- 「全体は部分の総和以上である」的なアレ

- > P.vii ここで言う良い設計とは、コードから製作者の意図が伝わるものであり、製作者の考えが理解しやすく、かつ、直感的に扱えるように捉えたもののことです
- [discord](https://discord.com/channels/432531367427964929/911610565103845387/916665949787131915)
- 完全同意:+1::+1::+1::+1::+1:
- 本書ではそのために実践していったプラクティスが、セキュリティの向上にも繋がっていくという話がテーマの一つだと思う:+1::+1::+1::+1:
- 何も考えていないのがコードから伝わってきているプロジェクトをどうにかするエッセンスが書いていれば嬉しいな。

- > P.viii 2009年 ドメイン駆動セキュリティという名前でこのコンセプトが生まれることになりました
- https://www.diva-portal.org/smash/get/diva2:945707/FULLTEXT01.pdf
- これのことかな
- > 設計においてまず第一に考えなくてはならないことはセキュリティである
- セキュリティと聞くとAOPなど一部のソースコードでアプリ全体をコントロールするものだと思っていたけれど、あらゆるコードで意識しなくてはならないものなのだと気づいた

- > P.x インターネットは既に答えを知っている、もしくは、何を質問すべきなのか既に知っている場合に有意義なツールなのだと思っています。一方、書籍は1つのテーマに沿って書かれているため、必要な情報がまとまっており、異なるトピックであっても、関連性のあるものはそのつながりが明白になっています。
- 本書に関係ないけど、この翻訳者の考えに同意。1から体系だてて知るには書籍のほうが都合がよい:+1::+1::+1::+1:
- 完全に同意する。図書館が最強なのでは？と思う。:+1::+1:

- > ベスト・プラクティスは技術の発展や環境の変化によって変わっていくものです。しかしながら、そのベスト・プラクティスは前の時代のベスト・プラクティスの反省から生まれたものや状況の変化に対応できるように改善したものがほとんどだと思っています。そのため、前の時代を知らなければ、なぜ、今、このようなことをしているのか、という疑問が出てくることは今の時代から開発者となった人には少なくないと思っています。 - p.xi
- 本筋には関係ないけれど、某か「知識を学ぶ」「知識をアップデートする」という上で大事なことを書いてくれていると感じた
- 前世代の情報を「古い」とか「使わない/使ってない」なんて理由で「上書き」してしまうと、後からの追跡（＝「前の時代を知る」こと）ができなくなってしまう
- 「知識のアップデート」は、前時代・過去からの*積み重ね*:+1:

- > P.xii 本書の第一の目的となるのは、ソフトウェアの設計とセキュリティがどのように結びつくのかを探求していくことです
- 本書の目的来たー！:+1:
- これを忘れずに読んでいこう:+1::+1::+1::+1::+1:

## 疑問
- p.iv 「Julie undefined」でどういうかたちでクラッシュしたのだろう:+1::+1::+1::+1::+1:
- [discord](https://discord.com/channels/432531367427964929/911610565103845387/916658595809087528)
- `undefined`が意味を持つ言語といえばjavascriptが浮かんだが、iPadで動作していたことを考えると、Objective-C or swift？(それらの言語で `undefined` が特定の意味を持つかは知らない)
- cordovaとかReact Nativeのようなweb技術ベースのアプリという線もありそうだけど、単に文字列をパースしたりする範囲では、jsの場合にはクラッシュの原因にはならなさそうな気がする

- > P.v さらには、関連するコードやテストなどがドメイン・エキスパートにとって分かりやすいものになっていれば、その中に潜む問題をより簡単にドメイン・エキスパートが見つけ出せるようになるからです
- [discord](https://discord.com/channels/432531367427964929/911610565103845387/916651607519813643)
- ドメイン駆動設計をやっていって、こういう場面に遭遇された方がいたら、話を聞いてみたい:+1::+1::+1::+1::+1::+1:
- コードまで読んでくれるドメイン・エクスパートは出会ったことがないし、いるんだろうか？と懐疑的:+1:

- > P.v セキュリティはビジネス・ドメインとそのドメインに属する顧客の要望に応えるために開発したツールとのあいだにある認識の差を減らすことで得られるものなのです。
- [discord](https://discord.com/channels/432531367427964929/911610565103845387/916660011818688562)
- 「認識の差」というKeyWordが出てくるが、この「認識の差」とは具体的にどのようなものを示しているのか？何となくはイメージできるが、具体的なイメージがあまり湧かなかった。:+1::+1::+1::+1:
- モデルと実装が乖離していないというような意味かと思いました。

- > P.v この認識の差が減るにつれ、セキュリティに対する危険性は全般的に取り除かれることになります。と言うのも、開発者がシステムを作り上げるためにモデリングを行った際に抽出された概念やプロセス、さらには、関連するコードやテストなどがドメイン・エキスパートにとって分かりやすいものになっていれば、その中に潜む問題をより簡単にドメイン・エキスパートが見つけ出せるようになるからです。
- [discord](https://discord.com/channels/432531367427964929/911610565103845387/916662222799896586)
- この「認識の差」を減らすことで、ドメインエキスパートにとって分かりやすいものになり、その結果セキュリティに対する危険性を取り除けると説明されている。この点について、まだ納得感が薄い。ドメイン・エキスパートは業務に詳しい人材であってセキュリティに対する知見があるわけではないのに、セキュアになるというのはイマイチ信じられない。。。:+1::+1:

- > P.vi〜vii > 本書は、ドメイン駆動設計の実践者達が知識の咀嚼（knowledge crunching）と呼ぶドメイン・モデリングの作業に置けるまさに中心となる部分に焦点を当てており
- 少しズレるかもしれないですが、知識の咀嚼をするのに大事なプロセスってなんだろう:+1:
- Evans のDDD本の１章が「Crunching knowledge」なので、そこを指しているのではないかと思わます。だから、索引や本文にも詳細がなさそうなので、Evans本を見てねと思いました。

- > p.v 設計において第一に考えなくてはならないことはセキュリティである:+1::+1:
- [discord](https://discord.com/channels/432531367427964929/911610565103845387/916655504758013992)
- 社内の設計レビューで、レビュープロセスが属人化しているので、どうすればいいんだろうってなっています:+1::+1::+1::+1::+1::+1:
- AWS上の構成でセキュリティグループの一部でフルオープンされているとか、インフラの側面はレビュープロセスが成り立っているけど、アプリケーションを含めてってなるとプロセスが回っていない、、、
- セキュリティのことは設計のときにも考えるけど、第一にかんがえるようなことはしてないなー

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

# 目次（P.xviii〜P.xxi）
## 目安の時間
- 20分

## 感想・気づき

- 2章「『ハムレット』の悲劇」、『ハムレット』そのものはあんまり関係ないのか……
- 『ハムレット』の内容となにか絡めてくるのかと、わくわくしてしまった

- 14.1章のセキュリティを意識したコード・レビュー、めっちゃ気になる
- あまり自分の中でセキュリティ観点でのコード・レビューできている気がしないので

- > P.xviii〜xxi 3部構成がSimon Sinekのゴールデンサークル理論に基づいた構成になっており、非常に魅力的に感じました。:+1::+1:
- [discord](https://discord.com/channels/432531367427964929/911610565103845387/916668635764903946)
- 第1部-導入編：WHYにあたる。セキュア・バイ・デザインがなぜ重要なのか？その理由を解説している。まず意義・理由を解説することで、取り組むモチベーションを理解することができ、この考えに対して納得感を得られる。
- 第2部-基礎編：HOW：セキュア・バイ・デザインをどのように取り組むのか、その方法論を解説している。コーディングやパイプライン、クラウド設計まで広い範囲について記載されているのが、素晴らしいなと思った。
- 第3部-応用編：WHAT：レガシー・コードの改善など、より具体的な手法を解説している。リファクタリングの手法を解説することで、すぐプロジェクトに適用できる点が良いと思った。
- ゴールデンサークル動画
- https://www.ted.com/talks/simon_sinek_how_great_leaders_inspire_action/transcript?language=ja

- P.xxi 12章に「レガシー・コードへの適用」の章があるのは熱い
- [discord](https://discord.com/channels/432531367427964929/911610565103845387/916667836447997972)
- 12.5 でDRY の誤解に触れている辺り神。 :+1: :+1: :+1: :+1: :+1::+1::+1::+1::+1:

- 2章で浅いモデリング、深いモデリングの話が触れられている。エヴァンス本では8章ブレイクスルーで1章分丸ごと説明されていたけど、少ないページ数で説明しきれるんだろうか

- > P.xxi 過保護な実装
- 最近、過保護のカホコみたので個人的ホットワード
- 防御的プログラミングめっちゃやっている感じなのかな？

- > P.xv ソースコードについて
- 書籍のコードでJavaを選択した判断理由が書かれていて、面白いなって思った
- 書籍書く上での技術選択のような気がした
- C言語の系統を扱っている技術者のことも考えての選択理由って思うと、書籍書く人って、ほんとすごいと思った

- > P.xvi表紙のイラストについて
- イラストについてこんな説明している本初めての見たような気がする

## 疑問

- 7.1章の部分的不変エンティティってなんだろう？　ドメイン駆動設計の文脈でそんな単語あったっけ
- https://speakerdeck.com/masuda220/domeinqu-dong-she-ji-toimiyutaburunakurasushe-ji?slide=4
- エヴァンス本では出てこなかった概念（もしかしたら違った言葉として出ているのかも）

---