Skip to main content

Enterprise の認証について

GitHub Enterprise Cloud 上にある Enterprise のリソースにユーザーがアクセスできるようにユーザーを認証する方法を選ぶことができます。

Enterprise の認証について

GitHub Enterprise Cloud の Enterprise 所有者は、Enterprise のリソースに対する認証とアクセスに関する要件を制御できます。

メンバーがユーザー アカウントを作成して管理できるようにするか、Enterprise で Enterprise Managed Users を使用してメンバーのアカウントを作成、管理できるようにするかを選ぶことができます。 メンバーが自分のアカウントを管理できるようにする場合は、SAML 認証を構成して、チームで使用される Web アプリケーションのセキュリティを強化し、ID とアクセスを一元化することもできます。

これらのオプションの詳しい情報を学習した後、Enterprise に最適な方法を決定するには、「Enterprise に最適な認証方法を特定する」を参照してください。

GitHub Enterprise Cloud の認証方法

GitHub Enterprise Cloud のアカウント管理と認証には、次のオプションを使用できます。

GitHub.com による認証

既定では、各メンバーは GitHub.com に個人アカウントを作成する必要があります。 Enterprise へのアクセス権を付与すると、メンバーは GitHub.com のアカウントにサインインした後、Enterprise のリソースにアクセスできます。 メンバーはアカウントを管理し、GitHub.com の他の Enterprise、Organization、リポジトリに投稿できます。

追加の SAML アクセス制限を使用した GitHub.com による認証

追加の SAML アクセス制限を構成する場合は、各メンバーが GitHub.com の個人アカウントを作成して管理する必要があります。 Enterprise へのアクセス権を付与すると、メンバーは GitHub.com のアカウントにサインインし、SAML ID プロバイダー (IdP) で正常に認証した後に、Enterprise のリソースにアクセスできます。 メンバーは個人アカウントを使用して、GitHub.com の他の Enterprise、Organization、リポジトリに投稿できます。 Enterprise のリソースへのすべてのアクセスに SAML 認証を要求する方法について詳しくは、「Enterprise IAM の SAML について」を参照してください。

GitHub Enterprise Cloud でスタンドアロン Organization を使用する場合、または Enterprise 内のすべての Organization に対して SAML 認証を使用しない場合は、個々の Organization に対して SAML を構成できます。 詳細については、「SAML シングル サインオンを使うアイデンティティおよびアクセス管理について」を参照してください。

Enterprise Managed Users とフェデレーションを使用した認証

GitHub.com の Enterprise メンバーのアカウントをより細かく制御する必要がある場合は、Enterprise Managed Users を使用できます。 Enterprise Managed Users では、IdP を使用し、GitHub.com の Enterprise メンバーのアカウントをプロビジョニングして管理します。 作成されたアカウントに各メンバーがサインインすると、Enterprise でそのアカウントが管理されます。 GitHub.com の残りの部分への投稿は制限されています。 詳細については、「Enterprise Managed Users について」を参照してください。

Enterprise に最適な認証方法を特定する

SAML SSO と Enterprise Managed Users の両方で、Enterprise のリソースのセキュリティが強化されます。 さらに、Enterprise Managed Users を使用すると、Enterprise メンバーのユーザー アカウントを管理し、アカウントで実行できる操作を制限できます。 ただし、これらの制限によって開発者のワークフローが妨げられる場合、Enterprise ではそれらを受け入れられないことがあります。

Enterprise が SAML SSO と Enterprise Managed Users のどちらから、より多くのメリットを得られるかを判断するには、これらの質問を自問してください。

ユーザーのユーザー アカウントを自分で管理したいか?

Enterprise Managed Users は、Enterprise メンバーが GitHub.com で自分の個人アカウントを使って Enterprise のリソースにアクセスすることを望まない場合に、適している可能性があります。

SAML SSO を使用すると、開発者は自分の個人アカウントを作成して管理でき、各アカウントは IdP の SAML ID にリンクされます。 Enterprise Managed Users は、ご自身でユーザーのアカウントをプロビジョニングするため、他の使い慣れた SSO ソリューションと同様に機能します。 また、ユーザー名とアカウントに関連付けられるメール アドレスを管理することで、ユーザー アカウントが会社の ID に準拠していることを確実にすることもできます。

現在、ユーザーに対して、GitHub.com で新しいアカウントを作成して Enterprise でのみ使用するように要求している場合は、Enterprise Managed Users が適している可能性があります。 ただし、IdP をユーザー向けの信頼できるソースとして使用し、アクセス管理が複雑すぎる場合は、SAML SSO の方が適切なオプションである可能性があります。 たとえば、IdP で新しいユーザーをオンボードするための確立されたプロセスが Enterprise にない場合があります。

