セキュリティのためのソフトウェア設計について

XSSやインジェクションなどの既知の攻撃を対策するだけがセキュリティ対策ではありません。たとえば、オンライン書店で、既知の攻撃対策は完ぺきだったが、-1冊の誤注文を受理し請求なし＆返金処理まで至ったという事例があります。こういった問題はドメインモデルに手を入れないと対策できません。どうやったらそれができるのか、それがセキュア・バイ・デザインです。ドメインモデルに基づいて設計自体にセキュリティの考慮(アプリケーションレベルでのフェイルファーストとゼロトラスト)を組み込む考え方です。

本スライドでは、セキュア・バイ・デザインの第1章を簡単に解説します。

Transcript

1. セキュリティのための ソフトウェア設計について かとじゅん( ) 2021/11/01 @j5ik2o 1
2. 自己紹介 Chatwork社 テックリード @j5ik2o 2
3. アジェンダ セキュア・バイ・デザインの第1章を簡単にまとめた資料です。詳 しくは書籍を買って読んでみてください なぜセキュア・バイ・デザインが必要なのか どのようにセキュア・バイ・デザインを実現するのか 3
4. なぜ セキュア・バイ・デザイン が必要なのか 4
5. XSSやインジェクションなどの 既知の攻撃を対策すれば セキュリティの対策は 十分でしょうか？ 5
6. 答えは 🙅🏻 6
7. 既知の攻撃対策が完ぺきでも セキュリティ上の問題が 生じることがあります 7
8. 詳しくは後述しますが 「セキュア・バイ・デザイン」に 一つの答えがあります 8
9. とはいえ セキュリティは重要だと 頭で分かっていても 行動には移しづらい 9
10. ありそうな二つのシナリオ セキュリティ診断を受ける 脆弱性がいくつも指摘されスケジュールが大幅に遅延する。 最悪はすべてを書き直す必要があるかもしれない セキュリティ診断は受けない そのまま本番デプロイ。しばらく順調に稼働するが、攻撃を 受けてしまいすべてのユーザ情報が流出しニュースになる 10
11. みえてくる問題点 重要度の高いセキュリティのタスクは、なぜか優先度が低くなる 開発者は セキュリティ より 機能 に関心が向いてしまう セキュリティ への考慮は啓蒙され続けているが、なぜ開発者は そうできないのか 重視されるテストと同様に、なぜ セキュリティ に関してもそう しないのか 11
12. 本書の位置づけ 本書では、安全なソフトウェアを効率的に、 かつ、労力をかけずに作成するためには、今 までとは異なる考え方をしなくてはならない と信じています。その考え方とは、開発者は セキュリティそのものに目を向けるのではな く、設計(design)に目を向ける、というもの です。 12
13. 19世紀の銀行盗難事件 通用口には鍵が掛かっていた が、鍵が外に吊されていた。知っている人なら入れる 金庫室の扉には強力な錠前が付けられていた が、金庫の扉の蝶番を壊すことができた 13
14. この事件から考えられること セキュリティは 機能(feature) で、安全な錠前(lock)を付ければ 対策できると考えている しかし犯人は銀行の脆弱な箇所を攻撃した。セキュリティとは横 断的な心配事(concern) ※concernは関心事と訳されることが多いが、セキュリティ文脈の 影響してか、本書では心配事と訳されている 14
15. どうすればよかったのか 「どうしたら泥棒がお金を持ち去ることを防げるようになる か？」を考える 通用口の鍵をどこに保管するのか 金庫室に入るほかの方法はないのか 15
16. 機能(FEATURE)とユーザストーリ ソフトウェアの説明には 機能 が利用されることは事実ではある 「これは自分のショッピング・リストを他のユーザと共有するア プリケーションである」 「これは写真をアップロードして、他のユーザにみてもらったり コメントをもらったりするWebサイトである」 17
17. セキュリティを機能として捉える弊 害 セキュリティのことを語る際、その78%がセキュリティの 機能 として直接分類されることを話している ユースケースやユーザストーリは 機能 にフォーカスするので、 どうしてもセキュリティを機能として捉えることが増える 18
18. 心配事(CONCERN)に目を向ける セキュリティを機能として見てしまうと、本来の目的から外れて しまうことが頻繁に起きる セキュリティに関する意識を、機能(feature) から 心配事 (concern) に変えていく 19
19. 写真格納サービスの例 ログイン画面は機能であり、利害関係者の心配事に間違いなく含 まれる。ユーザストーリでは 機能 ベースの表現がよく使われる ログイン画面がただ存在するだけでは、本来求めていた安全性を 得られない。このような単なるログイン画面は誰も求めていない ログイン画面が実現されたとしても、ユーザが秘匿したい画像フ ァイルは他のユーザからも閲覧可能な状況。これはユーザストー リで求められていた状況から逸れてしまっている 20
20. ログイン画面自体が重要ではない ユーザストーリで求められていることはログイン画面そのもので はない ここで求められているのは、写真の所有者のみが自身の写真を閲 覧・ダウンロードできることであり、他のユーザにはそれらがで きないようにすること 21
21. ユーザーストーリを見直す 写真格納サービスのユーザとして、 私は自身がアップロードした写真にログイン画面を経由して からアクセスできるようにしたいです 私は自身がアップロードした写真へのすべてのアクセスを認 証によって保護したいです それにより、私がアップロードした写真の機密性は保持されます 22
22. セキュリティにおける心配事の分類: CIA-T 機密性(Confientiality) 完全性(Integrity) 可用性(Avaliability) 追跡可能性(Traceability) 23
23. 機密性(CONFIENTIALITY) 機密性はセキュリティについて語る際、最も頻繁に取り上げられ る要素 『外部に知られるべきではない情報を絶対に漏れないようにする こと』に関する要素 例えば、医療記録などが機密性の例としてよく取り上げられる 24
24. 完全性(INTEGRITY) 完全性は『情報が変更されないこと』もしくは変更できたとして も『許可された方法でのみ変更されること』が重要である場合に 取り上げられる要素 例えば、選挙における投票数の集計が完全性の例。投票数が操作 されていないこと 25
25. 可用性(AVALIABILITY) 可用性は『取得可能なデータが必要なときに取得できること』を 意味する要素 例えば、消防隊員は火事が起こった場所を知る必要があり、すぐ にその情報を入手できるようになっていなければならない。もし 火災現場の情報がすぐに入手できなかった場合、到着が遅れてし まい、結果として手遅れになってしまう これだと求めれるセキュリティに応じられない 26
26. 追跡可能性(TRACEABILITY) 誰がどのデータにいつアクセスした、もしくは変更したのかを把 握できることを表す要素 金融機関や医療機関での数々の不正が発覚したことで、重要にな った 監査ログを残すことはGDPRの中で決められたことの一つ。例え ば、個人情報にアクセスがあった場合、そのアクセスを永続的な 監査ログに残し、追跡できるようにすることが、GDPRの中で定 められている 27
27. どのように セキュア・バイ・デザインを 実現するのか 28
28. どのようにこれらの観点を ソフトウェアに組み込むのか 『セキュリティを開発者の作業やソフトウェアの設計に組み込む』 29
29. 設計とは システムをどのように構築するのか、という ことを導く原則であり、コードからアーキテ クチャまですべてのレベルにおいて適用可能 なもののことになる。そこには能動的な意志 決定を必要とするすべての行為が含まれる。 30
30. 従来の考え方: XSS攻撃の例 UserAccountを表示する入力画面での例 (XSS攻撃は、攻撃者がWebアプリケーションを経由して被害 者となるユーザに対して悪意のあるコードを送る攻撃のこと) userNameはXSS攻撃に使われる可能性がある userNameに<script>alert(42);</script>を入力できてしまう とユーザの画面に警告ダイアログが表示されてしまう(完全性の 欠如) XSSの問題があるコード XSS対策したコード final case class UserAccount(id: Long, userName: String) final case class UserAccount(id: Long, userName: String) { vaildateForXSS(userName) // XSSを防ぐ } 31
31. この方法での問題点 セキュリティを意識しながら開発を行うことの問題 開発者はコードを書くとき目を向けているのは 機能 セキュリティを重視すると機能に影響がでてしまう セキュリティは 機能 より優先度が下がる 開発者に対してセキュリティの専門家と同等の知識を求める問題 開発者はセキュリティの専門家ではないし、それも望まれて いない 基本的には分業体制で品質を担保する考え方が主流 将来起こりえるすべての脅威を把握することが求められる問題 セキュリティ専門家が実装しても対策できるのは既知の脅威のみ 意図的な将来の脅威への対応は無理筋。 知ることができないこと を知る必要があり矛盾が生じる 32
32. セキュア・バイ・デザインの考え方 ソフトウェア設計を正しく行えば 真に安全なソフトウェアを実装できる セキュリティが重要ではないという意味ではない セキュリティそのものを中心に考えるのではなく、設計を中心に 考えるということ 33
33. セキュア・バイ・デザインの適用 浅いドメイン理解では、ユーザ名を文字列型と捉えてしまうが、 実際には値にはルールがある ドメインエキスパートとの会話で、ユーザ名で使える文字は 半角 英数とアンダーバーおよびハイフンのみで長さは4 から40 文字までとい う結論が導かれた いくつもの妥当性検証が含まれている。これはユーザ名が重要な ドメインモデルであることを示している 結果的にXSS対策されているが、<や>などの文字が除外されるの は、XSS攻撃自体を考慮したわけではない 正しい振る舞いから逸れるとき(欠陥が含まれる状況)は、アプリ ケーションは フェイル・ファースト( 早期失敗)する final case class UserAccount(id: Long, userName: String) { require(userName.length >= 4, "文字列の長さが不正(4文字未満)です") require(userName.length <= 40, "文字列の長さが不正(40文字超え)です") require(userName.matches("^[a-zA-Z0-9_-]+$"), "文字種が不正です") } 34
34. ドメイン・プリミティブを実現する 妥当性検証のロジックを1つの型にまとめることで高凝集の原則 に従うことができる。 ユーザ名をただの文字列型ではなく、ユーザ名 型。ドメインに特化した型を ドメイン・プリミティブという セキュリティより設計を意識することでドメインの知識を得て厳 密なドメインモデルを作成できるようになった。対象ドメイン上 の重要性が高い概念を 独自の型 として抽出できた 結果的に開発者はドメイン理解を深めるとともに、前述のXSS攻 撃にも対応できるようなった。 セキュリティについてまだ何も考えて いないのにもかかわらず final case class UserName(private val value: String) { require(value.length >= 4, "文字列の長さが不正(4文字未満)です") require(value.length <= 40, "文字列の長さが不正(40文字超え)です") require(value.matches("^[a-zA-Z0-9_-]+$"), "文字種が不正です") def asString: String = value } // UserName型である限り、正しい値(ユーザ名)であることが保証される final case class UserAccount(id: Long, userName: UserName) 35
35. FYI: 妥当性検証には順番がある 1. 長さの確認 2. 字句的内容の確認 3. 構文の確認 36
36. ドメインプリミティブによる効果 ソフトウェア開発の中で設計は自然と行われることである ビジネスにおける心配事とセキュリティにおける心配事が同等の 優先度を持って扱われるようになる セキュリティの専門家でなくても安全なコードを自然と書くよう になる ドメインを意識することでセキュリティに関するバグを意識せず に取り除く ソフトウェア・セキュリティに関する従来の アプローチと比べて、設計を強く意識するア プローチは書き出されるコードをさらに安全 なものにします。 37
37. 特定のドメインにおいて 汎用的なデータ型は大きな間違い 多くの開発者が汎用的なデータ型を選択するが、セキュリティの 観点からそれは大きな間違い 例えば、電話番号を文字列型として扱うのは便利と考えるかもし れないが、電話番号以外のいかなる種類の値であっても受け入れ ることができてしまう…！ 開発者は安易に文字列型を好む傾向があり、受け入れるはずのな いデータの種類を 変数名による指定 によって不正な入力を避け ようとしがち これでは不正な入力は防ぎようがない。対策は前述したドメイ ン・プリミティブを導入する def register(phoneNumber: String) = { // ... } 38
38. フェイル・ファーストとゼロ・トラスト ドメイン・プリミティブ を導入したら 終わりではありません ビジネスルールに照らして、セキュ リティの考慮を多層的に行う「 多層 セキュリティ 」という考え方がある モジュール間やシステム間であって も、お互いに ゼロ・トラストの関係 性を実現する コンポーネントA コンポーネントB コンポーネントC クライアント クライアントは事前条件を満 たしているか？ コンポーネントA は事前条件 を満たしているか？ コンポーネントB は事前条件 を満たしているか？ 39
39. 完全性が欠落した例 とある オンライン書店の話。あるユーザから$39の本を-1冊の注文 を受け付けてしまった。注文金額が$-39となった。明らかに不 具合。本来であれば、その書籍を返品しなければなりませんが、 そうはなっていません。これは技術的問題ではなくビジネスルー ルから逸れてしまった問題 経理システム を経由して 請求システム や 売掛金元帳システム に $-39が伝播して、請求システムは請求金額がなく、売掛金元帳 システムでは注文者に返金する手続きになった 不正な入力を受け付けて、 経理システムに伝播させた オンライン書 店が悪いのでしょうか。 請求システムや 売掛金元帳システムに不正な 入力を伝播させた 経理システムが悪いのでしょうか？ 入力や命令が常に正しいと仮定するとこのような問題が起きやす い。システム間でゼロトラストであるべき。つまり 多層セキュリ ティの考え方に従う 40
40. 結局どうすればいいのか？ ソフトウェアの安全性を担保するために ソフトウェア設計を重要視する。 これらの書籍から多くのことを学べます 41
41. まとめ セキュア・バイ・デザインは、設計を意識することでセキュリテ ィを考慮できる考え方。逆にいえば、セキュリティを切り口にド メインを学び、設計を改善することができる セキュリティ対策はビジネス的にも至上命題であり、セキュリテ ィを観点にドメイン駆動設計を取り組むことができる 42
42. 終わり 43