ZTNの第一歩 ～内部の脅威をSSL復号化で可視化する～

• 
• 

ビジネス開発本部 第1応用技術部
セキュリティチーム
松尾 咲季

企業に求められる内部不正対策

ここ数年、内部不正インシデントをきっかけとして、弊社取り扱いのセキュリティ商材に関するご相談を頂く機会が増えています。
内部不正には、故意に行われるものとそうでないものがあります。前者は、社外秘情報を私的利用のため、悪意を持って流出させるなどの例が当てはまります。同様の行為が悪意なく行われることもあります。従業員が自宅でも業務ができるよう個人用クラウドストレージに社内情報をアップロードしたところ、設定ミスで流出してしまうなどの例がそれに当たります。
EY Japanは、グローバル情報セキュリティサーベイ にて、確認された攻撃実行者タイプの30%超が故意・または不注意な内部ユーザであると報告しています。また、IPAが毎年公開している情報セキュリティ10大脅威においても、内部不正が 3年連続 Top 10内にランクインしています。

これらの統計は、インシデント報告されたもののみがカウントされており、そもそもの不正に気づけないものを含むと、氷山の一角と考えた方が良いでしょう。
一般的に、内部不正は攻撃の兆候や被害が見えやすい外部からの攻撃に比べて、検知が困難です。多くの企業が取り入れている従来型の境界防御型戦略は、攻撃者が外におり、保護すべきリソースはネットワーク内部にあるとの考え方に基づき設計されてきました。そのため、不適切な行動を行うユーザが内側にいた場合、また昨今のクラウド利活用により保護対象の資産がSaaSと社内に混在している場合には、既存のポリシーでは不正に気づけない事態が往々にしてあります。
一例をあげますと、とある企業の従業員が自身の権限でアクセス可能な社内データを、Shadow IT経由で外部に持ち出す事案が発生しました。入口・出口対策として、ネットワークを保護するファイアウォールが存在しましたが、従業員からShadow ITへの通信は該当IPアドレスからのTCP 443のログが存在するのみであり、情報持ち出しの気づきを得られる証跡は記録されていませんでした。この様なケースで脆弱性となりがちなのは、従業員は悪さをしないだろうとの信頼に基づくポリシー設計です。

内部ユーザを信用せず、常に検証する

近年、セキュリティ戦略において最も支持を集めているゼロトラストは、信頼度に応じたポリシー設計に異を唱え、“Never Trust always verify”（信用せず、常に検証する）の原則の元、従来のネットワークアーキテクチャから信頼の概念を排除すべきと謳っています。それを補助するツールも様々なベンダから提供されていますが、単一のツールを導入すれば、内部不正対策も含めたセキュアなネットワークが一足飛びに実現できるものではありません。重要なのは、保護対象となる資産を内外の脅威から守るため、ツールの設計・運用に信頼排除の原則を組み込むことです。

これは必ずしも新たなツール・新たなテクノロジーを導入しなければ実践できないことではありません。入口・出口対策としてほとんどの企業に導入されているゲートウェイセキュリティ型のファイアウォールでも、内部発信のトラフィックをSSL復号化で可視化し、IT部が許可したSaaSアプリのみをL7ベースで許可し、IPアドレスではなくユーザやデバイス単位で必要最小限の通信のみを許可することで、内から外への攻撃可能面を狭めることができます。裏を返せばゲートウェイセキュリティの短所は、9割前後のWebトラフィックがSSLやTLSで暗号化されている昨今（Google 透明性レポートより）、SSLを紐解かなければ防御能力が低下してしまう点にあります。

ファイアウォールはSSL復号化で戦闘力が上がる

具体的にSSL復号化のある・なしで、ゲートウェイセキュリティ機能にどれ程の差異があるのでしょう。以下の図は市場評価の高いPalo Alto Networks社のNext Generation Firewall（NGFW）の主要機能を例に、効果の差異を示したものです。

アプリケーション識別（App-ID）やURLフィルタリング、アンチスパイウェアは、パケットのペイロード部分を分析できなくても、SSL/TLSネゴシエーション時のサーバ証明書情報やトラフィックの振る舞い検知、DNS問い合わせ先の分析などにより、一定の検知・識別能力を発揮します。しかし、アンチウィルスやファイル制御、WildFireサンドボックスやテナント制御は、暗号化されたペイロードが検査対象となるため、SSL/TLSで暗号化されたトラフィックに対して有効に機能しません。

SSL/TLSトラフィックを対象とした場合、NGFWで実現できる入口対策・出口対策を様々なポイントで多層的に強化するには、SSL復号化の実装が必要となります。

HTTPSの増加に伴い、SSLベースのWebサイト・アプリ経由での情報漏洩や、SSLサイトをリンク先とするフィッシングなど、暗号化通信に隠ぺいされた攻撃は年々増加しています。SSL復号化に頼らないオプションとしては、エンドポイントセキュリティでの対策が考えられますが、機能・コスト・運用面でゲートウェイ、エンドポイントそれぞれにメリット・デメリットがありますので、どちらか一方を採用するというより、併用してセキュリティの統合運用を目指すべきでしょう。近い将来、攻撃の約7割超が何らかの種類の暗号化を用いて行われるとの予測もあり、多層防御の観点からもゲートウェイセキュリティ機能をフル活用すべく、SSL復号化を標準的に実装することをお奨めします。

ポイントを押さえれば復号化のハードルは高くない

