COLUMN

2025.05.14 ｜ Writer：タクヤ、ハヤマ

NTT東日本でクラウドセキュリティ対策(CASB)を運用してみた

こんにちは！NTT東日本セキュリティエンジニアのタクヤです。

ゼロトラストセキュリティコラムも遂に10回目となりました。

過去のコラムをまだご覧になっていない方は、是非ご覧ください。

第1弾コラム：「NTT東日本で実際に導入しているゼロトラストセキュリティを徹底解説！」

第2弾コラム：「NTT東日本におけるゼロトラストセキュリティの設計と導入」

第3弾コラム：「NTT東日本でゼロトラストセキュリティの運用・監視をやってみた」

第4弾コラム：「NTT東日本でEntra ID・Intuneを活用してみた」

第5弾コラム：「NTT東日本でEntra ID・Intuneを活用してみた(モバイル編)」

第6弾コラム：「NTT東日本でMicrosoft Defender for Endpointを運用してみた」

第7弾コラム：「多要素認証だけで十分？NTT東日本のゼロトラスト認証・認可を徹底解説」

第8弾コラム：「NTT東日本でメールのセキュリティ監視・制御をやってみた」

第9弾コラム：「NTT東日本のゼロトラスト環境で端末を守ってみた」

今回も、製品ごとに運用時の困りごとを例に挙げながら、どういう運用を行っているのか、どのような点を工夫しているのかについてご紹介していきます。

本コラムでは、クラウドアプリケーションに関するセキュリティ対策について、NTT東日本が利用しているZscaler Internet Access(以降ZIAと表記)とMicrosoft Defender for Cloud Apps（以降MDAと表記）の2製品を利用したCloud Access Security Broker（以降CASBと表記）の運用にスポットを当ててご紹介いたします。

最後までお付き合いいただけますと幸いです。

ゼロトラストセキュリティを導入したいが、何からはじめたらよいかわからない、最適なソリューションがわからないなどNTT東日本のセキュリティエンジニアが無料でご相談をおうけいたします。ぜひ、お気軽にお問い合わせください。

1. クラウドセキュリティの重要性
2. CASB導入後に感じたメリットや運用課題: 2-1. クラウドアプリケーションの可視化、利用状況分析; 2-2. クラウドアプリごとの利用可否設定; 2-3. Intuneと連携した条件付きアクセスの利用
3. CASB導入時の注意点: 3-1. SSLインスペクションの利用; 3-2. MDAの利用開始前に必要な設定
4. CASB運用で苦労したこと: 4-1. 新たなクラウドアプリケーションへの対応; 4-2. MDAポリシー設定、運用設計
5.まとめ

1. クラウドセキュリティの重要性

本項ではクラウドセキュリティの重要性についてご説明します。

第6弾コラムでご紹介したように、近年では社会のデジタル化がさらに進み、より多くのことがオンラインやWebアプリケーションを介して行えるようになっています。

この背景には、サーバー環境の変化が挙げられます。

従来は各々が実機のサーバーを構築し、その中にアプリケーションを構築するオンプレミス型が主流でしたが、仮想化技術の高度化に伴い、自らサーバーなどのハードウェア持たず、外部から提供された環境に構築されたアプリケーションを利用するクラウド型の環境にシフトしています。

クラウドの利用が一般化する中で、利用者として意識すべき課題があります。

まず、1つ目は情報セキュリティに対する考え方です。

オンプレミス環境では、構築から、権限や機能、アクセスログ管理まで、自社基準に合わせた詳細な設定が可能です。

しかし、クラウド環境ではプロバイダーの情報セキュリティポリシーに従う必要があり、自社の情報セキュリティポリシーを完全に満たすことが難しい場合があります。

2つ目は、共同責任モデルの考え方です。

共同責任モデルは、クラウドサービスを利用する際のクラウド事業者とユーザーの責任の分担を示すものです。

クラウドサービスは契約に基づいて利用されるため、全ての責任がクラウド事業者にあると誤解されがちです。特にSaasアプリケーションでは、データやアプリケーションの利用・管理はユーザーの責任で、自社のデータは自社で守る意識が重要です。

