GitHub 認証のしくみ

  • 6 分

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

GitHub の認証オプション

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

ユーザー名とパスワード

管理者は、ユーザーに既定のユーザー名とパスワードの認証方法 ("基本" の HTTP 認証スキームとも呼ばれる) を使用し続けること許可することができます。 近年、基本認証は機密性の高い情報を扱うにはリスクが高すぎることが実証されているため、このユニットに一覧表示されている他のオプションのいずれか (またはいくつか) を使用することを強くお勧めします。

個人用アクセス トークン

Screenshot of the personal access token screen.

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

SSH キー

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

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

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

デプロイ キー

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

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

GitHub では、次の追加のセキュリティ オプションも提供されます。

2 要素認証

Screenshot of the two-factor authentication screen.

2 要素認証 (2FA) は多要素認証 (MFA) とも呼ばれ、Web サイトまたはアプリにログインするときに使われるセキュリティの追加レイヤーです。 2FA では、ユーザーは自分のユーザー名とパスワードを使ってサインインし、本人だけがアクセスできる別の形式の認証を指定する必要があります。

GitHub の場合、認証の 2 番目の形式は、ユーザーのモバイル デバイス上のアプリケーションによって生成される、またはテキスト メッセージ (SMS) として送信されるコードです。 ユーザーが 2FA を有効した後で、GitHub アカウントに誰かがサインインしようとするといつでも、認証コードが GitHub によって生成されます。 ユーザーは、自分のパスワードがわかっていて、電話で認証コードにアクセスできる場合にのみ、アカウントにサインインできます。

Organization のオーナーは、Organization のメンバー、外部のコラボレーター、および支払いマネージャーに対して 2 要素認証を有効にするように要求することで、悪意のある攻撃者が Organization のリポジトリと設定にアクセスすることを難しくすることができます。

エンタープライズ所有者は、エンタープライズ アカウントによって所有されるすべての組織に対して特定のセキュリティ ポリシーを適用することもできます。

SAML SSO

ID プロバイダー (IdP) を使用してユーザーの ID とアプリケーションを一元的に管理している場合は、GitHub で組織のリソースを保護するために Security Assertion Markup Language (SAML) シングル サインオン (SSO) を構成できます。

この種の認証では、GitHub で組織およびエンタープライズ所有者に対して、リポジトリ、イシュー、pull request などの組織のリソースへのアクセスを制御し、セキュリティで保護する方法が提供されます。 Organization のオーナーは、SAML SSO を使用する Organization に GitHub ユーザーを招待できます。これにより、ユーザーは Organization へのコントリビューションができ、既存の ID とコントリビューションを GitHub に保持できるようになります。

ユーザーが SAML SSO を使用する組織内のリソースにアクセスすると、認証のために、GitHub によって、その組織の SAML IdP にリダイレクトされます。 IdP で自分のアカウントを使用して正常に認証された後、IdP によって、GitHub にリダイレクトされ、そこで組織のリソースにアクセスできます。

GitHub では、SAML 2.0 標準を実装するすべての ID プロバイダーに対して限定的なサポートが提供されています。たとえば次の一般的な ID プロバイダーが公式にサポートされています。

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

他にもあります。

LDAP

ライトウェイト ディレクトリ アクセス プロトコル (LDAP) は、ディレクトリ情報サービスにアクセスして保守するための一般的なアプリケーション プロトコルです。 LDAP を使用すると、既存のアカウントに対して GitHub Enterprise Server を認証し、リポジトリへのアクセス権を一元的に管理できます。 それは、サードパーティのソフトウェアを大規模な企業ユーザー ディレクトリと統合するために最もよく使われるプロトコルの 1 つです。

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

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

他にもあります。