Who Can Reach What? How Access and Exposure Analysis Works

Knowing where personal data is tells you half the risk. The other half is who can reach it, and in most organizations that is a question no single system can answer. Teams that read file server ACLs, Microsoft 365 sharing links and database roles separately never notice that the same payroll file is open to “everyone” by three different routes. Access and exposure analysis is the work of translating those three languages into one graph.

Why access information matters as much as content

A finding such as “4,200 documents on the HR share contain special category data” does not, on its own, produce a priority. Whether those documents can be read by three HR specialists or by every user in the domain gives the same content two very different risk levels. Exposure is the intersection of a content finding with access information, and prioritization is only possible at that intersection.

The Guide on the Processing of Special Categories of Personal Data published by KVKK, Türkiye’s data protection authority, lists limiting the staff who can access such data and logging access rights among the basic measures. Principle Decision 2026/2035 of 16 September 2026, in the context of monitoring corporate communication channels, stresses that access should be restricted to a limited set of staff, that access logs should be kept, and that “being technically able to access” should be kept apart from “being legally entitled to access”. The operational translation of both texts is the same: an organization has to know, and be able to show, which identity can reach which sensitive data. This article is not legal advice; how these texts apply to your organization should be assessed with your legal function.

In practice, access information is written in three different languages: the ACLs of file systems, the sharing models of cloud collaboration platforms, and the role and privilege tables of databases. Until those three are translated into each other, “who can reach what” cannot be answered.

How to read ACLs

On SMB/CIFS shares and NTFS file systems, access is defined by access control lists. Each list holds entries made of an identity (user or group), a set of permissions (read, write, modify, full control) and a type (allow or deny). Four features make them hard to read.

Inheritance. Sub-folders inherit the parent’s permissions by default. An “Authenticated Users: Read” entry granted on the root share years ago lives on silently in every folder created today. Unless the inheritance chain is broken, that permission is invisible when folders are inspected one by one; it only surfaces when effective permissions are computed.

Nested groups. A permission is granted to a group; the group’s members are other groups; their members are yet more groups. A “Finance-Read” group that contains “All-Staff” opens the finance folder to everyone, while the ACL shows only “Finance-Read”.

Deny entries. Deny takes precedence over allow, but an inherited deny is evaluated after an explicitly granted allow. The effective permission is the arithmetic of those precedences, and doing it by hand is error-prone.

Share permissions versus NTFS permissions. The SMB share’s own permission and the underlying file system’s permission are defined separately; the effective permission is their intersection. A folder with a share permission of “Everyone: Full Control” but tight NTFS permissions is safe; the reverse is not.

On NFS the model is simpler: export rules and file mode bits. The risk there is usually a directory exported with a world-readable mode bit, open to every client on the source network. Seratus collects file and folder permissions over a read-only connection; where permissions cannot be read, the file is still scanned and the gap is reported as a warning. Details are on the file servers page.

Sharing links: access without an ACL

In SharePoint Online, OneDrive and Teams files, a large share of access is granted not through ACLs but through sharing links. Three link types produce three exposure levels: links for specific people, “everyone in the organization” links and anonymous (public) links. The first resembles an ACL entry; the second and third grant access to anyone who knows the path or obtains the link, and they do not appear in a classic ACL read.

Two properties make links more dangerous than ACLs. The first is persistence: a link is not revoked once it has served its purpose; it works as long as the file exists. The second is propagation: when an “everyone in the organization” link is forwarded by email, every recipient reaches the file; the link copies as easily as the file itself.

Access analysis has to show these links in the same graph and on the same exposure scale as ACLs. A payroll spreadsheet sitting on NTFS with “Domain Users: Read” and in SharePoint with an “everyone in the organization” link is not two findings in two lists; it is one high-exposure finding.

Database roles: access at table level

In databases, access is defined by object privileges granted to users and roles. Roles and system/object privileges in Oracle, database roles (db_datareader, db_owner and so on) and schema permissions in SQL Server, roles and GRANT statements in PostgreSQL and MySQL/MariaDB all answer the same question: which identity can read which table.

Three gaps are common here. The application service account holding a role that reads the entire schema when it needs three tables. A “read-only” role created for reporting that has, over time, been granted to the whole staff. The personal database account of a manager who left years ago, still holding full privileges. None of these appears as “risk” on the database administrator’s screen; for that, which tables a role reaches has to be placed next to which columns in those tables hold TCKN, IBAN or health data.