出典：マイクロソフト社「クラウドにおける共同責任 - Microsoft Azure」

3つ目はシャドーITのリスクについてです。

クラウドアプリケーションは導入が簡易なため、管理者が意図しないサービスや機能が勝手に導入されてしまうという事例がよくあります。

これをシャドーITと呼び、それを発見し、対策を行うことが求められています。

では、これを放置するとどのような影響があるでしょうか。

例えば、外部ストレージ系のアプリケーションを知らずに利用した場合、社内の重要な経営情報や顧客情報が外部に流出するリスクがあります。

このような危険性のあるアプリケーションを不許可(アンサンクションアプリ)として管理しておく必要があります。

また、業務上許可されたアプリケーション(サンクションアプリ)であったとしても、そのアプリケーションにファイル共有機能や、会社用のアカウント以外でログインが可能であれば、機微情報が流出する恐れがあります。

このような事象を防ぐためにも、シャドーITへの対策は非常に重要です。

これらの課題を解決するためには、クラウドセキュリティの導入が不可欠です。NTT東日本では、ユーザーとクラウドプロバイダーの間に入り、クラウドアプリケーションの利用状況を可視化・制御するCASBを活用しています。これにより、シャドーITの発見や不審なユーザーアクティビティの検出などのセキュリティ対策を実施・運用しています。

2. CASB導入後に感じたメリットや運用課題

NTT東日本セキュリティエンジニアのハヤマです。

ここからは、CASBの運用中に得られた気づきや課題についてご説明します。

2-1. クラウドアプリケーションの可視化、利用状況分析

CASBに期待される最も重要な機能は、ユーザーが接続したクラウドアプリケーションの可視化と利用状況の分析です。ZIAとMDAの両方がこの機能を提供しますが、分析元のログやデータベースの違いにより、確認できる情報の範囲が異なります。

ZIAは、ユーザーとクラウドアプリケーションの間でプロキシとして動作してトラフィックを分析するため、どのクラウドアプリケーションでどのような動作を行ったか一つ一つのアクセスログで確認することができます。また、ユーザー情報に紐づく組織情報やユーザーグループ単位でアクセス先の調査を行うことも可能です。

一方、MDAは他のセキュリティ対策製品のアクセスログを元にトラフィックを分析し、統合的に利用状況を可視化します。

NTT東日本では、MDA上で特定のアクティビティを検知するポリシーを利用して利用状況の分析を行っています。

例えば、新規アプリケーションの大量データアップロードの検知や、Microsoftの認証基盤を利用するアプリケーション情報から既知のアプリケーションに偽装した悪意のあるアプリケーションの検知を実施しています。

2-2. クラウドアプリごとの利用可否設定

可視化したクラウドアプリケーションのアクセス状況をもとに、クラウドアプリの利用ポリシーに沿ったアクセス制御が必要です。

NTT東日本では端末のインターネットアクセスの制御はZIAを利用して一元的に管理しています。

ZIAは、従来のインターネットプロキシのように、端末と通信先サーバーの間に入り通信を制御します。従来型のプロキシは通信先のURLやIPアドレスに基づいてアクセス可否を決定していましたが、ZIAは接続先のクラウドアプリをURLから判別し、クラウドアプリケーション単位で制御を行います。

また、一部クラウドアプリケーション(M365,Google,Slackなど)では、接続先のテナント情報を事前に定義して制御に利用できます。

NTT東日本ではこれらの機能を利用し、全社員が利用する社内テナントへのアクセスは全員に許可し、個別の業務で利用するテナントは担当ユーザーのみに許可、それ以外の他社や個人契約のテナントはブロックする運用を行っています。

2-3. Intuneと連携した条件付きアクセスの利用

ゼロトラストセキュリティ環境を構築する際には、Intuneの条件付きアクセスを用いて、準拠デバイスや指定したIPアドレス以外からのアクセスを制限することが基本となります。

さらに仕様を詰めると、特定のアプリケーションやアクティビティを規制したいという要望が出てくることがあります。

NTT東日本でも、Intuneポリシーに準拠していないデバイスに対して、情報漏えいを防ぐため、特定のクラウドアプリケーションに対する利用規制が必要だという声が上がりました。

