Isolation and privileged access
Check who can perform an operation and which records they can access. VeriProof applies tenant, role, application, audit-engagement, and database controls at different points.
The controls depend on the service and operation. Validate the specific path you plan to approve.
Authorization layers
| Layer | Question to verify |
|---|---|
| Authentication | Did the trusted issuer create a token for the expected audience and resource? |
| Tenant scope | Does the request resolve to the expected organization? |
| Role and capability | Does the effective role permit this operation? |
| Application scope | Can the caller access this application? |
| Audit scope | Is an auditor limited to the assigned engagement and dates? |
| Data access | Do database roles, grants, and row policies enforce the service boundary? |
| Response contents | Does the response omit records and fields outside the caller’s scope? |
Customer-managed Azure
Customer-managed Azure uses a customer-owned subscription. It can still contain multiple VeriProof organizations, applications, roles, and service identities.
Do not describe the deployment as single-tenant unless the deployed data model and operating policy establish that boundary.
Privileged access
Administrative, staff, database, and emergency paths can have broader access than a normal customer role. Document:
- who can request and approve access;
- the exact role and time limit;
- the affected services and data;
- session logging and review;
- credential storage and rotation; and
- removal and follow-up evidence.
Validation
In an authorized test environment, check allowed and denied requests for each supported role. Use controlled accounts and records for cross-tenant and cross-application cases.
Include expired engagements, inactive users, and custom roles where applicable. Check both returned data and protected changes such as approvals or exports.
Verify the response and the underlying data access. A hidden navigation item is not authorization evidence.
Database row policies are one control, not a substitute for service authorization. Review privileged database roles and any path that can bypass normal filters.