ハイブリッドクラウドのセキュリティ参照アーキテクチャ
- リファレンスアーキテクチャは、各環境において、ID管理、ポリシー、適用、データ制御、および監視がどこに位置するかを示しています。
- ポリシー決定を1つのコントロールプレーンに一元化し、その適用をトラフィックが実際に流れる場所へと分散させる。
- オフィスでのブラウジングからAIエージェントに至るまで、6つのトラフィックフローが、ほとんどのハイブリッド環境を網羅しています。
- 物理的なネットワークではなく、トラストゾーン、データクラス、および管轄区域の周囲に制御境界を設定する。
- コンポーネントをCISAおよびNISTのコントロールにマッピングすることで、そのアーキテクチャは監査対応可能な証拠となります。
ハイブリッドクラウドのセキュリティリファレンスアーキテクチャとは、オンプレミスインフラストラクチャ、プライベートクラウド、SaaS、パブリッククラウドの各環境間でセキュリティ対策がどのように連携するかを示す、ベンダー中立の青写真です。これは、導入計画の策定、ベンダー間の比較、監査人へのセキュリティ設計の説明、およびゼロトラストへの進捗状況の測定などに活用されます。
この記事では、包括的なリファレンスモデルを紹介しています。その内容には、設計原則、論理図および展開図、コンポーネントリファレンス、6つのトラフィックフロー、制御境界、ID管理、ロギング、容量、耐障害性に関する設計上の考慮事項、CISAおよびNISTのコントロールへのマッピング、5つの導入事例、ならびに検証テストを含む成熟度向上の道筋が含まれています。
この記事は、「ハイブリッドクラウドのセキュリティ」ガイドの一部です。ハイブリッド環境のインフラストラクチャ全般については、「ハイブリッドクラウドアーキテクチャ:構成要素と導入モデル」をご覧ください。
参照モデルの背後にある設計原則
この参照モデルは、NISTおよびCISAのゼロトラストに関するガイダンスに基づいて策定された4つの原則に立脚しています。
- 決定と実施を区別する。NISTSP 800-207では、アクセスを許可するかどうかを決定する「ポリシー決定点(PDP)」と、接続を有効化、監視、または切断する「ポリシー実施点(PEP)」とを区別している。PDP は 1 つだが、PEP は複数存在する。
- ネットワーク上の位置情報に基づいて信頼を認めてはなりません。企業内LANに接続されているという理由だけで、認証や検査を省略してはなりません。NISTSP 800-215では、意味のある境界線の消失が、今日の企業ネットワークの決定的な特徴であると述べられています。
- データの保存場所ではなく、分類に基づいてデータを保護します。制御は、データがどこに移動しても、そのデータ分類に追従します。
- 個々の依存関係がどれでも障害を起こす可能性があるものと仮定します。IDプロバイダー、クラウドサービス、WAN回線がすべてダウンします。このアーキテクチャでは、そうした事態が発生した際の対応が定義されています。
2025年6月に24社のベンダーと共同で発行されたNISTの実践ガイド「SP 1800-35:ゼロトラストアーキテクチャの導入」は、オンプレミス環境およびクラウド環境におけるこれらの原則の19の実装例を示しており、本モデルを補完する有用な資料となっています。
建築図面
このリファレンスアーキテクチャは、2つのビューによって説明されます。1つは各レイヤーの構成を示す論理ビュー、もう1つはコンポーネントが実行される場所を示すデプロイメントビューです。
論理アーキテクチャ
論理アーキテクチャは、集中型の制御プレーン、分散型の適用プレーン、および共有型の可視化プレーンの3つのプレーンで構成されています。
コントロールプレーンではポリシーを一度定義します。エンフォースメントプレーンは、トラフィックが流れるあらゆる場所でそのポリシーを適用します。ビジビリティプレーンは、すべてのエンフォースメントポイントからテレメトリを収集し、リスクシグナルをポリシーにフィードバックします。

導入トポロジー
展開ビューでは、本社、支店、クラウドリージョン、およびリモートユーザーにおいて、各エンフォースメントポイントが物理的にどこで稼働しているかが表示されます。

