19kl42
19kl42

Column

FAL (クレデンシャル・フェデレーション保証レベル) の概要と連携の安全性

NIST SP 800-63で定義される「FAL(フェデレーション保証レベル)」について、OIDCやSAMLを用いたシステム間連携(SSO)におけるセキュリティ強度の考え方を解説します。

FAL (Federation Assurance Level) とは?

**FAL(フェデレーション保証レベル:Federation Assurance Level)とは、NIST SP 800-63-3 において定義された、「複数のシステム間で認証情報を連携(フェデレーション)する際の安全性のレベル」**を示す指標です。

現代のWebシステムでは、ユーザーが各サービスごとにパスワードを作るのではなく、「Googleでログイン」や企業内の「シングルサインオン(SSO)」を利用するのが一般的です。このとき、認証を提供する側(IdP)と、認証を利用する側(RP/SP)の間で、どのように安全にデータをやり取りするのか、その暗号化の強度やプロトコルの信頼性を評価するのがFALの役割です。

3つのレベル(FAL1, FAL2, FAL3)の違い

FALは、連携に用いられるアサーション(認証結果を証明するデータ。OIDCのIDトークンや、SAMLアサーションなど)が、どれだけ強力に保護されているかによって3段階に分かれます。

FAL1: 基本的なフェデレーション(低〜中程度の保証)

  • 要件: IdP(認証側)が発行したアサーションに、IdPの「デジタル署名」が付与されていること。
  • 仕組み: 署名があることで、RP(アプリ側)は「このデータは途中で改ざんされていない」ことと、「確かにIdPが発行したものだ」ということを検証できます。一般的なOIDC(IDトークン)やSAMLの実装は、最低限このFAL1を満たしています。

FAL2: アサーションの暗号化(高い保証)

  • 要件: FAL1の要件(署名)に加え、アサーション自体が「RP(アプリ側)の公開鍵を用いて暗号化」されていること。
  • 仕組み: FAL1では、アサーションの中身(ユーザーの氏名やメールアドレスなど)は署名されているものの、暗号化はされていないため、通信経路上で盗聴されると中身を読まれてしまう可能性があります(通信自体がHTTPSであっても、プロキシ等で漏れるリスクがあります)。FAL2では中身も暗号化(JWEなど)されるため、宛先である特定のアプリ以外は絶対に中身を読むことができず、プライバシーが強力に保護されます。

FAL3: トークンバインディング(非常に高い保証)

  • 要件: FAL2の要件(署名+暗号化)に加え、アサーションが「通信を行っているクライアント(ユーザーのブラウザやアプリ)」に暗号学的に強く紐付け(バインド)されていること。
  • 仕組み: これはいわゆる「Proof-of-Possession (PoP)」の概念です。万が一、攻撃者がFAL2のアサーションを盗み出したとしても、攻撃者の端末からはそれを使ってログインすることができません。現在、このFAL3を満たすための技術として、DPoP(Demonstrating Proof-of-Possession)などのトークンバインディング規格の策定と実装が進められています。

安全な連携システムを設計するために

シングルサインオン(SSO)を導入すれば無条件に安全になるわけではありません。連携の仕組み(フェデレーションプロトコル)自体に脆弱性があれば、一つのIdPが突破されただけで、連携するすべてのシステムがドミノ倒しのように乗っ取られる危険性があります。

システム設計者は、認証自体の強度(AAL)を高めるだけでなく、「IdPとアプリの間の連携経路」であるFALの強度も、扱うデータの重要度に合わせて適切に引き上げる(例:医療情報や金融情報を扱うならFAL2以上を要求する)必要があります。

スポンサーリンク
X (Twitter) でシェアFacebook でシェア

この記事を書いた人:19kl42 編集部

デジタルアイデンティティ、eKYC、プライバシー保護などの複雑な仕組みを「共通言語」へと翻訳して発信しています。誰もが「デジタルな自分」を正しく扱い、信頼をデザインできる社会を目指しています。

関連記事・用語

コラム一覧へ戻る