CAAで進めるパスキー段階展開と例外ハンドリング設計

Google Workspaceでは管理者アカウントへの2段階認証が段階的に自動適用となっており、パスキーを含む強固な認証方式の普及が進んでいる。OU（組織部門）・グループ単位でパスキー強制を段階的に適用できる構成になっており、BeyondCorpの中核機能であるCAA（Context-Aware Access、コンテキストアウェアアクセス）のモニターモードと組み合わせると、例外ユーザーを抱えた組織でも段階的な移行設計が可能になる。

この記事を読んだほうが良い人

• Google Workspaceでパスキー展開を計画中だが、一気に全社強制することへのリスクを感じている情シス担当者
• CAAをすでに使っており、パスキー展開にどう組み込むか判断したい人
• 共有アカウント・外部委託・レガシーデバイスを抱えており、例外ユーザーの対応方針が固まっていない人
• パスキー強制の企業運用として「誰がいつ登録済みか把握したい」というフェーズにある人

なぜパスキー展開にCAAを組み合わせるのか

パスキーを全社展開するとき、制御の軸は2つある。

1つ目は認証ポリシーの強制だ。管理コンソールのセキュリティ設定から、OU・グループ単位でパスキー（パスワードレス認証）の強制を有効にする。対象グループを段階的に広げることで、全社展開のペースをコントロールできる。

2つ目はアプリアクセスへの動的制御だ。CAA（Context-Aware Access）は、Googleのゼロトラストセキュリティフレームワーク「BeyondCorp」の実装の一つで、デバイス状態・ネットワーク環境・認証強度などの条件に基づいてアプリへのアクセス可否を動的に制御する仕組みだ。「モニターモード」で運用すれば、実際にアクセスをブロックせずに条件に引っかかるアクセスをログとして記録できる。

重要なのは、両者の役割は異なるという点だ。CAAは「このアクセスを通すかどうか」のゲートを担い、パスキー強制設定は「この認証方式でないとログインできない」という制約を担う。CAAだけでパスキー登録状態を直接チェックできるわけではなく、この役割分担を意識することが設計の出発点になる。

では全社一斉強制を試みると何が起きるか。パスキー未登録のユーザーがログインできなくなり、ヘルプデスクへの問い合わせが一時的に集中する。対応外デバイスを使っている社員が業務から締め出される。特に外出先や出張中のユーザーへの影響は即時で深刻だ。CAAとパスキー強制を段階的に組み合わせることで、「この部門はまだ準備中」という状態を安全に保ちながら移行を進められる。

組み合わせることで実現できる設計は次のようになる。

• モニター段階：CAAをモニターモードで設定し、未登録ユーザーによるアクセスパターンを把握する
• 部門別強制段階：特定OU・グループへのパスキー強制をONにし、CAAで影響を観察しながら対象を広げる
• 全社強制段階：例外グループを精査・縮小しながら、最終的に全ユーザーへ適用する

パスキー強制を段階的に進める3フェーズ設計

Phase 1：モニターフェーズ（最初の2〜4週間）

まず全社に対してパスキー強制はOFFのまま、登録を促すフェーズを設ける。強制しないまま登録数を集め、現状を把握することが目的だ。

並行して、機密アプリ（Gmail・Drive・管理コンソール等）に対してCAAアクセスレベルをモニターモードで設定する。モニターモードはアクセスをブロックせず、条件に引っかかったアクセスをログに記録するだけなので、業務への影響はゼロだ。

このフェーズで確認しておきたい項目は次の3点だ。

• パスキー未登録ユーザーの割合（セキュリティレポートから確認できる）
• CAAのモニターログに頻出するデバイスタイプ・OU・グループ
• 端末種別ごとのパスキー対応状況（iOS / Android / Windows / Macのバージョン分布）

Googleの管理コンソールには、2SV（2段階認証）の登録状況をOU・グループ別に確認できるセキュリティレポートが用意されている。パスキーの普及状況もここから把握できる。

Phase 1の「完了判断」の目安は、全ユーザーが1度以上ログインし、主要なアクセスパターンがひと通り観測できた状態だ。在宅勤務と出社が混在する環境では、曜日・時間帯を跨いだデータが集まるまでログを取り続けることが後のCAA条件設計の精度につながる。この段階で「パスキー非対応デバイスを持つユーザーが何人いるか」が把握できれば、Phase 2の準備が整ったと判断できる。

Phase 2：部門別段階強制（2〜8週間、部門ごとに設定）

ITリテラシーが高い部門・小規模なOU・管理者グループから、パスキー強制を段階的にONにする。Phase 1のモニターログをもとに、「デバイス非対応のケースがどのくらいあるか」「特定のネットワーク環境からのアクセスにどう対応するか」を判断の材料にする。

