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

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

かとじゅん
November 01, 2021
1.9k

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

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

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

かとじゅん

November 01, 2021
Tweet

More Decks by かとじゅん

Transcript

  1. この方法での問題点 セキュリティを意識しながら開発を行うことの問題 開発者はコードを書くとき目を向けているのは 機能 セキュリティを重視すると機能に影響がでてしまう セキュリティは 機能 より優先度が下がる 開発者に対してセキュリティの専門家と同等の知識を求める問題 開発者はセキュリティの専門家ではないし、それも望まれて

    いない 基本的には分業体制で品質を担保する考え方が主流 将来起こりえるすべての脅威を把握することが求められる問題 セキュリティ専門家が実装しても対策できるのは既知の脅威のみ 意図的な将来の脅威への対応は無理筋。 知ることができないこと を知る必要があり矛盾が生じる 32
  2. セキュア・バイ・デザインの適用 浅いドメイン理解では、ユーザ名を文字列型と捉えてしまうが、 実際には値にはルールがある ドメインエキスパートとの会話で、ユーザ名で使える文字は 半角 英数とアンダーバーおよびハイフンのみで長さは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
  3. ドメイン・プリミティブを実現する 妥当性検証のロジックを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
  4. フェイル・ファーストとゼロ・トラスト ドメイン・プリミティブ を導入したら 終わりではありません ビジネスルールに照らして、セキュ リティの考慮を多層的に行う「 多層 セキュリティ 」という考え方がある モジュール間やシステム間であって

    も、お互いに ゼロ・トラストの関係 性を実現する コンポーネントA コンポーネントB コンポーネントC クライアント クライアントは事前条件を満 たしているか? コンポーネントA は事前条件 を満たしているか? コンポーネントB は事前条件 を満たしているか? 39
  5. 完全性が欠落した例 とある オンライン書店の話。あるユーザから$39の本を-1冊の注文 を受け付けてしまった。注文金額が$-39となった。明らかに不 具合。本来であれば、その書籍を返品しなければなりませんが、 そうはなっていません。これは技術的問題ではなくビジネスルー ルから逸れてしまった問題 経理システム を経由して 請求システム

    や 売掛金元帳システム に $-39が伝播して、請求システムは請求金額がなく、売掛金元帳 システムでは注文者に返金する手続きになった 不正な入力を受け付けて、 経理システムに伝播させた オンライン書 店が悪いのでしょうか。 請求システムや 売掛金元帳システムに不正な 入力を伝播させた 経理システムが悪いのでしょうか? 入力や命令が常に正しいと仮定するとこのような問題が起きやす い。システム間でゼロトラストであるべき。つまり 多層セキュリ ティの考え方に従う 40