ドメイン駆動セキュリティへの道しるべ

Transcript

1. ドメイン駆動セキュリティへの道しるべ 変更容易なセキュリティアーキテクチャのためのエチケット
2. わらわの自己紹介  所属:ちゅらデータ データビジネスコンサル  特技:モデリング、抽象化、アナロジー、推論、守破離  一応、ここの運営です  あだ名:アジャイル界のハンコック  モットー:  モデルベースのセキュリティなくして、AIアタッカーには勝てない  巷のスクラムの８割は大体ただの反復
3. アジェンダ  課題提起  クリーンアーキテクチャと脅威モデリングのかかわり  ドメイン駆動設計と脅威モデリングのかかわり  セキュリティアーキテクチャで使うべき「原則」一覧  まとめ-次回予告
4. 課題提起
5. なぜ、私たちのシステムは「穴」だらけなのか?  WAFを入れた、パッチも当てた。それでもインシデントは起きる。  根本原因: アプリケーションの「脊髄（アーキテクチャ）」が、そもそも攻撃を受け入れやすい構造になっている。  「機能要件（動くこと）」を優先し、「非機能要件（守ること）」を後回しにしたツケ。
6. 本日のゴール  セキュリティ対策を「モグラ叩き」から「都市計画（アーキテクチャ）」へ昇華させる。  与えられたシステム図に対して、脅威分析を行うのではなく、開発者の関心のある、保守性の観点でシステムの構成要 素を考えたのちに、脅威分析ができるようになることがゴール。  そのためのツールセット  Clean Architecture: 守るべき資産を隔離する。  DDD (Domain Driven Design): 守るべき資産の正体を知る。  Principles (SOLID/Component/DRY/KISS/SLAP): 頑丈な建材を選ぶ これらを「脅威モデリング」という接着剤で統合する。
7. 現状の課題: セキュリティエンジニア  脅威モデリング手法（STRIDE, DREAD等）は知っ ている。  しかし、「DFD（データフロー図）」を描く段階で、「巨 大なプロセス」や「曖昧なデータストア」が登場し、解像 度が荒くなりがち。  結果として、技術的脅威は見つかるが、ビジネスロジッ クに潜む脅威を見逃してしまう。  セキュリティアーキテクチャは保守性が従来よりも高くなく てはいけない 開発エンジニア  考えた既存の設計モデルに脅威分析とかしない。  セキュリティエンジニアに脅威分析をさせる前に実装に 取り掛かりがち。  DFDを描かない。  でも一応、プロダクトの業務に関しては、DDDのバズり で関心が高まっている。
8. クリーンアーキテクチャと脅威モデリングのかかわり 脅威およびリスクの関心を分離せよ
9. クリーンアーキテクチャの導入
10. 関心の分離  概要 ソフトウェア工学において、プログラムを関心（責任・何をしたいのか）ごとに分離された構成要素で構築することを指します。  得られる効果 これにより、コードの可読性や保守性が向上し、変更に強いソースコードを作成することが可能になります。 具体的には、クラスや関数が一つの関心に専念している状態を維持し、複数の関心を一つに混ぜないことが重要。  他分野での効果 関心の分離は、複雑で依存関係が入り乱れたシステムの理解、設計、運用を容易にし、他の工学分野でも広く適用されています。 MECEに分けるとかっていうのも、関心の分離。
11. 脅威モデリングとの相乗効果  従来の脅威分析:「WebサーバーとDBの間の線」を見る（インフラ視点）。  Clean Arch x 脅威分析: 「ControllerとUseCaseの間の線」を見る（ロジック視点）。 脆弱性の70%以上はアプリ層にある。 ⇒どれだけインフラで頑張っても、高確率でトラブルにつながる。 ⇒だからこそ、アプリの構造図で脅威分析をする必要がある。 境界型防御とかいってるけど、 Clean Arch が使われていないとか論外。
12. すべての脅威を一度に考えてはいけない 脅威モデリングのワークショップなどを見ていて感じたこととして ビジネス、アプリ、インフラの脅威がすべて混在した状態で議論されていることが毎回である。 この代償として、以下があげられる。  同じ分析を何度も繰り返してしまう（DRY違反）  「認知的負荷」が高く、分析が雑になる  脅威同士の因果関係が不透明  脅威が見つかった際の対策が「対症療法」になり、設計が腐る  枝葉のノイズが多くてビジネスロジックの脆弱性を見落とす（最大のデメリット）
13. 関心を分けた層ごとの脅威分析を行うべし  各層と境界での脅威分析に分けて考える  これにより、各層でのリスク対策となるセキュリティ設計が行いやすい  ある層での脅威は、原因として外側のどの層での脅威?という、因 果関係が整理しやすい。
14. ドメイン駆動設計と脅威モデリングのかかわり 「GARBAGE IN, GARBAGE OUT」を防ぐための、堅牢なモデル構築フェーズ。
15. ※正しい地図なくして、正しい防御なし  スパゲッティコードの図を分析しても、ノイズだらけで脅威が見えない。  まずは「あるべき姿」をモデリングしなくてはならない。 ドメインモデル:「宝の地図」に相当 脅威モデリング:「海賊の襲撃計画を立てる」ことに相当
16. 境界付けられたコンテキスト  セキュリティでは信頼境界のこと  開発サイドでは、ビジネスの仕事の責任境界のこと に相当している。 両者が一致するのはまれだが、図のように 大幅な乖離は、混乱を招くので非推奨。
17. STEP 1 - イベントストーミング (全体像)  目的:時間軸で「ビジネスの事実」を捉える。 ビジネスイベントを起点にコマンド(処理)やポリシーを見 つけていく。 それにより、ビジネスの文脈の境界を見つける。  Security Point: ハッピーパスだけでなく、「認証失敗」「アカウントロック」 「決済エラー」などのSecurity Eventもこの段階で洗 い出す。これを忘れると、異常系の設計が漏れる。
18. STEP 2 - コンテキストマップ (境界の仮説)  イベントの塊から「境界づけられたコンテキスト」を定義。  各コンテキストの特性を抑える!!  現状のTrust Boundary (信頼境界)を引く  「商品カタログ」は一般公開（低信頼）。  「決済処理」は高機密（高信頼）。  この境界線（Context Map上の線）こそが重点防御ラインになる。
19. ドメインの特性を分類する  競合他社との差別化  業務ロジックの複雑さ の2軸で分類し、中核領域と、顧客などの個人情報系の 領域と分類する。 ※顧客系はコアではないが、個人情報保護の観点から LINDDUNの必要性。
20. STEP 3 - 概念モデリングとGRASP  コンテキストの中身を、クラス図レベルで詳細化する。 特に重要なクラウンの部分に集中してモデリングを行う。  ここで使う最強の原則:GRASP「情報エキスパート」。
21. 情報エキスパートによる「責務の要塞化」  原則: 「情報を持っているオブジェクトに、処理も任せる」。  NG例: UserManager が User からパスワードを取り出して検証する。 ⇒生データが移動している（漏洩リスク）。  OK例: User オブジェクト自身が authenticate() メソッドを持つ。 ⇒データはカプセル化され、外に出ない。  結論: 適切な責務割り当ては、アタックサーフェス（データ移動）を劇的に減らす。
22. 情報エキスパートのメリット 処理の割り当てにより、 エンティティ同士の境界の 間違いに素早く気付ける。
23. ここで初めて脅威モデリングの実践 (STRIDE)  作り上げたモデルを、攻撃者視点で叩くフェーズ。  綺麗なモデルができた。では、それを壊してみよう。  ※開発者にはウザがられます。  わたしは過激力業推奨派です。  モデルにSTRIDEを適用する。
24. アタックシミュレーション 1 (なりすまし)  対象: クリーンアーキテクチャの「Controller → UseCase」の境界。  脅威: 「内部呼び出しだから安全」と思い込み、Controllerでの認証チェックが甘い ⇒悪意あるリクエストがUseCase（ビジネスの核）に直接到達する Spoofing
25. アタックシミュレーション 2 (改ざん/否認)  対象: 「UseCase → Domain Entity」の境界。  脅威: UseCaseがデータを加工する際、意図せず整合性を壊す、あるいは ログを残さない。 ⇒データの Tampering と、誰がやったか追えない Repudiation。
26. 機能的境界 VS セキュリティ的境界  DDDで引いた「機能的な境界」と、脅威分析で見えた「守るべき境界」にはズレがある。  この「ズレ」を修正するのが、次のアーキテクチャ再構築フェーズ。
27. セキュリティアーキテクチャで使うべき「(パクってこれる)原則」 一覧 設計判断に迷った時の「羅針盤」
28. 単一責任の原則  思想:変更する理由は、クラスにつき一つであるべき  あれもこれもやりますというような、責務が曖昧な時には、必ずこの原則を満たせていない。  ビジネスロジックと表示ロジックを混ぜない。  セキュリティ文脈での適用:攻撃対象領域（アタックサーフェス）の分離 「計算する責務」と「権限をチェックする責務」を分ける。計算ロジックに認証コードを混入させない。  得られる効果:監査容易性 「どこで認証しているか」が一目瞭然になり、実装漏れやバグを発見しやすくなる。 意図が明確だからこそ、見つけやすい。
29. オープンクローズド原則 単一責務を満たせていることで、これを満たしやすくなる。  思想:拡張に対して開き、修正に対して閉じているべき  機能追加時に既存コードを書き換えない。  ゆえに、テストも追加部分だけで済みやすくなる。  セキュリティ文脈での適用:ポリシー変更によるデグレ（破壊）防止 「特定の国からのアクセス遮断」などのルール追加を、設定やPlugin追加だけで行い、コアロジックを触らせない。  得られる効果:安定性 頻繁なセキュリティポリシー変更があっても、ビジネス機能のバグ混入を防げる。 ⇒セキュリティアーキテクチャの変更がしやすくなる。⇒セキュリティがアジリティを下げにくくなる。
30. 依存関係逆転の原則  思想:「詳細ではなく、抽象に依存せよ」 上位モジュールは下位の実装を知る必要がない。 例) 要件定義では、細かい実装や言語といった詳細を決めないなどもこれ。  セキュリティ文脈での適用:ベンダーロックインからの解放 「AWS WAF」や「特定のAuthライブラリ」に直接依存せず、ISecurityPortという自社の抽象に依存する。  得られる効果:ポータビリティ 将来、認証基盤やインフラが刷新されても、ビジネスロジックを守り抜くことができる。 外側の詳細のみ、付け替えたらいいから。
31. 再利用・リリース等価原則(REP)  思想:再利用の単位とリリースの単位は同じであるべき  コピペではなく、バージョン管理されたモジュールを使う。  再利用される単位の中に、一部だけ違うバージョンのものがあることは許さないってこと。  セキュリティ文脈での適用:サプライチェーン・セキュリティの確保 社内共通のセキュリティ処理は、コピペ実装ではなく「ライブラリ」としてバージョン管理し、脆弱性対応を追跡可能にする。  得られる効果:追跡可能性  脆弱性が発見された際、「どのバージョンを使っているか」で影響範囲を即座に特定できる。  ※ライブラリがバージョン管理されていなかったら、大規模であったとき死にます
32. 閉鎖性共通の原則(CCP)  思想:同じ理由で変更するものは一つにまとめるべき。  単一責任原則のよりマクロ版  関連する変更が複数のコンポーネントに飛び火しないようにする。  セキュリティ文脈での適用:セキュリティ・ホットスポットの凝集 認証・認可・監査ログなど、セキュリティ要件変更で修正されるクラス群を一つのコンポーネント（パッケージ/サイドカー）に集める。  得られる効果:修正漏れ防止 セキュリティパッチを当てる箇所が1箇所で済み、修正漏れによる脆弱性放置を防ぐ。  代償:どうしてもコンポーネントの粒度が大きくなりがち
33. 全再利用の原則(CRP)  思想:不要なものに依存させるな  使わない機能が含まれる巨大なライブラリに依存しない。  使う側は、使われる側の機能群をすべて使うべき。一部使わないなどを意識しなくていいようにすべき。  セキュリティ文脈での適用:最小権限と不要機能の排除 「ハッシュ計算」だけしたいのに、巨大なフレームワーク全体をimportしない。不要な機能は攻撃の足がかりになる。  得られる効果:アタックサーフェス縮小 依存ライブラリの脆弱性リスク（Supply Chain Attack）を最小限に抑える。 不要なものへの依存を排除することで、最小権限の原則の保証につながるから。
34. ※3つをともに満たすことはできない REP、CCP、CRPは同時に２つまでしか満たせない。  戦略的使い分け  安定しているコンポーネントには、REP&CRP ⇒変更時のリスクには弱い。  不安定なコンポーネントには、CCPをまず最優先 ⇒再利用性は捨てざるを得ない。  時間経過でセキュリティコンポーネントの特性が変わる ので、そこに着目しどれを満たすべきか考える。
35. DRY(DON'T REPEAT YOURSELF)  思想:知識の重複を避ける  全く同じロジックを複数箇所に書くと、修正時に漏れが出る。  一か所にまとめて修正コストを抑える。  似てるだけのものはまとめてはいけない。  セキュリティ文脈での適用:防御機構の一元化 入力値検証（バリデーション）や権限チェックを各画面で書くな。 一箇所の共通関数やゲートウェイに集約せよ。  得られる効果:堅牢性の統一 「A画面はXSS対策済みだが、B画面は忘れていた」という事故を構造的に 防ぐ。
36. KISS(KEEP IT SIMPLE, STUPID)  思想:シンプルにしておけ、たわけ!!  複雑なコードは読みにくく、バグの温床になる。  有能ぶりたい、高度なもの試したいがために、他人の読めないコードにすることなかれ。  セキュリティ文脈での適用:理解可能なセキュリティ  「独自の暗号化」や「複雑怪奇なロール管理」を作るな。誰も検証できない仕組みは、必ず破られる。  標準技術をシンプルに使いましょう。  得られる効果:バグの排除  仕様がシンプルであればあるほど、監査しやすく、論理的な抜け穴（Logic Flaw）がなくなる。  シンプルなほど、今までの原則を満たしやすくもなります。
37. PIE原則  思想: コードの意図(コンテキスト)を明確に表現せよ String email を撲滅し、VerifiedEmail 型を使う。  セキュリティ文脈での適用: 不正な値（XSS文字列など）が存在できない「型」を作ることで、バリデーションロジックをシンプルに保つ。  得られる効果:  インジェクション攻撃の構造的排除  バリデーションの集約(DRY)  Fail Fast:不正データはシステムの入り口で弾かれ、深層部のビジネスロジックやDBには広がらない
38. SLAP(抽象化レベル統一の原則)  思想:関数内の抽象度、構造の抽象度を統一せよ  「本を貸し出す」という高レベルな関数の中に、「DB接続のバイト配列操作」という低レベルなコードを混ぜない。  本の目次のように記述する。  セキュリティ文脈での適用:ポリシー（意図）とメカニズム（実装）の分離 「送金権限チェック（高レベル）」と「AES暗号化のパディング処理（低レベル）」を同じ関数に書かない。  得られる効果:監査容易性と認知負荷の低減  セキュリティレビュアーが「ロジックの不備（権限チェック漏れ）」を探す際、暗号化の複雑なコードに惑わされず、一瞬でフローの正 しさを検証できる。  セキュリティテストも書きやすい。  KISSにもつながる。
39. 原則同士の関係性  SOLID原則で「守りやすい構造」を作る  コンポーネント原則で「リスクの境界」を引く  複雑さはセキュリティの敵 これらの原則は『きれいなコードを書くため』だけのものだと思われがち。 違います。これらは『守るための戦術』に変換できる。
40. 具体例  SRP（単一責務） これは『計算ロジック』の中に『認証コード』を混ぜるな、ということです。 混ざっていると、計算のバグを直すついでに、うっかり認証を無効化してしまうかもしれない。分かれていれば、そんな事故は起きません。  CCP（閉鎖性共通） 認証ルールの変更があった時、あちこちのマイクロサービスを修正して回るのは悪夢です。一箇所直し忘れたら、そこがセキュリティホール になります。だから、セキュリティに関わるものは一箇所に集める（凝集させる）んです。 つまり、セキュリティにおいて、『コードが読みやすい』ことは『脆弱性を見つけやすい』ことと同義です。
41. コンポーネントの原則による再編 (CCP)  認証・認可ロジックが各UseCaseに散らばっている（DRY違反）。  CCP (閉鎖性共通の原則)の適用: 「同じ理由（セキュリティポリシー変更）で変更されるものは、一つにまとめよ」。  対策: 共通の SecurityGateway や Sidecar コンポーネントを切り出し、そこに凝集させる。
42. つまり!!  セキュリティにおいて、『コードが読みやすい』ことは『脆弱性を見つけやすい』ことと同義。  『保守性の高いコード』とは、そのまま『脆弱性の入り込みにくいコード』なのです。
43. 本日のまとめ
44. 一連の流れ ① Structure: クリーンアーキテクチャで「守る場所」を隔離する。 ② Model: DDD/GRASPで「データ」をカプセル化する。 ③ Attack: 脅威モデリングで「死角」を見つける。 ④ Refine: 原則（CCP/DIP/KISSなど）で「構造」を強化する。 完璧なセキュリティは存在しない。しかし、「堅牢なアーキテクチャ」は存在する。 毎回コードを直すのではなく、「設計」で勝負しよう。そのためには、クリーンアーキテクチャの設計思想が必須。 良いアーキテクチャは、変更に強く、攻撃にも強い。また、カオス実験とかも行いやすい。
45. 原則や設計パターンの補足は各自  今日触れた原則などはごく一部です。  各々以下の本で原則や設計パターンを抑えるべし。
46. 次回予告  Architectureと組織構造は切り離せない。まだ組織設計の話はしてません。  セキュリティコンポーネントの設計から、セキュリティ組織の構造設計を扱います。
47. ありがとう ございます QIITA:せやかて駆動 X:ユミ駆動(アーキテクトの女王)