セキュア・バイ・デザイン 第8章　セキュリティを意識したデリバリ・パイプライン
===
###### 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です。

---

# 正誤表
https://book.mynavi.jp/files/user/support/9784839975999/errata_7599.pdf

# 分からなかった用語

*

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

## 感想・気づき

- 本書に書いているとおり、機能に関するテストとセキュリティに関するテストは区別していると思った。
- [Discord](https://discord.com/channels/432531367427964929/911610565103845387/980070085035188224)

## 疑問

- > 開発のプロセスにおいて、テストは必要不可欠なものである、という認識は開発者であればほとんどの人が共有している認識でしょう。
- [Discord](https://discord.com/channels/432531367427964929/911610565103845387/980068817474560040)
- 認識は広まっているとは思いますが、実際どうなのでしょう？:+1:

---

# 8.1 デリバリ・パイプラインの利用
## 目安の時間
- 20分

## 感想・気づき

## 疑問

- 本には直接関係ないかもなんですが、デリバリパイプラインにOWASP ZAP等でセキュリティ評価を自動化しているのって一般的なんしょうか（ウチはそこまでやれてない。長大なリリースサイクルにゲートとしてのペンテストがあるだけ） :+1:
- [Discord](https://discord.com/channels/432531367427964929/911610565103845387/980072576309149786)
- 注で言及されている『継続的デリバリー』では、同様の仕組みを「デプロイメント・パイプライン」という名前で読んでいたが、なぜ違う名前をつけたのだろう:+1:
- [Discord](https://discord.com/channels/432531367427964929/911610565103845387/980075029964423198)
- 『継続的デリバリー』的には「デリバリー」と「デプロイ（メント）」は区別されているっぽいので、あんまりいじっちゃいけない箇所という気もする
- クラウドベンダーは「デリバリ・パイプライン」という呼称を結構使っているが、表記ゆれが生じている？
- https://aws.amazon.com/jp/getting-started/hands-on/create-continuous-delivery-pipeline/
- https://cloud.google.com/deploy/docs/managing-delivery-pipeline?hl=ja-jp
- https://cloud.ibm.com/docs/ContinuousDelivery?topic=ContinuousDelivery-deliverypipeline_about&locale=ja

---

# 8.2 設計をより安全なものにする単体テスト

## 目安の時間

- 30分

## 感想・気づき

- 8.2「何をすべきでない」を特定するのは難しい。後で想定外でしたってオチになりがち。
- > p.284 コードがすべきことに囚われてしまうと、意図しない振る舞いを見のがしがちになるからです。そして、多くのセキュリティの脆弱性はこの意図しない振る舞いから生まれているのです。
- 結構刺さった。TDDをしていて、「こういう挙動になるべき」という観点でテストは書けているけど、その逆を自分はなかなかできていないと思った。
- > p.289 しかしながら、注文の代金を払ってしまうと、その注文は不変となり、注文内容を変更できなくなります。このことは注文の状態が意味的境界を超えたことを意味します。というのも、支払い前の注文の意味は支払い後の注文の意味と同じではないからです。
- [Discord](https://discord.com/channels/432531367427964929/911610565103845387/980089934851506226)
- 7章にも出てきていたエンティティリレーは、この考え方が背景にあるんだろうなと思った。
- 意味的境界(semantic boundary)の話ってどこらへんにあったっけ…？
- 境界値テストで、期待した異常を確認し、異常値テストで意図しない異常が起きないかどうかを確認しているとわかった
- 同じ異常ではあるが、意図されたものかどうかの違いは大きい
- 異常値テストで、ルールを満たさないすべての異常値から害をもたらす代表的なデータだけを適切な量抜き出してテストするのは、経験値ないと難しそう
- [Discord](https://discord.com/channels/432531367427964929/911610565103845387/980083822081212437)
- p.285の注で言及されている資料『Defense in Depth』で、「defense in depth = 多層防御」というアイディアに関する過去の議論が色々まとまっている
- [Discord](https://discord.com/channels/432531367427964929/911610565103845387/980091491693256714)
- このあたりのテクニック・アプローチが、本書で言う「多層セキュリティ」の元ネタっぽい

## 疑問

- 本題とは外れるけど、JUnit5のdynamic testとパラメータライズド・テストは、挙動が複数のテストケースをパラメータ化して実行しているように見えるので挙動が似ているような気がしている。これらの違いってなんだろう。
- [Discord](https://discord.com/channels/432531367427964929/911610565103845387/980081605961977866)
- > p.291 リスト8.4のコードでは、今回は文字数の確認くらいなので字句的内容のチェックを飛ばしたと書いているが、もし字句的内容の確認を入れるとしたら、正規表現の手前に`[a-z0-9]*`のチェックを入れるということで合っている？
- [Discord](https://discord.com/channels/432531367427964929/911610565103845387/980079547552768021)
- > p294 コラム 結果として被害を引き起こすデータを使ったテスト
- [Discord](https://discord.com/channels/432531367427964929/911610565103845387/980076989459349515)
- SQLインジェクションやXSSを引き起こす文字列を辞書として用意しておき、それを使ってテストする発想はなるほどと思いましたが、それをどこで、いつ、どの程度行うべきのか気になりました:+1::+1:
- 例えば、リポジトリの単体テストで全てのメソッドにSQLインジェクションのテストを書くべきなのか、単体テストではこの類のテストは書かずにリリース前のe2eテストでWeb APIのエンドポイント単位で辞書的にテストすれば良いのかなど
- TDDの文脈ではテストは設計のためのもので、上記のような脆弱性を防ぐためのものではないという認識です。この章では脆弱性（起こってほしくないこと）もテストするのが望ましいと主張されていますが、その類のテストをいつ、どこで、どの程度行うのが効果的かは記載されていなさそうなので気になってます:+1::+1::+1:
- [NCC Group報告書](https://research.nccgroup.com/wp-content/uploads/2020/07/second-order_code_injection_attacks._advanced_code_injection_techniques_and_testing_procedures.pdf)

---

# 8.3 機能トグル（feature toggle）のテスト

## 目安の時間

- 30分

## 感想・気づき

- 8.3.5 監視や自動化により問題の検知を早くし、ふりかえることができると思うのすが、検知した時すでに本番環境で起きているという問題が残る気がします。Blue-Green Deployment等と組み合わせる、あるいはロールバックも込みでパイプラインに組み込んでおく等を検討する必要もあるかもと思いました。:+1::+1:
- [Discord](https://discord.com/channels/432531367427964929/911610565103845387/980085454646964235)
- 機能トグルが意図した状態であることがテストされていることと、パイプライン上でテストが全て通ったときに本番にデプロイされるようになっていれば、そこはある程度軽減されると思っていました。（直接本番環境に入って構成ファイルを変更する・テストケース漏れとかだとどうしようもないですが…）

## 疑問

---

# ============= 6/11 はここから ==============

[discord](https://discord.com/channels/432531367427964929/911610565103845387/984991482899484703)

# 分からなかった用語

# 8.4 セキュリティに関するテストの作成と自動化

## 目安の時間

- 30分

## 感想・気づき

- 探索的テスト（たんさくてきてすと）：情報マネジメント用語辞典 - ITmedia エンタープライズ
- https://www.itmedia.co.jp/im/articles/1111/07/news203.html
- Explore it!
- https://www.devtobook.com/book/1937785025

- OWASP チートシート :+1:
- https://cheatsheetseries.owasp.org/index.html

- > p.313 場合によっては、これらのセキュリティ・テストを実施すると、テストが終わるまでしばらく時間がかかることがあります。そのため、これらのテストを実施する頻度はデリバリ・パイプラインに含まれる他のテストよりも少なくしたほうがよいでしょう。
- 毎回やるものだと思っていたから少し意外だった

- > p.313 このようなインフラの管理ができることはセキュリティの観点においても喜ばしいことです。なぜなら、人の手による間違いを最小限に抑えられることに加え、インフラの検証も自動化できるようになるからです。
- 手作りしてた昔は、本番いざ触ると想定外の設定が入ってる...というのを度々見かけた。IaCが充実したのは本当に喜ばしい。 :+1:

- Vulnerability Scanning Tools | OWASP Foundation
- https://owasp.org/www-community/Vulnerability_Scanning_Tools

- OWASP Dependency-Check Project | OWASP
- https://owasp.org/www-project-dependency-check/

## 疑問

- 皆さんの会社のCIには、セキュリティに対するテストが含まれていますか？:+1::+1:

---

# 8.5 可用性（avaailability）のテスト

## 目安の時間

- 30分

## 感想・気づき

- SP 800-27 Rev. A, Engineering Principles for IT Security: a Baseline | CSRC
- https://csrc.nist.gov/publications/detail/sp/800-27/rev-a/archive/2004-06-21
- https://csrc.nist.gov/publications/detail/sp/800-160/vol-1/final
-
- Understanding Denial-of-Service Attacks | CISA
- https://www.cisa.gov/uscert/ncas/tips/ST04-015

- ドメインDoS攻撃は文面に書かれると「なるほど」と思うが、開発中にケースの洗い出しが難しいと感じた。ビジネス、経営に対するインパクトがあるケースをどうやって思いつくのかなと。また、そんなことしないだろうという、心理的バイアスを外すことが必要と感じた。ルールに則って、悪事を働くケースシナリオを考え付くのは難しいそう。:+1: :+1::+1:

- newsapps/beeswithmachineguns: A utility for arming (creating) many bees (micro EC2 instances) to attack (load test) targets (web applications).
- https://github.com/newsapps/beeswithmachineguns

- Bees with Machine Guns をはじめて知った。
- 自分が知っていたのはabコマンドだった。（これだと分散でのリクエストにはならないけど）
- https://knowledge.sakura.ad.jp/7175/
- Gatling をしばしば使ってた

## 疑問
- 8.5.2 ドメインDoS攻撃の対策を知りたい。(Uberは同対策したか、特に今後も発生しうるドメインDoSに対してどういう施策がある？):+1::+1::+1::+1::+1: :+1:

- 8.5.2のUberのような迷惑行為に対するテストってどんなことが考えられるのか:+1::+1::+1: :+1:
- 1日に大量のキャンセルが出たら警告を出す
- 同じ連絡先からの予約が大量に来たら、その旨をログを残す

---

# 8.6 設定の妥当性確認（validation）

## 目安の時間

- 30分

## 感想・気づき
- P320 図8.5の特性要因図の分類は説明に使えそう。

- P.321の意図した変更は、追加するべき機能に対して変更した設定が、結果的に脆弱性に繋がることを知らなかったという風に読み取れる。これって意図しない変更と一緒では？
- と思ったけど、新たな機能を追加したときに意図して変更した。だけど既存の機能についてテストが無かったから、脆弱性に繋がる振る舞いに変わったことを検知できない、という意味なのか。:+1:
- 普段からテストコードはしっかり書かないと、こういったリスクがある :+1:

- > p.324 実際に使われるアプリケーションを作成するのであれば、フレームワークやライブラリのデフォルトの振る舞いを正確に理解していなければなりません。多くの場合、フレームワークのライブラリのデフォルトの振る舞いはアプリケーションを安全にするようにはなっていますが、場合によっては、使い勝手を優先して、セキュリティをある程度犠牲にした振る舞いをするようになっていることもあります。
- APIリクエストをするライブラリでデフォルトの挙動を理解してなかったのでバグを生み出したことを思い出した。
- ○○できること。といったユーザー目線でのテストを書いてたりするが、ライブラリやフレームワークのデフォルトの挙動を確認するテストはあまり書いたことがない:+1::+1:

## 疑問

- 設定のホット・スポットは他に何が考えられるだろう :+1:
- [discord](https://discord.com/channels/432531367427964929/911610565103845387/985159024456630284)

---