要約

  • 「Setting up 2FA with Passkey」はRIPE NCCの二段階認証サポート文書内の節見出しであり、台湾の機関ではない。この見出しが指すのは、RIPE NCC Access(SSO)アカウント向けのWebAuthn/FIDO2パスキー登録手順である。
  • RIPE NCCは2024年3月27日にRIPE NCC Accessアカウントでの2FAを義務化し、2024年5月30日にパスキーを2FA手段として追加した。パスキーはFIDO2互換ハードウェアキーまたはパスワードマネージャーに保存でき、iOS、Android、多くのデスクトップブラウザで利用できる。
  • 支柱となるRIPE-843ポリシー(2025年5月発効)は、IP資源とRPKIを管理するLIRポータル利用者を含む全SSOアカウント保有者に対し、TOTPまたはハードウェア/ソフトウェアパスキーによる2FAの有効化を義務付けている。
  • 名簿上の台湾(TW)タグは、RIPE NCCがメンバー名簿や国コード表示でISO 3166-1を採用していることの分類上の帰結であり、2024年8月の台北駐日経済文化代表処への回答書簡が示すとおり、出版元の帰属や政治的立場を意味しない。

文書が指しているもの

RIPE NCCのサポート文書は、2FAを「RIPE NCC Accessアカウントに追加の保護層を与える必須のセキュリティ機能」と定義する。RIPE NCC Accessは、LIRポータル、RPKI、その他のRIPE NCCサービスへのSSOである。手段は認証アプリとパスキー(ソフトウェアまたはハードウェア)の二種類で、パスキー節の見出しがまさに「Setting up 2FA with Passkey」である。

パスキー登録の実際の流れ

文書が記す登録手順は機械的だが、運用上の含意が大きい。設定画面で「Passkey」をクリックし、指示に従ってパスキーを登録し、保存場所を選び、名前を付け、最後に設定画面に表示された回復コードをコピーして安全に保管する、という順序である。回復コードは、認証アプリを削除した、スマートフォンの電池が切れた、端末を紛失した、あるいはセキュリティコードを生成できないあらゆる状況でのログインの代替手段と文書化されている。

対応認証器はWebAuthn/FIDO2認証器(ハードウェアとソフトウェア)とされ、Keycloakが対応する選択肢としてYubiKey、SoloKeys、Google Titan Security Key、Windows Hello、近代的なブラウザでのApple Face ID/Touch IDが挙げられている。パスキーはFIDO2互換のハードウェアセキュリティキーに保存するか、端末間で同期される可能性のあるパスワードマネージャーに保存できるというのが、2024年5月30日の発表の要旨だ。

なぜパスキーが可能になったか: Keycloak移行

RIPE Labsの技術記事によれば、かつてのRIPE NCC Accessの基盤であったAtlassian Crowdは、FIDO2キーのような近代的な2FA手段や、SAML 2.0、OIDCのようなセキュアな統合方式をサポートしていなかった。RIPE NCCはバックエンドをKeycloakへ置き換え、コンテナオーケストレーション基盤上でAWSのEKSを使うクラウドインフラに展開する作業を2023年7月に完了した。2FAは独自実装からKeycloakのネイティブ実装へ移り、その後に義務化が可能になった。RIPE NCC自身、TOTPを旧式技術と位置づけ、FIDO2キーや生体認証をメンバーからの最重要要望として挙げている。

義務化の制度化: RIPE-843

RIPE-843は「SSOアカウントで二要素認証を有効化することが義務である」と規定し、手段としてTOTPまたはハードウェア/ソフトウェアパスキーを挙げる。適用対象はIP資源やRPKIを管理するLIRポータル利用者を含むすべてのRIPE NCC Accessアカウント保有者である。つまり2024年3月27日の義務化に始まった運用上の制約が、2025年5月以降は正式ポリシーとして固定されたことになる。

セキュリティ上の論拠と残る弱点

英国国家サイバーセキュリティーセンター(NCSC)は、FIDO2資格情報(パスキーを含む)が、野外で観測される一般的な資格情報攻撃に対して従来型MFAと同等以上に安全と評価し、SMS、メールコード、アプリTOTP、プッシュ承認といった従来手段が本質的にフィッシング可能であり続けると指摘する。同時にNCSCは、利用者が資格情報を管理・削除でき、回復手段を設定できることをサービス側が明確に提供すべきだとしている (NCSCの分析)。RIPE NCCの回復コード方式はこの原則の実装だが、複数人で運用される機関にとって回復コードの保管は共有秘密の問題を一部に残す。パスキーが送信元に紐づく資格情報であるのに対し、回復コードはどこに写したか次第で漏えいしうる。