これだけのメリットがありながら、GatewayでSSL復号化を実装しているユーザは未だ多くはないと感じます。その背景には、復号化にCPU性能を要するためサイジングが難しい、クライアントへの証明書の配布・管理が厄介である、など設計・運用上の懸念点が多い点が一因として挙げられます。ただ最近は、サイジングの考慮が不要なマネージド型のSASEを活用するオプションに加え、ハードウェア型のNGFWもSSL復号化の性能が大幅に向上しており、従来よりもサイジングやコストのハードルは低くなっています。その他の懸念点についても検証・導入実績から得られた知見やNGFW自体の機能向上もあり、ある程度の攻略法が見えています。詳細は割愛しますが、下記図に主な懸念点と対策／回避策の例を示します。

SSL復号化でできる内部不正対策

ここからは、SSL復号化を設定することにより実現できる情報漏洩対策の具体例を幾つか紹介します。

ファイル持ち出し対策

• 課題

個人や企業契約にて、ファイル共有サービスを提供する様々なSaaSアプリケーションが利用可能になりましたが、HTTPSでアップロードされた場合にGatewayで証跡すら取ることができない点を解決したいとのご要望がありました。最終的には、社内ポリシーで許可するアップロードサイト、特定のユーザのみ許可するサイトをポリシーで制御し、それ以外のサイトは禁止することが要件です。

• 対策

Palo Alto Networks社のNGFWでは、SSL Decryption Forward Proxy、User-ID連携、File Blocking機能を活用することで要件を満たせます。以下は特定のユーザ／ユーザグループのみBoxへのアップロードを許可し、それ以外のアップロードは禁止するポリシーの設定例です。何れの場合も証跡を取ることが可能です。

上記設定で通信確認した際のログです。いつ・誰が・どのようなファイルを・何のアプリで・どこにアップロードしたのかの情報が取得できている点にご注目ください。
Source User: Suzuki は File Blocking Profileの Actionを alert（ログ採取）とした上部のルールに適用され、Boxへのアップロードが許可されています。
Source User: Yamada は File Blocking Profile の Actionをblockとしたルールに該当し、Boxへのアップロードが拒否されています。

• 注意点

サイトのアップロード先が、AWSのS3など汎用的なストレージである場合、アップロード制御をURLなどのホワイトリストベースで実施するのは困難な場合があります。まずは可視化からスタートし、社外への通信要件・アップロード要件を把握するためのトライアル期間を設けた上で制御の検討に入ることをお奨めします。

テナント制御

• 課題

MS365など組織公認のSaaSサービスであっても、自社組織以外のテナントへファイルを持ち出されてしまえば、情報漏洩のリスクとなります。Microsoftをはじめ、主要なSaaSベンダはHTTPヘッダに挿入されたテナント情報を確認し、明示的に指定されたテナントに対してのみアクセストークンを付与する仕組みをサポートしています。
NGFWは、復号化後のHTTPパケットにテナント情報を挿入することが可能です。ここでは自社組織のMS365テナントのみ許可する原則の元、特定のユーザのみ業務上必要なパートナー顧客のテナントへのアクセス権を、例外的に追加したいとのご要望に応える例を示します。

• 対策

Palo Alto Networks社のNGFWでは、SSL Decryption Forward Proxy、User-ID連携、URL Filtering (HTTP Header Insertion) 機能を活用し、テナント制御を実現できます。

NGFW URL Filtering機能の HTTP Header Insertion設定で、アクセスを許可するMicrosoftのテナント情報と、テナント制御のログを採取するAzure ADのディレクトリを指定します。ユーザが事前定義されたログインドメインで認証を受ける際、指定されたテナント情報をHTTPヘッダに挿入し、Microsoft側で対象以外のテナントへのアクセス要求をブロックする仕様となります。

ログには挿入された Headerが記録されます。

禁止されたテナントへのログインを試みたユーザには、Microsoftよりアクセスがブロックされたことを示すメッセージが表示されます。

• 注意点

テナント制御は HTTPヘッダの挿入により実現しますが、実装はSaaSベンダにより異なります。NGFWが事前定義にてサポートするベンダは Dropbox, Google G Suite, MS365, YouTube （PAN-OS 10.1⁺）です。

尚、プロファイル上に定義可能なヘッダ値にはNGFW側で character length: 512の制限があり、十数社のテナントを許可する必要がある場合には制約がかかる可能性があります。

おわりに

リモートワークの増加で、ますます制御が困難となっている内部不正対策に対して、ゲートウェイセキュリティを “Never Trust always verify”（信用せず、常に検証する）の原則に基づいてアップデートする必要性、そのために利用可能なテクノロジーについて述べました。併せてゲートウェイにSSL復号化を実装するメリットや、内部情報漏洩対策としての活用例を幾つかご紹介しました。

今回はオンプレミスの Next Generation Firewallを例に挙げましたが、パブリック・クラウドに実装する Secure Web Gateway やマネージド型の SASEにおいても、従業員のトラフィックを含めて可視化と制御の対象にすべき点は変わりません。

執筆者プロフィール

松尾 咲季
ネットワンシステムズ株式会社 ビジネス開発本部 第1応用技術部 セキュリティチーム所属
オンプレミス、クラウドのセキュリティ商材を評価、検証し、提案や導入支援を行う業務に従事
・CISSP
・AWS Speciality - Security
・Cisco CCNP Security
・Palo Alto Networks PCNSE

• 
• 

ナレッジセンターを検索する