はじめに

特に目新しい話ではないですが、年の暮れのアドベントカレンダーということで、今年、お仕事で、何度か同じお話をすることがあったトピックです。日本においては、プロキシ信仰が強い（もしくは、昔からの構成を変更したくない）といった話をよく聞くので、そもそも、なぜ時代は DNSレイヤセキュリティなのか、その良さを改めて整理してみました。

本題

私がまだ学生だった頃、squid(オープンソースのWeb proxyサーバー)を使って、Webプロキシを構築・運用していました。当時は、まだ大学のインターネット回線が数Mbpsで、プロキシサーバーでキャッシュを有効にし、帯域を有効活用していたわけです。更に、セキュリティの観点で、プロキシサーバーが代理応答することによりクライアントPCを脅威から保護、加えて、学生が Web上の掲示板などに危険な投稿をしてしまった際に、プロキシ上にHTTPのアクセスログを残す、という用途でもプロキシを利用していました。

主なWebプロキシの利用目的は、現在も変わっていません。が、しかし、インターネットをとりまく環境は、大きく変わりました。

現在は、かつてほど、企業向けWebプロキシサーバーが活躍できる時代では、無くなってきています。Webプロキシに関連する変化について、いくつか解説したいと思います。

1. ブロードバンド化とCDNの発展
2. HTTPS 通信の増大
3. SaaS の発展 - ローカルブレイクアウト
4. SaaS の発展 - コンテンツフィルタリング

ブロードバンド化とCDNの発展

言うまでもなく、この20年でインターネットの帯域は爆発的に増えました。アナログ 32kbpsだった家庭の回線も今は、数Gbpsのサービスが登場しています。また、CDN(Contents Delivery Network)も発展し、多くCDNプロバイダにより、動画などサービスとしてコンテンツがキャッシュされているものも増えています。

このため、現在ではWebプロキシのキャッシュ機能自体をそもそも使わないという企業も、多くみられます。

HTTPS 通信の増大

巧妙化するサーバーセキュリティリスクからユーザーを守るために、インターネット上を流れるトラフィックにおいても、暗号化された通信が当たり前の時代になっています。2014年 Google は HTTPSのサイトをSEO(Search Engine Optimization)のランキングに利用することを発表していますし、2018年7月の Chromeブラウザリリースから、HTTPのSSL暗号化されていないサイトについて、保護されていない通信であると、警告を出すようになっています。これらを受けて、多くのウェブサイトは、2019年現在、既に https に対応しています。

これが、Webプロキシのロギングの機能に関係してきます。多くの日本企業は、どのユーザー(クライアントのIPアドレス)が、どのサイト(宛先URL)の、どのコンテンツ(サブディレクトリとファイル)へ、どうアクセス(HTTPのメソッド)したか？についてロギングのためにWebプロキシサーバーを利用しています。

HTTPS で暗号化された通信は、WebプロキシでSSLをdecryptしないと、URLまでは分かりません。すなわち、これまで平文で流れていた際に確認できた、(サブディレクトリ含む)どのURLへ、どういうメソッド（GET/POSTなど）で、という内容が、暗号化されていると、ログに残せないのです。

もちろんWebプロキシサーバーに証明書をインポートし、SSL decrypt するなど、いくつかの手段を提供する機器もあり、内容を確認することも可能ですが、一般に、この作業は機器に掛かる負荷が高く、パフォーマンス要件を満たすためには、より高価な機器を導入する必要があります。

SaaS の発展 - ローカルブレイクアウト

今や、世の中はクラウドファーストの時代になり、O365, G-Suite, Box, Salesforce, Webex など、多くのクラウドサービス、SaaSを利用し、業務をクラウドに合わせて、デジタル時代に合った事業展開の速度を維持する企業も多いことでしょう。これらのSaaSアプリケーションの多くはインターネット経由でのアクセスを基本としており、企業の業務トラフィックは、社内のサーバーだけでなく、インターネットを経由するものが増えることになります。これにより、多くのSD-WANの文脈で語られる通り、これまでのネットワークアーキテクチャのあり方を変える必要があります。

