セキュリティ対策には設計図があります。少なくともアーキテクチャー図があります。しかし、何故かソフトウェアの場合は設計図もアーキテクチャー図も書けないセキュリティ対策が当たり前になっています。国際情報セキュリティ標準やセキュリティガイドラインを普通に理解すれば解ること、セキュリティ対策の基礎の基礎にも関わらず、です。

これは一般開発者の問題というより、セキュリティ専門家やセキュリティに詳しい開発者の問題でしょう。セキュリティ問題は十分に複雑な問題であることに異論はないと思います。複雑な問題を解くにはアーキテクチャー（構造化）と適切な設計が重要です。設計どころかアーキテクチャーさえないのは明らかに問題でしょう。設計となると細かな仕様が必要となります。ここではアーキテクチャーだけでも十分なのでこれだけを考慮します。

重要な事なので最初に書いておきます。セキュリティアーキテクチャー作る、は信頼境界線を書くことです。信頼境界の中に入れたモノ（入力やその他のモノ）であっても、普通は”何をしても安全なモノ”ではありません。安全性の為に更に詳細な入力検証が必要だったり、特定の権限を持つモノだけ許可したりするモノ、条件付きで信頼境界の中に入れるモノが普通にあります。また、信頼境界から出る時（出力）のセキュリティ対策は入力対策とは独立した対策です。これはよくある誤解なので注意しましょう。

信頼境界は”防衛線”です。”防衛線”での防御はITセキュリティ対策に限らず、全てのセキュリティ対策共通した防御策です。”防衛線”の”中に在るモノ”は”信頼できるモノ”であることを可能な限り保証します。”防衛線”を越えて”入るモノ”と”出るモノ”は可能な限り安全性を保証します。これが全てのセキュリティ対策共通の基本です。

※ 信頼境界を越えて検証されたモノ（物／人／データなど）が「全面的に信頼できると誤解される」ことがよくあります。検証されたモノであっても、検証された範囲／内容までしか信頼できません。全面的に信頼できるモノはほぼ無い、とゼロトラストで考える必要があります。

情報セキュリティのコンテクスト

情報セキュリティの場合、以下の”コンテクスト”にアーキテクチャー／設計が必要です。

• 物理的セキュリティー
• ネットワークセキュリティー
• ソフトウェアセキュリティー

これら3つを組み合わせた

• システムセキュリティー

アーキテクチャー／設計を考える場合、”コンテクスト”を分けます。建物を設計する場合、全ての設計図を１つにまとめるのではなく意匠図、構造図、設備図など分けることと同じです。別々の図面にしないと「マトモなモノが作れない」ことが図面／設計を分ける理由です。ITシステムのセキュリティーを考える場合、少なくとも上記4つのコンテクストのセキュリティアーキテクチャー（設計）が必要になります。

これら4つセキュリティーアーキテクチャーはそのまま信頼境界線図になります。セキュリティーアーキテクチャー ≒ 信頼境界線です。

ネットでセキュリティアーキテクチャーを検索するとソフトウェア以外のセキュリティアーキテクチャー図は比較的簡単に適当なモノが見つかります。

※ モノのセキュリティは物と者（人）のセキュリティに分けて考えるケースもよくあります。

物理的なセキュリティアーキテクチャー

次の図は物理的なセキュリティーアーキテクチャーを現した図です。

出典：http://www.nttwt.com/en/businessdomain/

この図ではデータセンターフロアの物理的なセキュリティ境界が赤い点線で書かれています。セキュリティ境界では「入るモノ」「出るモノ」をチェックします。

セキュリティ境界（＝信頼境界）でチェックするモノの例：

• 出入り可能な人
• 搬入可能なモノ
• 搬出可能なモノ

この図では省略されていますが、実際には多数の物理的なセキュリティ境界が多層に配置されているでしょう。

