堅牢なソフトウェアシステムを設計するには、機能的な論理だけでは不十分である。セキュリティに基づく基盤が不可欠である。アーキテクトがインフラを可視化する際、UMLデプロイメント図を用いてハードウェア、ソフトウェア、通信経路をマッピングする。しかし、標準的な図では、保護に必要な重要なセキュリティ層がしばしば見過ごされる。デプロイメントモデルにセキュリティ上の考慮事項を直接組み込むことで、脆弱性が設計段階で発見され、本番環境での発見を防ぐことができる。
このガイドでは、UMLデプロイメントモデリングにセキュリティ制御、信頼境界、コンプライアンス要件を組み込む方法を検討する。セキュリティをアーキテクチャ図における第一の要素として扱うことで、チームは脅威に対して初期段階から耐性を持つシステムを構築できる。
🏗️ デプロイメントの状況を理解する
UMLデプロイメント図は、システムの物理的アーキテクチャを表す。アーティファクト、ノード、それらの間の接続を示す。セキュリティの注釈がなければ、この視点は純粋に構造的なものに留まる。セキュアな状態にするためには、以下の要素を理解する必要がある。
- ノード：これらは物理的または仮想的なコンピューティングリソースを表す。サーバー、ルーター、クラウドインスタンスなどが含まれる。
- アーティファクト：これらは実行可能コード、データファイル、ライブラリなどの物理的な情報の断片を指す。
- 通信経路：ノード間でデータを交換できるネットワークリンクを指す。
これらの要素をモデル化する際、すべてのノードにセキュリティ文脈を適用しなければならない。一般的なサーバーノードでは不十分である。公開向けのウェブサーバーと内部データベースサーバーの違いを明確にすべきである。その違いは、それぞれに求められるセキュリティポジションにある。
🔒 ノードおよびハードウェアのセキュリティ確保
ノードはソフトウェアが実行される物理的または仮想的なエンドポイントである。セキュリティを重視したモデルでは、すべてのノードに、ハードニングおよびアクセス制御に関する特定の属性が必要となる。
物理的ノードと論理的ノード
デプロイメントモデルでは、物理的ハードウェアと論理的インスタンスを混同することが多い。セキュリティモデリングでは、これらを明確に分離する必要がある。
- 物理的ノード：これらはサーバーやIoTデバイスなどの実際のハードウェアを表す。セキュリティ上の考慮事項には、物理的アクセス制御、改ざん防止、環境制御が含まれる。
- 論理的ノード：これらは仮想マシン、コンテナ、クラウド関数を表す。ここでのセキュリティ上の考慮事項は、隔離、ハイパーバイザーセキュリティ、ランタイム環境に集中する。
ハードウェアセキュリティモジュール（HSM）
重要なシステムは、暗号化操作のために専用のハードウェアに依存することが多い。図では、これらを専用のノードとして明示的にモデル化すべきである。これにより、鍵管理がソフトウェアメモリで行われているのではなく、安全なハードウェア境界内で行われていることが強調される。
サーバーのハードニング状態
各サーバーノードには、そのセキュリティ構成に関するメタデータを保持すべきである。これには以下が含まれる：
- オペレーティングシステムのバージョンおよびパッチレベル。
- ノード上で有効なファイアウォールルール。
- ウイルス対策ソフトまたはエンドポイント保護の状態。
- 監査ログのためのログ機能が有効化されているか。
これらの詳細を注釈することで、アーキテクトは最終的なインフラ構成において、パッチが適用されていないか、監視されていないノードが存在しないことを保証できる。
💾 アーティファクトおよびデータストアの保護
アーティファクトはノードにデプロイされるファイルやコンポーネントです。すべてのアーティファクトが同じリスクプロファイルを持つわけではありません。一部は機密データを含む一方、他のものは公開ライブラリです。セキュリティモデリングでは、機密性および整合性要件に基づいてこれらを区別する必要があります。
データ分類
デプロイメントモデル内のデータストアは、分類レベルに応じてラベル付けされる必要があります。一般的なカテゴリには以下が含まれます：
- 公開：可用性を超えるセキュリティ制御は不要。
- 社内：組織ネットワーク内でのみアクセス可能。
- 機密：暗号化と厳格なアクセス制御が必要。
- 制限：規制遵守対象の極めて機密性の高いデータ。
静止時暗号化
データストアをモデリングする際、データが保存されている間に暗号化されているかどうかを図示する必要があります。これはコンプライアンスおよびデータ保護にとって不可欠です。ノードに制限データが格納されている場合、アーティファクトストレージには暗号化記号またはメモを付記する必要があります。
以下のシナリオを検討してください：
- データベースサーバー：フルディスク暗号化または機密フィールドのカラムレベル暗号化を示すべきです。
- ファイルサーバー：特定の文書タイプに対して暗号化が必要になる場合があります。
- キャッシュサーバー：セッショントークンを保持することが多く、厳格なメモリ分離を要します。
アーティファクトの整合性
デプロイされたコードが改ざんされていないことを確認することは重要です。デプロイメントモデルは、デジタル署名やチェックサムなどのアーティファクト検証メカニズムを反映すべきです。これにより、ノード上で実行されるのは信頼できるソフトウェアのみであることが保証されます。
🔗 通信経路の保護
ノード間の接続は、システムの最も弱い部分であることが多いです。これらの経路を通過するデータは、傍受、改ざん、サービス拒否攻撃の対象になりやすいです。デプロイメント図では、通信に使用されるセキュリティプロトコルを明確に定義する必要があります。
プロトコル仕様
ノード間の汎用的な線は曖昧です。各リンクはプロトコルおよびセキュリティ層を明記する必要があります：
- HTTPS/TLS：WebトラフィックおよびAPI呼び出しに必須。
- SSH：安全なリモート管理用。
- IPSec: サイト間トンネル接続に使用されます。
- 暗号化されていないTCP:避けるべきであり、避けられない場合はリスクとして強調すべきです。
ポート管理
ノード上で開いているポートは、その攻撃面を定義します。図では、管理者は外部ネットワークと内部ネットワークのどちらにポートが公開されているかを記録すべきです。これにより、不要な公開を特定するのに役立ちます。
重要な考慮事項には以下が含まれます：
- イングレスポート： トラフィックはノードのどこから入りますか？
- エグレスポート： トラフィックはノードのどこから出ますか？
- 管理ポート：管理に使用されるポートは、決してパブリックインターネットに公開してはいけません。
帯域幅とレート制限
セキュリティは可用性も含みます。サービス拒否攻撃は通信経路を標的にします。モデルはレート制限ポリシーを検討すべきです。図の要素として常に描かれるわけではありませんが、アーキテクチャはトラフィック洪水を軽減するロードバランサーやファイアウォールを考慮すべきです。
🛡️ 信頼境界とゾーンの定義
信頼境界は展開モデルにおいて重要です。信頼が終わる場所と検証が始まる場所を定義します。信頼境界を越えるには認証と承認が必要です。これらのゾーンを可視化することで、ステークホルダーがセキュリティチェックが行われる場所を理解しやすくなります。
ネットワークセグメンテーション
ノードは論理的なセキュリティゾーンにグループ化すべきです：
- DMZ（非武装地帯）：内部リソースから分離された、外部向けのサービス。
- 内部ネットワーク：コアビジネスロジック用の信頼できるインフラストラクチャ。
- 管理ネットワーク：ユーザーのトラフィックから分離された、管理作業専用のネットワーク。
- 隔離ゾーン：セキュリティリスクにより隔離が必要なシステムのため。
信頼レベル
各ゾーンは異なる信頼レベルを表します。低信頼ゾーンから高信頼ゾーンへデータが移動する際は、厳密な検査が必要です。展開図では、これらの境界を越えるデータの流れと関連するセキュリティゲートを示すべきです。
ファイアウォールルール
ファイアウォールはこれらのゾーンの強制ポイントです。モデルでは、ファイアウォールはゾーン間のノードまたはゲートウェイとして表現されるべきです。ルールは、どのトラフィックが通過を許可されているかを示すように要約されるべきです。
| ゾーン | 信頼レベル | アクセス制御 | 暗号化必須 |
|---|---|---|---|
| パブリックインターネット | 信頼できない | ホワイトリストのみ | はい（TLS 1.2以上） |
| DMZ | 低 | 制限されたイングレス | はい |
| 内部ネットワーク | 中 | ロールベース | オプション（内部） |
| 管理ゾーン | 高 | MFA必須 | はい（強力） |
🆔 認証と承認のモデル化
セキュリティとはハードウェアだけの話ではない。リソースにアクセスできるのは誰で、何であるかが重要である。認証（あなたが誰か）と承認（あなたができる操作）は、インフラ構造と並行してモデル化されなければならない。
IDプロバイダー
集中型のID管理を図示すべきである。システムが認証に特定のIDプロバイダーを使用する場合、このノードはすべての依存サービスにリンクされるべきである。これにより、依存関係と潜在的な単一障害点が明確になる。
認証メカニズム
各ノードまたはサービスは、サポートする認証方法を示すべきである：
- シングルサインオン（SSO）： ユーザー向けアプリケーション向け。
- APIキー： サービス間通信用。
- 証明書： マシン間通信用。
- OAuth/OIDC： 代理承認用。
承認ポリシー
承認ロジックは、デプロイメントモデルのメモに記録されるべきです。たとえば、データベースノードはアプリケーションサーバからの読み取りアクセスを許可するが、書き込みアクセスを拒否する場合があります。これらの権限がデータフローのセキュリティを定義します。
⚖️ 合法性および規制マッピング
多くの業界は厳格な規制フレームワークの下で運営されています。デプロイメント図は、法的遵守を確保するためにこれらの要件を反映しなければなりません。コンプライアンスをモデル化しないと、アーキテクチャ上の負債や法的罰則につながる可能性があります。
主要な規制
業種によっては、特定の基準が適用されます：
- GDPR：インフラ構造内にデータ保護および消去権の機能を備えることを要求します。
- HIPAA：健康データのアクセスおよび保存に対して厳格な制御を義務付けます。
- PCI-DSS：決済カードデータの取り扱いおよび保存方法を規定します。
- SOC 2：セキュリティ、可用性、処理の整合性に焦点を当てる。
データ所在
一部の規制では、データが特定の地理的境界内に留まることが求められます。デプロイメントモデルはノードの物理的位置を示す必要があります。これにより、地域法に違反してデータが国境を越えないことを保証します。
監査証跡
コンプライアンスはしばしばログ記録を要求します。図はログが生成され、どこに保存されるかを示す必要があります。ログ保存ノードは運用ノードとは別に配置され、ログ改ざんを防ぐ必要があります。
🐛 図面における脆弱性の特定
適切に構成されたデプロイメント図は、脆弱性の特定ツールとして機能します。システムを可視化することで、アーキテクトはコードを書く前から弱点を発見できます。
単一障害点
重要なノードにバックアップや冗長性がない場合、リスクを示します。図は高可用性構成を強調すべきです。クラスタリングや負荷分散が可視化されており、耐障害性が示されるべきです。
公開された管理インターフェース
管理インターフェース（SSHやRDPなど）は攻撃者の一般的な侵入経路です。図でこれらがインターネットに公開されている場合、赤信号です。これらはバストンホストまたはジャンプボックスを経由してルーティングされるべきです。
暗号化されていないチャネル
暗号化の表記のない図の任意の線は潜在的なリスクです。セキュリティレビューはこれらの線に注目し、暗号化のアップグレードを義務づけるべきです。
🧠脅威モデリングの統合
デプロイメントモデリングは、形式的な脅威モデリングの前段階です。インフラ構造がマッピングされると、チームはSTRIDEなどの手法を適用して、アーキテクチャ固有の脅威を特定できます。
脅威のカテゴリ
以下の脅威を図の要素にマッピングしてください：
- なりすまし：攻撃者はノードやユーザーを偽装できるか？
- 改ざん：送信中または保存中のデータが改ざんされる可能性はあるか？
- 否認：ユーザーは実行した行動を否認できるか？
- 情報漏洩：機密データがログやメモリに漏洩しているか？
- サービス拒否：システムが過負荷になる可能性はあるか？
- 特権の昇格：ユーザーが付与されたアクセス権より高いアクセスを得られるか？
データフロー分析
図全体を通してデータフローを追跡してください。機密データはどこから始まり、どこで終了しますか？どのポイントで変換されますか？各変換ポイントは潜在的な脆弱性です。
🔄 セキュリティ整合性の維持
デプロイメント図は静的な文書ではありません。インフラ構造の変更、パッチの適用、新しいサービスの追加が行われます。モデルはセキュリティ整合性を維持するために進化しなければなりません。
バージョン管理
デプロイメントモデルはコードベースと併せてバージョン管理されるべきです。これにより、チームは時間の経過とともにアーキテクチャの変更を比較し、セキュリティ更新を監査できます。
自動検証
現代的なツールは、図をセキュリティポリシーと照合して検証できます。新しいノードが暗号化なしで追加された場合、ツールはそれを警告すべきです。これにより、モデルが正確かつ安全であることが保証されます。
定期的な監査
デプロイメントモデルの定期的なレビューは必須です。セキュリティチームは物理的インフラが論理モデルと一致していることを確認すべきです。両者のずれはセキュリティの穴を生じさせます。
📝 最良の実践の要約
UMLデプロイメントモデリングにセキュリティを統合することは戦略的な必須事項です。セキュリティを反応的なチェックから予防的な設計要素へと移行します。これらのガイドラインに従うことで、設計段階から安全なアーキテクチャを構築できます。
実装における重要なポイントは以下の通りです：
- ノードに注釈を付ける：すべてのサーバーおよびデバイスについてセキュリティ状態を定義する。
- パスにラベルを付ける：すべての接続においてプロトコルおよび暗号化を指定する。
- ゾーンを定義する：信頼境界およびセグメンテーションを明確にマークする。
- 認証をモデル化する：アイデンティティおよびアクセスの管理方法を示す。
- コンプライアンスをマッピングする：規制要件が可視化されることを確認する。
- 定期的に更新する：図を環境と同期させ続ける。
セキュリティは継続的なプロセスである。デプロイメント図はその旅路の地図である。明確で正確かつセキュリティを意識した地図があれば、旅の途中から終点まで安全を確保できる。
