こんにちは、freee CSIRT専属engineerのEiji Sugiuraです。早いものでfreeeにjoinしてから、2年が経ちました。忘年会シーズンを前にしてγGTPが20を切ったので、これは酒を飲めと言う神様の思し召しだと感謝しています。
今回は、Zero Trust Networkを、既存のシステムにどうやって適用していくかを考えてみたいと思います。
この記事は freee Developers Advent Calendar 2019 の 5日目の記事です。
Zero Trust Networkは、Forrester Research社が提唱したシステムのセキュリティを考える上での概念です。「境界防御を超えて」といった修飾子が付いてたりしますね。
でも、Zero Trust Networkは境界防御を否定しているわけではなくて、環境の変化に合わせて境界防御だけでは辛いよね、多層防御でも触れたと思うけど、内部対策、出口対策忘れないでね！そして、endpointに気を配ろうね！といった話が主旨だと思っています。
さて、Zero Trust Networkでは、以下の3つがMUSTなのですが、
- All network flows MUST be authenticated before being processed
network flowは、認証してからでないと、処理をしてはならない - Authentication and encryption MUST be performed by the application-layer endpoints
endpointのapplicationの間で認証と暗号化を行わなければならない - All network flows MUST be enumerated so that access can be enforced by the system
システムによって制御されていることを確認できるように、network flowを列挙しなければならない
1.は、当たり前な感じがしますね。しかし、network flowごとにこれをやるのがミソですね。
2.は、境界防御との違いが大きい部分だと思います。
3.は、packet captureやflow logを収集しDPI*1などを駆使して、policyで制御していることを確認できる環境を仕立てなさいということだと理解しています。
危険なVPN
さて、Zero Trust Networkと旧来の境界防御の違いを際立たせるために、よく語られるのはVPNの否定です。
production systemへのアクセスは、firewallでIP制限をかけて社内のPCからに限定していて、オフィスに出勤しないと管理作業ができないのが原則だと思います。
でも、オフィスの外から緊急時の対応ができるように、例外が設けられるのもよくある話です。
例えば、社外のPCからのアクセスをVPN Gatewayで認証をかけてから許すことにした場合、以下の問題点があります。
- VPN認証のusername/passwordを手に入れれば、社内のPCと同じアクセス権限を入手できる = 認証はendpointで行うべきという原則に反する
- VPN接続すると、production systemへのアクセスが可能になってしまう = 攻撃の横展開が容易
これらは、fIrewallやVPN gatewayでfilteringを行なっただけでclientを信頼してしまい、Production system全体へのアクセスを許してしまったことからくる脆弱性です。
VPN改善案
手っ取り早くできる対処は、Production system側の管理サーバを切り離してVPNでアクセスできる先を絞る、Production systemのsegmentを分けるといった修正だと思います。
確かに、これだと社外からVPN接続を行なった結果、見えるのは管理サーバだけなのですが、管理サーバの他のportでlistenしているapplicationにアクセス可能だったり、別のVPN clientや社内のPCからのアクセスが見えたりしないでしょうか？
VPN Gatewayを追加することで複雑さは増しましたが、安全性が担保されたとはいえないのです。
理想
一方、Zero Trust Networkingが、勧めるのは以下のような解です。
- private CA*2が管理するprivate keyをTPM*3のようなユーザによる書き換えが不可能な領域に閉じ込めた上でPCを配布
endpointのデバイスを管理サーバで認証するための準備です。 - endpointであるPCと管理サーバで直接mTLS*4で接続
通信路を暗号化、PCは管理サーバの署名を検証し、管理サーバはPCの署名を検証します。
IPsec transport mode + EAP-TLSでも良いのですが、構築に手間がかかるので、mTLSの方が現実的だと思います。 - 管理サーバの利用状況をUBEA*5を用いて監視
アクセス元IPがいつもと異なる、ページのアクセスパターンがいつもと異なるなど、認証した後のユーザの行動について異常検知を行います。 - segment内の通信を、flow logとして記録
これは多層防御で言う内部対策です。横展開を監視するためにも、network内のflowを記録するのは必須です。 - segmentの境界でingressだけでなくegress filterを適切に定義
これは多層防御で言う出口対策です。
end-to-endでapplication-layerで認証や暗号化を行うことで、もしもVPN gatewayやfirewallでfilteringを忘れても大丈夫です。認証した結果アクセス可能なのは管理サーバ上のapplicationと、そこからアクセス可能なresourceだけのはずですから。
注意！filteringが要らないとは言っていません。
Zero Trust Networkでは、networkに存在しているだけではユーザやデバイスを信頼せず、sessionごとに互いを認証/暗号化を行なった上で、その後のnetwork内での動作を見張っておくことが重要だと考えているのです。
SSH access
ここからは、Production systemへのSSH accessについて考えてみます。
- 社内のPCがintranetに接続する際に、WiFiや802.1xによる認証を実施
- PCが踏み台サーバに接続に行くと、firewallでIP制限を実施
- 踏み台サーバのSSH serverでpublic key認証を実施
- TOTP*6で多要素認証を行う
この場合、endpoint間での認証は、SSH public keyとTOTPの2つだけです。 ただし、SSH public keyは、ファイルをコピーしてしまえば、簡単*7に使えてしまいます。TPMやhardware tokenに閉じ込めてしまいたいところです。 TOTPで多要素認証をするのは、とても良いことですが、盗難の危険がないわけではないですし、６桁の整数は数十秒間であれば何度でも利用できるので盗み見されるかもしれません。
とはいえ、社内には誰でも簡単に入室できるわけではないでしょうから、こうした弱点には目を向けないでいるのかもしれません。
まさか、WPA2-PSKのpassphraseを認証と勘違いしていたり、WiFi認証がMAC address filteringだけだったりしないですよね？
VPN経由でのSSH access
例外として、社外からのSSH accessを許す場合、オフィスのVPNを経由させるのは一般的なのではないかと思います。
- VPN接続する際に認証を実施
- PCが踏み台サーバに接続に行くと、firewallでIP制限を実施
- 踏み台サーバのSSH serverでpublic key認証を実施
- TOTPで多要素認証を行う
社内の時と異なるのは、WiFi/有線LANで行われていた認証が、VPN認証になった点ですが、
- VPN認証が、username/passwordのみだったりしないでしょうか？ そして、username/passwordをコピーすれば、別のPCからVPN接続ができたりしませんか？
- VPN接続しただけで、社内LANの他のPCにアクセスできたりしませんか？
社外に持ち出したPCや多要素認証に用いるsmart phoneが、盗まれる可能性もあります。 endpoint間で認証/暗号化を行う仕組みを用意しておかないと、リスクが高まるばかりです。
もしも、盗んだusername/passwordでVPN接続された場合、すぐに気づくことはできますか？ username/password以外の情報と照合していれば、気づけるかもしれません。
- IPを固定する。
- 利用可能な時間帯を限定する。
しかし、これらを絞れば簡単に不正に気づけるかというと、そうではないように思えます。
また、どこまでアクセスできたかを特定できますか？
- 社内LANを構成するL2SW、L3SW、Gatewayでpacket capture/flow logを蓄積
- real-timeで解析して異常検知
そして、気づいたとして、打つ手はありますか?
- VPN session teardown = VPN接続の強制切断、username/passwordが盗まれた場合は、これくらいしか打つ手がありません。他にも漏洩した情報はあるかもしれませんが、後の祭りですね。
- Device Lockdown = PCからの強制ログアウト、盗まれたPCをそのまま利用されている場合にだけ意味のある対策です。
- Device Remote wipe = PCのstorageの強制初期化、そもそも手元のstorageに機微な情報を置かない運用になっていれば必要ないかもしれません。
多層防御の考え方からいうと、優先度をつけて順に構築/運用していくことになりますが、もう少し簡略化できないものでしょうか。
より安全なSSH access
VPN認証は、endpoint間の認証ではなかったので、別の方法でendoint間の認証をsecureにしてみたいと思います。
- PCがnetworkに接続されたらCylanceにstatusをpush
- 踏み台サーバのSSH serverでpublic key認証
- TOTPで多要素認証
- SSH serverでCylance APIを用いて帯域外認証
- console logging = UEBAへのinput
- flow logging
この場合、接続元IPの制限を行う代わりにPC側で動作するCylancePROTECT/CylanceOPTICSからCylance SaaSにstatusをpushしてもらい、それを利用して帯域外認証を行います。 endpointにTPMが存在しないMacの場合でも、安全に認証を行うことができます。
この構成の利点は、以下の3点です。
- より安全な帯域外認証
SSH public keyやTOTPには盗難のリスクがありますが、第3者であるCylance SaaSの情報を改変するのは難しいため、より強固な認証だと言えます。 - いざという時の対処手段の確保
EDR*8であるCylanceOPTICSが稼働していることが保証されるので、Cylance SaaSから怪しいprocessをkillする、Device Lockdown、URL history取得、といった対処も行える。 - 自動的な対処
CylanceOPTICSのPackage Deployを利用すると対処手順をscriptに記述して自動化することが可能です。
Cylanceはあまり前面に押し出していないのですが、Cylance製品を管理するSaaS側にはCylance APIとしてRESTfulなAPIが用意されています。APIを作ってからWeb U/Iを用意するというだけあって、APIの方が機能が豊富です。利用しない手はないと思います。
Zero Trust Networkは、境界防御、多層防御の先にあるものなので、何か１つの製品を入れることで全てをカバーできることはありません。 様々な製品、OSSを組み合わせて、足りない部分は自分たちで仕組みを開発していくことが重要ですし、そこが楽しいところだと思っています。
一緒にCSIRTをエンジニアでドライブしていく仲間を求めています。
明日は、SREの知見を究めた後、人事労務フリーのエンジニアとして頑張っている橋本さんです！
*1:Deep Packet Inspection
*2:public CAのattack surfaceが広いこと、コストがかかること、APIが不足していて自動化が難しいことから、Zero Trust Networkでは、private CAの利用が推奨されています。
*3:Trust Platform Module
*4:mutual 相互認証 TLS
*5:User and Entity Behavior Analytics
*6:Time-based One-time Password、Google Authenticatorが代表的ですが、6桁の数字を入力するやつです。
*7:passphrase設定していれば、いくらか攻略にかかる時間が稼げます
*8:Event Detection and Response