最初に強制を試みるのは、パスキー登録率が高く、デバイスが比較的統一されているグループだ。IT担当者や管理者グループで先行して運用することで、「強制後に何が起きるか」の実績データを社内で作れる。問題が起きたとき影響を受けるユーザー数が少ない段階で経験を積んでおくと、後のフェーズで判断に自信を持ちやすくなる。

部門ごとの適用タイムラインの目安は以下の通りだ。

対象グループ	パスキー強制開始の目安
管理者・IT担当者	Phase 2の1週目
セキュリティ研修修了済みの一般社員	Phase 2の2〜3週目
本社部門の一般社員	Phase 2の4〜5週目
営業・フィールド（モバイル中心）	Phase 2の6〜7週目
例外グループ（後述）	Phase 3へ持ち越し

強制に先立ち、少なくとも2週間の「登録推奨期間」を設けること。メールや社内ポータルでのアナウンスと合わせ、ユーザー側がパスキーを登録する猶予を作る。強制を先行させると、ログインできないユーザーからのヘルプデスク問い合わせが集中する。

また、強制ONにした部門についてはロールバック手順を事前に決めておく。「問い合わせが1日あたり○件を超えたら一時的に強制を解除する」という基準を先に設定し、対応可能な件数の上限をヘルプデスクと合意しておく。緊急解除できる体制があると、段階展開のペースを落とすことへの心理的ハードルが下がり、無理な一括切り替えを防げる。

Phase 3：全社強制と残余例外の整理（完了目標を先に設定する）

Phase 2で残った例外グループを対象に、個別対応を進めながら段階的に強制を拡大する。このフェーズでは「例外の無期限存続」を防ぐことが最大のポイントだ。

完了目標日を事前に設定する。「〇月末までに例外ゼロ」または「例外は〇件まで、かつ半期ごとに再審査」というポリシーを先に策定し、ITガバナンス委員会またはマネジメント層の承認を取っておく。期限のない例外は永続化する。

完了の定義は「パスキー強制の適用率」で測ることを勧める。全アカウント数に対して、パスキー強制グループに含まれるアカウントの割合を定期的に追い、目標値（たとえば95%以上）を達成した時点をPhase 3の完了とする。残りの例外アカウントには代替セキュリティ措置（CAAによるネットワーク制限等）が適用されていることをセットで確認する。

パスキー強制で例外対応が必要な4ケースと運用方針

実際の展開では、次の4ケースで例外対応が必要になる。

1. 共有アカウント

受付端末・サービス共用アカウントなど、複数人が使うアカウントは個人のデバイスに紐づくパスキーが使えない。可能な限り個人アカウント運用に切り替えるのが最善だ。切り替えが困難な場合は、特定ネットワークからのアクセスのみ許可するCAAアクセスレベルで代替セキュリティを確保し、例外グループとして管理する。

共有アカウントの棚卸しはパスキー展開フェーズと並行して行うと効率が良い。「誰がいつ何の目的で使っているか」が整理されていない共有アカウントは、パスキー問題以前にセキュリティリスクになる。アカウントの数と用途を台帳にまとめ、個人化できるものは移行計画に含めておく。

2. 対応外デバイス

古いAndroid端末や一部の固定端末はパスキー登録に対応していない場合がある。対応方針は「デバイスリプレイスのタイムラインとセットで例外期限を設定する」だ。「端末更新後に例外解除」というトリガーを事前に合意しておくと、例外が宙ぶらりんにならない。

デバイス対応状況の確認には、管理コンソールのエンドポイント管理から端末一覧を参照する方法と、担当者へのアンケートを組み合わせる方法がある。特にBYOD（個人デバイスの業務利用）デバイスが混在する環境では、アンケートを先行させて非対応端末の数を把握してから、リプレイス予算の稟議に動くと話が早い。

3. 外部委託・パートナー

自社ドメインのアカウントを持つ外部委託者は、デバイス管理の対象外であることが多い。アクセス対象アプリを最小化し、CAAで接続元ネットワークを制限する。例外の有効期限は委託契約期間に合わせて設定すると管理が楽になる。

外部委託者向けに会社貸与のデバイスを用意できる場合は、そのデバイスにパスキーを設定させる形でパスキー展開に含められる。貸与が難しい場合は、アクセス許可するアプリケーションのスコープを最小化し、CAAによるアクセスログを定期的にレビューする運用で補完する。委託契約終了時のアカウント削除フローを別途整備しておくと、例外グループの肥大化を防げる。

4. 長期不在ユーザー

育休・長期休業などでパスキー登録アナウンスが届かなかったユーザーへの対応として、復職時のオンボーディングにパスキー登録を必須ステップとして組み込む。復職前に1対1でITサポートを提供できる体制を整えておくと、現場の混乱を防げる。