※ モノのセキュリティは物と者（人）のセキュリティに分けて考えるケースもよくあります。ここでは単純化の為に「物理的なモノ」と一括りにしています。まとめても「出入りする／接続するモノ」と考えて対応すればほぼ問題になりません。しかし、セキュリティ要件が厳しい場合は分けて考慮する方が良いです。

ネットワークのセキュリティアーキテクチャー

次の図はネットワークセキュリティのアーキテクチャー図です。

出典： http://www.chemanager-online.com/en/topics/safety-security/cyber-security-industrial-control-systems

ネットワークのレイヤー別にどのように接続、分離、管理されているか解る図になっています。この図では細かい仕様は判りませんが、セキュリティ境界（信頼境界）でセキュリティ制御が行われているであろうことがわかります。

セキュリティ境界（＝信頼境界）でチェックするモノの例：

• 接続可能なネットワーク（入力と出力）
• 接続可能なデバイス（入力と出力）
• 利用可能なプロトコル（入力と出力）

もう少し見慣れたネットワークのセキュリティ境界図は以下のようなモノだと思います。

出典：  https://www.cisco.com/c/en/us/td/docs/solutions/Enterprise/Data_Center/Virtualization/securecldeployg.html

出典： http://www.thecepblog.com/2016/08/27/nssa-a-holistic-perspective-of-network-security-by-pardeep-bhandari-and-dr-manpreet-singh/

システムのセキュリティアーキテクチャー

次の図はシステムレベル（物理、ネットワーク、ソフトウェアの組み合わせ）のセキュリティ境界（＝信頼境界）を表した図です。

出典：https://www.researchgate.net/figure/317546519_fig2_Fig-3-Trust-boundary-Layers-of-Use-Case

信頼可能なモノ（物理、ネットワーク、ソフトウェア）のレベルはどのような”検証”が行われているか？によって変ることがこの図から解ります。各信頼境界内ではモノが信頼可能であることが検証され、各信頼境界線上ではデータの入力と出力が検証されます。

次の図もシステムレベルのセキュリティ境界（＝信頼境界）を表した図です。

出典：https://msdn.microsoft.com/en-us/library/ff648647.aspx

この図の信頼境界ではWeb/Applicationサーバーとデータベースサーバーが同じ信頼境界の中に在ります。これをソフトウェアの信頼境界と誤解している例は少なくないので注意してください。物理的な信頼境界やネットワークの信頼境界がソフトウェアの信頼境界に成りえないことと同じで、システムの信頼境界はソフトウェアの信頼境界になりません。

ソフトウェアのセキュリティアーキテクチャー

次の図はソフトウェア（Webアプリケーション）の信頼境界の図です。点線が信頼境界線です。

出典：https://websec.io/2013/08/27/Core-Concepts-Trust-Boundaries.html

この図から分かるようにソフトウェアの信頼境界の限界は基本的に

• 最大でも同じプロセス／スレッド上のコードまで

であることが解ります。OSやOS上のファイルでさえ無条件では信頼できません。

そして、全てのコードは基本的に入力⇒処理⇒出力の構造を持っています。

この基本を理解した上でソフトウェアのセキュリティアーキテクチャーを考えると自然と（論理的に）以下のようなアーキテクチャーになります。

契約プログラミングを行った場合のセキュリティアーキテクチャーも、自然に（論理的に）上記の図のようなアーキテクチャーになります。

データのセキュリティ

情報セキュリティーアーキテクチャー／設計を考える場合には次の4つのコンテクストを分けて考えなければなりません。

• 物理的セキュリティー
• ネットワークセキュリティー
• ソフトウェアセキュリティー
• システムセキュリティー

これに加えて、データのセキュリティを別に考慮しなければなりません。コンピュータは何らかの入力データを受け入れ、それを処理し、処理後のデータを出力するモノです。この過程のどこかでデータが不正に漏洩したり、改ざんされたり、データに含まれた不正な命令を実行されたりすることが情報セキュリティの主なリスクです。全てのコンテクストで「データの入力と出力（不正な物も含む）」に十分に注意しなければなりません。

