顔認証システムのなりすまし対策 設計チェックリスト12項目

顔認証を業務システムに組み込むとき、「顔が一致するか」だけを見ていると印刷写真であっさり突破されます。本記事は、顔認証システムを本番運用する前に確認すべきなりすまし対策を、設計・調達の抜け漏れを防ぐチェックリストにまとめたものです。当ブログのこれまでの記事への索引も兼ねています。

各項目にチェックが付かない場合、その先の記事で背景を確認してください。

A. 脅威モデルを決める

□ 1. なりすまし成功時に「誰が・どれだけ得をするか」を言語化したか
対策レベルは用途で決まります。勤怠打刻と口座開設では守るべきラインが違います。まず自分のシステムの動機を言語化します。 → なりすまし攻撃の種類と、どこまでが現実的な脅威か

□ 2. どの攻撃類型まで守るかを決めたか
印刷写真・画面表示・動画再生・3Dマスク・ディープフェイク——全部に対策すると過剰投資になります。最低でも印刷写真と画面表示（誰でも今日実行できる）は必須と考えます。 → 攻撃コスト×遭遇しやすさのマトリクス

□ 3. カメラ提示攻撃だけでなく、注入攻撃（インジェクション）の想定をしたか
高価値システム（金融等）では、カメラを迂回して映像を注入する攻撃も想定します。これはライブネス検知だけでなく、通信・デバイスの保護が守備範囲です。

B. 顔認証と別に「ライブネス検知」を入れる

□ 4. 顔照合とライブネス検知を別の機能として設計したか
顔照合は「誰の顔か」、ライブネス検知は「生体か偽物か」を判定する別の技術です。顔が一致しても生体とは限りません。 → なぜ顔認証は写真で突破されるのか

□ 5. 選んだライブネス方式の「破られ方」を把握しているか
まばたき要求・動作要求・深度カメラには、それぞれ動画再生・注入攻撃・3Dマスクという弱点があります。採用方式の限界を理解した上で選びます。 → 簡易ライブネス3方式の限界

□ 6. ユーザーに動作要求をするか、パッシブ（無動作）にするか決めたか
動作要求は UX を損ない、高齢者・障害のある利用者に負担をかけます。単一フレームのパッシブ判定なら動作要求なしで成立します。 → 単一フレームのパッシブ判定

C. 精度を「数字」で評価する

□ 7. APCER と BPCER を「ペアで」「測定条件つきで」確認したか
片方だけの数字、条件のない数字は評価できません。攻撃種別（PAI）と件数を必ず添えて読みます。 → FAR/FRR と APCER/BPCER の違い

□ 8. 「ISO準拠の社内評価」と「第三者認定」を区別したか
「ISO/IEC 30107-3 の指標体系を参考にした社内評価」と、認証機関による認定は意味が違います。製品ページの表現を確認します。 → 指標の読み方

□ 9. 自社の運用環境（カメラ・照明・距離）で実測したか
公称値はベンダーの測定条件での数字です。実際のカメラ・照明・撮影距離では変わります。導入前に自環境で検証します。

D. 運用環境の制約を満たす

□ 10. クラウド送信が許される環境か確認したか
医療・工場・金融・組込・官公庁では、顔画像の外部送信が構造的に不可なことがあります。その場合はオンプレ・オフライン方式が必須です。 → クラウドAPIが使えない現場で顔認証を動かす

□ 11. 端末スペック（CPU・メモリ）で目標フレームレートが出るか
GPU 前提のモデルは組込・エッジで動きません。CPU 推論で実用速度が出るかを、実機（想定する最低スペック）で確認します。 → 低スペックCPUでの実測記事（近日公開）

□ 12. モデル・ライブラリの同梱、ライセンス認証、更新配布がオフラインで回るか
閉域網では実行時にモデルを取りに行けません。同梱・オフラインアクティベーション・内部配布の経路を設計に織り込みます。 → オフライン顔認証の設計チェックリスト

索引: このチェックリストの背景記事

まとめ

• なりすまし対策は「顔が一致するか」の先にある。脅威モデル → ライブネス方式 → 精度評価 → 運用環境の4段で漏れなく設計する
• 最低ラインは「印刷写真・画面表示を弾けること」。ここは用途を問わず必須
• 精度は APCER/BPCER をペア・測定条件つきで読む。運用環境での実測を怠らない
• クラウド送信の可否・端末スペック・オフライン運用は、精度と同じくらい導入可否を左右する