조직에서 데이터 유출을 방지하기 위한 모범 사례

조직에서 개인 데이터나 중요한 데이터가 노출되지 않도록 보호하는 데 도움이 되는 지침과 권장 사항을 알아보세요.

이 기사에서

이 가이드에 대하여

조직의 소유자는 개인 정보나 중요 데이터가 노출되지 않도록 최우선으로 관리해야 합니다. 데이터 유출은 의도적인 행위든, 우발적인 사고든 관련 당사자에게 심각한 위험을 초래할 수 있습니다. 데이터 유출로부터 보호하기 위한 조치를 취하지만 GitHub 보안을 강화하기 위해 조직을 관리할 책임이 있습니다.

데이터 유출 방지를 위해서는 다음과 같은 몇 가지 주요 구성 요소가 필요합니다.

  • 예방을 위한 사전 대응적 접근
  • 유출 가능성 조기 검색
  • 사건 발생 시 완화 계획을 유지합니다.

어떤 방법이 가장 좋을지는 관리하는 조직의 유형에 따라 결정됩니다. 오픈 소스 개발을 중심으로 하는 조직의 경우, 외부와의 협력을 원활하게 하기 위해 일반적인 상업 조직에 비해 관리 감독이 덜 엄격할 수 있습니다. 이 문서에서는 필요에 따라 구현해야 하는 고려해야 할 기능 및 설정에 대한 GitHub 높은 수준의 지침을 제공합니다.

계정 보안

2FA 사용 설정 및 모든 구성원에게 적용, 강력한 암호 지침 설정 등 보안 모범 사례를 구현하여 조직의 리포지토리와 설정을 보호해야 합니다.

          - 가능한 경우 SAML 및 SCIM 통합과 2FA 인증을 사용하여 보안 인증 프로세스를 사용하도록 설정합니다. 자세한 내용은 [AUTOTITLE](/organizations/managing-saml-single-sign-on-for-your-organization/about-identity-and-access-management-with-saml-single-sign-on), [AUTOTITLE](/organizations/managing-saml-single-sign-on-for-your-organization/about-scim-for-organizations), [AUTOTITLE](/authentication/securing-your-account-with-two-factor-authentication-2fa)을(를) 참조하세요.

  • 조직 구성원, 외부 협력자 및 청구 관리자가 개인 계정에 대해 2FA를 사용하도록 요구하므로 악의적인 행위자가 조직의 리포지토리 및 설정에 액세스하기가 더 어려워집니다. 이는 보안 인증을 사용하도록 설정하는 것에서 한 단계 더 나아진 것입니다. 자세한 내용은 조직에서 2단계 인증 요구을(를) 참조하세요.

  • 권장되는 암호 지침에 따라 GitHub사용자가 강력한 암호를 만들고 적절하게 보호하도록 장려합니다. 자세한 내용은 강력한 암호 만들기을 참조하세요.

  • 사용자가 푸시하는 퍼블릭 리포지토리와 관계없이 보호받을 수 있도록 개인 계정 설정에서 푸시 보호를 활성화하도록 권장합니다. 이렇게 설정하면 어떤 퍼블릭 리포지토리로 푸시하든 보호를 받을 수 있습니다. 자세한 내용은 사용자에 대한 푸시 보호 관리을 참조하세요.

  • 내부 보안 정책을 GitHub설정하여 사용자가 적절한 조치를 취하고 인시던트가 의심되는 경우 누구에게 연락해야 하는지 알 수 있도록 합니다. 자세한 내용은 Adding a security policy to your repository(리포지토리에 보안 정책 추가)을(를) 참조하세요.

계정 보안에 대한 자세한 내용은 계정 보안의 모범 사례을(를) 참조하세요.

데이터 누출 방지

조직의 소유자는 조직의 유형에 맞춰 액세스 권한을 제한하고 검토해야 합니다. 더욱 철저한 제어를 위해서는 다음 설정을 고려해 보세요.

Recommendation추가 정보
리포지토리를 포크하는 기능을 비활성화합니다.
          [AUTOTITLE](/repositories/managing-your-repositorys-settings-and-features/managing-repository-settings/managing-the-forking-policy-for-your-repository)

