CDIが構築/運用するセキュアなリモートワーク環境 - 折れまくるHWトークンの屍を超えて -

はじめに

技術部の石垣です。

弊社ではCOVID-19の影響を鑑み2月中旬から部署ごとではありますが、リモートワークを開始し2月25日には全社でのリモートワーク対応(BCP対応)となりました。

さてCOVID-19をきっかけとしてお客様から、セキュアなリモートワーク環境について相談を受けることがありましたので、弊社におけるPKIを利用したVPN利用環境およびVPN運用遍歴について少々紹介したと思います。

弊社社員数は50-100名に収まる程度です。

昨今ゼロトラストが話題に上がりVPNいらないんじゃない?となったりしますが、以下の理由でVPNを利用しています。

• 社内システムをパブリックネットワークに公開した場合、DDoS等の可用性リスクも考慮しなければならない。
• DDoS攻撃を受けても公開サービス(攻撃者に知られている公開サービス)のみに局所化したい=一般公開していない別系の社内向け公開システム+社内システムは業務継続可能としたい

なお弊社ではお客様にフォレンジック、診断サービスを行っていることもあり、ハードウェア、ネットワーク機器、OS、middlewareにおける設定上の不備や、運用上の不備、脆弱性等を利用して侵入する過程を見ている＋社内メンバーも攻撃能力を持った集団なので、一発即死にならないようにどう対策をすべきかを日々実践しています。

大手ネットワークベンダーや、老舗ソフトェアベンダーであっても安心ではありません。自分が運用者だったら発狂レベルの脆弱性がさらっと公開されています。

最近だと以下があります。

https://jp.tenable.com/blog/cve-2019-11510-proof-of-concept-available-for-arbitrary-file-disclosure-in-pulse-connect-secure

https://unit42.paloaltonetworks.jp/exploits-in-the-wild-for-citrix-adc-and-citrix-gateway-directory-traversal-vulnerability-cve-2019-19781/

https://www.fortinet.com/blog/business-and-technology/fortios-ssl-vulnerability

※診断環境で実際に遭遇するため社内エンジニアがこういった脆弱性を利用し侵入します。

概要と遍歴

さて社内ではフォレンジック・オフェンスのエンジニアだけではなくセールス、バックオフィス等も含め様々なITリテラシーの利用者が、Windows, Linux, Mac等様々な環境からVPNを利用する必要がありなかなかサポートが大変です。

入社当時(7-8年前)は既に社内ではHWトークン¹を利用可能なPKIベースのOpenVPNやPacketiX VPN等を利用していました。

またHWトークンは過去にGemalto K30, ePass2003等を利用していました。

なぜHWトークン(スマートカード等)を利用するのかについてですが、様々な侵害レポートでも報告されている通りセキュリティ侵害の主パターンは認証情報の窃取/漏洩/簡単なパスワード/使い回し等であり弊社でもペネトレーションテストでも同様の傾向が見られます。

元CIA CISO Robert Bigman（ロバート・ビッグマン）氏の講演²でも

2つ目は、二要素認証やスマートカードを組み合わせるなどして認証を強化することだ。コストの面で従業員全員に適用するのは難しい場合でも、少なくとも管理者権限を持つユーザーについては、強固な認証を採用すべきだとした。

管理者権限を持つクレデンシャルやチケットを入手するといった一連の作業を素早く行い、これらがサイバーセキュリティリスクの87％を占めている。逆に、こうした動きに対処できれば、かなりの部分を保護できることになる

と述べられています。

またDoD Cyber部隊もスマートカードベースの認証を利用しており以下のURLには利用にかかるドキュメントが公開されています。

https://public.cyber.mil/pki-pke/end-users/getting-started/

画面右上側のLogin with CACが記載されておりスマートカードベース認証は上記で紹介した組織においても利用されています。

過去の課題

Gemalto K30, ePass2003を利用する場合

現在はもしかしたら記載する制約は無いかもしれませんが数年前はGemaltoのHWトークンにおける課題として

• Linux等でlibidprimepkcs11.0.soが安定して動かない
• Linux向けは毎回buildが大変

