GitHub Enterprise で SSO化・ユーザープロビジョニングのために行った課題解決

インフラ GiHub Enterprise 認証 SSO 技術本部

あいさつ

皆様、ごきげんよう。
技術本部 インフラDivの中嶋でございます。

今回は、「GitHub Enterprise で SSO化・ユーザープロビジョニングのために行った課題解決」の話をしたいと考えてます。
アドウェイズではここ1年ほど、各種認証をSSO化するべく動いています。
その中でも今回はGitHub Enterpriseとのプロビジョニング連携をしようとした際に出てきた課題を解決しようとした話になります。

背景

  • 認証基盤の刷新プロジェクトがあった
  • 1年ほど前より認証基盤統一を目指し、新SSO基盤に揃えていく動きが始まり、GitHub Enterpriseもその対象の一つとなった

やったこと

  • 2023 1Q(1月-3月) 認証を新SSO基盤へ移行
  • 2023 2Q(4月-6月) プロビジョニングでユーザ作成(招待)の自動化 ← ココで課題が立ちはだかり、立ち往生

どんな課題があったのか？

最初に直面した課題

当初、Enterprise全体でのプロビジョニングを有効にしようとしていましたが、Enterpriseに属している各OrganizationでSSO設定を行っているため、Enterprise全体でのプロビジョニングを行うにはSSOの設定変更が必要でした。

プロビジョニングの方法としては下記2通り存在（プロビジョニングの範囲＝認証の範囲となる）

  1. Enterprise全体を認証の範囲として認証及びプロビジョニングを行う
  2. 各Organization毎を認証の範囲とし、Organization毎にプロビジョニングを行う

前者のメリットは以下の通りです

  • SSO基盤で利用しているGitHub Enterprise用のグループが１つで済む
  • 今後Organizationが増えた時にもユーザや組織の管理が容易

後者のメリットは以下の通りです

  • Organization毎に認証を有効化するかどうか選択できる

検討の結果、今回はメリットが大きいEnterprise全体でのプロビジョニングを行うために、認証もOrganization毎からEnterprise全体に切り替えるべく進めることとなった。(※のちに、Enterprise全体の認証はできるものの、プロビジョニングは現状不可能と判明。)

SSO強制の課題

SSO強制化をしたくないアカウントが存在するが、SSO強制化は認証組織単位でしかオンオフできない

※前提：会社の意向で、SSO基盤での認証を有効化した場合、SSO強制の有効化は必須

  • SSO強制化による影響
    • SSO経由でのログインのみが許可されるようになる
      • SSO基盤側に紐づくユーザが存在しないとログインができないため、セキュリティの向上に繋がる
  • Enterprise全体での認証有効化を行った上でSSOの強制化をした場合の影響
    • Enterprise配下のすべてのユーザ（Organization内のユーザ含む）はSSOの強制化によりSSO認証を通らないとログインできない
      • GitHubサポートにも問い合わせを行ったが、「個別のアカウントのみをSSO強制化から外す」という機能はGitHubには存在しないという回答だった。

OrganizationまたはEnterprise全体でのSSO強制を有効化した上でプロビジョニングを行うにはシステムアカウントをどう扱うかを決める必要があるということになった。

そもそもシステムアカウントが本当に必要なのか

  • 前提
    • 本件とは別で GitHub → GitHub Enterprise への移行を進めている
    • GitHubでは Circle CI の利用があり、Enterprise への移行が必要
      • ゆくゆくは GitHub Actions へリプレイス予定だが、現時点はそのままの状態で移行したい
  • システムアカウントが必要な理由
    • Circle CI と GitHub Enterprise を連携するために Owner アカウントでの連携が必要

Owner アカウント紐づけ方法

  • 個人の社員アカウント（GitHubEnterpriseの管理者）を紐付ける
    • 個人に紐づけた際のデメリット：連携の管理がその人にしかできなくなる(属人化)　紐づけた個人が、会社のクレカ情報まで見えてしまう
  • システムユーザを GitHub 上に作成して、その作成したユーザを紐付ける
    • システムユーザに紐づけた際のデメリット：SSO の強制ができなくなる

※上で説明の通り、Enterprise全体　or　Organization全体でのSSO強制化が無効になるため、セキュリティリスクが大きい状態での運用となってしまう

SSO基盤側でのシステムアカウント作成について

  • SSO基盤では原則、システムアカウントを作成する運用は行っていない。
    • 入退社処理から漏れる可能性が高い。
    • システムアカウントだらけになってしまうと管理しきれない可能性が高い。

今回はSSO強制の設定がらみなどで必要となったため、特例でSSO基盤側にシステムアカウントを作成することとなった。

解決するための案

マネージャーと話す際に出した案はこんな感じでした。

  • 案1: 一旦静観して、 Circle CI が GitHub Actions に移行するまで待つ
    • 該当のOrganizationにてSSO強制ができない期間が発生する
    • CircleCIの移行が完了するまでの期間の目途が見えていない
  • 案2: Enterprise 全体で認証する
    • やり方1: SSO基盤にシステムユーザーを作成する ← 今回はこちらの案で決定
      • SSO基盤にシステムユーザを作成した前例がない
    • やり方2: （社員の）Owner アカウントで連携を行う
      • 俗人化・クレカ問題有 (※上記記載)
  • 案3: 対象の Organization のみSSO強制しない
    • 対象Organizationのみセキュリティリスクが発生

今回は 案2.やり方1の「Enterprise 全体で認証し、SSO基盤にシステムユーザーを作成する」を採用しました。

大変だった、苦労した点

GitHub の仕様の理解に苦しみました。

  • 実際に触ってみての検証(わからないことだらけ)
  • GitHub には派生系が多く、必要な情報が一発で取得できない、余計な情報がヒットしてしまう
  • GitHub 特有の仕様（Enterprise 認証、Organization 認証など）を知るのに時間がかかった
    • GitHubの営業の方やサポートの方にもお問い合わせした
  • 独特な思想：人のアカウントのみでの運用が前提、SSO強制化の除外設定ができない ...など

プロビジョニングの有効化に至るまでに色々な課題が立ちはだかりました。

  • Enterprise でプロビジョニングする？ Organization でプロビジョニングする？
  • 自分自身でも最初、何が必要でどんな問題が～という部分が正確に整理できていなかった

まとめ

最初はプロビジョニングをしたかっただけなのに、そのためにはEnterprise全体での認証を考えたり
さらにはEnterpriseレベルでのプロビジョニングが対応していない等の問題が出てきたり・・・
SSO強制化の仕様を知らなければいけなく、さらにそのためには
そもそもシステムアカウントが必要かどうかの部分から検討しなければならず
RPGゲームのおつかいクエストをずっとやってる感覚でした。

今回の記事の中では途中のやり取りや時系列などは記載していませんが
当初は1か月ちょっと(5月中旬目途)で完了までもっていく予定だったものが
調査や情報収取・検証などに時間がかかってしまい
やっと今終わりが見えてきた状態となりました。

最終的にマネージャー数名を相手に方針を決める会議を開催するまで至り
それまでの準備や調査など大変でしたが、問題を先送りにせず今このタイミングで
理想的なゴールまで持っていけたのは本当によかったと思っています。

GitHubのようにシステムユーザでの運用をしない前提で
提供されているSaaSは他にもありますし、
今後の皆さんの方針決定の参考になれば幸いです。