はじめに こんにちは、 ネクストモード株式会社 テクニカルサポート担当です。 Okta Identity Governance (OIG) の機能の一つであるEntitlement...
【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 Admin Console」をクリックします。
「Super Organization Administrator」を選択し、利用したい時間と申請内容を入力したら、「Submit request」をクリックします。
承認者の作業
承認者はOktaダッシュボードから「Okta Access Requests」をクリックします。
RequestsのInboxを確認すると申請があるので、これをクリックします。
画面右側にはAccess Duration(利用期間)やどのような権限が要求されているかが表示されます。画面中央にはTasksとQuestions(申請内容)が表示されています。承認するには「Approve」をクリックします。
承認後の申請者側への反映
承認されると即座に権限が付与されます。申請者がOktaダッシュボードをリロードすると、Okta管理コンソールへの導線が表示され、実際にアクセスできるようになります。
また、承認後を基準に申請時に入力した時間が経過すると、自動的に権限は剥奪されます。
申請と承認はそれぞれメールで通知されますが、以下の記事で紹介しているようにSlackでの通知にも対応しています。
設定方法
以下の流れで、先ほどご紹介したイメージの設定を行います。
- Oktaグループの作成
- Okta Access Requestsアプリへのアサイン
- Access Requestの作成
1. Oktaグループの作成
リクエストを行える人と承認を行える人、それぞれを指定するために以下の2つのグループを作成しユーザーを追加します。
- Okta Super Administrator Requester
- Access Request Approver
2. Okta Access Requestsアプリへのアサイン
作成したOktaグループをOkta Access Requestsアプリへアサインします。
3. Access Requestの作成
Okta管理コンソールの「Security」>「Administrators」からGovernanceタブをクリックします。さらにAccess Requests内の「Create condition」をクリックします。
Condition nameを入力し、Requester scopeでは作成しておいたOktaグループ「Okta Super Administrator Requester」を指定します。
Access levelでは「Super Organization Administrator」を指定します。
Access durationでは申請者に最大2時間まで指定をさせたいので「Ask requester to specify expiration」を選択し、Maximum durationを「2 Hours」と指定します。承認フローを設定するため、Approval sequenceでSelect sequenceをクリックします。
事前に用意された承認フローも表示されていますが、ここでは「New sequence」をクリックしてカスタマイズします。
「Trigger」「Approve」「Deliver」のシンプルな構成が表示されています。
TriggerとApproveの間をクリックし、「Questions for Requester」を追加して、申請者に申請理由を入力させるようにします。
Approveをクリックし、Assign toに作成しておいたOktaグループ「Access Request Approver」を指定します。
最後に承認フローに名前をつけて「Save」をクリックします。
作成した承認フローを選択します。
表示されていない場合は「Refresh list」をクリックすると表示されるようになります。
「Create」ボタンをクリックします。
この設定はまだ有効化されていないため、縦の3点リーダー(…)メニューから「Enable」をクリックして有効化します。
これで設定は完了です。
運用上の留意点
API Tokenを発行している場合、そのトークンは発行元アカウントの権限に依存します。今回の仕組みを適用する人が既にAPI Tokenを発行していないか確認し、必要に応じて特定の個人に紐づかない専用アカウントで管理することをお勧めします。
なお、Super Administrator権限を常時保有するアカウントは最低一つ必要となります。このアカウントも個人に紐づかない緊急用Oktaアカウントとして厳重に保管し、利用時には記録が残るようにしておきましょう。アカウント情報はKeeperなどのパスワード管理ツールに保管し、利用した際にはログやWebhook通知を通じて誰が利用したかをSlackなどに自動通知できるようにしておくと、相互監視の観点からより適切な運用が実現できます。
まとめ
この記事ではSuper Administrator権限にフォーカスしましたが、他の権限でも同様に設定することができます。実際には、普段はRead-only Administratorを付与しておき、必要だと判断した時に必要な権限のアクセスリクエストを行えるようにしておくのがバランスが良いでしょう。
このようにOIG機能を活用したオンデマンド型のアクセス権限管理により、セキュリティの向上とコンプライアンスの強化が実現できます。常時権限を付与するのではなく、必要な時だけ一時的に権限を取得できる仕組みは、特権アカウント管理におけるベストプラクティスと言えるでしょう。