Okta のグループ運用を軽くするためにやったこと

第3回 Okta 勉強会 で発表した内容です
https://okta.connpass.com/event/244426/

Transcript

1. Okta のグループ運用を 軽くするためにやったこと 2022.04.27 第3回 Okta 勉強会 しもしゃん @shimosyan 1
2. アジェンダ 1. 自己紹介 2. 【おさらい】Okta のグループでできること 3. グループの設計・運用でやめたこと 4. グループの設計・運用でやったこと 5. グループの命名規則 6. Okta に期待したいこと 7. まとめ 2
3. 3 自己紹介
4. 自己紹介 しもしゃん Corporate Engineer at Chatwork Co., Ltd. 4 Twitter / GitHub @shimosyan スキル • Okta • Jamf Pro • Serverless Architecture • Network Engineering 趣味 • DTM • 自作PC 最近の取り組んでいること • 家を建てるために奔走中 ポートフォリオ https://shimosyan.github.io/
5. 5 【おさらい】 Okta のグループでできること
6. 6 ここでは以下の2つにフォーカスします Okta Group Okta Group Group Group Application グループ単位でアクセス権を付与して SSO できるようにしたり… グループそのものを Application へ同期したり… 主にアプリケーションへの Assignments と Push Groups の2つではないでしょうか？ 今回は、このアプリケーション設定に割り当てる グループの設計のことをお話します。 Assignments Push Group
7. 7 グループの設計・運用で やめたこと
8. 8 変化に弱い構成 Application 部署： 人事総務部 雇用：正社員 人事 総務部 部署：開発部 雇用：正社員 正社員 人事総務部用 権限設定 正社員用 権限設定 Okta 例えば、Data へのアクセス制限を実現する構成として、このような構成があります。 Okta 導入前では、アクセス権限の設定は「人事総務部用」や「正社員用」など直感でわかりやすい権限構成で Application 側のみで完結してい ました。 ここで Okta を導入してプロビジョニングを実現し、ユーザーや権限設定の起点をそのまま Okta に移植してくると図のようになります。 しかし、もし組織変更で「人事総務部」が「人事部」と「総務部」に分割され、システムの修正が必要になると何が起きるでしょうか？ 人事総務部用 ルール User Group 正社員用 ルール Group Rule 社外秘情報 （正社員のみアクセス可能） ユーザーが人事総務部所属なら 「人事総務部」グループに割り当てる ユーザーが正社員なら 「正社員」グループに割り当てる ← 連携 → ← 連携 → ※Okta の「人事総務部」グループに割り当てられると、 Application の「人事情報」にアクセスできるようになる 人事情報 （人事総務部のみアクセス可能） Data
9. 9 変化に弱い構成 Application 部署： 人事総務部 雇用：正社員 人事 総務部 部署：開発部 雇用：正社員 正社員 人事総務部用 権限設定 正社員用 権限設定 Okta 少なくとも、赤枠で囲った範囲は「人事部」・「総務部」用にシステムの修正、アクセス権限の要件の再整理が必要になります。この変更には かなりのリソースが必要です。 組織がある程度大きくなってくると、権限委譲などによりこのような大規模な組織変更が頻繁に行われるようになります。この構成のままで は、情シスのリソースがいくつあっても足りません。 人事総務部用 ルール User Group 正社員用 ルール Group Rule 社外秘情報 （正社員のみアクセス可能） ユーザーが人事総務部所属なら 「人事総務部」グループに割り当てる ユーザーが正社員なら 「正社員」グループに割り当てる ← 連携 → ← 連携 → 人事情報 （人事総務部のみアクセス可能） Data
10. 10 グループの設計・運用で やったこと
11. 11 改善した構成 Application 部署： 人事総務部 雇用：正社員 人事情報 編集可能 部署：開発部 雇用：正社員 社外秘 閲覧可能 人事情報編集用 権限設定 社外秘閲覧用 権限設定 人事情報 （Okta側の制御により、実質 人事総務部のみアクセス可能） Okta 先の問題点の改善がこちらです。 Data へのアクセスに必要な権限を「〇〇部の人」や「正社員の人」など具体的な設定ではなく、「〇〇が編集/閲覧できる人」のような抽象的 な設定にし、緑枠で囲った箇所の設定を置き換えます。 例えば上記の図なら、「人事総務部の人のグループ」→「人事情報が編集できる人のグループ」、「正社員の人のグループ」→「社外秘を閲覧 できる人のグループ」と置き換えています。 人事総務部用 ルール User Group 正社員用 ルール Group Rule 社外秘情報 （Okta側の制御により、実質 正社員のみアクセス可能） ユーザーが人事総務部所属なら 「人事情報編集可能」グループに割り当てる ユーザーが正社員なら 「社外秘閲覧可能」グループに割り当てる ← 連携 → ← 連携 → Data 抽象化した箇所
12. 12 改善した構成 Application 部署： 人事総務部 雇用：正社員 人事情報 編集可能 部署：開発部 雇用：正社員 社外秘 閲覧可能 人事情報編集用 権限設定 社外秘閲覧用 権限設定 人事情報 （Okta側の制御により、実質 人事総務部のみアクセス可能） Okta これにより、先の問題点と同じシチュエーションで「人事総務部」が「人事部」と「総務部」に分割されたとしても、変更しなければならない 赤枠の範囲を大幅に抑えることができます。 図のように、ユーザーのプロフィール情報と Group Rule だけの保守で済むことができ、抽象化した箇所は修正の必要性がありません。 このように、権限を抽象化することで Okta と Application 異なるシステム間の連携において変化に強いシステムを実現することができます。 人事総務部用 ルール User Group 正社員用 ルール Group Rule 社外秘情報 （Okta側の制御により、実質 正社員のみアクセス可能） ユーザーが人事総務部所属なら 「人事情報編集可能」グループに割り当てる ユーザーが正社員なら 「社外秘閲覧可能」グループに割り当てる ← 連携 → ← 連携 → Data 抽象化した箇所
13. 13 グループの命名規則
14. 14 グループ機能が抱える問題点 ① グループがネスト（階層）に対応し ていない ③ フィルタ機能が「前方一致」しか対 応していない ④ 一覧に表示できるのは200件まで フラットな階層で大量のグループを管 理する必要がある ② プロビジョニングを有効にした場合、連携 先サービスの全グループも一覧に表示される 膨大なグループから、的確に目的の グループを探せるようにするための工 夫が必要
15. 15 グループの命名規則の例 ② App_GWS_Group_組織A ① App_MS365_Login_GlobalAdmin グループの大カテゴリ - App：アプリケーション連携グループ用 - Dep：部署グループ用 - Emp：雇用区分グループ用 - などなど アプリケーション名 （カテゴリがAppのみ） 連携させるアプリケーション名 グループ名には文字数制限があるので略称を使い がち ③ Dep_人事部 アプリケーション連携グループ向け小カテゴリ （カテゴリがAppのみ） - Login：Assignments用 - Group：Group Push用 LoginとGroup、用途が重なったらLoginを優先 任意の文字列 グループを区別したいときに名前をつけたりする のはここ
16. 16 Okta に期待したいこと
17. Okta に期待したいこと ユーザーやグループのフィルタ機能、 もう少し使いやすくなって欲しい （運用回らなくなってきたので Terraform を使ってコード管理しています） あと、Okta Identity Engine 早く使いたいです！！ 17
18. 18 まとめ
19. まとめ 19 • グループや権限管理は、設計を工夫して抽象化を取り入れてみ たりすると、それだけで運用保守性が上がる！ ◦ 今回は RBAC（Roll Based Access Control）を取り入れました。 ◦ RBAC の発展形に ABAC（Attribute Based Access Control）があります。 （RBAC に加えて、ユーザーの「場所」や「時刻」を権限の評価に取り入れる概念） 今回の発表では、権限の抽象化を実現しているので将来的に ABAC への対応 も容易になっていると思います。
20. ご静聴 ありがとうございました 20