ソフトウェアアーキテクチャ図は、技術チームにとって主なコミュニケーションツールです。抽象的な要件と具体的な実装の間のギャップを埋めます。しかし、標準的なアーキテクチャ図は機能性とデータフローにのみ焦点を当てがちです。セキュリティ制御、信頼境界、脅威軽減戦略といった重要な層をしばしば見過ごします。設計段階でセキュリティを後回しにすると、コードが1行も書かれる前からシステムに脆弱性が埋め込まれてしまいます。

C4モデルは、図の階層を通じてソフトウェアアーキテクチャを文書化する構造的なアプローチを提供します。C4階層の各レベルにセキュリティの観点を統合することで、アーキテクトはリスク、コンプライアンス、保護メカニズムを明確に伝える視覚的言語を構築できます。このガイドでは、特定のツールやベンダーに依存せずに、コンテキスト、コンテナ、コンポーネント、コードレベルの図にセキュリティ思考を組み込む方法を探ります。

🔍 図におけるセキュリティの可視化が重要な理由

セキュリティは、機能しなくなるまでしばしば目に見えません。ファイアウォールは通信をブロックし、暗号化はデータを混乱させ、認証はアイデンティティを検証します。これらのメカニズムは不可欠ですが、標準的な設計文書ではほとんど描かれません。セキュリティが隠されていると、監査が難しくなり、新規メンバーが理解しにくくなり、進化する脅威に対して守りにくくなります。

アーキテクチャ図にセキュリティを組み込むことで、いくつかの明確な利点があります：

• 共有された理解：セキュリティチームと開発チームは異なる言語を話します。アプリケーションのフローと同様の図にセキュリティ制御を可視化することで、双方の理解を一致させます。
• 脅威の特定：図はデータフローを強調します。すべてのデータフローは潜在的な攻撃ベクトルです。これらの経路を可視化することで、データが漏洩または改ざんされる可能性がある場所を特定しやすくなります。
• コンプライアンス監査：規制はしばしばデータ保護対策の証明を要求します。適切に注釈が施されたアーキテクチャ図は、設計段階でのセキュリティ制御の証拠となります。
• インシデント対応：セキュリティインシデント発生時、データがどこに存在し、どのように移動しているかを理解することは極めて重要です。図は、対象範囲の制限と是正のための地図を提供します。

🏗️ C4モデル階層の概要

C4モデルは、ソフトウェアアーキテクチャ文書化の階層的アプローチです。全体像から実装の詳細までスケーリングできます。各レイヤーは異なる対象者を対象とし、異なる粒度の情報を提供します。適切なレイヤーにセキュリティを統合することで、正しい情報が正しい人に届くことを保証します。

1. コンテキスト図（レベル1）：システムとその環境の関係を説明します。ユーザーと外部システムに焦点を当てます。
2. コンテナ図（レベル2）：高レベルの技術的構造を説明します。ウェブアプリ、モバイルアプリ、データベースなどのソフトウェアシステムを示します。
3. コンポーネント図（レベル3）：単一のコンテナの高レベル設計を説明します。コントローラー、サービス、リポジトリなどの構成要素を示します。
4. コード図（レベル4）：単一コンポーネントの実装を説明します。クラスやメソッドを示します。外部に共有されるのはめったにありませんが、内部のセキュリティレビューには不可欠です。

🌍 レベル1：コンテキスト図のセキュリティ

コンテキスト図は入門点です。システムの境界を定義します。このレベルでのセキュリティは、信頼境界とアイデンティティに関するものです。信頼ゾーンの内側と外側を明確に区別する必要があります。

🔑 アイデンティティとアクセス管理

コンテキストレベルでは、最も重要なセキュリティ要素は認証です。システムとやり取りできる人物を明示する必要があります。

