Oktaマネージドデバイスでデスクトップ端末制限の実現（概要編）

今日の企業の業務では、従業員が様々な場所から様々な組織リソース（社内システムやデータ）を利用できることが当たり前になっています。そして、リソースへのアクセスに使用するデバイスも多様化しています。

業務を行う場所やデバイスの多様化は利便性を向上させますが、同時にセキュリティリスクを高めることにもなります。

インターネット上では、デバイスは多くの脅威にさらされます。マルウェアに感染したデバイスから社内システムを利用すると、不正アクセスによる個人情報・機密情報の漏えい、ランサムウェアによるデータの損失、あるいはシステムの破壊によって業務停止につながることも考えられます。

このようなリスクを低減するため、「組織が管理する信頼できるデバイス」以外からの組織リソースの利用を制限したいと、要望いただくことが多くあります。

本記事では、アイデンティティ管理サービス「Okta Workforce Identity Cloud」で認証を行う際に、クライアント証明書を用いて「組織が管理しているデバイスか、管理外のデバイスか」を判断する方法について、仕組みと実装手順を概要編、設定編に分けて説明します。

マネージドデバイスを利用するための条件

Okta Workforce Identity Cloud（以下、Okta）は、証明書基盤やMDMと連携して「デバイスが組織で管理されているものであるか」を判断し、認証リクエストを拒否したり、認証方法を切り替えたりなどの制御を行えます。Oktaでは、信頼できるデバイスを判断する方法を「デバイストラスト」機能と呼んでいましたが、現在提供されているOkta Identity Engineでは「マネージドデバイス」という機能名になっています。

まず、マネージドデバイスを利用するための条件について説明します。

ライセンス

マネージドデバイスを利用するためにはAdaptive SSOまたは、Adaptive MFAのライセンスが必要です。マネージドデバイスは、「アクセスに使われるデバイスが組織で管理されている」状況（コンテキスト）を認証の条件とするため、Adaptive SSO/MFAで利用できるコンテキストベース認証の機能として提供されます。

PKI（公開鍵暗号基盤）

デバイスが組織で管理されているかどうかの「管理証明」をするために、デスクトップデバイス（Windows、macOS）ではPKIとの連携が必要です。本記事では触れませんが、モバイルデバイス（Android、iOS）の管理証明にはPKIは不要です。ただし、MDMとの連携は必要となります。

Oktaでは、以下のPKI構成をサポートします。

Oktaを認証局（Certificate Authority：CA）として証明書を発行

この構成は、Microsoft IntuneやJamf Proなど、UEM/MDM製品で管理されたデバイスに対してクライアント証明書を発行できます。そのため、別途UEM/MDMの導入が必要です。

UEM/MDMはデバイスが登録されると、そのデバイス用のクライアント証明書の署名要求（Certificate Signing Request：CSR）を、Oktaが提供するCAに証明書管理プロトコルSCEPを通じて送ります。Okta CAは、受け取ったCSRに電子署名をしたクライアント証明書をUEM/MDMに送り返し、UEM/MDMからクライアント証明書を各デバイスに配付します。

UEM/MDMによって組織で管理されているデバイスにのみクライアント証明書が発行されるため、そのクライアント証明書を持つことが管理証明となります。

UEM/MDMが導入されている環境では最も導入しやすく、また運用コストも少ない構成となります。

サードパーティまたは独自認証局から証明書を発行

Okta CA以外の認証局を使ってクライアント証明書を発行する場合の構成です。この構成では、Oktaは外部認証局を信頼することで、外部認証局が発行したクライアント証明書を使ったデバイスの管理証明を行います。

注意点として、Oktaはそのクライアント証明書が本当に「組織が管理しているデバイスにのみ配付されていること」を判断できません。署名要求が正規のものであるか、発行したクライアント証明書が正しいデバイスに配付されているかについては、PKI側に委ねられるため、証明書の発行・配付には十分注意が必要です。

