BeyondCorp? ゼロトラスト? VPNを超えていけ!

TL;DR

  • BeyondCorpはゼロトラストの実装の一つ。ゼロトラストは超乱暴に言えばポストVPN
  • 社内も信用出来ないとして社外と同じ方式でNWを組む
  • HTTPSによる暗号化と次世代認証基盤を使ったCAACによるアクセスコントロール
  • FWによる境界からIDによる境界へのパラダイムシフト

はじめに

ニコ生でゼロトラストについて話したので、こちらは解説記事となります。

www.youtube.com

動画で利用したスライドはこちら。SpeakerDeck

コロナウイルスによりまさかのパンデミックによるBCPが発動されている今日この頃。皆様はいかがお過ごしでしょうか?

出社してる人、自宅からリモートワークをしている人、色々だと思います。

リモートワークと聞いてまず最初に思い浮かぶのがVPNですね。VPNで社内ネットワークに接続して社内と同様にアクセスできる。リモート接続の鉄板ですね。

ですが、VPNにもそれなりに問題があり、最近はゼロトラストセキュリティという言葉も聞くようになりました。あるいはGoogleVPNを辞めてBeyondCorpを採用する事で、VPN詰まりも無く在宅勤務できる仕組みがあるとか。

私も初めて「Google VPN辞めたってよ」的な話を聞いた時には「????」という感じだったので、今回はゼロトラストセキュリティあるいはBeyondCorpに関して説明していこうと思います。

BeyondCorp << ゼロトラスト

f:id:pascal256:20200301190527p:plain

現時点での私の理解では、という前置きは付いてしまいますがBeyondCorpとゼロトラストは言っている事は同じです。

もう少し言い換えるとGoogleでのゼロトラストの実践がBeyondCorpです。このあたりはDevOpsの実践の一つがSREなのと同じですね。

歴史的にゼロトラストが流行る前からGoogleが対応していた名残だと思います。なのでGCPでBeyondCorpを見かけたらゼロトラストの事と思えば良いですし、GCPな方はゼロトラストをBeyondCorpと理解すればだいたいあってます。

ゼロトラストセキュリティ

f:id:pascal256:20200301190619p:plain f:id:pascal256:20200301190635p:plain

Zero Trust SecurityとZero Trust Networkの差は前者の方が少し範囲が広く後者は企業ネットワーク基盤の話をしている認識です。とはいえ大きな差は無いでしょう。

スライドにも書いている通り、トラディショナルな企業ネットワークは「信頼されたネットワーク」の存在を前提に成立しています。

たとえば、DCの内と外はFirewallでがっちりと守ります。しかし、その中はどうですか? DC内の通信にFirewallやIDS/IPSはどこまで適用されるでしょうか?

DC内は安全という前提でVPNでDC内に繋ぐ事で社内システムにアクセスができます。多くの社内システムは外部にさらされることを想定していないので認証が弱かったりDDOS攻撃のような基本的な対策もされていません。

このようにネットワークを内と外で分けるのがトラディショナルなネットワークの基本的な考え方です。しかし、これは現代では十分ではありません。

ゼロデイ攻撃、巧妙なウイルス、ターゲッティング攻撃、悪意のある利用者と様々な理由により境界となるFWを超えた攻撃がなされるのは常識です。

f:id:pascal256:20200301191242p:plain

そのため、内部のアクセスであっても常に疑い認証をしっかりとする事が重要です。結果として「社内と社外を区別せず常に如何なる場所からのアクセスであっても検証する」という同じコントロールが実現できます。

リモート接続のセキュリティ3要素

リモート接続には様々な方式が存在しています。TELENT, VNC, SSH, そしてVPNです。

かつてはSSHの利用も多かったとは思いますが、今はVPNが主流だと思います。VPNにはDC間を繋ぐSite To Ste(S2S)VPNとClient to Site(C2S)がありますが、リモート接続に使うのはC2Sですね。

一言でVPNと言ってもその特性や実装はプロトコルや製品で大きく異なりますが、企業向けのリモート接続でC2SのVPNに要求される機能は以下でしょう。

f:id:pascal256:20200302025554p:plain

Authentication/認証

VPNクライアントを立ち上げると社内アカウントのIDとパスワードを入力します。場合によってはMFAで生体認証やスマートカードを使うケースもあります。いずれにしても利用者のIdentityはVPNにとっても非常に重要な要素です。

