みなさんこんにちは。ネットワールドの金沢です。
Okta Privileged Accessに関してこれまで2本ブログを書かせていただきました。今ブログが最終回です。OPAを使用した例として、RDP接続に時間・ユーザーの制限をかける設定をご紹介します。仕様としてはMicrosoft EntraのPIMをイメージしてください。
Okta内のサービス「Access Request」と併用することで、サーバーの使用を申請制・限定的に行うことを可能にさせます。本ブログはその手順を実際に開発・テストした際の記録となります。実際の設定画面の他、作成時に発生した懸念点も載せております。
目次
前提
今記事ではOkta Privileged Accessの他にAccess Requestを使用します。アクセスリクエストに関しては以下リンクにて詳細な記載がありますが、詳細に理解する必要はありません。 ライセンス等を制限して購入している場合はご注意ください。 help.okta.com
また、今記事は続き物となっており、前2記事で紹介した、OPAのADアカウント登録から使用するクライアント端末の登録まですべて終了しており、ADアカウントはOPAにてパスワード管理・パスワードローテーションが行われている状態です。そのほかの注意事項は前2記事と同様です。
シナリオ
以下は保護サーバーにRDPするときのイメージ図です。
①と②、Okta上では違うユーザーを同時操作します。①はOPAで保護された特権ADアカウントです。このアカウントでEnd User Dashboardにログインし、アクセスリクエストを起票し、②ユーザーが承認することでOPAアプリが使用できるようになります。その状態で前記事で登録したクライアントPCからOPAで保護しているサーバーにRDPします。
このサーバーのRDPは恒常的に許可されているわけではなく、OPAアプリを通じたRDPのみとし、それ以外のRDPは不可とします。
今回の制御の肝は、OPAアプリの使用を申請制とすることと、OPAアプリに時間制限をかけることです。
申請されておらず割り当たっていないときのイメージは、End-User Dashboardの画面の比較から確認できます。End User DashboardはOktaにユーザー情報があるすべてのユーザーが確認できる最初のポータルページで、特段設定しない限り割り当てられているアプリが表示されます。
画像は割り当て時の比較です。左がOkta Privileged Accessアプリが割り当たっていないとき、右が申請終了し割り当てがなされたときです。
アプリの割り当てはAdmin Consoleから直接割り当てをするのが一般的ですが、この場合の割り当て期間は恒常です。
割り当てを変則的にするため、アプリの利用に申請というステップを取り入れます。
画像の通り、この割り当てには時間制限を設けます。その期間が切れたときはアプリの割り当てを解除し、常にこのアプリケーションがどのユーザーからも使えるという状態を避けるようにします。
このアプリの承認は自分自身で行えます。ここでいう「自分自身」とは、ユーザー情報に関連せず人間一人のことであることをご理解ください。RDPしようとしているクライアント端末以外、もしくは別ブラウザ等でOktaにログインした、承認権限が割り当てられているユーザーを操作してセルフで承認することが可能です。
RDPはOPAを利用したときのみ、それ以外は使用できないように制限します。この制限はADのGPOと組み合わせ、OPAアプリが使用できるようになったタイミングでGPO上でRDPが可能なように制御します。そのため、このアプリが割り当てられていないときは自動的にRDPもできません。
RDPに使用できるアカウントはOPAアプリで管理している特権ADアカウントのみとします。デフォルトで作成される特権ADアカウントである「Administrator」は今回は考慮外とします。理由は前記事Okta Privileged AccessでAD管理をしてみた サーバー編 - ネットワールド らぼをご参照ください。
ドメインコントローラーの設定
GPOでRDPできるアカウントを制御されているかの確認をします。GPOで特別に許可しているADグループがない状態にします。
ビルドインで作成されるADグループのうち、以下グループは既定でRDP権限が付与されています。
| グループの種類 | RDP対象端末 |
|---|---|
| Administrators | ドメインコントローラー メンバーサーバー クライアント端末 |
| Remote Desktop Users | メンバーサーバー クライアント端末 |
これらのグループは既定でRDP権限を持っているため、ほかのグループにRDPの権限を与えていないことを確認します。 GPOを開き、「リモート デスクトップ サービスを使ったログオンを許可」が未定義となっていることを確認します。
Oktaユーザーを整備する
繰り返しになりますが、セルフでサーバー使用許可を実行するにはOktaのユーザーが2つ必要です。以下図の①、②を改めて整備します。
それぞれの役割としては以下です。
①Oktaユーザー：ユーザー基盤がADのアカウント。OPAで保護されていることが前提。保護サーバーに対してRDPを行うのに使用する。このユーザーでログインした状態のクライアント端末をOPAに登録しておく必要がある。
②Oktaユーザー：ユーザー基盤がAD以外のアカウント。OPAで保護されていない。①がOPAアプリを使用できるように操作するためのユーザー。パスワードを確認すること、①が起票したアクセスリクエストを許可することの2つを行う。
②Oktaユーザーに対して準備が必要です。
Admin Consoleで行う操作
- Okta Privileged Access関連
- 管理アカウント用グループの作成・プッシュ
OPA上でグループを作成しないように注意してください。今回は「temp-AccessRequest」というグループを作成しました。このグループにユーザーを追加する操作は自動で行い、かつ変則的に行います。ユーザーの割り当ては行わず、OPAアプリにプッシュします。
- 管理アカウント用グループの作成・プッシュ
- Access Request関連
- アクセスリクエスト管理者権限を割り当てる
このユーザーがアクセスリクエストを承認するため、権限が必要です。
- アクセスリクエスト管理者権限を割り当てる
Okta Privileged Accessで行う操作
- アクセス権を付与したグループに割り当てる
セキュリティポリシーにて設定したアクセス権をグループに割り当てます。OPAアプリユーザーに昇格した際、自動的にアクセス権が割り当たるようになります。
プッシュしたグループをプリンシパルとして割り当てる
OPAの割り当てに条件付けを行う
アプリの割り当てに対して条件付けを行います。これにより、Okta内アプリを使用することに対し申請ステップの導入及び時間制限をかけることが可能です。
Okta Admin Consoleからアプリケーションタブを開き、「Okta Privileged Access」アプリに遷移します。「Access Requests」タブを開き、「Create Condition」を押下します。
割り当てのために必要な条件を設定できます。 設定内容の詳細は以下となります。
| 項目名 | 設定の意味 |
|---|---|
| Requester scope | このアプリにアクセスできるOktaユーザーの範囲を指定。「Specific groups」を選択すると、このアプリのアクセスリクエストを上げられるのはそのグループ内のユーザーのみとなる。 |
| Access level | ユーザーが要求できるアプリへのアクセスレベルを定義 「Groups associated with the app」を選択し、先ほどのグループを設定 |
| Access duration | 承認後にアプリをアクセス・使用できる期間を設定。最短1時間最長52週間。 Ask requester to specify expirationを選択すると、要求者がアクセスしたい時間を要求することもできる。以下画像の場合は8時間の範囲でユーザーがアプリ使用の希望を出すことが可能。 |
例として以下画像のように設定しました。
設定が完了すると、Approval sequenceというタブが開かれます。これでアクセスリクエストが承認されるフローを作成することが可能です。「Select sequence」を選択します。
これまでに定義してきたフローが一覧と表示されます。「New sequence」を押下し新しく作成します。
シーケンス名を保存し作成を始めます。GUIで、TriggerとDeliverの間に、どのユーザーがアクセスを許可するのかといった動きを表現して作成します。
今回はシンプルに、アプリの使用理由を記入させるプロセスを経てから承認という流れにします。Question for Requesterを押下します。
理由を聞く文言を記入します。
もう一度「Questions for Requester」下の青い∔ボタンを押下し、承認タスクを追加します。
「Approval」を押下します。
どのユーザーが承認できるかを選択できます。属性からmanagerを選択することもできれば、グループに割り当てることも可能です。「Assign to」が想定通り割り当たっていれば「save」を押して保存します。
元のタブに戻り、リストをリフレッシュすると先ほど作成したシーケンスが表示されます。Selectします。
条件を作成していた画面に戻ってきます。作成したシーケンスが選択されていることを確認してCreateを押下してください。
作成した条件を有効にすることを忘れないでおきます。縦の三点リーダーを押し、「enabled」を押下します。
「Enabled」にしたら設定は完了です。
セキュリティルールを追加する
ドメインコントローラーの設定項目で、AD内のアカウントでRDPが可能なグループを制御しました。このグループにユーザーを追加すればRDPできるようになりますが、この追加を恒常的ではなくアプリの割り当てと同時に行えるような設定を追加する必要があります。
前々記事で作成した、RDPを制御しているセキュリティポリシー・ルールを開きます。
[Permissions for accounts]セクションまでスクロールします。
Accounts selected above will項目を設定することで、Okta Privileged Accessによるローカルグループメンバーシップの管理を決定することができます。今回はドメインコントローラーのRDPを行うため、Administratorグループ項目をONにしました。この設定により、一時的なADローカルグループへのユーザー追加が可能となりました。
動作確認
実際にどういった画面で使用できるのかどうかを動作確認も踏まえて確認します。 クライアント端末にOPAで登録済みのADアカウントを用いてログインします。このときクライアント端末も登録されている必要があることに注意してください。 アクセスするサーバー名は「DomainServer」であり、ドメインコントローラーの役割を持っています。
OPA未申請時のRDP接続確認
まずは何もしていない状態でリモートデスクトップ接続を行います。GPOによってアクセスが制御されていることを確認できます。
OPA申請時のRDP接続確認
Oktaのダッシュボードからアクセスリクエストを起票し、OPAアプリの割り当てを要求します。要求の承認者である②Oktaユーザーが承認できることを確認します。
「Request Access」を押下します。
アクセスを要求できるアプリが表示される画面に遷移します、今回は「Okta Privileged Access」を押下します。
OPAアプリ使用に制限をかける項目で設定したフローの通りにアクセスリクエストの画面が展開されます。使用したい時間を自分で設定し申請することも可能です。今回は1時間のアクセス期間を設定しました。
②Oktaユーザーに戻り、Access Requestアプリを開くとリクエストが届いています。
「Approve」を押下して承認します。「marked as done」と表示されればOKです。
アプリが割り当てられると画面に「Okta Privileged Access」が表示されます。
この状態でもう一度ドメインコントローラーにアクセスします。OPAアプリの経由は、アプリの画面とPowerShellからのコマンド実行からのアクセスによって可能です。
アクセスに使用できるADアカウントが一覧で表示されています。今回は使用しているADアカウントをそのまま選択します。「Connect」ボタンを押下します。
以下のポップアップが出てくるのでそのまま開きます。
「Approve」を押下します。
セキュリティポリシーで設定した通りにMFAが走ります。
RDPができていることが確認できました。
一連の流れはログでも確認できます。
またコマンドでの実行も可能です。PowerShellの起動からのアクセスを見てみます。クライアント端末からPowerShellを起動し「sft rdp [サーバー名]」を実行します。
プロンプト形式で接続に使用できるADアカウントが一覧となって表示されます。既にMFA認証が行われているため、MFAチェックはついた状態です。番号で使用するアカウントを選択します。
ビューアーが起動し、RDPに成功します。
こちらもログでサーバーにアクセスしたログが確認できます。
このアクセスはアプリ画面からのRDP直後に試したものです。従ってセキュリティポリシーでの「1度MFA認証を行うと、1時間MFA認証が行われない」という設定に該当するため、MFA認証は発生していません。
このように、Okta Privileged Accessを経由すると、サーバーのRDP対象を時間制限を用いて制御することができます。 またRDP時に使用したOktaユーザーや時間はOktaログを用いて辿ることが可能です。
補足
ローカルグループメンバーの割り当てに時差がある
動作確認中で発生している懸念点です。 アクセスリクエストを起票してから初のRDPは、サーバーへのRDPが失敗することがあります。検証では5分ほど時間を置き、再接続すればうまくいくことを確認しています。
これは「RDPセッションを開始してからローカルのAdministratorグループに割り当てを行う」というフローのため、RDPセッション開始からグループ割り当て・反映までに若干時間がかかるからが原因として考えられます.
RDPに失敗したときの失敗したユーザーが所属しているグループの状態を見ると、Administratorグループには追加されていない状態です。
しばらく時間を置き、RDPに成功したときはAdministratorグループに追加されています。
以下はAD内のログの画像です。グループの追加タイミングがRDPの失敗タイミングと成功タイミングの中間であることがわかります。
割り当てが時間制で行われている
実際にアプリの割り当てと同時にAD内のグループからユーザーが削除されるのかどうかを見てみます。先ほど追加された追加された1時間後にログを確認すると、割り当てが発生した1時間後にAdministratorグループからユーザーが外れたログが確認できます。
またこれは明確に1時間というわけではなく、「約1時間」でユーザーのグループの割り当ては外されています。
時間に差分がある理由に関しては、Okta上でこの時間に明確にグループの割り当てを削除したというログがないためどのタイミングで行われているかは不明ですが、おそらくADエージェントの同期タイミングと一致しているかと思われます。
終わりに
ここまでお読みいただきありがとうございました。いかがだったでしょうか。ただGUIで一元管理できるというだけではないOkta Privileged Accessアプリの使用例としてご参考になれば幸いです。
3本立てだったOPAとADにかかわる検証ブログも今回で最後となります。また次は違う検証結果をご紹介できればと思います。
▼▼▼▼▼▼▼▼▼▼▼▼▼▼▼▼▼▼▼▼▼▼
ネットワールドが開催する 年に一度の大イベント
【 Networld Wiz 2026 】お申込み受付中！！
本ブログでご紹介したメーカーもイベントへ出展します！
セッション & ブース出展情報 随時更新中
▼ぜひチェックしてください▼
