계정 보안의 모범 사례

이 가이드에 대하여

이 가이드에서는 계정 보안을 강화하기 위해 수행할 수 있는 가장 큰 변경 사항에 대해 설명합니다. 각 섹션에서는 보안을 개선하기 위해 프로세스를 변경할 수 있는 변경 내용을 간략하게 설명합니다. 가장 큰 변경 내용이 먼저 나열됩니다.

어떤 위험이 있나요?

계정 보안은 공급망 보안의 기본 사항입니다. 공격자가 GitHub에서 계정을 탈취할 수 있으면, 코드나 빌드 프로세스에 악의적인 변경을 가할 수 있습니다. 따라서 첫 번째 목표는 누군가가 조직 또는 엔터프라이즈의 다른 멤버 계정뿐 아니라 귀하의 계정도 탈취하기 어렵게 만드는 것입니다.

인증 중앙 집중화

엔터프라이즈 또는 조직 소유자인 경우 SAML을 사용하여 중앙 집중식 인증을 구성할 수 있습니다. 멤버를 수동으로 추가하거나 제거할 수도 있지만, GitHub와 SAML ID 공급자(IdP) 사이에 Single sign-on(SSO) 및 SCIM을 설정하는 편이 더 간단하고 더 안전합니다. 이렇게 하면 엔터프라이즈의 모든 멤버에 대한 인증 프로세스도 간소화됩니다.

엔터프라이즈 또는 조직 계정에 대한 SAML 인증을 구성할 수 있습니다. SAML을 사용하면 IdP를 통해 GitHub에서 기업 또는 조직 멤버의 개인 계정에 대한 액세스를 부여할 수 있으며, 또는 Enterprise Managed Users를 사용하여 기업에 속한 계정을 만들고 제어할 수도 있습니다. 자세한 내용은 ID 및 액세스 관리 기본 사항을(를) 참조하세요.

SAML 인증을 구성한 후 멤버가 리소스에 대한 액세스를 요청할 때 IdP에서 계속 인식되도록 SSO 흐름으로 전달됩니다. 인식할 수 없는 경우 요청이 거부됩니다.

일부 IdP는 SCIM이라는 프로토콜을 지원하며, 이는 IdP에서 변경을 수행할 때 GitHub에서 액세스를 자동으로 프로비전하거나 프로비전 해제할 수 있습니다. SCIM을 사용하면 팀이 성장함에 따라 관리를 간소화할 수 있으며 계정에 대한 액세스를 신속하게 철회할 수 있습니다. SCIM은 GitHub Enterprise의 개별 조직에서 사용할 수 있으며, 또는 Enterprise Managed Users를 사용하는 기업에서 사용할 수 있습니다. 자세한 내용은 조직에 대한 SCIM 정보을(를) 참조하세요.

2단계 인증 구성

계정의 보안을 개선하는 가장 좋은 방법은 2단계 인증(2FA)을 구성하는 것입니다. 암호 자체는 추측할 수 있거나, 손상된 다른 사이트에서 재사용되거나, 피싱과 같은 소셜 엔지니어링에 의해 손상될 수 있습니다. 2FA를 사용하면 공격자가 암호를 가지고 있더라도 계정이 손상되는 것을 훨씬 더 어렵게 만듭니다.

모범 사례로, 계정의 보안과 안정적인 액세스를 모두 보장하기 위해 계정에 2단계 자격 증명을 항상 최소 두 개 이상 등록해야 합니다. 추가 자격 증명을 등록해 두면 자격 증명 하나에 대한 액세스를 잃더라도 계정에서 잠기지 않습니다.

또한 가능한 경우 인증기 앱(TOTP 앱이라고도 함)보다 패스키와 보안 키를 우선하고, SMS 사용은 피해야 합니다. SMS 기반 2FA와 TOTP 앱은 둘 다 피싱에 취약하며, 패스키 및 보안 키와 동일한 수준의 보호를 제공하지 않습니다. SMS는 NIST 800-63B 디지털 ID 지침에서 더 이상 권장되지 않습니다.

조직의 서비스 계정이 GitHub에 의해 2FA 등록 대상으로 선택된 경우, 해당 토큰과 키는 마감일 이후에도 중단 없이 계속 작동합니다. 계정에서 2FA를 활성화할 때까지 웹사이트 UI를 통한 GitHub 액세스만 차단됩니다. 서비스 계정의 두 번째 요소로 TOTP를 설정하고, 설정 중에 표시되는 TOTP 비밀을 회사의 공유 암호 관리자에 저장하되, 비밀에 대한 액세스는 SSO를 통해 제어하는 것을 권장합니다.

엔터프라이즈 소유자인 경우 엔터프라이즈가 소유한 모든 조직에 대해 2FA를 요구하는 정책을 구성할 수 있습니다.

조직 소유자인 경우 조직의 모든 구성원이 2FA를 사용하도록 요구할 수도 있습니다.

자신의 계정에서 2FA를 활성화하는 방법에 대한 자세한 내용은 2단계 인증 구성에서 확인하세요. 조직에서 2FA를 요구하는 방법에 대한 자세한 내용은 조직에서 2단계 인증 요구에서 확인하세요.

엔터프라이즈 계정 구성