• 人間のアクター：ユーザーを明確にラベル付けしてください。管理者ユーザーと通常のエンドユーザーを区別してください。管理者アクセスはしばしばより厳格な制御を必要とします。
• 外部システム： これらはしばしば最も弱いリンクです。どのように認証しているかを示してください。APIキー、OAuthトークン、または相互TLSを使用していますか？
• 信頼ゾーン： 信頼境界を示すために視覚的な手がかりを使用してください。実線は高信頼の内部接続を表す場合があり、破線は低信頼の外部接続を表します。

🔗 データフローのセキュリティ

コンテキスト図のすべての線はデータフローを表します。すべてのデータフローが同等というわけではありません。一部は機密情報を含み、他のものは公開されたステータス更新を含む場合があります。

• 暗号化要件： 送信中に暗号化が必要なフローをマークしてください。「HTTPS」または「WSS.
• 個人情報（PII）の取り扱い： データに個人を特定できる情報が含まれる場合は、そのフローをマークしてください。これにより、下流のチームが追加の保護を適用する必要があることを確認できます。
• 認証メカニズム： フローに認証が必要かどうかを示してください。たとえば、「Bearer Token」または「Session Cookie」の要件は、接続線に記載してください。

📦 レベル2：コンテナ図のセキュリティ

システム境界が確立されると、コンテナ図はそれをデプロイ可能な単位に分解します。ここでは技術的なセキュリティ制御が可視化されます。コンテナは通常、Webアプリケーション、モバイルアプリケーション、マイクロサービス、またはデータベースです。

🛡️ ネットワークセキュリティとゾーン

コンテナはしばしば異なるネットワークゾーンに分散しています。これらのゾーンを可視化することで、ネットワークセグメンテーションの理解が深まります。

• DMZ配置： 公開インターネットに露出しているコンテナを示してください。これらは最高レベルの検査を要します。
• 内部サービス： 内部専用のコンテナを示してください。これらは直接インターネットに露出してはいけません。
• ファイアウォールルール： 色分けや注記を使用して、どのコンテナ同士が通信を許可されているかを示してください。これにより、侵害が発生した場合の横方向移動を防ぎます。

🔐 データの静的保護

コンテナはしばしばデータを保存します。データベース、ファイルストア、またはメッセージキューのいずれであっても、ストレージメディアにはセキュリティが必要です。

• 静的暗号化：コンテナに格納されたデータが暗号化されているかどうかを示してください。これはコンプライアンスにとって重要です。
• 鍵管理：暗号化鍵がどこに格納されているかを示してください。コンテナ自体が鍵を管理しているのか、それとも外部の鍵管理サービスが管理しているのかを確認してください。
• データ分類：格納するデータの機密性に基づいて、コンテナにラベルを付けてください。公開, 社内用, 機密、または制限.

📡 プロトコルセキュリティ

コンテナ間で使用されるプロトコルは、内部通信のセキュリティポジションを決定します。

• 内部API：内部APIがプレーンHTTPを使用しないことを確認してください。接続にHTTPSまたはmTLSを用いたgRPC.
• サービスメッシュ：サービスメッシュが使用されている場合は、コンテナ間のトラフィックが自動的に暗号化および認証されることを示してください。
• レガシープロトコル：FTPや暗号化されていないSMTPなどのレガシープロトコルが使用されている場合は、修復が必要なリスク領域として強調してください。

⚙️ レベル3：コンポーネント図のセキュリティ

コンポーネント図は単一のコンテナ内部にまで深入りします。論理的な構成要素を示します。ここにセキュリティのロジックが実装されます。

🧩 認証および承認ロジック

セキュリティロジックはしばしばコンポーネントに分散されています。このロジックがどこに存在するかを示すことが非常に重要です。

• 認証ハンドラ：ユーザーのログイン処理を担当するコンポーネントを特定してください。これらは攻撃者にとって高価値の標的です。
• 承認ミドルウェア：アクセス制御チェックが行われる場所を示してください。コントローラレベルで行われているか、サービスレベルで行われているか？
• トークン検証：セキュリティトークンの検証を行うコンポーネントを示してください。この検証が中央集権化されている場合、セキュリティポリシーの不整合のリスクが低下します。

