Upgrade to Pro — share decks privately, control downloads, hide ads and more …

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

かとじゅん
November 01, 2021
1.8k

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

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

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

かとじゅん

November 01, 2021
Tweet

More Decks by かとじゅん

Transcript

  1. セキュリティのための
    ソフトウェア設計について
    かとじゅん( )
    2021/11/01
    @j5ik2o
    1

    View full-size slide

  2. 自己紹介
    Chatwork社 テックリード
    @j5ik2o
    2

    View full-size slide

  3. アジェンダ
    セキュア・バイ・デザインの第1章を簡単にまとめた資料です。詳
    しくは書籍を買って読んでみてください
    なぜセキュア・バイ・デザインが必要なのか
    どのようにセキュア・バイ・デザインを実現するのか
    3

    View full-size slide

  4. なぜ
    セキュア・バイ・デザイン
    が必要なのか
    4

    View full-size slide

  5. XSSやインジェクションなどの
    既知の攻撃を対策すれば
    セキュリティの対策は
    十分でしょうか?
    5

    View full-size slide

  6. 答えは
    🙅🏻
    6

    View full-size slide

  7. 既知の攻撃対策が完ぺきでも
    セキュリティ上の問題が
    生じることがあります
    7

    View full-size slide

  8. 詳しくは後述しますが
    「セキュア・バイ・デザイン」に
    一つの答えがあります
    8

    View full-size slide

  9. とはいえ
    セキュリティは重要だと
    頭で分かっていても
    行動には移しづらい
    9

    View full-size slide

  10. ありそうな二つのシナリオ
    セキュリティ診断を受ける
    脆弱性がいくつも指摘されスケジュールが大幅に遅延する。
    最悪はすべてを書き直す必要があるかもしれない
    セキュリティ診断は受けない
    そのまま本番デプロイ。しばらく順調に稼働するが、攻撃を
    受けてしまいすべてのユーザ情報が流出しニュースになる
    10

    View full-size slide

  11. みえてくる問題点
    重要度の高いセキュリティのタスクは、なぜか優先度が低くなる
    開発者は セキュリティ より 機能 に関心が向いてしまう
    セキュリティ への考慮は啓蒙され続けているが、なぜ開発者は
    そうできないのか
    重視されるテストと同様に、なぜ セキュリティ に関してもそう
    しないのか
    11

    View full-size slide

  12. 本書の位置づけ
    本書では、安全なソフトウェアを効率的に、
    かつ、労力をかけずに作成するためには、今
    までとは異なる考え方をしなくてはならない
    と信じています。その考え方とは、開発者は
    セキュリティそのものに目を向けるのではな
    く、設計(design)に目を向ける、というもの
    です。
    12

    View full-size slide

  13. 19世紀の銀行盗難事件
    通用口には鍵が掛かっていた
    が、鍵が外に吊されていた。知っている人なら入れる
    金庫室の扉には強力な錠前が付けられていた
    が、金庫の扉の蝶番を壊すことができた
    13

    View full-size slide

  14. この事件から考えられること
    セキュリティは 機能(feature) で、安全な錠前(lock)を付ければ
    対策できると考えている
    しかし犯人は銀行の脆弱な箇所を攻撃した。セキュリティとは横
    断的な心配事(concern)
    ※concernは関心事と訳されることが多いが、セキュリティ文脈の
    影響してか、本書では心配事と訳されている
    14

    View full-size slide

  15. どうすればよかったのか
    「どうしたら泥棒がお金を持ち去ることを防げるようになる
    か?」を考える
    通用口の鍵をどこに保管するのか
    金庫室に入るほかの方法はないのか
    15

    View full-size slide

  16. 機能(FEATURE)とユーザストーリ
    ソフトウェアの説明には 機能 が利用されることは事実ではある
    「これは自分のショッピング・リストを他のユーザと共有するア
    プリケーションである」
    「これは写真をアップロードして、他のユーザにみてもらったり
    コメントをもらったりするWebサイトである」
    17

    View full-size slide

  17. セキュリティを機能として捉える弊

    セキュリティのことを語る際、その78%がセキュリティの 機能
    として直接分類されることを話している
    ユースケースやユーザストーリは 機能 にフォーカスするので、
    どうしてもセキュリティを機能として捉えることが増える
    18

    View full-size slide

  18. 心配事(CONCERN)に目を向ける
    セキュリティを機能として見てしまうと、本来の目的から外れて
    しまうことが頻繁に起きる
    セキュリティに関する意識を、機能(feature) から 心配事
    (concern) に変えていく
    19

    View full-size slide

  19. 写真格納サービスの例
    ログイン画面は機能であり、利害関係者の心配事に間違いなく含
    まれる。ユーザストーリでは 機能 ベースの表現がよく使われる
    ログイン画面がただ存在するだけでは、本来求めていた安全性を
    得られない。このような単なるログイン画面は誰も求めていない
    ログイン画面が実現されたとしても、ユーザが秘匿したい画像フ
    ァイルは他のユーザからも閲覧可能な状況。これはユーザストー
    リで求められていた状況から逸れてしまっている
    20

    View full-size slide

  20. ログイン画面自体が重要ではない
    ユーザストーリで求められていることはログイン画面そのもので
    はない
    ここで求められているのは、写真の所有者のみが自身の写真を閲
    覧・ダウンロードできることであり、他のユーザにはそれらがで
    きないようにすること
    21

    View full-size slide

  21. ユーザーストーリを見直す
    写真格納サービスのユーザとして、
    私は自身がアップロードした写真にログイン画面を経由して
    からアクセスできるようにしたいです
    私は自身がアップロードした写真へのすべてのアクセスを認
    証によって保護したいです
    それにより、私がアップロードした写真の機密性は保持されます
    22

    View full-size slide

  22. セキュリティにおける心配事の分類:
    CIA-T
    機密性(Confientiality)
    完全性(Integrity)
    可用性(Avaliability)
    追跡可能性(Traceability)
    23

    View full-size slide

  23. 機密性(CONFIENTIALITY)
    機密性はセキュリティについて語る際、最も頻繁に取り上げられ
    る要素
    『外部に知られるべきではない情報を絶対に漏れないようにする
    こと』に関する要素
    例えば、医療記録などが機密性の例としてよく取り上げられる
    24

    View full-size slide

  24. 完全性(INTEGRITY)
    完全性は『情報が変更されないこと』もしくは変更できたとして
    も『許可された方法でのみ変更されること』が重要である場合に
    取り上げられる要素
    例えば、選挙における投票数の集計が完全性の例。投票数が操作
    されていないこと
    25

    View full-size slide

  25. 可用性(AVALIABILITY)
    可用性は『取得可能なデータが必要なときに取得できること』を
    意味する要素
    例えば、消防隊員は火事が起こった場所を知る必要があり、すぐ
    にその情報を入手できるようになっていなければならない。もし
    火災現場の情報がすぐに入手できなかった場合、到着が遅れてし
    まい、結果として手遅れになってしまう
    これだと求めれるセキュリティに応じられない
    26

    View full-size slide

  26. 追跡可能性(TRACEABILITY)
    誰がどのデータにいつアクセスした、もしくは変更したのかを把
    握できることを表す要素
    金融機関や医療機関での数々の不正が発覚したことで、重要にな
    った
    監査ログを残すことはGDPRの中で決められたことの一つ。例え
    ば、個人情報にアクセスがあった場合、そのアクセスを永続的な
    監査ログに残し、追跡できるようにすることが、GDPRの中で定
    められている
    27

    View full-size slide

  27. どのように
    セキュア・バイ・デザインを
    実現するのか
    28

    View full-size slide

  28. どのようにこれらの観点を
    ソフトウェアに組み込むのか
    『セキュリティを開発者の作業やソフトウェアの設計に組み込む』
    29

    View full-size slide

  29. 設計とは
    システムをどのように構築するのか、という
    ことを導く原則であり、コードからアーキテ
    クチャまですべてのレベルにおいて適用可能
    なもののことになる。そこには能動的な意志
    決定を必要とするすべての行為が含まれる。
    30

    View full-size slide

  30. 従来の考え方: XSS攻撃の例
    UserAccountを表示する入力画面での例
    (XSS攻撃は、攻撃者がWebアプリケーションを経由して被害
    者となるユーザに対して悪意のあるコードを送る攻撃のこと)
    userNameはXSS攻撃に使われる可能性がある
    userNameにalert(42);を入力できてしまう
    とユーザの画面に警告ダイアログが表示されてしまう(完全性の
    欠如)
    XSSの問題があるコード
    XSS対策したコード
    final case class UserAccount(id: Long, userName: String)
    final case class UserAccount(id: Long, userName: String) {

    vaildateForXSS(userName) // XSSを防ぐ

    }
    31

    View full-size slide

  31. この方法での問題点
    セキュリティを意識しながら開発を行うことの問題
    開発者はコードを書くとき目を向けているのは 機能
    セキュリティを重視すると機能に影響がでてしまう
    セキュリティは 機能 より優先度が下がる
    開発者に対してセキュリティの専門家と同等の知識を求める問題
    開発者はセキュリティの専門家ではないし、それも望まれて
    いない
    基本的には分業体制で品質を担保する考え方が主流
    将来起こりえるすべての脅威を把握することが求められる問題
    セキュリティ専門家が実装しても対策できるのは既知の脅威のみ
    意図的な将来の脅威への対応は無理筋。
    知ることができないこと
    を知る必要があり矛盾が生じる
    32

    View full-size slide

  32. セキュア・バイ・デザインの考え方
    ソフトウェア設計を正しく行えば
    真に安全なソフトウェアを実装できる
    セキュリティが重要ではないという意味ではない
    セキュリティそのものを中心に考えるのではなく、設計を中心に
    考えるということ
    33

    View full-size slide

  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

    View full-size slide

  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

    View full-size slide

  35. FYI: 妥当性検証には順番がある
    1. 長さの確認
    2. 字句的内容の確認
    3. 構文の確認
    36

    View full-size slide

  36. ドメインプリミティブによる効果
    ソフトウェア開発の中で設計は自然と行われることである
    ビジネスにおける心配事とセキュリティにおける心配事が同等の
    優先度を持って扱われるようになる
    セキュリティの専門家でなくても安全なコードを自然と書くよう
    になる
    ドメインを意識することでセキュリティに関するバグを意識せず
    に取り除く
    ソフトウェア・セキュリティに関する従来の
    アプローチと比べて、設計を強く意識するア
    プローチは書き出されるコードをさらに安全
    なものにします。
    37

    View full-size slide

  37. 特定のドメインにおいて
    汎用的なデータ型は大きな間違い
    多くの開発者が汎用的なデータ型を選択するが、セキュリティの
    観点からそれは大きな間違い
    例えば、電話番号を文字列型として扱うのは便利と考えるかもし
    れないが、電話番号以外のいかなる種類の値であっても受け入れ
    ることができてしまう…!
    開発者は安易に文字列型を好む傾向があり、受け入れるはずのな
    いデータの種類を 変数名による指定 によって不正な入力を避け
    ようとしがち
    これでは不正な入力は防ぎようがない。対策は前述したドメイ
    ン・プリミティブを導入する
    def register(phoneNumber: String) = {

    // ...

    }
    38

    View full-size slide

  38. フェイル・ファーストとゼロ・トラスト
    ドメイン・プリミティブ を導入したら
    終わりではありません
    ビジネスルールに照らして、セキュ
    リティの考慮を多層的に行う「
    多層
    セキュリティ 」という考え方がある
    モジュール間やシステム間であって
    も、お互いに
    ゼロ・トラストの関係
    性を実現する
    コンポーネントA
    コンポーネントB
    コンポーネントC
    クライアント
    クライアントは事前条件を満
    たしているか?
    コンポーネントA
    は事前条件
    を満たしているか?
    コンポーネントB
    は事前条件
    を満たしているか?
    39

    View full-size slide

  39. 完全性が欠落した例
    とある
    オンライン書店の話。あるユーザから$39の本を-1冊の注文
    を受け付けてしまった。注文金額が$-39となった。明らかに不
    具合。本来であれば、その書籍を返品しなければなりませんが、
    そうはなっていません。これは技術的問題ではなくビジネスルー
    ルから逸れてしまった問題
    経理システム を経由して
    請求システム や
    売掛金元帳システム に
    $-39が伝播して、請求システムは請求金額がなく、売掛金元帳
    システムでは注文者に返金する手続きになった
    不正な入力を受け付けて、
    経理システムに伝播させた
    オンライン書
    店が悪いのでしょうか。
    請求システムや
    売掛金元帳システムに不正な
    入力を伝播させた
    経理システムが悪いのでしょうか?
    入力や命令が常に正しいと仮定するとこのような問題が起きやす
    い。システム間でゼロトラストであるべき。つまり
    多層セキュリ
    ティの考え方に従う
    40

    View full-size slide

  40. 結局どうすればいいのか?
    ソフトウェアの安全性を担保するために
    ソフトウェア設計を重要視する。


    これらの書籍から多くのことを学べます
    41

    View full-size slide

  41. まとめ
    セキュア・バイ・デザインは、設計を意識することでセキュリテ
    ィを考慮できる考え方。逆にいえば、セキュリティを切り口にド
    メインを学び、設計を改善することができる
    セキュリティ対策はビジネス的にも至上命題であり、セキュリテ
    ィを観点にドメイン駆動設計を取り組むことができる
    42

    View full-size slide