みなさんこんにちは、社内のエンジニアが働きやすくすることを目標にする Engineer Empowerment プロジェクトの @Mahito です。
この記事は、NTT Communications Advent Calendar 2021 2日目の記事です。
今回は社内のソースコードを GitHub Enterprise にとりまとめる活動とそこで遭遇した課題と解決方法についてお話します。
背景
きっかけは「NeWork のソースコードが見たい」という私の思いつきでした。
これを私が言い出した 2020 年当時、NTT Com ではソースコード管理の方法に決まりはなく、各プロジェクトの判断でバラバラにソースコードリポジトリが導入されていました。ちなみに、私が社内で見かけただけでもソースコードのホスティング先には以下のようなものがありました。
- GitHub (Team plan)
- GitHub (Enterprise Cloud)
- GitHub (Enterprise Server)
- GitLab (Community Edition)
この他にもあるかもしれませんが、基本的にサービスのソースコードはプロジェクト内に閉じられており、プロジェクト外の人がソースコードを見るためには各プロジェクトと交渉して閲覧するための権限を付与してもらわなければいけいないという状態でした。
このように、各プロジェクト内に閉じてソースコードを管理していることで、社内に情報が共有されず、同じようなライブラリやツールを作る重複開発が発生します。また、使っているライブラリのバグやセキュリティリスクの情報が共有されないなどのデメリットもありました。
このため、社内の開発者の情報共有やコラボレーションを促進するために（あわよくば NeWork のソースコードが見たい）、ソースコードリポジトリを共有することを目指してソースコードリポジトリの統合に向かって動き始めました。
統合に向けた検討と行動
統合に向けた検討でまず考えたのがソースコードリポジトリに「どのように運用するのか」と「何を使うのか」です。
どのように運用するかは以下の３つを考えました。
- 自分たちでソースコードリポジトリを社内にホスティングを行う
- 外部のホスティングサービスを利用する
- 上記２つのミックス
運用を考えた場合に現時点では自分たちで社内すべてのプロジェクトにソースコードホスティングサービスを提供できるだけの稼働を確保するのが難しい状況でした。そのため、2 の外部のホスティングサービスをメインにし、知的財産やお客様情報を扱うなど社内規定で外部のホスティングサービスに載せられないものは自分たちでホスティングするという 3 の案としました。
また運用に関するガイドラインについてもこの取組に協力してくれるエンジニアたちで話しながら案を策定しました。策定したガイドラインは GitHub 上に配置し、 Enterprise のメンバから見られる状態にして、問題や提案があれば Issue や Pull Request で改善をすることにしました。
ホスティングサービスに何を使うのかというところでは、GitHub と GitLab を検討し、社内の決裁から利用状況を確認したところ GitHub を利用しているプロジェクトが多かったので、移行のコストを減らすために GitHub としました。
幸いに、すでに GitHub Enterprise を契約しているプロジェクトも本取り組みに賛同してくれたこともあり、その契約をベースにとりまとめをはじめました。
社内調整
社内のソースコードリポジトリのとりまとめをはじめてしばらくした 2021 年 1 月末に大手企業のソースコードが GitHub 上に流出するという事件がありました。これをきっかけにセキュリティを担当する部から社内での GitHub 利用や運用についての調査が行われました。
幸いにすでに我々が社内の契約状況を把握していたことや運用ルールのベースを作っていたこともあり、セキュリティの担当と情報システムの担当と話し合い、全社のソースコードを我々の取り組みにとりまとめていく方向で合意ができました。
とりまとめへの課題
上記の話し合いの中でこの取組を行うためにセキュリティの担当から提示された課題は以下のようなものでした。
- 認証とユーザ管理
- 機密情報の取扱
- 監査ログ
- 運用方法
また、我々が取り組みの中で見つけた課題として以下のようなものもありました。
- アウトサイドコラボレーターの管理
- すでに GitHub にある Organization の移動と管理
以下ではこれらの課題にどのように対応したか、まだしていないかについてをお話をします。
認証とユーザ管理
セキュリティ担当からはセキュリティ対策としてログインに多要素認証を設定すること、会社を退職した社員のアカウントが残っていないことなどのユーザの管理を求められました。
管理すべき対象のユーザは社員と社員以外（協力会社等）の大きく2つに分けられ、それぞれについて対応を考えました。
社員
多要素認証は GitHub 側で ID / Password の認証に加え 2FA （二要素認証）を設定が可能ですが、今回はユーザ管理において後述するユーザプロビジョニング（SCIM）の機能を使いたいこともあり、情報システムの担当が管理する社員録と連携した Azure Active Directory（以下、AAD）を使った Single Sign-on（以下、SSO）を採用しました。
ユーザ管理には System for Cross-domain Identify Management (以下、SCIM)の機能を用いました。上記の社員録と連携した AAD と Security Group を用いて対象の Organization 上のユーザのプロビジョニング / デプロビジョニング を自動化することで、退職した社員は自動的にメンバから外れ、ソースコードリポジトリにアクセス出来なくなります。
社員以外
上記の社員以外の方についてはアウトサイドコラボレーターとしてリポジトリ単位に設定し、こちらは GitHub の 2FA を有効化してもらうことで多要素認証を設定してもらうことにしました。
一方、ユーザ管理が現在頭を悩ませるところとなっています。 GitHub のアウトサイドコラボレーターは Slack のゲストのように「2022 年 3 月 31 日まで有効」という有効期限の概念がなく、アウトサイドコラボレーターの削除は Organization の管理者が行わなければなりません。現在はガイドラインでアウトサイドコラボレーターの管理についての記載はしていますが、このあたりも自動化をしていきたいと考え調査し、下記のリンクのようなアウトサイドコラボレーターの管理を自動化する方法などを調べているところです。（まだ手はつけられていない今後の課題となっています）
https://github.com/icub-tech-iit/outside-collaborators
機密情報の取り扱い
基本的にリポジトリに機密情報を置くことはないようにしているのですが、特許に関わるソースコードやお客様情報を含むソースコードも社内には存在しているため、セキュリティ担当からも取り扱いについて考えたほうが良いとのアドバイスを受け、ガイドラインへの記載や運用を整備しました。
クレデンシャルの扱い
社内の利用者向けガイドラインではクレデンシャルの管理には Key Management Service の利用を検討することを前提としています。もしリポジトリに置く場合は暗号化してからリポジトリに置き、暗号鍵はリポジトリ外で管理すること、Private リポジトリであろうと平文で置かないことを記載しています。また、ガイドラインだけでは防げないケースにも備え、今後は GitHub Advanced Security を利用して Secret Scanning の利用も行っていくつもりです。
知的財産、お客さま情報の扱い
先に述べたように、社内の規定により特許などの知的財産や、お客さま情報については社外に持ち出すことが出来ないため、GitHub Enterprise Server を社内に構築し対応していくことにしました。
監査ログ
セキュリティ担当からは監査ログとしてある程度の期間保持し、インシデントがあった際に確認ができることを求められました。しかしながら、GitHub の監査ログは 90 日保存、Git 操作の監査ログは 7 日保存という期間のため、セキュリティ担当から求められる期間より短いものでした。
そこで監査ログを定期的に Export して保存する必要があるのですが、 @haeena がサクッと Google Cloud Platform の BigQuery に監査ログを保存する Cloud Function を書いて、必要に応じて監査ログを遡って検索できる状態にしてくれました。また、監査ログの保存状況は Slack Bot を通じて Slack へも通知されるようにも設定されています。（アイコンは大人の事情でカットしてあります）
運用
運用については情報システムの担当から問い合わせ対応やユーザ教育を心配する話がありました。
問い合わせ対応については、GitHub を利用する社内コミュニティを Slack 上で構築し、コミュニティベースで問い合わせ対応を行う仕組みを現在構築中です。また、Git / GitHub の使い方を学んでもらう話は、同じ NTT グループ内でも同様の課題感があると NTT グループ内のイベントでわかりました。そこで、NTT グループのエンジニア有志で Git / GitHub の勉強会を企画し、対応をはじめています。
既存 Organization の移動と管理
以前までは既存の Organization を Enterprise アカウント配下に移動させるためには GitHub 社に連絡をして移動をして貰う必要があり、依頼してから移動するまでの間にタイムラグがありました。
しかし、2021 年 9 月末に Enterprise の管理者が Organization を移動させる機能がリリースされました。これにより、現在は Enterprise アカウントに参加するプロジェクトが持つ Organization は Enterprise の管理者と Organization の管理者の合意があれば移動させられるようになり統合までのタイムラグがなくなりました。一方で、現在この方法で移動した Organization は Enterprise アカウントの 管理者であっても Organization の操作ができないため、 Organization の管理者から管理者権限を付与してもらう必要がありますが、ドキュメントを見ると近々 Enterprise の管理者が管理者になっていない Organization の管理者になる機能が提供されるようです。
とりまとめの効果
この取り組みを始めてよかったことが 3 つあります。
1. セキュリティの強化
認証、ユーザ管理、監査ログなど以前は各プロジェクトの自治に委ねバラバラだったところを、SSO 、SCIM、監査ログの保存などでレベルを合わせることが出来るようになりました。
2. 稼働の削減
他部の状況はわからないので弊部の話になるのですが、以前は各プロジェクトごとに契約の決裁していたものを私が取りまとめることで契約稼働の削減ができ、一部のメンバから感謝されています。
3. 社内の GitHub ユーザの情報共有やコラボレーションが行われるようになったこと
以前はどこのプロジェクトがソースコードリポジトリやホスティングに何を使っているのかわからなかったものが可視化されるようになりました。また、この取組について話し合う Slack チャンネルにいるユーザ間で情報共有や課題に対する議論が活発に行われるようになりました。そして、全社で共有する Organization を作ったことによりコラボレーションがはじまりつつあります。本ブログを管理するリポジトリは全社共有の Organization の上に作られており、そこで記事の管理や、レビュー、GitHub Actions によるデプロイが行われています。
おわりに
思いつきから始めた社内のソースコードリポジトリのとりまとめですが、現在 1000 近いアカウント契約数になっており、来年には 1400 を超えるアカウントの利用が見えています。課題はまだまだ山積みですが、この取組に賛同して協力をしてくれる人や応援してくれる人達がいるので引き続きとりまとめていきたいと思います。（ちなみに、NeWork の初期のコードは別件で見ることが出来たので目的は達成できました）
そんなわけで、現在の NTT Com におけるソースコードリポジトリのとりまとめについてでした。 この記事がどこかの社内ソースコードリポジトリのとりまとめの参考になれば幸いです。
明日もお楽しみに。