技術的には、クライアント証明書を手動で配付しインストールしても、マネージドデバイスは働きます。しかし、証明書を正しく配付するために独自認証局を使用する場合でも、UEM/MDMと連携した管理が事実上は必要であるとOktaのドキュメント上には記載されています。

では、UEM/MDMを導入していない組織は、どのようにマネージドデバイスを利用すれば良いのでしょうか？サードパーティの証明書発行機関では、デバイスへのクライアント証明書配付機能を提供しているものがあります。

一例として、サイバートラスト社が提供する「サイバートラスト デバイスID」では、様々なOSへの証明書一括配付機能や専用アプリを用いた証明書のインストールに対応しています。そして、固有情報（MACアドレスなど）を保持するデバイスにのみ証明書をインストールできる厳格な端末認証を行っているため、証明書発行時にデバイス固有情報をあらかじめ登録しておくと、UEM/MDMと連携を行わなくてもマネージドデバイスを構成できると考えます。

なお、サードパーティの証明書発行機関を利用する際の注意点ですが、証明書発行機関によっては複数の組織で共有する認証局を提供しており、証明書のサブジェクト内の組織名（O）や、組織単位名（OU）などで組織を判別できるようにしている場合があります。しかし、Oktaではサブジェクトを検証しないため、同じ証明書発行機関から発行された証明書であれば、どの組織のものであっても管理証明として使用できてしまいます。

前述の「サイバートラスト デバイスID」では専用認証局を提供する「デバイスID Premium」オプションを利用することで、別組織の証明書を管理証明に使用できないようにできます。他のサードパーティの証明書発行機関を利用する場合も、専用認証局を提供するサービスがあるものを利用するようにしてください。

マネージドデバイスの仕組み

ここではデバイスがOktaに認証要求を行う際に、どのようにマネージドデバイスが機能するのかについて概要を説明します。

検証される内容

マネージドデバイスは、Okta Verifyを使用したOkta FastPass認証の中で検証されるため、デスクトップデバイスにOkta Verifyがインストールされ、Okta FastPass認証が有効になっている必要があります。

Okta FastPassで認証を行う際、管理を証明するペイロード（データ）にクライアント証明書で署名を行います。Oktaは受け取ったペイロードが「信頼する認証局から発行されたクライアント証明書で署名されていること」「そのクライアント証明書が有効であること」を検証し、問題がなければデバイスを信頼できるデバイス（管理されたデバイス）として扱います。通常のクライアント認証ではクライアント証明書自体をサーバーが検証しますが、Oktaマネージドデバイスでは署名された管理証明情報を検証します（Oktaはユーザー証明書を使った認証［PIV認証］にも対応しています）。

クライアント証明書の使いまわし対策

OktaはFastPassによる初回認証時に、クライアント証明書とOktaによって払い出されるそのデバイスの一意のIDを紐づけます。UEM/MDMで証明書を配付している、または「サイバートラスト デバイスID」のように証明書が正しいデバイス以外にはインストールできず、エクスポートもできなくなっているのであれば、証明書が複数のデバイスにコピーされて使いまわしされることはありません。

しかし、万が一、別のデバイスでコピーされたクライアント証明書が管理証明に使用されたとしても、そのデバイスのIDとクライアント証明書が紐づけられたデバイスのIDが一致しないため、管理されたデバイスとは見なさないという防御機能を提供しています。もちろん、マネージドデバイスが正しく機能しないトラブルを避けるため、UEM/MDMで証明書を配付する場合でも、独自認証局を使用してクライアント証明書を発行する場合は、同じクライアント証明書を複数のデバイスに配付することが無いよう注意が必要です。

おわりに

前編となる概要編では、証明書によるOktaマネージドデバイスを利用するための条件とその仕組みについて紹介しました。クライアント証明書の発行方法は自組織の環境によって複数の方法から選択できるので、自組織にあった方法を検討してみてください。

後編ではマネージドデバイスを使った、ポリシーの具体的な設定例とその動作について紹介します。