このような要望に対し、IntuneとMDAのポリシーを連携させた条件付きアクセスを利用し規制を試みました。Intune側で対象のアプリケーションや適用範囲を指定し、その制御をMDAに渡す設定を行うと、MDAは特定の動作を検知した際にその動作を監査し、ブロックします。

実際にポリシー非準拠の端末からOffice365アプリケーションでのファイルコピー、印刷、アップロード、ダウンロードの動作を規制し、よりセキュアな環境を構築しました。

3. CASB導入時の注意点

本項では、CASB導入時に分かった運用の注意点についてご説明します。

3-1. SSLインスペクションの利用

NTT東日本の社内環境にてZIAの利用を開始したのち、ユーザーから「これまで利用していたサイトにZIA経由だと接続できなくなった」といった申告がいくつか出るようになりました。

通信ログやユーザーのヒアリングから原因を探っていったところ、ZIAの通信内容の復号化機能(SSLインスペクション)に原因があることがわかりました。

ZIAは通信の分析・制御を行うため、SSLインスペクションによって暗号化されたトラフィックを復号化することが必須です。これが原因で、「クライアント証明書を利用して接続するサイト」「特定の証明書以外で通信できない(証明書のピン止め)サイト」といったサイトにはSSLインスペクションを有効化した状態で接続することができなくなっていました。

このようなサイトは、高い機密性や完全性を求められるセキュリティソフトや一部ファイル共有サイトに見られます。

SSLインスペクションの除外を行えば接続可能になりますが、以下の制限が発生します。

詳細なURLでの制御が利用できず、FQDN単位での制御のみとなる。
テナント制御・クラウドアプリケーションの操作制御ができない。

そのため、ZIA導入時や新しいクラウドアプリケーションの利用開始時には、SSLインスペクションが影響を及ぼさないかを検証し、影響がある場合は除外を検討する必要があります。

3-2. MDAの利用開始前に必要な設定

セキュリティ対策製品を利用開始する際には、監視や分析に必要なログを連携する必要があります。

一般的なセキュリティ対策製品の場合には、それ自体のライセンスとそれを導入する端末やアプリケーションがあれば利用できます。

しかし、CASBの場合は、Secure Web Gateway製品など他のセキュリティ対策製品と組み合わせて利用する必要がある点に注意が必要です。

MDAの場合は、自社のMicrosoftテナントを作成し、EntraIDやMicrosoft 365を利用可能にしておく必要があります。

また、クラウドアプリケーションの制限や条件付きアクセスを利用するには、事前にMDEやIntuneとの連携設定が必要です。

製品導入後にログが出ない、期待した制御ができないといった問題を避けるため、必要な環境やライセンス、設定を事前に確認し、漏れなく設定を行いましょう。

4. CASB運用で苦労したこと

本項ではCASBの運用を始めるうえで困ったこと、苦労したことについてご説明します。

4-1. 新たなクラウドアプリケーションへの対応

ZIAを運用していて気づいた点は、インターネットの最新のサービスや技術といったトレンドの把握が不可欠というものです。

全体的な設定方針としてクラウドアプリケーションのカテゴリごとに、許可・警告・ブロックという運用を行っています。

例えば、ファイル共有カテゴリではダウンロードのみを許可し、生成AIカテゴリでは警告を表示するなど、カテゴリごとに大まかな制御を行いながら、個々のアプリケーションについては許可・ブロックを設定しています。しかし、ZIAの運用中に新しいクラウドサービスがカテゴリ設定に沿わない動作をすることがありました。これは、新しいクラウドアプリケーションがZIAのデータベースに登録されておらず、制御対象として認識されないままトラフィックが通過していたためです。

特に生成AI分野のような成長が著しい分野では、新しいクラウドアプリケーションが多く登場し、未制御のまま利用されるリスクがあります。そのため、運用チームが情報収集を行い、独自にURLリストを作成して制御を行うことにしました。このように、全体的な設定を行っていても、サービス動向の情報収集や制御ポリシーの定期的な見直しといったプロアクティブな運用が重要です。