4.2.3 - Multi-tenant access controls

[EnigmaRosa]

Proposing a new requirement to explicitly address multi-tenant access controls.

#	Description	L1	L2	L3	CWE
4.2.3	[ADDED] Verify that multi-tenant applications use cross-tenant controls to ensure user operations will never affect tenants with which they do not have permissions to interact.	✓	✓	✓	284

[elarlang]

I would like to have an example of a scenario.

As I understand, the proposed requirement here already contains recommendations from Josh so most likely it is close to PR.

[jmanico]

This is a super important requirement. Thumbs up.

[jmanico]

Example: I might have a URL like:

https://site.com/customer/1324

.. and I should only be able to look at customers for my company and not other companies in a mulit-tenant system. This is really all about detailed access control between tenants.

[elarlang]

Well, 4.1.3 says users should only be able to access functions, data files, URLs, controllers, services, and other resources, for which they possess specific authorization. This implies protection against spoofing and elevation of privilege.

and 4.2.1 says Verify that sensitive data and APIs are protected against Insecure Direct Object Reference (IDOR) attacks targeting creation, reading, updating and deletion of records, such as creating or updating someone else's record, viewing everyone's records, or deleting all records.

What is gives extra?

[jmanico]

You’re exactly right Elar. Multi-tenancy access control problems are mostly just IDOR and similar. This requirement is really just an extention of those since IDOR and similar is a much much bigger problem in multi-tenant apps. I can totally see why you don’t want this requirement. It’s a fair perspective.

But because of how dangerous access control problems are in multi-tenant apps I think it’s worth considering.

[elarlang]

It is not that "I don't like something", I can not see, what verification or test-action it gives extra. It is exactly the same test to make, you just need to analyze, who's data you got - is it "the same tenant" or "other tenant". The problem exists anyway.

If it is important to point out the multi-tenant aspect, it can be done in one of the mentioned existing requirements.

[jmanico]

Here is another approach to keeping this requirement. There are tons of cross-tenant controls to consider besides just access control. I really agree with your comments here @elarlang but I just want to make one more push to keep this.

• Tenant Isolation: Ensure strict logical separation of tenant data in the database. Implement table-level or schema-level separation.
• Tenant-Specific Encryption Keys: Use separate encryption keys for each tenant’s data to prevent unauthorized access, even at a storage level.
• Cross-Tenant API Gateway Controls: Use API gateways that enforce tenant-level authorization rules to ensure users cannot access other tenants’ resources.
• Data Partitioning: Implement database partitioning by tenant to ensure one tenant’s operations cannot affect another’s data.
• Scoped Access Tokens: Use scoped OAuth tokens that are restricted to a specific tenant context, ensuring that users cannot gain elevated privileges across tenants.
• Tenant ID Validation: Ensure that every API request or operation includes a validated tenant ID as part of the request context, preventing cross-tenant access.
• Strict Multi-Tenant Configuration Rules: Implement checks that prevent configuration changes or misconfigurations from affecting multiple tenants.
• Tenant-Specific Logging and Monitoring: Maintain separate logging and monitoring instances per tenant to avoid data leakage or monitoring errors.
• Resource Quotas Per Tenant: Impose limits on the amount of resources (e.g., memory, CPU, bandwidth) a tenant can use to avoid impact on other tenants.
• Tenant-Aware Error Handling: Ensure that errors or system exceptions affecting one tenant do not expose data or services belonging to another tenant.
• Request Origin Validation: Validate the origin of requests to ensure that they are made within the context of the correct tenant, blocking cross-tenant requests.
• Multi-Tenant Service Rate Limiting: Apply rate-limiting policies per tenant to prevent excessive usage by one tenant from degrading the experience for others.
• Isolated Application Instances: Run separate instances of application components for different tenants where feasible to prevent cross-tenant influence on application behavior.
• Cross-Tenant Data Access Restrictions in UI: Ensure that UI components are isolated per tenant, with no data leakage or display of another tenant’s information.
• Identity Federation Per Tenant: Implement identity federation that restricts access to tenants based on identity provider trust relationships, ensuring users from one tenant cannot authenticate to another.
• Cross-Tenant Auditing: Perform continuous auditing to detect and prevent unauthorized access or operations across tenants.
• Tenant-Specific Data Masking: Apply data masking policies on shared resources to ensure that one tenant’s sensitive data is not exposed to another.
• Tenant-Specific Backup and Disaster Recovery: Ensure that backups and disaster recovery processes are tenant-specific to avoid data mix-ups or recovery issues.
• Tenant-Aware Content Delivery Networks (CDNs): Ensure that CDN caches are segregated by tenant to prevent caching errors or content leaks across tenants.
• Database Query Scoping: Enforce strict query scoping in the data layer to ensure that all database queries are limited to the requesting tenant’s data.
• Tenant-Specific Cache Segregation: Implement tenant-specific cache keys and namespaces to prevent cross-tenant data sharing in cache layers.
• Zero-Trust Network Access (ZTNA): Enforce zero-trust principles within tenant boundaries to ensure users only access resources explicitly granted to them.
• Strict API Versioning and Permissions by Tenant: Differentiate API versions per tenant and ensure API permissions are scoped to the correct tenant environment.
• Tenant-Specific User Session Management: Ensure that user sessions are fully tenant-aware, blocking session token reuse across tenant boundaries.
• Tenant-Level Application Configuration: Store application configuration data in a tenant-specific manner to prevent configuration bleed across tenants.
• Cross-Tenant API Call Isolation: Implement strict firewall rules or access control lists (ACLs) that prevent APIs from making cross-tenant calls without proper authorization.
• Cross-Tenant Reporting Restrictions: Ensure reporting or analytics data is strictly scoped to the tenant making the request, preventing visibility of other tenants' data.
• Tenant-Specific Usage Analytics: Segment analytics and usage data by tenant to ensure that aggregated usage statistics do not expose cross-tenant data or behavior.
• Tenant-Specific Customization Controls: Allow each tenant to apply customization options (e.g., branding, settings) that are strictly isolated to their tenant space.
• Separate Identity Stores for Tenants: Use different identity stores (or logically partitioned identity stores) for each tenant to prevent cross-tenant authentication issues.

[tghosth]

As I said, I believe that it is is important to specifically mention multi-tenancy separation as it might require additional or more stringent controls compared to regular BOLA protection. I think Jim's comment nicely illustrates the associated complexities :) We probably don't want to go into as much detail but I think it demonstrates the point.

[jmanico]

I tend to agree with this. There are controls that benefit multitenant systems more than just access control.

[EnigmaRosa]

Great examples, Jim

[elarlang]

For me it is like to have separate requirement for each version of path traversal from CWE listing (see CWE-22 .. CWE-40).

But there seems to be overwhelming agreement on this...

[jmanico]

Honestly, I think you’re making a good point Elar. I go back and forth on this and can see both perspectives.

[tghosth]

To me, this is one of the examples where it is worth bending the rules slightly in order to highlight a particularly important point.

@EnigmaRosa please can you open a PR :)