Upgrade to Pro — share decks privately, control downloads, hide ads and more …

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

shimosyan
April 27, 2022

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

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

shimosyan

April 27, 2022
Tweet

More Decks by shimosyan

Other Decks in Technology

Transcript

  1. Okta のグループ運用を
    軽くするためにやったこと
    2022.04.27
    第3回 Okta 勉強会
    しもしゃん @shimosyan
    1

    View full-size slide

  2. アジェンダ
    1. 自己紹介
    2. 【おさらい】Okta のグループでできること
    3. グループの設計・運用でやめたこと
    4. グループの設計・運用でやったこと
    5. グループの命名規則
    6. Okta に期待したいこと
    7. まとめ
    2

    View full-size slide

  3. 3
    自己紹介

    View full-size slide

  4. 自己紹介
    しもしゃん
    Corporate Engineer at Chatwork Co., Ltd.
    4
    Twitter / GitHub
    @shimosyan
    スキル
    ● Okta
    ● Jamf Pro
    ● Serverless Architecture
    ● Network Engineering
    趣味
    ● DTM
    ● 自作PC
    最近の取り組んでいること
    ● 家を建てるために奔走中
    ポートフォリオ https://shimosyan.github.io/

    View full-size slide

  5. 5
    【おさらい】
    Okta のグループでできること

    View full-size slide

  6. 6
    ここでは以下の2つにフォーカスします
    Okta
    Group
    Okta
    Group
    Group Group
    Application
    グループ単位でアクセス権を付与して
    SSO できるようにしたり…
    グループそのものを Application へ同期したり…
    主にアプリケーションへの Assignments と
    Push Groups の2つではないでしょうか?
    今回は、このアプリケーション設定に割り当てる
    グループの設計のことをお話します。
    Assignments
    Push Group

    View full-size slide

  7. 7
    グループの設計・運用で
    やめたこと

    View full-size slide

  8. 8
    変化に弱い構成
    Application
    部署:
    人事総務部
    雇用:正社員
    人事
    総務部
    部署:開発部
    雇用:正社員
    正社員
    人事総務部用
    権限設定
    正社員用
    権限設定
    Okta
    例えば、Data へのアクセス制限を実現する構成として、このような構成があります。
    Okta 導入前では、アクセス権限の設定は「人事総務部用」や「正社員用」など直感でわかりやすい権限構成で Application 側のみで完結してい
    ました。
    ここで Okta を導入してプロビジョニングを実現し、ユーザーや権限設定の起点をそのまま Okta に移植してくると図のようになります。
    しかし、もし組織変更で「人事総務部」が「人事部」と「総務部」に分割され、システムの修正が必要になると何が起きるでしょうか?
    人事総務部用
    ルール
    User Group
    正社員用
    ルール
    Group Rule
    社外秘情報
    (正社員のみアクセス可能)
    ユーザーが人事総務部所属なら
    「人事総務部」グループに割り当てる
    ユーザーが正社員なら
    「正社員」グループに割り当てる
    ← 連携 →
    ← 連携 →
    ※Okta の「人事総務部」グループに割り当てられると、
    Application の「人事情報」にアクセスできるようになる
    人事情報
    (人事総務部のみアクセス可能)
    Data

    View full-size slide

  9. 9
    変化に弱い構成
    Application
    部署:
    人事総務部
    雇用:正社員
    人事
    総務部
    部署:開発部
    雇用:正社員
    正社員
    人事総務部用
    権限設定
    正社員用
    権限設定
    Okta
    少なくとも、赤枠で囲った範囲は「人事部」・「総務部」用にシステムの修正、アクセス権限の要件の再整理が必要になります。この変更には
    かなりのリソースが必要です。
    組織がある程度大きくなってくると、権限委譲などによりこのような大規模な組織変更が頻繁に行われるようになります。この構成のままで
    は、情シスのリソースがいくつあっても足りません。
    人事総務部用
    ルール
    User Group
    正社員用
    ルール
    Group Rule
    社外秘情報
    (正社員のみアクセス可能)
    ユーザーが人事総務部所属なら
    「人事総務部」グループに割り当てる
    ユーザーが正社員なら
    「正社員」グループに割り当てる
    ← 連携 →
    ← 連携 →
    人事情報
    (人事総務部のみアクセス可能)
    Data

    View full-size slide

  10. 10
    グループの設計・運用で
    やったこと

    View full-size slide

  11. 11
    改善した構成
    Application
    部署:
    人事総務部
    雇用:正社員
    人事情報
    編集可能
    部署:開発部
    雇用:正社員
    社外秘
    閲覧可能
    人事情報編集用
    権限設定
    社外秘閲覧用
    権限設定
    人事情報
    (Okta側の制御により、実質
    人事総務部のみアクセス可能)
    Okta
    先の問題点の改善がこちらです。
    Data へのアクセスに必要な権限を「〇〇部の人」や「正社員の人」など具体的な設定ではなく、「〇〇が編集/閲覧できる人」のような抽象的
    な設定にし、緑枠で囲った箇所の設定を置き換えます。
    例えば上記の図なら、「人事総務部の人のグループ」→「人事情報が編集できる人のグループ」、「正社員の人のグループ」→「社外秘を閲覧
    できる人のグループ」と置き換えています。
    人事総務部用
    ルール
    User Group
    正社員用
    ルール
    Group Rule
    社外秘情報
    (Okta側の制御により、実質
    正社員のみアクセス可能)
    ユーザーが人事総務部所属なら
    「人事情報編集可能」グループに割り当てる
    ユーザーが正社員なら
    「社外秘閲覧可能」グループに割り当てる
    ← 連携 →
    ← 連携 →
    Data
    抽象化した箇所

    View full-size slide

  12. 12
    改善した構成
    Application
    部署:
    人事総務部
    雇用:正社員
    人事情報
    編集可能
    部署:開発部
    雇用:正社員
    社外秘
    閲覧可能
    人事情報編集用
    権限設定
    社外秘閲覧用
    権限設定
    人事情報
    (Okta側の制御により、実質
    人事総務部のみアクセス可能)
    Okta
    これにより、先の問題点と同じシチュエーションで「人事総務部」が「人事部」と「総務部」に分割されたとしても、変更しなければならない
    赤枠の範囲を大幅に抑えることができます。
    図のように、ユーザーのプロフィール情報と Group Rule だけの保守で済むことができ、抽象化した箇所は修正の必要性がありません。
    このように、権限を抽象化することで Okta と Application 異なるシステム間の連携において変化に強いシステムを実現することができます。
    人事総務部用
    ルール
    User Group
    正社員用
    ルール
    Group Rule
    社外秘情報
    (Okta側の制御により、実質
    正社員のみアクセス可能)
    ユーザーが人事総務部所属なら
    「人事情報編集可能」グループに割り当てる
    ユーザーが正社員なら
    「社外秘閲覧可能」グループに割り当てる
    ← 連携 →
    ← 連携 →
    Data
    抽象化した箇所

    View full-size slide

  13. 13
    グループの命名規則

    View full-size slide

  14. 14
    グループ機能が抱える問題点
    ① グループがネスト(階層)に対応し
    ていない
    ③ フィルタ機能が「前方一致」しか対
    応していない
    ④ 一覧に表示できるのは200件まで
    フラットな階層で大量のグループを管
    理する必要がある
    ② プロビジョニングを有効にした場合、連携
    先サービスの全グループも一覧に表示される
    膨大なグループから、的確に目的の
    グループを探せるようにするための工
    夫が必要

    View full-size slide

  15. 15
    グループの命名規則の例
    ② App_GWS_Group_組織A
    ① App_MS365_Login_GlobalAdmin
    グループの大カテゴリ
    - App:アプリケーション連携グループ用
    - Dep:部署グループ用
    - Emp:雇用区分グループ用
    - などなど
    アプリケーション名
    (カテゴリがAppのみ)
    連携させるアプリケーション名
    グループ名には文字数制限があるので略称を使い
    がち
    ③ Dep_人事部
    アプリケーション連携グループ向け小カテゴリ
    (カテゴリがAppのみ)
    - Login:Assignments用
    - Group:Group Push用
    LoginとGroup、用途が重なったらLoginを優先
    任意の文字列
    グループを区別したいときに名前をつけたりする
    のはここ

    View full-size slide

  16. 16
    Okta に期待したいこと

    View full-size slide

  17. Okta に期待したいこと
    ユーザーやグループのフィルタ機能、
    もう少し使いやすくなって欲しい
    (運用回らなくなってきたので Terraform を使ってコード管理しています)
    あと、Okta Identity Engine 早く使いたいです!!
    17

    View full-size slide

  18. まとめ
    19
    ● グループや権限管理は、設計を工夫して抽象化を取り入れてみ
    たりすると、それだけで運用保守性が上がる!
    ○ 今回は RBAC(Roll Based Access Control)を取り入れました。
    ○ RBAC の発展形に ABAC(Attribute Based Access Control)があります。
    (RBAC に加えて、ユーザーの「場所」や「時刻」を権限の評価に取り入れる概念)
    今回の発表では、権限の抽象化を実現しているので将来的に ABAC への対応
    も容易になっていると思います。

    View full-size slide

  19. ご静聴
    ありがとうございました
    20

    View full-size slide