コンテンツまでスキップ

【Okta | OIGシリーズ】最小権限の原則を実践するAccess RequestsによるOkta管理者権限の付与

はじめに

こんにちは、ネクストモード株式会社テクニカルサポート担当です。

この記事を読んでいる方の中にはOktaのSuper Administrator権限を保持している方も多いのではないでしょうか。

ユーザーサポート業務としてパスワードリセットやMFAリセット、SSO設定を含む各種設定の調整などでOkta管理コンソールを利用する機会が多いと思います。

しかし、常にSuper Administrator権限を使える状態のままでよいのか疑問に思うことがありました。最小権限の原則を意識すれば、必要な時に必要な権限だけが付与されるべきなのです。

この記事ではOkta Identity GovernanceのAccess Requestsを活用し、利用時間を制限した権限付与を行う方法をご紹介します。

Access Requestsで実現できるOkta管理者権限付与のイメージ

ここでは、全く権限を持っていないユーザーがAccess Requestを行い、指定されたOktaグループ内のユーザーが承認することでSuper Administrator権限を付与する流れをスクリーンショットを交えてわかりやすくご紹介します。

 

申請者側の作業

申請者は最初にOktaダッシュボードから「アクセス要求」をクリックします。このスクリーンショットの時点では権限が全くないため、Okta管理コンソールへの導線がないことにも注目してください。

管理者権限がまったくないユーザーのOktaダッシュボード画面です。アクセスを要求するボタンが表示されています。

 

「Okta Admin Console」をクリックします。

アクセスリクエストでOkta Admin ConsoleとMore Itemsが表示されている画面です。

 

「Super Organization Administrator」を選択し、利用したい時間と申請内容を入力したら、「Submit request」をクリックします。

Okta Admin ConsoleのSuper Organization Administratorを選択し、申請内容を入力している画面です。

 

承認者の作業

承認者はOktaダッシュボードから「Okta Access Requests」をクリックします。

承認者のOktaダッシュボード画面でOkta Access Requestsが表示されている画面です。

 

RequestsのInboxを確認すると申請があるので、これをクリックします。

申請者がリクエストした申請が表示されている画面です。

 

画面右側にはAccess Duration(利用期間)やどのような権限が要求されているかが表示されます。画面中央にはTasksとQuestions(申請内容)が表示されています。承認するには「Approve」をクリックします。

リクエストの詳細画面です。

 

承認後の申請者側への反映

承認されると即座に権限が付与されます。申請者がOktaダッシュボードをリロードすると、Okta管理コンソールへの導線が表示され、実際にアクセスできるようになります。

申請者のOktaダッシュボード画面です。

 

また、承認後を基準に申請時に入力した時間が経過すると、自動的に権限は剥奪されます。

申請と承認はそれぞれメールで通知されますが、以下の記事で紹介しているようにSlackでの通知にも対応しています。

 

設定方法

以下の流れで、先ほどご紹介したイメージの設定を行います。

  1. Oktaグループの作成
  2. Okta Access Requestsアプリへのアサイン
  3. Access Requestの作成

 

1. Oktaグループの作成

リクエストを行える人と承認を行える人、それぞれを指定するために以下の2つのグループを作成しユーザーを追加します。

  • Okta Super Administrator Requester
  • Access Request Approver

 

2. Okta Access Requestsアプリへのアサイン

作成したOktaグループをOkta Access Requestsアプリへアサインします。

Okta Access RequestsアプリのAssignmentsが表示されています。

 

3. Access Requestの作成

Okta管理コンソールの「Security」>「Administrators」からGovernanceタブをクリックします。さらにAccess Requests内の「Create condition」をクリックします。

Administratorsの画面です。

 

Condition nameを入力し、Requester scopeでは作成しておいたOktaグループ「Okta Super Administrator Requester」を指定します。

Access levelでは「Super Organization Administrator」を指定します。

Access requestを作成している画面の前半部分です。

 

Access durationでは申請者に最大2時間まで指定をさせたいので「Ask requester to specify expiration」を選択し、Maximum durationを「2 Hours」と指定します。承認フローを設定するため、Approval sequenceでSelect sequenceをクリックします。

Access requestを作成している画面の後半部分です。

 

事前に用意された承認フローも表示されていますが、ここでは「New sequence」をクリックしてカスタマイズします。

承認フローの一覧画面です。

 

「Trigger」「Approve」「Deliver」のシンプルな構成が表示されています。

承認フロー新規作成時のデフォルト画面です。

 

TriggerとApproveの間をクリックし、「Questions for Requester」を追加して、申請者に申請理由を入力させるようにします。

申請者への質問を追加している画面です。

 

Approveをクリックし、Assign toに作成しておいたOktaグループ「Access Request Approver」を指定します。

承認者を指定している画面です。

 

最後に承認フローに名前をつけて「Save」をクリックします。

承認フローの名称を入力している画面です。

 

作成した承認フローを選択します。

表示されていない場合は「Refresh list」をクリックすると表示されるようになります。

一覧に新規作成した承認フローが表示されている画面です。

 

「Create」ボタンをクリックします。

新規作成した承認フローを指定した画面です。

 

この設定はまだ有効化されていないため、縦の3点リーダー(…)メニューから「Enable」をクリックして有効化します。

作成したAccess requestを有効化した画面です。

これで設定は完了です。

 

運用上の留意点

API Tokenを発行している場合、そのトークンは発行元アカウントの権限に依存します。今回の仕組みを適用する人が既にAPI Tokenを発行していないか確認し、必要に応じて特定の個人に紐づかない専用アカウントで管理することをお勧めします。

なお、Super Administrator権限を常時保有するアカウントは最低一つ必要となります。このアカウントも個人に紐づかない緊急用Oktaアカウントとして厳重に保管し、利用時には記録が残るようにしておきましょう。アカウント情報はKeeperなどのパスワード管理ツールに保管し、利用した際にはログやWebhook通知を通じて誰が利用したかをSlackなどに自動通知できるようにしておくと、相互監視の観点からより適切な運用が実現できます。

 

まとめ

この記事ではSuper Administrator権限にフォーカスしましたが、他の権限でも同様に設定することができます。実際には、普段はRead-only Administratorを付与しておき、必要だと判断した時に必要な権限のアクセスリクエストを行えるようにしておくのがバランスが良いでしょう。

このようにOIG機能を活用したオンデマンド型のアクセス権限管理により、セキュリティの向上とコンプライアンスの強化が実現できます。常時権限を付与するのではなく、必要な時だけ一時的に権限を取得できる仕組みは、特権アカウント管理におけるベストプラクティスと言えるでしょう。