GitHub Enterprise Cloud の Enterprise 設定とポリシーを構成する
直近の 2 つのガイドで、Enterprise アカウントを確立し、ユーザー モデルを選択しました。それではここで、すべての開発ワークに適用する設定とポリシーを構成しましょう。構成とポリシーは Enterprise レベルには適用されず、各 Organization 内で管理されます。これにより、一元管理と分散管理のバランスを希望どおりに管理できます。Enterprise レベルで確認できるほとんどのポリシー、構成オプション、設定は、Organization レベルでも同等ですが、両者にはいくつかの独自の構成アイテムや設定もあります。
ポリシーと設定を、開発、セキュリティ、運用、その他の関連チームのメンバーを含む全ての関係者と確認することは、推奨される方法の 1 つです。エンド ユーザーが業務を遂行するために必要なコラボレーションと柔軟性、および企業を保護するために必要なコンプライアンスとセキュリティの必須要件の両方を最適化する必要があります。
Enterprise ポリシーはトピックごとに分類されています。このガイドでは、トピックごとに最も重要な項目をいくつか紹介し、あまり一般的に設定されていない項目は省略します。そうした設定の全体的な詳細については、Enterprise ポリシーのドキュメントを参照してください。
GitHub Enterprise Cloud (GHEC) の設定を調べると、GitHub Copilot、GitHub Actions、GitHub Codespaces、GitHub Projects の設定があることが分かります。これらの設定については、次のガイドで課金に関して取り上げる際に説明します。これらの設定は GHEC とは別にライセンスが割り当てられるため、課金に影響する可能性があるためです。
まずは Fidelity の事例を取り上げ、コラボレーションとセキュリティのバランスを取るためにリポジトリ作成をどのように標準化したのか、また、設定に関する決定を社内の関係者とどのように検証したのかを見ていきます。
このガイドの学習内容
基本権限、リポジトリの作成およびフォーク機能など、Enterprise または Organization を構成するために利用可能なさまざまなポリシーと、設定方法のガイダンス (該当する場合)
コンプライアンス レポートやサポートを含む Enterprise 設定と機能
「ポリシーなし」に関する注意点
Enterprise ポリシーには常に「ポリシーなし」オプションが用意されており、各 Organization は特定の設定項目に対して独自のポリシーを設定できます。これは、積極的にポリシーを設定しないのではなく、Enterprise レベルで全体的に同じポリシーを設定することを選択しないという意味です。「ポリシーなし」は、複数の Organization があり、それぞれ異なる構成ニーズがある Enterprise の場合に便利です。
リポジトリ ポリシー
リポジトリ ポリシーは、リポジトリの作成と可視性に関連しており、Enterprise で最も機密性の高い設定のいくつかを網羅します。Enterprise レベルでも各 Organization レベルでも、これらの項目を注意深く確認するようにしてください。
リポジトリ アクセスの基本レベルの権限
基本レベルの権限は、Enterprise 内の全てのフル メンバー (外部コラボレーターではない) に付与される、継承されたデフォルトのリポジトリ アクセス権限です。この権限は、インナーソース文化への近道として役立ちます。この権限は、全てのユーザーへのアクセスのベースライン レベルを設定し、新しく作成されたリポジトリごとにチームや個人のアクセス割り当てを細かく管理することなく、可視化とコラボレーションを促進するために使用できます。もちろん、全ての Organization が同じレベルのデフォルトのオープンな環境を持つことが適切かどうか、あるいは Organization ごとに個別のポリシーを設定することが適切かどうかも検討する必要があります。
基本レベルの権限のオプションは以下のとおりです。
権限なし: Organization メンバーのリポジトリには、デフォルトの基本レベルの権限は付与されません。基本レベルの権限ではなく、チームとユーザーを直接指定してプライベート リポジトリの可視性を管理する必要があります。
読み取り: Organization メンバーに、デフォルトで全ての Organization リポジトリへの読み取りアクセス権が付与されます。これは、実質的にはインナーソースの設定です。Organization メンバー全員がプル リクエストの閲覧、クローン、作成ができますが、マージはできません。
書き込み、管理者: Organization メンバーに、全ての Organization リポジトリへの書き込みまたは管理者権限が付与されます。これらは制限がほとんどないデフォルト設定であり、Enterprise には推奨されません。
リポジトリ作成ポリシー
Organization のどのユーザーにリポジトリ作成を許可するか も、考慮すべき重要なポリシーです。オプションごとにそれぞれ異なる考慮事項があります。
メンバーはリポジトリを作成できる: Enterprise レベルで設定した場合、ユーザーは Enterprise で許可されている可視性の種類を使用して、Enterprise の Organization でリポジトリを作成できます。EMU を使用している Enterprise はパブリック リポジトリを選択できません。Organization のオーナーは、ここで何を選択したかに関係なく、常にリポジトリの全ての可能な可視性を作成できます。
無効: Organization のオーナーはリポジトリを作成できますが、エンド ユーザーは Enterprise でリポジトリを作成できなくなります。自動化プロセスを使用して標準設定からリポジトリを作成することを計画している企業の場合、このポリシー設定を使用します。
ユーザー名前空間リポジトリの作成をブロックする: このオプションは、EMU を使用している Enterprise でのみ使用できます。EMU ユーザー名前空間リポジトリは、 Organization ではなく、特定の EMU ユーザー アカウントが所有するリポジトリです。Enterprise によっては、開発者のためのサンドボックスとしてこれらの個人スペースを活用することを選択する場合があります。また、Enterprise や Organization のポリシーが一貫して適用される Organization スペース内に開発を閉じ込めるために、個人スペースをブロックすることを選択する Enterprise もあります。
リポジトリ作成者には、作成したリポジトリに対する管理者権限が自動的に付与されることに注意する必要があります。
当社では、全てのリポジトリが適切に保護されていることを確認するために、Enterprise 全体のセキュリティ ポリシーを設定し、Organization レベルのポリシーを使用して、アクセスや企業コードをよりきめ細かく差別化しています。リポジトリの作成を推進するセルフサービス ポータルを構築したところ、これらの標準が全社的に適用され、遵守されるようにしました。このアプローチを用いれば、コラボレーションとセキュリティの必要性のバランスを取ることができます。
リポジトリのフォーク ポリシー (およびフォークに関する注意事項)
フォークとは、元の上流リポジトリとコードと可視性設定を共有する新しいリポジトリのことです。フォークは、オープン ソース プロジェクトやユーザーが上流リポジトリへの書き込みアクセス権限を持っていない場合など、上流リポジトリに提案する前にアイディアの適用や変更を繰り返すためによく使用されます。フォークはもともと、オープンソースや、書き込み権限の管理が困難な低信頼シナリオで使用するためにコミュニティが設計したものです。このためフォークは、ID プロバイダー (IdP)、チーム、その他の自動化を使用してユーザーの ID を検証し、簡単に権限を管理できるような Enterprise のコンテキストには必ずしも最適ではありません。それでも、チームによっては、特定の種類のワークフローやツールをサポートするためにフォークを使用し続ける場合もあります。リポジトリのフォーク ポリシーは、こうしたフォークを作成できる場所を制御するのに役立ちます。
EMU を使用しているお客様への注意事項: フォーク ポリシーの設定は、ユーザー名前空間リポジトリの作成をブロックするように設定されている場合、先ほど説明したリポジトリの作成ポリシーによって上書きされます。この場合、リポジトリのフォーク ポリシーに関係なく、メンバーは自分のユーザー アカウントでリポジトリをフォークすることはできません。
リポジトリのフォークを許可する場所のオプションは以下のとおりです。
この Enterprise 内の Organization: メンバーは、Enterprise 内のどの Organization にもリポジトリをフォークできます。
同じ Organization 内: メンバーは、親リポジトリを所有する同じ Organization 内でのみリポジトリをフォークできます。このオプションでは、フォークがさまざまな場所に分散する代わりに、フォークの完全な可視性が維持されます。
ユーザー アカウントと同じ Organization 内: メンバーは、親リポジトリと同じ Organization やユーザー名前空間にリポジトリをフォークできますが、ユーザー モデルによって違いがあります。EMU を使用している Enterprise の場合、これはEnterprise Managed User アカウントの名前空間になります。つまり、Enterprise の内部にあり、管理下にあるものです。EMU を使用していない Enterprise の場合、これは個々のユーザーのアカウントの名前空間になります。つまり、Enterprise の外部にあり、Enterprise の管理下にないものです。
この Enterprise 内のユーザー アカウントと Organization: この設定では、EMU を使用している Enterprise としていない Enterprise でユーザー アカウントのフォークに同じ区別があります。EMU を使用している Enterprise の場合、Enterprise Managed User アカウントの名前空間へのフォークが許可され、EMU を使用していない Enterprise の場合、個々のユーザー アカウントの名前空間へのフォークが許可されます。さらにメンバーは、親リポジトリの Organization を所有するだけでなく、この Enterprise 内の任意の Organization にリポジトリをフォークできます。
ユーザー アカウント: EMU を使用している Enterprise の場合、メンバーは Enterprise Managed User アカウントの名前空間にのみリポジトリをフォークできます。EMU を使用していない Enterprise の場合、メンバーは個々のユーザー アカウントの名前空間にのみリポジトリをフォークできます。どちらの場合も、メンバーは Organization にフォークすることはできません。このため、Organization スペースからフォークを取り除きながら、フォークを許可できます。
どこでも: メンバーは、ユーザーアカウント、名前空間、Organization 内外を問わず、リポジトリをどこでもフォークできます。これは、EMU enterprise 外 にも適用されます。
外部コラボレーターのポリシー
外部コラボレーターとは、直接の招待によって 1 つ以上の Organization のリポジトリにアクセスできますが、明示的に Organization のメンバーではない人のことです。コンサルタントや臨時従業員などがあてはまります。外部コラボレーターについては、チーム、ロール、ユーザーのガイドで詳しく説明します。
このポリシーでは、リポジトリに外部コラボレーターを招待できる管理者のレベルを、Enterprise オーナー、Organization オーナー、リポジトリ管理者の中から選択できます。
EMU を使用している Enterprise の場合、このポリシーを目にすることはありません。この理由は、全てのユーザーは接続された IdP からプロビジョニングする必要があり、オーナーまたは管理者が作成することはできないためです。
Enterprise または Organization のオーナーが外部コラボレーターを招待することを要求すると、コラボレーターのアクセスに対する管理と制御を一元化しますが、ボトルネックを引き起こす可能性もあります。一方、個々のリポジトリ管理者がこれらの招待を管理できるようにすると、より多くのユーザーに招待の権限が付与されますが、コラボレーターのアクセス権の制御が緩くなる可能性があります。
デフォルト ブランチ名のポリシー
このポリシーは、全ての Organization の全てのリポジトリのデフォルト ブランチ名を設定します。ワークフローが異なる場合や、インテグレーションで特定のデフォルト ブランチ名が必要になった場合に、デフォルト名を変更できます。
他のいくつかのポリシーとは異なり、この Enterprise 全体で適用するオプションをオンにしない限り、これはリポジトリ レベルで上書きできます。
リポジトリの可視性の変更、削除、転送、問題の削除に関するポリシー
これらのポリシーは全て同様に、リポジトリの管理者権限を持つユーザーにこれらの破壊的または破壊的な可能性のあるアクションの実行を許可するか、またはこれらのアクションを Organization のオーナーに制限するかどうかを管理します。指定されたオプションを有効にするとリポジトリ管理者がそれぞれの操作を実行できるようになり、無効にすると Organization のオーナーに制限されます。
GitHub の初期イネーブルメント プロセスでは、ポリシーと設定をテストするために、本番環境とは別の GitHub Organization を作成しました。 利害関係者が全社に散らばっているため、この Organization に各所を代表するチームを招待し、そこでさまざまな自動化プロセスを試してもらったり、設定したプラットフォームを試してもらったりしました。代表チームは利害関係者のワーキング グループを結成してフィードバックを集め、一般提供する前にポリシーや設定を改善できるように、フィードバックを GitHub のイネーブルメント チームに提供しました。
GitHub プロジェクトのポリシー
このセクションのポリシーは、GitHub による開発者中心の組み込みプロジェクト管理ツールである GitHub Projects の使用を管理するものです。管理者は、1 つ以上の Organization でプロジェクトの使用を無効にしたり、プロジェクトの可視性の変更を管理したりできます。このポリシーは、段階的なロールアウトや他のプロジェクト管理ツールの使用を許可する場合に役立ちます。
GitHub Connect の設定
GitHub Connect は、GitHub Enterprise Cloud と GitHub Enterprise Server (GitHub のセルフホステッド Enterprise サービス) の間の限定的なデータ共有を許可することで、特定の機能を有効にするサービスです。GitHub Enterprise Server を使用している場合は、このセクションでこの機能を有効にして設定できます。
Enterprise の設定
Enterprise のプロフィール
このセクションでは、Enterprise アカウントの表示名、説明、ウェブサイトの URL、場所を設定、変更できます。この情報は、Enterprise アカウントのプロフィール ページで全ての Enterprise メンバーに表示されます。
また、このページには 2 つ目のタブがあり、フッターを設定できます。フッターは、ログインしている Enterprise コンテキストの全てのページの下部に表示されます。このタブを使用して、必要な法的通知や GHEC ユーザーに常に表示されなければならないその他のデータを表示できます。他の告知テキストと同様に、必要な情報のみを表示して余分な視覚的ノイズを避けるよう、これらの使用には慎重を期してください。
認証済みのドメインと承認済みのドメイン
ドメインの認証と承認は、どのドメインがその Enterprise や Organization からのメール通知を受信することを許可されるかを制御します。ドメインの認証には、ドメインの DNS レコード (企業が所有するドメインなど) へのアクセス権が必要です。一方、ドメインの承認は、ベンダーや請負業者のドメインなど、企業で管理していないが許可リストに入れたいドメインに使用できます。
認証済みの (承認済みでない) ドメインでは、各 Organization のプロフィール情報に URL として記載されている各 Organization のプロフィールにも承認済みバッジが表示されます。このため、Organization ページの外部向けの正当性をさらに高めることができます。
EMU を使用している Enterprise や Organization では、標準的なメールアドレスを使用しており、一般に公開されていないため、EMU を使用している Enterpriseのほとんどではドメイン認証が設定されていません。
告知
このセクションでは、全ての Enterprise ページの上部に表示されるグローバル告知バナーを作成できます。アラートによる疲労や視覚的なノイズを避けるため、この機能は絶対に必要な場合にのみ使用し、可能な限り、有効期限と削除可能オプションを使用することをお勧めします。
サポート
GHEC プランにはデフォルトで Enterprise サポートが含まれています。Enterprise サポートでは、GHEC サポート エンジニアによる年中無休のチケットベースのサポートを利用できます。また、追加特典付きのプレミアム サポートについて、購入済みのお客様や権利をお持ちのお客様もいます。
GitHub ユーザーなら誰でもサポートチケットを作成できますが、Enterprise オーナーと支払いマネージャーは自動的にサポート資格を持っているため、Enterprise アカウントに関連するサポート チケットの作成、閲覧、コメントができます。Enterprise オーナーは、自分の Enterprise アカウントが所有する Organization の一般ユーザーに対して最大 20 名までサポート資格を追加することもできます。
Enterprise 管理者やサポート資格を持つユーザーは、Enterprise サポート ポータルから GitHub サポート チケットを開いて管理できます。
コンプライアンス レポート
セキュリティ チームは、GitHub をベンダー パートナーとして検討、導入、維持する際に、コンプライアンス ドキュメントを最新の状態に維持する必要があります。GitHub では、最新の SOC レポート、サードパーティ証明書、および自己報告された業務手順を、Enterprise 管理ページ内のセルフサービス ドキュメントとしてダウンロードできるようにしています。
次の項目: 課金、ライセンス、従量課金制のサービスを管理する
これで、重要なポリシーとデフォルトの権限の大半を設定できました。次は、課金、ライセンス、従量課金制サービス (GitHub Actions や Codespaces など) に関連する設定を見てみましょう。