One of the transformational features of cloud file sharing services like Google Drive is how easy it is to work with collaborators outside your organization by sharing files more broadly than you would normally be able to with an on-premises file server.
But leveraging that openness without due consideration of security opens your organization to unintentionally giving access to the wrong people. Additionally, because permissions may be added as needed with no time limits, access that was temporarily appropriate can become a permanent, unmonitored attack vector.
Best practices
The principle of least privilege means that each file and resource should be accessible by the fewest number of people necessary and only for a legitimate operational purpose.
Elevated permissions — folders and files that are potentially accessible by external users — should be clear and explicit to everyone regularly using the storage system.
Macktez recommends at least annual audits and policy reviews to purge permissions exceptions that are introduced into storage systems but have outlived their intended purpose.
Real-world implementation
Macktez has spent the first quarter of 2025 deeply reviewing our own Google Drive policies, structure, and permissions exceptions. We have made a few key updates to highlight permissions exceptions (when still needed) with a clearer organizational divide between shared drives that allow external sharing and shared drives that do not.
We have three tiers of permissions allowance:
- Internal (no external sharing permitted)
- Allowlist sharing (external sharing on individual files permitted only to specific domains)
- External sharing (external sharing on individual files permitted)
In Google, each tier is set up as an Organizational Unit (OU) with its own security policies. Each top-level Shared Drive in Google Drive is then assigned to one of the three OUs.
- The Internal OU holds Shared Drives such as “HR” and “Finance”. These are folders with documents that should never be shared with anyone who doesn’t have a macktez.com address. By default, any new shared drive automatically starts in this OU, to make sure that any permissions added are done so intentionally.
- The Allowlist OU holds project folders that are primarily for internal use but may have more collaborative components with specific partners, in which case an external domain can be added to give us more flexibility for ongoing sharing. We keep the number of domains in the allowlist very low, and share only specific collaboration subfolders — which are named in a way that identifies them as collaboration folders — with those external domains.
- The External OU holds files that are exceptions to our default sharing guidelines, allowing for more flexibility for external sharing. We have one-off collaborative documents with clients (ongoing meeting notes, asset lists, case studies, SOPs), vendors, and other partners that don’t rise to the level of allowlisting an entire domain, but that still require collaboration. Storing them in this External OU ensures that we are intentional about the permissions we expect a file to be allowed.
Of course, just assigning a resource to one of those three OUs does not entirely define its accessibility. Every file and folder still needs individual permissions assigned. But the OU puts a ceiling on permissions options that’s vital for organizational security.
Audit process
We review our permissions policies annually. This year we are paying particular attention to one-off collaborations that are no longer current. Since it’s not practicable to audit every single file and make individual decisions about access, we are comfortable making wide determinations that reduce access; adding access back when requested is always possible, and it keeps the rationale for exceptions up-to-date.
For example, a file from 2022 that was shared with two people outside Macktez but not accessed in the past 12 months is reverting back to default permissions, accessible only by Macktez team members. It is possible that one of those external collaborators will have a reason to try to access the file again; but if they try to access the file now, see that they no longer have access, and really do need access again, they can reach out and we can re-add collaborators back if that is still appropriate.
Key takeaways
- Security is not a set-it-and-forget-it proposition. Review security policies at least annually.
- Regular audits keep security rationales relevant. Even when properly adhering to the principle of least privilege, exceptions inevitably creep into any storage solution. Plan for periodic purges of permissions exceptions.
- Err on the side of limiting access. Setting security defaults to stricter limits means that file sharing mistakes are more likely to be the kind where someone doesn’t have access to a file they should, rather than the kind where too many people have access to a file they shouldn’t.
- Use naming conventions to identify areas of broader access. Name files and folders that are accessible outside your organization to clearly identify their intended audience.