Skip to main content

Enterprise でセキュリティ設定のポリシーを適用する

Enterprise の Organization 内のセキュリティ設定を管理するようにポリシーを適用することも、各 Organization でポリシーを設定することもできます。

この機能を使用できるユーザーについて

Enterprise owners can enforce policies for security settings in an enterprise.

Enterprise でのセキュリティ設定のポリシーについて

ポリシーを適用して、GitHub Enterprise Cloud で Enterprise が所有する Organization のセキュリティ設定を制御できます。 既定では、Organization の所有者はセキュリティ設定を管理できます。

Enterprise で Organization に対して 2 要素認証を必須にする

注: 2023 年 3 月から 2023 年末まで、GitHub では段階的に、GitHub.com でコードを投稿するすべてのユーザーに、1 つ以上の形式の 2 要素認証 (2FA) を有効にすることをお願いします。 該当するグループに属してるユーザーは、そのグループが登録対象として選択されると通知メールを受け取り、45 日間の 2FA 登録期間が開始されて、GitHub.com での 2FA への登録を求めるバナーが表示されます。 通知を受け取らないユーザーは、2FA を有効にする必要があるグループには含まれませんが、有効にすることを強くお勧めします。

2FA 登録のロールアウトについて詳しくは、こちらのブログ記事をご覧ください。

Enterprise 所有者は、Enterprise が所有するすべての組織の Organization メンバー、支払いマネージャー、外部コラボレーターに対して、ユーザー アカウントをセキュリティで保護するために 2 要素認証を使用することを要求できます。このポリシーは、マネージド ユーザーを含む Enterprise には使用できません。

Enterprise が所有するすべての Organization で 2 要素認証を要求する前に、所有者自身のアカウントの 2 要素認証を有効にする必要があります。 詳しくは、「2 要素認証でアカウントを保護する」を参照してください。

警告:

  • Enterprise で 2 要素認証を要求すると、Enterprise が所有するすべての Organization 内のメンバー、外部コラボレーター、支払いマネージャー (ボットアカウントを含む) で、2 要素認証を使わないものは、Organization から削除され、そのリポジトリにアクセスできなくなります。 Organization のプライベートリポジトリのフォークへのアクセスも失います。 Organization から削除されてから 3 か月以内にユーザーが自分のアカウントで 2 要素認証を有効にすれば、そのユーザーのアクセス特権と設定を復帰できます。 詳しくは、「組織の以前のメンバーの回復」を参照してください。
  • 2 要素認証の要求を有効にした後、その Enterprise アカウントで所有されるすべての Organization の所有者、メンバー、支払いマネージャー、または外部コラボレーターが、各自のアカウントで 2 要素認証を無効にすると、Organization から自動的に削除されます。
  • 2 要素認証を要求するエンタープライズに所有者が 1 人しかいない場合は、エンタープライズに対する 2 要素認証の要求を無効にしない限り、所有者のユーザー アカウントの 2 要素認証を無効にすることはできません。

2 要素認証の使用を義務化する前に、Organization のメンバー、外部コラボレーター、支払いマネージャーに通知をして、各自に自分のアカウントで 2 要素認証をセットアップしてもらってください。 Organization のオーナーは、メンバーと外部コラボレーターがすでに 2 要素認証を使用しているかどうかを、各 Organization の [People] ページで確認できます。 詳しくは、「Organization 内のユーザが 2 要素認証を有効にしているかどうかを表示する」を参照してください。

: Organization 内の一部のユーザーは、GitHub.com による必須の 2 要素認証登録に選ばれている可能性がありますが、Enterprise の Organization に対する 2FA の要件を有効にする方法には影響しません。 Enterprise の Organization で 2FA の要件を有効にした場合、現在 2FA が有効になっていないすべてのユーザーは、GitHub.com によって有効にされる必要があるユーザーも含めて、Organization から削除されます。

  1. GitHub.com の右上の自分のプロファイル写真をクリックし、 [自分の Enterprise] をクリックします。

  2. Enterpriseのリストで、表示したいEnterpriseをクリックしてください。

  3. Enterprise アカウントのサイドバーで、 [設定] をクリックします。

  4. [設定] で、 [認証セキュリティ] をクリックします。

  5. [Two-factor authentication] で、設定変更に関する情報を確認します。 必要に応じて、設定を変更する前に Enterprise アカウントのすべての Organization の現在の構成を確認するには、 [Organization の現在の構成を表示する] をクリックします。

    Enterprise 設定のポリシーのスクリーンショット。 [Organization の現在の構成を表示する] というラベルの付いたリンクが、オレンジ色の枠線で強調表示されています。

  6. [2 要素認証] で、 [会社のすべての Organizations に 2 要素認証を要求する] をオンにして、 [保存] をクリックします。

  7. メッセージが表示されたら、Enterprise が所有する Organization から削除されるメンバーと外部コラボレーターに関する情報を読みます。 変更を確定するには、Enterprise の名前を入力して、 [メンバーを削除し、2 要素認証を必須にする] をクリックします。

  8. Enterprise によって所有される Organization から削除されるメンバーまたは外部コラボレーターがいる場合、Organization への元の権限とアクセス権を復帰するための招待状を、それらのユーザーに送信することをお勧めします。 彼らが招待状を受け取ることができるようにするには、まず各ユーザーが 2 要素認証を有効にする必要があります。

