全社的に会社用GitHubアカウントを廃止した件

GitHub

はじめまして。2019年1月に入社したSREスペシャリストのsonotsです。最近MLOpsチームのリーダーになりました。今回の記事はMLOpsの業務とは関係がないのですが、3月に弊社で実施した会社用GitHub個人アカウントの廃止について事例報告します。

TL;DR

  1. 個人で会社用と私用の2つの無料GitHubアカウントを持つことはGitHubの規約「非」準拠だった
  2. 会社用GitHubアカウントを廃止し私用GitHubアカウントを利用する規定に変更した
  3. セキュリティを担保するためGitHubのSSO機能を利用した

(2023-05-17 追記)
「現在は複数アカウントの作成は問題ないのではないか」という旨のご質問をいただきましたので、改めてGitHub社に確認しました。返答としては、複数の「無料」アカウント作成は記事公開時から変わらずNGであるとのことでした。
一方、現在ではEnterprise Managed Users(略称EMU)という機能がリリースされており、こちらを利用することで無料アカウントとは別の会社用アカウントを保持することができるようになっています。 EMUは本記事を公開後にリリースされた、会社のIdPと紐付いた、会社のEnterprise Account下のOrganizationにのみ書き込み権限を持つユーザーアカウントを作成できる機能です。EMUの規約にはユーザーアカウント保有数の制限は設けられていないことから、規約上の問題を回避できます。EMUについては興味をお持ちの方はオフィシャルのThe GitHub Blogの記事を参照してください。
(2023-05-17 追記ここまで)

会社用GitHubアカウントを作るべきか否か問題

会社で github.com ビジネスプランを利用するにあたって、会社用に新たにGitHubアカウントを作るかどうかは各社それぞれ悩んでいるポイントだと思います。

弊社ZOZOテクノロジーズは1年ほど前に github.com のビジネスプランを導入した際に、「会社用に新たにGitHubアカウントを作る」方針で運用をはじめました。

私用GitHubアカウントで会社リポジトリにアクセスできてしまうと、私用PCを紛失・盗難された場合に会社のソースコードが漏洩してしまうリスクがあるためです。 私用PCは会社で管理しておらず、セキュリティ強度が低い可能性が高いため、この時点では私用GitHubアカウントで会社リポジトリにアクセスすることを許可できませんでした。

会社用GitHubアカウントの利用で抱えた問題

そのような理由があり「会社用に新たにGitHubアカウントを作る」運用にしていたのですが、以下のような問題が出てきました。

  1. OSS活動時にアカウントを切り替える必要があり面倒
  2. GitHubの規約に準拠していない

1. OSS活動時にアカウントを切り替える必要があり面倒

現在ZOZOテクノロジーズでは外部への発表やOSS貢献が推奨されています。また入社以前からOSS活動をしていた社員が（私を含め）増えてきています。業務の一環としてOSS開発を行うこともあります。

会社リポジトリにアクセスする際は会社用GitHubアカウントを使い、OSS活動をする際は継続して私用GitHubアカウントを使いたい要求があり、切り替えに煩わしさがありました。

個人的にもブラウザのマルチユーザ機能を使ったり、作業中のリポジトリ名を取得して自動でSSH鍵を切り替える仕組みを作って、煩わしさを軽減させる努力はしました。 しかし、それでも煩わしさは完全には消せませんでした。

私は情シスのメンバーではなかったのですが、本案件を主導した動機として、この問題が大きく関わっています。

2. GitHubの規約に準拠していない

GitHubの規約に準拠していないというのは以下の文です。https://help.github.com/en/articles/github-terms-of-service

