Comments
Transcript
SDP Long version - チェック・ポイント・ソフトウェア・テクノロジーズ
SOF T WAR E-DEF INE D PROT ECT ION E nterpri se Securit y B lu eprin t SOFTWAREDEFINED PROTECTION Enterprise Security Blueprint チェック・ポイント・ソフトウェア・テクノロジーズ株式会社 〒160-0022 東京都新宿区新宿5-5-3 建成新宿ビル6F http://www.checkpoint.co.jp/ E-mail:[email protected] Tel:03（5367）2500 P/N EOJ24D0 2014.4 Table of Contents ES 01 02 03 S CPP SD CP A 概要 2 実施レイヤ 4 制御レイヤ 20 管理レイヤ 34 まとめ 42 Check Point Software-Defined Protection チェック・ポイントについて 53 付録： エンタープライズ・ネットワークの設計パターン 54 00 1 S E 概要 現代のビジネス環境では、自由な情報流通が必要不可欠です。企業のデータは、クラウドやモバイル・デバイス を通じて移動し、ソーシャル・ネットワーク経由で四方八方に広がっていきます。個人所有のデバイスを業務 利用する BYOD（Bring Your Own Device）やモバイル、そしてクラウド・コンピューティングの登場に よって、固定的な IT 環境の時代は終わりを告げ、柔軟性に優れたネットワークやインフラストラクチャが強く 求められるようになっています。 このようにIT 環境が急激に様変わりする中、それをさらに上回る速さで変化しているのがセキュリティ脅威の 動向です。セキュリティ脅威の進化と高度化は驚くべきスピードで進展し、既知と未知の脅威の組み合わせや パッチ未公開（「ゼロデイ」）の脆弱性悪用、および文書ファイルや Web サイト、ホスト、ネットワークに潜む マルウェアなど、日々新しいタイプの攻撃が出現しています。 今日、IT インフラストラクチャやネットワークの社会的な重要性は高まる一方です。こうした中、現在の環境 では、外部と内部の境界線が曖昧になり、またセキュリティ脅威が巧妙化の一途を っており、組織を確実に 守る革新的な対応策が求められています。 現在広く使用されている単機能型のセキュリティ・ソリューションは、戦術的な事後対応型（リアクティブ）で 応急処置的であり、入念に設計されたアーキテクチャに基づく対策ではありません。最新のセキュリティ脅威に 対処するには、高パフォーマンスなネットワーク・セキュリティ・デバイスと戦略的な事前対応型（プロアク ティブ）でリアルタイムの保護を組み合わせた、単一のアーキテクチャが必要です。 すなわち、組織をプロアクティブに保護する新たなパラダイムが求められているのです。 Software-Defined Protection（SDP）は、新たに策定された実践的なセキュリティ・アーキテクチャであり 方法論です。モジュール型で即応的、そして何よりセキュアなインフラストラクチャの構築を可能にします。 セキュアなインフラストラクチャを実現するアーキテクチャでは、環境の規模や種類を問わず、組織全体を保護 できなければなりません。例えば、本社や支社・支店のネットワーク、スマートフォンなどの携帯端末を利用した モバイル環境、クラウド環境などを網羅的に保護できる必要があります。 また保護機能は、膨大な数のアドバイザリや推奨事項に基づいてセキュリティ管理者が手動で設定するの ではなく、脅威動向の変化に自動で適応できる必要があります。これらの保護機能は、IT 環境全体とシームレス に統合されている必要があり、アーキテクチャは、組織内外の情報源を協調的に活用できる体制を構築でき なければなりません。 SDP アーキテクチャのセキュリティ・インフラストラクチャは、相互接続された以下の 3 つのレイヤで構成 されています。 実施レイヤ：物理および仮想のセキュリティ実施ポイントに基づくレイヤです。ネットワークをセグメ ント化すると共に、ミッション・クリティカルな環境において保護ロジックを実行します。 00 2 ENTERPRISE SECURITY BLUEPRINT EXECUTIVE SUMMARY ES 制御レイヤ：複数の情報源から得た脅威情報を分析し、実施レイヤが実行する保護機能とポリシーを 生成します。 モ ジ ュ ー ル 可 化 視 化 自 動 管 化 理 レ イ ヤ 管理レイヤ：インフラストラクチャ全体を協調させ、アーキテクチャ全体の即応性を最大限に高めます。 ス 脅威ェン ジ ） テリ情報 イン脅威 （ ア ク 制 セ 御 ス 保護 実施 機能 ポイ ント 実 実施 ポイ ント ポイ ント 施 レ イ ヤ 実施 実施 保護機能 制 デ ー 保 タ 護 御 レ イ ヤ 脅 威 対 策 ・ ティ リ ュ ー セキ リシ ポ ポイ ント SDPアーキテクチャでは、高パフォーマンスな実施レイヤと、迅速な機能強化を可能にするソフトウェア・ ベースの動的な制御レイヤを組み合わせることで、不測の事態への対応能力を高めると同時に、変化し続ける 脅威によるインシデントの発生を未然に防ぐプロアクティブな体制構築を可能にします。 将来を見据えた SDPアーキテクチャは、従来のネットワーク・セキュリティ要件やアクセス制御要件に対応し ながら、モバイル・コンピューティングや Software-Defined Network（SDN）などの最新技術を採用する 場合に欠かせない高度な脅威対策を実現します。 00 3 1 0 実施レイヤ セキュリティ対策の導入は、実施ポイントの実装場所を判断することから始まります。ユーザとシステムの 「相互作用」* を仲介するため、実施ポイントはネットワークとホストの両方に実装します。 セキュリティ 対策の導入は、 セグメント化は、実施レイヤを実装するうえでの基本原則となるものであり、攻撃を受けたときの被害を最小限 実施ポイントの に抑える極めて重要な役割を果たします。SDPアーキテクチャでセグメント化を行うと、ネットワーク内での 実装場所を 脅威の拡散を防ぐことができます。つまり、1 つのネットワーク・コンポーネントに対する攻撃を契機に、セキュ 判断することから リティ・インフラストラクチャ全体に被害が及ぶことを防止できるのです。 始まります セグメント化は、セキュリティ対策を実施する上での要となります。セグメント化には以下の目的があります。 モジュール型のシンプルなセキュリティ・ポリシーをネットワークの各セグメントに適用する セキュリティ・アーキテクチャのテンプレートをセグメントごとに作成できるようにする セグメント内の侵害を受けたホストに対し、被害の拡大を抑止するためのポリシーを適用する セキュリティ制御による仲介を必要としない、セグメント間相互作用を定義する * 相互作用：本書では、ネットワーク、コンピュータ、アプリケーションおよびユーザの関係で通信またはデータのやり取りが行われることを「相互作用」と 総称して使用しています。 00 4 ENTERPRISE SECURITY BLUEPRINT ENFORCEMENT LAYER 01 セグメント化を行う理由 第 1 世代のネットワーク・セキュリティ対策は、境界の保護に焦点を当てていました。コンピュータ・セキュ 攻撃を受けた場合の リティの専門家であるBill Cheswick 氏が、1990 年に「柔らかい中身を硬い甲殻で覆うロブスターのような 被害を最小限に もの」と表現したセキュリティ・モデルです。このモデルでは、内部ネットワークを「信頼できるネットワーク」、 インターネットを「信頼できないネットワーク」として扱っています。当時のファイアウォールの役割は、アウト 抑えるために バウンドの接続（信頼できるネットワークから信頼できないネットワークへの接続）を許可し、インバウンドの 欠かせないのが、 接続を遮断するという単純なものでしたが、その後、次世代ファイアウォールの登場により、侵入防御システム 区画化という （IPS）やユーザおよびアプリケーションの認識といった機能が追加され、アウトバウンド/ インバウンドのネット ワーク・トラフィックをよりきめ細かく制御できるようになっていきます。 考え方です 今日のビジネス環境において、境界セキュリティだけで組織を効果的に保護することはほとんど不可能です。 多くの組織では、情報システムを複数の拠点やネットワーク環境に配置し、内部ユーザだけでなく、ビジネス・ パートナーや顧客、さらには不特定多数にまでサービスを提供しています。また組織内では、メインフレーム・ コンピュータから社員のモバイル・デバイスに至るまで、多種多様なコンピューティング・リソースが業務に 使用されています。 組織の境界が拡張され、曖昧になるにつれ、内部ネットワークは信頼できるという従来の考え方は通用しなく なりつつあります。強い動機に支えられたサイバー攻撃者は、物理的なアクセスやソーシャル・エンジニア リングの手法、ハードウェアやソフトウェアのサプライ・チェーンへの侵入、ゼロデイ攻撃など、ありとあらゆる 手段を駆使して、標的とする組織のセキュリティ対策を破ろうとします。そこで、ネットワーク内における相互 作用を可視化し、保護するために、内部的なセキュリティ制御の重要性が高まっているのです。 攻撃を受けた場合の被害を最小限に抑えるために欠かせないのが、区画化という考え方です。魚雷攻撃の 被害を封じ込め沈没を免れるために航空母艦が水密区画という仕切りを設けているように、大規模な組織 では、セキュリティ特性の異なるネットワーク領域をセグメント化（区画化）し、被害の拡大を抑止して迅速に 復旧を行うための手段を取り入れる必要があります。 重要なネットワーク・リソースとユーザの間に実施ポイントを導入すると、外部の攻撃者によるユーザ・ワーク ステーションの侵害を素早く把握できるだけでなく、内部ユーザによる不正アクセスを検出して遮断できる ようになるため、ポリシーに沿ったセキュリティを実現できます。 00 5 ENTERPRISE SECURITY BLUEPRINT 01 ENFORCEMENT LAYER セグメント化の方法 セグメント化の実装は、ネットワークの最小単位のセグメントを定義するところから始まります。セグメントとは、 「実施ポイントによって保護されるコンピューティングおよびネットワーキングの要素の論理セット」を指します。 実行可能な単一のファイルから組織全体までをセグメントとして定義でき、同じポリシーと保護特性を共有する 要素を最小単位のセグメントに含めます。各セグメントの境界には、定義された保護ロジックを実施する実施ポイ ントを配置します。セグメントをグループ化すると、モジュール型の保護を実現できます。完成したセグメント化モ デルをネットワーク設計に組み込み、各ネットワーク・セグメント間の相互作用とデータ・フローを保護するための 信頼できるチャネルを構築します。 セグメント化の手順は以下のとおりです。 1 ップ テ ス 最小単位のセグメント ・ 同じポリシーと保護特性を共有する要素を特定します ・ セグメント境界にセキュリティ実施ポイントを定義し、セグメント間のすべての情報フローを仲介 させ、制御されたアクセスのみを許可します 2 ップ ステ セグメントのグループ化 ・ 最小単位のセグメントをグループ化して、モジュール型の保護を実現します 反復 ・ セグメントのグループ化を反復し、すべてのリソースを制御されたセグメント境界の中に定義します 3 ップ ステ 実施ポイントの統合 ・ ネットワーク・セキュリティ・ゲートウェイやホスト・ベースのソフトウェアなど、物理コンポーネントと 仮想コンポーネントを統合します ・ 統合と仮想化により、ソリューションを最適化します 4 ップ ステ 信頼できるチャネル ・ セグメント間の相互作用とデータ・フローを保護します ステップ 1：最小単位のセグメント 最小単位のセグメントは、次の条件を満たすコンピューティングおよびネットワーキングの要素のセットで構成 最小単位の されます。（1）共通のセキュリティ・プロファイルを共有し、 （2）それ以上小さなセグメントに分割できず、 （3） セグメントは、 セグメントと外部要素間のすべての相互作用を仲介するセキュリティ制御によって保護できる、の 3 点です。最小 単位のセグメントの例としては、セキュリティ・ソフトウェアがインストールされた単一のデバイスや、セキュリ ティ・ゲートウェイで保護された共有ネットワーク上の一連のホストなどが挙げられます。 共通のセキュティ・ プロファイルを 共有する コンピューティング・ ホストおよび ネットワーキング 要素のセットで 構成されます 00 6 ENTERPRISE SECURITY BLUEPRINT ENFORCEMENT LAYER 01 SDP アーキテクチャを実装する最初のステップは、最小単位のセグメントを定義し、共通のセキュリティ・ プロファイルを共有する要素を特定することです。セキュリティ・プロファイルは、セグメントに含まれるリソース の価値と、そのセグメントのユーザおよびセキュリティ制御の信頼レベルに基づいて各セグメントに割り当て られます。 セキュリティ・リスクが生じる可能性があるのは、異なるセキュリティ・プロファイルを割り当てられた 2 つの セキュリティ・ セグメントが相互作用する場合です。また各セグメントのセキュリティ・プロファイルの違いが大きいほど、 リスクが生じる リスクが大きくなります。こうしたリスクを回避するためには、このセグメント化手法に対応した、データや ホスト、アプリケーション、ネットワークの分類基準を用意します。 可能性があるのは、 異なるセキュリティ・ 分類の主な基準としては、ビジネス目標に応じて、機密性、完全性、可用性（Confidentiality、Integrity、 Availability: CIA）のいずれかのセキュリティ要件を使用します。例えば、以下のような分類が可能です。 プロファイルを 割り当てられた 公 開 - 不特定多数によるアクセスが許可されているシステムおよびデータ 2 つのセグメントが 顧 客 - 機密性の高い顧客情報を含むシステムおよびデータ。 相互作用する 一般的には、認証を受けた顧客およびごく一部の内部ユーザにのみアクセスが許可されます 内 部 - 社員であればどこからでもアクセスできるシステムおよびデータ 場合です 機 密 - 特別な保護が必要となる内部システムおよびデータ 部 門 - 部門の役割に応じて、特定の個人にのみアクセスが許可されるシステムおよびデータ このような分類は、セグメントとセキュリティ・プロファイルの定義に役立ちます。必要なセグメント化のレベル と程度は、各組織のビジネス・ニーズとセキュリティ要件によって異なります。例えば、 「最小権限」と「権限 分離」の原則を厳密に適用している組織もあれば、ユーザのアクセス・レベルとシステムの重要性をすべて 同等にしている組織もあります。 ヒント セグメント境界を判断する際は各要素が、 「同じ権限を与えられているか」、 「同じビジネス・プロセス をサポートしているか」、 「同様のリソースを扱っているか」、 「同じレベルのセキュリティ保護を受けているか」 を検討します。すべて該当する場合は、各要素を同じ最小単位のセグメントに含めることができます。 該当しない条件が 1つでもある場合、それらの要素は別のセグメントにする必要があります。 00 7 ENTERPRISE SECURITY BLUEPRINT 01 ENFORCEMENT LAYER 異なるセグメントに含めるべき要素の例を以下に示します。 同じLAN に接続された 2 台のエンドユーザ・ワークステーションが、同じ分類のリソースにアクセス する条件において： ● 2 人のユーザは同じリソースにアクセスできるため、一方のユーザが他方のワークステーションを 攻撃する動機はほとんどないと考えられます。そのため 2 台のワークステーションは、同じ最小 単位のセグメントに含めることができます。 ● ただし、これらのユーザがアクセス権限のないリソースにアクセスを試みようとするかもしれません。 このようなユーザとリソースは、異なるセグメントに含める必要があります。 モバイル・デバイスが、データセンターのサーバには無関係なリスク（物理的な窃盗など）にさらされ ている条件において： ● モバイル・デバイスとサーバのセキュリティ要件は異なっているため、同じ最小単位のセグメントに 含めるべきではありません。 異なる部門や拠点： ● 種類の異なる要素は、必ず別のセグメントに含める必要があります。 組織外のユーザからアクセス可能なサーバ： ● このような要素は、外部からアクセスできない内部サーバとはセキュリティ・プロファイルが異な ります。 ステップ 2：セグメントのグループ化 最小単位のセグメントを定義したら、次はそのセグメントを階層型のセグメントにグループ化していきます。 例えば、複数のアプリケーションはホストのセグメントに、複数のホストはネットワークのセグメントに、複数の ネットワークは組織のセグメントにグループ化できます。 個々のサブセグメントに対する保護を制御するのは、そのサブセグメント自体ですが、グループ化には以下に 示す利点があります。 抽象化と情報隠 によりモジュール性が向上 上位レベルのセグメント境界で、サブセグメントよりも高いレベルの信頼性、またはより包括的な 保護を実現 セキュリティ・インフラストラクチャ・サービスの制御と提供の一元化 感染拡大の抑止と迅速な復旧が可能 図 1-A に示した拠点例を見てみましょう。この組織のネットワークは、MPLSプロバイダ・ネットワークで接続 された複数の拠点で構成されています。網掛けの矩形で囲まれた各拠点は、内部ユーザをホストするアクセス・ ネットワーク（LAN）と複数のサーバ・セグメントで構成されています。内部サーバと機密サーバは異なる セグメントに配置されており、両セグメントは、ゲートウェイ（実施ポイント）によりユーザから分離されてい ます。複数の部門セグメントは、各部門に属するエンドユーザに単独で機能を提供しています。そして専用の セグメントが割り当てられた DMZ は、公開サービスを提供しています。 この例では、複数のサーバ・セグメントとユーザ・セグメントを分離することで、セグメント間で発生する すべての相互作用をきめ細かく制御できるようにしています。この仕組みにより、分類に基づいてセキュリ ティ・ポリシーを実施し、侵害を受けたホストからの被害拡大の抑止が可能となります。すべての内部セグ メントは、サーバ・セグメント内に構築された一元的なシステムおよびネットワーク管理インフラストラクチャ から、セキュリティ・サービスの提供を受けます。インターネット・アクセスとWAN アクセスは専用の実施 ポイントにより制御され、DMZ へのアクセス/DMZ からのアクセスはインターネット用の実施ポイントにより 制御されます。 00 8 ENTERPRISE SECURITY BLUEPRINT ENFORCEMENT LAYER 01 セグメントのグループ化 図 1-A MPLS セグメントの分類 インターネット 実施ポイント 実施ポイント 公開 内部 機密 部門 LAN 内部サーバ 部門サーバ DMZ 重要なサーバ データセンター セグメントを階層型にグループ化すると、相互作用が複数の実施ポイントを通過する場合があります。例えば、 「内部サーバ」セグメントに配置されたサーバが、コンテンツ・アップデート・サービスなどのインターネット上の リソースに接続する際の通信は、以下のような順序で各実施ポイントを経由します。 1.「内部サーバ」セグメントのホストにインストールされたセキュリティ・ソフトウェア 2.「内部サーバ」セグメント境界の実施ポイント 3. データセンターの境界に配置された実施ポイント 4. インターネットに直接接続された実施ポイント DMZセグメントに配置されたプロキシを経由する相互作用は、DMZセグメントへのアクセス/DMZセグメント からのアクセスに対する実施ポイントなど、追加の制御パスを通過します。 このように、ネットワーク上の小さいコンポーネントから大きいコンポーネントに向けてセグメントをグループ化 するプロセスを反復していくと、すべてのリソースを確実に保護セグメントに含めることができます。グループ化 されたセグメントに基づく階層型の防御ラインにより、内部ネットワークを適切に区画化して強固なセキュ リティを実現できます。 00 9 ENTERPRISE SECURITY BLUEPRINT 01 ENFORCEMENT LAYER ステップ 3：実施ポイントの統合 モデルから実装へ セグメント化モデルの完成後は、定義した実施ポイントをネットワーク・セキュリティ・ゲートウェイまたは ホスト・ベースのソフトウェアとして実装します。マルチホーム・ゲートウェイやゲートウェイ仮想化、仮想 ローカル・エリア・ネットワーク（VLAN）、SDN、ネットワーク仮想化などの統合技術や仮想化技術を使用 すると、パフォーマンスや管理性を最適化し、TCO（総所有コスト）が低減します。 図 1-Bに示したのは、セグメント化モデルの作成プロセスです。この図は、ユーザ・ワークステーション、サーバ （CRM 用、研究開発用、財務用）、セキュリティ・オペレーション・センター（SOC）、そしてDMZ に置かれた 公開サーバで構成されるサンプル・ネットワークにおけるセグメントを示しています。セキュリティ・プロ ファイルは、最小単位のセグメントに関連付けられています（色の凡例については、図 1-A の「セグメントの 分類」を参照）。実施ポイントは各セグメントの境界に置かれ、各セグメントはそのセキュリティ・プロファイルに 基づいてグループ化されています。 ネットワークのセグメント化プロセス 図 1-B Webサーバ ユーザ用 デスクトップ/ ノートPC CRMサーバ 研究開発サーバ SOCサーバ 財務サーバ 公開 内部 内部 機密 部門 部門 1. 最小単位の セグメント DMZ 2. セグメントの グループ化 01 0 LANユーザ データセンター ENTERPRISE SECURITY BLUEPRINT ENFORCEMENT LAYER 01 このボトムアップのモデリング・プロセスでは、特定のビジネス・アプリケーション用から組織全体を対象にした ものまで、必要なすべての実施ポイントを柔軟かつモジュール単位で判断し、その出発点（プロセス、ホスト、 ネットワークなど）とゴールを適切に見極めることができます。定義した実施ポイントは、対応するセグメント 境界内のデータおよびシステムを保護する、階層型の防御ラインを形成します。 ゲートウェイの統合 図 1-A のモデルには、セグメント境界の実施ポイントが 8 個描かれています（LAN セグメント内のホストに モデル化した複数の インストールされたセキュリティ・ソフトウェアによる実施ポイントは省略されています）。しかし多くの場合、 実施ポイントを、 8 個の実施ポイントとして8 台のセキュリティ・ゲートウェイ・アプライアンスを導入するケースはあまり考え られません。実施ポイントは、セキュリティや予算、パフォーマンス上の要件に応じて、各拠点で 1 台のマルチ １つのセキュリティ・ ホーム型セキュリティ・ゲートウェイ・アプライアンスに統合することができます。図 1-C は、1 台の統合 ゲートウェイ・ セキュリティ・ゲートウェイがすべてのセグメント間相互作用を制御する、シンプルなネットワーク構成となって アプライアンスに います。 統合できます 複数のセグメントの実施ポイントを 1 台のセキュリティ・ゲートウェイに統合 イン ター ネッ ト 図 1-C 内部 サー セキ ュ ゲー リテ トウ ィ・ ェイ MP LS バ 部門 サー バ 重要 なサ ー バ DM Z LA N 01 1 ENTERPRISE SECURITY BLUEPRINT 01 ENFORCEMENT LAYER セキュリティの仮想化 ゲートウェイの統合は大幅なコスト削減というメリットと同時に、実施ポイントが統合されることに起因する セキュリティの いくつかのデメリットをもたらします。特に問題なのは、セキュリティ・ポリシーの複雑化によって設定ミスが 仮想化により、 発生しやすくなるケースです。例えば、2 つの内部セグメント間のアクセス・ルール設定を間違えてインター ネットからのアクセスを許可してしまった場合、深刻な被害が生じるおそれがあります。 管理を効率化して TCO を削減できます 図 1-C のシンプルなネットワーク構成の代替案としては、図 1-D のような仮想セキュリティ・ゲートウェイを 使用する構成が考えられます。この構成では、1 台のアプライアンスに複数のバーチャル・システムをホスト します。各システムはセキュリティ・ゲートウェイと論理的に同等の機能を備えており、個別の管理が可能です。 セキュリティ制御の仮想化 図 1-D V イン ター ネッ ト 内部 サー V サー バ 重要 なサ ー バ DM Z LA N セキュリティの仮想化では、管理が効率化されます。各バーチャル・システムはセキュリティ・セグメントの実施 ポイントとしての役割を果たし、セキュリティ制御を個別に導入、管理することができます。しかもハードウェア・ プラットフォームが 1 つに集約されるため、TCO の削減効果も期待できます。 サーバの仮想化（クラウド） サーバ仮想化環境（付録の「設計パターン： クラウド」を参照）では、図 A-D に示すように、仮想マシン （VM）による仮想セキュリティ・ゲートウェイを実装できます。この構成では、基盤となる仮想化技術をクラウド・ インフラストラクチャが提供します。クラウド・インフラストラクチャは、複数の VLAN を VMレベルの実施 ポイント経由で接続し、セグメント間トラフィック・フローが各実施ポイントを通過するようにします。同じ物理 ホスト上の VM 間で発生するトラフィックの仲介は、そのホストの VM で動作する実施ポイントで効率的に 処理できます。 01 2 V 仮想 ゲー化セキ トウ ュリ ェイ ティ ・ バ 部門 V V V V MP LS ENTERPRISE SECURITY BLUEPRINT ENFORCEMENT LAYER 01 実施ポイントをハイパーバイザ自体に組み込めば、仮想ネットワークを設計し直してVM を実施ポイントの 背後に配置することなく、すべての情報フローを仲介できます。ハイパーバイザ・レベルの実施ポイントは、 仮想化プラットフォームが提供するAPIフックを使用して、ハイパーバイザがホストするVM 間のすべての ネットワーク・トラフィックを受信します。 また、図 1-D に示した物理的な仮想化セキュリティ・ゲートウェイをサーバ仮想化環境に組み込むと、仮想 サーバのセキュリティ処理を高パフォーマンスな専用セキュリティ・ハードウェアに任せることができます。 仮想 LAN（VLAN） VLAN は、ネットワークをセグメント化する最も一般的な方法です。トランク・インタフェース経由でスイッチ に接続されたセキュリティ・ゲートウェイは、ネットワーク・トラフィックを分析したうえで複数の VLAN に 転送できます。この構成では、1 台のセキュリティ・ゲートウェイで、数百に及ぶ VLAN 間のネットワーク・ トラフィックを制御することが可能です。図 1-E では、VLAN02 からVLAN03 へのすべてのネットワーク・ フレームをセキュリティ・ゲートウェイ経由で転送するようスイッチ・デバイスを構成しています。ゲートウェイ に実装された仮想実施ポイント経由で、セグメント間トラフィックを仲介できます。 VLAN を使用したネットワークのセグメント化 図 1-E イン ター ネッ ト LA N VL AN 03 02 ネッ ト 0 5 ワー ク ネ ッ ト ワ 0 ー 2 ク V LA N 0 5 V ネッ ト 0 4 ワー ク AN ネ ッ ト ワ 0 ー 3 ク 0 4 VL VLANアーキテクチャを使用してネットワークをセグメント化する主なデメリットは、セグメント分離ポリシー の実施を、攻撃を受けやすいネットワーク・スイッチに依存することです。設定ミスを犯した場合、VLAN ホッピング攻撃によってスイッチを 回され、VLANホストによる別のVLANホストへのアクセスを許すおそれ があります。このため、仮想的な分離と物理的な分離を組み合わせ、セグメント同士を多層的に分離することが 重要となります。 01 3 ENTERPRISE SECURITY BLUEPRINT 01 ENFORCEMENT LAYER Software-Defined Networking（SDN） 従来のネットワーク・インフラストラクチャでは、ルータやスイッチなどのネットワーク接続機能とファイア ウォールや IPS などのネットワーク・セキュリティ機能は、物理的な機器が提供しています。ネットワーク・ フローはネットワーク・トポロジによって決まり、パケットを目的地に届ける最適な経路を判断する役割は 個々のネットワーク・デバイスが担っていました。しかし昨今では、クラウドを利用した仮想サーバやネット ワーク環境の登場により、ネットワーク構成を大きく変えることなく迅速にアプリケーションを導入できるように することが強く求められています。ニーズに応じて登場したのが、ネットワークの制御とネットワーク・インフラ Software-Defined Networking（SDN）に おける実施レイヤ 実施 ポイ ント SD 実 図 1-F 施 レ イ ヤ ストラクチャを分離する新たなアーキテクチャ、Software-Defined Networking（SDN）です。 SD 内部 サー 実施 ポイ ント Nス イッ チ SD Nス イッ チ SD バ 部門 サー 実施 ポイ ント Nス イッ チ SD Nス イッ チ バ 重要 なサ ー バ LA N DM Z 図 1-F に示すように、SDP の実施レイヤとSDN のインフラストラクチャ・レイヤを統合すると、SDN スイッチ は単純な実施ポイントとして動作するようになります。このスイッチが果たすセキュリティ上の役割は、特定の フローおよびサブフローの処理をSDP セグメントの適切な実施ポイントに渡すことだけです。 図 1-Gは、SDPアーキテクチャとSDNアーキテクチャがどのように統合されるかを示しています。SDPの管理 レイヤは、SDN のアプリケーションAPI を使用し（1）、SDP の制御レイヤとSDN の制御レイヤ間でネット ワーク・ポリシーとセキュリティ・ポリシーを連携させて（2）、両者の統合を制御します。ネットワーク・フロー は、SDP/SDN の制御レイヤでプログラム処理され、一元化された物理または仮想の SDP 実施ポイントを 通過します（3）。前述したように、特定のフローおよびサブフローの処理を SDP セグメントの適切な実施 ポイントに渡すという単純な実施ポイントとしての役割をSDN スイッチに与えることで、すべてのセグメント 間相互作用を連続的に仲介できるようにしているのです。 01 4 Nス イッ チ 実施 ポイ ント ENTERPRISE SECURITY BLUEPRINT ENFORCEMENT LAYER 01 SDPとSDN の統合 化 2 視 N コ ン ト ロ ー ラ S D P の 管 自 動 理 レ イ ヤ 化 可 モ ジ ュ ー ル 化 1 ビ ジ ネ ス ビ ・ ジ ア ネ プ ス リ ビ ・ ケ ジ ア S ー ネ プ D シ ス リ N ・ ョ ケ の ア ン ー ア プ シ プ リ ョ リ ケ ン ケ ー ー シ ョ シ ン ョ ン ・ レ イ ヤ 図 1-G S D 2 脅威 P D 御 の 制 御 レ イ ヤ 3 S アク セス 制 対策 デー タ保 護 実施 ポイ ント ポイ ント 実 実施 施 レ イ ヤ 3 実施 ポイ ント 例えば SDN スイッチの設定により、LAN セグメントと内部サーバ間の相互作用は、あるセキュリティ・ゲート ウェイの実施ポイント経由で転送するようにしつつ、DMZとの相互作用については、より高度なセキュリティを 実装した別の実施ポイント経由で転送するように構成できます。また分散サービス妨害（DDoS）攻撃が発生 した場合に、攻撃トラフィックを通常のトラフィックとは違う経路でルーティングし、承認された相互作用に影響 が及ばないようにするといった対応も可能です。 01 5 ENTERPRISE SECURITY BLUEPRINT 01 ENFORCEMENT LAYER クラウドでのセキュリティ実施 セキュリティ処理は、ネットワークやホスト・ベースの実施ポイントではなく、プライベート・クラウドやパブ リック・クラウドの専用リソースでも実施できます。この場合、実施ポイントはローカルで利用可能な情報に 基づいてセキュリティ上の判断を下す代わりに、クラウドに対して問い合わせを行います。このようにクラウド のリソースを利用すれば、SDP の実施レイヤの機能を拡張できます。 セキュリティ処理をクラウドで実施すると、以下のようなメリットが得られます。 セキュリティ上の判断を下すにあたり、脅威に関するさまざまな指標（脅威指標）など、刻々と変化す る複雑な情報が必要となる場合があります。しかし、必要なすべての情報を、該当するすべての実施 ポイントに配布することは容易ではありません。セキュリティ処理をクラウドで行えば、データを1 箇 所に集約するだけで済み、実施ポイントに配布する必要がなくなります。 セキュリティ情報 / セキュリティ・イベント管理（SIEM）システムを使用すると、セキュリティ・イベン ト・ログをビッグデータとして1 箇所に集約し、回顧分析を実施できます。分析の結果、侵害を示唆 する手がかりを見つけ出し、相互作用を承認するための汎用的な基準を策定できます。この基準は、 実施ポイントで異常な振る舞いを検出するための手がかりとして使用できます。 電子メールのようにデータを蓄積してから中継するシステムの場合、データ・コンテンツや添付ファイ ルをクラウドにアップロードして分析する際に生じる遅延は、大きな問題になりません。宛先ホストに データや添付ファイルを転送する前に、クラウドのサンドボックス環境で不正なコードの有無を検査 します。 インターネット経由でクラウド・ベースのポータルにアクセスするモバイル・ユーザは、接続元に近い 場所からセキュリティ・サービスの提供を受けられるため、拠点に集約された実施ポイントを経由す る場合に比べ、素早く確実にセキュリティ処理を受けられます。 セキュリティ制御をクラウドで行う場合、セキュリティ実施の課題は組織のネットワークからクラウドへと移り ます。クラウド・サービスを利用する場合は、必要なセキュリティ制御をいつでも使用できるよう、十分な保証 と監視機能がプロバイダから提供されているかどうかを確認してください。またクラウドとの間で発生する すべての通信を認証、保護するため、クラウドとの接続には信頼できるチャネルを使用する必要があります。 DDoS 攻撃などを受けた場合に備え、クラウドとネットワークの可用性についての検討も重要です。 クラウド・ベースのセキュリティ実施ポイントの例は、付録 Aの「設計パターン： モバイル」で紹介しています。 01 6 ENTERPRISE SECURITY BLUEPRINT ENFORCEMENT LAYER 01 ステップ 4：信頼できるチャネル セグメントの実施ポイントは、セグメント間で発生する不正な相互作用を遮断します。それだけではなく、 承認された相互作用を保護することも必要です。2 つのネットワーク・セグメントが同じ場所に配置された 要素を共有している場合は、セキュリティ・ゲートウェイを物理的に両セグメントに接続して、セグメント間相互 作用を仲介させることができます。一方、2つのセグメントが物理的に切り離されている場合は、ネットワーク・ インフラストラクチャを横断するセグメント間の相互作用を保護する必要があります。 セグメント間の相互作用が、信頼できるネットワーク内の階層型のセグメントによって確立される場合、転送中 信頼できる のデータを保護する役割はそのセグメントが担います。ただしそのネットワークが、2 つのセグメントのセキュ ネットワーク経由で リティ・プロファイルと比較して信頼度が低い場合、攻撃者が両セグメント間を流れるデータにアクセスし、 データを改変できる可能性があります。したがって、セグメント間には信頼できるチャネルを確立し、セグメント 相互作用を行う場合は、 間の相互作用を暗号化することが必要となります。信頼できるチャネルでは、そのチャネルを通過するデータ セグメント間に信頼できる への不正アクセスを防ぎ、データ改変の試みを検出してブロックすることができます。 チャネルを確立して 以下の図では、異なる拠点の 2 つの部門セグメントが、信頼できるチャネル経由で相互作用を行っています。 相互作用を保護する またここでは、内部ユーザは内部サーバに直接アクセスすることができます。 必要があります 2 つのセグメント間の信頼された暗号化チャネル 図 1-H 信頼されたチャネル インターネット MPLS 部門サーバ 実施ポイント 重要なサーバ 実施ポイント データセンター DMZ LAN 内部サーバ 部門サーバ 重要なサーバ データセンター 01 7 ENTERPRISE SECURITY BLUEPRINT 01 ENFORCEMENT LAYER Stuxnetの事例研究 コンピュータ・ワームの感染拡大は、セグメント化で防御可能 2010 年 6 月、新種のネットワーク・ワームが発見されました。イランの核開発施設で使用されている、Siemens 社の産業用 制御装置 SCADA（Supervisory Control and Data Acquisition）を標的とする特殊なワームです。報道などによると、 このワームによってウラン濃縮装置が破壊されたイランは、核開発計画の進展に大打撃を受けました。ここでは、同ワームの 特 性について分析し、適切にセグメント化が実施されていればワームの感染拡大を未然に防げた可能性を示します。この 「Stuxnet」ワームは複合型の脅威であり、 （1）USBフラッシュ・ドライブ経由で Windows ベースのワークステーションに感染 する、 （2）ネットワークとリムーバブル・メディア経由で感染を広げる、 （3）感染ホストから指令（C&C）サーバに接続し、新たな 命令を受け取って情報を送信する、 （4）SCADAソフトウェアが動作するホストを見つけ出し、プログラム可能なロジック・コント ローラ（PLC）を改変してウラン濃縮のための遠心分離機を破壊する、という特徴を備えていました。 Stuxnet 図 1-I コム ナタンツ アラーク イスファハン WA N P2 サー デー バ タセ ブシャール イラン P接 続 4 2 オペ レ P C ータ 用 ンタ ー テヘラン イン ター ネッ ト 3 C& Cサ ーバ サーP L C バ LA N 1 Stuxnet は、自身の存在を隠 し駆除を妨害するため、複数の偽装手段を使用しています。実際、Stuxnet は何年もの間発見 されずに潜伏し、既知と未知の脆弱性を利用して感染を広げていました。最初に感染したのは、組織内で使用されている信頼で きるワークステーションです。その後ネットワーク経由で感染を広げ、イラン国内だけで 6 万台以上のホストに拡大しました。 報道によると、ナタンツの核開発施設に置かれた 1,000 台近くの遠心分離機が Stuxnet によって破壊されています。また Stuxnet は執拗に再感染するため、完全な駆除には膨大な時間と労力が必要となります。 01 8 ENTERPRISE SECURITY BLUEPRINT ENFORCEMENT LAYER 01 セグメント境界に以下の保護機能が導入されていれば、Stuxnet による攻撃を未然に防げた可能性があります。 アクセス制御 1. USBインタフェース経由によるホストへの侵入は、最小単位のセグメント境界でブロックできたはずです。またエンドポイント・ ホストとLANセグメントの境界にセキュリティ制御が導入されていれば、感染ホスト間のP2P 接続の確立を阻止できた可能性 があります。さらに、Stuxnet が検出されたホストのアウトバウンドのネットワーク接続を特定のネットワーク・サービスだけに 制限していれば、感染の拡大を抑止できた可能性があります。 2. ミッション・クリティカルな要素であるオペレータ用 PC は、ネットワーク経由でアクセスできないようにするべきでした。また セグメント境界にファイアウォールがあれば、オペレータ用 PC へのアクセスを遮断できた可能性があります。 脅威対策 3. LAN セグメントとWAN の境界にIPS が設置されていれば、感染ホストを検出し、既知の脆弱性経由での他のセグメントへの 感染拡大を防止できた可能性があります。IPS で検出できていれば、その分析結果に基づいてカスタム IPS シグネチャを 動的に生成、配布して、発覚した脆弱性の悪用を防ぎ、ワームを完全に封じ込むことができた可能性があります。 4. LAN からインターネット上の C&Cサーバに対するアウトバウンドのアクセスは、拠点や組織の境界で検出し、ブロックできた 可能性があります。 Stuxnet が多数の標的への感染に成功したという事実は、核制御用の PLC にアクセスできるミッション・クリティカルなオペ レータ用 PC など、セキュリティ特性の異なる要素間のセキュリティ制御が不十分であったことを裏付けています。 実施レイヤのまとめ SDPアーキテクチャの実施レイヤは、SDP を実現するための基盤となる複数の実施ポイントで構成されます。 実施ポイントは、ネットワーク・セキュリティ・ゲートウェイ、ホスト・ベースのソフトウェア、モバイル・アプリ ケーション、クラウドの仮想マシンとして実装できます。 実施レイヤを実装するうえでの基本原則となるのはセグメント化です。ネットワーク内での脅威の拡散を防ぐ セグメント化は、攻撃を受けた場合の被害を最小限に抑える極めて重要な役割を果たします。セグメント化の 実装は、ネットワークの最小単位のセグメントを定義するところから始まります。そしてこの最小単位のセグ メントの境界に、定義された保護ロジックを実施する実施ポイントを配置します。最小単位のセグメントを グループ化すると、モジュール型の保護を実現できます。最後に、各ネットワーク・セグメント間の相互作用と データ・フローを保護するための信頼されたチャネルを構築します。 ゲートウェイの統合を可能にするこのセグメント化は、幅広い構成のネットワーク・インフラストラクチャに 適用できます。物理的な構成に基づく従来型のインフラストラクチャにも、ネットワーク仮想化やサーバ仮想化、 仮想 LAN、SDN インフラストラクチャなどの最新技術を使用した動的な構成のインフラストラクチャにも適用 可能です。 SDP の実施レイヤでは、このセグメント化が、巧妙な APT（Advanced Persistent Threat）の感染拡大を防ぐ基本的な枠組みとなります。 01 9 2 0 制御レイヤ 制御レイヤは、SDP アーキテクチャの中心となるレイヤです。ソフトウェアによる保護機能を生成し、実施 レイヤの適切な実施ポイントに配置するという役割を担います。実施ポイントは、高パフォーマンスな専用 ハードウェア、またはネットワーク、モバイル・デバイス、クラウドのホスト・ベースのソフトウェアとして実装 されます。 保護機能には、脅威対策、アクセス制御、データ保護という3 つの種類があります。各機能では、それぞれ 異なる情報に基づいてセキュリティ・ポリシー・ルールを策定します。 脅威対策：脅威の特性と振る舞いに基づいてセキュリティ・ポリシーを実施します。セキュリティ・ ポリシーの元になる脅威情報は、適切なコミュニティからリアルタイムで取得します。 アクセス制御：管理レイヤでの設定に基づき、組織内のユーザとリソースの間の相互作用を制御する セキュリティ・ポリシーを実施します。 データ保護：振る舞いや相互作用ではなく、データの分類に基づいてポリシーを実施します。組織内 でのデータ・フロー・ポリシーは管理レイヤにより決定されます。 SDPでは、動的に変化する最新の脅威や組織のネットワーク構成の変更に柔軟に対応できます。実施レイヤは、 組織中に配置された実施ポイントで保護機能を実行する強力な基盤を構成します。保護機能はソフトウェアに よって制御されるため、新たな脅威や攻撃手法が出現した場合や、新しいテクノロジーを組織に導入した ケースでも、実施ポイントに設置されたハードウェア自体を置き換える必要はありません。 保護機能は、膨大な数のアドバイザリや推奨事項に基づいて手動で設定するのではなく、脅威動向の変化に 自動で適応できる必要があります。これは、脅威対策と管理レイヤ間の相互作用を基本的に自動化し、脅威指 標だけでは脅威や攻撃が発生しているかどうかを判断しきれない場合にのみ、人による意思決定を介在させる ことで実現できます。 02 0 ENTERPRISE SECURITY BLUEPRINT CONTROL LAYER 02 SDP の制御レイヤ 図 2-A 対 威 脅 御 レ イ ヤ 制 デ ー 保 タ 護 ア ク 制 セ 御 ス ィ・ テ ュリ ー キ セ リシ ポ 策 ス 脅威ェン ジ ） テリ情報 イン脅威 （ 脅威対策 脅威対策では、攻撃をブロックして脆弱性の悪用や不正なペイロードの配布を防ぎます。脅威対策ポリシーの 脅威対策は 中身は、 「すべての脅威を防御する」という単純明快なものです。組織ごとにカスタマイズする必要は、ほとんど すべての組織で ありません。むしろ、すべての組織で汎用的に適用する必要があります。 汎用的に適用します 脅威対策の保護機能は、感染前 / 感染後で役割が異なります。感染前の保護機能は、アプリケーションや プロトコルに存在する脆弱性の悪用や正規アプリケーションの妨害を試みる脅威をプロアクティブに検出して ブロックします。一方、感染後の保護機能は、ネットワーク要素の攻撃に成功した脅威を素早く検出し、感染 の拡大を防ぎ、無害化する役割を担います。両者の機能によってマルウェアの拡散を抑止し、ボットとC&C サーバ間の接続を遮断します。 セキュリティ脅威と判断する上で既存の手がかりが不足している場合、制御レイヤの脅威対策コンポーネント 脅威対策の機能は、 感染前の保護機能と は、シグネチャやレピュテーション、振る舞い分析、マルウェア・エミュレーション、人の検証など、複数の 感染後の保護機能に エンジンによる判断を相関分析し、十分な情報を得たうえでセキュリティ脅威かどうかの判断を下します。また 分類されます 外部のリソースを使用して、より効果的な保護機能を生成することもできます。 脅威対策の効果を高めるためには、信頼性の高い広範な脅威情報が必要です。また、情報を継続的かつ自動 的に収集できる仕組みを整えることも欠かせません。 02 1 ENTERPRISE SECURITY BLUEPRINT 02 CONTROL LAYER 脅威情報 脅威情報は組織内外の情報源から取得されます。有益な外部情報源としては、公に認知されているセキュリ ティ関連の組織や個人です。例えば、CERTs（Computer Emergency Readiness Teams）や CSIRTs （Computer Security Incident Response Teams）、セキュリティ・アナリスト、セキュリティ製品ベン 脅威情報は組織内外の 情報源から取得します ダー、セキュリティ・コミュニティに属するその他の組織などが挙げられます。また脅威情報は組織内でも 生成されます。マルウェア調査やサンドボックスでの実行、実施ポイントから収集されたセキュリティ・イベント 情報の解析などによって得られるデータが該当します。 脅威情報には、脅威の媒介、標的、攻撃の内容、 および攻撃者の戦術、技術、手順（TTP：Tactics, Techniques and Procedures） が含まれます。脅威対策コンポーネントは、収集された情報を元にビッグデータ分析を行い、 脅威指標と攻撃内容の説明で構成される、対策の実施に役立つ実用的な情報を生成します。生成される指標 は、実施レイヤが防御機能を実施するかどうかの判断基準になるほか、攻撃が行われた場合のネットワーク への影響を分析し、必要な対策を実施するために利用することもできます。 脅威情報の分析プロセス 図 2-B 脅威情報 セキュリティ・ アナリスト CERTs マルウェア調査 外部の 情報源 内部の 情報源 セキュリティ・ コミュニティ セキュリティ・ イベント解析 ビッグ データ 分析 脅威指標 コンテキストと メタデータ セキュリティ保護機能 02 2 サンドボックス ENTERPRISE SECURITY BLUEPRINT CONTROL LAYER 02 脅威情報の分析プロセスでは、生の情報を使用して、脅威の検出とブロックに活用できる脅威指標などの 実用的な情報を生成します。この情報により、以下に示す問いに対する答えを得ることができます。 注意すべき不正な振る舞いは？：ネットワーク・アドレスやドメイン名の解決リクエスト、URL、シス テム・コール、ファイル・ハッシュなど。 注意すべき場所は？：ネットワーク、電子メールの本文、添付ファイル、ハードディスク、メモリなど。 問題のイベントの重要度は？：メタデータにより、指標の信頼性レベルや攻撃の重要度レベルなどの 追加情報が提供されます。 攻撃への対処方法は？：攻撃をネットワークとホストのどちらでブロックするべきか、問題の脆弱性を 修正するパッチは公開されているか、などの情報が提供されます。 脅威情報の分析プロセスの一例を以下に示します。 生の情報の収集：金融関連企業を標的とする攻撃が確認されたとの知らせがありました。判明して いる TTP は、電子メールや USB メモリ、ハッキングした Web サイトなど複数の経路を使用して、 攻撃用の文書ファイルを標的のユーザに配布するというものです。この文書ファイルには、閲覧アプリ ケーションの脆弱性を悪用するマルウェアが埋め込まれています。ユーザがそのマルウェアを実行した 場合、C&C サーバとの接続が確立され、攻撃者がリモート・アクセス・ツール（RAT）を使用して 内部ネットワークにアクセスできるようになります。 実用的な情報の生成：実施レイヤのサンドボックスが文書ファイルを実行し、ローカル・ファイル・ システム上に別のファイル（RAT）をインストールするマルウェアが埋め込まれていることを確認し ます。サンドボックスは文書ファイルとRAT の一意のハッシュを生成し、これらを脅威指標として制御 レイヤに渡します。制御レイヤは、渡された指標を利用してこの攻撃をブロックする保護機能を生成 し、組織内の実施ポイントに配布します。指標は、コミュニティに属する別の組織とも共有されます。 感染後に発生する被害の抑止：攻撃の形跡が記録されたネットワーク・データやホストのファイル・ システムに対してビッグデータ分析を行うと、文書ファイルや RAT のハッシュと一致するファイルを 手がかりに、別のホストにも広がった感染の有無を確認できます。新たに感染ホストが見つかった場 合は、そのホストのネットワーク・アクセスを制限する保護機能を自動、または手動で生成すること ビッグデータ分析によって 感染ホストを 把握できます で、被害の拡大を抑止します。 セキュリティ・イベントの解析：ログ・データをさらに詳しく解析すると、不審なホストと特定のアウト バウンド接続の間に統計的な相関関係が見つかる場合があります。C&Cサーバやデータ保管サーバと 判断できる場合、ホストの IPアドレスや URL は、ボットによる通信を遮断するための指標として利用 します。 02 3 ENTERPRISE SECURITY BLUEPRINT 02 CONTROL LAYER 脅威指標として特に有用なのは、攻撃ごとに変化させるコストが高い要素を表す指標です。例えば、攻撃者に よって詐称され、接続のたびに無作為に変更される可能性が高い送信元アドレスは、ブロックしてもあまり 意味がありません。一方、ボットからC&C サーバへの接続を変化させるためには、新しい C&C サーバを 構築する必要があります。接続をブロックすれば、その攻撃を遮断できる可能性が高くなります。 ただし高度な攻撃への対処では、より複雑な脅威指標のマッチングが必要となります。例えば最新のマルウェア は、C&C サーバの URL を無作為に生成し、大量のサーバに接続できる特徴を備えている場合があります。 この URL 生成アルゴリズムを分析すると、攻撃に使用されるすべての URL を特定できる複雑な脅威指標を 導き出せます。 脅威指標の生成 脅威指標は、組織内部で確認された異常な振る舞いや不正な振る舞いに基づいて生成されるケースもあり ます。組織内で脅威指標を生成する要素を以下に示します。 サンドボックス環境で実行された実施レイヤのセキュリティ制御ロジック：文書ファイルやアプリケー ションが、マルウェアの存在を示唆する不審な振る舞いを示した場合、脅威指標が生成されます。 実施レイヤから渡された、異常や攻撃の可能性を示すセキュリティ・イベントの解析：イベントが脅威 による活動であると確認された場合、以降の攻撃をブロックし、感染ホストからの被害拡大を抑止す るための脅威指標が生成されます。 セキュリティ・アナリストによる、ネットワークやホストのフォレンジック分析：分析の結果、脅威指標 が生成される場合があります。生成された脅威指標は制御レイヤに渡され、各実施ポイントに配布 されます。 攻撃者をおびき寄せるためのハニーポット：内部ネットワークに侵入したつもりでいる攻撃者がハニー ポット内で活動している間に TTP を分析し、攻撃をブロックするための効果的な脅威指標を生成 します。 ゼロデイ攻撃対策 攻撃者は、システムの脆弱性、つまり潜在的なセキュリティ上の欠陥を突いて組織の資産に不正アクセスしよう とします。すでに述べたように脅威対策では、こうした活動を検出、ブロックし、セキュリティ脅威から資産を 保護します。問題は、脆弱性の存在がシステム所有者よりも先に攻撃者に知られてしまう場合があるケース です。このような「ゼロデイ脆弱性」に対する攻撃（ゼロデイ攻撃）は、直接的な対策を講じることができませ ん。その脅威に関する情報が、事前に一切存在していないからです。ゼロデイ攻撃の被害を軽減する対策 を以下に示します。 サンドボックス技術 - 標的のシステムをエミュレートした隔離環境で文書ファイルやアプリケーション を実行させます。想定外の振る舞いが検出された場合は実行を停止し、問題の文書ファイルやアプリ ケーションをネットワークまたはホストの手前でブロックします。 攻撃対象領域の最小化 - 最小権限の原則は、ゼロデイ攻撃対策として非常に有効です。この原則を 徹底すれば、攻撃に利用できるシステム・コンポーネントの欠陥を覆い隠すことができます。最小権限 の原則では、以下のような活動を防ぐことができます。 ● ネットワーク・ポートやサービスへのアクセス - 使用可能なネットワーク・プロトコルを制限し、 一般的でないために十分なテストが行われていない可能性がある機能の使用をブロックします。 ● データ・オブジェクトや未知のプログラムからのコード実行 -アプリケーションによるシステムの 改変を制限できます。 ● 02 4 通信する必要のないホスト間のネットワーク相互作用（P2P ネットワーク接続など）。 ゼロデイ攻撃の被害は、 特定の対策を講じれば 軽減できます ENTERPRISE SECURITY BLUEPRINT CONTROL LAYER 02 振る舞い制御とアノーマリ検出 - システムに「正常な振る舞い」を強制することで、システム・コン ポーネントが侵害を受けてもマルウェアをブロックできる場合があります。例えば、不自然なネット ワーク・スキャンを試みるホストの動作を制限します。 人間の介在 - 重要性の高い操作の実行に人間による確認や承認を義務付け、マルウェアや脅威の活 動を妨害します。さらに振る舞いの正否を基準化すると、異常な振る舞いだけに人間の介在を要求す ることができます。 回顧分析 - 新たに見つかった脅威や脆弱性に関する情報を使用して過去のシステム・イベント・ログ を分析し、不正な活動や侵害の痕跡を見つけ出します。 以上の他にも、脆弱性の修正パッチを速やかに適用し、脅威情報に基づくIPS を導入するという対策を講じ れば、新たに見つかった脆弱性の影響を受ける期間、つまり攻撃を受ける可能性がある期間をできる限り 短縮できます。ゼロデイ攻撃を免れるわけではありませんが、高度な攻撃の大半はパッチが適用されていない 既知の脆弱性を狙っており、この対策にも十分な効果があります。 アクセス制御 アクセス制御は、組織内でセキュリティ・ポリシーを実施する中心的な手段として有効で、現在でもセキュリ 最小権限の原則では、 ティ・アーキテクチャの基盤技術として重要な役割を担っています。 業務の遂行に最低限必 アクセス制御では、ネットワーク上のユーザとデータ間の相互作用を定義して、ビジネス・プロセスを規定 要となる相互作用のみ します。アクセス制御の基本的な考え方は、業務の遂行に必要となる最小限の権限のみを付与するというもの が許可されます です（「最小権限」の原則）。明示的に承認されていない相互作用は、すべて許可されていないと見なされ ブロックされます。 アクセス制御は、組織固有のビジネス・ルール、資産、ユーザ、ロール、およびアプリケーションなどの内容に 依存し、これらの資産、ユーザ、およびアプリケーション間で許可される相互の情報交換を条件とするセキュ リティ・ポリシーを定義します。 例えば、機密性の高いサービスへのアクセスを特定のユーザに許可するかどうかを判断し、そのユーザの 所在地やホストのステータス、時間帯などに基づいて許可するアクセスの内容を決定するのがアクセス制御の 役割です。 02 5 ENTERPRISE SECURITY BLUEPRINT 02 CONTROL LAYER アクセス制御機能は、インバウンド/アウトバウンドの両方向で機能します。インバウンドの制御では、各セグ メントは外部アクセスからセグメント内のリソースを保護します。最小権限の原則を厳密に適用すると、攻撃 対象領域を最小化できます。例えば、セグメント内のアプリケーションに脆弱性が存在しても、アクセス制御 ポリシーによってアクセスが遮断されていれば、脆弱性を悪用されることはありません。また最小権限の原則の 下では、保護されたセグメント内のクライアントに許可される外部サービスは、直接的・間接的に業務に関係 するサービスだけに制限されます。このためアウトバウンドの制御においても、この原則を徹底することが 重要です。 トラフィックの分析と制御は、そのコンテキストに基づいて柔軟に実施できます。例えば、インターネット・ トラフィックは承認されたアプリケーションやプロトコルについての最新情報をクラウド・データベースに照会し、 内部トラフィックでは組織内で使用されている独自のアプリケーションやプロトコルを許可する、といった対応が 可能です。 また制御レイヤは、ネットワーク構成の変更や各種 ITシステムに実装されている定義を認識することもでき ます。例えば、ユーザ・リポジトリに対する変更を把握する、新しい仮想マシンに適切なセキュリティ・ポリ シーを自動で適用する、DNS サーバに登録された新しいホストへのアクセスを許可するなどの処理が可能 です。また SDN の場合、制御レイヤは、ネットワーク・トラフィック・フローを特定の実施ポイントにリダイ レクトして、組織のセグメント化モデルとセキュリティ・ポリシーに基づくネットワーク構成を形成します。 データ保護 組織の情報を確実に守るためには、ストレージに蓄積されたデータとネットワークを転送中のデータの両方を保護 蓄積されたデータと する必要があります。許可されていないユーザによる不正アクセスを防止するには、組織内外に置かれたデータ 転送中のデータの両方を を暗号化します。また組織の基準に基づいてデータを分類し、データ・フローを適切に検査して情報漏洩を 検出、防止します。 データ保護は、データ分類と電子透かしのためのセキュリティ・ポリシーに基づいて実施します。データ分類は データの所有者、属性、内容を、電子透かしはデータの機密性をベースに作成します。電子透かしを使用 すると、ホストや拠点からデータが漏洩し、許可されていない第三者の手に渡ることを防止できます。 またストレージに蓄積されたデータを不正アクセスや改ざんから保護するためには、データ暗号化やデジタル 署名などの対策が必要です。これらの対策は、組織の管理下にあるシステムからデータがコピーされても 永続的に機能します。 暗号化が特に大きな効果を発揮するのは、モバイル・デバイスやリムーバブル・ストレージ、共有ストレージ、 クラウド環境に保存されたデータを保護する場合です。暗号伴や暗号化データへのアクセスを効率よく管理 するには、ローカルまたはクラウド型の伴管理インフラストラクチャが必要となります。また暗号化は、データを 安全に破棄するためにも利用できます。暗号伴を無効にすれば、暗号化データにはアクセスできなくなります。 02 6 保護する必要があります ENTERPRISE SECURITY BLUEPRINT CONTROL LAYER 02 リスクの種類に基づく保護機能の選択 実施ポイントで実行すべき保護機能は、実施ポイントの役割によって異なります。どのような保護機能を実装 するかは、セグメント内のリソース、ユーザに付与する権限、脅威の動向によって決まります。またシステム・ パフォーマンスや運用上の制約についても考慮が必要となります。 制御レイヤには、各セグメント境界の実施ポイントで実行する適切なセキュリティ制御ロジックを選択して、 アクセス制御ポリシーとデータ保護ポリシーを実施し、見つかった脅威に対処する役割があります。 セキュリティ制御を選択するには、まず個々のセグメントまたはセグメントのグループごとにリスク分析を行い ます。リスクとは、セキュリティ・インシデントが組織の運営や資産に与える影響の大きさとその発生確率を 指します。セキュリティ・インシデントの例には、ポリシー違反、脅威の出現、不適切なデータ・フローなどが 挙げられます。リスクを把握すると、それに基づいてセキュリティ制御に優先順位を設定するための枠組みを 策定できます。 セグメント境界をまたがる相互作用には、複数のカテゴリのリスクが当てはまる場合があります。リスクの レベルは、発生確率、成功確率、そして想定される被害の大きさに基づいて決まります。例えばアウトバウンド の HTTPリクエストは、サンプルのリスク・カテゴリに照らして以下のように分析できます。 リスク リスクの具体的な内容 アウトバウンドの HTTPリクエストの分析 内部関係者 権限のあるユーザがセキュリティ・ポリシーに 違反する相互作用を行う セグメント内のユーザは、外部サービスにアクセスする 権限を付与されているか？ 外部からの 攻撃 外部の攻撃者がリソースやサービスへの 不正アクセスを試みる 外部のサービスが攻撃者によって偽装されている 可能性はないか？ データ・ アクセス 攻撃者がネットワークやストレージ・インフラスト ラクチャにアクセスし、転送中のデータや蓄積された データを閲覧、改変する 相互作用で使用されるネットワーク・パスで 盗聴が行われる可能性はないか？ 情報漏洩 機密データが権限のないユーザに送信される、 リムーバブル・メディアに書き込まれる 許可されていない場所に膨大なデータが アップロードできるようになっていないか？ 攻撃者がプロトコル違反により システム障害を引き起こす プロトコル違反によって、クライアントの脆弱性が悪用さ れたりセグメントにマルウェアがダウンロードされたりする 可能性はないか？ 脆弱性の悪用 マルウェア サービス妨害 ネットワークまたはリムーバブル・デバイス経由で 不正なコードが送り込まれ、リソースに悪影響を 及ぼす 相互作用によって、処理能力やストレージ容量、 ネットワーク・キャパシティが大幅に消費され、 承認された相互作用に対するサービスが妨害される そのリクエストは、マルウェアを示唆するような振る舞い （C&C サーバやデータ保管サーバへの接続など）を示し ていないか？ リクエストのレートや持続期間、消費する帯域幅によって、 承認された相互作用のサービス・レベルが影響を受けるか？ 02 7 ENTERPRISE SECURITY BLUEPRINT 02 CONTROL LAYER リスクの検討は、上記のように大まかに行うことも、攻撃手法を想定して詳細に行うこともできます。一連の セキュリティ制御を定義してリスクを軽減し、組織にとって許容可能な水準にまでリスク・レベルを緩和します。 図 2-C は、リスクと保護機能のマッピングを簡潔に表しています。各行には大まかなリスク、各列にはリスクの セグメントを階層型に 影響を軽減する保護機能（感染前の脅威対策など）が記載されています。行と列には、それぞれ「電子メールに グループ化すると、 記載のリンク経由で拡散するマルウェア」などの具体的な攻撃手法、 「レピュテーション・ベースの URLフィル タリング」などの具体的な保護機能を当てはめることもできます。 1 つの相互作用が 複数の実施ポイントを 保護機能とリスクをマッピングすると、以下に示す点が可能となります。 通過する場合があります すべてのリスクを十分に軽減する 複数の実施ポイントを通過する相互作用の保護を検討する際に、どの実施ポイントにどのセキュリ ティ制御を適用するかを判断する 特定のセキュリティ制御では十分な効果が得られない場合や、コストが高すぎる場合、過大なリソース が必要となる場合に、対応しきれないリスクを把握し、セキュリティ制御を調整する 「ステップ 2： セグメントのグループ化」で述べたように、セグメントを階層型にグループ化すると、1つの相互 作用が複数の実施ポイントを通過する場合があります。この場合は、相互作用の通過パスに沿う複数の実施 ポイントにセキュリティ制御を適用し、関連するリスクを軽減する必要があります。例えば、受信した電子メール を既知のマルウェア・シグネチャと照合するアンチマルウェアは、メール・リレーをホストするDMZの入口、 メール・リレー自体、内部メール・サーバ、またはクライアント・ホストの実施ポイントに適用します。 セキュリティ制御とリスクのマッピング 図 2-C アクセス制御 脅威対策 データ保護 リスク 内部関係者 外部からの攻撃 データ・アクセス 情報漏洩 脆弱性の悪用 マルウェア サービス妨害 02 8 インバウンド アウトバウンド 感染前 感染後 ENTERPRISE SECURITY BLUEPRINT CONTROL LAYER 02 制御レイヤは、相互作用に付随するリスクをその通過パス全体を通じて制御できるよう、各実施ポイントに 適切なセキュリティ制御を提供します。セキュリティ制御の適用が推奨される一般的な実施ポイントを以下に 示します。 インバウンドのアクセス制御と感染前の脅威対策（ファイアウォール、IPS、ユーザの認識など） ： セキュリティ制御は、できるだけ保護対象となるリソースの近くに適用する必要があります。セキュリ ティ制御が回避されるリスクを軽減しながら、特定のリソースに合わせたきめ細かな制御を行うこと が可能になります。 サービス妨害対策： 組織の境界にはサービス妨害対策のセキュリティ制御を実装する必要があります。 サービス妨害攻撃の執拗さと発生頻度は増すばかりであり、攻撃を受けたときのリスクも甚大です。 感染前のアンチマルウェア： マルウェアは外部から侵入するのが一般的であるため、このセキュリティ 制御も組織の境界に実装する必要があります。また、マルウェアが埋め込まれている可能性のある文書 ファイルを扱う、エンドポイント・ホストやモバイル・デバイスにも実装します。実施ポイントを選定する 際には、パフォーマンス上の問題や暗号化データへの対応度を考慮する必要があります（暗号化 された電子メールは、マルウェア検査を実施する前に必ず復号化する必要があります）。 感染後の脅威対策： 外部アプリケーションへのアクセスを制限するためのセキュリティ制御は、組織の 境界に実装するのが一般的です。リスクの高い標的やアプリケーションの把握には、複数の情報源から 収集された情報を使用します。また、脅威による被害の拡大を抑止するため、エンドポイント・ホストで アウトバウンドのネットワーク・アクセス制御を実施します。 ネットワーク・レベルの情報漏洩対策： このセキュリティ制御はデータの種類に基づいて実装します。 内部データは組織の境界で制御する必要がありますが、部門データは部門セグメントの境界で制御 する必要があります。またデータへの不正アクセスを防止するため、エンドポイント・ホスト、モバイル・ デバイス、クラウド環境には暗号化のためのセキュリティ制御を実装する必要があります。 実施ポイントの詳しい説明、およびセキュリティ制御と実施ポイントのマッピングの詳細については、付録に 掲載されているネットワーク・セグメントの設計パターンを参照してください。 図 2-D は、前章で紹介した拠点の実装例です。前章の構成から、セキュリティ制御やその実施ポイントが 変更されています。この図では、セグメント境界のセキュリティ制御が 2 台の物理アプライアンスに集約され ています。1 台のアプライアンスは、インターネットとDMZ 間、そしてDMZと内部ネットワーク間のアクセスを 制御しています。もう1 台のアプライアンスには5つのバーチャル・システムがホストされており、各システムは、 MPLS ベースの WAN、LAN、内部サーバ・セグメント、機密サーバ・セグメント、部門サーバ・セグメントの それぞれの制御を担当しています。 02 9 ENTERPRISE SECURITY BLUEPRINT 02 CONTROL LAYER 実施ポイントへのセキュリティ制御の適用 図 2-D V LOG LOG LOG LOG LOG V V V V MP LS 内部 サー 仮想 ゲー化セキ トウ ュリ ェイ ティ ・ バ 重要 なサ ー バ 部門 ログ収集 ログ収集 サー LA N LOG DM 感染後の脅威対策感染後の脅威対策 Z LOG アウトバウンドのアクセス制御 アウトバウンドのアクセス制御 データ保護 データ保護 内部サーバ・セグメントのホストには、ファイアウォール、アンチマルウェア、フルディスク暗号化、集中ロギ ングなどのセキュリティ制御が導入されています。またモバイル・デバイスには、ファイアウォール、暗号化、 ロギング、VPN が導入されています。モバイル・デバイスからインターネット経由で内部ネットワークに接続 する場合は、信頼された VPN チャネルが使用されます（付録の「設計パターン： モバイル」を参照）。 インターネットに直接接続しているセキュリティ・ゲートウェイには、最も多くのセキュリティ制御が実装されて います。不特定多数からアクセス可能なインターネットと組織の境界では、セキュリティ・プロファイルが大きく 異なるためです。具体的に挙げると、 （1）インバウンドのアクセス制御： ファイアウォール、IPS、DDoS 対策、 （2）感染前の脅威対策： アンチマルウェア、 （3）感染後の脅威対策： アンチボット、 （4）アウトバウンドの アクセス制御： アプリケーション制御および URLフィルタリング、 （5）データ保護： データ損失防止（DLP） および VPNです。内部サーバ用のバーチャル・システムに実装されているのは、インバウンドのアクセス制御と 脅威対策（ファイアウォールとIPS）のみですが、これは内部ネットワークではセキュリティ・プロファイルの 違いがそれほど大きくないためです。 広範囲にわたる監視を可能にするため、この図のすべての実施ポイントにはイベント・ロギングも実装され ています。 03 0 セキ ゲーュリテ トウ ィ・ イ ェイ ンタ ーネ ット バ 感染前の脅威対策感染前の脅威対策 インバウンドのアクセス制御 インバウンドのアクセス制御 LOG ENTERPRISE SECURITY BLUEPRINT CONTROL LAYER 02 RSAに対する攻撃の事例研究 ある APT（Advanced Persistent Threat）攻撃の分析 2011 年 3月17日、コンピュータ・セキュリティ・ベンダーの RSA は、自社のネットワークが APT 攻撃によるハッキングを受け、 認証トークン製品「SecurID」に関する機密データが盗まれたと発表しました。顧客企業数社が攻撃被害に遭った RSA は同年 7 月、販売済みの SecurIDトークン 4,000 万個の回収、交換を余儀なくされました。RSA がこの攻撃によって被ったのは、 数百万ドルという多額の金銭的被害にとどまりません。同社は、社会的信用という貴重な財産をも失ったのです。 攻撃は次のような手順で行われました。（1）まず、同社社員の小規模な 2 つのチーム宛てに、 「2011 Recruitment Plan （2011 年の採用計画）」という件名の 2 種類の標的型フィッシング・メールが送られてきました。（2）1 人の社員がそのメール を開きます。メールには、Adobe Flash のゼロデイ脆弱性を悪用するExcelファイルが添付されており、このファイルによって リモート・アクセス・ツール（RAT）の「Poison Ivy」がインストールされました。インストールされたマルウェアは C&Cサーバに 接続し、攻撃者を内部ネットワークに引き入れます。 （3）攻撃者は、ネットワーク内を移動しながらユーザの認証情報を収集し、 管理特権のある認証情報を探し出しました。（4）そしてその認証情報を使用してSecurID に関するデータを盗み出し、データ 保管サーバに送信した後、外部からデータを回収したのです。 図 2-Eと2-F は、どのようなセキュリティ制御を実装すれば、複数の経路を使用するこの攻撃を阻止できたかを示しています。 RSA に対する攻撃 図 2-E イン ター ネッ ト 4 内部 サー デー 3 バ 重要 タセ 2 なサ ー 1 バ ンタ 部門 ー サー バ LA N DM Z 03 1 ENTERPRISE SECURITY BLUEPRINT 02 CONTROL LAYER RSA のセキュリティ・チームは脅威情報を収集しており、分析のための機能も実装していました。そして実際に進行中の攻撃を 検出していましたが、ネットワークに侵入した攻撃者による目的達成を阻止する適切な制御を欠いていました。RSAに対する攻撃 では、一連の相互作用が侵入キル・チェーン 1 に沿って行われています。適切にセグメント化されたネットワークでは、各相互 作用は、インターネットからDMZ、DMZ から内部サーバ・セグメント、内部サーバ・セグメントからアクセス・ネットワークと いったように、複数のセグメント境界と実施ポイントをまたがって行われます。各実施ポイントに異なる種類のセキュリティ制御 ロジックを実装していれば、そのいずれかが攻撃を検出し、ブロックする可能性が高くなります。 以下に示すように、RSA に対するこの攻撃は侵入キル・チェーンに沿ったいくつかのポイントで阻止できた可能性があります。 感染前の脅威対策 - 電子メールの添付ファイルを隔離して、不正な活動を行うかどうかを確認できた可能性があります。 感染後の脅威対策 - Poison Ivyは有名な不正アプリケーションであり、C&Cサーバへの接続はブロックできたはずです。 インバウンドのアクセス制御 - マルウェアに感染したエンドポイントによる最も重要なリソースへのアクセスはブロック できたはずです。 アウトバウンドのアクセス制御 - 組織の境界に DLP を実装していれば、データの外部送信をブロックできた可能性が あります。 データ保護 - 機密情報は暗号化して保存しておくべきでした。 RSA に対する侵入キル・チェーンの進行を阻止するための保護戦略 図 2-F イン ター ネッ ト 感染 脅 威 後の 対策 アウ トバ アク ウンド セス の 制御 4 内部 サー デー バ 重要 タセ なサ ー バ ンタ 3 イン バ アク ウン セス ドの 制御 2 デー タ保 護 部門 ー サー 1 バ LA 感染 脅 威 前の 対策 N DM Z 1 侵入キル・チェーンは、米軍の軍事作戦の攻撃手順を元にLockheed Martin が提唱した、一連のステップで構成されるサイバー攻撃の方法論です。 この概念は、偵察、武器化、配送、攻撃、インストール、指令（C&C）、目的の実行というステップで構成されています。 03 2 ENTERPRISE SECURITY BLUEPRINT CONTROL LAYER 02 制御レイヤのまとめ SDPアーキテクチャの制御レイヤは、保護機能を生成し、実施レイヤに配置する役割を担います。保護機能 には、脅威対策、アクセス制御、データ保護という3 つの種類があります。 それぞれの保護機能を、各セグメントおよびそのリソースに付随するリスクに体系的にマッピングすると、APT 攻撃を含むあらゆる種類の攻撃に対する強力な多層防御を実装できます。 制御レイヤで適切な保護機能を生成するためには、組織およびその情報システムに関する知識（アクセス 制御）、脅威に関する知識（脅威対策）、データ資産およびその分類に関する知識（データ保護）が集約され ている必要があります。 また、各実施ポイントで保護できる範囲を最大化するため、セグメントごとにリスク分析を実施し、評価した リスクを関連するセキュリティ制御にマッピングして、相互作用のパスを分析することも重要となります。 03 3 3 0 管理レイヤ 管理レイヤは、セキュリティと組織のビジネス・プロセスを統合して、SDPアーキテクチャを具現化するための レイヤです。 組織のネットワーク構成は頻繁に変更されます。特に顕著なのは、サービス指向アーキテクチャ（SOA）に ビジネス・プロセスの 基づくネットワークや仮想データセンターなど、アプリケーションがホスト間を、仮想ホストが物理サーバ間を 急速な変化に沿った対応は、 移動し、SDN や API によってネットワーク構成が動的に変更されるような環境です。またモバイル・ユーザの 増加やクラウド・サービスの普及によって、ネットワークの接続範囲が拡大している状況も、構成変更が頻発 セキュリティ管理者にとって する要因となっています。ネットワーク・アドレスやネットワーク・サービス単位でアクセス制御を実施して ほとんど不可能な状態です きたセキュリティ管理者にとって、ネットワーク構成が目まぐるしく変化する現在の状況は非常に大きな負担 となっています。 組織内外のセキュリティ脅威の動向が悪質化の一途を っていることも、問題を複雑にしています。困難な 状況に対処するには、最小権限の原則をよりきめ細かく管理し、ユーザ・アイデンティティやロールの割り当て、 ホストのコンプライアンス状況、データ・アイデンティティ、アプリケーション・アイデンティティ、リクエスト・ パラメータなど、これまで考慮する必要がなかった新しい属性についても対応が迫られます。 このようにネットワークの複雑化が進み、きめ細かなポリシーの運用が求められる中で、ビジネス・プロセスの 急速な変化に沿った対応は、セキュリティ管理者にとってほとんど不可能な状態です。SDP の管理レイヤは 以下に示す特徴を備えるフレームワークを提供し、セキュリティ管理者が抱える課題を解決します。 モジュール型 - セキュリティ・セグメント境界と保護機能の単位でのセキュリティ・ポリシー管理を 可能にします。個々のポリシー管理担当者は、与えられた役割を果たすために必要となる最小限の 情報と権限を利用して、シンプルなポリシーのサブセットを管理できます。 オ ープン - API を使用して、制御レイヤと組織のシステムを自動的に同期します。管理者の負担が 軽減すると共に、ネットワーク内でのセキュリティ・ポリシーの一貫性が向上します。 耐障害性 - サイバー攻撃の検出および阻止と被害の抑止が、ネットワークの可視化によって容易 になります。攻撃を受けた場合でもサービス・レベルを一定の水準に保ちます。また追跡調査や復旧、 共同作業も負担が軽くなります。 03 4 ENTERPRISE SECURITY BLUEPRINT MANAGEMENT LAYER 03 モジュール化 大規模な組織のセキュリティ・ポリシーは非常に複雑化しており、セキュリティ・ポリシーのルールベースを 構成するルールが数千個に及ぶケースも珍しくありません。また多くの組織では、ネットワーク構成の把握が それぞれ局所的に留まる複数のツールを使用してセキュリティ管理を行っています。セキュリティ・ポリシーが 複雑化している上、ネットワークに対する視界が限られているため、管理作業の縦割り化が避けられません。 SDP では、統合管理コンソールを使用して、ネットワークやホスト、アプリケーション、データのセキュリ ティ・ポリシーをまとめて定義できます。またポリシーのモジュール化により、セキュリティ・ポリシー・ルール をポリシー全体の一部のみ対応する独立したモジュールに分割し、シンプルで扱いやすい、再利用可能なコン ポーネントとして管理することができます。分割された各ポリシー・モジュールを1つにまとめ、完全なポリシー として制御レイヤに渡す役割は管理レイヤが担います。 ポリシーをモジュール化するには、実施レイヤで定義した論理的なセグメント境界の単位でセキュリティ・ ポリシーを定義します。各セグメントおよび関連する相互作用に的を絞ることで、ポリシーの定義が大幅に 簡素化されます。 セキュリティ・ポリシーは 論理的なセグメント境界の 単位で定義します ポリシーをモジュール化すると、複数のセキュリティ管理者で管理作業を分担し、組織の課題解決に同時並行 で取り組めるようになります。各管理者は、自身の担当分野に関係するセキュリティ・ポリシーのサブセットの みを管理します。環境の規模をスムーズに拡張するためには、複数の担当者による同時並行でのセキュリ ティ・ポリシー管理に、管理レイヤが対応する必要があります。そしてセキュリティ・ポリシーに対して同時に 変更を加えることができ、臨機応変にマージできる対応が求められます。 各ポリシー・モジュールは、保護機能の種類ごとに、ネットワーク・フローやデータ・フロー、規制遵守などの レイヤおよびサブレイヤ単位で定義します。グローバル・ポリシーは、ポリシー違反とならない範囲で、より 詳細な内容の下位ポリシーで上書きできます。管理レイヤは、ポリシー・モジュール間でのポリシーの継承と 競合の解決のためのフレームワークを提供します。 各ポリシー・モジュールは、 保護機能の種類ごとに、 レイヤおよび サブレイヤ単位で 図 3-Aでは、データベース・サーバが内部サーバ・セグメントにホストされ、このデータベースにアクセスする Web サーバが DMZ セグメントにホストされています。この場合、データセンターのネットワーク管理者は、 定義します 内部ネットワーク上で特定のプロトコルを許可するグローバル・ネットワーク・セキュリティ・ポリシー・レイヤ （1）を定義できます。また、承認された Webアプリケーションを定義するサブレイヤ（2）をDMZ 管理者が 管理し、内部サーバ・セグメントから外部へ送信可能なデータ・オブジェクトを定義する独立レイヤ（3）を、 内部サーバ管理者が管理します。 03 5 ENTERPRISE SECURITY BLUEPRINT 03 MANAGEMENT LAYER ポリシーのモジュール化 図 3-A MPLS インターネット 実施ポイント 実施ポイント 2 1 3 LAN 内部サーバ 部門サーバ 重要なサーバ データセンター 管理レイヤでは、管理者の作業と管理レイヤの自動化スクリプトの両方に対し、最小権限の原則と職務分掌の 原則を適用する必要があります。これによりポリシーが簡素化し、設定ミスが発生する可能性や内部関係者に よる攻撃のリスクが低減します。例えば、アクセス制御と脅威対策の管理を、複数のチームで安全に分担でき ます。 職務分掌を実現する強力な機能が用意されていると、権限の委任を体系的に実施し、専任の担当者だけに セキュリティ管理を依存する場合に避けられないボトルネックを排除できます。例えばビジネス・ユーザに 対し、その職務の範囲内にある要素へのアクセス権を管理する権限を付与し、管理作業を行うための適切な ユーザ・インタフェースを提供できるようになります。極端な例では、日常的に下すセキュリティ上の判断 （不審な Web サイトにアクセスするかどうかなど）をエンドユーザに一任できます。特定のファイルやネット ワーク・サービスにアクセスする業務上の正当性をエンドユーザに提示させたうえで、管理者がその是非を 判断するという仕組みを構築できます。 保護機能の管理方法は保護機能の種類によって異なります。組織固有の構成に基づき、セグメントごとに 定義するアクセス制御ポリシーや、データの分類に基づくデータ保護と異なり、各セグメントの脅威対策は、 以下に示す保護機能の一般的な特性に基づいて選択することになります。 各保護機能の信頼性レベル（誤検出が発生した場合のリスク・レベル） 問題の攻撃がビジネスに与える影響の重要度 セキュリティとパフォーマンスのトレードオフ。一部の脅威対策では、分析に多くの処理能力とスト レージが必要となります。管理者は、管理対象ごとに各リソースを割り当て、適用可能な保護機能や リアルタイムで実行する必要のある保護機能を判断します。 03 6 DMZ ENTERPRISE SECURITY BLUEPRINT MANAGEMENT LAYER 03 自動化 組織のネットワークやアプリケーション、ホスト、ユーザ、ロールの構成は、ビジネス環境の変化に合わせて 刻々と移り変わります。セキュリティ管理者にとって、組織構成の変化に手作業で追随していくことは容易では ありません。サーバやネットワークのアイデンティティや配置場所が頻繁に変わる、サーバ仮想化や SDN などの技術を使用した仮想環境は特に困難です。 組織構成の変化に 手作業で追随する セキュリティ管理者は 困難に直面しています SDP の管理レイヤでは、セキュリティ・ポリシーの管理を自動化し、他のシステムとの連携を可能にする、 オープンな自動化インタフェースが提供されます。 他のシステムとの同期 SDP の管理レイヤは、制御レイヤのセキュリティ・ポリシーと、動的に変化する環境（クラウド連携エンジンや 構成データベース、資産管理システム、アイデンティティ管理インフラストラクチャなど）との同期を可能に します。これは、管理レイヤの API や CLI（コマンドライン・インタフェース）などのインタフェースを通じて、 オブジェクトおよびその属性を自動的に更新することで実現しています。 多くの場合、ABAC（属性に基づくアクセス制御）モデルが自動化のベースとなっています。ABAC モデルの 場合、セキュリティ・ポリシーは、IPアドレスやネットワーク・ポートなどの静的な技術的識別子を使用するの ではなく、コンテキストに基づく論理的な属性（ロール、アプリケーション、データの分類、クライアントや サーバの種類など）の機能として表されます。 図 3-A に示したネットワーク構成において、セキュリティ・ポリシー・モジュールは、Webアプリケーション・ サーバがアプリケーション固有のデータベース・アクセス・プロトコルに基づいてデータベース・サーバに アクセスすることを許可しながら、それ以外のデータベース・アクセスをすべて禁止しています。また、ある システムによって新しいホストがデータベース・サーバと認識された場合、このホストに対し自動的にポリシー・ モジュールを適用します。このホストを保護対象に含めるため、新しいポリシーをインストールする必要は ありません。 以下に示す同期シナリオも考えられます。 アイデンティティ認識とアプリケーション認識で、業務の役割に応じたアクセス制御ポリシーの定義を サポートする データ認識で DLP ポリシーをサポートする クラウド連携により、新たに作成された仮想マシンや物理ホスト間で移動された仮想マシンに自動的 に保護機能を適用する CRMシステムでオープンされたチケットを、管理レイヤが処理するセキュリティ・プロビジョニング・ ワークフローと自動的に同期する ネットワーク管理システムで、セキュリティ・ポリシーの定義に使用可能なネットワーク・トポロジ 情報と資産管理情報を提供する SDN の API を使用して、保護されたセグメント間のネットワーク・フローを適切な実施ポイントで 通過させる 03 7 ENTERPRISE SECURITY BLUEPRINT 03 MANAGEMENT LAYER ルールの管理 多くの場合、セキュリティ構成ルールは時間の経過と共に肥大化していきます。セキュリティ管理者は、新たな ユーザやホスト、アプリケーション、相互作用に対応するため、頻繁に構成ルールに手を加えていきますが、 システムの運用終了がセキュリティ・マネージャに伝えられるケースはほとんどありません。構成ルールの 肥大化は、管理効率に悪影響を及ぼすだけでなく設定ミスを誘発し、必要な保護機能が無効化されてしまう 事態も考えられます。 ポリシー管理を自動化すると、セキュリティ・ポリシーを常に正確な状態に維持できます。以下に示す典型的な ミスを検出して管理者に通知し、ポリシーの調整とチューニングを自動的に行います。 重複するルール： 対応するルールの存在の有無を確認せずに新しいルールを作成すると、ルールの 重複が発生する場合があります。 存在しない要素を参照するルール：このようなルールは構成ルール・セットの肥大化とパフォーマンス の悪化を招くだけでなく、アドレスやアイデンティティが別の目的で再利用された場合に問題を引き 起こす可能性があります。存在しない要素を参照するルールの例としては、保護対象のセグメントには 導入されていないアプリケーションやバージョンの脆弱性を保護するための IPS シグネチャなどが 挙げられます。例えば産業用制御装置を保護する IPS シグネチャは、特定の組織以外ではほとんど 無用の存在です。該当しない組織では、このようなルールを削除できます。 優先順位の高い別のルールによって上書きされているルール：例えば CFO による財務システムへ のアクセスを許可するルールがある一方で、経営陣全体に同様のアクセスを許可するルールがある 場合、前者のルールは後者と重複していることになります。また例外を意図したルールが、より汎用的 なルールによって無効化する場合もあります。このような場合は優先順位の調整が必要となります。 一時的なルール：ある相互作用を一時的に許可するためのルールには有効期限を設定し、期限後は 自動的に削除される設定が必要です。 コンプライアンス違反：セキュリティ・ポリシー構成が PCI DSS や HIPAA、NERC CIP などの業界 規制や法規制に違反している場合、自動的に検出されます。例えば設定ミスにより、暗号化が必要な 相互作用を平文での実行が許可されている場合などが考えられます。 03 8 ENTERPRISE SECURITY BLUEPRINT MANAGEMENT LAYER 03 可視化 可視化が必要となる理由は、状況の正しい認識とインシデントへの迅速な対応の2 点です。前者はネットワーク で発生しているイベントを把握し、後者は発生しているイベントに対して何らかの対処を行います。 制御レイヤの保護機能とインシデント対応担当者の相互作用を支援するSDP の管理レイヤは、インシデント 対応の効率化を可能にします。膨大なデータを分析して異常な振る舞いを見つけ出すことについては自動制御 に分がありますが、不正な振る舞いパターンの把握、誤検出の除外、攻撃者の動機や意図別にイベントを 分類する、効果的で安全な行動指針の決定といった活動については、まだ人間に一日の長があります。ただし、 信頼性レベルが高い指標に合致する不正な振る舞いをブロックするために、自動対応システムが使用される 場合もあります。 状況の認識 管理レイヤは、ネットワークに配置された実施ポイントからイベント情報を収集して集約し、相関分析を実施 します。インシデント対応担当者は、一連のイベントをリアルタイムで視覚的に確認して、最初に使用された 攻撃経路やその後に攻撃を受けたホスト、侵害されたデータを把握します。イベントの調査を行うと、個々の 攻撃で使用されたマルウェアや脅威の振る舞い、ネットワーク・アドレスについての脅威指標が生成されます。 各指標は自動的に制御レイヤへと渡され、さらに実施レイヤに配布されて組織の保護に使用されます。 セキュリティ関連イベントのレポートは、以下に示すさまざまなソースから取得できます。 実施ポイントは、検出された相互作用と脅威指標が一致したことを報告します。 実施ポイントから、不正な相互作用が報告されます。 管理レイヤの分析機能により、承認された相互作用の記録の中に、追跡調査が必要となる異常な 振る舞いが見つかる場合があります。 組織内外の情報源から、不審な振る舞いが報告されます。例えば、使用不能に陥ったサービス状況を ユーザが報告したり、自社が攻撃の発信源になっていると別の組織から指摘されたりする場合が あります。 攻撃の可能性があるインシデントが発見されたら、インシデント対応の手順を開始して問題の重要度を判別し、 それ以降の対応が必要かどうかを判断します。適宜フォレンジック・データを収集、分析し、攻撃の阻止を第一 に考えながら、想定される被害を調査してインシデントの再発を防止します。 不特定多数を狙ったウイルス攻撃やハッキングの場合、インシデントは単発的に発生するのが通常です。この 場合、攻撃を防ぐか被害を回復すれば対応は終わります。一方、広範な攻撃キャンペーンの一環と判断できる 場合もあります。インシデントの見極めは非常に重要です。後者の場合、発見されたイベントや脅威指標に 一致した振る舞いは氷山の一角に過ぎないからです。インシデント対応担当者は、過去のイベント（見つかった イベントより前に発生したイベント）を調査し、今後発生するイベント（見つかったイベント以降に展開される 攻撃）を注視する必要があります。 03 9 ENTERPRISE SECURITY BLUEPRINT 03 MANAGEMENT LAYER 調査の過程で、新しい攻撃の痕跡や感染が疑われるホストが見つかる場合もあります。これらの情報は制御 レイヤに渡され、対応する保護機能の生成と調査範囲の拡大に使用されます。このプロセスでは、過去の イベント情報と組織内外の情報源（インターネットなど）を活用して、以下に示す項目を調査します。 侵入キル・チェーンにおける感染前の活動内容は？ つまり、そのホストがいつどのようにして感染に 至ったのかという経緯です。ホストから行われた活動とホストに対して行われた活動のログを調べ、 侵害行為が行われた期間とそれ以前に行われた活動を把握します。ホストの感染経緯が分かれば、 今後同じ方法で行われる攻撃をブロックすることができます。 他のホストが同じ攻撃を受けていた可能性を示唆する痕跡がログに残されているか？ このような ホストが見つかった場合は調査対象に加えます。 感染後の活動 - 感染が疑われるホストから行われたすべてのアウトバウンドの活動を調査します。 結果によっては、別のホストが侵害を受けていることを示す新たな痕跡が見つかる場合があります。 感染ホストから行われているアウトバウンドの接続は、未知の C&C サーバやデータ保管サーバへの 接続である可能性があります。未知の接続先が見つかった場合は調査を行い、攻撃活動に利用さ れているかどうかを確認して脅威指標を生成します。 インシデント対応担当者は、データの視覚化ツールや分析ツールを使用して、管理レイヤから提供される情報 （振る舞いの正常 / 異常を示す基準値や、イベントの属性と一致する脅威指標など）に基づいて調査を行う ことができます。各イベントの相関分析と既知のパターンとの照合を行うと、確認する必要のあるイベントの 数を減らすことができます。初期対応における各プロセスの連携には、ワークフロー・ツールや意思決定支援 ツールを利用します。また、標的の環境をシミュレートするハニーポットやハニーネットを使用すれば、攻撃 者をおびき寄せてその活動を観察できます。 インシデント対応 攻撃への対応にどのような手段を使用するかは、その対象がキル・チェーンのどの段階に該当するかによって 異なります。つまり、感染前の活動（偵察、配送、攻撃）、または感染後の活動（インストール、指令、目的の 実行）のどちらかによって、取るべき手段が分かれるのです。一般に、攻撃を阻止するための活動には以下に 示すいずれかが含まれます。 脅威と標的との相互作用を防止、ブロックする 相互作用で認められていないプロトコルやデータ・コンテンツの使用を禁止する システムに対する変更やデータ・フローに制限を課す（リソースの使用制限を設ける、境界外への 機密データの送信を防止するなど） 04 0 ENTERPRISE SECURITY BLUEPRINT MANAGEMENT LAYER 03 攻撃者による偵察活動や人に対する工作活動が発覚したり、攻撃が差し迫っている状況を示す脅威情報が 提供されるなど、インシデントの前兆が把握できる場合があります。攻撃への対策を講じるために、各情報を 活用することができます。例えば、悪用される可能性のある脆弱性の解消または隠 、保護機能の配布、マル ウェア配布 Web サイトへのアクセス遮断、脅威指標のインポートなどの対策が可能です。 攻撃がすでに成功し、感染後の活動が高い確率で疑われる場合は、被害を抑止するセキュリティ制御を利用 して相互作用を最小限にとどめ、その間に侵害の痕跡の有無を調査します。相互作用を最小限に抑える構成 を前もってセグメントごとに用意しておくと、セグメントの侵害が発覚した場合や目下の攻撃の影響を受ける 可能性が予想される場合に、その構成を自動的に有効化することができます。業務に不可欠な相互作用を 継続しながら、複数の攻撃経路を遮断する対応が実現します。 標的が 1 つの組織に絞られる、または TTP を標的ごとにゼロから構成し直すような攻撃は、まず滅多に発生 しません。複数の組織で発生したセキュリティ・イベントの情報を集約して共有する協調型のセキュリティ情報 基盤は、実際の攻撃への対策として非常に有効となります。1つの組織で確認された脅威やTTP、脅威指標を 共有すれば、その後に行われる同じ攻撃から別の組織を守ることができます。 管理レイヤのまとめ 管理レイヤはSDPアーキテクチャを具現化するためのレイヤです。アーキテクチャを構成する各コンポーネント が機能できるようにし、セキュリティ管理者と実施レイヤおよび制御レイヤの橋渡し役を担います。 SDP の管理インタフェースでは、アクセス制御ポリシーとデータ制御ポリシーを定義し、各脅威対策を個別に 有効化できます。脅威対策ポリシーは、アクセス制御ポリシーとデータ制御ポリシーによって許可されたトラ フィックに自動で適用し、また複数の管理者や組織外の管理者で管理することもできます。 管理レイヤでは、アクセス制御に関して、各ネットワーク・セグメントに関連付けられたポリシー・レイヤと サブレイヤをサポートすると同時に、複数の管理者による同時並行での管理を可能にする管理権限の委譲機能 を提供する必要があります。 管理レイヤは、組織間の連携を通じて、セキュリティ制御の最適化に必要となる脅威情報を入手します。 また管理レイヤは、ネットワーク内で発生しているイベントを可視化して、プロアクティブなインシデント対応を 可能にします。 04 1 S まとめ 今日のセキュリティ上の課題に対処するには、セキュリティ・アーキテクチャの最新の全体像を把握する必要が あります。セキュリティ脅威は日進月歩で進化を遂げているため、セキュリティ・アーキテクチャには、日々変 わりゆく情報システムの要件に素早く対応し、適応することが求められます。 SDPアーキテクチャはセキュリティ・アーキテクチャの新たなパラダイムであり、モジュール型で動的なセキュ リティ・インフラストラクチャを実現するための実践的なアプローチです。SDP がもたらす優れた柔軟性は、 新たな脅威への対処や、最新のコンピューティング・プラットフォームや、ネットワーキング・プラットフォーム の採用によって生じる課題解決を可能にします。 ネットワーク内で活動する脅威を見つけ出すためには、対策の実施に役立つ実用的な脅威情報を脅威指標と いう形で生成、配布するためのメカニズムとプロセスが必要です。そのため、脅威対策の元になる脅威情報を 組織内外の情報源から収集し、脅威指標として実施ポイントに配布します。実施ポイントは、脅威指標を利用 してセキュリティ脅威をリアルタイムで検出し、ブロックします。 そして耐障害性に優れるオープンでモジュール型のセキュリティ管理により、セキュリティとビジネス・プロセス の統合が実現し、多層型のセキュリティ管理フレームワークに基づいて管理権限の委譲と職務分掌を行う ことが可能となります。また自動化技術が、セキュリティ・アーキテクチャと他のシステムの連携を実現します。 共有された脅威情報が統合された最新のセキュリティ・アーキテクチャを採用することにより、内部リソースの 侵害を許していた外部からの脅威を検出し、感染拡大を抑止して、駆除することが可能となります。 04 2 ENTERPRISE SECURITY BLUEPRINT CHECK POINT SOFTWARE-DEFINED PROTECTION CPP SD CPP SD Check Point Software-Defined Protection Software-Defined Protection（SDP）は、チェック・ポイントがお客様およびセキュリティ・コミュニティ 全般に向けて提唱する実践的なセキュリティ・アーキテクチャです。SDP は、モジュール型で即応的、そして 何よりセキュアなインフラストラクチャの構築を可能にします。 本章では、チェック・ポイント製品を使用してSDPアーキテクチャを構築し、ネットワーク、ホスト、モバイル 環境、およびクラウド環境にセキュリティ・サービスを実装する方法について説明します。 Check Point SDPでは、新たな脅威に対処し、新しいテクノロジーを採用するために必要となる高い柔軟性を 提供します。チェック・ポイントのソリューションは、既知および未知の脅威に対する新たな保護機能を生成し、 短い時間でクラウドを介して防御情報を配信しています。適切なセキュリティ設計アーキテクチャに基づいて チェック・ポイントのセキュリティ・ソリューションを実装すると、新たなリスクを招くことなく、最新の情報 システム・ソリューションを導入できるようになります。 SDPは、相互接続された3つのアーキテクチャ・レイヤが連携し、高パフォーマンスで高い適応性、そして集中 管理可能なセキュリティを実現するエンタープライズ・アーキテクチャです。 04 3 施 レ イ ヤ チ ェ ッ エ ク ン ・ポ ド セ ポ イ キ イ ント ュ ン の リ ト テ ・ ィ チ ェ ッ ク モ ・ポ セ バ イ キ イ ント ュ ル・ の リ テ ィ チ ェ ッ ク ・ ク ポ ラ イ セ キ ウド ント ュ ・ の リ テ ィ 04 4 制 ア ク 制 セ 御 ス 御 レ イ ヤ デ ー 保 タ 護 脅 威 対 策 ィ・ テ ュリ ー キ セ リシ ポ 実 チ ェ ッ セ ク・ キ ポ ゲ ュ イ ー リテ ン ト ィ ト ウ ・ の ェ イ 管 p e n a rt Ev e a rt n A t 理 P レ Is イ ヤ O Sm Sm C o n so le CPP S D CHECK-POINT SOFTWARE-DEFINED PROTECTION ENTERPRISE SECURITY BLUEPRINT Check Point SDP 図 CPSDP-A ENTERPRISE SECURITY BLUEPRINT CHECK POINT SOFTWARE-DEFINED PROTECTION CPP SD Check Point SDP の実施レイヤ 組織の境界が拡張され、曖昧になるにつれ、内部ネットワーク、クラウド環境、そしてモバイル環境で構成される IT 環境全体をセグメント化する必要性が高まっています。 チェック・ポイントでは、各セグメントの境界を保護する幅広い種類の実施ポイントを提供しています。ライン ナップには、高パフォーマンスなネットワーク・セキュリティ・アプライアンスや仮想ゲートウェイ、エンドポイント・ ホスト用のソフトウェア、モバイル・デバイス向けのアプリケーションが含まれます。各実施ポイントを構成要素 として組み合わせることで、セグメント化と統合に対応した安全なシステムおよびネットワークを設計できます。 Check Point SDP 実施レイヤ 図 CPSDP-B 内部 サー 仮想 ゲー化セキ トウ ュリ ェイ ティ ・ 重要 ログ収集 信頼 チャ できる ネル バ なサ ー バ ログ収集 感染前の脅威対策 感染前の脅威対策 LA 感染後の脅威対策 感染後の脅威対策 インバウンドのアクセス制御 インバウンドのアクセス制御 イン ター ネッ ト N DM Z アウトバウンドのアクセス制御 アウトバウンドのアクセス制御 データ保護 データ保護 ネットワークの実施ポイントとなるゲートウェイ チェック・ポイントでは、ネットワーク上の実施ポイントとなるゲートウェイを、アプライアンス、およびオープン・ プラットフォームに導入可能なソフトウェアという2 つの形態で提供しています。どちらも、ネットワーク環境の 要件に合わせて柔軟に実施ポイントを選択できます。 セキュリティ・アプライアンスは、環境の規模に合わせて最適化された19 のモデルが用意されています。（2014 年 3 月現在）支社・支店などの小規模環境向けとなる600アプライアンスおよび 1100アプライアンスから、大規 模企 業やデ ータセンター 環 境で比類ないパフォーマンスと拡 張 性を実 現する業 界 最 速の 61000 セキュリ ティ・システムまで、あらゆる環境に対応するモデルが っています。 04 5 ENTERPRISE SECURITY BLUEPRINT CPP S D CHECK-POINT SOFTWARE-DEFINED PROTECTION 600 アプライアンス （3 モデル） 2200 アプライアンス 12000 アプライアンス （3 モデル） 21000 アプライアンス （3 モデル） 61000 セキュリティ・システム 1100 アプライアンス （3 モデル） 4000 アプライアンス （4 モデル） 13500 アプライアンス チェック・ポイントのセキュリティ・アプライアンス 図 CPSDP-C 堅牢で管理性に優れたアプライアンス用セキュリティ・オペレーティング・システム「GAiA」を搭載するチェック・ ポイントのアプライアンスは、高いパフォーマンスを実現するマルチコア技術と高速ネットワーク技術の組み合わせ により、最高レベルのネットワーク・セキュリティを実現します。 チェック・ポイントの多くのセキュリティ・ゲートウェイは、仮想ゲートウェイをプロビジョニングしてホストすることも できます。多数のルータ、スイッチ、仮想化セキュリティ・ゲートウェイからなる仮想ネットワークを1 つのハード ウェア・プラットフォームに統合して、セキュリティ環境を簡素化、最適化します。 ホスト・ベースの実施ポイント（エンドポイントおよびモバイル向け） ネットワークを効果的に保護するため、セグメント境界のセキュリティは、ホスト・レベルでセキュリティ・ポリシーを 実施するホスト・ベースのソフトウェア・エージェントで補完する必要があります。 Windows および Mac OS に対応するCheck Point Endpoint Security は、ワークステーションやモバイル・ デバイス向けにホスト・ベースのセキュリティ実施ポイントを提供します。 iOS および Android に対応するCheck Point Mobileアプリケーションは、BYOD 環境において、デバイスに 保存されている個人のデータやアプリケーションからは分離し、安全な環境をベースに許可されたユーザが業務用 の電子メール、スケジュールやドキュメントへアクセス可能とする暗号化ソリューションを提供します。 Mobile Access Software Blade は、インターネット経由で内部リソースにアクセスするモバイル・デバイス 向けに、VPN を使用する信頼されたチャネルを提供し、エンドポイントとモバイル・デバイスの実施ポイントを 補完します。 プライベート・クラウドとパブリック・クラウド スケール・メリットの実現や、コンピュータによる処理、ストレージおよびネットワークの各リソースの有効活用を 目的に、クラウド・コンピューティングを導入する組織が増加しています。 04 6 ENTERPRISE SECURITY BLUEPRINT CHECK POINT SOFTWARE-DEFINED PROTECTION CPP SD プライベート・クラウド環境では、Check Point Security Gateway Virtual Edition （VE）を使用することで、ハイパーバイザ・レベルとVMレベル（ネットワーク・モード）の 実施ポイントを実装し、VM 間トラフィックのセグメント化が可能になります。VE による 実施ポイントは、新たに作成されたVMや物理ホスト間で移動されたVMを保護するため、 管理レイヤにより自動的にプロビジョニングされます。 Check Point Virtual Appliance for Amazon Web Servicesを使用すると、Amazon Web Services（AWS）のパブリック・クラウド環境に導入されたシステムに、セグメント化 とファイアウォール・ポリシーを適用できます。 クラウド環境で運用するゲートウェイ チェック・ポイントでは、保護された内部ネットワークの外で業務を行うモバイル・ユーザに対し、組織固有の セキュリティ・ポリシーをクラウド経由で適用するためのゲートウェイを提供しています。モバイル・ユーザの すべてのトラフィックは、脅威対策、アクセス制御、データ保護に対応したクラウド内の実施ポイントを通過 します。 Check Point SDP の制御レイヤ 制御レイヤは、SDPアーキテクチャの中心となるレイヤです。保護機能を生成し、適切な実施ポイントに配置 するという役割を担います。またこのレイヤは、チェック・ポイントが過去 20 年間、業界をリードする革新的な 保護機能を提供してきた分野でもあります。 Check Point SDP の制御レイヤ 図 CPSDP-D R UD 制 御 レ イ ヤ 次 デ 世 ー 代 保 タ 護 ・ ティ リ ュ ー セキ リシ ポ 次 ア 世 ク 代 制 セ 御 ス CL 次 脅 世 威 代 対 策 TH T EA チェック・ポイントSoftware Blade アーキテクチャ SDP におけるの制御レイヤは、環境固有のニーズに応える柔軟で効果的なセキュリティ・ソリューションを 実 現 するチェック・ポ イントの Software Bladeア ー キテクチャに 基 づ いています。20 種 類 以 上 の 04 7 ENTERPRISE SECURITY BLUEPRINT CPP S D CHECK-POINT SOFTWARE-DEFINED PROTECTION Software Blade を自由に選択して導入できるモジュール型アーキテクチャで、実施ポイントごとの最適なセキュ リティ・ソリューション構築が実現するほか、要件に合わせ徐々にセキュリティ・インフラストラクチャを拡張して いくことが可能です。 信頼 で チャ きる イ ンタ ネル ーネ ット Software Blade の有効化 図 CPSDP-E 次世代脅威対策 チェック・ポイントでは、既知および未知の幅広い脅威に対処する効果的なセキュリティ技術を提供しています。 チェック・ポイントの脅威対策ソリューションは、以下に示す主要コンポーネントで構成されています。 統合型侵入防御システム（IPS） ：既知および未知の脆弱性の悪用を防ぎます。 ネットワーク・ベースのアンチウイルス：マルウェアやウイルス、トロイの木馬など、シグネ チャで検出可能な脅威のネットワークへの侵入や感染拡大を防ぎます。また、内部ユーザに よる不正な Web サイトへのアクセスを遮断します。 脅威エミュレーション：仮想サンドボックスでファイルを検査、実行して不正な振る舞いの有無 を確認することにより、未知の脆弱性を悪用するゼロデイ攻撃や標的型攻撃による被害を防止 します。 アンチボット：感染後の対策としてマルウェア感染マシンを検出し、ボットからC&Cサーバへの 通信を遮断して被害の拡大を防ぎます。 04 8 ENTERPRISE SECURITY BLUEPRINT CHECK POINT SOFTWARE-DEFINED PROTECTION CPP SD 脅威対策のセキュリティ制御には、常に最新の脅威情報を提供する必要があります。そのためチェック・ポイ ントでは、クラウド環境で脅威情報のビッグデータと保護機能を生成する「Check Point ThreatCloud ™」 という独自の脅威インテリジェンス基盤を運用しています。 他の組織と共有し共闘を目的とするCheck Point ThreatCloud は、リアルタイムのセキュリティ脅威情報 をセキュリティ指標として制御レイヤに配信します。 ThreatCloud には現在、1,100 万件以上のマルウェア・シグ ネチャ、約 270 万件のマルウェア感染サイトの情報、5,500 件 以上のボットネット通信パターンが登録されています。 ThreatCloud のデータベースには、世界中で情報を収集する チェック・ポイントのセンサー・ネットワークや第三者機関、チェック・ポイントのセキュリティ研究者、セキュ リティ調査機関、そしてチェック・ポイントのゲートウェイから収集された新しい脅威情報が随時追加され、 チェック・ポイントの実施ポイントには、この ThreatCloud からリアルタイムのセキュリティ指標が配信され ます。ある組織に対してマルウェア攻撃が行われた場合は、その攻撃に関する情報がすぐさまThreatCloud に送られます。攻撃のシグネチャは大規模データベースに追加され、ThreatCloud に参加するすべての組織 で即座に利用可能となります。 次世代ファイアウォールとデータ保護 特定のビジネス・プロセスを保護するには、ネットワーク内で発生するユーザとデータ間の「相互作用」* を 定義して、アクセス制御とデータ保護を実施する必要があります。 チェック・ポイントのアクセス制御技術は、複数のSoftware Blade が組み込まれた次世代ファイアウォールを ベースとし、さまざまなコンテキストが統一されたセキュリティ・ポリシーを実施できます。このアクセス制御 技術は以下に示す各機能で構成されています。 次世代ファイアウォールと VPN - ネットワーク層、アプリケーション層、データ層で ネットワーク検査を行うためのエンジンであるチェック・ポイントの特許技術ステート フル・インスペクションが、セキュリティ保護の多層化を可能にする柔軟な基盤を提供 します。 ユーザ・アイデンティティの認識 - ユーザ情報を条件とした、きめ細かなセキュリティ・ポ リシーの実施を可能にします。ユーザ・アイデンティティとエンドポイントのステータス 情報を共有する、チェック・ポイントのセキュリティ・ゲートウェイとエンドポイント・ホ ストにより、組織全体にわたる協調的なポリシーの実施が実現します。 アプリケーション制御 - 5,000 以上のアプリケーションと30 万以上のウィジェットを 網羅する、業界最大規模のWebアプリケーション・ライブラリが、包括的なアプリケー ション制御を可能にします。アプリケーション・トラフィックを常時監視し、組織のセキュ リティ・ポリシーに基づいてトラフィックの遮断や速度制限を実施できます。URLフィルタ リングと緊密に統合されており、レピュテーションやカテゴリに基づく動的なセキュリ ティ・ポリシーの実施をサポートしています。 デ ータとコンテンツの認 識 - Check Point DLP Software Blade は、幅 広い自動 データ分類技術に基づいて各文書の重要性を個別に判別します。 * 相互作用：本書では、ネットワーク、コンピュータ、アプリケーションおよびユーザの関係で通信またはデータのやり取りが行われることを「相互作用」と 総称して使用しています。 04 9 ENTERPRISE SECURITY BLUEPRINT CPP S D CHECK-POINT SOFTWARE-DEFINED PROTECTION 次世代データ保護 チェック・ポイントの次世代データ保護技術には、データ認識の機能が含まれています。データ保護技術の 1 つで あるDLP Software Blade は、コンテンツ検査を実施して、ファイルの内容をリポジトリの登録情報と照合します。 DLP Software Blade による 800 以上のファイル形式のコンテンツ検査や、事前定義済みの 650 以上のコン テンツ・タイプにより、包括的で効率的な業界最高水準の DLP を実現します。 またチェック・ポイントでは、ストレージなどに保存、蓄積されたデータを保護する暗号化技術も提供しています。 これらの暗号化技術をすべての実施ポイントに実装すると、機密性の高い文書やデータへの不正アクセスとリムー バブル・メディアへの無断コピーを防止できます。 Check Point SDP の管理レイヤ 管理レイヤは SDPアーキテクチャを具現化するためのレイヤです。アーキテクチャを構成する各コンポーネントが 機能できるようにし、セキュリティ管理者と実施レイヤおよび制御レイヤの橋渡し役を担います。 モジュール型 / 多層型のポリシー管理 チェック・ポイントのすべての保護機能と実施ポイントは、単一の統合セキュリティ管理コンソールで管理します。 チェック・ポイントのセキュリティ管理製品は高い拡張性を備えており、超高速動作のインタフェースを使用して 膨大なオブジェクトを効率よく管理できます。 SDPアーキテクチャでは、複数の管理者の職務分掌を実現し、担当するセグメントごとにセキュリティ・ポリシーを 定義することが可能なネットワークのセグメント化に対応した管理が求められます。 また各管理者は、脅威対策、アクセス制御、データ保護における自身の役割に応じて、セキュリティ・ポリシーを 容易に把握できることも望まれます。 Check Point Security Management では、レイヤとサブレイヤという新しい概念を使用して各要件に対応し ます。ポリシーはセグメントごとに定義し、個別のレイヤごとにてアクセス制御ポリシーを定義すれば、各ポリシーを 複数の管理者に割り当てられます。複数の管理者が同じポリシーを同時並行で管理することが可能となります。 サブポリシー 図 CPSDP-F 05 0 ENTERPRISE SECURITY BLUEPRINT CHECK POINT SOFTWARE-DEFINED PROTECTION CPP SD 自動化と連携 SDP アーキテクチャでは、アクセス制御ポリシーとデータ保護ポリシーは組織固有の要件に合わせて定義 され、新しいユーザやアプリケーション、ビジネス・プロセスが追加されるたびに変更されます。 各変更をサポートするCheck Point Security Management は、CLIとWeb サービスAPI を提供してい ます。ネットワーク管理やCRM、トラブル・チケット発行、アイデンティティ管理、クラウド連携などのシステム との統合が可能となります。 管理レイヤでは、外部システムとのオープンなインタフェースを介して、環境に行われた変更を把握し、合わせて セキュリティ・ポリシーを調整します。例えば新しい仮想マシンが追加された場合には、そのマシンの分類に 基づく適切なセグメント・ポリシーを自動的に適用するなどの対応が考えられます。 セキュリティ状況を可視化する Check Point SmartEvent 安全な環境を維持するためには、セキュリティ状況の可視化が不可欠です。管理レイヤには、状況の認識と インシデント対応の両機能が備わっている必要があります。 Check Point SmartEventでは、ビッグデータ分析とリアルタイムのセキュリティ・イベントの相関分析を 実施します。複数の情報源から収集されたインシデント情報を1つに集約し、相関分析を行います。どのような イベントが発生したのかを正確に把握できるため、インシデント対応担当者はネットワークの保護に必要な対策 を的確に判断できます。 セキュリティ・イベント解析は、脅威をリアルタイムでブロックするためにThreatCloud 経由で配布できる、 脅威指標という形で対策実施に有効な情報を生成します。 指定した対応を自動で実施する機能を使用すると、対応者が設定ツールを再起動する前に必要なアクションを 取ることができ、脅威による被害の拡大を抑止可能となります。 Check Point SmartEvent 図 CPSDP-G 05 1 ENTERPRISE SECURITY BLUEPRINT CPP S D CHECK-POINT SOFTWARE-DEFINED PROTECTION まとめ 急速な進化を遂げる脅威からネットワークを保護するためには、増加の一途を るネットワーク・トラフィックに対応 するだけでなく、リアルタイムの保護機能を動的に実装できるアーキテクチャが必要です。 SDPは、直面するセキュリティ問題に加えて、将来の問題にも対応可能な柔軟なセキュリティ・アーキテクチャです。 チェック・ポイントは、最高レベルのセキュリティと管理性を備えた、包括的な SDPアーキテクチャの実現に必要と なるすべてのコンポーネントを提供しています。 05 2 ENTERPRISE SECURITY BLUEPRINT CHECK POINT SOFTWARE-DEFINED PROTECTION P C CP チェック・ポイントについて チェック・ポイントは、20 年前の創業以来、インターネットを安全な場所にする使命に基づいて企業活動を 行ってきました。ファイアウォールを発明した創業当初から、ネットワーク・セキュリティ分野全体を牽引する 今日に至るまで、チェック・ポイントは、進化を続けるインターネットを安全に利用するための技術の開発に 一貫して注力しています。 今日のインターネットは、ビジネスに必要不可欠な社会基盤としての役割を担う一方、サイバー攻撃者にとって 犯罪活動を行う格好の場となっています。チェック・ポイントはこの状況を打破すべく、多層型の脅威対策の 実装を可能にし、ゼロデイ攻撃を含むあらゆる脅威に対して最高レベルの保護を実現できる、セキュリティ・ アーキテクチャを開発しました。 チェック・ポイントが提供する包括的なエンタープライズ・セキュリティ・ソリューションは、高い柔軟性を特徴 とするSoftware Bladeアーキテクチャに基づいています。チェック・ポイントの独自開発によるSoftware Bladeアーキテクチャは、本書で解説しているセキュリティ・モデルの実装に最適な枠組みです。Software Bladeアーキテクチャの下で動作するモジュール型のセキュリティ機能パッケージ、Software Blade は、 チェック・ポイントの広範なセキュリティ・アプライアンスやエンドポイント、モバイル・デバイス、クラウド環境 などの幅広い実施ポイントに導入することができます。 同アーキテクチャに基づいて開発され、業界から高い評価を得ているチェック・ポイントの次世代ファイア ウォールやセキュアWeb ゲートウェイ、脅威対策ソリューション、データ保護ソリューションは、DDoS 攻撃や APT 攻撃、ボットネット、ウイルス、ゼロデイのマルウェア、標的型攻撃等のサイバー攻撃の阻止、被害の抑止、 攻撃の結果生じる情報漏洩の抑止効果が実証されています。 クラウド・ベースの脅威情報基盤 ThreatCloud ™を活用するチェック・ポイントのセキュリティ製品とサービス は、最新の脅威に対処します。ThreatCloud には、チェック・ポイントの研究機関や業界のマルウェア対策 機関、世界中のセキュリティ・ゲートウェイから攻撃情報を収集する、世界規模の脅威センサー・ネットワーク によって随時情報が追加されます。 もはやテクノロジー単体では、昨今のセキュリティ問題に対処することはできません。加えて、セキュリティを ビジネス・プロセス全体に組み込むシームレスな統合セキュリティ戦略が欠かせません。この戦略は、綿密に 定義されたセキュリティ・ポリシーをユーザのニーズにマッピングし、セキュリティ・ソリューションに組み込む ところから始まります。ユーザに対する啓蒙も工程に含まれています。なぜなら、組織が直面するリスクの 大半には、意図せずポリシー違反を犯したり機密データを危険にさらすユーザが関わっているからです。さらに、 ネットワークの状況を網羅的に把握できる単一のセキュリティ管理ツールで、セキュリティ実施ポイントを 可視化し、制御する必要があります。 この包括的なセキュリティ・アプローチと革新的なセキュリティ・ソリューションを組み合わせれば、最新の 脅威がもたらす課題に対処すると共に、セキュリティを組織の競争力として位置付けることが可能となります。 多くのアナリストからネットワーク・セキュリティ市場のリーダーと評価されているチェック・ポイントは、この20 年間、エンタープライズ・レベルの革新的なセキュリティ・ソリューションとベスト・プラクティスを提供し続け てきました。チェック・ポイントの製品は、Fortune 100および Global 100の全社をはじめ、大小さまざまな 規模の10 万以上の組織が採用しています。 05 3 A 付録： エンタープライズ・ネットワークの 設計パターン エンタープライズ・ネットワークの設計パターン エンタープライズ・ネットワークの設計パターン・テンプレート 図 A-A データセンター 小規模の 支社・支店 子会社 サーバ WAN アクセス・ ネットワーク サーバ NOC アクセス・ネット 中規模の 支社・支店 MPLS サーバ アクセス・ネット NOC/ SOC DMZ インターネット・アクセス パブリック・クラウド Infrastructure as a Service 本社 モバイル・ワーカー サーバ アクセス・ネットワーク WAN インターネット・アクセス 05 4 V ENTERPRISE SECURITY BLUEPRINT APPENDIX A セキュリティ導入の設定パターンを作成、検討することは、特定の状況下で発生する典型的な問題に対する 汎用的で再利用可能な解決策です。以降のセクションで紹介するのは多くの組織に適用できる一般的な各設計 パターンで、組織のセキュリティ・アーキテクチャを定義する際の素案として利用できます。これを元に、実際の データ処理要素や拠点の種類に合わせてセグメント化のテンプレートを作成し、拠点固有のシステムやアプリ ケーションを当てはめて実装します。作成したテンプレートは、調整を加えることで別の事業部などにも適用で きます。図 A-Aは、さまざまな拠点やサービスのテンプレートを定義した、ある組織のネットワーク構成図です。 以降のセクションでは、サーバ、アクセス・ネットワーク、モバイル、クラウドの設計パターンに適用される セグメント化の原則について説明します。また、インターネット・アクセス、DMZ、ネットワーク・インフラスト ラクチャの設計パターンと、各設計パターンへの実装が推奨される保護機能についても解説します。 設計パターン：サーバ 紹介するサーバ設計パターンは、主にデータセンターや中規模∼大規模環境を想定しています。この設計 パターンでは、組織内外にサービスを提供する一連のサーバおよび関連するネットワーク機器を定義します。 データセンターの設計パターン 図 A-B データセンター サーバ WAN NOC/ SOC DMZ インターネット・アクセス 05 5 ENTERPRISE SECURITY BLUEPRINT A APPENDIX セグメント化 セグメント化のためのアーキテクチャは以下の手順で構成します。 ステップ 1：最小単位の各セグメントには、シンプルなセキュリティ・プロファイルを共有するサーバ・ホスト やネットワーク要素を含めます。セキュリティ・プロファイルは、ビジネス目標（システムの所有権、ビジネス・ オーナー、管理上の責任）、資産（情報の所有権、情報量、サービス・レベル）、アクセス（ユーザ、アプリ ケーション、運用上の特性）、保護の内容（物理、ホスト、ネットワーク）に基づいて定義します。例えば、 メッセージング・アプリケーションとERPシステムでは、セキュリティ・プロファイルが異なるケースが一般的 です。このようなシステム同士は別のセグメントに配置します。 ステップ 2：セキュリティ・プロファイルが大きく異なるデータセンター領域をセグメント化する際には、 階層型のグループ化を使用します。例えば、承認されたユーザのみがアクセスできるアプリケーション、組織 内のすべてのユーザがアクセスできるアプリケーション、顧客のみがアクセスできるアプリケーションがある 場合には、特定のユーザのみがアクセスできるアプリケーションを、組織内のすべてのユーザがアクセスできる アプリケーションから切り離された専用のセグメントに配置します。 セグメントを保護する役割はそのセグメント自体が担うことになりますが、多くのセキュリティ制御は、 認証管理や権限管理、タイム・サーバ、SIEMシステム、ネットワーク管理などの共有サービスを利用して います。他のセグメントとの「相互作用」*を適切に制御できるよう、このようなサービスは専用のセグメント に配置する必要があります。 すべてのデータセンター・リソースを適切なセグメント境界に定義し終えるまで、階層型のグループ化を 繰り返します。結果として定義されるセグメントは、1 つの複雑なセグメントか、以下の図 A-C に示すよう な物理的に分離された複数のセグメントのいずれかになります。 ステップ 3： 各セグメントを保護するための実施ポイントをセグメント境界に配置します。VLAN を使用す ると、スイッチのトランク・インタフェースに接続した 1 台のセキュリティ・ゲートウェイ・アプライアンスで 多数のサーバ・セグメントを保護できます。セグメントの分離が現実的に難しい場合は、ホスト・ベースの セキュリティ制御を使用して、セキュリティ・プロファイルの異なるサーバとの不正な相互作用を防止します。 セグメント化モデルが完成したら、そのモデルに基づいてネットワークを設計し、モデル化した実施ポイ ントにセキュリティ製品を配置します。この際、各セグメントのネットワーク・フローが必ず実施ポイント を通過するように設計します。 ステップ 4：2つのセグメント間で相互作用が発生する場合は、その時点で使用されるネットワークの通過点 や経路を把握しておきます。その相互作用に関わるすべてのネットワーク要素がいずれかのセグメント、または 上位レベルのセグメントに含まれている場合は、対応するセグメントのセキュリティ・ポリシーをネットワーク・ セキュリティ制御アプリケーションで実施する必要があります。第三者が管理するIP バックボーンを通過する 場合など、相互作用で使用されるネットワーク・パスを完全に制御できない場合は、転送中のデータが漏洩や 改変のリスクにさらされます。このような場合は、信頼された暗号化チャネル（VPN）を2 つのセグメント間に 確立する必要があります。 * 相互作用 : 本書では、ネットワーク、コンピュータ、アプリケーションおよびユーザの関係で通信またはデータのやり取りが行われることを「相互作用」と 総称して使用しています。 05 6 ENTERPRISE SECURITY BLUEPRINT APPENDIX A データセンターの設計パターン - サーバ・セグメント 図 A-C データセンター サーバ 信頼されたチャネル 保護機能 一般的なサーバの設計パターンには、以下に示す保護機能を定義します。 インバウンドのアクセス制御 アクセス制御ルールの一環として、セキュリティ・ゲートウェイまたはアプリケーション・レベルのセキュ リティ・レイヤでクライアントの識別と認証を行います。クライアントの識別と認証には、アイデンティ ティ管理インフラストラクチャを使用します。 対象となる外部のクライアント（ユーザ、ホスト、プログラム）にサーバ（ホスト、サービス、アプリ ケーション）へのアクセス権限が設定されているかどうかに基づき、ファイアウォールのセキュリ ティ・ポリシーによる権限付与を行います。アクセス権限の有無は、クライアントとサーバのアイデン ティティに基づいて判断します。 クライアントに特定のアプリケーション・リクエスト（データの挿入や削除、アップロードなど）を行う 権限が設定されているかどうかに基づき、アプリケーションを制御するポリシーによる権限付与を 行います。 IPS を使用して、承認された相互作用に対するプロトコル準拠のチェックを実施します。 ファイアウォールを使用して、サーバ・セグメントの外部からの共有インフラストラクチャ（管理サーバ や各種のネットワーク要素など）への不正アクセスを防止します。 アウトバウンドのアクセス制御 クライアントおよびサーバのアイデンティティとサービス・リクエストに基づき、承認されたアウト バウンドの相互作用のみをファイアウォールで許可します。 感染前の脅威対策 IPSを使用して、サーバ・セグメント境界の内部に配置されたアプリケーションの既知の脆弱性の悪用 をブロックします。 データ保護 組織内外の権限のないユーザへの機密情報の漏洩を防止します。 遠隔地の部門サーバ・セグメントやパブリック・クラウドとの間で行われる相互作用に信頼された VPN チャネルを使用し、セグメント化を補完します。 05 7 ENTERPRISE SECURITY BLUEPRINT A APPENDIX 設計パターン：クラウド クラウド・コンピューティングを導入すると、スケール・メリットを実現し、コンピューティング・リソース、 ストレージ・リソース、ネットワーク・リソースを有効活用できるようになります。仮想マシンとして動作しネット ワーク接続された多数のホストで構成され、仮想マシンは、ハイパーバイザが提供する実行環境／仮想ネット ワーク環境上で動作します。 クラウド環境には、1つの組織が占有するプライベート・クラウドと、不特定多数や特定のユーザ・コミュニティ 向けにサードパーティが提供するパブリック・クラウドの 2 つの種類があります。プライベート・クラウドは、 サーバ・セグメントの一部として、またはインターネット上に実装することも可能です。 クラウドの設計パターン 図 A-D re A-d: Cloud design pattern 仮想 V M マシン レベ と ルのして動 ハイ 実 施 作す パー ポイ る バイ ント ザ・ レ 実 施 ベル ポイ の ント （パ イン ブリ ターネ ッ （プ ま ク・クット ライ たは ラウ ベー WA ド） ト・ N クラ ウド ） 05 8 ハイ パー バイ ザ ENTERPRISE SECURITY BLUEPRINT APPENDIX A プライベート・クラウドやパブリック・クラウドに適用するセグメント化の方法やセキュリティ制御の種類は、 基本的には物理ネットワークと変わりません（前述の「設計パターン： サーバ」を参照）。 セキュリティ・ゲートウェイを物理ネットワークに導入すれば、クラウド環境を、セキュリティ特性や 所有者の異なるアプリケーションをホストする複数の領域にセグメント化できます。 仮想マシン（VM）はクラウド内で自由に移動できます。ただし、セグメント化されたセキュリティ条件の 異なるクラウド間で移動することはできません。 各クラウド内で、仮想セキュリティ・ゲートウェイをハイパーバイザと連携させる、またはVM 内で実行 して、VM 間の相互作用を制御できます。仮想セキュリティ・ゲートウェイは、ハイパーバイザ・レベル または VMレベルどちらでも、連携 API を使用して更新できます。クラウド内で移動された VM を 追跡し、常に同じ保護を適用します。 VMのホスティング・アプリケーションで動作するセキュリティ・ソフトウェアは、各ホストを最小単位の 要素としてきめ細かく制御します。 内部ネットワークとクラウド間の通信には、信頼されたチャネルを使用する必要があります。信頼された チャネルは、ユーザの認証情報（SAML 認証情報など）に基づくユーザ・アイデンティティの確認に も利用できます。 クラウド環境では、機密データがマルチテナント型のシステムで処理および保存されたり、VM の移動後に 放置されたVMイメージや仮想ストレージにデータが残存する可能性があるため、データ保護に特別な注意を 払う必要があります。また、データが保存される地理的な場所についても制御が必要となる場合があります。 データへの不正アクセス対策にはデータの暗号化が有効です。 05 9 ENTERPRISE SECURITY BLUEPRINT A APPENDIX 設計パターン：アクセス・ネットワーク（ワークステーション） アクセス・ネットワークの設計パターンは、支社・支店や本社などの自社環境にエンドユーザ・ワークステー ションを配置する場合に使用します。通常、エンドユーザ・ワークステーションは、内部のサーバ・アプリケー ションと組織外の特定のサービス、およびアプリケーションにアクセスします。他のワークステーションと直接 的に相互作用することは基本的にありません。 アクセス・ネットワークの設計パターン 図 A-E 本社 サーバ アクセス・ネットワーク WAN インターネット・アクセス セグメント化 アクセス・ネットワーク・セグメントのセグメント化モデルは、データセンターの設計パターンと同じ 5 つの ステップに基づいて構築します。その際は、以下に示す点に配慮する必要があります。 エンドユーザ・ワークステーションは、ホスト・ベースのセキュリティ・ソフトウェアを使用して制御する 必要があります。各ワークステーションは、ネットワークおよびその他の I/O インタフェース経由で行 われる相互作用に制御を適用する最小単位のセグメント 2 となります。 エンドユーザ・ワークステーションは、アクセス・ネットワーク・セグメント内でグループ化します。 各セグメントには、シンプルなセキュリティ・プロファイルを共有するワークステーションを含めます。 特殊なセキュリティ・プロファイルを持つユーザ（管理者、顧客サービス担当者、製造担当者、人事 担当者、財務担当者など）のワークステーションは、セグメント境界のセキュリティ実施ポイントの 背後にグループ化します。 ワークステーションで動作するアプリケーションのクライアントには、サーバに接続するタイプが あります。このようなアプリケーション・クライアントとサーバ間の相互作用は制御しなければなり ません。詳細については、前章で取り上げたデータセンターの実施ポイントについての説明を参照し てください。 アクセス・ネットワークは、リモートのサービスにアクセスするため WAN に接続されています。拠点 間通信インフラストラクチャの信頼性を問わず、物理拠点の境界には実施ポイントを構成する必要が あります。多くの組織では、物理拠点をさらに細かくセグメント化しています（構内の建物間や建物 内のフロア間など）。 2 セキュリティ・ソフトウェアがホスト上でのプロセス間相互作用も制御する場合は、プロセスが最小単位の要素となり、ホスト・レベルの境界はその上位 レベルのセグメントとなります 06 0 ENTERPRISE SECURITY BLUEPRINT APPENDIX A 多くのエンドユーザは、組織外のサービスにもアクセスします。インターネットやWiFi など、外部環境 に対するすべてのアクセスを制御する必要があります。 アクセス・ネットワークの設計パターンには、多くの組織で採用されているいくつかのパターンがあります。 必要に応じて、これらのパターンを組み合わせて使用しても構いません。 専用アクセス・ネットワーク 専用アクセス・ネットワークの設計パターンは、データセンターのサーバ・セグメント化モデルに対応する パターンです。エンドユーザ・ワークステーションをその役割に基づいてグループ化し、特定の機能を持つ サーバへの接続を許可します。例えば製造現場のワークステーションについては、製造アプリケーションへの 接続を許可し、外部サービスへのアクセスを禁止します。 アクセス・ネットワークの設計パターン - 専用アクセス・ネットワーク 図 A-F 相互 LA 作用 MP LS イン ター ネッ ト N 内部 サー デー バ 重要 タセ なサ ー バ ンタ 製造 ー サー バ 製造 現場 のL AN 06 1 ENTERPRISE SECURITY BLUEPRINT A APPENDIX 共有アクセス・ネットワーク 共有アクセス・ネットワーク構成では、特定の場所に配置されたすべてのエンドユーザ・ワークステーションが、 共有ネットワーク・インフラストラクチャに接続します。内部サービスと外部サービスへのアクセスは、データ センターまたはインターネット・アクセスのセグメント境界で制御し、ネットワーク・セグメントではなくホスト またはユーザのアイデンティティに基づいてアクセスの可否を判断します。 この構成では、1 台のエンドユーザ・ワークステーションがマルウェアに感染した場合、他のすべてのワークス テーションにも感染が広がる可能性があります。そのため、各ワークステーションを最小単位のセグメントと して定義し、それぞれにホスト・ベースのセキュリティ・ソフトウェアを導入することが推奨されます。 アクセス・ネットワークの設計パターン - 共有アクセス・ネットワーク 図 A-G MP LS イン ター ネッ ト 内部 サー デー バ 重要 タセ なサ ー バ ンタ 製造 ー サー バ LA 06 2 N ENTERPRISE SECURITY BLUEPRINT APPENDIX A 仮想専用アクセス・ネットワーク 仮想専用アクセス・ネットワークは、共有アクセス・ネットワークと専用アクセス・ネットワークの両設計パターン の特徴を兼ね備えたネットワークです。ユーザが組織内で物理的に分散している（共有アクセス）が、その 役割に応じてアクセスを制限する（専用アクセス）必要がある場合に仮想専用アクセス・ネットワーク構成を 採用します。 各エンドユーザ・ホストには、少なくともファイアウォールとVPNを含むホスト・ベースのセキュリティ・ソフト ウェアを導入します。各ホストが関与するすべての相互作用は、特定のサーバ・セグメントを保護するVPN ゲートウェイを通過するように構成します。承認された VPNコミュニティの外部にある要素との相互作用は ブロックします。 アクセス・ネットワークの設計パターン - 仮想専用アクセス・ネットワーク 図 A-H MP LS イン ター ネッ ト 内部 サー デー バ 重要 タセ 信頼 なサ ー され たチ ャネ ル バ ンタ 製造 ー サー バ LA N 仮想デスクトップ 仮想デスクトップ・インフラストラクチャ（VDI）構成では、エンドユーザ・ソフトウェアはデータセンターの仮想 マシンで実行され、エンドユーザ・ワークステーションはユーザとのインタフェースとしての役割のみを果たし ます。ワークステーションとVDI 間の通信は、Microsoft RDPをはじめとするリモート・デスクトップ・プロトコル （RDP）だけに制限します。このアプローチでは保護に関する問題を、以下に示すようにエンドユーザ・ワーク ステーション側とVDI 側に分けて考える必要があります。 1. エンドユーザ・ワークステーションは、共有アクセス・ネットワーク構成または専用アクセス・ネットワーク 構成で配置します。ワークステーションの接続先は、RDP 経由での VDI 環境のみに制限します。 2. VDI 環境は、プライベート・クラウド環境またはパブリック・クラウド環境として実装し、保護します （「設計パターン： クラウド」を参照）。 06 3 ENTERPRISE SECURITY BLUEPRINT A APPENDIX セキュリティ制御は、エンドユーザ・ワークステーションとVDI 間で発生するクライアント/ サーバ型の相互 作用、および各 VDI からデータセンター内のサーバへのアクセスに適用します。また各仮想マシンではホスト・ ベースのセキュリティ・ソフトウェアを実行し、個々の VDI をきめ細かく制御してポリシー違反を防止すると 共に、セキュリティ侵害が見つかった場合の被害拡大を抑止します。 アクセス・ネットワークの設計パターン - 仮想デスクトップ ハイ パー ネッ ト 0 0 ワー ク 1 ネッ ト 0 0 ワー ク 2 ネ ッ ト 0 ワー 0 3 ク ネ ッ ト 0 ワー 0 4 ク R D P デ セ ー ン タ タ ー ク サ ライ ー ア バ ン ・ ト プ ロ / ト コ ル 図 A-I 仮想 V M マシン レベ と ルのして動 ハイ 実 施 作す パー ポイ る バイ ント ザ・ レ 実 施 ベル ポイ の ント 保護機能 通常、アクセス・ネットワークの設計パターンには、以下に示すセキュリティ制御を定義します。 インバウンドのアクセス制御 ホスト・ベースのファイアウォールを使用して、ワークステーションへの外部からのアクセスを制限し、 承認されたプログラムによる適切なサーバ・ホストおよびサービスへのアクセスを許可します。 エンドポイントの I/O ポート（USB ポートなど）を制御して、承認されていないデバイスやリムー バブル・メディアの接続を禁止します。 アウトバウンドのアクセス制御 プロセスやサーバのアイデンティティ、サービス・リクエスト、ホストの侵害状況に基づき、承認された アウトバウンドの相互作用のみをファイアウォールで許可します。 VDI 設計パターンでは、エンドユーザ・ワークステーションが VDI へのアクセスに使用するプロト コルを、リモート・デスクトップ・プロトコルのみに制限します。VDI に対しては、承認されたサービス へのアクセスのみを許可し、クラウド内部からの攻撃を防止します。 感染前の脅威対策 インバウンドの相互作用を検査して、不正なコードやマルウェアが潜んでいないかどうかを確認します。 感染後の脅威対策 ホスト・ベースのソフトウェアを使用して、ワークステーションがマルウェアに感染していないかどうか を検査します。感染が見つかった場合は、被害の拡大を抑止するためのセキュリティ制御を有効に します。 06 4 バイ ザ ENTERPRISE SECURITY BLUEPRINT APPENDIX A データ保護 フルディスク暗号化により、物理的な不正アクセスからデータを保護します。 リムーバブル・メディアを暗号化し、組織外で発生するデータへの不正アクセスを防止します。暗号化 されていないリムーバブル・メディアへのデータ転送を禁止します。 文書ファイルの暗号化により、ファイル・アクセスをきめ細かく制御します。 仮想専用アクセス・ネットワークの設計パターンでは、部門サーバ・セグメントとの間に信頼された VPN チャネルを確立します。 設計パターン：インターネット・アクセス インターネット・アクセス・セグメントは、組織の拠点からインターネットを経由して外部の要素に対して行 われるアウトバウンドの相互作用をサポートするネットワーク要素で構成されます。インバウンドのすべての 相互作用は、制御された共有（DMZ）セグメントで処理する必要があります（次のセクションを参照）。 インターネット・アクセスの設計パターン 図 A-J 本社 サーバ アクセス・ネットワーク WAN インターネット・アクセス セグメント化 通常、インターネット・アクセス・セグメントの内部が複雑な構成になることはありません。以下に示す点に配慮 が必要となります。 インターネット・アクセス・セグメントのセキュリティ・プロファイルはインターネットと同等です。 そのため、このセグメントとの間で発生するすべての相互作用は厳格に制御しなければなりません。 アウトバウンドの相互作用は組織内のクライアントから開始されます。その際は、双方向のデータ・ フローが許可されるため、ユーザが不正な要素またはその疑いがある要素と相互作用することを 防止し、この経路から内部リソースに対して行われる攻撃を阻止するためのセキュリティ制御を実装 する必要があります。 DNS によるドメイン名の解決については特別な注意が必要です。不正な細工が施された DNS 応答 が返された場合、内部リソースがインターネット上の不正な要素と相互作用をさせられたり、マル ウェアに感染した内部ホストとC&C サーバとの相互作用が行われたりするおそれがあります。また アクセス制御を回避するため、DNSトンネリングという手法がしばしば使用されます。 06 5 ENTERPRISE SECURITY BLUEPRINT A APPENDIX ゲスト・ユーザがインターネットにアクセスできるよう、ゲスト用 WiFi ネットワークをインターネット・ アクセス・セグメントに接続する場合は、ゲスト用 WiFi ネットワークから内部リソースへのアクセスを 禁止する必要があります。組織の要件によっては、ゲストのリソースを保護しつつセキュリティ・ポリ シーを実施するために、ゲストとインターネット間に実施ポイントを配置した方が適切な場合もあり ます。 キャッシュなどの目的でプロキシ・サーバを使用する場合は、DMZ に配置する必要があります。これ により、インターネットから行われるプロキシ・サーバへの攻撃が内部ネットワークに波及することを 防止できます。また、プロキシによりIPアドレスが一つに集約される前にユーザが開始する相互作用 を実施ポイントで監視できるようになります。 保護機能 通常、インターネット・アクセスの設計パターンには、以下に示すセキュリティ制御を定義します。 インバウンドのアクセス制御 ファイアウォールを使用してインターネットからの攻撃を防ぎます。 IPS を使用して、プロトコル準拠とデータ・コンプライアンスのチェックを実施します。 アウトバウンドのアクセス制御 ファイアウォールを使用して、承認されたアウトバウンドの相互作用を許可します。アプリケーション 制御では、既知の不正な Web サイトへのアクセスとマルウェア感染や情報漏洩につながるアプリ ケーションの使用を防止します。 ネットワーク・アドレス変換（NAT）により内部のアドレス情報を隠 します。 感染前の脅威対策 IPS を使用して、アプリケーションに存在する既知の脆弱性の悪用を防止します。 アンチマルウェアを使用して、アプリケーションに存在するデータ関連の脆弱性の悪用を防止します。 脅威エミュレーションを使用すると、アプリケーションの振る舞いをエミュレートして不正なコンテンツ を検出、ブロックできます。 DoS 攻撃対策を使用して、システム・リソースを浪費させる攻撃をブロックします。 感染後の脅威対策 ボットとC&C サーバ間の相互作用をブロックします。 データ保護 DLP を使用して、機密データの組織外への漏洩を防止します。 06 6 ENTERPRISE SECURITY BLUEPRINT APPENDIX A 設計パターン：制御された共有ゾーン（DMZ） DMZ の設計パターンは、セキュリティ・プロファイルが大きく異なる2 つのセグメント間で制御された共有を 実現する場合に使用します。インターネットやエクストラネットのユーザに対し、内部リソースへの制御された アクセスを提供する用途が一般的ですが、組織内で機密性の高いリソースを共有するために使用することも できます。 DMZ の設計パターン 図 A-K データセンター サーバ WAN DMZ NOC/ SOC インターネット・アクセス セグメント化 DMZ セグメントが必要となるのは、あるセグメントの内部リソースを侵害した攻撃者が、接続された別の セグメントに不正アクセスする可能性があるためです。このため DMZ のホストは「要塞」ホストと呼ばれる ことがあり、このような攻撃に対処できるよう特別な強化を施すことが求められます。DMZ に接したセキュリ ティ・ゲートウェイは、攻撃を阻止すると共に、DMZ 内からの異常な情報フローを検出するという、2つの役割 を担います。DMZ 内から異常な通信が発生している場合、要塞ホストが侵害を受けている可能性があります。 DMZ セグメントのセグメント化モデルを以下に示します。 DMZ セグメントのセグメント化モデル 図 A-L DMZ 内部 3 外部 （またはセグメントB） 2 1 06 7 ENTERPRISE SECURITY BLUEPRINT A APPENDIX DMZ セグメントには以下に示す実施ポイントを定義します。 1. DMZと外部ネットワーク（またはセグメントB）間の相互作用を制御する実施ポイント 2. DMZと内部ネットワーク間の相互作用を制御する実施ポイント 3. 要塞ホスト自体を保護する実施ポイント 通常、DMZ では複数種類の相互作用の通過を許可する必要があります。例えば以下に示す場合は、Web プロキシとWebアプリケーションの両方で、インターネットに接続された DMZ が必要となります。 内部ネットワークのユーザがインターネット上の Webリソースにアクセスする場合、DMZ には、 Webプロキシ、およびインターネット・ドメイン名を内部ユーザに提供するDNSリレーを導入します。 インターネット上の顧客が、Webフロント・エンド、および内部ネットワークに配置されたデータベース・ サーバから情報を取得するWebアプリケーションにアクセスする場合、DMZ には、Web サーバ、 Webアプリケーション・サーバ、および Webフロント・エンドのドメイン名をインターネット上の顧客 に向けて解決するDNSリレーをホストします。 WebプロキシとWebアプリケーションのセキュリティ・プロファイルは以下のとおりとなります ビジネス目標 Webプロキシ Webアプリケーション 内部ユーザによるWebアクセス 顧客へのアプリケーション提供 なし 顧客データ すべての内部ユーザ 認証を受けた顧客 シンプルなプロキシ・サーバを DMZ セグメントのセキュリティ制御で保護 複雑なWebアプリケーションをアプリケーション・ レベルのセキュリティ制御とDMZ セグメントの セキュリティ制御で保護 資産 アクセス 保護の内容 それぞれのアプリケーションのセキュリティ・プロファイルは大きく異なります。Webプロキシへのアクセスを 承認されたユーザは、必ずしも顧客データへのアクセスを承認されていません。このため DMZでは、各アプリ ケーションを個別に保護されたセグメントに配置し、Webプロキシが侵害されても顧客データに影響が及ば ないよう配慮する必要があります。同時に、Webアプリケーションが侵害されても、攻撃者がアウトバウンドの Webトラフィックを制御できないように設定することも重要です。 このセグメント化モデルでは、DMZ を狙ったサービス妨害攻撃に対してより強固な保護を実現できます。 サービス制御を分離する、または強力な制御を使用すれば、DMZ 内のサーバに対してネットワーク回線を飽和 させる攻撃が行われた場合でも、組織内からのアウトバウンドのアクセスが受ける影響を回避できます。例えば、 インバウンドとアウトバウンドのネットワーク・フローに異なるISPリンクを使用するなどの対策が考えられます。 DMZ セグメントのセグメント化モデル 2 図 A-M 内部 外部 （またはセグメントB） 06 8 ENTERPRISE SECURITY BLUEPRINT APPENDIX A この場合は、インバウンドとアウトバウンドのドメイン名解決にそれぞれ専用の DNS サーバを用意し、イン バウンドの DNS サーバでは外部からのアクセスを許可するアドレスのみを解決するように設定します。 保護機能 通常、DMZ の設計パターンには以下のセキュリティ制御を定義します。 インバウンドのアクセス制御 ファイアウォールを使用して、承認されたインバウンドの相互作用を許可すると同時に、インターネット （図 A-L のマーカー1）と内部ネットワーク（図 A-L のマーカー2）からの攻撃を防ぎます。 IPS を使用して、プロトコル準拠とデータ・コンプライアンスのチェックを実施します。 アウトバウンドのアクセス制御 ファイアウォールを使用して、DMZ から内部のサーバおよびサービスへの承認されたアクセスを許可 します。 感染前の脅威対策 IPS を使用して、アプリケーションに存在する既知の脆弱性の悪用を防止します。 感染後の脅威対策 要塞ホストが侵害を受けた場合に、被害の拡大を抑止します。 ボットとC&C サーバ間の相互作用をブロックします。 設計パターン：モバイル ユーザの担当業務によっては、外出先から組織内の情報システムへのアクセスが必要になる場合もあります。 このようなアクセスは、組織が支給するノートPCやモバイル・デバイス（スマートフォンやタブレットなど）以外 にも、自宅の PC やネットカフェの共用 PCといった組織の管理下から外れたデバイスから行われるケースも あります。モバイル・アクセスは、新たなセキュリティ問題を組織にもたらします。 すべてのモバイル・デバイスは、物理的な窃盗やアクセスに対して脆弱です。デバイスを組織が支給している 場合には使用を制御することができますが、現在広まりつつあるBYOD（Bring Your Own Device： 個人 所有のデバイスの業務利用）では、ユーザは個人所有のデバイスから組織のリソースにアクセスします。この 場合、組織がデバイスをきめ細かく制御することは不可能です。また、公共ネットワークであるインターネットに 接続するモバイル・デバイスは、組織の内部ネットワークに置かれたワークステーションよりもマルウェアへの 感染リスクが高くなります。 モバイル・デバイスに関するもう1つの課題は、プラットフォームやオペレーティング・システムの多様性です。 この課題は、汎用的な実施ポイントでは必要なすべての保護機能に対応できないという問題をもたらします。 特に、プラットフォームの処理能力やストレージ容量が十分でない場合に大きな障害となります。 06 9 ENTERPRISE SECURITY BLUEPRINT A APPENDIX セグメント化 モバイル・デバイスは最小単位のセグメントであり、デバイス・ベースのソフトウェアを使用して保護する 必要があります。モバイル・デバイスは、信頼されたチャネルを介して、組織の DMZ セグメントに配置された モバイル・アクセス・サーバ（図 A-N）またはパブリック・クラウド（図 A-O）に接続します。モバイル・アクセス・ サーバでは、モバイル・デバイスから組織内のリソースへのアクセスを仲介します。また、モバイル・デバイス によるインターネット・アクセスをモバイル・アクセス・サーバで仲介すると、モバイル・デバイスの保護を 多層化できます。 モバイルの設計パターン 図 A-N データセンター モバイル・ デバイス インターネット・ アクセス 信頼できるチャネル DMZ 組織の リソース インターネット モバイル・ アクセス・ サーバ モバイル・デバイスには、少なくともデータ保護を実装する必要があります。この設計パターンでは、ネット ワーク・アクセス制御と脅威対策の実行およびセキュリティ・イベント・ログの保存をモバイル・アクセス・ サーバまたはクラウドの実施ポイントに委ねることができるため（「クラウドでのセキュリティ実施」を参照）、 モバイル・デバイスの性能に依存せずに必要な機能を実装できます。 モバイル /クラウドの設計パターン 図 A-O モバイル・ デバイス インターネット クラウド 07 0 組織の リソース ENTERPRISE SECURITY BLUEPRINT APPENDIX A 保護機能 通常、モバイルの設計パターンには以下の保護機能を定義します。 インバウンドのアクセス制御 ファイアウォールを使用して、モバイル・デバイスのネットワーク・トラフィックを、モバイル・アクセス・ サーバにトンネリングされるアウトバウンドの相互作用に制限します。 組織のリソースに対するアクセスを許可する前に、複数ファクタによるユーザ認証を実施します。 アウトバウンドのアクセス制御 ファイアウォールを使用して、承認されたアウトバウンドの相互作用を許可します。アプリケーション 制御では、既知の不正な Web サイトへのアクセスやマルウェア感染や情報漏洩につながる、アプリ ケーションの使用を防止します。 ネットワーク・アドレス変換（NAT）により内部のアドレス情報を隠 します。 感染前の脅威対策 IPS を使用して、モバイル・アプリケーションに存在する既知の脆弱性の悪用を防止します。 アンチマルウェアを使用して、アプリケーションに存在するデータ関連の脆弱性の悪用を防止します。 クラウド・ベースのサンドボックスを使用して、アプリケーションの振る舞いをエミュレートして不正な コンテンツを検出、ブロックします。 感染後の脅威対策 モバイル・デバイスがマルウェアに感染していないかどうかを検査します。 モバイル・アクセス・サーバで、ボットによるC&C サーバへの接続を検出します。 侵害の痕跡が見つかった場合は、被害の拡大を抑止するためのポリシーを実施します。 データ保護 VPN を使用して、モバイル・デバイスとモバイル・アクセス・サーバ間に信頼されたチャネルを確立 します。 モバイル・デバイスに保存またはキャッシュされる業務データを暗号化します。 モバイル・アクセス・サーバとのセッション終了時に、モバイル・デバイスに残された情報を消去します。 設計パターン：ネットワーク・インフラストラクチャ ネットワーク・インフラストラクチャは、ネットワーク・トラフィックを発生させるアプリケーションを実行し、 ホスト間通信をサポートする複雑なハードウェア・コンポーネントとソフトウェア・コンポーネントで構成されて います。各コンポーネントの管理と監視には、ネットワーク管理アプリケーションを使用します。 ネットワーク・インフラストラクチャの保護は、以下に示す原則に基づいて実施する必要があります。 ネットワークのセグメント化モデルでは、各ネットワーク要素が最小単位のセグメントとなり、外部の 攻撃からネットワーク要素自体を保護する役割を担います。通常、ネットワーク要素が実施するセキュ リティ・ポリシーでは、以下に示す各対策を行います。 1. 制御プレーンとデータ・プレーンを物理的に分離する：トラフィック転送のためのポートを、制御や 監視の役割から外します（逆も同様）。制御プレーンのポートは、実運用環境のネットワークから 物理的、または VPN などで仮想的に切り離されたLOM（Out-of-Band Management）用の ネットワークに接続します。 2. 制御プレーンから接続する際には認証と権限付与を行う。 3. セキュリティ監査記録は、制御プレーンの監視システムに転送する。 07 1 ENTERPRISE SECURITY BLUEPRINT A APPENDIX ネットワーク・インフラストラクチャは、ネットワーク要素の侵害リスクを管理できるようにセグメント 化する必要があります。これは特に、ネットワーク要素でネットワークを仮想化している場合に重要で す（「仮想 LAN（VLAN）」と「Software-Defined Networking（SDN）」のセクションを参照）。 例えば特に厳重な保護が必要となるセグメントでは、物理的に独立したスイッチを使用します。この スイッチを、セキュリティ・プロファイルが大きく異なる別のセグメントと共有してはなりません。 ネットワーク管理アプリケーションは、境界のセキュリティ制御で他のセグメントから保護された セグメントにグループ化します。 複数のセグメントで構成されるネットワーク・インフラストラクチャを通過するネットワーク・トラ フィック・フローに対しては、サーバ・セグメント境界とアクセス・ネットワーク・セグメント境界の セキュリティ制御を使用して、最小権限の原則を実施する必要があります。例えば、エンドユーザ・ ワークステーションがネットワーク・スイッチを 回したり、設定に対する改ざんを妨げるようにする 必要があります。不正なルートの挿入はセグメント境界でブロックします。 ネットワーク・インフラストラクチャの 設計パターン 図 A-P 制御プレーン データ・プレーン ネットワーク 管理 アプリケーション セキュリティ・ ゲートウェイ スイッチ ルータ 攻撃を受けた場合でも業務を継続できるよう、ネットワーク・オペレーションズ・センター（NOC）に は、保護された専用のセグメントを用意することが推奨されます。これは、LOM 用のネットワークを 使用する、または QoS を使用してセキュリティ監視用に最小限の帯域幅を確保すれば実現できます。 07 2 ENTERPRISE SECURITY BLUEPRINT APPENDIX A 設計パターン：セキュリティ・オペレーションズ・センター（SOC） イベントのロギングは、すべての実施ポイントで重要なセキュリティ制御要件です。ログに記録したイベント 情報は、長期保存と分析に対応した集中リポジトリに集約する必要があります。複数の拠点で構成されるネット ワークでは、多くの場合、ネットワーク帯域幅の消費量を削減するため、ローカルでログを保存してから1 箇所 に集約するという方法が採用されます。ホスト・レベルとネットワーク・レベルのイベントの両方に対応した 統合型のイベント管理インフラストラクチャでは、複数の経路から行われる攻撃を詳細に分析できます。 発生したイベントに自動および手動で対応する仕組みを構築するには、セキュリティ制御をリアルタイムで 調整して攻撃をブロックし、被害の拡大を抑止できる集中管理機能が望まれます。これらのセキュリティ制御 は、ネットワークやホスト、アプリケーション、データ、脅威動向の状況（アプリケーションのリスク、攻撃源、 既知のマルウェア、アプリケーションの脆弱性など）の変化に合わせて更新してください。 ネットワーク管理アプリケーションと同様、ロギングおよびセキュリティ管理サーバも、セキュリティ・インフラ ストラクチャに対する攻撃を防止するため、専用のネットワーク・セグメントに配置します。また実施ポイント へのポリシーの配布やログの収集など、重要なセキュリティ・データをネットワーク経由で転送する場合は、 改ざんを防ぐため信頼できるチャネルを使用しなければなりません。信頼されたチャネルは、セキュリティ管理 ホストのなりすましを防ぐ目的でも使用できます。 保護機能 通常、SOC の設計パターンには、以下に示す保護機能を定義します。 インバウンドのアクセス制御 ファイアウォールを使用してSOCとの相互作用を厳格に制限することにより、ネットワーク管理サーバ やサービスへの不正アクセスを防ぎ、承認された制御プロトコルのみを許可します。 IPSを使用して、承認された相互作用に対するプロトコル準拠のチェックを実施します。 インバウンドの脅威対策 不正なルートの挿入や、ネットワーク・インフラストラクチャ・サービスへの不正アクセスを防止します。 IPSを使用して、管理アプリケーションに存在する既知の脆弱性の悪用を防止します。 データ保護 VPNを使用して、ネットワーク要素のLOMに使用する信頼されたチャネルを構築します。 07 3 SOF T WAR E-DEF INE D PROT ECT ION E nterpri se Securit y B lu eprin t SOFTWAREDEFINED PROTECTION Enterprise Security Blueprint チェック・ポイント・ソフトウェア・テクノロジーズ株式会社 〒160-0022 東京都新宿区新宿5-5-3 建成新宿ビル6F http://www.checkpoint.co.jp/ E-mail:[email protected] Tel:03（5367）2500 P/N EOJ24D0 2014.4