GitHubは、個人およびOrganizationがコードを発見したり、共有したり、またはコードに貢献できる強力なプラットフォームです。しかし、特にOrganization内のユーザやリポジトリの数が増えた場合など、GitHubに存在する膨大な量の情報に対応しきれなくなることもあります。

Organizationの管理者は、セキュリティ要件を遵守し、メンテナンス作業を減らしながらも、可能な限り良いコラボレーション環境をユーザに提供したいと考えています。そのために、以下3点を中心に、GitHubが推奨するOrganization向けのベストプラクティスをご紹介します。

•   ユーザとコンテンツを保護する
•   ユーザとコンテンツを整理する
•   メンテナンスとコンプライアンスのワークフローを自動化する

ユーザとコンテンツを保護するためのベストプラクティス

多くのユーザはGitHubからオープンソースコードを連想しますが、Organizationは規模の大小を問わず、オープンソースへのコントリビューションに加えて、プロプライエタリであるソフトウェアの開発にもGitHubを利用しています。Organizationのメンバーとコードの安全を維持するために、次のことをお勧めします。

2要素認証(2FA)の必須化

Organizationのオーナーは、すべてのメンバーおよび外部のコラボレータに対して、自分のアカウントで2要素認証を有効化することを推奨します。GitHubは、Google AuthenticatorなどのTime-based One-Time Password  (TOTP)アプリを介した2FAをサポートしており、(オプションで)FIDO U2Fに準拠したハードウェアキーを利用することもできます。

また、GitHubでは現在、SMSベースの2FA の設定も許可しています。ただし、SMSベースの2FAはさまざまな攻撃に対して脆弱であることが実証されているため、TOTPの利用を強くお勧めします。

また、2FAを必須にする場合は、あらかじめOrganizationのメンバーに通知しておくこともお勧めします。Organizationに対して2FAを必須にするとアカウントで2FAを設定していないメンバーおよび外部のコラボレータはすべて即座に権限が削除され、リポジトリのフォークへのアクセスが中断されてしまいます。2FAが必須になるまでに2FAを設定できないユーザがいても、少数であれば心配いりません。権限の削除から3か月以内であれば、回復させることができます。

GitHub EnterpriseでのSAML認証の有効化と必須化

OrganizationがGitHub Enterpriseプランである場合、そのメンバーに対してSAML認証を設定および必須にすることができ、これを推奨します。

SAML認証を有効化すると、Organizationは、メンバーがコンテンツにアクセスする際に企業のアカウントポリシーを適用することができます(パスワードの有効期間、最小パスワード要件、Webセッションのタイムアウト、2FAなど)。

SAML認証が必須になると、SAMLを介してサインインしていないメンバーはすべて、Organizationから自動的に権限が削除されます。そのため、Organizationの全メンバーにSAML認証を必須にする前に、まずSAMLプロバイダーを設定し、Organizationのメンバーには「オプトイン」期間を残しておくことをお勧めします。この期間中、SAML認証の適用時にOrganizationからアカウントの権限が削除されてしまわないように、全メンバーがSAMLを介してサインインするように働き掛ける必要があります。

2FAと同様、SAML認証の設定をしていないことが原因で権限が削除されたユーザは、削除から3か月以内であれば、権限を回復させることができます。

注意：リポジトリに追加された外部のコラボレータは、Organizationに属していないため、SAML認証を使用する必要はありません。外部のコラボレータに対してSAML認証を必須にしたい場合は、Organizationのメンバーとして招待し直し、SAMLプロバイダーでIDを設定する必要があります。

デフォルトのリポジトリ権限

企業におけるソフトウェア開発でも、可視性をさらに高め、社内でコードを再利用できるようGitHubの環境を設定することをお勧めします。多くのOrganizationにとって、これはすべてのメンバーがすべてのコードに対して読み取り専用以上のアクセス権を持つことを意味しています。読み取り専用アクセス権は、Organizationのデフォルトのリポジトリ権限を「read」に設定することで簡単に付与できます。

プライベートリポジトリでのコラボレーションを向上させるには、各リポジトリでブランチ保護を適切に設定したうえで、_write_権限をデフォルトで付与することを検討してください。これにより、メンバーはリポジトリ内にブランチを作成し、Pull Requestを通じて変更を提案できると同時に、本番稼働の準備が整ったコードの変更は禁止することができます。これは、次のような場合に、Organizationのメンバーがプライベートコードで共同作業する際に推奨される方法です。

•   フォークが他の名前空間(Organizationの外部)に存在しているため、次のような状況が生じる場合。
  • コラボレーションや権限管理のために、OrganizationのいずれのTeamにもアクセスできない
  • オーナーがコラボレータを自分で追加、削除する必要がある
  • Organizationの設定済みのインテグレーションにアクセスできない

•   フォークが検索用にインデックス化されていない