Device Trust/機器認証

これは厳密には認証の一部ですが分かりやすいのであえて切り出しました。BYODとしてどんなPCからもリモート接続可能というケースもありますが会社から提供されたPCのみから使えるケースも多いと思います。これを実現するためにSSL証明書など端末にインストールする方式をとります。。これによって安全なPCかどうかを判定するわけです。

Encryption/暗号化

VPNの最も基本的な機能と言っても良いでしょう。Virtual Private Networkというだけあってあらゆる通信パケットをラッピングして暗号化するのがVPNの本業です。これによりインターネットを経由したアクセスであってもセキュアな通信が実現できます。

セキュアな通信としてはインターネットVPN、広域IP網を利用したIP-VPN、そしてVPNじゃないけど専用線があり良く比較に上がると思いますが「セキュリティ観点では」実質これらは同等です。

IP-VPN専用線を使うのは単に通信品質の保証やレイテンシなどパフォーマンスのためです。セキュリティ強度としてはSSLを利用したインターネットVPNで問題なく、そこは製品選定の時には誤解しないように注意が必要です。価格は圧倒的に違いますしw

リモートアクセスとしてのVPNは上記の要素によりセキュアな通信を実現しています。逆に言えば上記の3つを満たせばVPNでなくてもセキュアな分けです。

VPNの問題点

つづいてVPNの問題点について考えていきましょう。大きく以下の3つがあります。

f:id:pascal256:20200302025735p:plain

キャパシティ/パフォーマンス

まずはキャパシティです。VPNは基本的に社内のDCに接続しに行くのでVPN GWが必要になります。

これはリモート専用の設備なのでリモート利用者向けにキャパシティプランを組み立てますが、そこがネックです。1万人の会社で1万人がリモートアクセスするケースはまれでしょう。せいぜい1000人分のキャパプラをします。

これが災害時には5000人とかに跳ね上がり混雑を引き起こします。BCPを考慮した予算確保は現実的には結構大変なので現実的な課題です。

またパフォーマンス観点でもVPNは暗号化された通信なので原理的に遅いというのもありますが、そもそもDCを経由した通信を実現する技術です。DC内にアクセスする場合なら良いのですがSaaSの場合は不必要な経路を通ることになります。地理分散してない場合は海外からの接続では大きくレイテンシーが劣化してしまう懸念もあります。

特にVDIを利用している場合は通信がTCPに固定されてしまったりVDI側の最適化方法が上手く使えない場合もあるので通信が劣化しがちです。

このようにVPNにはいくつかのオーバーヘッドがあり、キャパシティプランも個別に必要なものとなっています。

適切な制御の難しさ

VPNは基本的に社内に中継ポイントを置いてそこからアクセスする方式なので追加のACLを入れない限り社内と同様のアクセスポリシーが適用されてしまいます。

つまり良くも悪くも「リモートからもVPNを繋げば社内と同じ完全に同じことができる」ということです。

例えば「リモートからメールなどのシステムにはアクセスしたいけど、顧客管理システムにはアクセスさせたくない」というケースがあったとします。

この場合、VPNで振られるIPで顧客管理システムの手前にあるFirewallで止めるしかありません。さらに「基本的には禁止なんだけどAさんだけは顧客管理システムにアクセスさせたい」という要件もあり得ます。この場合は、AさんのIPに対してさらに例外的な設定をする必要があります。

VDIを利用しているとより複雑で、社内と社外で同じVDIを使うとリモート接続かどうかがそもそも判定できません。そのため社外用のVDIを別に用意するケースも考えられます。

また、これらの制御はあくまでACLなので、通常のアクセス権を管理しているフロー(アカウント管理とか権限管理とか)とは異なります。異なる作業を組み合わせるためオペレーションや業務フローが煩雑になりがちです。

これらの課題は既存のDCの設計次第ですし、実現できなくはないのですがコントロールのコストが高すぎるためあまり細かな権限管理は行われていないのが実際だと思います。

一貫したセキュリティポリシーの適用が困難

f:id:pascal256:20200301192216p:plain

VPNの最大の問題として「VPNに繋がないと社内セキュリティが適用できない」という事が言えます。