Seratus extracts that mapping as a role-to-table permission graph. The connection is read-only: a thin client for Oracle, db_datareader level for SQL Server, a read-only account for PostgreSQL and MySQL/MariaDB. The tables a role can reach are joined with the personal data found by sampling-based column detection, and the result sits in the same graph as the ACL and link findings on the file side.

Identity problems: departed users, unresolvable SIDs, cyclic groups

The identity side is where access analysis most often produces wrong answers. Three problems stand out.

Departed users and orphaned access. An account disabled or deleted in the directory is not automatically removed from ACLs, sharing links or database user tables. If the account is disabled, the access cannot be used for now; but if it is re-enabled, or a new account is created with the same name, the permissions return. These entries should be flagged separately as “orphaned access”, because cleaning them up is both the easiest and the most postponed remediation.

Unresolvable SIDs. In a Windows environment, ACL entries are stored not by user name but by security identifier (SID). When the account is deleted, the SID can no longer be resolved to a name and remains in the ACL as a string beginning with S-1-5-21. The entry leaves “who can reach this” unanswered. More importantly, unresolvable SIDs are the trace of a migration or domain merger; if an account in a trusted domain carries that SID, the access stays open by a route nobody is watching.

Cyclic group memberships. When “Project-A” is a member of “Regional-Team” and “Regional-Team” is a member of “Project-A”, membership resolution loops forever. Most tools stop there or compute membership incompletely. The cycle means every permission granted to one group spreads to all members of the other, pushing effective access well beyond what anyone assumed.

Seratus flags all three as separate finding types; LDAP/directory synchronization keeps user and scope information aligned with the current state of the directory. When the graph detects a cycle it completes the resolution by breaking the cycle and reports the cycle itself as a finding.

What least privilege means in practice

The principle of least privilege is simple on paper: every identity should hold only the access its job requires. Applying it requires three questions to be answered for every asset: who can reach it, who actually uses that access, and what does it contain. The first is answered by reading ACLs, links and roles; the third by content classification. The second belongs to access logs and, in most organizations, can only be answered partially.

What makes the principle workable is prioritizing not any one of these questions but their intersection. Special category data sitting under public or organization-wide access, a payroll folder open to an unresolvable SID and an application role that reaches every table should be ranked in the same list on the same scale. Remediation is then assigned to the asset owner: permission removal, link revocation, role narrowing or quarantining the file. Each action is approved and recorded, because an action that narrows access can also stop a business process and must be reversible.

How Seratus closes these gaps

Gap: ACLs, sharing links and database roles read in separate tools in separate languages. The Seratus access and exposure graph combines file server ACLs, SharePoint, OneDrive and Teams sharing links (anonymous, “everyone in the organization”, specific people) and Oracle, SQL Server, PostgreSQL and MySQL/MariaDB role-to-table permissions in one graph on one exposure scale.

Gap: effective permissions hidden by inheritance and nested groups. The graph resolves inherited permissions and nested group memberships to compute effective access; overshared and public assets are brought to the front.

Gap: orphaned access, unresolvable SIDs and cyclic groups. Each is its own finding type; LDAP/directory synchronization keeps user and scope information current, cycles are broken during resolution and reported.

Gap: assets with broad access but unknown content. Data classification and Turkish-specific detection join the content finding with access information; findings such as “special category data overshared” land in the KVKK gaps list.

Gap: narrowing access without a record or approval. Permission removal, quarantine and masking are assigned to an owner in the remediation and evidence flow, executed under a separate approval right and written to the audit log with who, when and why; findings can be forwarded to SIEM and ticketing systems.

Gap: granting write permissions for discovery. Every source connection is read-only: db_datareader on SQL Server, read-only application permissions on Microsoft 365, read-only mounts on file servers. No source requires write access for analysis.

Takeaway

“Who can reach what” is answered in three languages across three kinds of systems, and as long as those answers are kept apart, least privilege stays an intention. Access and exposure analysis intersects ACLs, sharing links and database roles with the content finding in one graph, flags departed users, unresolvable SIDs and cyclic groups separately, and turns remediation into a recorded, approved action. The risk is not in where the data is; it is in who can reach it.