Ubie DiscoveryでSREなどをしている@itkqです。
UbieではGitホスティングにgithub.comを使っています。プロダクト開発に必要なprivateなコードベースはもちろん、OSSや就業規則といったドキュメントをpublicにホストしたりもしています。また、この記事を書いている時点で、メインのOrganizationのメンバーは121名です。
自分が入社したのは一年前（2021年1月）で、まだ情報システム専任の人がいませんでした。それから今に至るまで、GitHubの運用を「会社」にしていく話を書きます。
一年前のGitHubの運用
当時、UbieのOrganizationに所属していた人数は、業務委託含め80〜90名ぐらいで、Businessプランを利用していました。私はSREとして入社しましたが、情報システム専任の人がおらず、SREをはじめとする何名かのメンバーがgithub.comを最小労力で運用している状態でした。自分も実際に携わってみると、以下のセキュリティやガバナンスの課題に気づきました（これらは既存の運用者も気づいていたものの手が回っていないことでした）。
- Organizationに所属する正社員には、全員にOwners権限が与えられている。アカウント追加削除やリポジトリの作成、チームへの所属などのオペレーションを各自よしなに手作業で行うため、ヒューマンエラーや暗黙的な変更によるリスクが大きい
- 2FAを強制できていない
- SAML SSOを有効化したい
そこで自分の当事者意識をもってグッと力を入れ、セキュリティチームも巻き込みながら、これらの課題を解決していくことにしました。
会社になるために行った施策
最小権限化とas Code
今後人が増えていくことを考えると、全員がOrganization owners権限を持っていることは、ミスや退職時の漏れなどのリスクが看過できないと考えました。そこで、Organization ownersは最低限の人に絞り、メンバーの追加と削除はBotアカウントとTerraformで行うことにしました。GitHub Actionsでplanおよびapplyを自動的に実行しています。
Enterprise移行
情報セキュリティを担当するメンバーも増えたことで、改めてGitHub運用に必要な要件を洗い出したところ、リスク管理のため監査ログは必要だろうとの結論に至りました。
機械的な監査ログの保全にはGitHub Enterprise移行が必須でした。運用負荷軽減とこれまで通りの体験をなるべく変えたくなかった理由から、GitHub Enterprise ServerではなくGitHub Enterprise Cloud (GHEC) が候補でした。また、脆弱性管理の観点で、セキュリティチームがAdvanced Securityを検証したいとの要望もありました (ただし、検証の結果Advanced Securityは結局見送りました)。他にも、Enterprise内でポリシー別にリポジトリを置くOrganizationを分け、例えば本番環境にデプロイされるリポジトリを置くOrganizationには厳しめのポリシーを適用する構想もありました。
GHECに移行する意思決定から社内稟議、実際の移行まで2週間もかかりませんでした。意思決定ではROI (Return on Investment) が見合うかを考えます。今回のケースではプラン変更による金銭コストの増加に対して、セキュリティ観点のリスク軽減が期待でき、また実質他の選択肢がないことをまとめたところ、すぐに承諾されました。
今のところ、監査ログは公式が提供するストリーミングを使ってGCSに永続化しています。
SAML SSOと2FAの強制
Ubieでは原則BYODを禁止しており、業務用のPCは管理された端末を社員に貸与しています。一方で、特にエンジニアは社外の活動でもgithub.comにアクセスすることが普通にあります。UbieのOrganizationへは社用アカウントのみでアクセスさせる方法は、OSS等の開発体験の毀損に直結することから、選択肢にはなり得ませんでした。とはいえ管理外の私物端末から社用Organizationへのアクセスは制限したいニーズがありました。
このニーズを満たすため、SAMLによるSSOを強制することにしました。公式に対応しているSAMLサービスをみると、Ubieにおける実質的なIdPであるGoogle Workspaceは残念ながら非対応でした。GitHub社から、Google Workspaceは公式サポートしていないものの、動作は確認しているとのコメントを貰いました。実際に検証してみると、動作は問題ないことを確認できました。UbieではAzure ADが導入されている一方、二重の運用コストを避けるためにGoogle WorkspaceをIdPとして構成しています。Azure ADとGoogle Workspace間の連携が正しく動作する確信を持てなかったため、このような暫定対応をしています。
SSOを強制するにあたって必要なアクションをまとめてアナウンスし、一週間後に強制を有効化しました。一週間以内にアクションを取らなかった人は一時的にアクセスできなくなりますが、必要なタイミングでアクションすればクリティカルな問題にはならないと判断したためです。同様に、2FAの強制も行いました。また、Email通知をUbieのドメインに限定することもこのタイミングで行いました。個人用Emailに会社の情報が漏れないようにするためです。
まだ道半ば…！
最低限やりたかったことは達成できました。しかし「会社」になりきれたわけではなく、以下をはじめとするやりたいことが多くあります。
- GitHub公式のプラクティスを参考にしながら、さらなるhardening
- 公式にサポートされたIdPを使いたい
- Enterprise Managed Usersを使ったり、Teamの同期をやりたい
- ポリシー別にOrganizationを分けて運用する
- 本番環境にデプロイされるOrganization、OSSだけをホストするOrganization、etc.
- 各リポジトリで強制したいポリシーを継続的監査
- 生産性を犠牲しないやり方で
今回はGitHubに限った話を書きましたが、これに限らず、社内システムをエンジニアリングしていく人を圧倒的に募集しています！
Special thanks
GitHubの件は、以下の方々と協力して進めました。感謝🙏
- @sakajunquality as SRE
- @cestquigucci as 情報セキュリティ
- @mizutani as セキュリティエンジニア
- @tamosan_01 as コーポレートエンジニア
Discussion