数年前のCloudflareのセキュリティアーキテクチャは、古典的な「城と堀」のVPNアーキテクチャでした。社員は企業内VPNを利用して、すべての社内アプリケーションやサーバーに接続し、業務を行っていました。VPNにログインする際には、Google AuthenticatorやAuthyのような認証アプリを使用して、タイムベースのワンタイムパスコード（TOTP）による二要素認証を強制適用しましたが、2層目の認証を持つ内部アプリケーションはごく少数でした。そのアーキテクチャは、外見は強そうですが、セキュリティモデルは弱いのです。私たちは最近、私たちが防いだフィッシング攻撃の仕組みについて詳しくまとめました。攻撃者が、TOTPなどの二要素認証方式で「保護」されているアプリケーションをどのようにフィッシングすることができるかを説明したものです。幸いなことに、私たちは既にTOTPを廃止し、ハードウェアセキュリティキーとCloudflare Accessに置き換えていました。このブログでは、その方法について詳しく説明します。
フィッシング問題の解決策は、 _FIDO2/WebAuthn_と呼ばれる多要素認証（MFA）プロトコルを介して行われます。現在、Cloudflareの社員は全員、FIDO2を安全な多要素認証として利用してログインし、当社独自のZero Trust製品を使って当社のシステムに対し認証を行っています。私たちの新しいアーキテクチャはフィッシングに強く、最小権限アクセス制御をより簡単に強制適用することができます。
セキュリティキーの用語と使用内容について
2018年、私たちはフィッシングに強いMFAに移行したいと考えました。evilginx2と、フィッシングのプッシュ型モバイル認証ツール、TOTPをめぐる成熟を目の当たりにしていたからです。ソーシャルエンジニアリングや認証情報の盗難攻撃に耐えるフィッシング耐性MFAは、FIDO標準を実装したセキュリティキーだけでした。FIDOベースのMFAは、FIDO2、WebAuthn、ハード（ウェア）キー、セキュリティキー、そして特にYubiKey（ハードウェアキーの有名なメーカーの名前）などの新しい用語を導入し、この記事を通して参照します。
WebAuthnはウェブ認証標準を指し、そのプロトコルの仕組みについてはCloudflareダッシュボードでのセキュリティキー対応をリリースした際に詳しく書いています。
CTAP1（U2F）およびCTAP2は、ソフトウェアまたはハードウェアデバイスがWebAuthnプロトコルを実行するプラットフォームとどのように相互作用するかを詳述する、クライアントから認証子へのプロトコルを指します。
FIDO2は、これら2つのプロトコルが認証に使用されているものをまとめたものです。区別は重要ではありませんが、命名規則が混乱のもととなる可能性があります。
最も重要なことは、これらのプロトコルや標準はすべて、フィッシングに強く、ハードウェアデバイスで実装可能なオープンな認証プロトコルを作成するために開発されたものであるということです。ソフトウェアでは、Face ID、Touch ID、Windowsアシスタントなどで実装されています。ハードウェアでは、USB、Lightning、NFCによる認証にYubiKeyなど別の物理デバイスを使用します。
FIDO2は、暗号的に安全なチャレンジ/レスポンスを実装しており、チャレンジプロトコルにはユーザーが認証する特定のWebサイトやドメインが組み込まれているため、フィッシングに強いという特徴があります。ログインするとき、セキュリティキーはexample.netでは、ユーザーがexample.comで正当にログインしようとするときとは異なるレスポンスを生成します。
Cloudflareでは、これまで複数の種類のセキュリティキーを社員に発行してきましたが、現在は2種類のFIPS検証済みセキュリティキーを全社員に発行しています。最初のキーはYubiKey 5 NanoまたはYubiKey 5C Nanoで、社員のノートPCのUSBスロットに常時入れておくことを想定しています。2つ目は、デスクトップでもモバイルでもNFCまたはUSB-Cで動作するYubiKey 5 NFCまたはYubiKey 5C NFCです。
2018年末には、全社イベントでセキュリティキーを配布しました。全社員にキーの登録、キーでの認証、デバイスに関する質問などを簡単なワークショップで行ってもらいました。プログラムは大成功でしたが、まだ粗削りで、WebAuthnで動作しないアプリケーションもありました。セキュリティキーの完全な強制適用はまだ準備ができておらず、問題を解決するための中間的なソリューションが必要だったのです。
始まり：Cloudflare Zero Trustによる選択的セキュリティキーの強制適用
私たちが保守を担当しているアプリケーションやサーバーは数千台あり、それらはVPNで保護されていました。これらのアプリケーションをZero Trustアクセスプロキシに移行し始めたのは、社員にセキュリティキー一式を発行したのと同じ時期でした。
Cloudflare Accessにより、社員はかつてVPNで保護されていたサイトへ安全にアクセスできるようになりました。各社内サービスでは、署名された認証情報を検証してユーザーを認証し、ユーザーが当社のIDプロバイダーにサインインしていることを確認しました。Cloudflare Accessは、セキュリティキーの展開に_必要でした。_セキュリティキーによる認証を必要とする最初のいくつかの社内アプリケーションを選択的に強制適用するためのツールを提供してくれたからです。
私たちはアプリケーションをZero Trust製品に導入する際にTerraformを使用しました。これは私たちが最初にセキュリティキーを強制適用したCloudflareのアクセスポリシーです。Cloudflare AccessがIDプロバイダーと統合する際にOAuth2を使用するように設定し、IDプロバイダーはOAuthフローの一部としてどのタイプの二段階認証が使用されたかをAccessに通知します。
この場合、swkは、セキュリティキーを所有していることを証明するものです。もし誰かがログインしてセキュリティキーを使わなかった場合、再度ログインし、プロンプトが表示されたらセキュリティキーを押すように指示する親切なエラーメッセージが表示されるでしょう。
選択的な強制適用は、セキュリティキーの展開の流れを瞬時に変えました。2020年7月29日に単一サービスでの強制適用を開始し、その後の2カ月間でセキュリティキーによる認証が大量に増えました。このステップは、従業員が新しい技術に慣れるために非常に重要でした。選択的強制の期間は、休暇中の人を考慮すると少なくとも1カ月は必要ですが、今にして思えば、それ以上長くする必要はないでしょう。
アプリケーションをZero Trust製品に移行し、VPNから切り離すことで、他にどのようなセキュリティ上の利点があったのでしょうか。レガシーアプリケーションやSAMLを実装していないアプリケーションでは、ロールベースのアクセス制御と最小特権の原則を強制するために、この移行が必要でした。VPNはネットワークトラフィックを認証しますが、すべてのアプリケーションは、そのネットワークトラフィックが誰のものであるかを知ることができません。私たちのアプリケーションは、複数のレベルの権限を強制するのに苦労し、それぞれが独自の認証スキームを再発明する必要がありました。
Cloudflare Accessを導入した際、RBACを強制適用するためにグループを作成し、各人が持つべき権限レベルをアプリケーションに伝えました。
ここでは、ACL-CFA-CFDATA-argo-config-admin-svcグループのメンバーだけがアクセスできるサイトを紹介します。ログイン時に社員が自分のセキュリティキーを使用したことを強制適用し、そのための複雑なOAuthやSAML連携は必要ありませんでした。これと同じパターンを使っている社内サイトが600以上あり、すべてでセキュリティキーを強制適用しています。
選択的実施の終わり：CloudflareがTOTPを完全中止した日
2021年2月、当社の従業員がソーシャルエンジニアリングの試みをセキュリティチームに報告するようになりました。当社のIT部門を名乗る人物から電話がかかってきており、警戒していたのです。そこで、社員がソーシャルエンジニアリング攻撃の犠牲にならないよう、すべての認証にセキュリティキーを使用することを義務付けることにしたのです。
WebAuthnを除く他のすべてのMFA（SMS、TOTPなど）を無効にした後、正式にFIDO2のみとなりました。ただし、「ソフトトークン」（TOTP）は、このグラフでは完全にゼロにはなっていません。これは、セキュリティキーを紛失したり、アカウントからロックアウトされた場合、別の方法でログインできる安全なオフライン回復プロセスを経る必要があるためです。このような事態に備え、従業員には複数のセキュリティキーを配布し、バックアップを取れるようにしておくことがベストプラクティスです。
全従業員がYubiKeyを使用してフィッシングに強いMFAを実現したところで、もう終わりでしょうか？では、SSHやHTTP以外のプロトコルはどうでしょうか？私たちは、IDとアクセス管理のための統一されたアプローチを求めていたので、セキュリティキーを他のプロトコルの任意のものにすることが次の検討事項でした。
SSHでセキュリティキーを使用する
SSH接続にセキュリティキーを導入することをサポートするために、私たちはCloudflare Tunnelをすべての本番環境インフラに配備しました。Cloudflare Tunnelはトンネルを通過するプロトコルに関係なくCloudflare Accessとシームレスに統合され、トンネルを実行するにはトンネルクライアントcloudflaredを必要とします。つまり、全てのインフラにcloudflaredバイナリをデプロイし、各マシンにトンネルを作成し、セキュリティキーが必要なCloudflare Accessポリシーを作成し、ssh接続にはCloudflare Accessを通してセキュリティキーが必要になるということです。
Zero Trustデベロッパー向けドキュメントには、素晴らしいチュートリアルが掲載されています。私たちの各サーバーは、トンネルを開始するために必要な設定ファイルを持っています。Systemdはcloudflaredを起動し、トンネルを開始する際にこの（または類似の）設定ファイルを使用します。
オペレーターが当社のインフラストラクチャにSSH接続する必要がある場合、ProxyCommand SSHディレクティブを使用してcloudflaredを呼び出し、Cloudflare Accessで認証し、Cloudflare経由でSSH接続を転送します。当社の社員のSSH設定には、このようなエントリーがあり、cloudflaredのヘルパーコマンドで生成することができます。
tunnel: 37b50fe2-a52a-5611-a9b1-ear382bd12a6
credentials-file: /root/.cloudflared/37b50fe2-a52a-5611-a9b1-ear382bd12a6.json
ingress:
- hostname: <identifier>.ssh.cloudflare.com
service: ssh://localhost:22
- service: http_status:404OpenSSHはバージョン8.2からFIDO2をサポートしています。しかし、すべてのアクセスリスト制御を一箇所で管理するアクセス制御への統一されたアプローチには、利点があることがわかりました。
Host *.ssh.cloudflare.com
ProxyCommand /usr/local/bin/cloudflared access ssh –hostname %h.ssh.cloudflare.com私たちが学んだこと、私たちの経験がどのようにお客様のお役に立てるか
この数ヶ月の間に、認証の未来はFIDO2とWebAuthnとなったことに疑問の余地はないでしょう。FIDOベースの認証で近代化を図ろうとする他の組織にとって、これらの学習が役立つことを願っています。
セキュリティキーの導入にご興味のあるお客様、またはCloudflareのZero Trust製品にご興味のあるお客様は、securitykeys@cloudflare.comまでご連絡ください。今回のフィッシングやソーシャルエンジニアリングによる攻撃には、私たちの予防的な取り組みが役に立ったようですが、次に起こることを防止するために、私たちのセキュリティチームはまだ成長を続けています。