これは簡単に言えば社内ProxyやPaloAltoなどの次世代FW、あるいはEDRやデバイス制御の適用外になるという事です。VPNを使わない場合は通常のインターネット経路の接続になってしまい、トラフィックを管理することが出来ませんし、DC内にあるセキュリティツールからリモート管理することもできません。

このようにオンプレミスのセキュリティと相性が極めて悪いのです。そのためリモート接続用のPCのセキュリティが下がってしまいます。

これに対応するためにリモート接続用のPC向けに別の製品を入れるなどでセキュリティを担保する事もありますが、これもコントロールがケースバイケースになる事で複雑化してしまい望ましくはありません。

他にも接続先が社内システムなのかSaaSなのかで適用するセキュリティ製品が異なる場合もあります。たとえば、社内システムにはVPN必須だけど社内でも利用しているSaaSVPN無しでも行けてしまうとか適切に設定をしていないと脆弱性になりますし、社内のセキュリティルールが複雑化して矛盾が発生してしまう元です。

このようにVPNでは「オフィス内とリモート接続」「DC内とSaaS」といった複雑な環境に対して一貫したセキュリティモデルを適用することが困難です。

ゼロトラストによるセキュアな通信

f:id:pascal256:20200302104357p:plain

それではゼロトラストでどのようにセキュアな通信を実現するかを見ていきたいと思います。

ゼロトラストは既に述べているとおりFWではなく認証システムを基盤としたセキュリティモデルです。そのため、認証という点では問題なく実施できます。

例えばAzureADを使った場合であればセキュリティキーやスマホの認証アプリ、あるいは指紋認証などのFIDO対応のMFAを適用しパスワードレスな運用もできます。デバイス認証に関してもIntuneなどの組み合わせて実現できます。

大きく異なるのは通信の暗号化です。VPNでは全ての通信を暗号化していました。これは当時としては必要だったのですが現在はWebアプリケーション化も進んでおりHTTPSも当然利用されています。VDIのようなアプリケーションの場合でもSSL/TLSには対応してます。その為、暗号化自体は個々のアプリケーション側に任せるというのがゼロトラストの考え方です。

時代が、暗号化を常識とするようになったので、結果としてリモートアクセス基盤としてはVPNのように「全てを暗号化する」という責務から解放されたわけです。

ゼロトラストの企業ネットワーク

f:id:pascal256:20200302105332p:plain

ゼロトラストにおける企業ネットワーきうの形を見ていきましょう。

「トラディショナルな企業ネットワーク」と異なり信頼できるネットワークは無くなり、認証基盤により各ユーザ/各アプリ毎にチェックを行います。

ネットワークとFWがセキュリティ境界だったトラディショナルなモデルから、IDを境界にセキュリティを担保するようになりました。

後述するCAACにより社内なのか社外なのかというのはあくまで多要素の一つとして利用はされますが、根本的にはどこからアクセスするかとかどこにアクセスするかは関係なくなります。

これにより社内も自宅もDCもSaaSも関係なく同一のシステムでアクセスコントロールが掛けれるようになります。

コンテキスト認識アクセスコントロール

f:id:pascal256:20200302124331p:plain f:id:pascal256:20200302124405p:plain 引用: [Japan Tech summit 2017] SEC 010

Context-Aware Access Control (CAAC) ではコンテキスト----すなわち「誰が」「どこから」「どのデバイスで」「どのアプリに」アクセスしようとしているかを判定して、それらのリスクを計算した上でアクセス可否を判定します。

これにより同一の人が自宅からアクセスするときと社内からアクセスする時で認証の制御を分けることが出来ます。VPNが苦手だったロケーションによる複雑な制御がゼロトラストでは容易になります。

このようなリスクを動的に計算する仕組みはルールベースの認証だけではなく、機械学習などにより「いつもと違うアクセスに対して追加の認証を要求する」と言ったリスクベース認証も可能です。

たとえば、出張等で海外に行っているときや不正アクセスが多くリスクが高いと判定された時は追加の認証が自動で入ったりする、などが例としてイメージしやすいかと思います。従来のRBAC + Network ACLではこのような柔軟な制御は苦手なのでCAACになって実現しやすくなったことの一つです。

ゼロトラストによるVPNの問題点の解決

f:id:pascal256:20200302125004p:plain f:id:pascal256:20200302125025p:plain

