会社情報
採用情報
お問い合わせ
Article

二要素認証を全社導入する段階的アプローチ

高田晃太郎
二要素認証を全社導入する段階的アプローチ

Microsoftの分析では、多要素認証がアカウント乗っ取りの99.9%を防ぐ可能性があると報告されています¹。一方、VerizonのData Breach Investigations Reportでは、直近の年次版でインシデントの大半に「人」の関与があることが繰り返し示されています²。数字は十分に説得力がありますが、CTOやエンジニアリングリーダーにとって難しいのは「正しいやり方で、止めずに、全社で」実装することです。業務は止められず、レガシープロトコルや自動化ジョブ、現場端末の多様性が現実の壁として立ちはだかります。本稿では、実務でつまずきやすいポイントを前提に、二要素認証（2FA）の全社導入を段階的に成功させるための設計・実装・運用の勘所を、測定指標と具体的なポリシー例とともに整理します。

目的と前提を数値でそろえる：スコープ、方法、指標

最初に決めるべきは目的の粒度です。単に「全員に2FAを強制」ではなく、重要資産のリスク低減、ヘルプデスク負荷の最小化、ログイン体験の一貫性といった複合目標を設定し、測定可能なKPIで縛ります。代表的には、有効化率、強制適用率、バイパス率、ヘルプデスク問い合わせ件数/100ユーザー/月、認証成功率、認証レイテンシのp95、誤拒否率、1ユーザー当たりの初期登録所要時間などが有効です。導入前に現状値を採っておくと、介入効果が定量で示せるため、経営合意と継続投資の説得材料になります。

次に方法の選定です。2FAの手段は、TOTPアプリ、プッシュ通知（番号マッチ付き）、FIDO2セキュリティキー（公開鍵方式）、OS/ブラウザのパスキー（FIDO2/WebAuthnのパスワードレス資格情報）、そしてSMS/音声通話があります。NIST SP 800-63Bは、PSTN（SMS/音声）を使うアウトオブバンド方式のリスクを明示し「制限付き（Restricted）」として扱っています。したがって標準はアプリベースやFIDO2/WebAuthn/パスキーを優先し、SMSは回復や暫定用途にとどめる設計が無理のない選択です³。また米国CISAは、フィッシング耐性を持つ認証（例：FIDO2/WebAuthnやパスキー）の採用を強く推奨しています⁴。複数方式を併用し、端末紛失時の回復経路と「最終手段の紙ベースの回復コード」を定義します。

スコープは「アイデンティティ・プロバイダ（IdP：認証の入口を集中管理する基盤）配下の全クラウドアプリ」を起点とし、並行してメールやVPN、Git、社内Wi-Fiなど業務基盤の入り口に寄与の大きい箇所から優先度順に広げます。レガシープロトコル（IMAP/POP/SMTP、古いActiveSync）、ヘッドレスCI/CD、バッチやRPA、サービスアカウント、そして障害時のブレークグラスアカウントは、ユーザー向けの2FAとは別設計が必要です。ここで例外を先にカタログ化しておくと、全社展開時の「止まる」事故を減らせます。

監査可能な土台を用意する：ポリシー集中とログ基盤

方針の一貫性を保つには、IdPでのポリシー集中が要です。Microsoft Entra ID（旧Azure AD）、Okta、Duo、Auth0など、組織の標準IdPに集約し、条件付きアクセスやグループベースの適用、位置情報とデバイスコンプライアンスの信号を活用します。すべてのサインインイベントはSIEMに集約し、タイムスタンプ、ユーザー、クライアント、利用した要素、結果、リスクシグナルを最低限の共通スキーマで保存します。監査対応とチューニングの双方で、検索可能性と追跡可能性が後から効いてきます。

互換性の鬼門に先手を打つ：レガシーとSSOの整理

