MDMが届かない端末からのアクセスをどう守る？Okta Device Assuranceで実現したアクセス統制

NOT A HOTEL Business Accelerator の @enpipi です。
多様な企業やパートナーと協業する私たちにとって、「自社管理外の端末からの業務アクセス」をどう守るかは避けて通れないテーマです。

本記事では、MDM（モバイルデバイスマネジメントの略。以下、MDM） が適用できない端末に対しても、端末の健全性に基づくアクセス統制を実現するために、Okta Device Assurance Policy（デバイス保証ポリシー） を活用した取り組みを紹介します。実装の要点だけでなく、運用での工夫やつまずきを書きます。

背景と課題

クラウドサービスを利用する環境では、端末の健全性がセキュリティの基盤となります。 また、不正アクセスを防ぐため、常に最適で強固な認証方式を採用し続ける必要があります。

NOT A HOTEL では、以下の仕組みでセキュリティ要件を確保しています。

• MDMで端末の健全性と認可端末であることを担保

• 業務に用いるクラウドサービスを Okta による SSO で一元管理

• Oktaのデバイストラストを採用し、MDM管理外の端末からのアクセスをブロック

一方で、委託先など社外協力者が自社管理外の PC やスマートフォンを利用する場面は少なくありません。すべてに端末を貸与して MDMを導入するのは、運用やコスト等の観点から現実的とは言えないケースがあります。

その結果、外部端末のセキュリティ状態を把握・制御できないという課題が残っていました。

方針：端末状態を根拠に認可する

そこで採用したのが Okta Device Assurance Policy です。

Oktaで保護されたリソースへのアクセスにデバイスを使用する前に、最新のオペレーティングシステムのバージョンや、セキュリティパッチがデバイスにインストールされているかどうかを確認できます。

ユーザーやネットワーク条件ではなく「端末の状態」を根拠に、Okta への認証を許可するかを評価できます。これにより、自社管理外の端末でも、当社が定めた要件を満たす端末のみが Okta にサインインできる状態を作れます。

設計のポイント

Device Assurance Policy は主要 OS（macOS / Windows / iOS / Android / ChromeOS）に対応し、端末側の条件を細かく評価できます。
利用には Authentication Policy の「Device」条件の代替として、Device Assurance Policy（デバイス保証ポリシー） を設定します。

代表的に評価できる要素（例）

• OS バージョンの最小要件

• デバイス暗号化（FileVault / BitLocker 等）の有効化

• 画面ロック（パスコード）・生体認証の設定

• 脱獄・ルート化の有無

認証フロー上の位置付け

• 認証前段で端末状態を評価し、要件を満たさない場合は猶予期間後にブロック

• 各アプリの Authentication Policy と組み合わせる

事前要件

• Okta Verify のインストールとセットアップ（端末側）

• 各 OS の対応バージョンや前提条件は Okta の公式ドキュメントを参照

運用上の工夫（サポート負荷を下げる）

• エラーメッセージの日本語化

  • デフォルトの英語のままだと「なぜアクセスできないか」が伝わりにくい

  • デバイス保証に高度なポスチャチェックを構成する \| Okta Identity Engine を用いると、メッセージとリンク先をカスタマイズできる

  • 端末要件、問い合わせ先、自己解決手順を日本語で提示

• 猶予期間の設定

  • 猶予期間を設けることで導入後の即時ハレーションを防ぐ

つまずきと対処

• Okta Verify 必須化の体験設計

  • スマートフォンでOkta Verifyの起動ポップアップを否認した場合、キャッシュ破棄が必要。

  • 事前アナウンスとスクリーンショット付の手順、想定問答を用意し、回復手順を簡潔に統一

• β版 OS の扱い

  • iOS の β バージョンを正しく認識できず、最新でも「最新でない」扱いになる事象を確認

  • 通常は β 禁止だが、業務上の必要性が確認できる場合に限り、期間と対象を限定した例外運用を設定

  • Okta Ideasで投票してフィードバック済み

• Windows Updateと、Windows 更新リングとの整合

  • Windows の新リリース直後、Device Assurance Policy が更新を要求しても管理端末側で未展開のタイムラグが発生した。

  • 猶予期間を十分に取り、更新リングと認証強度の整合を担保

• Windows BitLocker の検知

  • 外部記録媒体含めたすべてのパーティションで暗号化されている必要がある

    • メーカーのリカバリ用パーティションが原因で「端末全体が暗号化されていない」判定になるケースがあった

    • それぞれ要件を踏まえてDevice Assurance Policyを分けることで対応

• Windows Helloを適用できない管理外端末があった

  • 共有PCで利用するためということを確認

  • それぞれ要件を踏まえて対応

• 高度なポスチャチェックのトリガーと Device Assurance Policy の項目との対応関係が分かりにくい。

  • 一部、想定と異なるエラーメッセージが表示

  • ワークアラウンドで確認しながら、エラーメッセージを調整

成果

Device Assurance Policyを導入後、以下の成果を得られました。

• 一部端末で暗号化未設定を検知し、関係者と連携して是正できた

• Intuneでは成功ステータスになっていたが実際にはBitLockerが暗号化中の端末を検知できた

• 管理が行き届きにくい外部スマホ等でも、一定のセキュリティ要件を技術的に保証できた

• 文章と導線の工夫により、サポート工数の増加を最小化できた

学びと限界

サプライチェーンのセキュリティは、セキュリティチェックシートや契約で形式上担保しても、端末の実態までは管理しにくい領域です。
Device Assurance Policyはそのギャップを「端末状態の評価」という現実解で埋めます。

一方で、評価対象はあくまで端末状態です。
情報の持ち出しや、利用可能なサービス範囲まで強く制御するには、やはり MDM 管理下の端末貸与が最善です。業務内容等に合わせて両者を補完的に使い分けるのが現実的だと学びました。

まとめ

• MDM が届かない領域はゼロにはならない

• だからこそ、端末状態に基づくアクセス統制を共通基盤として整える

• その上で、リスクの高い業務やデータには MDM 端末を必須貸与化する

Okta Device Assurance Policy は、非管理端末における技術的なセキュリティ施策を実装するための実用的な選択肢でした。
Device Assurance Policyをスムーズに導入できた背景には、MDMで端末要件を整備済みだったこと、日頃からセキュリティガイドラインを委託先とも共有し統制していたことがあります。

NOT A HOTEL では一緒に働くメンバーを探しています！
カジュアル面談も大歓迎です。よろしくお願いいたします！