セキュア・バイ・デザイン 第4章 安全性を確立する実装テクニック
===
###### 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分 | 次回開催日と読む範囲決めてクローズ | |

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

---

# （お試し運用）この用語がわからない、難しい
※ここに本を読んでわからなかった用語を書いていってください。
※私もわからなかった、という方がいれば、:+1:をつけてください

- （例）集約とは？

- 並列(parallel)アクセスと並行(concurrent)アクセスの違い (感想気づきにもありますが):+1::+1:
- ある時刻において、複数のプロセスが計算途中状態にある　→　並行
- ある時刻において、複数のプロセスが実行状態にある　→　並列
- 並行プログラミング入門の1章がわかりやすいと思う。

---

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

## 感想・気づき

- > p.127 開発者にとって、優先事項と締め切りは常に付いて回るものです。場合によっては ～略～ …本当にそうでしょうか？
- [discord](https://discord.com/channels/432531367427964929/911610565103845387/949627937232134184)
- 質とスピードはトレードオフではない、という話を思い出した。[質とスピード ソフトウェア開発の典型的な誤解を解く](https://speakerdeck.com/twada/quality-and-speed-2020-autumn-edition):+1::+1::+1::+1::+1::+1::+1::+1:

- > p.127 この章では、ソフトウェアが安全になるような設計をすることは、脆弱で悪用しやすいソフトウェアを構築することよりも、なぜ時間が掛からないのか、ということを考えていきます
- むしろ脆弱なソフトウェアを作るほうが時間が掛かる、ということなのか。:+1::+1:

## 疑問

---

# 4.1 不変性（immutability）
## 目安の時間
- 40分

## 感想・気づき

- > p.131 データの完全制（integrity）はデータのライフサイクルのすべてにおいて常に正しい状態を保つようにする性質のことです。もう一方のデータの可用性（availability）は想定しているパフォーマンス・レベルでシステムのデータを取得できることを保証する性質のことです。
- [discord](https://discord.com/channels/432531367427964929/911610565103845387/949639168517111849)
- 1章あたりでも書いてあったけど、ぱっと見て可用性はセキュリティ品質に関係するんだろうか？　って思うけど、セキュリティ品質を高めた上で欲しいデータにアクセスがしにくい（タイムアウトする）状況は意味がない。セキュリティ品質を高めた上で可用性もちゃんと担保する。
- Dos攻撃を考えると、可用性もセキュリティ品質に含まれそう。:+1::+1::+1:
- CVEスコアにも、可用性含まれますしね。:+1::+1::+1:
- 逆に可用性が低いけどセキュアだと言える状況ってあるんでしょうか？

- > p.128 そして、この可用性はシステムをDoS（Denial of Service）攻撃から守る際の重要な要素となります。
- [discord](https://discord.com/channels/432531367427964929/911610565103845387/949633928120135690)
- そうなの？:+1::+1::+1::+1:
- スレッドロックが起きるようなコードだと、いっぱいリクエストが来ると辛くなる

- > p.129 経理部門から、銀行振込を選択した信用スコアの低い顧客がたくさん存在する
- 不変条件が破られているというお話か

- > p.129 次に目を向けてほしいのは、各メソッドに synchronized 修飾子を付けてフィールドの値が同時に変更されることを防いでいる点です。
- [discord](https://discord.com/channels/432531367427964929/911610565103845387/949636875163926589)
- 「想定レベル内」の負荷試験で出た問題をとりあえず解消する、とかで実施されてしまいそうな気がする。このケースに限らず、「なんか良さそう」で設定を入れず、入れる前にどう悪くなることがあるかは考えたい。:+1::+1::+1:

- > p.132 並列（parallel）アクセスよりも並行（concurrent）アクセスによって引き起こされるスレッド競合のほうがコードからその原因を簡単に理解できる傾向があります
- 並列、並行...？:+1::+1:
- ここがわかりやすかった(https://qiita.com/Kohei909Otsuka/items/26be74de803d195b37bd#%E4%B8%A6%E8%A1%8C%E3%81%A8%E4%B8%A6%E5%88%97%E3%81%AE%E9%81%95%E3%81%84)
- 並列 = ある時刻に、複数のスレッドが同時に実行状態にある
- 並行 = ある時刻に、複数のスレッドが同時に計算途中状態(待機状態も含む)にある
- 並列の場合、複数の処理が同時に実行されている状態だが、並行の場合、必ずしも複数の処理が同時に実行されているとは限らない
- スレッドAが処理を実行している時、同時にスレッドBも処理を実行しているなら並列かつ並行
- スレッドAが処理を実行している時、スレッドBが待機状態(だが、スレッド自体は完了しておらず、計算途中状態)であるなら、並列ではないが並行
- スレッドAが待機状態で、スレッドBも待機状態の場合は並列ではないが並行
- スレッドAが計算完了後で、スレッドBがそもそも起動開始前なら、並列でも並行でもない
- [並行プログラミング入門](https://www.oreilly.co.jp/books/9784873119595/)が詳しい(p.3-6)
- 状態数が多いと理解しにくい、複雑

- > pp.132-133 しかしながら、新たにロックの仕組みを導入することは設計に複雑さをもたらすことになり、さらに、開発者はより多くのことを覚える必要が出てくるため、ここのようなことはできるだけ避けたほうがよいでしょう。
- わかる。なるべく設計はシンプルに保ちたい。:+1:

- > pp.135-136 creditScoreフィールドの初期化をsetCreditScoreメソッドを介して行なうことですが、このような実装をしてしまうと、最大一度でも呼び出されない（at-most-once）という振る舞いを保証しない限り、信用スコアの値が好きなときに何度でも変えられてしまうことになります。
- setterがなんで悪いのか？　というのを端的に説明できる
- ここで指摘されているのは、setterの問題点というよりは、「不完全なコンストラクタ + setterによる事後的な充足」という構成の問題点、と整理するのが正確な気はする
- setter(任意の値でフィールドを交換できるメソッドとする)の問題点ないし懸念点は、at-most-onceの話よりも、並行/並列処理において複数スレッドで同じオブジェクトが参照されてしまう点からの方が、より一般に指摘できそう
- setterを許容できる場合は言及されていなかったと思いますが、許容できる場面ってどの様な場合が考えられるでしょうか？

-　最近の言語は、参照渡しが基本なので（C言語は値渡しが基本）ついついこの手の問題をスルーしがちなんだよなぁ。参照渡しが基本の言語では、不変性は本当に有効だと思う。 :+1::+1:

## 疑問

- > p.132 並列（parallel）アクセスよりも並行（oncurrent）アクセスによって引き起こされるスレッド競合のほうがコードからその原因を簡単に理解できる傾向があります
- [discord](https://discord.com/channels/432531367427964929/911610565103845387/949630829418663936)
- どういう理由で、そうなんだろうか:+1::+1::+1:

- > p.132 複数のスレッドがそれぞれ異なるsynchronizedメソッドに同時にアクセスしようとした場合、固有ロックを取得できなかったスレッドはすべて意図せずブロックされてしまうことになるのです
- オブジェクト単位で固有ロックを発生させているってこと？

- リスト4.4のCreditScoreクラスでは、信用スコアの計算までが責務となっていたが、リスト4.5では計算の責務は別に移していて、CreditScoreは不変な状態にしたってことか
- 計算の責務はどこに行ったかまでは本書には書いてないけど、ドメインサービスとかに移してるのかな

---

# 第4.2 契約（contract）を使った速やかな失敗（fail-fast）
## 目安の時間
- 40分

## 感想・気づき

- > p.139 まず、事前条件とは、1960年代後半におけるコンピュータ・サイエンスの理論研究で出てきたものであり、その中でも特にHoare卿（Sir Charles Anthony Richard Hoare）によって提案されたHoare理論が有名です
- https://ja.wikipedia.org/wiki/%E3%83%9B%E3%83%BC%E3%82%A2%E8%AB%96%E7%90%86

- > p.139 セキュリティに関する問題の多くは責任の所在の曖昧さによって起こる傾向があります
- この意識は無かったけど、考えてみるとバグが発生して調査が難航するのは、責務の切り分けの曖昧になっていて特定が難しいってことが多いかもしれない:+1:

- 表4.3と表4.4の事前条件と事後条件は、どっちが正解というわけではなくて、どちらかに寄せるべきということを示しているのだと理解
- クラスに寄せる（表4.4）ことが多そう？

- > p.143 Bertrand Meyer氏によって設計されたプログラミング言語Eiffelでは、このサポートがプログラミング言語自体に組み込まれています。
- Eiffel初めて知った。めちゃくちゃ面白そう
- https://www.eiffel.org/doc/eiffel/ET-_Design_by_Contract_%28tm%29%2C_Assertions_and_Exceptions
- http://geolog.mydns.jp/www.geocities.co.jp/SiliconValley-Sunnyvale/5725/

- > p.145 NOTE：ここで重要なのが、例外を発生させた不正なデータを繰り返し使わないことです。例えば、受け取った不正なデータをログに出力するようなことをしていると、そのことが脆弱性となることがあります。このことについては、第9章にて、詳しく見ていきます。
- [discord](https://discord.com/channels/432531367427964929/911610565103845387/949641049561792542)
- これってかなり重要な情報では。結構やっていそう…。:+1::+1::+1::+1::+1::+1::+1:

- p.146 TIPにある少なくともnullの値を確認するのは、最近はnullセーフな言語もあるので意識しないまでも勝手に出来ているってのはありそう

- > p.148 また、読者の中には、現在、子猫の名前に「s」が含まれていることを確認するコードが2箇所にあることに気付いた人もいるかと思います。
- [discord](https://discord.com/channels/432531367427964929/911610565103845387/949648221041475625)
- これ気になっていた。ドメイン・プリミティブというのが第5章で紹介されるらしい:+1::+1::+1:

- p.144　リスト4.7を見る限り、事前条件の確認＝引数チェック と見受けられるが、引数チェック以外の方法で事前条件の確認をするパターンがあるのかイメージできなかった:+1::+1::+1:
- [discord](https://discord.com/channels/432531367427964929/911610565103845387/949645670216769556)

- > p.150 この速やかな失敗は、より大きな規模のソフトウェアにて、受け取ったデータを利用しても問題ないかを確認する際に、さらに効果を発揮する物です。
- [discord](https://discord.com/channels/432531367427964929/911610565103845387/949648765034315876)
- 何を欲してるかも読みやすいので、読みやすさでも幸せ。:+1::+1:

## 疑問

---

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

# ===================後半(3/19)はこちらから===================

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

# （お試し運用）この用語がわからない、難しい
※ここに本を読んでわからなかった用語を書いていってください。
※私もわからなかった、という方がいれば、:+1:をつけてください

- （例）集約とは？

# 第4.3 妥当性確認（validation）
## 目安の時間
- 90分

## 感想・気づき

- > p.151 また、妥当性確認（validation）は様々なことを意味する傾向のある言葉でもあります。
- [discord](https://discord.com/channels/432531367427964929/911610565103845387/954711252943372318)
- 読んでいて妥当性確認の意味が、人によってブレているってこと初めて知った。:+1::+1::+1::+1::+1::+1::+1::+1::+1::+1:
- 自分はフォーマット確認くらいだと思っていた
- バリデーションという単語から想像するのは「字句的内容」「構文」のチェックくらい。普段コーディングする際に「オリジン」のチェックなんて意識できていなかったな。。:+1::+1:
- とはいえオリジンの確認は、各所ですべきものではなくどこかで共通処理として行うべきだと思う:+1:
- p.153の注釈12。怖い。ボットネットも課金して借りることができるのか:+1::+1:
- 内部サービスの場合、IPアドレスを制限をするっていうのも、妥当性確認の1つっていう意識がなかった:+1::+1::+1::+1::+1::+1::+1:
- [discord](https://discord.com/channels/432531367427964929/911610565103845387/954715140413071400)
- 攻撃とはちょっと違うけど、正当にユーザー登録をしてデータを盗み出すっていう手口もあるなって思った:+1::+1::+1::+1::+1:
- [discord](https://discord.com/channels/432531367427964929/911610565103845387/954717126491512872)
- バッチとかで何度もアクセスしてデータを取りにいったりするので、○分で△リクエストまでっていう制限を掛けていく対処をしたり。
- スクレイピングなんか割とこの範疇に近いかも。
- > p.157 もし、注文のデータ・サイズが1GBもある場合、これは適切なデータなのでしょうか？
- [discord](https://discord.com/channels/432531367427964929/911610565103845387/954720945917001838)
- 「将来大きいデータが来るかもしれない(今は数10KBいないだけど、数100KBくらいも)」として値の上限を決めないと、セキュリティ的にも対処できる機会を失ってしまうんだなぁ。:+1::+1:
- > P.159 この膨大なサイズの文字列を正規表現エンジンが読み込んでしまい、そのまま負荷の高い処理を始めてしまうことです。
- [discord](https://discord.com/channels/432531367427964929/911610565103845387/954719730172837888)
- 正規表現でも同じチェックはできるけど、データ量を減らして負荷を下げることがまずは目的:+1::+1::+1::+1::+1::+1::+1:
- > p.164 リスト4.19

        public ISBN(final String isbn) {
            notNull(isbn);
            inclusiveBetween(10, 10,isbn.length());
            isTrue(isbn.matches("[0-9X]*"));    ①  
            isTrue(isbn.matches("[0-9]{9}[0-9X]"));    ②  
            isTrue(checksumValid(isbn));    ③  
            this.isbn = isbn;
        }

- リスト4.20 で否定されているけれど、意外と目的に合わせて多段階で正規表現判定するのもありかもと思った。:+1::+1:
- > p.156 攻撃者が悪意を持ってアクセスキーを利用してきた場合、その攻撃者をブラックリストに一時的に含めることも可能です
- [discord](https://discord.com/channels/432531367427964929/911610565103845387/954723603952336916)
- 悪意を持って利用してきたってことを分かるようにする仕組みって難しそう:+1:
## 疑問

- > p.152 一般的に、データ長の確認などのように負荷が低い妥当性確認を早めに行い、データベースの呼び出しが必要となるような負荷の高い妥当性確認を後で行なうのが好ましいです。こうすることで、より負荷のかかる高度な妥当性確認を不必要に実施することを妨げるようになるのです。
- [discord](https://discord.com/channels/432531367427964929/911610565103845387/954707862704242698)
- 1章あたりで字句的内容は構文より早くやったほうがいい、みたいなことを見た気がする。字句的内容の方が比較的軽い処理なんだろうか？:+1:
- 負荷が少ない順にやる理由として、負荷の早めのところで妥当性確認が失敗したらすぐに結果を返せる、というのが前提にあるような気がしている。だけど、全種類の妥当性確認をするニーズがあったらあまり順番性には意味がないのでは？
- さすがに、正しくエンコードされていなかったり、フォーマットに沿っていなかったら、意味解析はできないからすぐに結果返すのだろうけど。
- 字句的解析の目的は、データの構造は関係なくて、データに含まれている文字が正しいかを確認する、というのはわかったが、XMLのような複雑だった場合は、字句やトークンと呼ばれるものに分割するのは、後の「構文（syntax）の確認」に踏み込んでいるようにも見える :+1:
- [discord](https://discord.com/channels/432531367427964929/911610565103845387/954704790045216780)
- > 言い換えると、XMLを受け取るシステムは悪意のあるXMLのブロックをXMLパーサに解析させることなく拒否しなくてはならないのです。(...)前述した妥当性確認(validation)の流れの中で2番目に実施される字句的内容(lexical content)の確認がその対応を行う部分となります。(...)この作業は受け取った文字の集まりであるデータを一連のトークン（1単位の字句）に変換するシンプルな作業に過ぎず、順序や意味を分析する必要はないからです - p.35
- 1.5.5で↑のような説明がありますね。本書で言うところの字句解析は、XMLの内容をXMLの仕様に従って解析し意味内容を把握すること(ex. ENTITYの展開など)は含まず、ただ文字列としてアプリケーションが認める型式に従っているかどうかの検証を指すという感じかと。
- 他方で、「構文(syntax)の確認」は何をカバーするのかについて、ENTITY等XMLの仕様に基づいてそのXMLドキュメントがどのような「意味」を表現しているかを理解し、それが諸々のルール（XML文法だったり、アプリケーションが許容するデータ内容だったり）に適合するか確認すること、という感じになるかと思います。
- XMLの 整形式 (well-formed) と 妥当 (valid) の違いとか、それ以前に特定の文字コードの観点で正しい文字列かとか :+1:
- データに対する意味 (Semantics) の確認は「ドメイン・モデル」が適してるといきなり出てきたような気がするけど、ここまでの妥当性確認はどこでやるのが適しているのだろう? (どこで、何を、という話はここまであったか覚えてないのですがｗ):+1::+1::+1::+1:
- [discord](https://discord.com/channels/432531367427964929/911610565103845387/954701659668365333)
---