互換性の多くはプロトコルとクライアントに起因します。モダン認証に非対応のクライアントは段階的に更新し、やむを得ない場合は限定期間のアプリパスワードやプロトコル制限で被害範囲を局所化します。またSaaS群をSSO配下に束ね、IdP側の強制で一元適用できるようにします。SSO未接続のSaaSは順次統合し、社内ポータルからの起動を標準導線にします。ゼロトラストの考え方と合わせて、入口をIdPに寄せるほど統制と可視性が上がります。

パイロットから本番強制へ：段階的な拡大戦略

いきなり全社強制に踏み切るのではなく、デバイスと業務パターンの多様性を代表するユーザー群でパイロットを実施します。IT/セキュリティ部門が最初に自分たちで使い倒し、次に資金・人事・経理のようなリスクの高い部門、そしてプロダクション権限を持つエンジニアへ拡大します。OSはWindows、macOS、iOS、Androidを網羅し、リモートとオフィス、モバイルとデスクトップの両方を含めます。期間の目安として、1〜2週でベースライン計測と設定の下見、3〜4週でパイロット、5〜8週でウェーブ1/2の展開、9〜12週で全社強制という流れが、業務影響と学習効果のバランスを取りやすい印象です。

コミュニケーションは導入の成否に直結します。登録手順の動画と画像、よくある質問、回復コードの保管指針、紛失時の緊急連絡、ブレークグラスの適用条件を事前に配布し、登録期限とサポート時間帯を明確にします。押し付けではなく、なぜ2FAが必要か、どの手段が安全で使いやすいかを説明することで、自発的な登録率が上がります。

実装の具体例：主要プラットフォームのポリシー

コンセプトだけでは動きません。代表的な環境での実装サンプルを示します。実際の適用では組織の要件に合わせて条件や例外を調整してください。

AWS IAMでコンソール操作にMFAを要求する基本ポリシーの例です。ブレークグラスや自動化ロールは別ポリシーで扱い、ここでは一般ユーザーに焦点を当てます。

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "DenyIfNoMFA",
      "Effect": "Deny",
      "Action": "*",
      "Resource": "*",
      "Condition": {
        "BoolIfExists": { "aws:MultiFactorAuthPresent": "false" }
      }
    }
  ]
}

Microsoft Entra ID（Azure AD）の条件付きアクセスをTerraformで管理する例です。緊急アカウントや登録未完了ユーザーを除外し、クラウドアプリ全体に強制します。

provider "azuread" {}

resource "azuread_group" "breakglass" {
  display_name = "SEC-BreakGlass"
  security_enabled = true
}

resource "azuread_conditional_access_policy" "mfa_all" {
  display_name = "Require MFA for All Cloud Apps"
  state        = "enabled"
  conditions {
    users {
      include_users  = ["All"]
      exclude_groups = [azuread_group.breakglass.id]
    }
    applications {
      included_applications = ["All"]
    }
    client_app_types = ["all"]
  }
  grant_controls {
    operator          = "AND"
    built_in_controls = ["mfa"]
  }
}

OktaのポリシーAPIで、WebAuthnとOkta Verifyを優先し、SMSはアカウント回復に限定するルールを作成する例です。

curl -s -X POST \
  -H "Authorization: SSWS <OKTA_API_TOKEN>" \
  -H "Content-Type: application/json" \
  https://<your-okta-domain>/api/v1/policies \
  -d '{
    "type": "MFA_ENROLL",
    "name": "Company MFA Enrollment",
    "status": "ACTIVE",
    "settings": {
      "factors": {
        "okta_verify": {"enroll": {"self": "REQUIRED"}},
        "webauthn": {"enroll": {"self": "OPTIONAL"}},
        "sms": {"enroll": {"self": "NOT_ALLOWED"}}
      }
    }
  }'

Duo Admin APIを使い、Duo Pushの番号マッチとWebAuthnを許可するグループポリシーを作るPython例です。エラー処理を含め、失敗時のログを残します。

import json
import logging
import requests
from requests.auth import HTTPBasicAuth

logging.basicConfig(level=logging.INFO)

API_HOST = "https://api-<your-duo-host>.duosecurity.com/admin/v1"
IKEY = "<IKEY>"
SKEY = "<SKEY>"