Enterprise の SSH 証明機関を管理する

SSH 証明機関 (CA) を使うと、Enterprise が所有するすべての Organization のメンバーに、指定した SSH 証明書を使ってその Organization のリポジトリにアクセスするのを許可できます。 SSHがリポジトリで無効になっていなければ、Organizationのリソースにメンバーがアクセスする際に、SSH証明書を使わなければならないようにすることができます。詳しくは、「SSH認証局について」をご覧ください。

各クライアント証明書を発行する際には、その証明書がどのGitHub Enterprise Cloudユーザー用かを示すエクステンションを含める必要があります。 詳しくは、「SSH認証局について」を参照してください。

SSH認証局を追加する

Enterprise に SSH 証明書が必要な場合、Enterprise メンバーは SSH 経由の Git 操作に特別な URL を使用する必要があります。 詳しくは、「SSH認証局について」を参照してください。

各証明機関は、GitHub.com 上の 1 つのアカウントにのみアップロードできます。 SSH 証明機関が Organization または Enterprise アカウントに追加されている場合、GitHub.com 上の別の Organization または Enterprise アカウントに同じ証明機関を追加することはできません。

1 つの証明機関を Enterprise に追加し、もう 1 つの証明機関を Enterprise 内の Organization に追加する場合は、いずれかの証明機関を使用して Organization のリポジトリにアクセスできます。

  1. GitHub.com の右上の自分のプロファイル写真をクリックし、 [自分の Enterprise] をクリックします。

  2. Enterpriseのリストで、表示したいEnterpriseをクリックしてください。

  3. Enterprise アカウントのサイドバーで、 [設定] をクリックします。

  4. [設定] で、 [認証セキュリティ] をクリックします。

  5. [SSH 認証局] の右側にある [新しい CA] をクリックします。

  6. "Key(キー)"の下で、公開SSHキーを貼り付けてください。

  7. [CA の追加] をクリックします。

  8. 必要に応じて、メンバーに SSH 証明書の使用を要求するには、 [SSH 証明書を要求する] を選択し、 [保存] をクリックします。

    注: SSH 証明書が必要な場合、ユーザーは HTTPS または未署名の SSH キーを使用して組織のリポジトリにアクセスするための認証を行うことができなくなります (SSH キーが外部 ID システムを介した認証を必要とする組織に対して承認されているかどうかは無関係です)。

    その要件は承認された OAuth appsと GitHub Apps (ユーザーからサーバーへのトークンを含む)、またはデプロイ キーや GitHub エコシステム内の信頼された環境である GitHub Actions と Codespaces などの GitHub 機能には適用されません。

SSH認証局を削除する

CAを削除すると、元に戻すことはできません。 同じCAを使用したくなった場合には、そのCAを再びアップロードする必要があります。

  1. GitHub.com の右上の自分のプロファイル写真をクリックし、 [自分の Enterprise] をクリックします。

  2. Enterpriseのリストで、表示したいEnterpriseをクリックしてください。

  3. Enterprise アカウントのサイドバーで、 [設定] をクリックします。

  4. [設定] で、 [認証セキュリティ] をクリックします。

  5. [SSH 認証局] で、削除する CA の右側にある [削除] をクリックします。

  6. 警告を読み、 [わかりました。この CA を削除してください] をクリックします。

認証されていないユーザーに対する SSO の管理

注: 現在、サインインへのユーザーの自動リダイレクトは Enterprise Managed Users のベータ版であり、変更される可能性があります。

Enterprise で Enterprise Managed Users を使用している場合は、認証されていないユーザーが Enterprise のリソースにアクセスしようとしたときに表示される内容を選ぶことができます。 Enterprise Managed Users について詳しくは、「Enterprise Managed Users について」をご覧ください。

既定では、プライベート リソースの存在を隠すために、認証されていないユーザーがお客様の Enterprise にアクセスしようとすると、GitHub に 404 エラーが表示されます。

開発者の混乱を防ぐために、ID プロバイダー (IdP) を介してユーザーがシングル サインオン (SSO) に自動的にリダイレクトされるように、この動作を変更できます。 自動リダイレクトを有効にすると、Enterprise のリソースのいずれかの URL にアクセスするすべてのユーザーは、リソースが存在することを確認できます。 しかし、リソースを確認できるのは、IdP で認証した後に適切なアクセス権を持っている場合のみです。

注: ユーザーが Enterprise のいずれかのリソースにアクセスしようとしたときに個人アカウントにサインインすると、自動的にサインアウトされ、SSO にリダイレクトされ、マネージド ユーザー アカウント にサインインすることになります。 詳しくは、「複数のアカウントの管理」を参照してください。

  1. GitHub.com の右上の自分のプロファイル写真をクリックし、 [自分の Enterprise] をクリックします。

  2. Enterpriseのリストで、表示したいEnterpriseをクリックしてください。

  3. Enterprise アカウントのサイドバーで、 [設定] をクリックします。

  4. [設定] で、 [認証セキュリティ] をクリックします。

  5. [シングル サインオン設定] で、 [ユーザーをサインインに自動的にリダイレクトする] を選択または選択解除します。

参考資料