はじめに – なぜこのドメインが重要なのか？
こんにちは！CISSPの学習、順調に進んでいますか？
CISSPのドメインは全部で8つありますが、その中でもドメイン3「セキュリティアーキテクチャとエンジニアリング」は、システムのセキュリティを根本から理解するために非常に重要な領域です。
このドメインは、単に個別のセキュリティ技術を知っているだけでなく、「どのようにすればシステム全体として安全になるのか」「どのような設計思想に基づいてセキュリティを組み込むべきか」といった、より本質的な考え方や原則を学びます。
このドメインをしっかり理解することは、CISSP試験の合格はもちろん、実際の業務でセキュリティの設計や評価を行う上でも強力な武器となります。
この記事では、CISSP受験を目指す皆さんを対象に、ドメイン3の主要なポイントを分かりやすく解説し、知識を深めるお手伝いをさせていただきます。さあ、一緒にセキュリティアーキテクチャとエンジニアリングの世界を探求しましょう！
ドメイン3の主要なテーマを深掘り
ドメイン3は広範なトピックをカバーしていますが、主に以下の分野に分けられます。
1. セキュリティモデルとアーキテクチャの概念
システムの設計を始める前に、どのようなセキュリティを実現したいのか、その基本的な考え方や枠組みを理解することが重要です。
セキュリティの基本原則（CIAトライアドなど）
セキュリティの最も基本的な目標は、以下の3つです。
- 機密性（Confidentiality）：許可された者だけが情報にアクセスできるようにすること。情報が漏洩しないように保護します。
- 完全性（Integrity）：情報が正確であり、許可されていない変更や破壊から保護されていること。情報の正確さと信頼性を維持します。
- 可用性（Availability）：許可された者が必要な時に情報やシステムにアクセスできること。システムが停止せず、利用可能であることを保証します。
これら3つは「CIAトライアド」と呼ばれ、セキュリティの基礎となります。さらに、誰が何を行ったかを追跡できる否認防止（Non-repudiation）や説明責任（Accountability）といった原則も重要です。
主要なセキュリティモデル
これらの原則を実現するために、さまざまなセキュリティモデルが提唱されています。
- Bell-LaPadula Model：主に機密性に焦点を当てたモデルです。情報の「読み込み」と「書き込み」に関するルールを定義し、格付けの高い情報が低いレベルに漏洩するのを防ぎます（「No Read Up（上位を読まない）」、「No Write Down（下位に書かない）」）。
- Biba Model：Bell-LaPadula Modelとは対照的に、主に完全性に焦点を当てたモデルです。情報の完全性を損なうようなアクセスを防ぎます（「No Read Down（下位を読まない）」、「No Write Up（上位に書かない）」）。
- Clark-Wilson Model：こちらも完全性に焦点を当てていますが、より実用的なビジネス環境を想定しています。特定の制約（Constrained Data Items: CDIs）に対して、定義された手続き（Transformation Procedures: TPs）を通じてのみ操作を許可し、完全性を維持します。
これらのモデルは、システムの設計やアクセス制御のメカニズムを考える上での理論的な基盤となります。
セキュリティアーキテクチャの設計原則
セキュアなシステムを設計するための一般的な原則がいくつかあります。
- 最小権限（Principle of Least Privilege）：ユーザーやシステムが必要最低限の権限のみを持つようにします。
- 職務分掌（Separation of Duties）：重要な業務プロセスを複数の担当者に分割し、一人による不正や誤操作を防ぎます。
- 多層防御（Defense in Depth）：単一のセキュリティ対策に依存するのではなく、複数の異なるセキュリティ対策を組み合わせて、防御を多層化します。
- フェールセーフデフォルト（Fail-Safe Defaults）：システム障害時や設定ミスが発生した場合でも、セキュリティが破綻しないように、デフォルトの動作を「拒否」や「制限」とする原則です。
- 最小機構（Economy of Mechanism）：セキュリティ機構は可能な限りシンプルに設計し、検証や管理を容易にします。
- 公開設計（Open Design）：セキュリティ機構のアルゴリズムや設計を公開しても、秘密に依存しないように設計します。セキュリティは設計の秘密ではなく、鍵やパスワードの秘密に依存します（Kerckhoffs’ Principle）。
- 完全仲介（Complete Mediation）：アクセス要求があるたびに、その正当性を毎回検証します。
- 心理的受容性（Psychological Acceptability）：セキュリティ対策が使いやすく、ユーザーの業務を妨げないように設計することで、ユーザーがセキュリティ対策を回避しようとするインセンティブを減らします。
2. セキュアなシステム設計と実装
セキュリティの原則とモデルを理解したら、それを具体的なシステムの設計と実装に落とし込みます。
セキュアな設計手法（SDLCへの組み込み、脅威モデリング）
システムの開発ライフサイクル（SDLC: Software Development Life Cycle）の初期段階からセキュリティを組み込むことが非常に重要です（これを「セキュリティ・バイ・デザイン」と呼びます）。
- セキュリティ要件定義：企画・要件定義段階でセキュリティに関する要件を明確にします。
- 設計段階でのセキュリティレビュー：設計がセキュリティ原則に沿っているか、脆弱な設計になっていないかを専門家がレビューします。
- 脅威モデリング：システムにどのような脅威が存在し、それらがシステムのどこを狙う可能性があるかを分析します。例えば、STRIDEモデル（Spoofing, Tampering, Repudiation, Information Disclosure, Denial of Service, Elevation of Privilege）などがあります。
- セキュアコーディング：開発者は、クロスサイトスクリプティング（XSS）やSQLインジェクションなどの脆弱性を生まないように、安全なコーディング規約に従います。
- セキュリティテスト：開発後のテスト段階で、脆弱性スキャンや侵入テストなどを実施します。
セキュリティコントロールの種類
セキュリティ対策は、その性質によっていくつかの種類に分けられます。
- 技術的コントロール（Technical Controls）：ファイアウォール、侵入検知システム（IDS）、アンチウイルスソフトウェア、暗号化、認証システムなど、技術的な手段でセキュリティを強制するものです。
- 管理コントロール（Administrative Controls）：セキュリティポリシー、手順、標準、リスク管理プロセス、セキュリティ教育・訓練、人事セキュリティなど、組織の方針や手続きに関連するものです。
- 物理的コントロール（Physical Controls）：警備員、鍵、フェンス、監視カメラ、環境制御装置（消火設備、温度/湿度管理）など、物理的なアクセスや環境を保護するものです。
効果的なセキュリティアーキテクチャは、これら異なる種類のコントロールを組み合わせて構築されます。
各種セキュリティ技術（設計観点から）
特定のセキュリティ技術が、アーキテクチャの中でどのように利用されるかを理解します。
- 暗号（Cryptography）：データの機密性や完全性を保護するために、どのように暗号化やハッシュ関数を利用するか（通信経路の暗号化、データの暗号化保存など）。
- アクセス制御（Access Control）：誰が（主体）、何に（客体）、どのような操作を（権限）許可されるかを管理する仕組み（DAC, MAC, RBACなどのモデルの適用）。
- 認証（Authentication）：ユーザーやシステムが主張する本人であることを確認する仕組み（多要素認証MFAの導入など）。
- 認可（Authorization）：認証されたユーザーやシステムに、どのような操作を許可するかを決定する仕組み。
3. エンタープライズセキュリティアーキテクチャ
個別のシステムだけでなく、組織全体の視点からセキュリティアーキテクチャを考えます。
標準フレームワーク（SABSA, TOGAFなど）
エンタープライズレベルでセキュリティを体系的に構築するためのフレームワークがいくつか存在します。
- SABSA（Sherwood Applied Business Security Architecture）：ビジネスの視点からセキュリティ要件を定義し、セキュリティサービス、ドメイン、コンポーネント、そしてそれらの実装に至るまで、ビジネスの目的と整合性の取れたセキュリティアーキテクチャを構築するためのフレームワークです。
- TOGAF（The Open Group Architecture Framework）：ビジネス、アプリケーション、データ、テクノロジーの4つの領域を含むエンタープライズアーキテクチャのフレームワークです。セキュリティはこのフレームワークに組み込まれるべき要素として扱われます。
クラウドセキュリティアーキテクチャ（IaaS, PaaS, SaaSの考慮事項）
クラウドコンピューティング環境におけるセキュリティ設計は、オンプレミスとは異なる考慮が必要です。最も重要な概念の一つが「責任共有モデル（Shared Responsibility Model）」です。
- IaaS（Infrastructure as a Service）：ベンダーはハードウェア、ストレージ、ネットワーク、仮想化レイヤーを提供します。利用者はOS、ミドルウェア、アプリケーション、データを管理します。セキュリティ責任の大部分は利用者にあります。
- PaaS（Platform as a Service）：ベンダーはOS、ミドルウェア、ランタイム環境まで提供します。利用者はアプリケーションとデータを管理します。IaaSよりもベンダーの責任範囲が広がります。
- SaaS（Software as a Service）：ベンダーはすべてのレイヤー（アプリケーションを含む）を提供します。利用者はデータの管理や設定の一部を行います。セキュリティ責任の大部分はベンダーにあります。
どのサービスモデルを利用するかによって、セキュリティ設計や対策の責任範囲が大きく変わることを理解しておく必要があります。
仮想化、コンテナ、マイクロサービスのセキュリティ
これらの新しい技術環境におけるセキュリティの課題と対策も、ドメイン3の対象です。
- 仮想化（Virtualization）：複数の仮想マシン（VM）を単一の物理サーバー上で実行します。セキュリティ上の課題は、ハイパーバイザー（VMを管理するソフトウェア）のセキュリティ、VM間の分離、VM Sprawl（管理不能なVMの増加）などです。
- コンテナ（Containers）：アプリケーションとその依存関係を軽量なコンテナにパッケージ化します。VMよりも分離レベルが低い場合があり、イメージの脆弱性、コンテナ間の分離、オーケストレーションツール（Kubernetesなど）のセキュリティが課題となります。
- マイクロサービス（Microservices）：一つの大きなアプリケーションを、独立してデプロイ可能な小さなサービスの集まりとして構築します。サービス間の通信のセキュリティ、APIセキュリティ、各サービスの脆弱性管理などが重要になります。
4. 脆弱性の評価とリスク軽減
設計されたアーキテクチャやシステムに存在する可能性のある脆弱性を評価し、リスクを軽減するための手法も学びます。
アーキテクチャレベルの脆弱性
これはコードのバグといったレベルではなく、設計そのものに起因する脆弱性です。
- 単一障害点（Single Point of Failure）の存在
- 不十分な分離やセグメンテーション
- 脆弱な認証・認可フロー
- 外部システムとの信頼関係の設計ミス
設計段階でのリスク評価と対策
これらのアーキテクチャレベルの脆弱性を早期に発見し、修正することが、後工程での手戻りやコスト増を防ぎます。
- 設計レビュー：セキュリティ専門家によるアーキテクチャ設計のレビュー。
- 脅威モデリング：設計図に基づいた脅威の洗い出しと評価。
- リスク分析：特定された脆弱性がもたらすリスク（可能性と影響度）の評価と、それに基づいた対策の優先順位付け。
「セキュリティは後から付け足すものではなく、最初から設計に組み込むもの」という考え方が、このドメインでは非常に重要です。
まとめ
CISSPドメイン3「セキュリティアーキテクチャとエンジニアリング」は、セキュリティの基本的な考え方から、具体的なシステムの設計、そして最新の技術環境における考慮事項まで、幅広い知識が求められる領域です。
このドメインの学習を通じて、単なる技術の知識だけでなく、なぜそのような設計が必要なのか、どのような原則に基づいているのかといった、より高レベルな視点を養うことができます。
一見難しそうに見えるかもしれませんが、一つ一つの概念を丁寧に理解していけば、きっと面白さが分かってくるはずです。システムがどのように動いているのか、どのようにすれば安全になるのかを深く考える習慣をつけましょう。
このドメインの学習のポイント
- セキュリティモデルや設計原則の意味と違いをしっかり理解する。
- SDLCにおけるセキュリティの各段階での活動内容を把握する。
- クラウド、仮想化、コンテナといった新しい技術環境固有のセキュリティ課題と対策を学ぶ。
- アーキテクチャレベルの脆弱性がどのようなものか、そしてそれを設計段階でどのように対処するかを理解する。
- 単語の意味を覚えるだけでなく、「なぜそうするのか？」という背景や理由を考えるようにする。
これらのポイントを意識して学習を進めると、知識が体系的に整理され、理解が深まるはずです。
演習問題に挑戦！
それでは、これまでに学んだ知識を確認するための演習問題に挑戦してみましょう。答えはすぐに下にありますので、まずは自分でじっくり考えてみてくださいね。
問題
Q1: ある組織が、厳格な機密性を要求される軍事情報を扱うシステムを設計しています。このシステムにおいて、格付けの高いユーザーが低い格付けの情報にアクセスすることを許可し、低い格付けのユーザーが高い格付けの情報にアクセスすることを拒否するアクセス制御モデルはどれが最も適していますか？
1. Biba Model
2. Clark-Wilson Model
3. Bell-LaPadula Model
4. Brewer and Nash Model
Q2: システム開発ライフサイクル（SDLC）において、セキュリティの確保のために最も早期に実施されるべき活動はどれですか？
1. 脆弱性スキャン
2. セキュアコーディング
3. セキュリティ要件の定義
4. 侵入テスト
Q3: あるユーザーアカウントが、業務遂行に必要最低限の権限のみを持っている状態は、セキュリティのどの設計原則に基づいていますか？
1. 職務分掌（Separation of Duties）
2. 多層防御（Defense in Depth）
3. 最小権限（Principle of Least Privilege）
4. フェールセーフデフォルト（Fail-Safe Defaults）
Q4: クラウドコンピューティングのIaaSモデルを利用している組織において、ゲストOSのパッチ管理の責任は通常誰にありますか？
1. クラウドサービスプロバイダー（CSP）
2. クラウド利用者
3. 責任共有モデルにおいて責任は共有されない
4. サードパーティのセキュリティベンダー
Q5: セキュリティアーキテクチャを設計する際に、単一のセキュリティ機構が破られた場合でも、他のセキュリティ機構によってシステム全体が保護されるように、複数の異なるセキュリティ対策を組み合わせて配置する考え方を何と呼びますか？
1. 最小機構（Economy of Mechanism）
2. 完全仲介（Complete Mediation）
3. 公開設計（Open Design）
4. 多層防御（Defense in Depth）
Q6: システム設計において、将来的な脅威や攻撃手法を予測し、それらがシステムにどのような影響を与えるかを分析するプロセスを何と呼びますか？
1. リスクアセスメント
2. 脅威モデリング
3. 脆弱性スキャン
4. ペネトレーションテスト
Q7: セキュリティモデルのうち、トランザクションの正確性と完全性を保証するために、定義された手続き（TP）を通じてのみ特定のデータ項目（CDI）への操作を許可するモデルはどれですか？
1. Bell-LaPadula Model
2. Biba Model
3. Clark-Wilson Model
4. Lattice-Based Model
Q8: 仮想化環境におけるセキュリティ上の主要な懸念事項の一つで、仮想マシンを管理し、物理ハードウェアとVM間の仲介を行うソフトウェアの脆弱性に関連するものは何ですか？
1. SQLインジェクション
2. クロスサイトスクリプティング（XSS）
3. ハイパーバイザーの脆弱性
4. バッファオーバーフロー
Q9: エンタープライズセキュリティアーキテクチャの設計において、ビジネス目標をセキュリティ要件に変換することに焦点を当てたフレームワークはどれが最も適切ですか？
1. TOGAF
2. ITIL
3. COBIT
4. SABSA
Q10: セキュアなシステムを構築するために、設計段階からセキュリティを考慮し、開発プロセス全体にセキュリティ活動を組み込む考え方を一般的に何と呼びますか？
1. セキュリティテスト
2. セキュリティ運用
3. セキュリティ・バイ・デザイン
4. インシデントレスポンス
解答と解説
Q1の解答：3
解説：軍事情報のような厳格な機密性を要求される環境に最も適しているのは、機密性に焦点を当てたBell-LaPadula Modelです。このモデルは「No Read Up（上位を読まない）」と「No Write Down（下位に書かない）」というルールにより、情報の機密性を維持します。Biba Modelは完全性、Clark-Wilson Modelも完全性に焦点を当てています。Brewer and Nash Model（中国の壁モデル）は、競合する企業の情報を分離するなど、特定のビジネス要件に基づいた機密性モデルです。
Q2の解答：3
解説：SDLCにおいて、セキュリティは可能な限り早期に組み込むことが重要です。要件定義段階でセキュリティ要件を明確にすることで、後続の設計、実装、テストといった工程で適切なセキュリティ対策が講じられます。脆弱性スキャンや侵入テストはテスト段階、セキュアコーディングは実装段階で行われる活動です。
Q3の解答：3
解説：ユーザーやシステムに必要最低限の権限のみを与えることは、「最小権限の原則（Principle of Least Privilege）」に基づいています。これにより、権限の悪用や誤用による被害を最小限に抑えることができます。職務分掌は複数の担当者で業務を分けること、多層防御は複数の対策を組み合わせること、フェールセーフデフォルトは安全側に倒れる設定に関する原則です。
Q4の解答：2
解説：クラウドの「責任共有モデル」において、IaaSでは、クラウドプロバイダーは仮想化レイヤー以下のインフラストラクチャの責任を持ちます。ゲストOS、ミドルウェア、アプリケーション、データの管理やセキュリティは、利用者の責任範囲となります。したがって、ゲストOSのパッチ管理は利用者が行う必要があります。
Q5の解答：4
解説：複数の異なるセキュリティ対策を組み合わせ、単一の対策が破られてもシステム全体が保護されるようにする考え方は、「多層防御（Defense in Depth）」と呼ばれます。これは、あたかも城の堀、城壁、内壁といった複数の防御線を設けることに例えられます。
Q6の解答：2
解説：システムの設計段階で、どのような脅威が存在し、それがシステムにどのような脆弱性をもたらしうるかを分析する体系的なプロセスは「脅威モデリング（Threat Modeling）」と呼ばれます。これにより、設計上の問題点や潜在的な攻撃経路を早期に特定し、対策を講じることができます。リスクアセスメントはリスク全体の評価、脆弱性スキャンやペネトレーションテストは実装後のテスト手法です。
Q7の解答：3
解説：トランザクションの正確性と完全性を保証し、定義された手続きを通じてのみデータ項目への操作を許可するモデルは、「Clark-Wilson Model」です。ビジネス環境における完全性の維持に焦点を当てています。Bell-LaPadulaは機密性、Bibaは完全性ですが、Clark-Wilsonはより実用的な手続きに基づいています。
Q8の解答：3
解説：仮想化環境において、ハイパーバイザーは複数のVMを管理する基盤となるため、ハイパーバイザーに脆弱性があると、その上で動作するすべてのVMに影響が及ぶ可能性があります。これは仮想化環境固有の重要なセキュリティリスクです。SQLインジェクションやXSS、バッファオーバーフローは主にアプリケーションの脆弱性です。
Q9の解答：4
解説：SABSA（Sherwood Applied Business Security Architecture）は、ビジネスの視点からセキュリティ要件を定義し、それに基づいたセキュリティアーキテクチャを構築することに特化したフレームワークです。TOGAFはより一般的なエンタープライズアーキテクチャのフレームワークであり、ITILはITサービスマネジメント、COBITはITガバナンスのフレームワークです。
Q10の解答：3
解説：システムの企画・設計段階からセキュリティを考慮し、開発プロセス全体にセキュリティ活動を組み込む考え方は、「セキュリティ・バイ・デザイン（Security by Design）」と呼ばれます。これは、後からセキュリティ機能を追加するのではなく、最初からシステムの一部として設計するというアプローチです。
全問正解できたでしょうか？ もし間違ってしまった問題があっても大丈夫。解説を読んで、なぜそれが正解なのか、他の選択肢はなぜ違うのかをしっかり理解することが、学習の質を高める上で最も重要です。
この記事が、皆さんのCISSPドメイン3の学習に役立つことを願っています。引き続き、他のドメインの学習も頑張ってください！ 応援しています！
コメント