# Melhores práticas para evitar vazamentos de dados na sua organização Conheça as diretrizes e as recomendações para ajudar a evitar a exposição de dados particulares ou confidenciais presentes na sua organização. ## About this guide As an organization owner, preventing exposure of private or sensitive data should be a top priority. Whether intentional or accidental, data leaks can cause substantial risk to the parties involved. While GitHub takes measures to help protect you against data leaks, you are also responsible for administering your organization to harden security. There are several key components when it comes to defending against data leaks: * Taking a proactive approach towards prevention * Early detection of possible leaks * Maintaining a mitigation plan when an incident occurs The best approach will depend on the type of organization you're managing. For example, an organization that focuses on open source development might require looser controls than a fully commercial organization, to allow for external collaboration. This article provide high level guidance on the GitHub features and settings to consider, which you should implement according to your needs. ## Secure accounts Protect your organization's repositories and settings by implementing security best practices, including enabling 2FA and requiring it for all members, and establishing strong password guidelines. * Requiring organization members, outside collaborators, and billing managers to enable 2FA for their personal accounts, making it harder for malicious actors to access an organization's repositories and settings. For more information, see [Requiring two-factor authentication in your organization](/en/enterprise-server@3.19/organizations/keeping-your-organization-secure/managing-two-factor-authentication-for-your-organization/requiring-two-factor-authentication-in-your-organization). * Encouraging your users to create strong passwords and secure them appropriately, by following GitHub’s recommended password guidelines. For more information, see [Creating a strong password](/en/enterprise-server@3.19/authentication/keeping-your-account-and-data-secure/creating-a-strong-password). * Establishing an internal security policy in GitHub, so users know the appropriate steps to take and who to contact if an incident is suspected. For more information, see [Adding a security policy to your repository](/en/enterprise-server@3.19/code-security/getting-started/adding-a-security-policy-to-your-repository). For more detailed information about securing accounts, see [Best practices for securing accounts](/en/enterprise-server@3.19/code-security/supply-chain-security/end-to-end-supply-chain/securing-accounts). ## Prevent data leaks As an organization owner, you should limit and review access as appropriate for the type of your organization. Consider the following settings for tighter control: | Recommendation | More information | | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | | Disable the ability to fork repositories. | [Managing the forking policy for your repository](/en/enterprise-server@3.19/repositories/managing-your-repositorys-settings-and-features/managing-repository-settings/managing-the-forking-policy-for-your-repository) | | Disable changing repository visibility. | [Restricting repository visibility changes in your organization](/en/enterprise-server@3.19/organizations/managing-organization-settings/restricting-repository-visibility-changes-in-your-organization) | | Restrict repository creation to private or internal. | [Restricting repository creation in your organization](/en/enterprise-server@3.19/organizations/managing-organization-settings/restricting-repository-creation-in-your-organization) | | Disable repository deletion and transfer. | [Setting permissions for deleting or transferring repositories](/en/enterprise-server@3.19/organizations/managing-organization-settings/setting-permissions-for-deleting-or-transferring-repositories) | | | | | Disable the ability to use deploy keys. | [Restricting deploy keys in your organization](/en/enterprise-server@3.19/organizations/managing-organization-settings/restricting-deploy-keys-in-your-organization) | | | | | Scope personal access tokens to the minimum permissions necessary. | None | | Secure your code by converting public repositories to private whenever appropriate. You can alert the repository owners of this change automatically using a GitHub App. | [Prevent-Public-Repos](https://github.com/apps/prevent-public-repos) in GitHub Marketplace | | Confirm your organization’s identity by verifying your domain and restricting email notifications to only verified email domains. | [Verifying or approving a domain for your organization](/en/enterprise-server@3.19/organizations/managing-organization-settings/verifying-or-approving-a-domain-for-your-organization) and [Restricting email notifications for your organization](/en/enterprise-server@3.19/organizations/keeping-your-organization-secure/managing-security-settings-for-your-organization/restricting-email-notifications-for-your-organization) | | Prevent contributors from making accidental commits. | [Removing sensitive data from a repository](/en/enterprise-server@3.19/authentication/keeping-your-account-and-data-secure/removing-sensitive-data-from-a-repository#avoiding-accidental-commits-in-the-future) | ## Detect data leaks No matter how well you tighten your organization to prevent data leaks, some may still occur, and you can respond by using secret scanning, the audit log, and branch protection rules. ### Use secret scanning Secret scanning helps secure code and keep secrets safe across organizations and repositories by scanning and detecting secrets that were accidentally committed over the full Git history of every branch in GitHub repositories. Any strings that match patterns defined by you or your organization, are reported as alerts in the ** Security** tab of repositories. > \[!TIP] > Regardless of the enablement status of secret scanning and push protection, organizations on GitHub Team and GitHub Enterprise can run a free report to scan the code in the organization for leaked secrets. See [Secret security with GitHub](/en/enterprise-server@3.19/code-security/securing-your-organization/understanding-your-organizations-exposure-to-leaked-secrets/about-secret-risk-assessment). Your site administrator must enable secret scanning for your instance before you can use this feature. For more information, see [Configuring secret scanning for your appliance](/en/enterprise-server@3.19/admin/code-security/managing-github-advanced-security-for-your-enterprise/configuring-secret-scanning-for-your-appliance). For more information about secret scanning, see [Secret scanning](/en/enterprise-server@3.19/code-security/secret-scanning/introduction/about-secret-scanning). You can also enable secret scanning as a push protection for a repository or an organization. When you enable this feature, secret scanning prevents contributors from pushing code with a detected secret. For more information, see [Push protection](/en/enterprise-server@3.19/code-security/secret-scanning/protecting-pushes-with-secret-scanning). Finally, you can also extend the detection to include custom secret string structures. For more information, see [Defining custom patterns for secret scanning](/en/enterprise-server@3.19/code-security/secret-scanning/using-advanced-secret-scanning-and-push-protection-features/custom-patterns/defining-custom-patterns-for-secret-scanning). ### Review the audit log for your organization You can also proactively secure IP and maintain compliance for your organization by leveraging your organization's audit log, along with the GraphQL Audit Log API. For more information, see [Reviewing the audit log for your organization](/en/enterprise-server@3.19/organizations/keeping-your-organization-secure/managing-security-settings-for-your-organization/reviewing-the-audit-log-for-your-organization) and [Enterprise administration](/en/enterprise-server@3.19/graphql/reference/enterprise-admin#interface-auditentry). ### Set up branch protection rules To ensure that all code is properly reviewed prior to being merged into the default branch, you can enable branch protection. By setting branch protection rules, you can enforce certain workflows or requirements before a contributor can push changes. For more information, see [About protected branches](/en/enterprise-server@3.19/repositories/configuring-branches-and-merges-in-your-repository/managing-protected-branches/about-protected-branches). As an alternative to branch protection rules, you can create rulesets. Rulesets have a few advantages over branch protection rules, such as statuses, and better discoverability without requiring admin access. You can also apply multiple rulesets at the same time. For more information, see [About rulesets](/en/enterprise-server@3.19/repositories/configuring-branches-and-merges-in-your-repository/managing-rulesets/about-rulesets). ## Mitigate data leaks If a user pushes sensitive data, ask them to remove it by using the `git filter-repo` tool. For more information, see [Removing sensitive data from a repository](/en/enterprise-server@3.19/authentication/keeping-your-account-and-data-secure/removing-sensitive-data-from-a-repository). Also, if the sensitive data has not been pushed yet, you can just undo those changes locally; for more information, see [the GitHub Blog](https://github.blog/2015-06-08-how-to-undo-almost-anything-with-git/) (but note that `git revert` is not a valid way to undo the addition of sensitive data as it leaves the original sensitive commit in Git history). If you're unable to coordinate directly with the repository owner to remove data that you're confident you own, you can fill out a DMCA takedown notice form and tell GitHub Support. Make sure to include the problematic commit hashes. For more information, see [DMCA takedown notice](https://support.github.com/contact/dmca-takedown). > \[!NOTE] > If one of your repositories has been taken down due to a false claim, you should fill out a DMCA > counter notice form and alert GitHub Support. For more information, see [DMCA counter notice](https://support.github.com/contact/dmca-counter-notice). ## Next steps * [Best practices for securing code in your supply chain](/en/enterprise-server@3.19/code-security/supply-chain-security/end-to-end-supply-chain/securing-code) * [Best practices for securing your build system](/en/enterprise-server@3.19/code-security/supply-chain-security/end-to-end-supply-chain/securing-builds)