Enterprise でどの ID プロバイダーを使用するか?

Enterprise Managed Users がサポートされている IdP の数は限られています。SAML SSO を使用すると、多数の IdP に対する完全なサポートと、SAML 2.0 標準を実装しているすべての IdP に対する制限付きサポートが提供されます。 各オプションでサポートされている IdP の一覧については、「Enterprise Managed Users について」および「Enterprise IAM の SAML について」を参照してください。

サポートされていない IdP で Enterprise Managed Users を使用できるのは、サポートされていない IdP をサポートされている IdP にフェデレーションして統合ポイントとして使用する場合のみです。 このような余分な複雑さを避けたい場合は、SAML SSO の方が優れたソリューションになる可能性があります。

開発者はパブリック リポジトリ、gist、GitHub Pages サイトのどれで作業するか?

Enterprise メンバーが誤って GitHub.com で Enterprise 所有のコンテンツを一般に漏洩させることがないように、Enterprise Managed Users では、ユーザーが実行できる操作に対して強力な制限が課されます。 たとえば、managed user accounts では、パブリック リポジトリ、任意の可視性を持つ gist、または Enterprise 外部で閲覧できる GitHub Pages サイトを作成することはできません。 制限の完全な一覧については、「managed user accounts の機能と制限」を参照してください。

これらの制限が受け入れらない Enterprise もあります。 Enterprise Managed Users がご自身に適しているかどうかを判断するには、開発者と共に制限事項を確認し、いずれかの制限によって既存のワークフローが妨げられるかどうかを確認します。 該当する場合は、お使いの Enterprise には SAML SSO が適している可能性があります。

開発者は Enterprise 外部のコラボレーションに依存しているか?

Managed user accounts では、Enterprise 内部のリポジトリにのみ投稿できます。 開発者がプライベート リポジトリを含め、エンタープライズ内と外部の両方のリポジトリに投稿する必要がある場合、Enterprise Managed Usersはエンタープライズに適していない可能性があります。 SAML SSO の方が優れたソリューションになる可能性があります。

一部の会社では、GitHub.com に SAML SSO を使用して既存のエンタープライズ内のリポジトリを保持し、enterprise with managed usersも作成します。 1 つのワークステーションから両方のエンタープライズによって所有されるリポジトリに投稿する開発者は、1 つのブラウザー内で GitHub.com のアカウントを切り替えるか、アカウントごとに異なるブラウザーを使用する必要があります。 開発者は、2 つのアカウントに対応するようにワークステーションの Git 構成をカスタマイズする必要がある場合もあります。 このワークフローの複雑さは、内部コードを誤って一般に漏洩させるリスクを高める可能性があります。

enterprise with managed usersを作成する場合に、開発者が 1 つのワークステーションからエンタープライズ外のリソースに投稿する必要がある場合は、開発者のローカル Git 構成でアカウントを切り替えるためのサポートを提供できます。 詳細については、「Enterprise Managed Users について」を参照してください。

Enterprise は外部のコラボレーターに依存しているか?

SAML SSO を使用すると、外部コラボレーター ロールを使用して、IdP のディレクトリのメンバーではないユーザーに特定のリポジトリへのアクセスを許可できます。 これは、社外のコラボレーター (請負業者など) に対して特に役立ちます。 詳しい情報については、「外部のコラボレーターを Organization のリポジトリに追加する」を参照してください。

Enterprise Managed Users の場合、外部コラボレーター ロールは存在しません。 Enterprise のリソースには、常に IdP によってプロビジョニングされる managed user accounts のみがアクセスできます。 外部コラボレーターに Enterprise へのアクセスを許可するには、IdP でゲスト アカウントを使用する必要があります。 Enterprise Managed Users に関心がある場合は、開発者に、これによって既存のワークフローが妨げられるかどうかを確認してください。 該当する場合は、SAML SSO の方が優れたソリューションになる可能性があります。

会社が移行コストを許容できるか?

会社で GitHub.com を初めて使用する場合、SAML SSO と Enterprise Managed Users は同じように簡単に導入できます。

既に GitHub.com を使用していて、開発者が各自のユーザー アカウントを管理している場合は、Enterprise Managed Users を導入するには、新しい Enterprise アカウントに移行する必要があります。 詳しい情報については、「managed user accounts を含む Enterprise について」を参照してください。

Enterprise Managed Users は無料ですが、移行プロセスにはチームの時間またはコストが必要になる場合があります。 この移行プロセスが、ご自身のビジネスと開発者に許容されることを確認してください。 そうでない場合は、SAML SSO が適している可能性があります。

参考資料