이 가이드의 내용
이 가이드에서는 계정 보안을 강화하기 위해 수행할 수 있는 가장 큰 변경 사항에 대해 설명합니다. 각 섹션에서는 보안을 개선하기 위해 프로세스를 변경할 수 있는 변경 내용을 간략하게 설명합니다. 가장 큰 변경 내용이 먼저 나열됩니다.
어떤 위험이 있나요?
계정 보안은 공급망 보안의 기본 사항입니다. 공격자가 GitHub에서 계정을 인수할 수 있는 경우 코드 또는 빌드 프로세스를 악의적으로 변경할 수 있습니다. 따라서 첫 번째 목표는 누군가가 사용자의 계정과 더불어 다른 조직의 본인 계정과 구성원 계정을 쉽게 인수하지 못하도록 만드는 것입니다.
2단계 인증 구성
Note
2023년 3월부터 GitHub은 GitHub.com에 코드를 기여하는 모든 사용자에게 2단계 인증(2FA) 방식을 하나 이상 사용하도록 요구하고 있습니다. 자격이 있는 그룹에 속했다면 해당 그룹이 등록 대상으로 선택되었을 때 45일 간의 2FA 등록 기간이 시작되었음을 알리는 알림 이메일을 받았을 것이며, GitHub.com에 2FA 등록을 요청하는 배너가 표시되었을 것입니다. 알림을 받지 못했다면 2FA를 사용해야 하는 그룹은 아니지만, 사용하는 것을 적극 권장합니다.
2FA 등록 출시에 대한 자세한 내용은 블로그 게시물을 참조하세요.
개인 계정의 보안을 개선하는 가장 좋은 방법은 2FA(2단계 인증)를 구성하는 것입니다. 암호 자체는 추측할 수 있거나, 손상된 다른 사이트에서 재사용되거나, 피싱과 같은 소셜 엔지니어링에 의해 손상될 수 있습니다. 2FA를 사용하면 공격자가 암호를 가지고 있더라도 계정이 손상되는 것을 훨씬 더 어렵게 만듭니다.
계정에 대한 보안 및 신뢰할 수 있는 액세스를 모두 보장하는 모범 사례를 위해 항상 계정에 두 개 이상의 2단계 자격 증명을 등록해야 합니다. 추가 자격 증명을 사용하면 자격 증명 하나에 대한 액세스 권한이 없어도 계정에서 잠기지 않습니다.
또한 인증자 앱(TOTP 앱이라고 함)보다 암호 및 보안 키를 선호해야 하며 가능하면 SMS 사용을 피해야 합니다. SMS 기반 2FA 및 TOTP 앱은 모두 피싱에 취약하며 암호 및 보안 키와 동일한 수준의 보호를 제공하지 않습니다. SMS는 NIST 800-63B 디지털 ID 지침에 따라 더 이상 권장되지 않습니다.
조직 소유자인 경우 조직의 모든 구성원이 2FA를 사용하도록 요구할 수 있습니다.
자신의 계정에서 2FA를 사용하도록 설정하는 방법에 대한 자세한 내용은 2단계 인증 구성을(를) 참조하세요. 조직에서 2FA를 요구하는 방법에 대한 자세한 내용은 조직에서 2단계 인증 요구을(를) 참조하세요.
개인 계정 구성
GitHub는 2FA에 대한 몇 가지 옵션을 지원하며, 그 중 어느 것도 없는 것보다는 낫지만 가장 안전한 옵션은 WebAuthn 자격 증명입니다. WebAuthn에는 FIDO2 하드웨어 보안 키, Windows Hello 등 플랫폼 인증자, Apple 또는 Google 휴대폰 또는 암호 관리자와 같은 인증자가 필요합니다. 2FA의 다른 형식을 피싱하는 것은 어렵지만 가능합니다(예: 누군가가 6자리 일회용 암호를 읽도록 요청하는 경우). 그러나 도메인 범위 지정이 프로토콜에 기본 제공되므로 웹 사이트의 자격 증명이 GitHub에서 로그인 페이지를 가장하는 데 사용되지 않기 때문에 WebAuthn은 피싱에 저항력이 더 강합니다.
2FA를 설정할 때는 항상 복구 코드를 다운로드하고 둘 이상의 2FA 자격 증명을 설정해야 합니다. 이렇게 하면 계정에 대한 액세스가 단일 디바이스에 의존하지 않습니다. 자세한 내용은 2단계 인증 구성 및 2단계 인증 복구 메서드 구성을(를) 참조하세요.
조직 계정 구성
조직 소유자인 경우 2FA를 사용하도록 설정하지 않은 사용자를 확인하여 설정에 도움을 준 다음 조직에 2FA를 요구할 수 있습니다. 해당 프로세스를 안내하려면 다음을 참조하세요.
SSH 키를 사용하여 GitHub에 연결
웹 사이트에 로그인하는 것 외에 GitHub와 상호 작용하는 다른 방법이 있습니다. 많은 사람들이 SSH 프라이빗 키를 사용하여 GitHub에 푸시하는 코드에 권한을 부여합니다. 자세한 내용은 SSH 정보을(를) 참조하세요.
계정 암호와 마찬가지로 공격자가 SSH 프라이빗 키를 가져올 수 있는 경우 사용자를 가장하고 쓰기 액세스 권한이 있는 모든 리포지토리에 악성 코드를 푸시할 수 있습니다. 디스크 드라이브에 SSH 프라이빗 키를 저장하는 경우 암호를 사용하여 보호하는 것이 좋습니다. 자세한 내용은 SSH 키 암호 사용을(를) 참조하세요.
또 다른 옵션은 하드웨어 보안 키에 SSH 키를 생성하는 것입니다. 2FA에 사용 중인 것과 동일한 키를 사용할 수 있습니다. 프라이빗 SSH 키는 하드웨어에 유지되며 소프트웨어에서 직접 액세스할 수 없기 때문에 하드웨어 보안 키는 원격으로 손상하기 매우 어렵습니다. 자세한 내용은 새 SSH 키 생성 및 ssh-agent에 추가을(를) 참조하세요.