第3回：Oktaの認証設定
浅葉 正史ブログ第3回について
わけあって第2回から更新の間隔がだいぶ開いてしまったのですが、「はじめてのOkta」ブログ第3回となります。
本ブログの第1回では、そもそもIDaaSとはなんだろう？という話題で、主に以下の3つがIDaaSの機能であるということを書きました。
- ID統合管理
- SSO
- アクセス制御の強化
第2回では、Okta Workforce Identity Cloud（以降「Okta」と記述を省略させて頂きます）を使って、「SSO」と、「ID統合管理」に必要なユーザープロビジョニングについて、設定を実際に試してみました。
ですので、今回第3回では、Oktaの「アクセス制御の強化」機能に関わる設定を実際に試してみたいと思います。
システムの「アクセス制御（アクセスコントロール）」とは
まず前提知識として、そもそもシステムにおける「アクセス制御」（「アクセスコントロール」という言い方をする人もいますね）とはなんだろう？と考えてみました。
アクセス制御とは、システム上のリソースに対して、誰が、何に対して、どういうアクセス権限でアクセスを可能とするかという方針を決め、実装し、アクセスが方針通り制御されていることをログ等の記録で確認することです。
方針は、例えば「自社の全従業員が、自社のMicrosoft 365に、一般権限で利用できるようにする」 「自社の人事部の社員が、人事システムに、管理者権限でアクセスできるようにする」 みたいな感じです。
インターネットで「アクセス制御とは」のように検索すると、アクセス制御を以下の三要素として説明することが多いようです。
| 認証 | アクセスの主体「誰」を識別し、適切な主体にのみアクセスを許可すること |
| 認可 | アクセスを許可された主体に対して、適切なシステムの利用権限を付与すること |
| 監査 | 認証と認可がポリシー通り行われていることをログ等に記録しモニタリングすること |
Oktaで言うと、「認証」はユーザーのOktaへのログインを制御すること。「認可」は、Oktaにログインしたユーザーに対し、アプリケーションへの適切な利用権限を付与すること。監査は、上記認証と認可のログをOktaのシステムログに記録することと言えるでしょうか。
なお、上記説明は単純化した説明となりますが、認証されるアクセス主体はユーザーにとは限らずデバイスやプログラムであることもあったり、誰に何を許可するかだけでなく「どういう条件で」という条件付け（例えば接続元が社内ネットワークの場合はアクセスを許可する等)があったり、実際のアクセス制御の運用はもう少し複雑かもしれません。
様々な認証方法
IDaaSは様々なシステムのID管理と認証を統合するサービスですので、アクセス制御の上記3要素の中でも、Oktaのアクセス制御機能の中核はやはり「認証」機能となると思います。
システムの認証方法にも色々種類がありますが、またインターネットで「認証の種類」などと検索して調べてみますと、認証方法を以下の3つ要素の認証に分類して考えている方が多いようです。
| 認証要素の分類 | 説明 | 例 |
|---|---|---|
| 知識認証 | 本人だけが知っている知識を元に認証する方法 | パスワード 秘密の質問 |
| 所有物認証 | 本人が所有物を使用して認証する方法 | デバイス（PC/スマートフォン） ICカード トークン メールアドレス |
| 生体認証 | 本人の固有生体情報を利用して認証する方法 | 指紋 静脈 顔 |
この、3要素の認証のうち複数要素を組み合わせた認証を「多要素認証」（Multi-Factor Authentication 略してMFA）と言います。
私は、これまでずっとIDとパスワードだけで行う認証がメインの時代を生きてきたわけですが、昨今はパスワード認証を代表とする知識認証のセキュリティ上の脆弱さがすこぶる悪評であり、「パスワード認証など、この世から消してしまえ」というのがセキュリティ意識の高い方々の統一見解になっているかもしれません。
Oktaでは、豊富な種類の認証機能が提供されており、その中でもパスワードレスな認証方法が強く推奨されています。
Oktaが提供する認証機能について、以下が公式のドキュメントのリンクとなります。 （こちらのページでは前述「生体認証」について「固有」の認証と記載されています）
また、この後使用する認証方法の選択にあたって「フィッシング耐性」という言葉が出てくるのですが、「フィッシング耐性」については、以下リンクのOktaのブログ記事「フィッシング耐性のある多要素認証（MFA）の必要性」と「初めてのOkta Workforce Identity Cloud (WIC) [第4回] 「Phishing resistant」って何だ？」が、わかりやすく説明されており、勉強になる内容でした。
https://www.okta.com/jp/blog/2022/10/the-need-for-phishing-resistant-multi-factor-authentication/
https://www.okta.com/jp/blog/2024/01/first-time-with-okta-wic-what-is-phishing-resistance/
なお、Okta Workforce Identity Cloudは、利用したい機能毎にプロダクト（ライセンス）が分かれており、契約するプロダクトによって利用できる認証方法が異なるようです。以下のリンクのページがプロダクト毎の機能が掲載された公式ページ（英語）になりますが、例えば「Okta Verify」という認証アプリを使用したFastPassというパスワードレス認証の機能は「SSO」というプロダクトの契約のみで可能ですが、同じくOkta Verifyを使用したワンタイムパスワード認証やPush認証の利用には「MFA」というプロダクトの契約が必要になるようです。
実際にOktaの認証の設定をやってみた
トライアル環境で、実際にOktaの認証設定を試してみました。
①利用する認証方法の選択と設定
まずは、Oktaで利用するユーザー認証方法の選択と設定を行います。
管理コンソールの左側ニューから[セキュリティ]-[Authenticator] の画面を開きます。
こちらの画面でまずはOktaで使用したい認証方法を選択し、設定します。
なお、Oktaで管理する各アプリケーション毎にどのような認証方法を使用するかは、別途後述の「認証ポリシー」で設定します。 ここでは、その前提として、Oktaで使用したい全ての認証方法を選択し、設定をします。
上記画面の「Authenticatorを追加」ボタンをクリックすると、以下の画面が表示されます。様々な種類の認証方法が選択できることがわかります。
なお、2024年1月現在、私のトライアル環境ではAuthenticatorの画面で最初以下のフィッシング耐性のある認証方法の利用を促すメッセージが表示されていました。
このメッセージは、利用する認証方法として「FIDO2(WebAuthn)」を有効にすることで表示が消えました。
今回私は、既定で有効となっているパスワード認証とメール認証の他に、Okta VerifyとFIDO2(WebAuthn）を追加で有効にしました。
また、こちらの画面では、利用を選択した認証方法についての追加の設定をすることが可能です。認証方法の行の右端の「アクション」をクリックすると「編集」のメニューが表示され、設定が可能です。
例えば「パスワード」の認証方法の設定だと、所謂パスワードポリシー（最小文字数や複雑性の条件、ロックアウト条件など）をここで設定できます。 また、Oktaの認証アプリ「Okta Verify」の設定の場合は、Okta Verifyで使用可能な3つの認証方法ワンタイムパスワード、Push通知、Okta FastPassの中でどれを使用するか等を設定ができます。
②グローバル・セッション・ポリシーの設定
次にグローバル・セッション・ポリシーの設定を確認しました。管理コンソールの左側ニューから[セキュリティ]-[グローバル・セッション・ポリシー] の画面を開きます。
グローバル・セッション・ポリシーは、Oktaの全認証の共通のポリシーとなります。Oktaで管理するアプリケーション毎の「認証ポリシー」もこの後に設定しますが、このグローバル・セッション・ポリシーは、Oktaの全ての認証で、アプリケーション毎の認証ポリシーの前にチェックされるポリシーになります。
以下リンクは、グローバル・セッション・ポリシーの設定方法についてのOkta公式ドキュメントになります。
ここでは例えば以下のような設定が可能です。
- 多要素認証を必須とするかどうか
- セッションのタイムアウト時間
- ユーザーがログイン時に「サインイン状態を維持する」をチェックした場合、ブラウザを開きなおした際にもセッションの有効期間内はサインインを省略することができるようにするかどうか
なお、セッションのタイムアウト時間は、後述のアプリケーション毎の認証ポリシーでグローバル・セッション・ポリシーより短い時間を設定可能なので、ここでは組織としてのMAXの時間を設定します。 ちなみに、Oktaのセッションタイムアウト時間はあくまでもOktaの認証のセッションのタイムアウト時間です。各アプリケーションのタイムアウト時間はアプリケーション側で制御されます。例えばOktaの最大セッション時間を12時間に設定しても、Oktaで認証するMicrosoft 365のセッションタイムアウト時間がMicrosoft 365側で無制限の設定になっている場合、Microsoft 365のセッションは無制限となります。Okta側のタイムアウト設定は、例えば、ユーザーが先にOktaの認証でSlackにログインしており、その後にMicrosoft 365にログインしようとした場合に、先のSlackへのログイン時に確立したOktaの認証セッションがいつまでMicrosoft 365の認証で有効とするかという設定となります。
また、グローバル・セッション・ポリシーの初期状態で作成されている「デフォルトポリシー」の「デフォルトルール」は一部設定変更ができない部分もありますので、自組織にカスタマイズしたポリシーを設定する場合は新しく自組織用のポリシーとルールを作成し、デフォルトポリシーより優先してポリシーが適用されるようにするとよいと思います 。（ポリシーは、条件に合致するポリシーが複数ある場合、上にある、番号が若いポリシーが優先され一つ適用されます。ポリシーの中にルールを複数作成した場合の適用されるルールも同様の考え方になります）
③アプリケーションに適用する「認証ポリシー」の設定
最後に、アプリケーション毎の「認証ポリシー」を設定しました。
「認証ポリシー」を作成（Oktaの初期状態で提供されているポリシーをそのまま使用することも可能です）し、アプリケーションに適用するという流れになりますが、一つの「認証ポリシー」を複数のアプリケーションに適用することが可能です。ですので、認証ポリシーの作成は「Slack用認証ポリシー」「Box用認証ポリシー」のように一つ一つのアプリケーション用に作成するというよりは、自社で利用するアプリケーションを求められるセキュリティレベルである程度分類し、セキュリティレベルの区分ごとのポリシーを作成するような方法が管理しやすいかもしれません。（「セキュリティレベルHighアプリ用ポリシー」「セキュリティレベルMiddleアプリ用ポリシー」「セキュリティレベルLowアプリ用ポリシー」みたいなイメージ）
今回は、自社で使用するセキュリティレベル中くらいのアプリケーションの認証ポリシーとして、以下のようなポリシーを作成すると仮定しをして設定を行ってみました。
- ユーザーが自社オフィスから対象アプリケーションにアクセスする場合は、パスワード認証またはOkta Verify認証またはWebAuthn認証を使用可能とする
- ユーザーが社外から対象アプリケーションにアクセスする場合は、フィッシング耐性のある強固なセキュリティの認証方法であるWebAtuhn認証のみを利用可能とする
管理コンソールの左側メニューの[セキュリティ]-[認証ポリシー]の画面で、「ポリシーを追加」をクリックし、ポリシーの名前と説明を入力し、ポリシーを作成します。
ポリシーを作成した後、そのポリシーのルールを設定します。ルールは複数作成することできますが、条件に合致するルールが複数ある場合は一番上の番号が一番若いルールが適用されます。
以下リンクは、ルールの設定方法や設定可能な内容について詳細が記載されたOktaの公式ドキュメントです。
ポリシーを作成した時点の初期状態で「Catch-all Rule」というルールがありますが、これは上位の全てのルールの条件に合致しない場合の「その他の場合」用のルールになります。まず最初に、この「Catch-all Rule」を編集し、「THEN」の「アクセス」の設定を初期値の「認証の成功後に許可」から「拒否」に変更しておくと、セキュリティの観点でよいのではと思います。（ネットワーク上のファイヤーウォール設定で、許可する通信を明示的に指定した上で、それ以外の通信は全て拒否という設定にしておくことがセキュリティ上望ましいのと同じようなイメージです）
その後、「ルールを追加」で、ルールを作成します。今回は社内からのアクセスと社外からのアクセスで異なる認証ルールを設定したいため、2種類の条件を設定するため二つのルールを作成します。ただ、今回は、ルール作成の前に、「社内からのアクセスの場合」「社外からのアクセスの場合」という条件設定をするために、ゾーンの定義を作成しました。
管理コンソール左側のメニューの[セキュリティ]-[ネットワーク]の画面で、「ゾーンを追加」をクリック。「IPゾーン」を作成します。
ゾーン名（今回は「社内」としました）を指定して、オフィス内のネットワークからインターネット接続する場合のグローバルIPアドレスを「ゲートウェイIP」に設定します。
次に、先ほど作成した認証ポリシーに「社内」「社外」という二つのルールを追加作成しました。
まず「社内」という名前のルールを作成し、「IF」の条件設定で「ユーザーのIP:」を「次のいずれかのゾーン」を選択し、その下に表示されたボックスで先ほど作成した「社内」ゾーンを指定。
「THEN」の「アクセス」は「認証の成功後に許可」のままとし、「ユーザーが認証に使用する要素」を「任意の一要素タイプ/Idp」を選択します。 「この要件を満たす、OrgのAuthenticator」という枠内で、設定した内容でユーザーが選択可能な認証方法が確認できます。
➀で行った「Authenticator」の設定で有効にした認証方法の中から、条件にマッチした認証方法もしくはその組み合わせが使用可能になります。 作成した「社内」ルールでは、ユーザーは、メール、パスワード、Okta Verify、WebAuthnの4種類のいずれか一つの認証方法でログインが可能となります。
またここでは、必要に応じて「再認証の頻度」の設定も可能ですが、今回は初期値の「2時間」のままにしました。
次に「社外」という名前のルールを作成し、「IF」の条件設定で「ユーザーのIP:」を「次のゾーンのいずれにも含まない」を選択し、その下に表示されたボックスで先ほどと同様「社内」ゾーンを指定。
「THEN」の「アクセス」は「認証の成功後に許可」のまま、「ユーザーが認証に使用する要素」は「所有要素」を選択、表示された「所有要素の制約」という設定箇所で「フィッシング耐性」のチェックをオンにします。これで、このルールではフィッシング耐性のある所有物認証であるWebAuthnのみが使用可能になります。
これでポリシーの作成は完了です。
次は認証ポリシーをアプリケーションに適用するのですが、対象のポリシーの画面で「アプリケーション」のタブをクリックすると表示される画面で「アプリを追加する」ボタンをクリックしてその認証ポリシーを適用するアプリケーションを選択します。複数のアプリケーションを選択することも可能です。
ユーザー向けのOktaのダッシュボードであるOkta Dashboardも一つのアプリケーションという扱いとなっていますので、今回は試しに作成したポリシーをOkta Dashboardに適用してみました。
試しにポリシーを適用したOkta Dashbordにログインをしてみます。
まず、IPアドレスを設定した社内ネットワークのPCからOkta Dashboardにアクセスしてみました。
まず、Okta FastPass（Okta Verifyを使った認証方法の一つ。ユーザー名入力が不要。）でサインインするか、それ以外の認証方法のためにユーザー名を入力する画面が表示されました。
ユーザー名を入力し「次へ」をクリックするとパスワード入力を求められ、パスワードを入力することでOkta Dashbordにログインすることができました。
また、パスワード入力の画面で「他の方法で検証する」のリンクをクリックすると、以下のようにパスワード以外の認証方法を選択できる画面が表示され他の認証方法でもログインが可能でした。
なお、再度ログインする際は、ユーザーID入力をした後に前回使用した認証方法が優先されて表示されるようでした。
次に社外のネットワークのWidows PCのChromeブラウザで、Okta Dashboardにアクセスをしてみました。
最初はさきほどと同じようにOkta FastPassでサインインするか、それ以外の認証方法のためにユーザー名を入力する画面が表示されました。 認証ポリシーで、Okta Verifyの認証を有効にしていないので最初にOkta FastPassのボタンが表示される動作は意外に思ったのですが、これは認証方法としてOkta FastPassが有効になっているわけではなく、ユーザーがユーザーIDの入力の手間を省く機能としてOkta FastPassの利用ができるのだと理解しました。
ユーザーIDを入力して「次へ」をクリックすると、Windows PCではWindows Helloの認証要求の画面が表示され、Windows Helloの認証でOkta Dashboardにログインすることができました。
私が使用したPCは指紋認証装置がないため、PINの入力を求められPINでログインしています。（ちなみに、PINはパスワードに似ていて「知識認証」のようですが、デバイス固有の認証情報であるため「所有物認証」となります）
社内からのアクセスの時とは異なり、ログイン時に「他の方法で検証する」のリンクは表示されず、他の認証方法が選択できないことも確認できました。
また、スマートフォンのブラウザでOkta Dashboardにアクセスした場合はスマートフォンの指紋認証でログインする動作となりました。
以上、今回第3回ブログでは、Oktaのアクセス制御の機能の中核である認証機能の設定を実際に試してみました。
