# 조직에서 데이터 유출을 방지하기 위한 모범 사례 조직에서 개인 데이터나 중요한 데이터가 노출되지 않도록 보호하는 데 도움이 되는 지침과 권장 사항을 알아보세요. ## 이 가이드에 대하여 조직의 소유자는 개인 정보나 중요 데이터가 노출되지 않도록 최우선으로 관리해야 합니다. 데이터 유출은 의도적인 행위든, 우발적인 사고든 관련 당사자에게 심각한 위험을 초래할 수 있습니다. 데이터 유출로부터 보호하기 위한 조치를 취하지만 GitHub 보안을 강화하기 위해 조직을 관리할 책임이 있습니다. 데이터 유출 방지를 위해서는 다음과 같은 몇 가지 주요 구성 요소가 필요합니다. * 예방을 위한 사전 대응적 접근 * 유출 가능성 조기 검색 * 사건 발생 시 완화 계획을 유지합니다. 어떤 방법이 가장 좋을지는 관리하는 조직의 유형에 따라 결정됩니다. 오픈 소스 개발을 중심으로 하는 조직의 경우, 외부와의 협력을 원활하게 하기 위해 일반적인 상업 조직에 비해 관리 감독이 덜 엄격할 수 있습니다. 이 문서에서는 필요에 따라 구현해야 하는 고려해야 할 기능 및 설정에 대한 GitHub 높은 수준의 지침을 제공합니다. ## 계정 보안 2FA 사용 설정 및 모든 구성원에게 적용, 강력한 암호 지침 설정 등 보안 모범 사례를 구현하여 조직의 리포지토리와 설정을 보호해야 합니다. * 가능한 경우 SAML 및 SCIM 통합과 2FA 인증을 사용하여 보안 인증 프로세스를 사용하도록 설정합니다. 자세한 내용은 [SAML Single Sign-On을 사용하는 ID 및 액세스 관리 정보](/ko/enterprise-cloud@latest/organizations/managing-saml-single-sign-on-for-your-organization/about-identity-and-access-management-with-saml-single-sign-on), [조직에 대한 SCIM 정보](/ko/enterprise-cloud@latest/organizations/managing-saml-single-sign-on-for-your-organization/about-scim-for-organizations), [2FA(2단계 인증)를 사용하여 계정 보호](/ko/enterprise-cloud@latest/authentication/securing-your-account-with-two-factor-authentication-2fa)을(를) 참조하세요. - 조직 구성원, 외부 협력자 및 청구 관리자가 개인 계정에 대해 2FA를 사용하도록 요구하므로 악의적인 행위자가 조직의 리포지토리 및 설정에 액세스하기가 더 어려워집니다. 이는 보안 인증을 사용하도록 설정하는 것에서 한 단계 더 나아진 것입니다. 자세한 내용은 [조직에서 2단계 인증 요구](/ko/enterprise-cloud@latest/organizations/keeping-your-organization-secure/managing-two-factor-authentication-for-your-organization/requiring-two-factor-authentication-in-your-organization)을(를) 참조하세요. - 권장되는 암호 지침에 따라 GitHub사용자가 강력한 암호를 만들고 적절하게 보호하도록 장려합니다. 자세한 내용은 [강력한 암호 만들기](/ko/enterprise-cloud@latest/authentication/keeping-your-account-and-data-secure/creating-a-strong-password)을 참조하세요. - 사용자가 푸시하는 퍼블릭 리포지토리와 관계없이 보호받을 수 있도록 개인 계정 설정에서 푸시 보호를 활성화하도록 권장합니다. 이렇게 설정하면 어떤 퍼블릭 리포지토리로 푸시하든 보호를 받을 수 있습니다. 자세한 내용은 [사용자에 대한 푸시 보호 관리](/ko/enterprise-cloud@latest/code-security/how-tos/secure-your-secrets/prevent-future-leaks/manage-user-push-protection)을 참조하세요. - 내부 보안 정책을 GitHub설정하여 사용자가 적절한 조치를 취하고 인시던트가 의심되는 경우 누구에게 연락해야 하는지 알 수 있도록 합니다. 자세한 내용은 [Adding a security policy to your repository(리포지토리에 보안 정책 추가)](/ko/enterprise-cloud@latest/code-security/how-tos/report-and-fix-vulnerabilities/configure-vulnerability-reporting/add-security-policy)을(를) 참조하세요. 계정 보안에 대한 자세한 내용은 [계정 보안의 모범 사례](/ko/enterprise-cloud@latest/code-security/tutorials/implement-supply-chain-best-practices/securing-accounts)을(를) 참조하세요. ## 데이터 누출 방지 조직의 소유자는 조직의 유형에 맞춰 액세스 권한을 제한하고 검토해야 합니다. 더욱 철저한 제어를 위해서는 다음 설정을 고려해 보세요. | Recommendation | 추가 정보 | | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ----- | | 리포지토리를 포크하는 기능을 비활성화합니다. | | | [리포지토리에 대한 포크 정책 관리](/ko/enterprise-cloud@latest/repositories/managing-your-repositorys-settings-and-features/managing-repository-settings/managing-the-forking-policy-for-your-repository) | | | 리포지토리 표시 여부 변경을 비활성화 합니다. | | | [조직의 리포지토리 표시 유형 변경 제한](/ko/enterprise-cloud@latest/organizations/managing-organization-settings/restricting-repository-visibility-changes-in-your-organization) | | | 리포지토리 생성을 비공개 또는 내부용으로 제한합니다. | | | [조직에서 리포지토리 만들기 제한](/ko/enterprise-cloud@latest/organizations/managing-organization-settings/restricting-repository-creation-in-your-organization) | | | 리포지토리 삭제 및 전송을 비활성화합니다. | | | [리포지토리를 삭제하거나 전송하기 위한 권한 설정](/ko/enterprise-cloud@latest/organizations/managing-organization-settings/setting-permissions-for-deleting-or-transferring-repositories) | | | | | | 배포 키를 사용하는 기능을 비활성화 합니다. | | | [조직의 배포 키 제한](/ko/enterprise-cloud@latest/organizations/managing-organization-settings/restricting-deploy-keys-in-your-organization) | | | | | | 범위 personal access token는 필요한 최소 권한까지입니다. | None | | 코드를 보호하기 위해 필요한 경우 퍼블릭 리포지토리를 프라이빗으로 전환하세요. 를 사용하여 이 변경 내용의 리포지토리 소유자에게 자동으로 경고할 수 있습니다 GitHub App. | | | \[ | | | ]\( GitHub Marketplace | | | 도메인을 확인하고 이메일 알림을 확인된 이메일 도메인으로만 제한하여 조직의 ID를 확인합니다. | | | [조직의 도메인 확인 또는 승인](/ko/enterprise-cloud@latest/organizations/managing-organization-settings/verifying-or-approving-a-domain-for-your-organization) 및 [조직에 대한 메일 알림 제한](/ko/enterprise-cloud@latest/organizations/keeping-your-organization-secure/managing-security-settings-for-your-organization/restricting-email-notifications-for-your-organization) | | | 표준 서비스 약관을 GitHub 사용하는 대신 조직이 고객 계약으로 업그레이드되었는지 확인합니다. | | | [GitHub 고객 계약으로 업그레이드](/ko/enterprise-cloud@latest/organizations/managing-organization-settings/upgrading-to-the-github-customer-agreement) | | | 기여자가 실수로 커밋하는 것을 방지합니다. | | | [Removing sensitive data from a repository(리포지토리에서 중요한 데이터 제거)](/ko/enterprise-cloud@latest/authentication/keeping-your-account-and-data-secure/removing-sensitive-data-from-a-repository#avoiding-accidental-commits-in-the-future) | | ## 데이터 유출 감지 데이터 유출을 방지하기 위해 조직을 얼마나 잘 강화하든, 일부는 여전히 발생할 수 있으며 감사 로그 및 분기 보호 규칙을 사용하여 secret scanning대응할 수 있습니다. ### secret scanning 사용 Secret scanning 는 GitHub 리포지토리의 모든 브랜치의 전체 Git 기록을 스캔하여 실수로 커밋된 비밀을 탐지함으로써 조직과 리포지토리 전반에 걸쳐 코드의 보안을 유지하고 비밀을 안전하게 보호하는 데 도움이 됩니다. 비밀 검색 파트너, 다른 서비스 공급자 또는 사용자 또는 조직에서 정의한 패턴과 일치하는 모든 문자열은 리포지토리 탭에서 ** Security and quality** 경고로 보고됩니다. 사용할 수 있는 두 가지 형식이 있습니다: secret scanning 및 파트너에 대한 비밀 검사 경고. * 파트너에 대한 비밀 검사 경고: 기본적으로 사용하도록 설정되며 모든 공용 리포지토리 및 공용 npm 패키지에서 자동으로 실행됩니다. * 사용자에 대한 비밀 검사 경고: 조직에 대한 추가 검사 기능을 얻으려면 사용자에 대한 비밀 검사 경고을 사용하도록 설정해야 합니다. 활성화된 사용자에 대한 비밀 검사 경고는 다음 유형의 리포지토리에서 감지할 수 있습니다.에 대한 라이선스를 보유한 경우. * GitHub Enterprise Cloud를 사용하는 조직이 소유한 공용 리포지토리 * 라이선스가 있는 경우 프라이빗 및 내부 리포지토리 GitHub Code Security > \[!TIP] > secret scanning 및 푸시 보호의 사용 상태와 관계없이 조직이 GitHub TeamGitHub Enterprise에서 무료 보고서를 실행하여 조직의 코드 내에서 유출된 비밀을 검사할 수 있습니다. [GitHub 사용하여 비밀 보안](/ko/enterprise-cloud@latest/code-security/concepts/secret-security/secret-security-with-github)을 참조하세요. secret scanning에 대한 자세한 내용은 [비밀 스캐닝](/ko/enterprise-cloud@latest/code-security/concepts/secret-security/secret-scanning)을(를) 참조하세요. secret scanning을 리포지토리 또는 조직에 대한 푸시 보호로 사용하도록 설정할 수도 있습니다. 이 기능을 사용하도록 설정하면 secret scanning에서 기여자가 검색된 비밀을 사용하여 코드를 푸시하지 못하도록 방지합니다. 자세한 내용은 [푸시 보호](/ko/enterprise-cloud@latest/code-security/concepts/secret-security/push-protection)을 참조하세요. 마지막으로 검색 범위를 확장하여 사용자 지정 비밀 문자열 구조를 포함할 수도 있습니다. 자세한 내용은 [비밀 검사를 위한 사용자 지정 패턴 정의](/ko/enterprise-cloud@latest/code-security/how-tos/secure-your-secrets/customize-leak-detection/define-custom-patterns)을(를) 참조하세요. ### 조직의 감사 로그 검토 GraphQL 감사 로그 API를 사용하여 조직의 감사 로그를 활용함으로써 IP를 사전에 보호하고 조직의 규정 준수를 유지할 수 있습니다. 자세한 내용은 [조직의 감사 로그 검토](/ko/enterprise-cloud@latest/organizations/keeping-your-organization-secure/managing-security-settings-for-your-organization/reviewing-the-audit-log-for-your-organization) 및 [기업 관리자](/ko/enterprise-cloud@latest/graphql/reference/enterprise-admin#interface-auditentry)을(를) 참조하세요. ### 분기 보호 규칙 설정 분기 보호를 설정하면 기본 분기에 병합하기 전에 모든 코드를 제대로 검토할 수 있습니다. 분기 보호 규칙을 설정하면 기여자가 변경 사항을 푸시하기 전에 특정 워크플로나 요구 사항을 적용할 수 있습니다. 자세한 내용은 [보호된 분기 정보](/ko/enterprise-cloud@latest/repositories/configuring-branches-and-merges-in-your-repository/managing-protected-branches/about-protected-branches)을(를) 참조하세요. 분기 보호 규칙 대신 규칙 집합을 만들 수 있습니다. 규칙 세트는 상태와 같은 분기 보호 규칙에 비해 몇 가지 장점이 있으며 관리자 액세스를 요구하지 않고도 검색 가능성을 향상할 수 있습니다. 여러 규칙 집합을 동시에 적용할 수도 있습니다. 자세한 내용은 [규칙 세트에 대한 정보](/ko/enterprise-cloud@latest/repositories/configuring-branches-and-merges-in-your-repository/managing-rulesets/about-rulesets)을(를) 참조하세요. ## 데이터 유출 완화 사용자가 중요한 데이터를 푸시했을 경우, `git filter-repo` 도구를 사용하여 해당 데이터를 제거하도록 요청하세요. 자세한 내용은 [Removing sensitive data from a repository(리포지토리에서 중요한 데이터 제거)](/ko/enterprise-cloud@latest/authentication/keeping-your-account-and-data-secure/removing-sensitive-data-from-a-repository)을(를) 참조하세요. 또한 중요한 데이터가 아직 푸시되지 않은 경우 해당 변경 내용을 로컬로 실행 취소할 수 있습니다. 자세한 내용은 [the GitHub Blog](https://github.blog/2015-06-08-how-to-undo-almost-anything-with-git/) (하지만 `git revert` Git 기록에 원래 중요한 커밋을 남겨 두는 중요한 데이터 추가를 실행 취소하는 유효한 방법은 아님)을 참조하세요. 자신이 소유하고 있다고 확신하는 데이터를 삭제하기 위해 저장소 소유자와 직접 협의할 수 없는 경우, DMCA 게시 중단 통지 양식을 작성하여 GitHub 지원팀에 알릴 수 있습니다. 문제가 있는 커밋 해시가 반드시 포함되어야 합니다. 자세한 내용은 [DMCA 게시 중단 통지](https://support.github.com/contact/dmca-takedown)를 참조하세요. > \[!NOTE] > 만약 허위 신고로 인해 리포지토리 중 하나가 삭제되었다면, DMCA 반론 통지서를 작성하여 GitHub 지원팀에 알려주시기 바랍니다. 자세한 내용은 [DMCA 반론 통지](https://support.github.com/contact/dmca-counter-notice)를 참조하세요. ### 노출된 토큰 해지하기 자격 증명이 GitHub 리포지토리 GitHubsecret scanning에 노출된 경우, 자격 증명을 보고하고 해지하는 데 GitHubsecret scanning를 사용할 수 있습니다. 자세한 내용은 [비밀 검사에서 경고 해결](/ko/enterprise-cloud@latest/code-security/how-tos/manage-security-alerts/manage-secret-scanning-alerts/resolving-alerts#reporting-a-leaked-secret-in-a-private-repository)을(를) 참조하세요. 소유하지 않은 자격 증명이 리포지토리 외부에서 GitHub 노출된 경우, 해당 자격 증명을 해지할 수도 있습니다. 이렇게 하면 커뮤니티의 GitHub 전반적인 보안에 기여하고 이러한 자격 증명의 영향을 신속하게 제한할 수 있습니다. API는 취소를 지원합니다. * Personal access tokens (classic)접두사에 `ghp_`을 사용 * Fine-grained personal access tokens접두사에 `github_pat_`을 사용 * OAuth app 접두사를 사용하는 `gho_` 토큰 * GitHub App 접두사를 사용하는 `ghu_` 사용자-서버 토큰 * GitHub App 접두사를 사용하여 `ghr_` 토큰 새로 고침 노출된 토큰이 GitHub나 다른 위치에 있는 경우, REST API를 사용하여 해지 요청을 제출할 수 있습니다. 지원되는 자격 증명 형식의 완전하고 신뢰할 수 있는 목록은 [취소](/ko/enterprise-cloud@latest/rest/credentials/revoke#revoke-a-list-of-credentials) 을 참조하세요. ## 다음 단계 * [공급망 코드 보안의 모범 사례](/ko/enterprise-cloud@latest/code-security/tutorials/implement-supply-chain-best-practices/securing-code) * [빌드 시스템 보안의 모범 사례](/ko/enterprise-cloud@latest/code-security/tutorials/implement-supply-chain-best-practices/securing-builds)