セキュア・バイ・デザイン 第9章　安全性を考えた処理失敗時の対策
===
###### 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です。

---

# わからなかった単語

# 第9章 序章
## 目安の時間
- 30分

## 感想・気づき

- > p.329 どのような設計を選択するのか、もしくは、どういう理由でその設計を選択するのかということに関係なく、開発者は処理が失敗した時のことを考慮しなければなりません。
- ビジネス例外、技術的例外の話が次に出てくるけれど、これら失敗を考慮できるのは重要なスキル。その割に軽視される場面も多い？:+1::+1::+1::+1::+1::+1:

## 疑問

- セキュリティの観点に限らず、エラーや異常系について、身の回りで積極的に議論されているでしょうか？:+1::+1::+1::+1::+1::+1::+1::+1::+1:

---

# 9.1 処理が失敗したときの対応に使われる例外
## 目安の時間
- 30分

## 感想・気づき

- 深く考えたことなかったけど、スタックトレースからいろんな情報がわかるから攻撃に使えてしまうんだな…。 :+1::+1::+1:
- 内部情報を公開することは、攻撃者にとって利益がある、と考えるのが良さそうですね。 :+1::+1:

- > P.334 今回のように、両方の例外をIlliegalStateExceptionとしていた場合、扱っている例外がビジネス例外なのか、それとも、技術的な例外なのかを判断できなくなってしまいます。まさに、これが、ビジネス例外と技術的例外を同じ例外の型を使って一緒に扱うべきではないことの理由なのです。
- これはとても納得:+1::+1::+1:

- > p.338 また、この中でAccountExceptionをキャッチするのは無駄なことをしているように思われるかもしれませんが、このセーフティ・ネットは非常に重要です。なぜなら、このドメインで発生するすべてのビジネス例外はAccountExceptionクラスを継承するようにしているため、すべてのビジネス例外がこのドメインで適切に対応され、技術的例外のみがグローバルな例外ハンドラーに伝達されることを保証できるようになるからです。
- ドメイン層より外にビジネス例外を出さないようにする、という考え方をすれば良いということか
- レイヤリングしたら、レイヤごとに異なる関心を持っているので、例外もレイヤごとに定義して処理したい。必要ならば、下位層の例外を上位層の例外に置き換えることで、意味の変換をして送出しなおしたりも。:+1::+1::+1:

- P.334のコラムは地味に重要だなぁと感じる。
- (stremaApiにおいての)reduceメソッドに定義した関数が実行されるということは、要素が複数あるとき
- `reduce((accountA, accountB) -> throw new IlliegalStateException)`というやり方ができるんだな:+1:

- > p.340 確かに、処理の失敗を分析するのに問題が起きた口座番号と顧客情報があると便利なのですが、セキュリティの観点から言えば、これは大きな問題です。
- 開発用にデバッグ用に仕込んで、そのまま残すとかの事故アリそう。 :+1::+1:
- ログレベルでなんとかできないかな
- 「情報いっぱいログに残したから、調査しやすくてみんな幸せだ！」と思ってた時期があった気がする。

## 疑問
- ビジネス例外とアプリケーション例外を分けようみたいな流れは前からあった気がするけど、いっしょくたにする実装って多いんだろうか。:+1::+1:
- ドメイン層に置くといった整理はしていなかったとしても

- > P.341 例えば、処理を失敗したときの情報に口座番号と顧客情報を含める代わりに「データベースの接続に失敗しました（ID: XYZ）」のような情報を残すことも考えられます。
- 口座番号などの情報が何もなかったら、その顧客に関する処理に関して何か調査が必要な場合には、どうやって調査したらいいのでしょうか？
- おそらく"ID: XYZ"から調査できるようにしているのかと。そして、そこにアクセスするには特別な権限が必要な形にしているのでしょう。

---

# 9.2 例外を使わない処理失敗時の対応
## 目安の時間
- 30分

## 感想・気づき

- > p.345 この別の見方の根幹を成す考えは、何らかの処理をする際に失敗することは例外的なことではなく、想定可能な結果である、というものです。
- たしかに、ビジネス例外と言われているけど、残高不足で失敗すること自体は特に例外か？と言われるとそうではない気がする:+1::+1::+1::+1::+1:

- 結果を返すアプローチは、ある程度コード品質が高いのが前提にあるように感じた。(例えば、複雑な条件なものに導入した結果、return漏れが発生するなど)

## 疑問

