Enterprise でのセキュリティ設定のポリシーについて
ポリシーを適用して、GitHub Enterprise Cloud で Enterprise が所有する Organization のセキュリティ設定を制御できます。 既定では、Organization の所有者はセキュリティ設定を管理できます。
Enterprise で Organization に対して 2 要素認証を必須にする
Note
2023 年 3 月より、GitHub では、GitHub.com でコードを投稿するすべてのユーザーに、1 つ以上の形式の 2 要素認証 (2FA) を有効にすることが求められます。 該当するグループに属しているユーザーは、そのグループが登録対象として選択されると通知メールを受け取り、45 日間の 2FA 登録期間が開始されて、GitHub.com での 2FA への登録を求めるバナーが表示されます。 通知を受け取らないユーザーは、2FA を有効にする必要があるグループには含まれませんが、有効にすることを強くお勧めします。
2FA 登録のロールアウトについて詳しくは、こちらのブログ記事をご覧ください。
Enterprise 所有者は、Enterprise が所有するすべての organization の organization メンバー、支払いマネージャー、外部コラボレーターに対して、ユーザー アカウントをセキュリティで保護するために 2 要素認証を使うことを要求できます。このポリシーは、マネージド ユーザーを含む Enterprise には使用できません。
Enterprise が所有するすべての organization で 2 要素認証を必須にする前に、所有者自身のアカウントの 2FA を有効にする必要があります。 詳しくは、「2 要素認証でアカウントを保護する」をご覧ください。
2 要素認証の使用を義務化する前に、Organization のメンバー、外部コラボレーター、支払いマネージャーに通知をして、各自に自分のアカウントで 2 要素認証をセットアップしてもらってください。 Organization の所有者は、メンバーと外部コラボレーターが既に 2FA を使用しているかどうかを、各 organization の [People] ページで確認できます。 詳しくは、「組織内のユーザが 2 要素認証を有効にしているかどうかを表示する」をご覧ください。
Warning
- Enterprise で 2 要素認証を必須にすると、Enterprise が所有するすべての organization に属する外部コラボレーター (ボットアカウントを含む) のうち、2FA を使っていないものは、organization から削除され、そのリポジトリにアクセスできなくなります。 Organization のプライベートリポジトリのフォークへのアクセスも失います。 ユーザーが、organization から削除されてから 3 か月以内にアカウントで 2FA を有効にすれば、そのユーザーのアクセス特権と設定を復元することができます。 詳しくは、「組織の以前のメンバーの回復」をご覧ください。
- 2 要素認証の必須要件を有効にすると、その Enterprise アカウントが所有するすべての外部コラボレーターのうち、アカウントの 2FA を無効にしているものは、organization から自動的に削除されます。 2FA を無効にしたメンバーと支払いマネージャーは、再度有効にするまで organization リソースにアクセスできなくなります。
- 2 要素認証を必須にしている Enterprise で自分が唯一の所有者である場合、Enterprise で必須になっている 2FA を無効にしない限り、自分のユーザー アカウントの 2FA を無効にすることはできません。
Note
organization 内の一部のユーザーは、GitHub.com による必須の 2 要素認証登録に選ばれている可能性がありますが、Enterprise で organization に対して 2FA の要件を有効にする方法には影響しません。 Enterprise の organization で 2FA の必須要件を有効にした場合、その時点で 2FA を有効にしていない外部コラボレーターは、GitHub.com で有効にする必要があるものも含め、organization から削除されます。
-
GitHub の右上隅にあるプロフィール写真をクリックします。
-
ご自分の環境に応じて、[Your enterprise] または [Your enterprises] をクリックし、表示するエンタープライズをクリックします。
-
ページの左側にある Enterprise アカウントのサイドバーで、 [設定] をクリックします。
-
[設定] で、 [認証セキュリティ] をクリックします。
-
[Two-factor authentication] で、設定変更に関する情報を確認します。 必要に応じて、設定を変更する前に Enterprise アカウントのすべての Organization の現在の構成を確認するには、 [Organization の現在の構成を表示する] をクリックします。
-
[Two-factor authentication] で、[Require two-factor authentication for the enterprise and all of its organizations] をオンにして、[Save] をクリックします。
-
メッセージが表示されたら、organization リソースへのユーザー アクセスが 2FA 要件によってどのような影響を受けるかについての情報を確認します。 変更を確定するには、[Confirm] をクリックします。
-
Enterprise によって所有される organization から削除される外部コラボレーターがいる場合、organization に対する元の特権とアクセス権を復元するための招待状を、それらのユーザーに送信することをお勧めします。 それらのユーザーが招待状を受け取ることができるようにするには、まず各ユーザーが 2FA を有効にする必要があります。
エンタープライズで organization に対してセキュリティで保護された方法 2 要素認証を必須にする
2 要素認証の要求に加え、エンタープライズの所有者は、エンタープライズが所有するすべての organization の organization メンバー、支払いマネージャー、外部コラボレーターに対し、セキュリティで保護された 2FA の方法を使うことを要求できます。 セキュリティで保護された 2 要素メソッドには、パスキー、セキュリティ キー、認証アプリ、GitHub モバイル アプリがあります。 セキュリティで保護された 2FA の方法が構成されていないユーザー、またはセキュリティで保護されていない方法が構成されているユーザーは、エンタープライズが所有する organization 内のリソースにアクセスできなくなります。 このポリシーは、管理対象ユーザーを持つエンタープライズでは使用できません。
セキュリティで保護された 2 要素認証の方法を義務化する前に、organization のメンバー、外部コラボレーター、支払いマネージャーに通知して、各自に自分のアカウントで 2FA をセットアップしてもらうことをお勧めします。 Organization の所有者は、メンバーと外部コラボレーターが既にセキュリティで保護された 2FA の方法を使用しているかどうかを、各 organization の [People] ページで確認できます。 詳しくは、「組織内のユーザが 2 要素認証を有効にしているかどうかを表示する」をご覧ください。
-
[Two-factor authentication] で、[Require two-factor authentication for the enterprise and all of its organizations] と [Only allow secure two-factor methods] をオンにして、[Save] をクリックします。
-
メッセージが表示されたら、セキュリティで保護された方法の 2FA を必須にすることによって organization リソースへのユーザー アクセスがどのような影響を受けるかについての情報を確認します。 変更を確定するには、[Confirm] をクリックします。
-
Enterprise によって所有される organization から削除される外部コラボレーターがいる場合、organization に対する元の特権とアクセス権を復元するための招待状を、それらのユーザーに送信することをお勧めします。 これらのユーザーが招待状を受け取ることができるようにするには、まず各ユーザーがセキュリティで保護された方法により 2FA を有効にする必要があります。
Enterprise の SSH 証明機関を管理する
SSH 証明機関 (CA) を使用して、Enterprise が所有するすべての Organization のメンバーに、指定した SSH 証明書を使用してその Organization のリポジトリにアクセスすることを許可できます。 Enterprise で Enterprise Managed Users を使用している場合、Enterprise メンバーは、証明書を使用して個人所有のリポジトリにアクセスすることもできます。SSHがリポジトリで無効になっていなければ、Organizationのリソースにメンバーがアクセスする際に、SSH証明書を使わなければならないようにすることができます。詳細については、「SSH認証局について」を参照してください。
各クライアント証明書を発行する際には、その証明書がどのGitHub Enterprise Cloudユーザー用かを示すエクステンションを含める必要があります。 詳しくは、「SSH認証局について」を参照してください。
SSH認証局を追加する
Enterprise に SSH 証明書が必要な場合、Enterprise メンバーは SSH 経由の Git 操作に特別な URL を使用する必要があります。 詳しくは、「SSH認証局について」をご覧ください。
各証明機関は、GitHub Enterprise Cloud 上の 1 個のアカウントにのみアップロードできます。 SSH 証明機関が Organization または Enterprise アカウントに追加されている場合、GitHub Enterprise Cloud 上の別の Organization または Enterprise アカウントに同じ証明機関を追加することはできません。
1 つの証明機関を Enterprise に追加し、もう 1 つの証明機関を Enterprise 内の Organization に追加する場合は、いずれかの証明機関を使用して Organization のリポジトリにアクセスできます。
-
GitHub の右上隅にあるプロフィール写真をクリックします。
-
ご自分の環境に応じて、[Your enterprise] または [Your enterprises] をクリックし、表示するエンタープライズをクリックします。
-
ページの左側にある Enterprise アカウントのサイドバーで、 [設定] をクリックします。
-
[設定] で、 [認証セキュリティ] をクリックします。
-
[SSH 認証局] の右側にある [新しい CA] をクリックします。
-
"Key(キー)"の下で、公開SSHキーを貼り付けてください。
-
[CA の追加] をクリックします。
-
必要に応じて、メンバーに SSH 証明書の使用を要求するには、 [SSH 証明書を要求する] を選択し、 [保存] をクリックします。
Note
SSH 証明書を必要とすると、ユーザーは HTTPS 経由で、または未署名の SSH キーを使って organization のリポジトリにアクセスするための認証を、行うことができなくなります。SSH キーが外部 ID システムを介した認証を必要とする organization に対して認可されているかどうかには関係ありません。
その要件は承認された GitHub Apps (ユーザーからサーバーへのトークンを含む)、またはデプロイ キーや GitHub エコシステム内の信頼された環境である GitHub Actions と Codespaces などの GitHub 機能には適用されません。
ユーザー所有リポジトリへのアクセスの管理
SSH 証明書 を使用してユーザー所有のリポジトリへのアクセスを有効または無効にすることができます (Enterprise で マネージド ユーザー アカウント を使用している場合)。 ただし、Enterprise が GitHub.com メンバーで個人用アカウントを使用している場合、個人所有のリポジトリにアクセスするために証明書を使用することはできません。
-
GitHub の右上隅にあるプロフィール写真をクリックします。
-
ご自分の環境に応じて、[Your enterprise] または [Your enterprises] をクリックし、表示するエンタープライズをクリックします。
-
ページの左側にある Enterprise アカウントのサイドバーで、 [設定] をクリックします。
-
[設定] で、 [認証セキュリティ] をクリックします。
-
[SSH 証明機関] で、[ユーザー所有リポジトリにアクセス ] チェック ボックスを選択します。
SSH認証局を削除する
CAを削除すると、元に戻すことはできません。 同じCAを使用したくなった場合には、そのCAを再びアップロードする必要があります。
-
GitHub の右上隅にあるプロフィール写真をクリックします。
-
ご自分の環境に応じて、[Your enterprise] または [Your enterprises] をクリックし、表示するエンタープライズをクリックします。
-
ページの左側にある Enterprise アカウントのサイドバーで、 [設定] をクリックします。
-
[設定] で、 [認証セキュリティ] をクリックします。
-
[SSH 認証局] で、削除する CA の右側にある [削除] をクリックします。
-
警告を読み、 [わかりました。この CA を削除してください] をクリックします。
SSH 証明機関のアップグレード
2024 年 3 月 27 日に先立って企業の にアップロードされた CA、GitHub Enterprise Server バージョン 3.13 以前の
認証されていないユーザーに対する SSO の管理
Note
自動的なユーザーのログインへのリダイレクトは、現在 Enterprise Managed Users の パブリック プレビュー 段階であり、変更される可能性があります。
Enterprise で Enterprise Managed Users を使用している場合は、認証されていないユーザーが Enterprise のリソースにアクセスしようとしたときに表示される内容を選ぶことができます。 Enterprise Managed Users の詳細については、「Enterprise Managed Users について」を参照してください。
既定では、プライベート リソースの存在を隠すために、認証されていないユーザーがお客様の Enterprise にアクセスしようとすると、GitHub に 404 エラーが表示されます。
開発者の混乱を防ぐために、ID プロバイダー (IdP) を介してユーザーがシングル サインオン (SSO) に自動的にリダイレクトされるように、この動作を変更できます。 自動リダイレクトを有効にすると、Enterprise のリソースのいずれかの URL にアクセスするすべてのユーザーは、リソースが存在することを確認できます。 しかし、リソースを確認できるのは、IdP で認証した後に適切なアクセス権を持っている場合のみです。
Note
ユーザーは、Enterprise のいずれかのリソースにアクセスしようとして個人用アカウントにサインインさせられた場合、自動的にサインアウトされて、SSO にリダイレクトされ、マネージド ユーザー アカウント にサインインすることになります。 詳しくは、「複数のアカウントの管理」をご覧ください。
- GitHub の右上隅にあるプロフィール写真をクリックして、[Your enterprise] をクリックします。
- ページの左側にある Enterprise アカウント サイドバーで、[Identity provider] をクリックします。
- [Identity Provider] で、[Single sign-on configuration] をクリックします。
- [シングル サインオン設定] で、 [ユーザーをサインインに自動的にリダイレクトする] を選択または選択解除します。