🛑 入力検証およびデータクリーニング

セキュリティ侵害はしばしば不適切な入力から始まります。コンポーネント図は入力が処理される場所を強調すべきです。

• エントリポイント：外部データを受け取るコンポーネントをマークしてください。これらはインジェクション攻撃に対する第一の防衛線です。
• データクリーニングロジック：データを保存または処理する前にクリーニングを行うコンポーネントを示してください。これにより、SQLインジェクションやクロスサイトスクリプティングを防止できます。
• 出力エンコーディング：データがユーザーに送信される前にエンコードされる場所を示してください。これにより、悪意のあるスクリプトがブラウザで実行されないことを保証します。

📊 ロギングおよびモニタリング

セキュリティ運用はログに依存しています。何が起きたかが見えなければ、侵害を検出することはできません。

• セキュリティログ：セキュリティ関連のログを生成するコンポーネントを特定してください。例として、ログイン失敗試行、権限拒否、構成変更などがあります。
• ログ集約：ログが送信される場所を示してください。中央集権的なログサービスに送信されていますか？これにより、コンポーネントが侵害された場合でもログが失われないことを保証します。
• 機密データのマスキング：ログが資格情報や機密データの漏洩を防ぐためにクリーニングされているかどうかを示してください。

🧠 レベル4：コード図のセキュリティ

コード図は最も詳細なレベルです。クラスやメソッドを示します。開発チーム外に共有されるのは稀ですが、深いセキュリティレビューには不可欠です。

🔒 暗号化操作

このレベルでは、暗号化がどのように使用されているかを正確に確認できます。

• ハードコードされたシークレット：コード構造内にハードコードされたAPIキーまたはパスワードがないか確認してください。これらは重大な脆弱性としてマークされるべきです。
• アルゴリズムの使用:強力なアルゴリズムが使用されていることを確認する。MD5やSHA1のような弱いアルゴリズムは避けるべきである。
• 乱数生成:セッションIDやトークンに暗号化された乱数生成器を使用することを確保する。

🧪 セキュリティ向けユニットテスト

セキュリティ要件はテストされなければならない。コード図はセキュリティテストが定義されている場所を示すことができる。

• セキュリティテストケース:セキュリティテスト専用のメソッドを特定する。これらは認証バイパス、インジェクション、アクセス制御をカバーすべきである。
• 統合テスト:セキュリティ制御が全体のシステムの文脈でどのようにテストされるかを示す。

🚧 信頼ゾーンと境界

C4モデルのすべてのレベルにおいて、信頼ゾーンは繰り返し登場するテーマである。信頼ゾーンとは、セキュリティ制御が一貫しており、境界が明確に定義された領域である。

ゾーンタイプ	信頼レベル	一般的な制御	図示表現
外部インターネット	ゼロトラスト	ファイアウォール、WAF、TLS	破線赤色の境界
DMZ	低信頼	厳格なフィルタリング、アクセス制限	破線オレンジ色の境界
内部ネットワーク	中程度の信頼	ネットワークセグメンテーション、認証	実線青色の境界
セキュアコア	高信頼	暗号化、鍵管理、監査	固い緑色の枠

これらのゾーンを可視化することで、ステークホルダーはシステムの異なる部分のリスクプロファイルを理解しやすくなります。DMZでの侵害は、セキュアコアを損なってはいけません。この概念は、ディフェンスインデプスと呼ばれます。

🧩 C4における一般的なセキュリティパターン

特定のセキュリティパターンは、アーキテクチャ全体で頻繁に出現します。これらのパターンを明示的に文書化することで、時間の節約と混乱の軽減が可能になります。

🔑 APIゲートウェイパターン

