このガイドについて
このガイドでは、アカウントのセキュリティを強化するために行うことができる影響が最も大きい変更について説明します。 各セクションで、セキュリティを向上させるためにプロセスに対して行うことができる変更の概要を示します。 変更は影響が大きい� �に示されます。
リスクとは
アカウントのセキュリティは、サプライ チェーンのセキュリティの基礎となります。 攻撃者が GitHub Enterprise Server 上のユーザーのアカウントを乗っ取ることができると、コードやビルド プロセスに悪意のある変更を� えることができます。 したがって、最初の目標としては、自分自身のアカウントおよび他ののユーザーのアカウントの乗っ取りを困難にする必要があります。
認証の一元化
のサイト管理者であれば、既存の ID プロバイダー (IdP) (CAS、SAML、LDAP など) と接続する認証方法を選択することで、ユーザーのログイン エクスペリエンスを簡� 化できます。 つまり、GitHub の追� のパスワードを記憶する必要がなくなります。
認証方法によっては、GitHub Enterprise Server への追� 情� � (たとえば、ユーザーがどのグループのメンバーであるかや、ユーザーの暗号化キーの同期など) の通信もサポートされます。 これは、組織の成長に合わせて管理を簡� 化する優れた方法です。
GitHub Enterprise Server で使用できる認証方法の詳細については、「Enterprise の認証について」を参照してく� さい。
2 要� 認証の構成
上の個人アカウントのセキュリティを向上するために最適な方法は、2 要� 認証 (2FA) を構成することです。 パスワード自体は、推測しやすいこと、侵害された別のサイトでも利用されていたこと、またはフィッシングなどのソーシャル エンジニアリングによって侵害される可能性があります。 2FA を使用すると、攻撃者がパスワードを取得した� �合でさえ、アカウントの侵害がはるかに困難になります。
のサイト管理者であれば、インスタンスのすべてのユーザーのために 2FA を構成できる� �合があります。 GitHub Enterprise Server 上で 2FA を使用できるかどうかは、使用する認証方法によって異なります。 詳細については、ユーザー認証の一元化に関するページを参照してく� さい。
組織の所有者であれば、組織のすべてのメンバーが 2FA を有効化することを要求できる� �合があります。
エンタープライズ アカウントの構成
エンタープライズの所有者は、インスタンスのすべてのユーザーに 2FA を要求できる� �合があります。 GitHub Enterprise Server 上で 2FA ポリシーを使用できるかどうかは、ユーザーがインスタンスにアクセスする際にどのように認証されるかによって異なります。
- CAS または SAML SSO を使用して外部 IdP から にサインインする� �合、 GitHub Enterprise Server 上で 2FA を構成することはできません。 IdP の管理アクセス権を持つユーザーが、IdP に対して 2FA を構成する必要があります。
- 外部 LDAP ディレクトリを介して にサインインする� �合、GitHub Enterprise Server 上でエンタープライズの 2FA を要求することができます。 ディレクトリ外部のユーザーの組み込み認証を許可する� �合、個々のユーザーは 2FA を有効にできますが、エンタープライズの 2FA を要求することはできません。
詳細については、「エンタープライズのセキュリティ設定にポリシーを適用する」を参照してく� さい。
個人アカウントの構成
注: サイト管理者がに対して構成した認証方法によっては、個人アカウントで 2FA を有効にすることができません。
GitHub Enterprise Server では、2FA のオプションがいくつかサポートされています。どれも何もしないよりも効果がありますが、最も安全なオプションは WebAuthn です。 WebAuthn では、ハードウェア セキュリティ キー、あるいは Windows Hello や Mac TouchID など、サポートするデバイスが必要です。 他の形式の 2FA であればフィッシングは困難とはいえ可能です (たとえば、6 桁のワンタイ� パスワードを読み上げるように誰かに� �まれるなど)。 た� し、WebAuthn のフィッシングは不可能です。ドメイン スコープがプロトコルに組み込まれているため、ログイン ページを偽装する Web サイトの資� �情� �が GitHub Enterprise Server で使用されるのを妨げるためです。
2FA を設定するときは、必ず回復コードをダウンロードし、複数の要� を設定する必要があります。 こうすることで、アカウントへのアクセスが 1 つのデバイスに依存しなくなります。 詳細については、「2 要� 認証の構成」、「2 要� 認証復旧方法の構成」、および GitHub ショップの GitHub ブランド ハードウェア セキュリティ キーを参照してく� さい。
組織アカウントの構成
注: サイト管理者がに対して構成した認証方法によっては、組織の 2FA を要求できません。
組織の所有者であれば、どのユーザーの 2FA が有効になっていないかを確認し、設定を支援してから、組織の 2FA を要求することができます。 そのプロセスの手� �については、次を参照してく� さい。
SSH キーを使用した GitHub Enterprise Server への接続
Web サイトにサインインする以外に GitHub Enterprise Server とやり取りする他の方法があります。 多くのユーザーは、SSH 秘密キーを使用して GitHub にプッシュするコードを承認します。 詳細については、「SSH について」を参照してく� さい。
アカウントのパスワードと同様に、攻撃者が SSH 秘密キーを取得できた� �合は、ユーザーを偽装し、ユーザーが書き込みアクセス権を持つ任意のリポジトリに悪意のあるコードをプッシュする可能性があります。 SSH 秘密キーをディスク ドライブに保存する� �合は、パスフレーズで保護することをお勧めします。 詳細については、「SSH キーのパスフレーズを使う」を参照してく� さい。
もう 1 つのオプションは、ハードウェア セキュリティ キーに SSH キーを生成することです。 2FA で使用しているのと同じキーを使用できます。 ハードウェア セキュリティ キーをリモートで侵害することは非常に困難です。SSH 秘密キーはハードウェア上に残っており、ソフトウェアから直接アクセスすることはできないためです。 詳細については、「ハードウェア セキュリティ キーの新しい SSH キーの生成」を参照してく� さい。
ハードウェア対応の SSH キーはきわめて安全ですが、組織によってはハードウェア要件が合わない� �合があります。 代わりの方法は、短期間� け有効な SSH キーを使用することです。そのため、秘密キーが侵害された� �合でも、長い間悪用されることはありません。 これが、独自の SSH 証明機関を実行する背後にある概念です。 この方法によって、ユーザーの認証方法を細かく制御できるようになりますが、SSH 証明機関を自身で管理する責任を伴います。 詳細については、「SSH 証明機関について」を参照してく� さい。