ePassでは

• 同一のバージョンのソフトウェア+設定であっても、トークン内部のファームバージョン?/chipが異なると動かない

等ハードウェア周りでいろいろと苦労させられることがありました。社内ではほかにSafenet等もトークンあったため選択としてはありましたが、Gemaltoに買収されなかなか製品を見なったため結局利用せずおわってしまいました。

Gemalto K30

利用しているうちに、折れ曲がってしまった無残な姿

ePass 2003

同じソフトウェア、設定を利用しても、動かない等いろいろ苦しい経験をさせられたePass2003

OpenVPNを利用する場合

• クライアントソフトウェアのインストールが必要
• 通信速度が思ったよりも出ない
• Wi-FiからLTEに切り替わる際接続が切れる

PacketiX VPNを利用する場合

• スマートカード認証を利用する場合クライアントソフトウェアのインストールが必要
• Windowsしかスマートカード認証を利用できなく対応プロトコルも限定的

OpenVPN/PacketiXクライアントソフトウェアのインストール・アップデートはなかなか大変です。

またスマートカード認証では基本PKCS11を利用しますが、クライアントソフトウェアのPKCS11対応や、どのプロトコル(L2TP Over IPSecとか)で利用できるかも重要でありPacketiXではWindows限定となるため、弊社CHOが頑張ってクライアント側でTOTP実装をPacketixクライアント側で作り社内のTOTP対応Radiusと連動を試みましたが、接続規定時間or通信上限になると突然途切れる動作(ReKeyで再度TOTP認証が必要)であり運用上の課題となることが予見できたため利用は諦めました。

現在の環境

VPNクライアントはWindows, macOSに組み込まれているVPN(IKEv2)を利用しています。またVPNクライアントで利用するHWトークンは前回のBlog投稿に記載のとおりYubikey 5 NFC/Yubikey 4を利用しており、FIPS-201 PIV³規格(いわゆるスマートカード認証)を利用したクライアント認証のためのデバイス⁴として利用しています。

Yubikey 4/5 NFCは全体的にメカニカルな部品が露出していないので、耐水性、防塵性、耐久性、費用対効果⁵が一番高いと社内で評価している製品です。なにより多数のユーザが利用しており様々なフィードバックが製品に反映されていることが最終的に各OS環境において安定した動作につながっているとみられ素晴らしい製品だと思います。

とはいえ利用方法によっては、折れてしまうこともあります。筆者出張先のホテルでYubikey刺しっぱなしのままラップトップを落として破損した経験有ります。社内では筆者含め2名破壊

なお弊社ではHSMを利用した社内認証局から証明書発行を行っています。

VPNサーバはIKEv2+RFC5755のAttribute Certificateの仕組みを利用してユーザの所属先ごとに接続可能な通信先が切り替わる仕組みとなっています。またサーバは約2-3年ほど運用しており非常に安定しています。

昨今話題になっているNATテーブル枯渇に関してはIKEv2 Split-Tunnelingを利用し社内向けトラフィックと社外向けトラフィックを分離しているため、VPNが遅い等の問い合わせはありません。なおIKEv2 Windows10 実装は、サーバからのルーティング情報を無視するのでPowershellでVPN設定を行いSplit-Tunneling設定を行っています。

 VPNのパフォーマンスに関してはINTEL AES NIを利用し暗号処理をしているため、現状のVPNクライアント数でCPUは一桁%の負荷であり、回線が先にボトルネックになります。※弊社ではいくつかの出入り口を持っているので必要に応じて接続分散させることで対応は可能

VPN接続後においても社内では同一のYubikeyを利用しシンクライアント、Kerberos、SSH、Web、SMTP等においてもWindows, Mac, Linuxの複数の環境をサポートしつつクライアント認証⁶を実現しており社内内部,およびネットワーク出入り口で多層防御対策を行っています。

またネットワークレイヤーもVPNによるACL制御(L3)だけではなくL3-L4レイヤーでサービスごとにセグメンテーション分離しACL設定を行っており全体のライン数は数千〜万オーダです。実際にどうやって運用管理をしているかはこちらに記載がありますので興味があればご覧ください。

