幾年前，Cloudflare 的網路安全架構是一個經典的「城堡加護城河」VPN 架構。我們的員工使用我們的企業 VPN 連線至所有內部應用程式和伺服器，來完成自己的工作。我們使用限時一次性密碼 (TOTP) 強制執行了雙因素驗證，因此，在登入 VPN 時使用了驗證器應用程式（如 Google Authenticator 或 Authy），但只有幾個內部應用程式擁有第二層驗證。該架構的外觀貌似很強，但網路安全模型卻很弱。最近，我們詳細介紹了我們所防止的網路釣魚攻擊的機制，其中逐步說明了攻擊者如何對使用第二因素驗證方法（如 TOTP）「保護」的應用程式進行網路釣魚。幸運的是，我們早就棄用了 TOTP，並用硬體安全金鑰和 Cloudflare Access 取而代之。本部落格會詳細地介紹我們的做法。
網路釣魚問題可透過多重要素驗證 (MFA) 通訊協定（名為 FIDO2/WebAuthn）來解決。如今，所有 Cloudflare 員工都使用 FIDO2 作為安全的多重要素登入，並使用我們自己的 Zero Trust 產品進行系統驗證。我們的新架構不僅可以防止網路釣魚攻擊，還可讓我們更輕鬆地強制執行最低權限存取控制。
安全金鑰術語和我們使用的安全金鑰簡介
2018 年，我們就知道我們想要遷移至防網路釣魚攻擊的 MFA。我們看到了 evilginx2、網路釣魚推送型行動驗證器的成熟度，以及 TOTP。唯一能夠抵禦社交工程和認證竊取攻擊的防網路釣魚攻擊的 MFA 就是實作 FIDO 標準的安全金鑰。FIDO 型 MFA 引入了新的術語，例如，FIDO2、WebAuthn、硬（件）秘鑰、安全金鑰，還有具體的 YubiKey（一個知名硬件秘鑰製造商的名稱），本貼文會參考這些術語。
WebAuthn 指的是 Web 驗證標準，我們在發佈對 Cloudflare 儀表板中安全金鑰的支援時，詳細地描述了這一通訊協定的工作方式。
CTAP1(U2F) 和 CTAP2 是指用戶端至驗證器通訊協定，其詳細描述了軟體或硬體裝置如何與執行 WebAuthn 通訊協定的平台互動。
FIDO2 是用於驗證的這兩個通訊協定的集合。差異並不重要，但命名方法可能會令人困惑。
最重要的是要知道，制定上述所有通訊協定和標準都是為了建立開放式驗證通訊協定，不僅可以防止網路釣魚攻擊，還可以使用硬體裝置來實作。在軟體中，使用面部 ID、Touch ID、Windows Assistant 等來實作。在硬體中，將 YubiKey 或其他獨立的實體裝置與 USB、Lightning 或 NFC 搭配使用來進行驗證。
FIDO2 可防止網路釣魚攻擊，因為它實作密碼編譯安全的查問/回應，並且查問通訊協定整合了使用者進行驗證的特定網站或網域。與使用者以合法方式嘗試在 example.com 上登入相比，在 example.net 上登入後，安全金鑰會產生不同的回應。
多年來，Cloudflare 已向員工發出多種類型的安全金鑰，但我們目前向所有員工發出了兩種不同的 FIPS 驗證的安全金鑰。第一種金鑰是 YubiKey 5 Nano 或 YubiKey 5C Nano，會始終留在員工筆記型電腦的 USB 插槽中。第二種是 YubiKey 5 NFC 或 YubiKey 5C NFC，可透過 NFC 或 USB-C 在桌上型電腦和行動裝置上使用。
2018 年下半年，我們在一次全公司活動上分發了安全金鑰。我們要求所有員工註冊金鑰、使用它們進行驗證，並在簡短的工作坊期間詢問有關裝置的問題。該計畫取得了巨大的成功，但仍有一些粗糙的邊緣和應用程式無法使用 WebAuthn。我們尚未做好完全強制執行安全金鑰的準備，因此，需要一些折衷解決方案來解決這些問題。
開始：使用 Cloudflare Zero Trust 選擇性強制執行安全金鑰
我們負責維護的應用程式和伺服器有數千個，由我們的 VPN 提供保護。我們開始將所有這些應用程式遷移至 Zero Trust 存取代理，與此同時，向員工發出了一組安全金鑰。
藉助 Cloudflare Access，我們的員工可以安全地存取曾由 VPN 提供保護的網站。每個內部服務都會驗證已簽名的認證來驗證使用者，並確保使用者已使用我們的識別提供者登入。Cloudflare Access 對於我們推出安全金鑰_是必要項_，因為它提供了一個工具，我們才能選擇性強制執行需要使用安全金鑰進行驗證的前幾個內部應用程式。
我們在將應用程式登入到 Zero Trust 產品時使用了 Terraform，這就是 Cloudflare Access 原則，我們會先在其中強制執行安全金鑰。我們設定了 Cloudflare Access 以在與識別提供者整合時使用 OAuth2，識別提供者會通知 Access 在 OAuth 流程中使用哪種類型的第二因素。
在我們的案例中，swk 是持有安全金鑰的證明。如果有人登入，但未使用其安全金鑰，則會向他們顯示一則說明性錯誤訊息，指示他們重新登入，並在系統提示時按下安全金鑰。
選擇性強制執行立即變更了我們推出安全金鑰的軌道。2020 年 7 月 29 日，我們開始對單一服務強制執行，在接下來的兩個月內，使用安全金鑰的驗證大幅增加。為了讓我們的員工有機會熟悉新技術，這一步至關重要。考慮到休假的人，應設定至少一個月的選擇性強制執行時間，但事後看來，這麼長的時間足夠了。
透過移動我們的應用程式來使用 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 通訊協定怎麼樣呢？我們想要採用一種統一的方法進行身分識別和存取管理，因此我們下一步要考量的便是，在任意其他通訊協定中使用安全金鑰。
在 SSH 中使用安全金鑰
為了支援在 SSH 連線中使用安全金鑰，我們為所有生產基礎架構部署了 Cloudflare Tunnel。Cloudflare Tunnel 可與 Cloudflare Access 無縫整合，無論採用哪種通訊協定來傳輸通道，執行通道都需要通道用戶端 Cloudflare 化。這表示，我們可以將 Cloudflare 化二進位部署至所有的基礎架構，並為每台機器建立一個通道，在必須使用安全金鑰的位置建立 Cloudflare Access 原則，然後 ssh 連線就會開始透過 Cloudflare Access 要求提供安全金鑰。
實際上，這些步驟並沒有聽起來那麼令人生畏，並且 Zero Trust 開發人員文件中有一個非常精彩的教學課程來教您如何做。我們的每一台伺服器都有一個啟動通道所需的設定檔。Systemd 會叫用 cloudflared，而 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:404值得注意的是，OpenSSH 自 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 連絡我們。雖然我們很高興，我們的預防措施幫助我們抵禦了最新一輪的網路釣魚和社交工程攻擊，但我們的網路安全團隊仍在不斷發展，以協助防止以後出現的任何攻擊。