Skip to main content

アカウントをセキュリティで保護するためのベスト プラクティス

ソフトウェア サプライ チェーンにアクセスしてアカウントを保護する方法に関するガイダンス。

このガイドについて

このガイドでは、アカウントのセキュリティを強化するために行うことができる影響が最も大きい変更について説明します。 各セクションで、セキュリティを向上させるためにプロセスに対して行うことができる変更の概要を示します。 変更は影響が大きい順に示されます。

リスクとは

アカウントのセキュリティは、サプライ チェーンのセキュリティの基礎となります。 攻撃者が GitHub Enterprise Cloud 上のユーザーのアカウントを乗っ取ることができると、コードやビルド プロセスに悪意のある変更を加えることができます。 したがって、最初の目標としては、自分自身のアカウントおよび他の組織またはエンタープライズのメンバーのアカウントの乗っ取りを困難にする必要があります。

認証の一元化

エンタープライズまたは組織の所有者であれば、SAML を使用して一元化された認証を構成できます。 メンバーの追加または削除は手動で行うことができますが、シングル サインオン (SSO) と SCIM を GitHub Enterprise Cloud と SAML ID プロバイダー (IdP) の間に設定する方が簡単で安全です。 これにより、エンタープライズのすべてのメンバーの認証プロセスも簡略化されます。

エンタープライズ アカウントまたは組織アカウントに対して SAML 認証を構成できます。 SAML を使用すると、GitHub.com 上のエンタープライズまたは組織のメンバーの個人アカウントに IdP を介してアクセス権を付与できます。あるいは、Enterprise Managed Users を使用してエンタープライズに属するアカウントを作成および制御できます。 詳しくは、企業の認証に関する記事をご覧ください。

SAML 認証を構成した後、メンバーがリソースへのアクセスを要求すると、メンバーは SSO フローに転送されて、IdP でも認識されていることが確認されます。 認識されていない場合、要求は拒否されます。

一部の IdP では SCIM というプロトコルがサポートされます。これは、IdP で変更を行ったときに、GitHub Enterprise Cloud 上で自動的にアクセス権をプロビジョニングまたはプロビジョニング解除できます。 SCIM を使用すると、チームの成長に合わせて管理を簡素化し、アカウントに対するアクセス権をすばやく取り消すことができます。 SCIM は、GitHub Enterprise Cloud 上の個々の組織または Enterprise Managed Users を使用するエンタープライズで使用可能です。 詳細については、「Organization の SCIM について」を参照してください。

2 要素認証の構成

アカウントのセキュリティを向上するために最適な方法は、2 要素認証 (2FA) を構成することです。 パスワード自体は、推測しやすいこと、侵害された別のサイトでも利用されていたこと、またはフィッシングなどのソーシャル エンジニアリングによって侵害される可能性があります。 2FA を使用すると、攻撃者がパスワードを取得した場合でさえ、アカウントの侵害がはるかに困難になります。

エンタープライズの所有者であれば、エンタープライズに所属するすべての組織で 2FA を必要とするようにポリシーを構成できる場合があります。

組織の所有者であれば、組織のすべてのメンバーが 2FA を有効化することを要求できる場合があります。

エンタープライズ アカウントの構成

エンタープライズの所有者は、エンタープライズのすべてのメンバーに 2FA を要求できる場合があります。 GitHub Enterprise Cloud 上で 2FA ポリシーを使用できるかどうかは、メンバーがエンタープライズのリソースにアクセスする際にどのように認証されるかによって異なります。

エンタープライズが Enterprise Managed Users を使用するか SAML 認証がエンタープライズに適用されている場合、 GitHub Enterprise Cloud 上で 2FA を構成することはできません。 IdP の管理アクセス権を持つユーザーが、IdP に対して 2FA を構成する必要があります。

詳細については、「エンタープライズの ID とアクセス管理について」および「エンタープライズのセキュリティ設定にポリシーを適用する」を参照してください。

個人アカウントの構成

: エンタープライズの所有者がGitHub.com 上のエンタープライズに対して構成した認証方法によっては、個人アカウントで 2FA を有効にすることができません。

GitHub Enterprise Cloud では、2FA のオプションがいくつかサポートされています。どれも何もしないよりも効果がありますが、最も安全なオプションは WebAuthn です。 WebAuthn では、ハードウェア セキュリティ キー、あるいは Windows Hello や Mac TouchID など、サポートするデバイスが必要です。 他の形式の 2FA であればフィッシングは困難とはいえ可能です (たとえば、6 桁のワンタイム パスワードを読み上げるように誰かに頼まれるなど)。 ただし、WebAuthn のフィッシングは不可能です。ドメイン スコープがプロトコルに組み込まれているため、ログイン ページを偽装する Web サイトの資格情報が GitHub Enterprise Cloud で使用されるのを妨げるためです。

2FA を設定するときは、必ず回復コードをダウンロードし、複数の要素を設定する必要があります。 こうすることで、アカウントへのアクセスが 1 つのデバイスに依存しなくなります。 詳細については、「2 要素認証の構成」、「2 要素認証復旧方法の構成」、および GitHub ショップの GitHub ブランド ハードウェア セキュリティ キーを参照してください。

組織アカウントの構成

: エンタープライズの所有者がGitHub.com 上のエンタープライズに対して構成した認証方法によっては、組織の 2FA を要求できません。

組織の所有者であれば、どのユーザーの 2FA が有効になっていないかを確認し、設定を支援してから、組織の 2FA を要求することができます。 そのプロセスの手順については、次を参照してください。

  1. 組織内のユーザーが 2 要素認証を有効にしているかどうかの表示
  2. 組織で 2 要素認証を要求する準備
  3. 組織で 2 要素認証を要求する

SSH キーを使用した GitHub Enterprise Cloud への接続

Web サイトにサインインする以外に GitHub Enterprise Cloud とやり取りする他の方法があります。 多くのユーザーは、SSH 秘密キーを使用して GitHub にプッシュするコードを承認します。 詳細については、「SSH について」を参照してください。

アカウントのパスワードと同様に、攻撃者が SSH 秘密キーを取得できた場合は、ユーザーを偽装し、ユーザーが書き込みアクセス権を持つ任意のリポジトリに悪意のあるコードをプッシュする可能性があります。 SSH 秘密キーをディスク ドライブに保存する場合は、パスフレーズで保護することをお勧めします。 詳細については、「SSH キーのパスフレーズを使う」を参照してください。

もう 1 つのオプションは、ハードウェア セキュリティ キーに SSH キーを生成することです。 2FA で使用しているのと同じキーを使用できます。 ハードウェア セキュリティ キーをリモートで侵害することは非常に困難です。SSH 秘密キーはハードウェア上に残っており、ソフトウェアから直接アクセスすることはできないためです。 詳細については、「ハードウェア セキュリティ キーの新しい SSH キーの生成」を参照してください。

ハードウェア対応の SSH キーはきわめて安全ですが、組織によってはハードウェア要件が合わない場合があります。 代わりの方法は、短期間だけ有効な SSH キーを使用することです。そのため、秘密キーが侵害された場合でも、長い間悪用されることはありません。 これが、独自の SSH 証明機関を実行する背後にある概念です。 この方法によって、ユーザーの認証方法を細かく制御できるようになりますが、SSH 証明機関を自身で管理する責任を伴います。 詳細については、「SSH 証明機関について」を参照してください。

次の手順