これまでのように、本社拠点もしくはDCにインターネットの出口を一箇所用意し、プロキシサーバを配置して管理を行う、というやり方に限界が出てきました。支店などの地方拠点からのSaaSへの通信は、拠点から直接インターネットへ接続するというローカルブレイクアウトが、より効率的な通信の方法として、まさに今、多くの企業が取り組んでいます。

では、Webプロキシはどうすればいいのでしょうか？これまでは、本社拠点・DCにWebプロキシを配置すれば済むデザインがほとんどでしたが、企業の業務トラフィックが、インターネット経由で、拠点やモバイルデバイスから直接接続されるので、すべての拠点に、DC同様、物理的なプロキシを配置するとなると、コスト的なインパクトは大きいですし、リモートワークなど実現が難しいケースもあります。

SaaS の発展 - コンテンツフィルタリング

Webプロキシサーバーの機能で、もう一つ大きなものとしてコンテンツフィルタリングの機能があります。企業としては、ユーザーを守るためのものではありますが、SaaSが発展する現代は、新たなアプリケーションが日々出てくるため、プロキシで定義された古いポリシーが原因で、顧客から送られてきた box.com のURLへのアクセスできなくて無駄な手間が増えたとか、開発環境から Github, dockerhub や Python Package Index(PIP)へアクセスできなくて検証が進まずに困ったとか経験があるのではないでしょうか？　私も個人的にユーザーの立場としては、Webプロキシというのは、あまり良い思い出がないです。

しかし、IT管理者の立場からは、脅威からユーザーを守る必要があり、また、どうしてもオンプレミスのプロキシサーバーだと、シグネチャのアップデートやアプリケーションの認識にタイムラグが生じることも多いでしょう。またユーザーから、聞いたこともないSaaSサービスへのアクセスを依頼されても、そのサービスが信頼に足るかどうか確認するのも大変だろうとは思います。

もう一点、SaaSアプリケーションの中には、Webプロキシ利用を推奨しないものがあります。そういったアプリケーションのために Webプロキシを管理する管理者は、プロキシを通す宛先・通さない宛先を管理するためにPAC(Proxy Auto Configuration)ファイルの管理に日々追われることになります。

では、どうすればいいのか？

上記の通り、時代の変化とともに、Webプロキシの活躍できる場が少なくなり、運用の課題が多くなっています。課題をまとめると下記のとおりです。

• キャッシュ機能
  • ブロードバンド化/CDNの発展により利用価値が下がっている
• 代理応答とログ機能
  • HTTPSについては、細かいURL・Methodまでは残せないケースも多い
• 配置の難しさ
  • モバイルデバイスや、小規模拠点など、現代では、全ての企業トラフィックをカバーできない
  • すべてをカバーしようとすればするほど、コストが高くなる
• コンテンツフィルタリング
  • 新しいSaaSが日々増えている状況へ 対応の難しさ

こういった背景を抱える現代においては、既存ソリューションの見方を変える必要があります。有効な手段として、2つの選択肢を、ご提案します。

• 効果が少ない Webプロキシを使わずに "DNSレイヤ" でセキュリティを担保する
• モバイルデバイスや小規模拠点でも利用しやすい "クラウドプロキシ" ソリューションを使う

DNSレイヤでのセキュリティ(ドメインレピュテーション)

一つは、Webプロキシ をもはや辞めてしまおうという選択肢です。これは、言い換えると、(見えるかどうかわからない)ログの機能にお金をかけるのをやめて、守るべきセキュリティに集中するという選択です。これをDNSレイヤでのセキュリティ（ドメインレピュテーション)で実現します。

DNS レイヤでのドメインレピュテーションは、ドメインのレベルで怪しいかどうかを判断し、怪しい宛先については、通信をブロックします。DGA(Domain Generation Algorithm) により自動生成されたドメインや、マルウェア・ランサムウェアが利用する、怪しい・危険なドメインを通信が始まるDNS問い合わせの際に、セキュリティインテリジェンスのデータベースと照合します。もちろんコンテンツフィルタも可能です。

