このガイドについて
このガイドでは、アカウントのセキュリティを強化するために行うことができる影響が最も大きい変更について説明します。 各セクションで、セキュリティを向上させるためにプロセスに対して行うことができる変更の概要を示します。 変更は影響が大きい順に示されます。
リスクとは
アカウントのセキュリティは、サプライ チェーンのセキュリティの基礎となります。 攻撃者が GitHub 上のユーザーのアカウントを乗っ取ることができると、コードやビルド プロセスに悪意のある変更を加えることができます。 したがって、最初の目標としては 組織 のお使いのアカウントと他の メンバー に対する乗っ取りを困難にする必要があります。
2 要素認証の構成
注: 2023 年 3 月より、GitHub では、GitHub.com でコードを投稿するすべてのユーザーに、1 つ以上の形式の 2 要素認証 (2FA) を有効にすることが求められます。 該当するグループに属しているユーザーは、そのグループが登録対象として選択されると通知メールを受け取り、45 日間の 2FA 登録期間が開始されて、GitHub.com での 2FA への登録を求めるバナーが表示されます。 通知を受け取らないユーザーは、2FA を有効にする必要があるグループには含まれませんが、有効にすることを強くお勧めします。
2FA 登録のロールアウトについて詳しくは、こちらのブログ記事をご覧ください。
個人用アカウント のセキュリティを向上させる最善の方法は、2 要素認証 (2FA) を構成することです。 パスワード自体は、推測しやすいこと、侵害された別のサイトでも利用されていたこと、またはフィッシングなどのソーシャル エンジニアリングによって侵害される可能性があります。 2FA を使用すると、攻撃者がパスワードを取得した場合でさえ、アカウントの侵害がはるかに困難になります。
ベスト プラクティスとして、セキュリティと、アカウントへの信頼できるアクセスを両方確保するため、第 2 認証要素の資格情報を常に 2 つはアカウントに登録してください。 資格情報を追加することで、1 つの資格情報が使えなくなったとしても、アカウントから閉め出されることがありません。
また、可能な限り、SMS を使うのではなく、認証アプリ (TOTP アプリという名前です)で、 パスキーおよび セキュリティ キーとを選んでください。 SMS ベースの 2FA アプリと TOTP アプリはどちらもフィッシングに対して脆弱であり、 パスキー および セキュリティ キーと同じレベルの保護を提供しません。 SMS は、NIST 800-63B デジタル ID ガイドラインでは推奨されなくなりました。
組織の所有者であれば、組織のすべてのメンバーが 2FA を有効化することを要求できます。
自分のアカウントで 2FA を有効にする方法について詳しくは、「2 要素認証を設定する」をご覧ください。 自分の組織で 2FA を要求する方法について詳しくは、「Organization で 2 要素認証を要求する」をご覧ください。
個人アカウントの構成
GitHub では、2FA のオプションがいくつかサポートされています。どれも何もしないよりも効果がありますが、最も安全なオプションは WebAuthn 認証情報です。 WebAuthn には、FIDO2 ハードウェア セキュリティ キー、Windows Hello などのプラットフォーム認証子、Apple の携帯または Google の携帯、パスワード マネージャーなどの認証子が必要です。 他の形式の 2FA であればフィッシングは困難とはいえ可能です (たとえば、6 桁のワンタイム パスワードを読み上げるように誰かに頼まれるなど)。 ただし、WebAuthn のフィッシングに対してもっと耐性があります。ドメイン スコープがプロトコルに組み込まれているため、ログイン ページを偽装する Web サイトの認証情報が GitHub で使用されるのを妨げるためです。
2FA を設定するときは、必ず回復コードをダウンロードし、複数の 2FA 認証情報を設定する必要があります。 こうすることで、アカウントへのアクセスが 1 つのデバイスに依存しなくなります。 詳細については、「2 要素認証を設定する」および「2 要素認証リカバリ方法を設定する」を参照してください。
組織アカウントの構成
組織の所有者であれば、どのユーザーの 2FA が有効になっていないかを確認し、設定を支援してから、組織の 2FA を要求することができます。 そのプロセスの手順については、次を参照してください。
SSH キーを使用した GitHub への接続
Web サイトにサインインする以外に GitHub とやり取りする他の方法があります。 多くのユーザーは、SSH 秘密キーを使用して GitHub にプッシュするコードを承認します。 詳しくは、「SSH について」を参照してください。
アカウントのパスワードと同様に、攻撃者が SSH 秘密キーを取得できた場合は、ユーザーを偽装し、ユーザーが書き込みアクセス権を持つ任意のリポジトリに悪意のあるコードをプッシュする可能性があります。 SSH 秘密キーをディスク ドライブに保存する場合は、パスフレーズで保護することをお勧めします。 詳しくは、「SSH キーのパスフレーズを使う」を参照してください。
もう 1 つのオプションは、ハードウェア セキュリティ キーに SSH キーを生成することです。 2FA で使用しているのと同じキーを使用できます。 ハードウェア セキュリティ キーをリモートで侵害することは非常に困難です。SSH 秘密キーはハードウェア上に残っており、ソフトウェアから直接アクセスすることはできないためです。 詳しくは、「新しい SSH キーを生成して ssh-agent に追加する」を参照してください。