このガイドについて
このガイドでは、アカウントのセキュリティを強化するために行うことができる影響が最も大きい変更について説明します。 各セクションで、セキュリティを向上させるためにプロセスに対して行うことができる変更の概要を示します。 変更は影響が大きい順に示されます。
リスクはどのくらいですか?
アカウントのセキュリティは、サプライ チェーンのセキュリティの基礎となります。 攻撃者が GitHubでアカウントを引き継ぐ可能性がある場合は、コードまたはビルド プロセスに悪意のある変更を加える可能性があります。 したがって、最初の目標は、自分のアカウントや、あなたの組織または企業の他のメンバーのアカウントを乗っ取りにくくすることです。
認証の一元化
企業または組織の所有者は、SAML を使用して一元化された認証を構成できます。 メンバーは手動で追加または削除できますが、 GitHub と SAML ID プロバイダー (IdP) の間でシングル サインオン (SSO) と SCIM を設定する方が簡単で安全です。 これにより、エンタープライズのすべてのメンバーの認証プロセスも簡略化されます。
エンタープライズ アカウントまたは組織アカウントに対して SAML 認証を構成できます。 SAML を使用すると、IdP を使用して、 GitHub 上の企業または組織のメンバーの個人アカウントへのアクセスを許可したり、 Enterprise Managed Usersを使用して企業に属するアカウントを作成および制御したりできます。 詳しくは、「ID とアクセス管理の基礎」をご覧ください。
SAML認証を構成した後、メンバーがリソースへのアクセスを要求すると、SSOフローにリダイレクトされ、IdPによって認識されていることを確認することになります。 認識されていない場合、要求は拒否されます。
一部の IdP では SCIM と呼ばれるプロトコルがサポートされています。これは、IdP に変更を加えたときに、 GitHub のアクセスを自動的にプロビジョニングまたはプロビジョニング解除できます。 SCIM を使用すると、チームの成長に合わせて管理を簡素化し、アカウントに対するアクセス権をすばやく取り消すことができます。 SCIM は、 GitHub Enterprise上の個々の組織、または Enterprise Managed Usersを使用する企業で使用できます。 詳しくは、「組織におけるSCIMについて」をご覧ください。
2 要素認証の構成
メモ
2023 年 3 月より、GitHub では、GitHub.com でコードを投稿するすべてのユーザーに、1 つ以上の形式の 2 要素認証 (2FA) を有効にすることが求められます。 該当するグループに属しているユーザーは、そのグループが登録対象として選択されると通知メールを受け取り、45 日間の 2FA 登録期間が開始されて、GitHub.com での 2FA への登録を求めるバナーが表示されます。 通知を受け取らないユーザーは、2FA を有効にする必要があるグループには含まれませんが、有効にすることを強くお勧めします。
2FA 登録のロールアウトについて詳しくは、こちらのブログ記事をご覧ください。
アカウントのセキュリティを向上させる最善の方法は、2 要素認証 (2FA) を構成することです。 パスワード自体は、推測しやすいこと、侵害された別のサイトでも利用されていたこと、またはフィッシングなどのソーシャル エンジニアリングによって侵害される可能性があります。 2FA を使用すると、攻撃者がパスワードを取得した場合でさえ、アカウントの侵害がはるかに困難になります。
ベスト プラクティスとして、セキュリティと、アカウントへの信頼できるアクセスを両方確保するため、第 2 認証要素の資格情報を常に 2 つはアカウントに登録してください。 追加の資格情報により、1 つの資格情報へのアクセスが失われても、アカウントからロックアウトされなくなります。
また、可能な限り、認証アプリ (TOTP アプリと呼ばれる) でパスキーやセキュリティ キーを使い、SMS を使うのは避けてください。 SMS ベースの 2FA アプリと TOTP アプリはどちらもフィッシングに対して脆弱であり、パスキーやセキュリティ キーと同じレベルの保護を提供しません。 SMS は、NIST 800-63B デジタル ID ガイドラインでは推奨されなくなりました。
組織内のサービス アカウントが GitHubによって 2FA 登録用に選択されている場合、そのトークンとキーは期限後も中断することなく引き続き機能します。 アカウントで 2FA が有効になるまで、Web サイト UI を介した GitHub へのアクセスのみがブロックされます。 サービス アカウントの第 2 認証要素として TOTP を設定し、会社のパスワード共有マネージャーで設定中に表示される TOTP シークレットを保存すること、シークレットへのアクセスは SSO で制御することをお勧めします。
エンタープライズ所有者の場合は、企業が所有するすべての組織に対して 2FA を要求するようにポリシーを構成できる場合があります。
組織の所有者である場合は、組織のすべてのメンバーが 2FA を有効にすることを要求できます。
自分のアカウントで 2FA を有効にする方法について詳しくは、「2 要素認証を設定する」をご覧ください。 自分の organization で 2FA を要求する方法について詳しくは、「Organization で 2 要素認証を要求する」をご覧ください。
エンタープライズ アカウントの構成
エンタープライズ所有者は、エンタープライズ のメンバー上のすべてのに対して 2FA を要求できる場合があります。 GitHubで 2FA ポリシーを利用できるかどうかは、メンバーがエンタープライズのリソースにアクセスする際の認証方法によって異なります。
エンタープライズで Enterprise Managed Users を使用している場合、またはエンタープライズで SAML 認証が強制されている場合、GitHub で 2FA を設定することはできません。 IdP の管理アクセス権を持つユーザーが、IdP に対して 2FA を構成する必要があります。
詳細については、「 エンタープライズ IAM の SAML について と Enterprise でセキュリティ設定のポリシーを適用する」を参照してください。
個人アカウントの構成
メモ
エンタープライズ所有者サイト管理者認証方法によっては、個人アカウントに対して 2FA を有効にできない場合があります。
GitHub は 2FA のいくつかのオプションをサポートしており、いずれのオプションも何もないよりも優れていますが、最も安全なオプションは WebAuthn 資格情報です。 WebAuthn には、FIDO2 ハードウェア セキュリティ キー、Windows Hello などのプラットフォーム認証子、Apple の携帯または Google の携帯、パスワード マネージャーなどの認証子が必要です。 他の形式の 2FA であればフィッシングは困難とはいえ可能です (たとえば、6 桁のワンタイム パスワードを読み上げるように誰かに頼まれるなど)。 ただし、WebAuthn は、ドメイン スコープがプロトコルに組み込まれているため、ログイン ページを偽装する Web サイトからの資格情報が GitHubで使用されるのを防ぐため、フィッシングに対してはるかに耐性があります。
2FA を設定するときは、必ず回復コードをダウンロードし、複数の 2FA 認証情報を設定する必要があります。 こうすることで、アカウントへのアクセスが 1 つのデバイスに依存しなくなります。 詳細については、「2 要素認証を設定する」および「2 要素認証リカバリ方法を設定する」を参照してください。
組織アカウントの構成
メモ
エンタープライズ所有者サイト管理者認証方法によっては、組織に 2FA を要求できない場合があります。
組織の所有者であれば、どのユーザーの 2FA が有効になっていないかを確認し、設定を支援してから、組織の 2FA を要求することができます。 そのプロセスの手順については、次を参照してください。
SSH キーを使用して GitHub に接続する
Web サイトにサインインする以外にも、 GitHub を操作する方法は他にもあります。 多くのユーザーは、SSH 秘密キーを使用して GitHub にプッシュするコードを承認します。 詳しくは、「SSH について」をご覧ください。
アカウントのパスワードと同様に、攻撃者が SSH 秘密キーを取得できた場合は、ユーザーを偽装し、ユーザーが書き込みアクセス権を持つ任意のリポジトリに悪意のあるコードをプッシュする可能性があります。 SSH 秘密キーをディスク ドライブに保存する場合は、パスフレーズで保護することをお勧めします。 詳しくは、「SSH キーのパスフレーズを扱う」をご覧ください。
もう 1 つのオプションは、ハードウェア セキュリティ キーに SSH キーを生成することです。 2FA で使用しているのと同じキーを使用できます。 ハードウェア セキュリティ キーをリモートで侵害することは非常に困難です。SSH 秘密キーはハードウェア上に残っており、ソフトウェアから直接アクセスすることはできないためです。 詳しくは、「新しい SSH キーを生成して ssh-agent に追加する」をご覧ください。
ハードウェアベースの SSH キーは非常に安全ですが、一部の組織ではハードウェア要件が機能しない可能性があります。 代わりの方法は、短期間だけ有効な SSH キーを使用することです。そのため、秘密キーが侵害された場合でも、長い間悪用されることはありません。 これが、独自の SSH 証明機関を実行する背後にある概念です。 この方法によって、ユーザーの認証方法を細かく制御できるようになりますが、SSH 証明機関を自身で管理する責任を伴います。 詳しくは、「SSH認証局について」をご覧ください。