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

Oktaの管理者権限を適切に移譲してみた

shimosyan
January 23, 2023

 Oktaの管理者権限を適切に移譲してみた

shimosyan

January 23, 2023
Tweet

More Decks by shimosyan

Other Decks in Technology

Transcript

  1. 自己紹介 4 しもしゃん Corporate Engineer at Chatwork Co., Ltd. Twitter

    / GitHub @shimosyan スキル • Okta • Jamf Pro • Serverless Architecture • Network Engineering 趣味 • DTM • 自作PC ポートフォリオ https://shimosyan.github.io/
  2. Chatworkとは 8 ※Nielsen NetView 及びNielsen Mobile NetView Customized Report 2022年5月度調べ月次利用者(

    MAU:Monthly Active User)調査。※調査対象は Chatwork、Microsoft Teams、Slack、LINE WORKS、Skypeを含む47サービスを Chatwork株式会社にて選定。 効率的に情報共有できる グループチャット 仕事の見える化ができる タスク管理 見落としがなくなる ファイル管理 いつでも会議ができる ビデオ/音声通話
  3. Chatworkは利用者数No.1*のビジネスチャット 9 * Nielsen NetView 及びNielsen Mobile NetView Customized Report

    2022年5月度調べ月次利用者(MAU:Monthly Active User)調査。調査対象はChatwork、Microsoft Teams、Slack、LINE WORKS、Skypeを含む47サービスを Chatwork株式会社にて選定。 3月 リリース 10万社 突破! 20万社 突破! 30万社 突破! 導入社数 37万6000社以上! (2022年9月末日時点)
  4. IdP とクラウドサービスの連携における課題とは 11 SaaS IDaaS IdP 管理者 権限 IdP とクラウドサービスの管理者が同じパターン

    管理者が同じときの良いこと • シングルサインオン(SSO) の設定 をするとき、IDaaS を始めとする Identity Provider(IdP)と Service Provider(SaaS 等のクラウドサービ ス)の両方の管理画面にアクセスでき るため設定が楽。 • 単一で完結するため、情シスの都合の いいタイミングで導入できる。 • 導入後も新規利用者のアカウント作成 ・IdP の割り当て作業がやりやすい。 情シス担当者 SAML・OIDC
  5. IdP とクラウドサービスの連携における課題とは 12 SaaS IDaaS IdP 管理者 権限 一方、IdP とクラウドサービスの管理者が異なるパターン

    管理者が異なると… • お互いの管轄するサービスの管理画面 に入れないため、それぞれの作業内容 がわからない。 • 設定値の交換のためにコミュニケー ションが発生する。 • 導入の際にお互いの作業タイミングを 合わせる必要がある。 • 導入後も新規利用者のアカウント作成 と IdP の割り当て作業が別作業とな るため非効率。 管理者 権限 事業部門担当者 情シス担当者 SAML・OIDC 連携が必要
  6. IdP とクラウドサービスの連携における課題とは 13 SaaS IDaaS IdP 管理者 権限 一方、IdP とクラウドサービスの管理者が異なるパターン

    管理者が異なると… • お互いの管轄するサービスの管理画面 に入れないため、それぞれの作業内容 がわからない。 • 設定値の交換のためにコミュニケー ションが発生する。 • 導入の際にタイミングを合わせる必要 がある。 • 導入後も新規利用者のアカウント作成 と IdP の割り当て作業が別作業とな るため非効率。 管理者 権限 事業部門担当者 情シス担当者 SAML・OIDC これのいずれかで齟齬があると、利用者が ログインできなくなりサービスが利用できな くなる恐れ 連携不十分
  7. IdP とクラウドサービスの連携における課題とは 15 SaaS IDaaS IdP 管理者 権限 今日ご紹介する解決アプローチ 今回ご紹介するのは

    Okta の管理者権限 を移譲することによって、事業部門担当 者が最小限の権限で運用または実装が実 施できるようにする方法です。 Chatwork で実施した実例を交えながら ご紹介しようと思います。 事業部門担当者 情シス担当者 SAML・OIDC 移譲 管理者 権限
  8. IdP の権限設定を使った解決アプローチ 17 Okta には Okta Identity Engine と Okta

    Classic Engine と2つのバージョンがあり、利用者によってど ちらかのバージョンが利用できます。 これから説明することは、両方のバージョンで設定できることを確認しています。 お知らせ
  9. IdP の権限設定を使った解決アプローチ 19 事業部門担当者 情シス担当者 管理者 権限 Chatwork ではこのように役割を定義しています。 このパターンでは事業部の担当者が

    SSO の設定も自力で実施でき運用も可能という最も多くの権限を移 譲します。 事業部の役割 ・ SSOの設定 ・ ユーザーへの利用権限付与 情シスの役割 ・ ユーザーアカウントの管理 ・ 管理者権限を移譲する人の任命
  10. IdP の権限設定を使った解決アプローチ 20 一方、事業部の担当者が SSO の知識がなく自力での設定が難しい場合は情シスが設定を実施することが あります。 情シスの役割 ・ ユーザーアカウントの管理

    ・ 管理者権限を移譲する人の任命 ・ SSOの設定 事業部の役割 ・ SSOの設定 ・ ユーザーへの利用権限付与 事業部門担当者 情シス担当者 管理者 権限
  11. IdP の権限設定を使った解決アプローチ 21 SSOの設定 ユーザーへの利用権限付与 Application Administrator Group Membership Administrator

    https://help.okta.com/oie/ja-jp/Content/Topics/Security/administrators-admin-comparison.htm Okta の管理者権限はある操作できる権限がある程度定まっているプリセットが用意されてお り、そのうち上記の Application Administrator と Group Membership Administrator の2つ を使うことで、権限を移譲することができます。 これらはユーザーごと、グループごとに付与することができます。
  12. IdP の権限設定を使った解決アプローチ 22 SSOの設定 ユーザーへの利用権限付与 Application Administrator Group Membership Administrator

    詳細は後ほど説明しますが、アプリケーションの利用ユーザーへの利用権限付与には Okta で ユーザーをまとめることができるグループを使用します。 グループを使うことで設定実現の自由度が上がります。
  13. IdP の権限設定を使った解決アプローチ 24 SSO 設定の実施 利用権限割り当て 管理者グループ 利用者グループ SSO 設定可能な

    管理者グループ 事業部門担当者 情シス担当者 メンバー管理 SSO 設定 利用者 所属 所属 担当者を 割り当て 利用権限の付与 SAML 設定 SSOして利用 具体的なイメージ図 Group Menbership Administrator を付与 • 情シス担当者は、管理される利用者グ ループと SSO 設定は設定が空っぽな 箱のみ作成します。 • 2つの管理者グループを作成し、それ ぞれに先ほど紹介した Okta の管理者 権限を付与しています。 • 事業部門担当者を上記管理者グループ に割り当てます。そうすることで、利 用者グループと SSO 設定の管理が可 能になります。 Application Administrator を付与
  14. IdP の権限設定を使った解決アプローチ 25 SSO 設定の実施 利用権限割り当て 管理者グループ 利用者グループ SSO 設定可能な

    管理者グループ 事業部門担当者 情シス担当者 メンバー管理 SSO 設定 利用者 所属 所属 担当者を 割り当て 利用権限の付与 SAML 設定 SSOして利用 Group Menbership Administrator を付与 なお、SSO 設定については対象のアプリ ケーションが Okta Integration Network (OIN) と呼ばれるカタログに登録されてい る場合は、SSO 設定の箱を用意せずに 「OINからアプリの作成・編集」できる権 限を渡すことが可能です。 サンドボックス環境など、複数環境を持っ ている場合はこの方法が有効です。 Application Administrator を付与
  15. IdP の権限設定を使った解決アプローチ 26 できないこと グループA グループAを 管理できる権限を 持ったグループB グループBを 管理できる権限を

    持ったグループC メンバー管理 できない メンバー管理 できる ここで注意点があります。 図のように、グループメンバーの管理について2重にして「管理者の割り当ても委譲したい」と考えるかも しれません。しかし、 Okta ではこれを設定することができません。 これは Okta の仕様により「権限を持っているグループへの割り当ては特権管理者(Super Administrator)しか設定できない」という制約が入っているためです。 そのため、管理者グループへの割り当ては特権管理者である情シスが実施する必要があります。 https://help.okta.com/oie/ja-jp/Content/Topics/Security/administrators-admin-comparison.htm
  16. Chatwork における活用事例 28 SSO 設定の実施 利用権限割り当て 管理者グループ 利用者グループ SSO 設定可能な

    管理者グループ 事業部門担当者 情シス担当者 メンバー管理 SSO 設定 利用者 所属 所属 担当者を 割り当て 利用権限の付与 SAML 設定 SSOして利用 Group Menbership Administrator を付与 Chatwork ではこれを基本としてユース ケースごとにアレンジを加えて運用してい ます。 ここからはそれらアレンジ例と、いくつか 実際に導入している例を挙げてご紹介しま す。 Application Administrator を付与
  17. Chatwork における活用事例 29 メンバー管理者権限のみを渡して、SSO の設定は情シスがおこなうパターン 利用権限割り当て 管理者グループ 利用者グループ 事業部門担当者 情シス担当者

    メンバー管理 SSO 設定 利用者 所属 所属 担当者を 割り当て 利用権限の付与 SAML 設定 SSOして利用 Group Menbership Administrator を付与 SSO 設定の実施 SSO のみ 情シスが設定
  18. Chatwork における活用事例 30 メンバー管理を Okta Group Rule による自動化と併用するパターン SSO 設定の実施

    利用権限割り当て 管理者グループ 利用者グループ SSO 設定可能な 管理者グループ 事業部門担当者 情シス担当者 自動追加されない分だけ メンバー管理 SSO 設定 利用者 所属 所属 担当者を 割り当て 利用権限の付与 SAML 設定 SSOして利用 Group Menbership Administrator を付与 Application Administrator を付与 Okta Group Rule Rule にマッチした ユーザーを自動で追加 ※情シス管理 「〇〇部に所属しているユーザー を自動で特定のグループに割り当 てる」という動作が仕込まれた Group Rule
  19. Chatwork における活用事例 31 事例: Salesforce SSO 設定 SSO 設定 SAML

    設定 利用者 グループ 利用者 アプリ管理 者グループ SAML 設定 Salesforce システム担当者 利用権限管理 者グループ 情シス担当者 担当者を 割り当て 社内のSalesforceの事例です。 Salesforce環境がいくつかあるとのことな ので、Salesforce用の設定を何個でも作成 できる権限を付与しました。
  20. Chatwork における活用事例 32 事例: AWS SSO(一部抜粋) SSO 設定 SRE利用者 グループ

    SRE管理者 グループ アプリ管理 者グループ SRE部MGR SRE部メンバー 所属 所属 熟練メンバーの み所属 SSO 設定の実施 SAML 設定 情シス担当者 部署A管理 者グループ 部署A利用 者グループ メンバー管理 A部MGR A部メンバー 所属 所属 メンバー管理 AWS 部署B管理 者グループ 部署B利用 者グループ B部MGR B部メンバー 所属 自動追加されない 業務委託だけメンバー管理 利用権限の付与 Okta Group Rule 業務委託 所属 Rule にマッチした ユーザーを自動で追加 条件:B部に所属している ユーザー ※情シス管理 各管理者用グループに ユーザーを割り当て 設定が膨大だったので抜粋です。社内のSREチームが主 導で進めてくれたAWS SSOの事例となります。 最初の設計のときにアドバイスをしただけで殆どはSRE が設計をまとめていました。