長期不在中のアカウントは、CAAでアクセス可能なアプリケーションを最小化しておくことも選択肢の一つだ。特に外部サービスへのSSOやOAuth連携が有効なアカウントは、不在期間中のアクセスがないか管理コンソールの監査と調査機能で定期的に確認する運用を入れておく。

BeyondCorpのCAA条件設計：どのアプリに何を設定するか

どのアプリにCAAを適用するか、またどの条件でブロックするかは、アプリの機密度を基準に判断する。以下の表を設計の出発点として活用してほしい。

アプリの機密度	推奨するCAA設定	例外ユーザーへの対応
高（管理コンソール・機密Drive）	デバイス信頼度＋認証強度条件 / Activeモード	別アクセスレベル（IP制限等の代替条件）を適用
中（Gmail・Chat・Meet）	デバイス信頼度 / まずモニターモードで開始	モニターログを確認してからActiveへ切り替え
低（一般社内ツール）	CAAは当面不要	パスキー強制設定だけで対応する

モード選択の基準は次の2点だ。

• モニターモード：アクセス条件に引っかかっても実際にはブロックしない。影響範囲の可視化・ログ取得が目的。Phase 1〜Phase 2初期に推奨
• Activeモード：条件を満たさないアクセスをブロックする。設定ミスがあると業務影響が出る。Phase 2後半〜Phase 3で適用する

CAAにはBasicモードとAdvancedモード（CEL: Common Expression Language を使った条件式）がある。デバイス信頼度やIPレンジによる制御だけであればBasicモードで対応できる。一方、認証強度の条件（ハードウェアセキュリティキーや特定の多要素認証方式の要求）を組み込みたい場合はAdvancedモードが必要になる。どちらのモードで組むかは、組織のデバイス管理成熟度と運用担当者のCEL習熟度を踏まえて判断する。

認証強度の観点では、Access Context Managerが提供する「クレデンシャル強度ポリシー（Credential Strength Policy）」という仕組みがある。これはサービスへのアクセス時に要求する認証方式の強度を条件として指定できる機能で、フィッシング耐性のある認証方式（パスキー・ハードウェアセキュリティキー等）をアクセス条件に設定できる。この機能はAdvancedモードでの設定が前提で、利用にはChrome Enterprise Premium（管理対象ユーザー）のライセンスが必要だ。パスキー展開を機にCAAの認証強度条件を見直す場合は、現在使っているアクセスレベルのモードを確認してから設定変更に入る。

なお、CAAを利用するにはCloud Identity Premium、Enterprise Standard以上（Enterprise Essentials Plus含む）、Education Plus、Frontlineなどの対応エディションが必要だ。現在のエディションでCAAが利用可能かどうかを事前に確認しておく。

例外ユーザー対応チェックリスト

Phase 3の完了を目指す前に、以下の項目を確認する。

• [ ] 例外グループの構成員リストを最新化した（四半期ごとに更新する運用を決めた）
• [ ] 各例外ユーザーの「例外理由」と「解除予定日」を記録した
• [ ] 例外グループに適用するCAAアクセスレベルを別途定義した（未定義なら標準より厳しいIP制限等を検討）
• [ ] 例外グループのアクセスログを定期的に確認する運用を決めた
• [ ] 長期不在ユーザーの復職時フローにパスキー登録を組み込んだ
• [ ] 共有アカウントのネットワーク制限設定を文書化した
• [ ] 例外継続には半期ごとの承認が必要というポリシーを策定した
• [ ] ヘルプデスクがパスキー登録のサポート手順を把握している

まとめ：段階展開は「期限つきの移行計画」として設計する

パスキーとCAAを組み合わせた段階展開で大事なのは、「例外の永続化を防ぐ」ことだ。モニターフェーズで影響を測り、部門別に段階的に強制を広げ、例外グループには解除期限と代替セキュリティを設定する。この3ステップを「やんわりと進める計画」ではなく、完了目標日のある移行プロジェクトとして設計することが、情シス担当者が管理層を巻き込んで進めるための現実的な方法だ。

CAAのモニターモードは「強制できない言い訳」ではなく「強制に必要なデータを集めるツール」だ。モニター期間に得たログをもとに、「いつ・誰に・どのアプリでブロックをかけるか」を確認してからActiveモードへ移行する。その積み重ねが、全社パスキー強制という最終ゴールへの最短経路になる。

今週できる最初の一歩は、CAAをモニターモードで機密アプリに設定し、来週のセキュリティレポートでパスキー未登録ユーザーの実数を把握することだ。数字を持ってはじめて、管理層への説明も具体的になる。

コーポレートITのご相談はお気軽に

この記事で書いたような業務改善・自動化の設計から実装まで、DRASENASではコーポレートITの現場に寄り添った支援を行っています。 「まず相談だけ」でも大歓迎です。DRASENAS 公式サイトからお気軽にどうぞ。