ゼロトラストでは。VPNと違いリモート専用の仕組みという分けではなく社内も社外も同じ仕組みです。その為社外向けの特別なキャパシティプランは不要です。つまり社内向けに1万人の設計をしたら1万人分のリモートアクセスのキャパシティは持っているわけです。

また、CAACを基本とした次世代認証基盤により社内も自宅もDCもSaaSも一貫した仕組みでアクセスコントロールが出来ます。もう、リモートの場合は特定のIPセグメントを振って、それに対してACLを入れて。。。と言ったことは不要です。

アクセスコントロールだけではなくエンドポイントセキュリティに対しても一貫したコントロールが可能になります。

CAACの機能として「どこから」を判定する必要があるため基本的にこの認証基盤はインターネットからアクセスされる場所にあります。つまり、社外からの門番として存在していたVPN-GWの代わりに認証基盤自体がGWになってるわけです。

そのため「VPNに繋ぐ」というクッション無しにダイレクトにSaaSへの認証やアクセスを制御できます。これによりEDRやEgress Filterでもクラウドベースのセキュリティ製品を利用しやすくなります。これらを使いVPNを経由せずインターネットから直接端末を保護することで、社内にいる時と同様に社外のセキュリティをコントロールできます。

このようなデバイスレベルでのセキュリティ、End to Endのセキュリティがゼロトラストの特徴です。

半面、認証基盤に要求されことは多くAzureADやCloudIdentityあるいは各種セキュリティ大手ベンダーやベンチャーが出しているIDaaSを使うのが無難でしょう。

ゼロトラストの課題と展望

セキュリティと言えば「めんどくさい」「生産性が下がる」というのがイメージだと思いますが、ゼロトラストは珍しく生産性とセキュリティの両方を向上させる概念です。

ゼロトラストで社内と社外を区別しないというのは結構大きくて、これは「スタバのようなカフェ」と「会社の社内ネットワーク」を同じセキュリティレベルとしている事です。逆に言えば会社のネットワークセキュリティを普通のWiFiレベルまで下げれます。

ただ、万能ではなく課題というか注意点もあります。

たとえば、ネットワーク的には同一とはいえ社内と社外では監視カメラや入退室のセキュリティーカードといった物理セキュリティが異なるので通常は区分する必要があることも多いでしょう。

また、WebアプリケーションならHTTPSやIDaaS対応は容易ですが、C/Sベースのレガシーな仕組みだと難しい部分もあります。

特にサーバとの通信が平文の謎プロトコルだとクライアント側に結構手を加えないと実現は難しいでしょう。新規に作るものやHTTPS/SAMLに対応したデスクトップアプリなら問題はありませんが。

そういったこともあって、まだまだVPNを利用される事は多いと思います。しかしSaaSが増えてきた現在ではゼロトラストの観点でセキュリティを組んでいくしかありません。基本はWebアプリケーションにしてC/S型のデスクトップだけVDIやアプリケーションストリーミングを利用して対応する必要があるかと思います。

レガシー対応としては、既存のWebアプリケーションをゼロトラストに対応させるGoogleの「BeyondCorp Remote Access」やMicrosoftの「Azure Application Proxy」が有効です。C/SにはCitrixの 「アプリケーション仮想化」などが使えるかと思います。

まとめ

今回はBeyondCorpを皮切りにゼロトラストに関して説明してみました。改めてまとめるとポイントは下記です。

  • BeyondCorpはゼロトラストの実装の一つ。ゼロトラストは超乱暴に言えばポストVPN
  • 社内も信用出来ないとして社外と同じ方式でNWを組む
  • HTTPSによる暗号化と次世代認証基盤を使ったCAACによるアクセスコントロール
  • FWによる境界からIDによる境界へのパラダイムシフト

それにしても震災のタイミングではじめてDRという考えが「現実的なシナリオとして」定着しましたが、今回のパンデミックBCP観点でのリモートワークも現実的な検討になるんでしょうか?

災害は喜ぶことでは決してないですが、雨降って地固まるというか塞翁が馬というか少しでも困難を糧にできれば良いなぁ、と思います。

あと、余談ですがAzureADはADのマネージドクラウド版ではなく、まったく別の認証基盤でむしろADFSに認証機能が内蔵されて進化したものととらえた方が良いので名前に惑わされないように注意しましょう。

それでは、Happy Hacking!

参考