Introduction
보안 인시던트 방지는 이에 대응하는 것보다 비용이 적게 들고 중단이 적습니다. GitHub을(를) 사전에 강화하여 악용된 자격 증명, 무단 접근 및 공급망 공격과 같은 위협에 대한 노출을 줄입니다.
이 가이드에서는 주로 엔터프라이즈 GitHub Enterprise Cloud의 일부인 조직에서 적용할 수 있는 보호 조치에 중점을 둡니다. GitHub Enterprise Cloud을(를) 시험해 보려면 GitHub Enterprise Cloud 평가판 설정을 참조하십시오.
GitHub여기에 언급된 대부분의 보안 기능(예: 보안 구성, 분기 규칙 집합 및 액세스 제어)은 조직 수준 또는 엔터프라이즈 수준에서 구성할 수 있습니다.
즉각적인 작업
조직 전체에서 보안 기준을 설정하기 위해 지금 바로 수행할 수 있는 강력한 작업입니다.
보안 적용 범위 설정
GitHub's GitHub Advanced Security 도구가 모든 리포지토리에서 활성화되어 있는지 확인합니다. 도구를 하나씩 사용하도록 설정하는 대신 단일 작업으로 조직 또는 엔터프라이즈의 리포지토리에 적용할 수 있는 보안 설정 컬렉션인 보안 **구성**을 만들고 적용할 수 있습니다.
강력한 구성에는 다음이 포함될 수 있습니다.
-
**Secret scanning ** 이미 코드베이스에 커밋된 비밀을 감지하고 새 비밀이 푸시 보호를 통해 푸시되지 않도록 합니다. 유출된 자격 증명은 보안 위반의 가장 일반적인 원인 중 하나입니다.
-
**Code scanning ** 프로덕션에 도달하기 전에 소스 코드의 취약성 및 코딩 오류를 식별합니다.
-
**Dependabot alerts ** 및 Dependabot security updates 종속성의 알려진 취약성 및 맬웨어를 알리고 자동으로 끌어오기 요청을 열어 취약한 종속성을 업데이트합니다.
[AUTOTITLE](/enterprise-cloud@latest/code-security/how-tos/secure-at-scale/configure-organization-security/establish-complete-coverage/creating-a-custom-security-configuration)(조직) 및 [AUTOTITLE](/enterprise-cloud@latest/code-security/how-tos/secure-at-scale/configure-enterprise-security/establish-complete-coverage/creating-a-custom-security-configuration-for-your-enterprise)(기업)을 참조하세요.
컨트롤 강화
GitHub 는 리포지토리 및 조직에서 발생할 수 있는 작업을 제어하는 다양한 컨트롤을 제공합니다. 이러한 컨트롤이 적절하게 구성되도록 하는 것은 위험을 줄이는 데 필수적입니다.
규칙 세트를 사용하여 중요 분기 보호
규칙 집합을 사용하면 하나 이상의 리포지토리에서 분기 및 태그에 대한 보호 규칙을 정의할 수 있습니다. 끌어오기 요청 검토 및 상태 검사(예: 자동화된 보안 검사)와 같은 요구 사항을 적용하는 데 사용합니다. 이렇게 하면 손상된 계정의 변경 내용을 포함하여 권한이 없는 변경 내용이 프로덕션 코드에 도달하지 않도록 방지할 수 있습니다.
[AUTOTITLE](/organizations/managing-organization-settings/creating-rulesets-for-repositories-in-your-organization)(조직) 및 [AUTOTITLE](/enterprise-cloud@latest/admin/enforcing-policies/enforcing-policies-for-your-enterprise/enforcing-policies-for-code-governance)(기업)을 참조하세요.
푸시 보호를 우회할 수 있는 사람을 제어
푸시 보호를 사용하도록 설정하면 검색된 비밀을 푸시하려고 시도하는 참가자가 차단되지만 기본적으로 차단을 무시할 수 있는 옵션이 있습니다. 위임된 바이패 스를 사용하려면 바이패스 요청이 검토 및 승인 주기를 통과해야 하므로 명시적이고 감사된 결정 없이는 바이패스가 발생할 수 없습니다.
[AUTOTITLE](/enterprise-cloud@latest/code-security/how-tos/secure-your-secrets/manage-bypass-requests/enabling-delegated-bypass-for-push-protection)을(를) 참조하세요.
끌어오기 요청에 종속성 검토 적용
종속성 검토 작업은 끌어오기 요청의 종속성 변경 내에서 알려진 취약성을 표시하여, 병합되기 전에 취약한 종속성을 찾아낼 수 있도록 합니다. 비밀에 대한 푸시 보호와 마찬가지로 사후 경고가 아닌 게이트 역할을 합니다. 조직 전체의 끌어오기 요청에 대한 종속성 검토를 적용할 수 있습니다.
[AUTOTITLE](/code-security/concepts/supply-chain-security/about-dependency-review#about-the-dependency-review-action) 및 [AUTOTITLE](/code-security/how-tos/secure-at-scale/configure-organization-security/configure-specific-tools/enforcing-dependency-review-across-an-organization)을(를) 참조하세요.
액세스 검토 및 제한
부여되었을 때 적절한 액세스는 더 이상 필요하지 않을 수 있습니다. 조직에 대한 액세스 권한을 가진 사용자와 무엇이 있는지를 정기적으로 검토하면 무단 행동의 위험을 줄일 수 있습니다.
멤버 액세스 감사 및 최소 권한 원칙 준수
조직의 구성원에게 필요한 액세스 권한만 있는지 확인합니다. 더 이상 액세스가 필요하지 않은 멤버를 제거하고, 더 넓은 권한이 정당화되지 않는 역할을 다운그레이드하고, 외부 공동 작업자 액세스를 검토합니다. 지나치게 허용되는 액세스는 손상된 계정의 폭발 반경을 증가합니다.
기본 역할이 조직에 필요한 것보다 더 관대한 경우 각 팀에 필요한 특정 권한만 부여하는 사용자 지정 역할을 만들 수 있습니다. 이는 제로 트러스트 보안 모델을 채택하는 조직에 특히 유용합니다.
[AUTOTITLE](/enterprise-cloud@latest/admin/managing-accounts-and-repositories/managing-roles-in-your-enterprise/identify-role-requirements)을(를) 참조하세요.
권한 있는 애플리케이션 검토
OAuth apps와 GitHub Apps가 조직에 설치되어 있으면 데이터에 액세스할 수 있습니다. 권한 있는 애플리케이션 목록을 검토하고 더 이상 필요하지 않거나 더 이상 신뢰할 수 없는 애플리케이션을 제거합니다. 오래된 통합은 종종 간과되는 공격 표면을 나타냅니다.
[AUTOTITLE](/apps/using-github-apps/reviewing-and-modifying-installed-github-apps) 및 [AUTOTITLE](/enterprise-cloud@latest/organizations/managing-oauth-access-to-your-organizations-data/about-oauth-app-access-restrictions)을(를) 참조하세요.
IP 허용 목록을 사용하여 네트워크 액세스 제한
조직이 GitHub Enterprise Cloud에서 운영하는 경우, 만약 조직이 알려진 네트워크 범위 내에서 운영한다면, 해당 범위에서만 GitHub 리소스에 접근을 제한하기 위해 IP 허용 목록을 구성하십시오. 이렇게 하면 예기치 않은 위치에서 사용되는 손상된 자격 증명에 대한 방어 계층이 추가됩니다.
[AUTOTITLE](/enterprise-cloud@latest/organizations/keeping-your-organization-secure/managing-security-settings-for-your-organization/managing-allowed-ip-addresses-for-your-organization) 및 [AUTOTITLE](/enterprise-cloud@latest/admin/configuring-settings/hardening-security-for-your-enterprise/restricting-network-traffic-to-your-enterprise-with-an-ip-allow-list)을(를) 참조하세요.
비밀 위험 평가 실행
조직의 리포지토리에 대한 주문형 무료 검사를 실행하여 조직 전체에서 현재 노출되는 총 비밀 수를 특정 시점으로 볼 수 있습니다.
[AUTOTITLE](/code-security/how-tos/secure-at-scale/configure-organization-security/configure-specific-tools/assess-your-secret-risk)을(를) 참조하세요.
단기 작업
이러한 작업은 보안 태세에도 중요하지만 배포하기 전에 더 많은 준비와 조정이 필요할 수 있습니다.
인증 강화
약하거나 손상된 인증은 계정 인수의 가장 일반적인 원인 중 하나입니다. 조직 전체에서 강력한 인증을 요구하면 이러한 위험이 크게 줄어듭니다.
모든 멤버에 대해 2FA(2단계 인증)가 필요하므로 손상된 암호만으로는 계정에 액세스하기에 충분하지 않습니다. 요구 사항을 적용하기 전에 조직과 통신하여 구성원이 2FA를 설정할 시간을 갖도록 합니다.
조직은 인증을 ID 공급자를 통해 중앙 집중화하여 SSO(Single Sign-On, 싱글 사인온)를 적용함으로써 더 발전할 수 있습니다.
[AUTOTITLE](/organizations/keeping-your-organization-secure/managing-two-factor-authentication-for-your-organization/requiring-two-factor-authentication-in-your-organization) 및 [AUTOTITLE](/enterprise-cloud@latest/organizations/managing-saml-single-sign-on-for-your-organization/about-identity-and-access-management-with-saml-single-sign-on)을(를) 참조하세요.
GitHub Actions 워크플로 강화
GitHub Actions 워크플로는 종종 비밀, 배포 자격 증명 및 리포지토리에 대한 쓰기 권한에 액세스할 수 있습니다. 신중한 구성이 없으면 손상되거나 악의적인 작업이 데이터를 유출하거나 악성 코드를 삽입할 수 있습니다.
워크플로 사용 권한을 명시적으로 선언
기본적으로, 워크플로는 GITHUB_TOKEN을 통해 광범위한 권한을 받을 수 있습니다. 워크플로 파일의 키를 사용하여 permissions 각 워크플로에 필요한 최소 권한을 명시적으로 선언합니다. 이렇게 하면 손상된 워크플로 단계로 인해 발생할 수 있는 피해가 제한됩니다.
타사 작업을 고정하여 SHA 커밋
태그로 타사 작업을 참조하는 경우(예 v1:) 태그를 다른 코드를 가리키도록 이동할 수 있습니다. 작업을 전체 커밋 SHA에 고정하면 항상 검토하고 승인한 정확한 코드를 실행할 수 있습니다. 태그가 하이재킹되는 공급망 공격으로부터 보호합니다.
실행할 수 있는 작업 제한
실행할 수 있는 작업을 제어하도록 조직 또는 엔터프라이즈 수준에서 정책을 구성합니다. GitHub가 생성한 작업, 검증된 작성자의 작업 또는 특정 허용 목록으로 작업을 제한할 수 있습니다.
GitHub Actions와 관련된 추가 보안 사용 관행은 물론, 이러한 모든 사례에 대한 자세한 내용은 [AUTOTITLE](/actions/reference/security/secure-use)을 참조하십시오.
지속적인 보안 관행
이러한 관행은 정기적인 운영 리듬의 일부가 되어야 합니다.
보안 개요를 사용하여 보안 상태 모니터링
보안 개요는 조직 및 기업의 보안 환경에 대한 중앙 집중식 보기를 제공합니다. 이를 사용하여 보안 기능이 사용하도록 설정된 리포지토리를 추적하고, 새로운 위험이 눈에 띄지 않도록 열려 있는 경고가 있는 리포지토리를 식별합니다.
[AUTOTITLE](/enterprise-cloud@latest/code-security/concepts/security-at-scale/about-security-overview)을(를) 참조하세요.
보안 부채를 줄이기 위해 정기적인 보안 캠페인 실행
시간이 지남에 따라 보안 경고가 누적 될 수 있습니다. 보안 캠페인을 사용하면 수정 작업을 구성하고 우선 순위를 지정할 수 있습니다. 이에 따라 개발자에게 경고 그룹을 할당하거나 Copilot이 생성한 수정 사항의 도움을 받아 경고를 직접 Copilot할당할 수 있습니다.
보안 캠페인은 조직에서 GitHub Team 사용하거나 GitHub Enterprise CloudGitHub Secret Protection or GitHub Code Security 사용하도록 설정된 상태로 사용할 수 있습니다. 보안 캠페인 생성 및 관리하기을(를) 참조하세요.
액세스 및 사용 권한 감사 계속
사람들이 조직에 가입하고 나가고 프로젝트가 발전함에 따라 액세스 요구 사항이 변경됩니다. 다음의 정기 검토를 계획하세요.
- 조직 멤버 자격 및 역할.
- 외부 공동 작업자 액세스.
- 리포지토리 수준 권한 및 팀 할당.
- 인증된 OAuth 및 GitHub Apps.
이렇게 하면 조직이 변경되더라도 최소 권한 원칙에 따라 액세스가 유지됩니다.
종속성을 최신 상태로 유지
취약한 종속성은 공격자의 공통 진입점입니다. Dependabot 는 알려진 취약성으로 종속성을 업데이트하기 위해 끌어오기 요청을 자동으로 열 수 있지만, 이러한 끌어오기 요청은 즉시 검토하고 병합해야 합니다.
보안 업데이트가 중단되지 않도록 풀 리퀘스트를 심사하고 병합하는 프로세스를 설정합니다.
[AUTOTITLE](/enterprise-cloud@latest/code-security/concepts/supply-chain-security/about-dependabot-auto-triage-rules) 및 [AUTOTITLE](/code-security/how-tos/secure-your-supply-chain/manage-your-dependency-security/managing-pull-requests-for-dependency-updates)을(를) 참조하세요.
비밀 교체 및 만료 적용
자격 증명이 오래 존재할수록 노출되거나 도난당할 기회가 더 많아집니다. 가능한 경우:
- personal access tokens에 만료 날짜를 설정합니다.
- 정기적인 일정에 따라 시크릿을 교체합니다.
토큰 관리에 대한 자세한 내용은 AUTOTITLE 및 AUTOTITLE 을 참조 하세요.
다음 단계
- 강력한 예방 제어가 있더라도 보안 인시던트가 여전히 발생할 수 있습니다. 미리 설정해야 하는 몇 가지 중요한 도구 및 응답 프로세스가 있습니다. 보안 인시던트 준비을(를) 참조하세요.