課題提起
疑問
なぜ、クリーンアーキテクチャとか、関心の分離、SOLIDなどのソフトウェアアーキテクチャの設計原則や、思想がセキュリティ機能の文脈に全然登場しないのでしょうか？
あたり前にこれらの原則は暗黙的に使われるべきなのに、なんとなくでセキュリティ設計されている印象です。
歴史的背景
歴史上、ソフトウェアアーキテクチャの世界とセキュリティアーキテクチャの世界が、異なる専門家によって、異なる言語で、異なる目的意識をもって発展してきたという、根深い背景があるからです。
この２つの世界に、明確な認知境界線が引かれてしまっている
わけです。
DevSecOpsの理想系
しかし、「あたり前にソフトウェアの原則は暗黙的に使われるべき」という考えは、まさに現代のDevSecOpsが目指す理想の姿そのものだったりします。
まはや、DevSecOpsのためには、
クリーンアーキテクチャ本に載っているような設計原則
プリンシプルオブプログラミングにあるような代表的原則集
これらは、マストでお作法として押さえておくべきものです。
なぜ、そのギャップは存在するのか？
🏰 アナロジー：城の建築家と、城の警備隊長
ソフトウェアアーキテクト（城の建築家）
関心事
住みやすさ、増改築のしやすさ、部屋（ドメイン）の適切な配置、効率的な動線（データフロー）。
原則
関心の分離、SOLID原則、ドメイン駆動設計。
これらは 「良い城を、長く使えるように建てる」 ための設計思想です。
セキュリティアーキテクト（城の警備隊長）
関心事
敵の侵入経路、城壁の弱点、見張り台の配置、兵士の巡回ルート。
原則
脅威モデリング(STRIDE)、多層防御、最小権限の原則。
これらは 「あらゆる攻撃から城を守り抜く」 ための戦術です。
歴史背景
歴史的に、この両者は別の専門家でした。
建築家はまず城を建てます。
その後に警備隊長が「この城はここが弱いから、ここに堀を作ろう」「この扉は貧弱だから、もっと頑丈なものに替えよう」と後からセキュリティ対策を施してきたのです。
これが、
セキュリティが「アドオン（追加機能）」のように扱われ、アーキテクチャの文脈で語られてこなかった大きな理由です。
しかし優れた設計原則は「最高のセキュリティ」である
ですが、クリーンアーキテクチャのような優れた設計原則は、それ自体が極めて強力なセキュリティ基盤を提供します。
両者の目的は、実は同じ方向を向いているんです。
以下の表で見比べてみてください。
クリーンアーキテクチャとセキュリティ価値の関係
クリーンな構造の場合
優れたソフトウェアアーキテクトが建てた城は、各部屋の配置が合理的であり、重要な部屋（クラウンジュエル系）は建物の中心にあり、廊下も見通しが良いため、
警備隊長から見ても「そもそも守りやすい城」 になっているのです。
ダーティーな構造の場合
構造がわかりにくいアーキテクチャの場合、そもそもセキュリティ担当である、
警備隊長から見ると、「どこに重要な資産があるのかわからない。攻撃がどこから来るのかもわかりにくい。」 といったことに繋がります。
結果、セキュリティアーキテクチャも保守のしにくいものになります。
時代の変化：DevSecOpsによる世界の融合 🤝
そして、冒頭で触れた、セキュリティとソフトウェアアーキテクチャの認知領域における境界は、まさに現代のソフトウェア開発が解決しようとしている課題そのものです。
「後から警備隊長がチェックする」というウォーターフォール的な開発では、もう現代のスピードには追いつけません。
そこで、「建築家自身が、警備隊長の視点を持って設計する」 というDevSecOpsやシフトレフトの考え方が主流になってきているのが今のDevSecOpsです。
シフトレフト
セキュリティの活動を、開発プロセスの後半（右手側）から、設計・開発といった前半（左手側）に移行させること。
セキュリティチャンピオン
開発チーム内に、セキュリティの知識を持つメンバーを配置し、設計段階からセキュリティを考慮に入れる制度。
これからの時代、クリーンアーキテクチャやドメイン駆動設計を語ることは、それ自体がセキュリティアーキテクチャを語ることと同義になっていきます。
なので、セキュリティアーキテクト、セキュリティエンジニアの皆さん、冒頭で説明した、２冊の原則集を常識にしちゃいましょう。
ドメインモデリングと脅威モデリングを同時に
実は、設計よりももっと前尾工程のドメインモデルを定義した段階から、脅威モデリングを行うアプローチは、セキュリティを
「後付けの鎧」から「設計に組み込まれた免疫システム」へ
と変える、極めて効果的で先進的な考え方です。
先に投資
どうせ後から、
「これはクリーンアーキテクチャの同心円でいう、どの層のセキュリティなのか？」
を考え、各領域にセキュリティ機能を綺麗に配置していくくらいなら、
初期のドメインモデルの段階からやってしまった方が、後になってからのセキュリティ機能のリファクタリングとか、そのために必要なテスト設計工数を節約できます。
ドメインモデルの段階で脅威モデリングを行うことで、非機能テストの優先順位付けは劇的に速く、そして正確になります。
ECRSが暗黙的に使われている
実は、暗黙的にECRSが適用されています。
まず、脅威モデリングを行う順番が入れ替えられています。(ECRSのR)
そして、ドメインモデリングとセットで脅威モデリングを行うので、ECRSのCも適用されています。
なぜ、それがそれほど効果的なのか？
アナロジーとして、「宝の地図と海賊の襲撃計画」で考えてみましょう。
ドメインモデル：「宝の地図」に相当
ここには、ビジネスにとって最も価値のある資産（顧客データ、注文情報、決済ロジックなど）がどこにあるかが、明確に描かれています。
私のオススメは、RDRAのモデルを使って、情報モデルをマクロなドメインモデルとして
扱ってしまうことです。
前提として、わたしはRDRAの情報モデルの各情報エンティティは、
より具体なレイヤーで集約の範囲を特定し、その集約のルートエンティティを
RDRAの情報モデルに出すようにしています。
脅威モデリング：「海賊の襲撃計画を立てる」ことに相当
この宝の地図を見て、「どこを攻撃すれば最も効率的に宝を盗めるか？」「どのルートを通れば見つかりにくいか？」を、攻撃者の視点でシミュレーションします。
設計の初期段階でこの2つを組み合わせることで、守備側（ブルーチーム）は、
海賊がどこを狙ってくるか？ を事前に予測できます。
そのため、「どの宝の周りに最も屈強な兵士を配置し、どの道に最も巧妙な罠を仕掛けるべきか」という 防衛戦略（＝テスト戦略） を、迷うことなく立てることができるのです。
ドメインモデルからの具体的なテスト優先順位の導出
ドメインモデルの各要素に対して脅威モデリング（例：STRIDE）を適用すると、テストすべきことが驚くほど明確になります。
以下に、各ドメインモデルの要素と、それに対する脅威分析、非機能テストという順の
マトリクス表を貼っておきます。
無駄なテスト削減をし、本来もっとテストが必要な所への優先的なテスト投資 のため、
わたしは先に脅威モデリングを行い、その成果物をもとにテスト計画を立てることを推奨しています。
結論：勘から科学へ
このアプローチを取らない場合、非機能テストは
「一般的なベストプラクティスだから」「過去に問題があったから」といった、
経験や勘に頼りがちになります。
しかし、ドメインモデルというビジネス価値の設計図を起点に脅威を分析することで、テスト戦略は以下のように進化します。
網羅的から集中的へ
すべてを均等にテストするのではなく、ビジネスリスクが最も高い領域にリソースを選択集中できます。
抽象的から具体的へ
「セキュリティをテストする」という曖昧な目標が、
「注文の改ざんを防ぐための整合性テストを行う」 という実行可能なタスクに変わります。
手遅れから先手へ
実装が完了してから脆弱性を探すのではなく、設計段階で弱点を予測し、最初からある程度堅牢な実装と、それを検証するテストを計画できます。
まさしく、これはシフトレフトの思想そのものであり、品質とセキュリティを開発の初期段階に組み込むための、最も合理的で強力な方法です。
詳しくは、以下の記事を参考にしてください。