今後の課題

• TNC対応 ※リンク先資料に記載されたPEP/PDPのキーワードで気づく方がいるかもしれませんが、筆者はゼロトラストがTNCの概念を取り込んだと思っています。
• TPM2を利用したいわゆるSecure boot/Trusted Boot + FDE + AIKの対応 ※社内のいくつかのプロジェクトでは既にSecure boot/Trusted Bood, FDE, AIKの動作は検証済みであり技術的な評価はほぼ完了。

まとめ

弊社におけるVPNサービスでのセキュリティ確保およびPKI利用についてご紹介しました。

VPN限らずエンタープライズ環境(内部/外部ネットワーク/アプリケーション)においてオンラインで確かな認証/認可はセキュリティにおける永遠の課題であると思います。

本稿記載内容および参考リンク等を紹介することでセキュリティ対策検討の一助になれば幸いです。

余談 

RFC5755 Attribute Certificateはとっても便利な仕組みです。ある認証局から発行された証明書に対して、何らかの要素を書き加えて署名を行うことができます。

たとえばA CAから発行されたkuma.pem 証明書があったとして、そのkuma.pem証明書にattribute としてgroup: CDI Zero Project とタグみたいなものを付与し、Z Attiribute CAで署名を行って、kuma-zero.pem を生成します。弊社ではYubikeyを利用していますのでkuma.pemに対応する秘密鍵が入ったUSBトークンを利用してVPNサーバに接続するとVPNサーバでZ Attiribute CAおよびA CAをtrustしていれば、kuma.pem -> kuma-zero.pem -> CDI Zero Projectとattributeが見つかります。

サーバとクライアント間はattribute: CDI Zero Projectに定義されたIP Addressのみだけ通信可能なVPN接続できあがる仕組みです。

x509証明書=認証、Attribute Certificate=認可と考えていただくとわかりやすいかと思います。運用面から見ても本人確認を行うプロセス(トークン向け電子証明書)と、利用を許可するプロセス(VPN利用向け電子証明書)が分離でき内部統制や柔軟な運用対応が可能となります。

これを応用するとマイナンバーカードを利用して、認証向け公開鍵(利用者証明書用電子証明書)を取り出して、Z Attiribute CAでattibuteを付与するとVPNでスマートカード認証ができたりもします。

オンラインで公開鍵を受け渡す場合には、署名用電子証明書で利用者証明書用電子証明書に署名を行い、受け取り側で署名検証すると安全な本人確認ができたりします。

ただしマイナンバーカード利用や証明書有効性(CRL,OCSP)確認は以下の申請、回線接続・利用代金が必要です。

https://www.j-lis.go.jp/jpki/minkan/procedure1_2.html

https://www.j-lis.go.jp/jpki/minkan/procedure1_2_2.html

OCSPの提供は無理にしても、CRLぐらいはCDN経由で公開いただくともっと利活用が進む思います。

マイナンバーカードを持ち歩くのは嫌ということを聞きますが、せっかくのリモートワークなので自宅だと家から持ち出す必要なく1000円と安く調達でき、かつ本人確認済み証明書まで発行しているのでセキュアにVPN接続するにはとても便利なデバイスです。自治体だとLGPKI、政府職員だとGPKIで発行されたスマートカードを保有されていると思いますので、入退室等で見せるだけでなくそれらのカードを利用することでセキュアな認証や改ざん対策等の電子署名(SMIME/PDF等)もできます。

なおマイナンバーカード内の利用者証明書用電子証明書データ(プライバシー)を気にされる方は以下の仕様書が参考になるとおもいます。

https://www.j-lis.go.jp/data/open/cnt/3/2187/1/13_profile_genkou.pdf

このRFC5755の応用としてNSAではサプライチェーンリスクでの活用を行う動きがあります。

次回の記事ではIoT環境における攻撃を想定し上記内容を含んだセキュリティ確保対策についてご紹介できればと思います。