多要素認証（MFA）や定期的なログインを「セキュリティ対策」として徹底している企業は多いでしょう。ところが、VPNやゼロトラストネットワークを提供する Tailscale は、それに真っ向から異議を唱えています。
2025年6月、Tailscaleが発表した公式ブログ記事によれば、「頻繁な再認証はセキュリティを高めるどころか、逆にリスクを招きかねない」というのです。
再認証の“やりすぎ”が招く落とし穴
セキュリティ業界では昔から「パスワードは定期的に変えよう」「ログインセッションは短く保とう」といった教訓が信じられてきました。しかしTailscaleはこれらを「もはや時代遅れ」と断じます。
🔄 なぜ危険なのか？
- ユーザーが疲弊する
- 頻繁なMFA要求は「クリック癖（OK連打）」を誘発し、MFA疲労攻撃（Push Bombing）への耐性を下げます。
- 認証フローが鈍化する
- 作業のたびに認証を求められることで、業務効率が著しく低下します。
- 形式的な安心感に依存
- 「再認証してるから大丈夫」という誤解は、実際の攻撃への対応を疎かにします。
Tailscaleが提唱する「スマートな認証」
Tailscaleは「頻度よりも質」「強制よりも文脈」を重視すべきだと主張し、以下のようなアプローチを推奨しています。
✅ OSレベルのロックを活用する
ユーザーが席を離れたら自動ロック、戻ってきたらOSで再認証──これだけで十分。アプリケーション側で再認証を繰り返すよりも、自然でストレスのないセキュリティを実現できます。
✅ 必要なときだけ認証する
たとえばSSHログインや重要な設定変更など、高リスクな操作時だけ再認証を促す方式。Tailscaleでは「Check mode」やSlack連携を活用することで、ポリシーに応じた“オンデマンド認証”を実現しています。
✅ ポリシー変更への即時対応
「ユーザーが退職した」「端末が改造された」など、セキュリティリスクのある状態を検知したら即座にアクセスを遮断する。これを可能にするのが、以下の2つの仕組みです：
- SCIM：IDプロバイダーと連携してユーザー情報をリアルタイム同期
- デバイスポスチャーチェック：端末の状態（パッチ、暗号化、MDM登録など）を継続監視し、信頼性の低い端末はアクセスを拒否
そもそも「再認証」の目的とは？
私たちはしばしば、再認証という行為そのものがセキュリティを担保してくれていると勘違いします。しかし、重要なのは**「誰が」「どこで」「どの端末から」「何をしようとしているか」**をリアルタイムに判断できるかどうかです。
それを支えるのが、動的アクセス制御（Dynamic Access Control）という発想です。
結論：セキュリティは「煩わしさ」ではなく「適切さ」
Tailscaleが示すように、現代のセキュリティは「頻度」ではなく「文脈」と「信頼性」に基づいて設計すべきです。
過剰な再認証は、ユーザーを疲れさせ、攻撃者にはチャンスを与えます。
その代わりに、端末の状態をチェックし、IDの状態をリアルタイムで反映する設計こそ、次世代のセキュリティと言えるでしょう。
💡 補足：用語解説
🔄 SCIM（System for Cross-domain Identity Management）
SCIMは、複数のドメイン間でユーザーのアカウントや属性情報を統一的に管理・同期するための標準プロトコルです。主にクラウドベースのSaaSやIDaaS（Identity as a Service）間で、ユーザーの追加・変更・削除を自動化するために使用されます。
📌 特徴
- 標準化されたREST APIとJSONスキーマ
- RFC 7643（スキーマ）、RFC 7644（API）で定義
- プロビジョニングとデプロビジョニングの自動化
- IDaaS側でユーザーを作成・更新・削除すると、SCIM対応のSaaSにも自動反映される
- 役職や部署、グループ情報の同期も可能
- 単なるアカウント作成だけでなく、ロールベースのアクセス制御（RBAC）も実現可能
📘 ユースケース例
- Oktaで新入社員のアカウントを作成 → SlackやGitHubなどに自動でアカウントが作成される
- 社員の部署が異動 → 使用中のSaaSすべてに新しい役職情報を同期
- 退職者が出たら → すべてのサービスから即時に削除して情報漏えいリスクをゼロに
🛡️ デバイスポスチャーチェック（Device Posture Check）
デバイスポスチャーチェックは、ユーザーが利用しているデバイスの「安全性」を評価する仕組みです。ゼロトラストアーキテクチャにおいて、「ユーザー本人であること」だけでなく、「使用している端末が信頼できること」も確認する必要があります。
📌 チェックされる代表的な項目
| チェック項目 | 説明 |
|---|---|
| OSのバージョン | 最新のWindowsやmacOSなどが使われているか |
| セキュリティパッチ | 最新のパッチが適用されているか |
| ウイルス対策 | 有効なセキュリティソフトが稼働中か |
| ストレージの暗号化 | BitLocker（Windows）、FileVault（Mac）などが有効か |
| ロック画面設定 | スクリーンロックやパスコードの有無 |
| 管理状態（MDM） | 企業による端末管理がなされているか |
| Jailbreakやroot化 | デバイスが不正に改造されていないか |
📘 利用例
- Tailscaleでは、信頼されていない端末からの接続を拒否するようにACL（アクセス制御リスト）で設定可能
- OktaやGoogle Workspaceでは、MDM登録済みデバイスのみログインを許可するように設定可能
- 一時的にセキュリティ状態が悪化したデバイス（ウイルス対策無効など）を自動でブロック
🎯 まとめ
| 用語 | 主な目的 | 対象 |
|---|---|---|
| SCIM | ID情報の自動同期 | ユーザーアカウント・属性 |
| デバイスポスチャーチェック | デバイスの安全性確認 | 利用端末の状態・構成 |
この2つを組み合わせることで、「ユーザー + デバイスの状態」という多層的な認証・認可モデルを実現でき、TailscaleのようなゼロトラストVPNでもより安全かつ利便性の高いアクセス制御が可能になります。