コンポーネントリファレンス
各コンポーネントには、それぞれ明確な役割、配置、およびハイブリッド特有の要件が定められています。
| コンポーネント | 飛行機 | 一般的な配置 | 必須の要件 | ハイブリッド方式の検討 |
|---|---|---|---|---|
| IDプロバイダー | 制御 | クラウドでもオンプレミスでも、高可用性を実現 | ユーザー、デバイス、ワークロード、およびエージェントの認証を行い、コンテキストを提供する | 到達不能時のフォールバックを定義する;人間以外のアイデンティティも対象とする |
| ポリシーエンジンとコンソール | 制御 | クラウド、オンプレミス、あるいはその両方 | 1つのポリシーセットを保持し、すべての適用ポイントに展開する;バージョンの変更 | オンプレミスとクラウドでの適用を同一のルールで管理しなければならない |
| 分類およびDLP辞書 | 制御 | 中央から各執行拠点へ配布される | 機密データを一度定義する | 可能な場合は、顧客環境内で指紋を作成する |
| Secure web gateway (ローカル) | 執行 | データセンターおよび大規模施設 | Webトラフィックを検査し、TLSを復号化し、脅威およびアクセスポリシーを適用し、クラウドで適用されるデータ保護のためにトラフィックを転送する | クラウドサービスの中断中も、ローカルでの脅威対策およびアクセス制御は継続されます。転送されたコンテンツとクラウド上で提供されるサービスは、それぞれ個別に評価してください。 |
| Secure web gateway (クラウド) | 執行 | 承認済み地域におけるベンダーのPoP | リモートユーザーに対しても同様の機能 | 居住地に関する地域制限 |
| CASB(インラインおよびAPI) | 執行 | クラウド | SaaSの利用、共有、および保存データの管理 | DLPとの株式分類 |
| ZTNAゲートウェイ(ローカル) | 執行 | 保護されたアプリケーションの隣 | オンサイトユーザーおよび社内システムに対するアプリケーションごとのアクセス権限 | サポート対象のローカルセッションについては、クラウド経由の転送を回避可能。ID、ポリシー、および障害時の依存関係を検証する |
| ZTNAブローカー(クラウド) | 執行 | アプリコネクタを備えたベンダーPoP | リモートユーザーに対するアプリケーションごとのアクセス権限 | ローカルパスと同じ権限 |
| セグメンテーション・ファイアウォール | 執行 | トラストゾーン間、特にIT/OT間 | ゾーン間のデータフローを制限する | 同じ政策意図から導き出された規則 |
| エンドポイントおよびブラウザの制御 | 執行 | ユーザー端末とブラウザセッション | トラフィックを誘導し、セッション内でデータ制御を実施する | AIツールと管理対象外のパスを網羅しています |
| HSM または鍵管理 | サポート | オンプレミスとクラウド | 検査用CAおよび暗号化鍵を保護する | 規制対象のトラフィック向けの顧客管理型キー |
| ログパイプライン | 可視性 | ローカルのコレクターと中央のSIEM | イベントの収集、ルーティング、および保持 | 滞在状況を考慮したルーティングと保持 |
| SIEMとUEBA | 可視性 | 中央 | 環境をまたいだ相関分析と検知 | リスクシグナルを政策部門にフィードバックする |
| DSPM | 可視性 | クラウドとオンプレミスでのスキャンを併用 | 機密データの棚卸しと漏洩リスク | 特定のツールがどのリポジトリおよびインラインパスを対象としているかを確認する |
交通の流れ
6つのトラフィックフローで、ほとんどのハイブリッド・エステートを網羅しており、各フローには、文書化された適用ポイントと復号ポイントがそれぞれ1つずつ設けられている必要があります。
フロー 1:オフィスユーザーからインターネットまたはSaaSへ
ユーザーはIDプロバイダーを通じて認証を行います。トラフィックはローカルゲートウェイに送信され、そこで復号化、脅威の検査、Webおよびアクセスポリシーの適用が行われた後、データ保護の対象となるセッションは、同じポリシーに基づいて検査を受けるため、ベンダーのクラウドへ転送されます。この経路におけるTLSの終端処理と再暗号化を文書化し、TLS検査リスクの管理に関するNSAのガイダンスに沿って、重複した検査を回避してください。
フロー 2:リモートユーザーから SaaS へ
エンドポイントエージェントまたはブラウザの制御機能により、トラフィックは最も近い承認済みのクラウド拠点へと誘導されます。適用されるポリシーセットはフロー1と同様です。CASBでは、テナント制限やアクティビティレベルのDLPなど、SaaS特有の制御機能が追加されます。
フロー 3:ユーザーからプライベートアプリケーションへ
アクセスは、ネットワークレベルのVPNではなく、ZTNAを経由して行われます。アクセスサービスは、身元、デバイスの状態、およびポリシーを確認した上で、ユーザーを承認されたアプリケーションにのみ接続します。導入環境によっては、リモートユーザーにはクラウドブローカーを、サポート対象のオンプレミスセッションにはローカルゲートウェイを使用する場合があります。ブローカーの配置、アプリケーションプロトコル、セッションの可視性、および実際のデータパスを確認してください。「プライベートアプリケーション向けのオンプレミスZTNA」を参照してください。