엔터프라이즈 소유자는 엔터프라이즈의 모든 구성원에 대해 2FA를 요구할 수 있습니다. GitHub에서 2FA 정책을 사용할 수 있는지는 멤버가 Enterprise의 리소스에 액세스하기 위해 인증하는 방식에 따라 달라집니다.

기업에서 Enterprise Managed Users를 사용하거나 기업에 SAML 인증이 강제 적용되는 경우, GitHub에서 2FA를 구성할 수 없습니다. IdP에 대한 관리 액세스 권한이 있는 사용자가 IdP에 대해 2FA를 구성해야 합니다.

자세한 내용은 엔터프라이즈 IAM에 대한 SAML 정보 및 엔터프라이즈에서 보안 설정에 대한 정책 적용을(를) 참조하세요.

개인 계정 구성

GitHub는 2FA에 대해 여러 옵션을 지원하며, 어떤 옵션이든 없는 것보다는 낫지만 가장 안전한 옵션은 WebAuthn 자격 증명입니다. WebAuthn에는 FIDO2 하드웨어 보안 키, Windows Hello와 같은 플랫폼 인증기, Apple 또는 Google 휴대전화, 또는 암호 관리자와 같은 인증기가 필요합니다. 2FA의 다른 형식을 피싱하는 것은 어렵지만 가능합니다(예: 누군가가 6자리 일회용 암호를 읽도록 요청하는 경우). 하지만 WebAuthn은 프로토콜에 도메인 범위 지정이 기본으로 포함되어 있으므로 피싱에 훨씬 더 강합니다. 이는 로그인 페이지를 사칭하는 웹사이트의 자격 증명이 GitHub에서 사용되지 못하도록 방지합니다.

2FA를 설정할 때는 복구 코드를 항상 다운로드하고, 2FA 자격 증명을 둘 이상 설정해야 합니다. 이렇게 하면 계정에 대한 액세스가 단일 디바이스에 의존하지 않습니다. 자세한 내용은 2단계 인증 구성 및 2단계 인증 복구 메서드 구성을(를) 참조하세요.

조직 계정 구성

조직 소유자인 경우 2FA를 사용하도록 설정하지 않은 사용자를 확인하여 설정에 도움을 준 다음 조직에 2FA를 요구할 수 있습니다. 해당 프로세스를 안내하려면 다음을 참조하세요.

1.        [AUTOTITLE](/organizations/keeping-your-organization-secure/managing-two-factor-authentication-for-your-organization/viewing-whether-users-in-your-organization-have-2fa-enabled)
   

2.        [AUTOTITLE](/organizations/keeping-your-organization-secure/managing-two-factor-authentication-for-your-organization/preparing-to-require-two-factor-authentication-in-your-organization)
   

3.        [AUTOTITLE](/organizations/keeping-your-organization-secure/managing-two-factor-authentication-for-your-organization/requiring-two-factor-authentication-in-your-organization)
   

SSH 키를 사용하여 GitHub에 연결

웹사이트에 로그인하는 것 외에도 GitHub와 상호 작용하는 다른 방법이 있습니다. 많은 사용자가 SSH 프라이빗 키를 사용하여 GitHub에 푸시하는 코드를 인증합니다. 자세한 내용은 SSH 정보을(를) 참조하세요.

계정 암호와 마찬가지로 공격자가 SSH 프라이빗 키를 가져올 수 있는 경우 사용자를 가장하고 쓰기 액세스 권한이 있는 모든 리포지토리에 악성 코드를 푸시할 수 있습니다. 디스크 드라이브에 SSH 프라이빗 키를 저장하는 경우 암호를 사용하여 보호하는 것이 좋습니다. 자세한 내용은 SSH 키 암호 사용을(를) 참조하세요.

또 다른 옵션은 하드웨어 보안 키에 SSH 키를 생성하는 것입니다. 2FA에 사용 중인 것과 동일한 키를 사용할 수 있습니다. 프라이빗 SSH 키는 하드웨어에 유지되며 소프트웨어에서 직접 액세스할 수 없기 때문에 하드웨어 보안 키는 원격으로 손상하기 매우 어렵습니다. 자세한 내용은 새 SSH 키 생성 및 ssh-agent에 추가을(를) 참조하세요.

하드웨어 기반 SSH 키는 매우 안전하지만, 하드웨어 요구 사항이 일부 조직에는 적합하지 않을 수 있습니다. 다른 방법은 짧은 기간 동안만 유효한 SSH 키를 사용하는 것이므로 프라이빗 키가 손상된 경우에도 오랫동안 악용되지 않습니다. 이는 사용자 고유의 SSH 인증 기관을 실행하는 개념입니다. 이 방법을 통해 사용자가 인증하는 방법을 높은 수준으로 제어할 수 있지만 SSH 인증 기관을 직접 유지 관리하는 책임도 함께 따릅니다. 자세한 내용은 SSH 인증 기관 정보을(를) 참조하세요.

다음 단계

•         [AUTOTITLE](/code-security/supply-chain-security/end-to-end-supply-chain/end-to-end-supply-chain-overview)
  

•         [AUTOTITLE](/code-security/supply-chain-security/end-to-end-supply-chain/securing-code)
  

•         [AUTOTITLE](/code-security/supply-chain-security/end-to-end-supply-chain/securing-builds)
  

•         [AUTOTITLE](/code-security/getting-started/best-practices-for-preventing-data-leaks-in-your-organization)