Architecture and operating model
External-sharing governance is not one on/off switch. Organization defaults, organizational units or groups, sites/shared drives, folders/files, link types and guest identity can narrow the same decision at different layers. Determine effective access from the most restrictive layer together with existing sharing objects.
Google Workspace combines Drive sharing settings, allowlists and Trust Rules; Microsoft 365 combines tenant and SharePoint/OneDrive site settings, link types and Entra B2B guest policies. Similar labels across the platforms do not guarantee identical defaults or license scope.
A controlled model defines sharing zones by data class, verified guest identity, expiry, reauthentication, download restrictions and audit review. Keep sensitive content in a separate site/shared drive with external sharing disabled; use domain allowlists and time-bound access for project areas.
- 1Classify data and business need
- 2Apply guest identity and domain policy
- 3Grant time-bound sharing and access
- 4Audit, recertify and remove
Design parameters
- Data class
- Define different boundaries for public, internal, confidential and regulated content.
- Link type
- Separate risks of anonymous links, new/verified guests and existing-guests-only access.
- Lifecycle
- Require sponsor, expiry date, periodic recertification and leaver cleanup.
- Audit scope
- Define retention and review periods for sharing, access, download and policy-change events.
Administration layers across platforms
Service names are reference points. Scope, defaults, region availability and operating requirements differ; they are not interchangeable guarantees.
| Control area | Google Workspace | Microsoft 365 |
|---|---|---|
| Organization scope | Admin Console Drive sharing settings | SharePoint/OneDrive organization sharing level |
| Narrow scope | OU/group, trust rules, shared-drive restrictions | Site sharing level, sensitivity/Entra guest controls |
| Trusted party | Allowlisted domains and trust-rule conditions | Entra B2B allow/block and cross-tenant settings |
| Monitoring | Drive log events and investigation tools | Purview audit and SharePoint/Entra events |
Worked example
For a 120-day supplier project, allow only project.example, apply a 14-day link lifetime and review sponsors monthly. Disable anonymous links and limit sharing to the project area. At closure, remove guest memberships and file-level exceptions from an exported report.
In a 5,000-person organization, a total external-sharing count is insufficient. Query new external domains, anonymous links, confidentially labeled files and failed access separately; use a 30-day baseline to establish ownership and false positives.
Example commands: replace lab values and confirm permissions and software versions before use.
# Microsoft 365: read tenant and selected site sharing state
Connect-SPOService -Url https://contoso-admin.sharepoint.com
Get-SPOTenant | Select-Object SharingCapability,RequireAnonymousLinksExpireInDays
Get-SPOSite -Identity https://contoso.sharepoint.com/sites/project | Select-Object Url,SharingCapability
# For Google Workspace, filter Admin Console > Reporting > Audit and investigation >
# Drive log events by target user, external domain and visibility changes.Troubleshooting
| Observation | Likely cause / distinction | Verification |
|---|---|---|
| User cannot share | An organization, OU/site or trust/guest policy may be more restrictive. | Inspect effective user group, content location, target domain and link type for the same event. |
| Access remains after sharing is disabled | A file member, group membership or guest account may provide another path. | List links, direct permission, groups and guest objects separately. |
| External user loops during sign-in | The account, invitation match or cross-tenant condition may be wrong. | Verify invited address, tenant identity and sign-in log correlation ID. |
Acceptance checks
- Document allowed sharing models for every data class.
- Confirm anonymous links are not the default in pilot areas.
- Run negative tests with a non-allowlisted domain and personal account.
- Sample guest sponsor and expiry records.
- Verify sharing and access events appear in audit logs.
- At project closure remove links, direct permissions, groups and guest accounts together.
Related concepts
File permissions and service identities
File access combines users/groups, permission bits, ACLs and security policies. Running an application as root can hide permission problems; prefer a justified, restricted service identity in production. Directory traversal permission differs from file-read permission. Sharing permissions do not necessarily override filesystem restrictions. Identify the account actually running the application, directory chain and ACLs when troubleshooting. Test narrowly required access rather than opening permissions globally.
Authentication and sessions
Authentication proves who a user or workload is; authorization determines what that identity may do. Successful sign-in does not grant access to every resource. User sessions, service identities, API tokens and device certificates have different lifecycles. Design session duration, token renewal, employee departure, lost-device handling and emergency access alongside initial sign-in. Measure which existing sessions remain usable and which new access attempts are denied when the identity provider becomes unavailable.
Least privilege and separation of duties
Least privilege limits the permissions needed for a task to specific resources and time periods. Giving everyone the same administrator role complicates access reviews and investigations. Separate daily-use identities from privileged accounts, and restrict interactive use and unnecessary network access for service identities. An access matrix should show which operation an identity may perform on each resource. Test whether an application keeps working after a permission is removed: unnecessary privileges sometimes become visible only during controlled reduction.
Version and support lifecycle
Installability does not prove production support. Review the compatibility chain across OS, application, drivers, extensions and management tools. Update plans should record version, support end, restart needs and rollback methods. A test environment that does not reflect production can produce misleading results. Validate service health and existing workflows after a change, not just version numbers. Remember that pinning a version can also prevent future security fixes.
Telemetry and time correlation
Telemetry combines logs, metrics and events that explain system behavior. A log describes an event, a metric shows behavior over time, and a distributed trace follows a request across components. Clock differences can make one event appear to occur at several times. Use synchronized clocks, reliable source identifiers and consistent time-zone handling. Alarm design should consider duration and user impact alongside thresholds. Monitor gaps in collection separately: absence of logs must not be interpreted as absence of incidents.
Policy lifecycle
A policy needs management as its scope changes, not just when it is enabled. Separate drafting, observation, pilot deployment, enforcement and periodic review. Every exception needs an owner, reason, scope and expiry date. A successful pilot can still cause production false positives if test data does not represent real user behavior. Identify affected users and applications before deploying with measurable acceptance criteria. A rollback path should identify who may reverse the change and under which conditions, rather than merely locating an interface button.
Primary documentation
Prepared by the Doz Teknoloji technical team using the primary references below. Calculations and lab scenarios state their assumptions; validate the applicable product version before rollout.