Data Segregation and Security in ecoPortal's Multi-Tenant SaaS Platform

ecoPortal is designed with a multi-tenant architecture, where the same application instance serves multiple customers (tenants). This document provides an overview of how we segregate tenant data and enforce data security using MongoDB Atlas and AWS OpenSearch. Our architecture ensures that customer data is isolated, secure, and scalable.

1. Data Ownership and Segregation in MongoDB Atlas

Per-Organization Ownership

• In our MongoDB Atlas database, each document (or "row") includes a specific field that identifies the organisation (tenant) that owns the data.

• This organisation identifier is enforced at the application level for all queries to ensure that only authorised users from a specific tenant can access their data.

• The system architecture enforces multi-tenancy by associating all data operations (read/write) with this organisation identifier, effectively isolating data by the tenant.

Security Implications

• By associating each document with an organisation ID, we can control access at the database query level, preventing unauthorised access to data from other tenants.

• Data segregation at the document level ensures that even though tenants share the same database instance, their data remains logically separated.

2. Data Isolation in AWS OpenSearch

Alias-Based Access

• AWS OpenSearch is used to enable full-text search capabilities. To ensure tenant data is isolated in search queries, we use an alias-based approach. Each organisation has its own search alias, which serves as a virtual pointer to its data.

• Search queries made by a tenant will only return results from the tenant's own alias, preventing cross-tenant data access.

Noise Neighbor Prevention: Index Segregation

• To further enhance data isolation and performance, we can decide to move tenant data to its own dedicated index. This technique helps minimise the impact of "noisy neighbours" (where one tenant's large-scale operations could affect others).

• With separate indices, resource allocation and performance tuning can be tenant-specific, ensuring high availability and optimal response times for larger tenants without affecting others.

3. Automated Multi-Tenant Filtering Tests

Automated Testing for Security and Compliance

• To ensure that multi-tenant filtering and segregation mechanisms work as intended, we have implemented automated tests that continuously verify that all operations respect tenant boundaries.

• These tests are triggered during the development and deployment pipeline to verify that:

  1. Query filtering by organisation is enforced across all database and search operations.

  2. Data from one organisation cannot be accessed by another, ensuring complete data isolation at all stack layers.

Key Test Scenarios

• Data Access Control: Automated tests validate that users can only access data associated with their organisation.

• Cross-Tenant Search Prevention: Queries executed via OpenSearch are verified to return only data from the organisation's alias.

• Index Isolation Testing: Where data has been moved to dedicated indices, tests ensure that the segregation is complete and access is limited to the appropriate tenant.