全コンテンツの参照を許可すべきでない請負業者が社内に存在する、あるいは一部のコードの機密度が非常に高く、「Need To Knowの原則」が適用される場合など、すべてのリポジトリに対する読み取り専用以上のアクセス権をメンバーに付与することができない場合は、デフォルト権限を「none」に設定し、チームと外部のコラボレータを使用してリポジトリへのアクセス権を明示的に付与することができます。このような場合、チームを利用して同じように「オープン」な環境を構築することをお勧めします。その方法については、この記事の「チーム」セクションでご説明します。

リポジトリの可視性

ほとんどのOrganizationには、オープンソースコミュニティに貢献できるリポジトリを決定するための明確なポリシーと手順があります。GitHub.comでは、「パブリック」なリポジトリはすべて世界中で参照および利用することができます。GitHubでは、Organizationの管理者は、メンバーによるリポジトリの可視性の変更を禁止することができます。

これを有効化した場合、リポジトリの可視性を変更できるのはOrganizationのオーナーだけです。

ユーザとコンテンツを整理するためのベストプラクティス

子チームを使用してチーム管理をシンプル化 

多くのOrganizationでは、リポジトリへのメンバーのアクセスを管理するために「チーム」を利用しています。多数のチームをシンプルに管理するには、子チームを使用します。子チームは親チームのアクセス権限を継承します。また、親チームが@メンションされると、子チームのメンバーも通知を受け取ります。

「全社員」チームを使用して、Organization全体でオープンな環境を促進 

上記の「デフォルトのリポジトリ権限 」セクションで説明したように、Organization全体での共有、再利用、コントリビューションを促進するために、リポジトリをできる限りオープンにする必要があります。すべてのリポジトリに対して最低でも_read_権限をデフォルトで指定することができない場合、全社員 チームを作成し、最も機密度の高いリポジトリを除くすべてのリポジトリへの適切なアクセス権を付与することをお勧めします。これにより、企業の全社員がオープンな環境のメリットを享受できると同時に、Organizationの社員以外のメンバーによるアクセスをより厳重に制限することができます。

Ad-hoc チームで社内の専門知識を活用 

GitHubを使用する多くの企業は、Organization内のチーム構造を実際の組織図に基づいて作成し、適切なレベルのアクセス権を付与しています。しかし、この構造だけでは盲点が残ってしまう可能性があります。なぜなら、既存のチームメンバーだけでは、特定の問題解決に必要な専門知識がない可能性があるからです。Ad-hoc チーム の考え方は既存のチームを補足するために作成し活用できます。。特定の専門性や話題を軸にし、Organizationのメンバーが自由に参加できるチームを作ることを「Ad-hoc チーム」と呼んでおります。チームディスカッション機能と組み合わせることで、Ad-hoc チームで次の通りを実現できます·  

• 内部の開発コミュニティが自然に集まるスペース
• 非公式で自然に育った緩いサポートネットワーク
• Organization全体から人材や専門知識を活用するための機会
• 知識の拡散を促進するための新しい方法

Topics

TopicsはOrganizationのリポジトリを整理するのに役立ちます。多くのオープンソースコミュニティとリポジトリは、Topicsを使用して言語やアプリケーションタイプ別にリポジトリを分類します。その良い例がelectron/electronリポジトリです。

Organization内のチームは、次のようなさまざまな基準で簡単にリポジトリを分類できることを望んでいます。

•   使用されているフレームワークと言語
•   リポジトリの保守を担当するチーム
•   リポジトリが所属している上位のシステム

Topicsは、これを実現する素晴らしい方法です。_Java_、_Team-Ice-Cream_、_order-management_などのTopicsをリポジトリに追加するだけです。GitHubの検索時に、そのトピックを含む結果が返されます。検索欄で、検索の前に接頭辞@my-organizationを付けてスコープをOrganizationに設定するだけで、クエリーに一致するOrganization内のリポジトリで設定されているトピックやその他の結果を確認することができます。

ラベル 

多くのGitHubユーザは、ラベルを使用してIssueとPull Requestを分類する機能に慣れています。しかし、プロジェクトの規模やスコープが大きくなるにつれて、使用されるラベルも膨大な数になる可能性があります。使用されるラベルの数が増える場合は、テキストと色の両方でラベルをコード化する分類法を作成することをお勧めします。

この手法をうまく利用しているのが、Electronプロジェクトで使用されているラベルです。コンポーネントと関係があるラベルはすべて明るいオレンジ色を使用し、バグについて記したIssueはすべて明るい黄色を使用しています。これにより、多くのIssueやPull Requestを検索している場合に、ラベルの色に注目するだけで個々のIssueまたはPull Requestが何についてなのかを迅速に把握できます。詳細はラベルを読んで確認できます。

コンテンツおよびユーザを整理、保護するベストプラクティスを最大限に活用するためにサポートが必要な場合は、当社のサポートチームにお問い合わせください。

あわせて、以下の資料もご覧ください。

GitHub EnterpriseのOrganizationに関するガイド　[GitHub Enterprise管理者向け]