GitHub 認証のしくみ

完了

前のユニットでは、チーム、組織、エンタープライズ レベルでの一般的な管理タスクについて学習しました。 このユニットでは、組織の所有者によって実行される最も一般的な管理タスクの 1 つについて説明します。これは、GitHub に対するユーザーの認証の設定と制御です。

GitHub の認証オプション

GitHub に対して認証を行うためのオプションがいくつかあります。

ユーザー名とパスワード

管理者は、ユーザーに既定のユーザー名とパスワードの認証方法 ("基本" の HTTP 認証スキームとも呼ばれる) を使用し続けること許可することができます。

注

GitHub では、Git 操作または API の使用に対するパスワード認証がサポートされなくなりました。 このユニットに記載されている他のオプションのいずれか (または複数) を使用することを強くお勧めします。

個人用アクセス トークン

個人用アクセス トークン (PAT) は、GitHub API またはコマンド ラインを使用する場合に、GitHub に対する認証でパスワードの代わりに使用できます。 ユーザーは GitHub の設定オプションを使用してトークンを生成し、そのトークンの権限をリポジトリまたは組織に関連付けます。 ユーザーは、git コマンドライン ツールを使って GitHub とやりとりするとき、ユーザー名とパスワードの入力を求められたら、トークン情報を入力できます。

SSH キー

個人用アクセス トークンを使用する代わりに、ユーザーは SSH キーを使用して、SSH 経由でリモート サーバーおよびサービスに接続し、認証することができます。 SSH キーを使用すると、ユーザーは操作ごとにユーザー名と個人用アクセス トークンを指定する必要がなくなります。

SSH を設定する際に、ユーザーは SSH キーを生成して ssh-agent にそれを追加してから、そのキーを GitHub アカウントに追加します。 SSH キーを ssh-agent に追加すると、セキュリティを強化するレイヤーとして SSH キーにパスフレーズが確実に設定されます。 ユーザーは、パスフレーズを自動的に指定するように git のローカル コピーを構成するか、git コマンドライン ツールを使用して GitHub とやりとりするたびに手動で指定することができます。

SAML シングル サインオン (SSO) を使用する組織に所有されるリポジトリで、SSH キーを使用することさえできます。 組織によって SSH 証明書が提供される場合、ユーザーはその証明書を GitHub アカウントに追加することなく、組織のリポジトリにアクセスすることもできます。

デプロイ キー

デプロイ キーは、1 つのリポジトリへのアクセス権をユーザーに付与する、GitHub でのもう 1 つの種類の SSH キーです。 GitHub ではキーのパブリック部分を、個人用ユーザー アカウントではなくリポジトリに直接アタッチします。キーのプライベート部分はユーザーのサーバーに残ります。 デプロイ キーは既定では読み取り専用ですが、リポジトリに追加するときに書き込みアクセス権を付与することができます。

フォーク設定を構成するには:

1. リポジトリの [設定] に移動します。
2. 左側のサイドバーの [セキュリティ] で、[ キーのデプロイ] をクリックします。
3. [ デプロイ キーの追加] オプションを見つけて、新しいキーを作成します。

GitHub の追加されたセキュリティ オプション

GitHub には、アカウントと組織のリソースを保護するためのさまざまなセキュリティ オプションが用意されています。

2 要素認証

多要素認証 (MFA) とも呼ばれる 2 要素認証 (2FA) により、GitHub アカウントに保護レイヤーが追加されます。 2FA では、ユーザーはユーザー名とパスワードを使用してサインインし、2 番目の認証形式を提供します。

GitHub では、いくつかの第 2 要素オプションがサポートされています。

• 時間ベースのワンタイム コードを生成する認証アプリ (Microsoft Authenticator、Google Authenticator、Authy など)。
• FIDO2/WebAuthn をサポートするハードウェア セキュリティ キー (YubiKey や Titan セキュリティ キーなど)。
• パスワードレスでフィッシングに強い認証用のパスキー。
• SMS ベースのコード。これはサポートされていますが、他のオプションよりも安全性が低いと見なされ、主要な方法としては推奨されません。

2FA の適用:

• GitHub Team と GitHub Enterprise Cloud の組織の場合、組織の所有者は、メンバー、外部コラボレーター、課金マネージャーに対して、個人アカウントに対して 2FA を有効にすることを要求できます。
• Enterprise Managed Users (ESU) と GitHub Enterprise Server (GHE.com): 管理者はエンタープライズ管理アカウントに対してのみ 2FA を要求できますが、ユーザーの個人用 GitHub.com アカウントに 2FA を適用することはできません。

2FA を適用すると、承認されていないアクセスから組織を保護し、リポジトリと機密データのセキュリティを強化できます。

SAML SSO

ID プロバイダー (IdP) を使用してユーザーの ID を一元的に管理する場合は、GitHub で組織のリソースを保護するように SAML シングル サインオン (SSO) を構成できます。 SAML SSO を使用すると、組織と企業の所有者は、リポジトリ、問題、プル要求などのアクセスを制御してセキュリティで保護できます。 リソースにアクセスすると、GitHub によってユーザーがリダイレクトされ、組織の IdP で認証されます。

GitHub では、SAML 2.0 標準を実装するすべての ID プロバイダーがサポートされ、次のようないくつかの一般的なプロバイダーが公式にサポートされています。

• Active Directory フェデレーション サービス (AD FS)。
• Microsoft Entra ID。
• Okta。
• OneLogin。
• PingOne。

LDAP (GitHub Enterprise Server)

LDAP (ライトウェイト ディレクトリ アクセス プロトコル) は、ユーザー ディレクトリ情報にアクセスして管理するために広く使用されているプロトコルです。 GitHub Enterprise Server では、LDAP 統合を使用して、既存の会社のディレクトリに対してユーザーを認証し、リポジトリ アクセスを一元的に管理できます。

GitHub Enterprise Server は、次のような主要な LDAP サービスと統合されます。

GitHub Enterprise Server は、次のような一般的な LDAP サービスと統合されます。

• Active Directory。
• Oracle Directory Server Enterprise Edition。
• OpenLDAP。
• Open Directory。