データ／ソフトウェアのセキュリティをマジメに考えれば考えるほど、入力検証の重要性が明らかになります。

セキュリティ対策が論理的に正しいか検証する方法

まとめ

セキュリティアーキテクチャー（信頼境界設計）は一種類だけではありません。設計対象によって種類があります。混同するとセキュリティ問題の原因になります。

自分のアプリケーションのセキュリティアーキテクチャーは？と聞かれて図に書けないならアーキテクチャーがありません。図に書けても「ソフトウェアの一番外側の境界」が信頼境界でない場合は理想的なセキュリティアーキテクチャーではありません。

常に理想的なアーキテクチャーである必要はありません。しかし、ネットワークをインターネットに接続する際にネットワークのエッジ（最外周の境界）にファイアーウォールを設置するのがベストプラクティスであることはソフトウェアでも同じです。エッジ（最外周の境界）に信頼境界がない、のはセキュリティが要求されるモノの場合は普通あり得ない設計です。セキュリティのプロならまずこのような脆弱な設計はしません。

沢山のソフトウェアのアーキテクチャーがありますが、残念ながらソフトウェアのセキュリティアーキテクチャーが考慮されてない実装は多数あります。（というよりほとんど考慮されていない方が多い）

ソフトウェアのセキュリティアーキテクチャーは図にすることが必要ない程単純で当たり前である、とコンピューターサイエンティストは考えていたと思います。プログラムを確実に意図通りに動作させる（攻撃者に不正な動作／インジェクションを行わせない）には、入力と出力を確実にすることは論理的に当然の事です。入力と出力対策は90年代はじめから繰り返し”文字”（防御的プログラミング）として提唱されてきたソフトウェアのセキュリティ対策です。

しかし、図にされた物となると、防御的プログラミングが提唱された90年代はじめ、セキュアコーディング／セキュアプログラミングが提唱された2000年代はじめ、知る限りではソフトウェアのセキュリティアーキテクチャー図を見たことがほぼありません。

図によるセキュリティアーキテクチャーが無かったことが原因なのかどうか判りませんが、残念ながら防御的プログラミング／セキュアコーディングが提唱されてから四半世紀以上経っても、ソフトウェアが安全に動作する為に必要な基本アーキテクチャーさえ持たないアプリケーションばかりです。この現状はソフトウェアセキュリティの基礎の基礎を理解していない「専門家」に、全てではなくても、責任があること明らかでしょう。IPAのセキュアプログラミング講座がマトモになったのはつい最近のことです。その前はセキュアプログラミングの基本さえ説明されず、入力対策と出力対策があべこべ、という酷い状態でした。

コンピューターサイエンティストは入力検証が重要なセキュリティ対策であることを少なくとも60年代から知っていました。「入力の検証がセキュリティ対策ではない／重要なセキュリティ対策ではない」と主張している人達はセキュリティ理解していない素人と言えます。セキュリティ専門家と言われている人の中には何十年もソフトウェアセキュリティの本質を理解していないで素人考えを主張し続けている方も居ます。今更修正できないので出鱈目でも主張し続けざるを得ないのかも知れませんが、ISO 27000等が推奨するセキュリティ対策の構造化を無視し、脆弱なソフトウェア量産の手助けをするのはいい加減に止めてほしいです。¹

”入力と出力が正しい”これがプログラムが正常の動作する為に必要な条件であることは半世紀も前から解っていることです。入力と出力に着目したセキュリティ設計／セキュリティアーキテクチャーがないソフトウェアが安全にならないのは当然でしょう。セキュリティが重要と言われて久しいですが「ソフトウェアのセキュリティ設計（セキュリティアキーテクチャー）が無い」アプリケーションばかりである状況は何時になったら改善されるのでしょうか？

参考：

ゼロトラストをより細かく分解する

ほとんどのセキュリティ問題はインジェクション問題 – インジェクションパターンとして理解すると簡単