payload = {
    "name": "Corporate MFA",
    "status": "active",
    "pushinfo": {"require_duo_code": True},
    "webauthn": {"enabled": True}
}

try:
    r = requests.post(f"{API_HOST}/policies", auth=HTTPBasicAuth(IKEY, SKEY), data=payload, timeout=10)
    r.raise_for_status()
    logging.info("Policy created: %s", r.json().get("policy_id"))
except requests.RequestException as e:
    logging.error("Failed to create policy: %s", e)
    raise

GitHubの組織メンバーに2FAを必須化する設定は、Enterprise外でもAPIで可能です。SAML/SSOと組み合わせると効果的です。

curl -X PATCH \
  -H "Authorization: token <GITHUB_TOKEN>" \
  -H "Accept: application/vnd.github+json" \
  https://api.github.com/orgs/<org> \
  -d '{"members_can_create_repositories": false, "two_factor_requirement_enabled": true}'

最後に、Entra IDのサインインログをKQLで可視化する例です。導入の進捗と失敗要因を日次で追跡します。

SigninLogs
| where TimeGenerated > ago(7d)
| summarize total = count(), mfa = countif(AuthenticationRequirement == "multiFactorAuthentication"),
          success = countif(ResultType == 0), fail = countif(ResultType != 0) by bin(TimeGenerated, 1d)
| extend mfa_rate = todouble(mfa) / todouble(total), success_rate = todouble(success) / todouble(total)

運用監視とSLO：壊さずに締める

本番強制の前に、ポリシーを「レポート専用（Report-only）」で数日走らせ、影響範囲を確認します。強制後はSLOを設定し、日次で差分を見ます。例えば全社の認証成功率を99.5%以上、p95の認証レイテンシを3秒以下、ヘルプデスクの関連チケットを月間ユーザー100人当たり0.5件以下、登録未完了率を5%未満、ブレークグラス発動を四半期で0件という水準に置くと、ユーザー体験と保護水準のバランスを保ちやすくなります。SLO違反が続くときは、許可方式の見直し、クライアント更新、例外の縮退、コミュニケーション増強の順で原因を切り分けます。

プッシュの承認疲れ対策は必ず組み込みます。 番号マッチや端末ロック解除との連動、プッシュ回数のレート制限、失敗の連続時にCAPTCHAや追加要素を求める段階的な強化、そして地理/時間帯の異常検知を、IdP側の機能で有効化します。ユーザー教育も有効で、プッシュ承認は必ず自分の操作と一致するか画面で確認する習慣を、オンボーディング時に示します。これらは承認疲れを悪用する攻撃の抑制に有効で、フィッシング耐性の高いFIDO2/WebAuthnやパスキーの併用と合わせて効果を高められます⁵。

例外設計と自動化：止めないための裏側

サービスアカウントやバッチ、CI/CDはユーザー2FAの枠外で設計します。クラウドではマネージドIDやOIDCフェデレーション（ワークロードが相手先に対して短命のトークンで自身を証明する方式）を用いて、秘密情報を発行せずワークロードを認証させます。GitHub Actionsからクラウドへは短命トークン、Kubernetes内はServiceAccountとIRSA/GSA Workload Identityなど、相手先に応じた非対話フローを標準化します。人の介在する共有アカウントは原則廃止し、どうしても残る場合はアクセスごとの記録と権限の時間制限を徹底します。

ブレークグラスは二つの独立経路とオフライン手順を用意します。具体的にはクラウドIdPに追加要素免除の緊急アカウントを少数だけ用意し、強固なパスフレーズと保管手順で保護します。発動条件、承認者、発動時の自動通知、発動後の強制パスワード変更、事後レビューを運用プロセスに組み込み、四半期ごとにリハーサルを実施します。緊急時の連絡網と、端末紛失時の本人確認フローも平時に検証しておくと復旧が早まります。