APIゲートウェイは、すべてのクライアント要求の単一のエントリポイントとして機能します。認証、レート制限、ルーティングを処理します。

• 配置： 外部ユーザーと内部コンテナの間に配置されます。
• セキュリティ役割： 個々のサービスからセキュリティロジックを移譲し、一貫したポリシーの適用を確保します。
• 図の注記： ゲートウェイに「AuthN/AuthZ」ラベルを付ける。

🔒 データ暗号化パターン

データは、保存時および送信中において保護される必要があります。これは基本的なパターンです。

• 送信中：すべてのネットワーク通信にTLSを使用する。
• 保存時：データベースおよびファイルストアを暗号化する。
• 鍵：鍵をデータとは別に保管する。

👁️ 監査ログパターン

すべての重要な操作はログに記録されるべきです。これはフォレンジック分析にとって不可欠です。

• ログに記録する内容：ユーザーの操作、システムの変更、セキュリティイベント。
• ログの整合性：攻撃者がログを改ざんできないようにする。
• 保持期間：コンプライアンスのためにログをどのくらいの期間保持するかを定義する。

🔄 メンテナンスと進化

セキュリティは一度きりの作業ではない。システムは進化し、脅威は変化し、新たな脆弱性が発見される。アーキテクチャ図もそれに合わせて進化しなければならない。

📅 図の更新

システムに変更が加えられた際には、図を更新すべきである。これにより、ドキュメントが真実の情報源のまま保たれる。

• 変更管理： 図の更新をデプロイメントパイプラインに統合する。
• レビュー周期： セキュリティチームと定期的にアーキテクチャ図のレビューをスケジュールする。
• バージョン管理： セキュリティコントロールの変化を時系列で追跡できるように、図のバージョンを保持する。

🧪 ローカル脅威モデル化の統合

脅威モデル化とは、潜在的なセキュリティ脅威を特定するプロセスである。これはC4図と連携して機能する。

• STRIDEモデル： 図の各要素を検証するために、STRIDEモデル（なりすまし、改ざん、否認、情報漏洩、サービス拒否、特権昇格）を使用する。
• データフロー分析： 図内のすべてのデータフローを確認する。各ステップでデータが保護されているかを確認する。
• 資産の特定： 図内に高価値の資産を特定する。セキュリティ対策の重点をこれらの資産の保護に当てる。

📝 セキュリティ図のチェックリスト

このチェックリストを使用して、C4図がセキュリティ対応していることを確認する。

• [ ] 信頼境界が明確にマークされているか？
• [ ] すべてのデータフローに、送信中の暗号化が示されているか？
• [ ] ストレージコンテナに対して、保存時の暗号化が示されているか？
• [ ] 認証ポイントがラベル付けされているか？
• [ ] 敏感なデータフローが強調されているか？
• [ ] 外部依存関係が特定され、評価されているか？
• [ ] ネットワークセグメントやゾーンが可視化されているか？
• [ ] ロギングおよびモニタリングポイントが示されているか？
• [ ] 知られている脆弱性が文書化されているか？
• [ ] 図面はコードの変更に合わせて常に最新の状態に保たれていますか？

💡 セキュリティ可視化に関する最終的な考察

セキュアなシステムを構築するには、セキュアなコードを書くこと以上に、セキュアな設計が必要です。C4モデルは、その設計を可視化するための堅実なフレームワークを提供します。コンテキスト図からコードレベルまで、すべてのレイヤーにセキュリティの考え方を組み込むことで、チームはデフォルトで耐障害性を持つシステムを構築できます。

セキュリティは共有された責任です。図面がセキュリティ制御を明確に伝えることで、開発者、運用担当者、セキュリティエンジニアはより効果的に協働できます。この共有された可視性によりリスクが低減され、提供されるソフトウェアに対する信頼が高まります。図面は動的な文書であることを思い出してください。それはその図面が表すコードと同じように扱われるべきです。