どうも おかしん です。
社員、業務委託、再委託、パートナー企業の担当者が同じSaaSを使う組織では、「OktaでMFAを必須にしています」だけでは説明しきれない場面が増えます。
同じアプリにログインする人でも、雇用形態、契約期間、端末の管理主体、端末の状態、EDRで見えているリスクは違います。ここをグループ名だけで押し込むと、例外が増えた瞬間に、なぜ許可しているのか、なぜ拒否しているのかを説明しづらくなります。
この記事では、ABAC（Attribute-Based Access Control / 属性ベースアクセス制御）を、Okta、Jamf Pro、Microsoft Intune、EDRを使う現場の言葉に置き換えて整理します。結論から言うと、最初に作るべきものは難しいポリシー式ではなく、雇用形態×デバイス管理状態のマトリクスです。
先に結論: まずマトリクスを作る
業務委託やパートナーが混在する組織でABACを始めるなら、いきなり細かい式を書かず、まず次の問いに答えます。
- 誰がアクセスするのか: 社員、業務委託、再委託、パートナー
- どの端末からアクセスするのか: 会社管理端末、委託先管理端末、個人端末
- その端末は期待された状態か: 登録済み、管理済み、OS更新、暗号化、画面ロック、EDR状態
- どのSaaSへ、どの操作まで許可するのか: 閲覧、編集、ダウンロード、管理操作
- 例外をいつまで許すのか: 契約期間、プロジェクト期間、緊急対応期間
この整理は、ゼロトラストの基本思想でいう「アクセスをネットワークの内外ではなく、文脈とリスクで判断する」考え方にもつながります。大事なのは製品を増やすことではなく、アクセスを許可する理由を説明できる状態にすることです。
最初のたたき台としては、次のくらいの粗さで十分です。
| 雇用形態 | 会社または委託元が管理する端末 | 個人端末・管理外端末 |
|---|---|---|
| 社員 | Okta MFA + Device Trust + Device Assurance | 重要SaaSは制限。必要ならブラウザ限定、DLP、ダウンロード制限 |
| 業務委託 | Okta FastPass + Device Trust + 契約期間に応じたアプリ割当 | 原則禁止。例外は期限、対象SaaS、補償統制を明記 |
| 再委託 | 原則として長期SaaSアクセスを認可しない | 認可しない |
| パートナー | SaaSごとのFederation、ゲスト、期限付きアクセス | 原則禁止。必要時はブラウザ分離やVDIを検討 |
この表があるだけで、「社員だから全部許可」「委託先だから全部禁止」のような雑な判断から離れられます。例外を作る場合も、どの属性を満たしていないから補償統制が必要なのかを話しやすくなります。
ABACを現場の言葉に置き換える
NIST SP 800-162では、ABACを、subject、object、requested operations、environment conditionsなどの属性を、ポリシーやルールに照合してアクセス可否を判断する論理的アクセス制御方式として整理しています。
この定義をそのまま現場へ持ち込むと少し硬いので、SaaSアクセス制御では次のように読み替えると扱いやすくなります。
| NISTの観点 | SaaS運用での読み替え | 例 |
|---|---|---|
| subject | 利用者や所属元の属性 | 社員、業務委託、所属会社、契約終了日、職務 |
| object | 守る対象 | Salesforce、Box、GitHub、管理コンソール、顧客データ |
| operation | 許可したい操作 | ログイン、閲覧、ダウンロード、編集、管理操作 |
| environment conditions | 状況やリスク | 端末管理状態、OSバージョン、EDR状態、場所、時間帯 |
| policy | 判断ルール | 会社管理端末かつEDRリスク低なら重要SaaSを許可 |
RBACが悪いという話ではありません。部署、職務、プロジェクトでグループを分けるRBACは今でも便利です。ただ、業務委託やパートナーが混じると、「同じプロジェクトメンバーでも、会社管理端末かどうか」「契約終了日を過ぎていないか」「EDR上のリスクが高くないか」のような条件が効いてきます。
つまり、RBACで大枠を作り、ABACで文脈を足す。この順序が現実的です。
Okta×MDM/UEM×EDRの3層で見る
Okta、Jamf Pro、Microsoft Intune、EDRを組み合わせるときは、1つの製品に全部を背負わせない方がよいです。役割を3層に分けます。
| レイヤー | 主な役割 | 代表例 | 記事での見方 |
|---|---|---|---|
| IdP / アクセス制御 | 認証、MFA、アプリサインインポリシー、条件評価 | Okta | 最終的にSaaSアクセスを許可・拒否する場所 |
| MDM / UEM | 端末登録、管理状態、証明書配布、構成プロファイル | Jamf Pro, Microsoft Intune | その端末を誰が管理し、期待状態へ寄せられるかを見る場所 |
| EDR / Endpoint Security | 脅威検知、端末リスク、Zero Trust Assessmentなど | CrowdStrike、Windows Security Center、Chrome Device Trust | 端末のリスクシグナルをアクセス判断へ加える場所 |
OktaのDevice TrustからOkta FastPassへの移行FAQでは、Identity EngineのDevice TrustはOkta Verifyと証明書を使い、特定のMDMに閉じずに動作すると説明されています。Jamf ProやMicrosoft Intuneなどのエンドポイント管理ツールは、利用者がOkta連携アプリへアクセスする前に端末を管理する役割を担います。
Device Trustは「その端末が登録・管理された端末として扱えるか」を見るための土台です。一方、Okta Device Assuranceは、OSバージョン、画面ロック、ディスク暗号化などの端末姿勢を、アプリサインインポリシーの条件へ組み込むための機能です。
さらに、OktaのEDR signals for custom expressionsでは、CrowdStrikeのZero Trust Assessmentスコアを表す device.provider.zta.overall や、Windows Security Centerのアンチウイルス、ファイアウォール、自動更新などのtrust signalsが説明されています。EDRやWindows Security Centerの状態を、Okta Expression Languageの条件として使えるわけです。
Oktaのエンドポイントセキュリティ連携が対応するのは、本稿執筆時点（2026年6月）ではCrowdStrike、Microsoft Windows Security Center、Chrome Device Trustです。ChromeOSやChromeブラウザのデバイスシグナルを条件に使いたい場合は、Chrome Device Trust連携が選択肢になります。
ここで混ぜてはいけないのは、Jamf ProやMicrosoft IntuneはMDM/UEMであり、EDRそのものではないという点です。同じように、Windows Security CenterはWindows標準のセキュリティ状態（アンチウイルスやファイアウォールの有効性など）を集約するシグナル源であり、CrowdStrikeのようなEDR製品そのものではありません。MDM/UEMは端末を管理し、EDRは脅威やリスクを見る。この役割分担を曖昧にすると、「管理されている端末だから安全」と言いすぎてしまいます。
属性をどこで判定するか
ABACを運用へ落とすときは、属性を1か所に集めるより、どの基盤がどの属性を責任を持って出すかを決める方が現実的です。
| 属性 | 判定する場所 | ポリシーでの使い方 |
|---|---|---|
| 雇用形態 | HR / IdP / グループ | 社員、業務委託、パートナーでアプリ割当と条件を分ける |
| 契約終了日 | HR / ITSM / IdP属性 | 契約終了後にアクセスを止める。延長時は期限を更新する |
| 端末登録 | Okta Verify / Device Trust | Registered / Managed相当の条件に使う |
| 端末管理状態 | Jamf Pro / Microsoft Intune | 証明書配布、構成プロファイル、準拠状態の根拠にする |
| 端末姿勢 | Okta Device Assurance | OSバージョン、画面ロック、暗号化などを条件化する |
| EDRリスク | CrowdStrike / Windows Security Center | リスクスコアやセキュリティ状態をアクセス条件に加える |
| アクセス対象 | Okta / SaaS側 | 重要SaaS、管理画面、データ持ち出し操作を分ける |
実務では、この表をそのまま設計資料にすると議論が早くなります。「業務委託はOktaグループで分けます」と言うだけではなく、「業務委託という属性はどこから来て、契約終了時に誰が消すのか」まで決める必要があります。
過去の弊社ブログでは、Okta Device Assuranceでデバイスの状態を条件にアクセス制御を行なってみたや、改訂版 Intuneを使ってmacOSをOkta Identity Engine Device Trustしてみたで、それぞれの検証観点が整理されています。EDR連携については、Okta Identity EngineとEDRを連携してアクセス制御してみたも合わせて読むと、今回の話の具体像が見えやすくなります。
実装前に決めること
実装前に決めたいのは、画面上の設定値よりも、運用上の責任分界です。
| 決めること | なぜ必要か | 例 |
|---|---|---|
| 重要SaaSの優先順位 | 全SaaSを一気にABAC化すると運用が詰まる | まずBox、GitHub、Salesforceなどから始める |
| 雇用形態の分類 | グループ名ではなく契約と責任で分ける | 社員、業務委託、再委託、パートナー |
| 端末管理の基準 | どこまでを会社が責任を持って制御できるか決める | Jamf/Intune登録、証明書、暗号化、画面ロック |
| 例外の期限 | 例外が恒久化するとポリシーが壊れる | プロジェクト終了日、契約終了日、緊急対応期間 |
| 監査ログ | 後から説明できない統制は続かない | 誰が、どの端末から、どの条件で、許可/拒否されたか |
| 解除手順 | 委託終了時にSaaS残留を防ぐ | IdP停止、SaaSゲスト削除、トークン無効化 |
最初の対象は、全社利用SaaSよりも、データの価値が高く、外部委託者が触る可能性があり、ログが追えるSaaSが向いています。たとえばソースコード、顧客情報、契約情報、ファイル共有、チケット管理のような領域です。
逆に、最初から全端末、全SaaS、全委託先を対象にすると、例外申請と問い合わせで運用が詰まりやすくなります。ABACは細かくできるほど強いのではなく、説明できて、維持できて、見直せる粒度にすることが大事です。
運用で詰まりやすい注意点
Device TrustとDevice Assuranceを同じ意味で使わない
Device Trustは、Okta Verifyや証明書を使って、端末が登録・管理された端末として扱えるかを見る土台です。Device Assuranceは、OSバージョンや画面ロック、ディスク暗号化など、より具体的な端末姿勢を見る条件です。
両方を使う場合でも、「管理された端末か」と「その端末が今どの状態か」は分けて説明した方がよいです。
あわせて押さえておきたいのは、OktaがDevice TrustからOkta FastPassへの移行（およびデスクトップ向けのManagement attestation）を推奨している点です。とくにJamf Pro管理のmacOSを対象としたOkta Device Trustは、Jamf Classic APIの廃止にともない2024年9月30日で提供終了（EOL）となりました。現時点で新規に設計するなら、Device Trustを恒久の土台と見なさず、Okta Verify登録を前提としたFastPassを中心に据えることを検討してください。
macOSのFileVault確認をDevice Assuranceだけに寄せない
OktaのAdd a device assurance policyでは、macOSのDisk encryption条件はハードウェアディスク暗号化を確認し、FileVaultの状態は確認しないと説明されています。
FileVault準拠を要件にするなら、Jamf ProやMicrosoft Intune側のコンプライアンス、スマートグループ、構成プロファイル、レポートで別途確認する設計にします。ここを読み違えると、「Device Assuranceで暗号化を見ているからFileVaultも担保できている」と誤解しやすいです。
EDRシグナルはリアルタイム万能ではない
OktaのEndpoint security integrationsでは、EDRシグナルはOkta側で最大8時間、またはセッションタイムアウトまでキャッシュされると説明されています。
そのため、EDRシグナルを条件に入れる場合も、「常に最新の脅威状態が即時反映される」と書かない方がよいです。高リスク操作では、セッション再評価、アラート連携、手動停止、SaaS側の権限削除も組み合わせます。
再委託の常時SaaSアクセスを安易に認可しない
再委託先に長期SaaSアクセスを出すと、契約、責任分界、端末管理、アカウント停止、ログ確認が一段難しくなります。
必要な場合でも、常時ログインできる個人アカウントを作る前に、VDI、Browser Isolation、期限付きゲスト、作業単位の共有、データ持ち出し制限を検討します。ここはセキュリティだけでなく、契約と業務委託管理の論点です。
明日やるなら何から始めるか
明日から始めるなら、次の順番が現実的です。
- 重要SaaSを3つ選ぶ。
- そのSaaSへアクセスしている社員、業務委託、パートナーを一覧化する。
- 会社管理端末、委託先管理端末、個人端末を分ける。
- 既存のOktaグループ、アプリ割当、MFA条件、Device Trust条件を棚卸しする。
- Jamf Pro / Microsoft Intuneで見ている端末管理条件を確認する。
- EDRシグナルをOktaの条件へ使えるか確認する。
- 例外を期限付きで書き出し、次回見直し日を決める。
この順番なら、大きなゼロトラストプロジェクトにしなくても始められます。最初の成果物は、立派な構成図ではなく、重要SaaSごとの「誰が、どの端末から、どの条件でアクセスしてよいか」の表で十分です。
FAQ
Q1. ABACとRBACは何が違いますか。
RBACは、役割に権限を結びつける考え方です。ABACは、利用者、対象、操作、環境条件などの属性を組み合わせて判断します。実務では、RBACで大枠を作り、ABACで端末状態、契約期間、リスクなどの条件を足すと考えると分かりやすいです。
Q2. Okta Device TrustとDevice Assuranceは何が違いますか。
Device Trustは、Okta Verifyや証明書を使って、端末が登録・管理された端末として扱えるかを見る土台です。Device Assuranceは、OSバージョン、画面ロック、ディスク暗号化などの端末姿勢をアプリサインインポリシー条件へ入れる機能です。両方を併用する場合もあります。
Q3. BYODを完全禁止できない場合はどうすべきですか。
会社管理端末と同じ権限を与えないことが出発点です。ブラウザ限定、ダウンロード制限、DLP、対象SaaS限定、期限付きアクセスなどを組み合わせます。重要データを扱うSaaSでは、BYODを例外扱いにし、例外の期限と承認者を残す方が運用しやすいです。
Q4. EDRシグナルをOktaに渡せない場合はどうすべきですか。
まずMDM/UEMとDevice Assuranceで、登録済み端末、OSバージョン、画面ロック、暗号化などの確認から始めます。EDRシグナルは、あれば強化できる層として扱い、使えない状態で全体設計を止めない方がよいです。
Q5. 再委託先にもアカウントを発行してよいですか。
必要な場合はありますが、常時SaaSアクセスを前提にしない方が安全です。契約、責任分界、端末管理、ログ、停止手順を確認し、まずは期限付きアクセスや作業単位の共有で足りるかを検討します。
まとめ
業務委託・パートナーが混在する組織でABACを実装するなら、最初に必要なのは複雑なポリシー式ではありません。
まず、誰が、どの端末から、どの状態で、どのSaaSへアクセスしてよいかを表にします。そのうえで、Oktaは認証と条件評価、Jamf ProやMicrosoft Intuneは端末管理、EDRは端末リスクというように、属性の出どころと責任範囲を分けます。
ABACは、社員や業務委託を疑うための仕組みではありません。業務に必要なアクセスを、安全に、説明可能に、期限付きで許可するための整理です。
まずは重要SaaSを3つ選び、雇用形態×デバイス管理状態のマトリクスを作るところから始めてみてください。
参考資料
- NIST SP 800-162: Guide to Attribute Based Access Control (ABAC) Definition and Considerations
- Okta: Device assurance
- Okta: Add a device assurance policy
- Okta: EDR signals for custom expressions
- Okta: Endpoint security integrations
- Okta: Migrate from Device Trust to Okta FastPass FAQ
- Okta: Okta Device Trust for Jamf Pro managed macOS devices - End of Life October 2024
- CrowdStrike Falcon Identity Protection