리포지토리 표시 여부 변경을 비활성화 합니다. | 조직의 리포지토리 표시 유형 변경 제한 리포지토리 생성을 비공개 또는 내부용으로 제한합니다. |
조직에서 리포지토리 만들기 제한 리포지토리 삭제 및 전송을 비활성화합니다. | 리포지토리를 삭제하거나 전송하기 위한 권한 설정 | | 배포 키를 사용하는 기능을 비활성화 합니다. | 조직의 배포 키 제한 | | 범위 personal access token는 필요한 최소 권한까지입니다. | None 코드를 보호하기 위해 필요한 경우 퍼블릭 리포지토리를 프라이빗으로 전환하세요. 를 사용하여 이 변경 내용의 리포지토리 소유자에게 자동으로 경고할 수 있습니다 GitHub App. | 에서 Public-Repos 방지GitHub Marketplace 도메인을 확인하고 이메일 알림을 확인된 이메일 도메인으로만 제한하여 조직의 ID를 확인합니다. | 조직의 도메인 확인 또는 승인 및 조직에 대한 메일 알림 제한 표준 서비스 약관을 GitHub 사용하는 대신 조직이 고객 계약으로 업그레이드되었는지 확인합니다. | GitHub 고객 계약으로 업그레이드 기여자가 실수로 커밋하는 것을 방지합니다. | Removing sensitive data from a repository(리포지토리에서 중요한 데이터 제거)

데이터 유출 감지

데이터 유출을 방지하기 위해 조직을 얼마나 잘 강화하든, 일부는 여전히 발생할 수 있으며 감사 로그 및 분기 보호 규칙을 사용하여 secret scanning대응할 수 있습니다.

          secret scanning 사용

          Secret scanning 는 GitHub 리포지토리의 모든 브랜치의 전체 Git 기록을 스캔하여 실수로 커밋된 비밀을 탐지함으로써 조직과 리포지토리 전반에 걸쳐 코드의 보안을 유지하고 비밀을 안전하게 보호하는 데 도움이 됩니다. 비밀 검색 파트너, 다른 서비스 공급자 또는 사용자 또는 조직에서 정의한 패턴과 일치하는 모든 문자열은 리포지토리의 **보안** 탭에서 경고로 보고됩니다.

사용할 수 있는 두 가지 형식이 있습니다: 파트너에 대한 비밀 검사 경고 및 사용자에 대한 비밀 검사 경고.

  •         파트너에 대한 비밀 검사 경고: 기본적으로 사용하도록 설정되며 모든 공용 리포지토리 및 공용 npm 패키지에서 자동으로 실행됩니다.

  •         사용자에 대한 비밀 검사 경고: 조직에 대한 추가 검사 기능을 얻으려면 사용자에 대한 비밀 검사 경고을 사용하도록 설정해야 합니다.

    활성화된 사용자에 대한 비밀 검사 경고는 다음 유형의 리포지토리에서 감지할 수 있습니다.에 대한 라이선스를 보유한 경우. * GitHub Enterprise Cloud를 사용하는 조직이 소유한 공용 리포지토리

    • 라이선스가 있는 경우 프라이빗 및 내부 리포지토리 GitHub Code Security

팁

          secret scanning 및 푸시 보호의 사용 상태와 관계없이 조직이 GitHub TeamGitHub Enterprise에서 무료 보고서를 실행하여 조직의 코드 내에서 유출된 비밀을 검사할 수 있습니다. 

          [AUTOTITLE](/code-security/securing-your-organization/understanding-your-organizations-exposure-to-leaked-secrets/about-secret-risk-assessment)을 참조하세요.

          

          secret scanning에 대한 자세한 내용은 [AUTOTITLE](/code-security/secret-scanning/introduction/about-secret-scanning)을(를) 참조하세요.

          secret scanning을 리포지토리 또는 조직에 대한 푸시 보호로 사용하도록 설정할 수도 있습니다. 이 기능을 사용하도록 설정하면 secret scanning에서 기여자가 검색된 비밀을 사용하여 코드를 푸시하지 못하도록 방지합니다. 자세한 내용은 [AUTOTITLE](/code-security/secret-scanning/protecting-pushes-with-secret-scanning)을 참조하세요. 마지막으로 검색 범위를 확장하여 사용자 지정 비밀 문자열 구조를 포함할 수도 있습니다. 자세한 내용은 [AUTOTITLE](/code-security/secret-scanning/using-advanced-secret-scanning-and-push-protection-features/custom-patterns/defining-custom-patterns-for-secret-scanning)을(를) 참조하세요.