フロー 4:ワークロード間
データセンターとIaaSワークロード間のサービス間トラフィックでは、ワークロードID、相互TLS、およびセグメンテーションルールが使用されます。どのサービスが通信できるかは、同じポリシーソースによって定義されます。
フロー 5:クラウドサービス内の保存データ
CASB APIの統合とDSPMスキャンにより、クラウドストレージおよびSaaS上で機密データ、リスクの高い共有、過剰な権限を検出し、インラインで適用されたのと同じ分類に基づいて是正措置を講じます。「DSPMとSSEの連携方法」をご覧ください。
フロー 6: AI エージェントとサービスアカウント
AIエージェントや自動化システムは、多くの場合、ユーザーレベルのアクセス権を持ち、ネットワーク内部から発信されるWebSocketなどの長期接続を介して内部APIを呼び出します。各エージェントに固有のIDとアプリケーションごとの権限を割り当て、そのトラフィックをローカルの適用ポイント経由でルーティングし、外部のAIサービスへ送信するデータに対してDLPを適用してください。
制御境界
制御境界は、機器が設置されている場所ではなく、保護すべき対象の周囲に引くべきである。
| 境界 | 何が区別されるのか | 主要な制御機能 |
|---|---|---|
| アイデンティティの境界 | 認証済みおよび未認証の主体からの認証 | IdP、MFA、条件付きアクセス |
| アプリケーションの境界 | 他のすべてのアプリとは独立したアプリ | ZTNA、アプリごとのポリシー |
| データの境界 | レジデンシーの境界であるリージョン内に留めておかなければならないデータやログ。さらに、主権の範囲には、インフラを運用する主体も含まれる。 | DLP、暗号化、ローカル検査 |
| 管轄区域の境界 | リージョン内に保持する必要があるデータおよびログ | ローカルでの適用、居住地を考慮したログ記録 |
| IT/OTの境界 | 企業のIT部門が提供する運用技術 | セグメンテーション・ファイアウォール、制限対象のプロトコル |
| プロバイダーの境界 | プロバイダー側からのあなたの責任は、 | 文書化された責任分担マトリックス |
管轄区域の境界は、見過ごされがちです。復号化されたトラフィック、検査ログ、またはDLPインシデントのコピーが管轄区域外へ流出すると、保存されたデータ自体が移動していなくても、アーキテクチャがデータ居住要件に違反する可能性があります。「ハイブリッドクラウドセキュリティにおけるデータ主権」を参照してください。
ハイブリッドクラウドのネットワークセキュリティ
ハイブリッド環境におけるネットワークセキュリティは、境界の保護から個々の接続の保護へと移行しています。
- サイト間トラストを、セグメンテーションとアプリケーションごとのアクセス制御に置き換える。
- サイト間およびクラウドリージョン間で暗号化されたトンネル(IPsec、GRE、またはプライベート相互接続)を維持しますが、トンネルの所属を認証の根拠として扱わないでください。
- トラフィックを意図的に誘導する:管理対象のオフィスネットワークには明示的なプロキシまたはPACファイル、ローミングユーザーにはエージェントやブラウザ制御、支店にはトンネルを使用する。
- 各フローをどのコンポーネントが復号化するかを決定し、どのフローも二重に復号化されないようにします。
- すべての取り締まり地点で記録を取り、一元的に照合する。
NIST SP 800-215 では、ZTNA、マイクロセグメンテーション、ソフトウェア定義境界、およびネットワークサービスとセキュリティサービスを組み合わせたセキュア・アクセス・サービス・エッジ(SASE)モデルなど、これらの選択肢について検討しています。
設計上の考慮事項
アーキテクチャが実際に機能するかどうかは、4つの設計領域――アイデンティティ、ロギング、処理能力、および障害時の挙動――によって決まります。
アイデンティティ・アーキテクチャ
アイデンティティはあらゆるアクセス決定における最初の入力要素であるため、このリファレンスアーキテクチャでは、4種類のアイデンティティを第一級の対象として扱っています。
- 従業員向けユーザー。すべてのクラウドプロバイダーおよびSaaSアプリケーションと連携した、信頼性の高い単一のIDプロバイダーであり、フィッシング攻撃に耐性のある多要素認証(MFA)と条件付きアクセス機能を備えています。グループおよびロールのデータは単一のソースから取得されるべきであり、これにより環境間で権限設定に不整合が生じないようにします。
- デバイス。オンサイトユーザーおよびリモートユーザーについて、デバイスの識別情報と状態(管理状況、パッチレベル、ディスク暗号化、エンドポイント保護)を評価する必要があります。
- ワークロードとサービス。アプリケーションとサービスは、共有秘密鍵やネットワーク上の位置情報ではなく、ワークロードのIDと相互TLSを用いて相互に認証を行います。
- AIエージェントと自動化。各エージェントには固有のID、範囲限定の権限、および責任を負う担当者が割り当てられるため、その行動は個別に承認、記録、および取り消しを行うことができます。
見落としがちな設計上のポイントが2つあります。まず、セッションは有効期限が切れるまで信頼し続けるのではなく、デバイスが準拠状態から外れるなど、コンテキストが変化した際に再評価されるべきです。次に、IDプロバイダーが利用できない場合に備え、管理者向けの緊急アクセス権限を定義し、その利用に関しては厳格な管理とアラート機能を設ける必要があります。
ロギングとテレメトリ
ハイブリッドアーキテクチャにおけるログ記録は、データの転送先に関する制限を遵守しつつ、検知、調査、およびコンプライアンスの要件を満たすものでなければなりません。
- 収集すべき情報。すべての適用ポイントでは、ユーザー、デバイス、アプリケーションまたは宛先、ポリシーの決定内容、一致したルール、および関連するデータ分類をログに記録する必要があります。ローカルおよびクラウドでの適用から発生したイベントを結合できるように、共通の相関キー(ユーザーID、デバイスID、セッションID)を使用してください。
- 収集場所。各主要拠点のローカルコレクターが、まずイベントを保存し、その後、中央のSIEMに転送します。これにより、WANの障害時にもログが保持され、選択的な転送が可能になります。
- 転送すべき内容。検知に必要なメタデータを転送してください。DLPの証拠資料およびコンテンツの抜粋は、それらが収集された管轄区域に保管し、アクセスを権限のある調査担当者に限定してください。
- データ保持。データの種類および管轄区域ごとに、データ保持期間を規制要件に整合させ、その内容を文書化する。
- 完全性。ログが改ざんされるのを防ぎ、障害や攻撃の兆候となり得るデータの欠落を検知して警告を発します。
容量とサイズ選定
ローカルな処理ポイントは、ピーク時の復号済みトラフィック量に合わせて規模を設定する必要があります。これは、ハイブリッド展開においてパフォーマンス問題が生じる最も一般的な原因です。
- サイトごとのピークスループットと接続レートを測定し、復号されるトラフィックの割合を把握します。TLSの復号処理は、高い計算負荷を伴います。
- フェイルオーバーに備えた余裕を持たせてクラスタを構成し、1つのノードがダウンしても残りのノードに過負荷がかからないようにします。
- 暗号化トラフィックの増加、大容量ファイルの転送、および長時間続くAIセッションやコラボレーションセッションに対応します。
- 容量の追加方法を計画します。仮想アプライアンスやコンテナ化されたアプライアンスは、専用ハードウェアよりも迅速にスケールアップできます。
- クラウドのPoPについては、特に居住地によって利用可能なリージョンが制限される場合は、プロバイダーにリージョンの容量やフェイルオーバーの選択肢を確認してください。
レジリエンスと故障挙動
各依存関係が失敗した場合に何が起こるかを定義しない限り、リファレンスアーキテクチャは不完全である。
- ベンダーのクラウドが利用できない場合:Webおよびプライベートアプリケーションポリシーのローカルでの適用は、キャッシュされたポリシーに基づいて継続されます。一方、データ保護、remote browser isolation 、AIセキュリティ制御、CASB、データセキュリティ態勢管理など、クラウドから提供されるサービスについては、接続経路が復旧するまで適用されません。リモートユーザーは他の接続拠点にフェイルオーバーします。
- IDプロバイダーが利用できない場合:既存のセッションを継続するかどうか、およびローカルでの代替手段が存在するかどうかを定義してください。
- サイトのWANまたはインターネット接続が切断された場合でも、ローカルZTNAにより、オンプレミスのアプリケーションへのアクセスは引き続き利用可能です。
- ローカルゲートウェイの障害:クラスタのピアまたはクラウドのPoPが、同じポリシーに基づいて処理を引き継ぎます。
- フェイルオープンかフェイルクローズか:トラフィッククラスごとに決定し、その状態を運用部門が確認できるようにする。
テスト計画については、「ハイブリッド SSE の耐障害性:フェイルオーバーと復旧」を参照してください。
CISAおよびNISTへのマッピングの制御
各コンポーネントを既知のフレームワークにマッピングすることで、リファレンスアーキテクチャは監査人にとっては裏付け資料となり、実装担当者にとってはチェックリストとなります。
この表は、各コンポーネントを、CISAの「ゼロトラスト成熟度モデル」の柱およびNIST SP 800-53 Rev. 5における代表的な制御ファミリーに対応付けています。
| コンポーネント | CISA ZTMMの柱 | NIST SP 800-53 Rev. 5 に規定される代表的な制御措置 |
|---|---|---|
| IDプロバイダー | アイデンティティ | IA-2 識別および認証;IA-5 認証情報の管理;IA-9 サービスの識別および認証;AC-2 アカウント管理 |
| デバイスの状態 | デバイス | CM-6 の設定;SI-3 悪意のあるコードからの保護 |
| ポリシーエンジン | ガバナンス;自動化とオーケストレーション | AC-3 アクセス実施;AC-24 アクセス制御に関する決定;CM-2 ベースライン構成;CM-3 構成変更管理 |
| Secure web gateway | ネットワーク | SC-7 境界保護;AC-4 情報フローの強制;SI-3 悪意のあるコードからの保護;SI-4 システム監視 |
| TLSの検査と鍵 | ネットワーク;データ | SC-8 伝送の機密性および完全性;SC-12 暗号鍵の確立および管理;SC-13 暗号による保護 |
| ZTNA | ネットワーク;アプリケーションとワークロード | AC-17 リモートアクセス;AC-3 アクセス制御の徹底;AC-6 最小権限の原則 |
| セグメンテーション・ファイアウォール | ネットワーク | SC-7 境界保護;AC-4 情報フローの強制 |
| CASB | アプリケーションとワークロード;データ | AC-20 外部システムの利用;SA-9 外部システムによるサービス提供;AC-4 情報フローの徹底 |
| DLP | データ | AC-4 情報フローの強制;SI-4 システム監視 |
| DSPM | データ、可視化、および分析 | CM-12 情報の保管場所;RA-3 リスク評価;SC-28 保存中の情報の保護 |
| ログパイプラインとSIEM | 可視化と分析 | AU-2 イベントの記録;AU-6 監査記録の確認、分析、および報告;AU-9 監査情報の保護;SI-4 システムの監視 |
| レジリエンス設計 | ガバナンス | CP-2 緊急対応計画;CP-10 システムの復旧および再構築 |
このマッピングは出発点に過ぎません。各組織は、自組織のベースラインおよび規制の適用範囲に照らして、統制の適用可能性を確認する必要があります。
導入事例
この参照モデルは、ポリシーを再設計するのではなく、適用ポイントを変更することで、さまざまな業界に適応します。
例 1:地方銀行
本社およびデータセンターでは、ローカルのSWGおよびZTNAゲートウェイを運用しており、顧客データの復号および検査は、銀行が管理するインフラ上でのみ行われます。支店のトラフィックについては、ローカルのアプライアンスを使用するか、最寄りのデータセンターへのトンネルを利用します。リモート勤務のスタッフは、当該地域内に限定されたクラウドのPoP(接続拠点)を利用します。検査ログは国内に留まります。この構成により、EU機関向けのDORA ICTリスクおよびサードパーティ要件に対応しつつ、SaaS向けのクラウドCASBの利用も可能となります。
例 2:OT ネットワークを有するメーカー
セグメンテーション・ファイアウォールにより、プラントのOTネットワークと企業のITネットワークが分離されています。OTシステムは、ローカルのSWGを経由して、承認された更新先およびテレメトリ先へのみにアクセスします。エンジニアは、デバイスの状態チェックを行うローカルのZTNAを通じてプラントシステムにアクセスします。WANやクラウドサービスに障害が発生した場合でも、プラントへのアクセスと検査はローカルで継続されます。
例 3:公共部門の機関
機密扱いまたは外部ネットワークから切り離されたネットワークでは、外部サービスなしでの運用が明示的にサポートされているコンポーネントを使用する必要があります。非機密ネットワークでは、リモートワーカー向けに適切に承認されたクラウドサービスを利用することができます。ポリシーの同期、ID、更新、およびライセンスに関する依存関係を文書化し、環境固有の例外については変更管理の対象としてください。
例4:地域の医療システム
電子カルテおよび画像診断システムは、医療システムのデータセンターで稼働しています。病院内の臨床用ワークステーションはローカルゲートウェイを利用しているため、WebおよびSaaSトラフィックに含まれる患者データはオンプレミスで検査されます。医療機器は、外部へのアクセスが厳格に制限されたセグメント化されたゾーンに配置されています。 リモートで勤務する臨床医は、管理対象デバイスの要件を満たしたクラウドZTNAブローカーを介してEHRにアクセスし、保護対象の医療情報に対するDLPルールは両方の経路で同様に適用されるため、HIPAAセキュリティ規則の保護措置がサポートされています。
例 5:世界的な小売企業
店舗では、地域ハブへの小規模なブランチゲートウェイまたはトンネルを利用しており、POSシステムは、決済処理業者にのみアクセス可能なセグメント化されたカードホルダーデータ環境内に配置されています。本社および店舗スタッフのウェブ閲覧は、地域ハブまたはクラウドのPoP(接続拠点)で検査され、欧州からのトラフィックはEU域内に制限され、ログは当該地域内に保存されます。ローカルなセグメンテーションとアクセスルールはクラウドに依存しないため、WANがダウンしても店舗システムは稼働し続けます。これにより、PCI DSSのセグメンテーションおよびログ記録の要件が満たされます。
成熟度パスと検証
CISAの成熟度段階を活用して導入を段階的に進め、各段階が機能していることを確認するために反復可能なテストを実施する。
満期までの経過
組織が参照アーキテクチャを一度に完全に導入することはめったにありません。CISAのモデルでは、有用なロードマップとなる4つの段階(従来型、初期段階、高度段階、最適段階)が示されています。
| ステージ | ハイブリッドアーキテクチャの構成 |
|---|---|
| 伝統的な | オンプレミスのプロキシとクラウドツールを分離;プライベートアプリ用のVPN;個別のポリシー;サイロ化されたログ |
| 初期 | MFA対応の単一IDプロバイダー、リモートユーザー向けのクラウドSWG、主要アプリ向けの初のアプリケーション単位のアクセス制御 |
| Advanced | オンプレミスとクラウドの両方の適用を統括する単一のポリシーエンジン、オンプレミスユーザーを含むほとんどのプライベートアプリ向けのZTNA、統一されたDLP分類、一元化されたログ記録 |
| 最適 | 分析を活用した、リスクに応じた継続的なアクセス制御;DSPMに基づくデータポリシー;ドリフトの自動検出機能を備えた「ポリシー・アズ・コード」;検証済みのフェイルオーバー |
現在の段階と次の段階の間のギャップを、段階的な計画の基礎として活用する。
アーキテクチャの検証
アーキテクチャの良し悪しは、テストによって確認された動作によって決まるため、各フローと境界について、再現性のあるテストで検証してください。
- 既知の悪意のあるURL、テスト用マルウェアファイル、およびDLPテスト用ドキュメントをすべての適用ポイントに送信し、利用可能なクラウド経路を通じて同一の結果が得られることを確認します。その経路が遮断された場合に、クラウドで適用される制御機能の想定される動作を記録します。
- 各フローが正確に1回だけ復号されることを確認してください。
- オンプレミス、リモート、および管理対象外のデバイスからプライベートアプリケーションへのアクセスを試み、期待される結果を確認してください。
- 特定のサイトからのベンダークラウドへのアクセスを遮断し、ローカルでの適用が継続されていることを確認する。
- すべてのエンフォースメントポイントからのログがSIEMに確実に到達していること、およびレジデンシールールが遵守されていることを確認してください。
Skyhighがリファレンスアーキテクチャにどのように対応しているか
Skyhigh Hybrid SSE Meshは、コントロールプレーン(1つのコンソールと、ポリシーがコードとしてプッシュされるポリシーエンジン)、ローカルでの適用(ローカル TLS 検査およびローカル ZTNA を備えたオンプレミス型 SWG アプライアンス)、クラウドでの適用(クラウド型 SWG、CASB、ZTNA、および RBI)、ブラウザレベルの制御、および DSPM(Skyhigh Security)を網羅しています。
インスペクションキーの保護およびオンプレミスでのサンドボックス化については、Skyhighに確認の上、対応している連携機能、製品バージョン、および導入要件をご確認ください。選択したゲートウェイやサービスがHSMに対応しているとは、決して想定しないでください。
出典
- NIST.SP 800-207: ゼロトラスト・アーキテクチャ(2020年8月)。https://csrc.nist.gov/pubs/sp/800/207/final
- NIST.SP 800-215: 安全な企業ネットワーク環境の構築ガイド(2022年11月)。https://csrc.nist.gov/pubs/sp/800/215/final
- NIST NCCoE.SP 1800-35: ゼロトラスト・アーキテクチャの導入(2025年6月)。https://csrc.nist.gov/pubs/sp/1800/35/final
- NIST.SP 800-53 Rev. 5: 情報システムおよび組織のためのセキュリティおよびプライバシー管理措置。 https://csrc.nist.gov/pubs/sp/800/53/r5/upd1/final
- CISA.ゼロトラスト成熟度モデル、バージョン 2.0。 https://www.cisa.gov/zero-trust-maturity-model
- NSA. 「トランスポート層セキュリティ(TLS)検査に伴うリスクの管理」(2019年11月)。https://media.defense.gov/2019/Nov/18/2002212783/-1/-1/0/MANAGING%20RISK%20FROM%20TLS%20INSPECTION_20191106.PDF
- 欧州連合。規則(EU)2022/2554(デジタル・オペレーショナル・レジリエンス法)。 https://eur-lex.europa.eu/eli/reg/2022/2554/oj
- 米国保健社会福祉省(HHS)。HIPAAセキュリティ規則。 https://www.hhs.gov/hipaa/for-professionals/security/index.html
- PCIセキュリティ基準協議会。PCI DSS v4.0.1(ドキュメントライブラリ)。https://www.pcisecuritystandards.org/document_library/
- Skyhigh Security. 「Skyhigh Hybrid SSE Mesh による Symantec EdgeSecure Web Gateway の近代化」(2026年7月15日)。https://www.skyhighsecurity.com/industry-perspectives/modernizing-your-symantec-edge-secure-web-gateway-with-skyhigh-hybrid-sse-mesh.html
- Skyhigh Security. 「Skyhigh SSEプラットフォームにより、ハイブリッド環境の導入がさらに容易に」(2024年10月3日)。https://www.skyhighsecurity.com/cloud-security/adopting-hybrid-just-got-easier-with-skyhigh-sse-platform.html