One person or legal entity may maintain no more than one free Account (if you choose to control a machine account as well, that's fine, but it can only be used for running a machine).

個人で2つ以上の無料GitHubアカウントを保持してはいけないと記載されています。

この件についてビジネスプランで契約している場合はどうなるのか、GitHub社のソリューションエンジニアであるikeike443氏に確認していただきました。 会社用に新たに作成したアカウントは有料GitHub組織に所属しているが、そのアカウント自体は無料アカウントであるため、この規約に準拠していないと返事をいただきました。またGitHubというサービス自体マルチアカウントで使うような設計になっていないため、GitHub社としてはアカウントの一本化を推奨するとのことでした。

1年前にビジネスプランを導入した際にはこの規約についての認識が不足しており、GitHub社の規約に準拠していない社内運用ルールになっていました。規約に準拠していない運用を行なっているのは、企業としてあるべき姿ではないため、GitHub社に相談し会社用GitHubアカウントの廃止の検討を始めました。

また他社事例に詳しい、とある著名フリーランスエンジニアの方からも、同様の理由から各社で会社用GitHubアカウントの廃止を進言してきたとの情報をいただいたことも後押しになりました。

会社用アカウントを廃止した場合にセキュリティをどのように担保するか

会社用GitHubアカウントを廃止する場合、元々懸念していたように、セキュリティ強度が落ちる可能性があります。

そこで、ikeike443氏にアドバイスを受けたところ、SSO機能を使うことでセキュリティ強度を（ある程度）担保できることがわかりました。

現在の弊社では社内システムのSSO化も進めており、以前と違いSSO機能を使うことができるようになりました。この機能によりセキュリティ強度を担保できることがわかったため、会社用GitHubアカウントの廃止を決断しました。

焦点となった、GitHubのSSO機能について簡単に説明します。

GitHubのSAML single sign-on (SSO)機能について

公式ドキュメントはAbout authentication with SAML single sign-on - GitHub Helpにあります。

ビジネスプランに入っているGitHub組織の管理者は、GitHub組織の設定画面からSSO機能を有効化することで、会社の認証基盤とSAML連携したSSOを要求できます。

GitHub組織のSAML連携設定が行うと、一般ユーザがウェブブラウザからGitHubの対象組織にアクセスすると、上部に以下のようなSSO認証を促す警告が表示されるようになります。またhttps://github.com/orgs/組織名/ssoのようなURLが発行されるので、そのリンクを踏むことでもSSO認証できます。

GitHub組織の管理者は、GitHub組織のSSO連携の設定画面で、SSO認証を強制することもできます。この機能を有効化すると、SSO認証を有効にしていない組織Memberが全員組織から排除されます。組織のOutside Collaboratorには影響がありません。

そして、ここが重要な点なのですが、一般ユーザが会社リポジトリにGitアクセスする際のSSH鍵に対してもSSOが要求されます。 公式ドキュメントは Authorizing an SSH key for use with a SAML single sign-on organization - GitHub Help にあります。個人のSSH鍵設定画面 https://github.com/settings/keys から、Enable SSOしてSSO認証することで会社リポジトリをgit cloneできるようになります。

  1. 会社PCにはSSO有効化したSSH鍵をおく
  2. 私用PCにはSSO有効化していないSSH鍵をおく

という運用ルールにすることで、私用PCを紛失・盗難された場合でも私用PCからは会社リポジトリにはGitアクセスできないため、リスクを減らすことができました。これにより、会社用GitHubアカウントの廃止を決断できました。

1点、当初私が誤解していたので補足しておきますが、この機能は git clone 時に都度ポップアップウィンドウが立ち上がってSSO認証を求めるような機能ではなく、あくまでもブラウザ上で１度だけSSO認証しておくものになります。

会社用アカウントの廃止およびSSO有効化の実施

SSOが有効化されていることが、会社用GitHubアカウントを廃止するためのセキュリティ上の前提条件となったため、SSO有効化とGitHubアカウントの移行を同時に実施しました。

1週間のSSO有効化期間を設けたのち、3月末にSSO強制化を実施し、完全に移行を完了しました。 以下のような移行手順書を用意し（本物は画像も貼ってありリッチにしあがっていますが、簡略化しています）、弊社メンバーに展開してご協力いただきました。

会社用GitHubアカウントを使い続ける場合

私用GitHubアカウントを持ってない方の場合は簡単で、2ステップで完了しました。

  1. https://github.com/orgs/組織名/sso のリンクをクリックしSSOを有効化する
  2. SSH鍵のSSOを有効化する

私用GitHubアカウントに切り替える場合

こちらはなかなか手間がかかります。旧アカウントで権限確認をしておき、新アカウントでSSO認証を行い、権限を以前と同等に設定しなおす必要がありました。

  1. 旧会社用アカウントでの権限（所属Team、自身がOwnerになっているリポジトリ）を確認しておく
  2. 旧会社用アカウントで発行しているPersonal access tokenがないか確認し、あれば切り替え後に再設定する
  3. ブラウザで私用GitHubアカウントにログインし直す
  4. https://github.com/orgs/組織名/sso のリンクをクリックしSSOを有効化する
  5. 会社用のSSH鍵を新たに生成し、そのSSH鍵のSSOを有効化する
  6. Teamへの招待、自身がOwnerになっていたリポジトリに対してAdmin権限の付与を実施してもらう
  7. 移行が確認でき次第、旧会社用アカウントでログインし https://github.com/settings/organizations にて会社組織からLeaveする（有料枠を空けるため）

所属Teamの一覧を簡単に取得する方法はなさそうでしたが、弊社では幸いTeam数が少なかったため手動確認で賄ってもらいました。FYI: GraphQL APIで取得することもできそうでした。

自身がOwnerになっているリポジトリ一覧を簡単に取得する方法はなさそうでしたが、自身がCollaboratorになっているリポジトリの一覧を https://github.com/settings/repositories から確認できるので、そこからアタリをつけて頂きました。

オプションとして、会社リポジトリの通知を私用メールアドレスではなく会社メールアドレスに飛ばしたい場合は https://github.com/settings/notifications から設定変更をして頂きました。

間違えて旧会社用アカウントでSSOしてしまった場合、GitHub組織管理者の方で、https://github.com/orgs/組織名/people/ユーザ名/sso からRevokeすることで、無効化できました。

Botアカウントの場合

SSOを有効にしたほうが、セキュリティ強度が上がるという考えから、BotアカウントもSSO必須というルールにしました。そのため、SSOできるように社内の認証基盤にもアカウントを作る必要がありました。

  1. Bot用社内アカウントの発行を依頼
  2. ブラウザでBotアカウントにログインしなおす
  3. https://github.com/orgs/組織名/sso のリンクをクリックしSSOを有効化する
  4. SSH鍵のSSOを有効化する

注意点として、3と4の間で git clone できない瞬間が発生するため、Botが動いていない時間帯を狙い、手早くSSOを有効化してもらう必要がありました。

Outside Collaboratorの場合

GitHub組織Memberにのみ影響があるため、Outside Collaboratorには影響ありませんでした。

ただ、当初の想定ではOutside Collaboratorだと考えていた外部協力者が、Team機能を使うため組織Memberになっているケースがいくつかありました。関係各所に連絡してOutside Collaborator への変換を実施させていただきました。

なお、MemberとOutside Collaboratorの違いおよび共通点は以下のようになります。

  • Outside CollaboratorはTeam機能を使えない
  • 組織MemberはSSOを求められる。よって社内の認証基盤にアカウントが必要である
  • どちらも有料枠（seats）を消費する

Outside Collaboratorに変換すると、Teamに所属していた場合と同様の権限になるようにリポジトリごとに権限が与えられます。しかし、今後はTeam機能が使えなくなってしまうため、不便です。

社内の認証基盤の都合もあり実施できなかったのですが、外部協力者の方もMemberにしてSSOを有効化したほうがセキュリティ強度は高いですし、改善の余地はあると考えています。

デプロイキーの場合

ユーザではなくリポジトリに紐づくため、デプロイキーには影響ありませんでした。

SSO有効化の進捗確認

GitHub組織の管理者は sso:unlinked という検索フィルターでSSOをまだ有効化していないユーザの一覧を取得できました。この機能を用いて進捗状況をウォッチしました。

特にBotアカウントのSSO有効化が実施されていないと、SSO強制化を実施したタイミングでZOZOの本番システムに影響が出る危険性もあるため、重点的に確認しました。

強制排除されたユーザのサポート

SSO強制化によりGitHub組織から強制排除されたユーザは、SSOリンクを踏むことで組織に再度所属できます。その際に所属Teamなどの権限は元どおりに戻すことができるため、特別なサポートは必要ありませんでした。

新しい社内レギュレーション

SSO強制化を実施した後の新しい社内レギュレーションをまとめると以下のようになります。

  • 私用のGitHubアカウントで会社リポジトリにアクセスすることを推奨する（無料マルチアカウントは規約非準拠となるため会社用無料GitHubアカウントの作成は非推奨とする）
  • ブラウザからアクセスする際はSSO認証をすること（システム側で強制）
  • SSH鍵もSSO認証をしてアクセスすること（システム側で強制）
  • SSO認証したSSH鍵は会社PCにのみおくこと。私用PCにはSSO認証していない別のSSH鍵を用意して利用すること
  • 会社PCの紛失・盗難にあった場合、SSO認証したSSH鍵を削除できるように、会社PCにはリモートワイプを導入すること（通常、貸与された時点で導入済み）
  • GitHubアカウント、SSOアカウント共にMFA設定をすること（システム側で強制）

課題：実現できなかったこと

Enable SSOしたSSH鍵が私用PCに置かれていないことを、機械的な仕組みで防ぐか、せめて検知をしたかったのですが難しいようでした。リポジトリを git clone した証跡などが取れると良いのですが、GitHub組織のAudit Logではそれらの証跡は取れないようでした。

今後のGitHubに期待しています。

おわりに

ZOZOテクノロジーズで実施した github.com の会社用GitHubアカウントの廃止について報告しました。150人以上の組織で github.com のビジネスプランを利用し、SSOを利用している事例は珍しいとGitHub社の方から聞きましたので記事にしました。会社で github.com を利用する場合の事例として他社でも参考にしていただけたら幸いです。

弊社に入社してまだ3か月ですが、GitHubの運用のみではなく、他にも社内ツールやレギュレーションの改善が速いサイクルで実施されているのを目の当たりにしています。第二創業期のわちゃわちゃ感を味わいたい方にはおすすめです。

ZOZOテクノロジーズでは自発的に動いて会社に良い影響を与えてくれるメンバーを絶賛募集中です。ご興味のある方は、以下のリンクからぜひご応募ください！

corp.zozo.com

追記: FAQ

Twitterやはてなブックマークであった質問コメントについて回答します

Ｑ. 会社で課金していないということ？

ビジネスプランを利用しており、会社のGitHub組織に招待するユーザ数の枠で課金されています。それでもGitHubアカウントそのものは無料アカウントなので規約非準拠になるということでした。会社用に有料GitHubアカウント （Pro）を作ることにすると2重で課金される状態になります。会社用に作った無料アカウントは会社リポジトリのアクセス以外の用途でも使えるため、そのような判断になるのかと思われます。

Ｑ. 私用アカウントを会社に紐づけて身バレしたくないのだが？

「新しい社内レギュレーション」では私用のGitHubアカウントで会社リポジトリにアクセスすることを推奨してはいますが、必須とはしていません。新しく無料アカウントを作ると規約非準拠となるので、そちらは会社としては非推奨になりますが、新しく有料アカウントを作って利用することは可能です。まだ社内事例がないため、社内レギュレーションには記載していませんが、そちらの支払いについては社内でこれから検討が必要です。

Ｑ. GitHub Enterprise (Server) にはしないのですか？

GitHub Enterprise Server（旧称 GitHub Enterprise）への移行は導入コストがかかることに加え、自分たちでアップデートも含め運用するコスト（手間）を払わなければならないので今回は導入を避けました。また、外部サービス連携も難しくなります。CircleCI Enterprise など一部のサービスはGitHub Enterprise Server同様にオンプレで運用するプランも提供しているので利用可能ですが、そちらも自分たちで運用する必要がでてきます。さらに、新しい機能が github.com よりも遅れて導入されるなど欠点があります。複数組織を作れる点や、セキュリティ強度が高い点はもちろん利点になると思います。

今回のSSO化を実施するよりも圧倒的に導入・運用コストが高く、さらに不便になる点もあることから、（少なくとも今は）GitHub Enterprise Serverを導入しないという判断をしました。本記事は同様の理由からGitHub Enterprise Serverを導入せずに「会社で github.com を利用する場合の事例」として参考にしていただけたら幸いです。

カテゴリー