このガイドについて
このガイドでは、アカウントのセキュリティを強化するために行うことができる影響が最も大きい変更について説明します。 各セクションで、セキュリティを向上させるためにプロセスに対して行うことができる変更の概要を示します。 変更は影響が大きい順に示されます。
リスクとは
アカウントのセキュリティは、サプライ チェーンのセキュリティの基礎となります。 攻撃者が GitHub AE 上のユーザーのアカウントを乗っ取ることができると、コードやビルド プロセスに悪意のある変更を加えることができます。 したがって、最初の目標として、自分自身のアカウントおよび自分の Organization または Enterprise の他のメンバーのアカウントの乗っ取りを困難にする必要があります。
2 要素認証の構成
GitHub AE 上の Enterprise のセキュリティを向上するために最適な方法は、SAML ID プロバイダー (IdP) で 2 要素認証 (2FA) を構成することです。 パスワード自体は、推測しやすいこと、侵害された別のサイトでも利用されていたこと、またはフィッシングなどのソーシャル エンジニアリングによって侵害される可能性があります。 2FA を使用すると、攻撃者がパスワードを取得した場合でさえ、アカウントの侵害がはるかに困難になります。
ベスト プラクティスとして、セキュリティと、アカウントへの信頼できるアクセスを両方確保するため、第 2 認証要素の資格情報を常に 2 つはアカウントに登録してください。 資格情報を追加することで、1 つの資格情報が使えなくなったとしても、アカウントから閉め出されることがありません。
SSH キーを使用した GitHub AE への接続
IdP を介して Web サイトにサインインする以外に GitHub AE とやり取りする他の方法があります。 多くのユーザーは、SSH 秘密キーを使用して GitHub にプッシュするコードを承認します。 詳しくは、「SSH について」を参照してください。
IdP アカウントのパスワードと同様に、攻撃者が SSH 秘密キーを取得できた場合は、ユーザーを偽装し、ユーザーが書き込みアクセス権を持つ任意のリポジトリに悪意のあるコードをプッシュする可能性があります。 SSH 秘密キーをディスク ドライブに保存する場合は、パスフレーズで保護することをお勧めします。 詳しくは、「SSH キーのパスフレーズを使う」を参照してください。
もう 1 つのオプションは、ハードウェア セキュリティ キーに SSH キーを生成することです。 2FA で使用しているのと同じキーを使用できます。 ハードウェア セキュリティ キーをリモートで侵害することは非常に困難です。SSH 秘密キーはハードウェア上に残っており、ソフトウェアから直接アクセスすることはできないためです。 詳しくは、「新しい SSH キーを生成して ssh-agent に追加する」を参照してください。
ハードウェア対応の SSH キーはきわめて安全ですが、組織によってはハードウェア要件が合わない場合があります。 代わりの方法は、短期間だけ有効な SSH キーを使用することです。そのため、秘密キーが侵害された場合でも、長い間悪用されることはありません。 これが、独自の SSH 証明機関を実行する背後にある概念です。 この方法によって、ユーザーの認証方法を細かく制御できるようになりますが、SSH 証明機関を自身で管理する責任を伴います。 詳しくは、「SSH認証局について」を参照してください。