Access Controls, Governance, and Audit Logging
Access Controls, Governance, and Audit Logging
This domain tests how MicroStrategy enforces who sees which rows, columns, and objects, and how changes and access are audited.
Core rules
- Privileges are bundled into security roles and inherited from every group a user belongs to. Privileges are additive; a user gets the union, and a Bypass all security filters privilege overrides row-level restrictions.
- Object ACLs control view/modify/full control on folders, reports, metrics, and cubes; inheritance comes from the folder unless broken.
- Security filters enforce row-level access per user or group. When a user belongs to multiple groups with filters, the filters are combined with OR, which can widen access rather than narrow it.
- Column-level protection uses data masking on attribute forms or restricted metric access, not a security filter.
- Audit sources include the Change Journal (object changes), History List (executions), job statistics, Platform Analytics, and Enterprise Manager.
Worked example
A user in the East group and the West group sees both regions, although each group filter alone restricts one region. The behavior is expected: security filters from all group memberships are unioned. To restrict the user, remove one membership, or replace the two filters with a single filter that expresses the intended scope. Reasoning: MicroStrategy treats each filter as a grant; it does not intersect grants. If the user also had Bypass all security filters, no filter would apply at all.
Traps that cost marks
- Assuming multiple security filters intersect to the most restrictive scope.
- Forgetting that privileges are additive across groups.
- Relying on a report filter for security; users can remove or edit it.
- Looking for object changes in the History List when the Change Journal is the right source.
- Ignoring time zone and retention settings when reading audit data.