- p.346、リスト9.9の結果オブジェクト(Result)で想定していないエラーが起きた場合には、UNKNOWN的な失敗理由を追加するイメージ？
- それこそ例外を投げる
- [discord](https://discord.com/channels/432531367427964929/911610565103845387/990234000352239626)

- 逆に結果オブジェクトを使うことによるデメリットってなんだろうか:+1::+1:
- グローバルな例外ハンドラーが呼ばれることはなくなるから、開発者が気をつけていないとエラーを補足できない？
- エラーのチェックを忘れるとバグになる

---

# ★☆★☆★☆★☆★☆★7/9 はここから★☆★☆★☆★☆★☆★

# 9.3 可用性（availability）の設計

## 目安の時間
- 45分

## 感想・気づき

- > P.348 CIAの順序はAICだというのを政府CISOの人が言ってた（セキュリテイと聞くとCが大事と思われがちだが、経営視点で考えるとAありきである）

- > p.349 この回復性を備えたシステムとは、高い負荷がかかっている状況であっても、機能を提供し続けられるように設計されたシステムのことです。
- 回復性(resilience) と 頑健性(robustness) って、違うようでいて混同する話も多いんじゃないかと思う。:+1:
- https://www.slideshare.net/hiromasaoka/15-noops/14

- > p.350 重要なのは、システムがレスポンスを素早く返すことの重要性を理解することです。と言うのも、このシステムを呼び出す側にとって、いつ返ってくるのか分からない結果をいつまでも待つよりも、できるだけ早い段階で、このシステムがリクエストを受け付けないことを示すエラーを受け取る方が良いからです。
- APIの返答速度が遅かったとき（暫定処理だとは認識合わせつつ）、ローディングのインジケータを入れたことはあった。何かしら処理をしていることをユーザーに理解をさせる目的で入れた :+1:
- HTTPステータスコードには「リクエストを受け取ったが、処理が完了していないこと」を示す`202 Accepted`がある :+1:
- 正常系の時の応答の早さと、異常系の応答のはやさどっちを求めるかというのは結構作るものによって意見が分かれそう。(正常系を早くするなら同期応答、異常系を早くするなら非同期応答が都合いいケースとか)

- サーキットブレーカーを導入する際のドメインモデリングに注意が必要とはあるけど、そもそもそういうデータが取れなかったことに関するデフォルトの挙動は常に考えたい:+1::+1:

- > p.356 ただし、サービスやサーバを分割する際は、その中に隠れた依存関係が存在しているかもしれないことに注意してください
- サービス分けていてもDBは同じだったりするのはあるある:+1:

- 回復性と応答性の話が出てきたので、リアクティブ宣言っぽいなって思っていたらp.358のコラムでまさにその話が出てきていた :+1:

- バルクヘッドの考え方はクラウドが主流となった今だと結構当たり前になっている気がする:+1:
- 当たり前的な感覚で、バルクヘッドってパターンをそもそも認識できてない可能性はありそう

## 疑問

- サーキットブレーカーの具体的な実装例は特に書かれていないけど、ミドルウェアでやるイメージかな:+1:
- [Istioサーキットブレーカーで備えるマイクロサービスの連鎖障害 \- ZOZO TECH BLOG](https://techblog.zozo.com/entry/zozotown-istio-circuit-breaker)
- と思ったけど、`他のビジネスロジックのときと同じように行っていきましょう`とTIPに書いてあるので、ドメインロジックでそういった考慮をするイメージっぽいな

---

# 9.4 不正なデータの対応

## 目安の時間
- 45分

## 感想・気づき

- > p.361 この名前の制限はしばらくの間は問題なく機能していました。しかしながら、ある時、会員データベースを拡張して他のシステムからも会員のデータを取り込むようになった時、このNameクラスの契約はニューヨークの新年の打ち上げ花火のように木っ端微塵に破綻してしまいました。
- データの取り込みじゃないですが、Active Directory とかをまとめて認証で共有してると、使ってるミドルごとにユーザの一意性認識がずれてたり、取り込んでる情報がずれてたりで、ユーザ管理が壊れたことはありました。:eyes:

- > p.364 まず、妥当性確認の結果が「偽（false）」となったときに受け取ったデータをそのままメッセージに含めることは、アプリケーションが出力する情報への制御を実質的にユーザ（悪意ある第三者）に与えることになります。
- そういう考え方をしたことがなかった :+1:

- > p.364 これは、特に、例外に含まれる内容をログに出力している場合やユーザに表示している場合に当てはまります。例えば、ログに残されていた次のデータは問題が無いように見えるかも知れません。しかしながら、もし、このログ・データをブラウザ・ベースの管理ツールが適切なエスケープを行わずに表示していた場合、この値はJavaScriptのコードとして解析されてしまい、スクリプトとして実行されてしまうかもしれません。
- そういうやり方ができちゃうのか…怖い :+1::+1::+1:

## 疑問

- p.361の「9.4.1 妥当性確認の前にデータを修正することによって引き起こされる問題」というのは、データ修正することよりも、妥当性確認した結果をログにそのまま出したこと自体が問題な気がしているのですが、どうなんでしょうか。:+1:

---