조직의 감사 로그 검토

GraphQL 감사 로그 API를 사용하여 조직의 감사 로그를 활용함으로써 IP를 사전에 보호하고 조직의 규정 준수를 유지할 수 있습니다. 자세한 내용은 조직의 감사 로그 검토 및 인터페이스을(를) 참조하세요.

분기 보호 규칙 설정

분기 보호를 설정하면 기본 분기에 병합하기 전에 모든 코드를 제대로 검토할 수 있습니다. 분기 보호 규칙을 설정하면 기여자가 변경 사항을 푸시하기 전에 특정 워크플로나 요구 사항을 적용할 수 있습니다. 자세한 내용은 보호된 분기 정보을(를) 참조하세요.

분기 보호 규칙 대신 규칙 집합을 만들 수 있습니다. 규칙 집합은 상태 같은 분기 보호 규칙에 비해 몇 가지 장점이 있으며 관리자 액세스를 요구하지 않고도 검색 가능성이 향상됩니다. 여러 규칙 집합을 동시에 적용할 수도 있습니다. 자세한 내용은 규칙 세트에 대한 정보을(를) 참조하세요.

데이터 유출 완화

사용자가 중요한 데이터를 푸시했을 경우, git filter-repo 도구를 사용하여 해당 데이터를 제거하도록 요청하세요. 자세한 내용은 Removing sensitive data from a repository(리포지토리에서 중요한 데이터 제거)을(를) 참조하세요. 또한 중요한 데이터가 아직 푸시되지 않은 경우 해당 변경 내용을 로컬로 실행 취소할 수 있습니다. 자세한 내용은 the GitHub Blog (하지만 git revert Git 기록에 원래 중요한 커밋을 남겨 두는 중요한 데이터 추가를 실행 취소하는 유효한 방법은 아님)을 참조하세요.

자신이 소유하고 있다고 확신하는 데이터를 삭제하기 위해 저장소 소유자와 직접 협의할 수 없는 경우, DMCA 게시 중단 통지 양식을 작성하여 GitHub 지원팀에 알릴 수 있습니다. 문제가 있는 커밋 해시가 반드시 포함되어야 합니다. 자세한 내용은 DMCA 게시 중단 통지를 참조하세요.

참고

만약 허위 신고로 인해 리포지토리 중 하나가 삭제되었다면, DMCA 반론 통지서를 작성하여 GitHub 지원팀에 알려주시기 바랍니다. 자세한 내용은 DMCA 반론 통지를 참조하세요.

노출된 토큰 해지하기

자격 증명이 GitHub 리포지토리 GitHubsecret scanning에 노출된 경우, 자격 증명을 보고하고 해지하는 데 GitHubsecret scanning를 사용할 수 있습니다. 자세한 내용은 비밀 검사에서 경고 해결을(를) 참조하세요.

소유하지 않은 자격 증명이 리포지토리 외부에서 GitHub 노출된 경우, 해당 자격 증명을 해지할 수도 있습니다. 이렇게 하면 커뮤니티의 GitHub 전반적인 보안에 기여하고 이러한 자격 증명의 영향을 신속하게 제한할 수 있습니다. API는 취소를 지원합니다.

  •         Personal access tokens (classic)접두사를 사용하여 `ghp_`

  •         `github_pat_`에 Fine-grained personal access tokens 접두사를 사용하여

  •         OAuth app 접두사를 사용하는 `gho_` 토큰

  •         GitHub App 접두사를 사용하는 `ghu_` 사용자-서버 토큰

  •         GitHub App 접두사를 사용하여 `ghr_` 토큰 새로 고침

노출된 토큰이 GitHub나 다른 위치에 있는 경우, REST API를 사용하여 해지 요청을 제출할 수 있습니다. 지원되는 자격 증명 형식의 완전하고 신뢰할 수 있는 목록은 취소 을 참조하세요.

다음 단계

  •         [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)