運用はできるだけコード化します。ポリシーはTerraformやPulumiで管理し、変更はPRレビューを経て適用します。登録状態や未登録ユーザーの抽出、回復コードの未発行検出、リスクサインインのアラートはスケジュールジョブにし、ダッシュボードに surfaced します。SSO未接続SaaSの棚卸しを月次で回し、SSO統合の進捗もKPIに入れます。FIDO2やパスキーの採用率を上げると、ログインのレイテンシとヘルプデスク負荷の両方が下がるため、二段の効果が期待できます⁵。

ビジネス効果とROI：費用対効果を見える化する

2FAのROIは、インシデント回避の逸失コスト削減に加え、運用効率の向上で説明できます。例として従業員500名の環境を考えます。パスワード関連のヘルプデスクは仮に年0.5件/人、1件あたりの社内コストを30分×人件費4,000円/時と仮定すると、年間の粗いコストは500×0.5×2,000円＝50万円になります。2FAとSSOの併用でこの種の問い合わせが30〜50%減るケースはしばしば報告されており⁵、単純化すれば年間15〜25万円の削減効果が見込めます。SMSを標準にしない設計であれば、通信費の可変コストも抑制できます。登録と定着にかかる初期コストは、ヘルプデスクと情報システムの稼働で数十〜百数十時間規模、FIDO2キーを配布する場合でもハイリスク職務に限定すれば数百本で済みます。併せて、強制の「前後」でサインイン失敗率やレイテンシ、登録未完了率を定量で追えば、投資の正当化がしやすくなります。重要なのは、投資対効果を月次のKPIに落として継続的にレビューすることです。保護と業務効率はトレードオフではなく、適切なデザインで相乗効果を生みます。

よくあるつまずきと対処の要点

現場で多いのは、登録期限直前に集中しヘルプデスクが飽和する問題、レガシークライアントの想定漏れでメールが受信できなくなる事故、回復コード未発行のまま端末紛失でロックアウトする事象です。対処として、パイロット期に登録促進キャンペーンを小規模で試し、最も効くメッセージと媒体を特定してから全社展開に移します。互換性は「禁止前提で例外許可」の設計に切り替え、対象と期間を明記した申請フローで管理します。回復コードはオンボーディング完了の定義に組み込み、未発行者には自動リマインダーを送ります。これらは地味ですが、止めない2FAの鍵になります。

まとめ：二要素認証を「文化」にする

2FAの全社導入は、一度の強制で終わるプロジェクトではなく、組織の基盤を更新し続けるプログラムです。目的と指標をはじめに明確にし、パイロットで学び、例外を管理しながら段階的に締め、ログに基づいて運用を改善する。この一連のサイクルを回せば、保護は厳しく、体験は軽く、運用はシンプルに近づきます。自社の現状を数値で見える化し、まずは高リスク職務のパイロットから始めるのはどうでしょうか。次の四半期の全社強制を目標に、今日からポリシーのコード化とベースライン計測に着手すれば、導入の山は確実に低くなります。業務を止めない強い入口を、段階的に作っていきましょう。

参考文献

  1. Microsoft Security Blog. One simple action you can take to prevent 99.9 percent of account attacks (2019-08-20). https://www.microsoft.com/en-us/security/blog/2019/08/20/one-simple-action-you-can-take-to-prevent-99-9-percent-of-account-attacks/
  2. Verizon. 2023 Data Breach Investigations Report. https://www.verizon.com/about/news/2023-data-breach-investigations-report
  3. NIST SP 800-63B. Digital Identity Guidelines: Authentication and Lifecycle Management (Revision 3, 2017-06-22; includes updates 2020-03-02). https://pages.nist.gov/800-63-3/sp800-63b.html
  4. CISA. Implementing Phishing-Resistant MFA (Fact Sheet). https://www.cisa.gov/resources-tools/resources/implementing-phishing-resistant-mfa
  5. Okta Security Blog. Everything is “Yes”: reducing friction while increasing security with phishing-resistant authenticators and smarter policies. https://sec.okta.com/articles/everythingisyes/