これには、いくつかの利点があります。

• まず、導入の容易さです。基本的に、クライアントのDNSの設定をセキュアなDNSサーバーへ向けるだけ設定は終了です。いくつかやり方はありますが、ネットワークの構成を大きく変えることなく実現が可能です。また、モバイルデバイス等への対応も容易です。
• また、パフォーマンスについて。プロキシ型と違い、データ通信トラフィックを中継しないので、トラフィックが集中することによるパフォーマンス低下などは起こりません。
• さらには、より高いセキュリティレベルでの保護を実現できるという点も大きいです。DNSのレイヤでの保護になるため、80/443 ポート以外の通信も保護可能です。万一、マルウェアに感染し、その後のC2Cの通信で別のポートを利用したとしても、DNSのレベルでブロックが可能です。セキュリティインテリジェンスを持つ企業は、日々、怪しい・危険なドメインのリストをアップデートしています。

例えば、2017年に発生したインシデント WannaCry の際には、Cisco Umbrella は、最初のサンプル発見から、数時間のうちに、関連ドメインリストを Malware カテゴリにアップデートし、Umbrella 利用者は被害の拡大から保護されています。https://www.cisco.com/c/dam/global/ja_jp/solutions/collateral/enterprise-networks/ransomware-defense/wannacry-timeline.pdf

私も個人的に利用していますが、怪しいサイトへのアクセスも ユーザー側が何もしなくてもDNSのレベルで守られているという安心感は計り知れません。また、もちろん、ログに関しても、宛先ホストへのDNS問い合わせのアクティビティログは取得可能です。

クラウドプロキシ

もう一つは、クラウドプロキシを使うという選択肢です。オンプレミスにあるWebプロキシをそのままクラウドに持っていくという考えです。これにより、小さな拠点や、リモートオフィスなど機器を置きたくない拠点からローカルブレイクアウトしている場合も保護することが可能になります。

プロキシのアーキテクチャでしかできないこともあります。通信を代理応答（=Proxy)するため通信自体の中身を見ることができるという点です。要件によっては、プロキシを利用したほうがいいケースもあるでしょう。その場合も、現代の利用シーンを想定すると、如何にリモート拠点やモバイルデバイスからの通信を保護するかという点が重要になります。それを解決するにはクラウドプロキシを使うという選択肢も一つだと思います。

クラウドプロキシの利点は下記の通りです

• クラウド上のプロキシを利用するため、場所やデバイスに限らず利用することが可能
• トラフィックの中身を見た制御など、より詳細な制御が可能

ただ、SSLや、パフォーマンスなどの課題は、残ります。また、より高いセキュリティのためにDNSセキュリティと合わせて利用するケースもあります。

今後は?

今回、イマドキの企業内のWebプロキシのあり方を中心に書きました。
この分野は、クラウドの発展や利用ケースに応じて時代と共に移り変わっています。クラウドサービスの中に個人情報や社外秘の情報などポリシーに合わないデータを配置していないかを確認する DLP(Data Loss prevention)の機能を実現するCASB(Cloud Access Service Broker)のソリューションが、合わせて求められる時代です。これらを 上記のクラウド・セキュリティと如何に合わせて提供できるかというのが、企業の課題になりつつあります。

こういった最近のトレンドに合わせたセキュリティソリューションとして、シスコは Umbrella という DNS セキュリティ/クラウドセキュリティのソリューションをリリースしています。

• Cisco Umbrella は最近のリリースでクラウドプロキシ に対応しています。
• Cisco Umbrella では、AppDiscovery の機能により、シャドーITの可視化に加え、信頼できるアプリケーションかどうか、アプリ運営会社の信用情報等をあわせて確認できます。
• Cisco Umbrella は、Chromebook や Apple iOS などのモバイルデバイスにも対応しています。
• Cisco Umbrella では CASB 機能の統合も今後予定されています。