Customer Account Isolation | Multi-Tenant Security

What Is Customer Account Isolation

Customer account isolation keeps files, processes, and credentials separate when different tenants use the same server. In shared infrastructure and cloud computing, it helps protect secure data and prevent unauthorized access when tenants share the same platform.

Effective data isolation requires fine-grained access control, suitable access policies, and clear policy enforcement across the underlying infrastructure. These controls help protect customer environments, internal business units, and new teams, while reducing the risk of exposing anything to external users.

The 7 Layers of Customer Account Isolation

Multi-tenancy is foundational for scalable cloud computing.

Customer account isolation requires multiple security layers working together. Each layer protects a different part of the server. Data isolation techniques include software and hardware-based methods. Software-based isolation includes segmentation and paging mechanisms, while hardware-based isolation uses extended page tables for memory virtualization.

💡Isolation Security Quicklist:

Listed in priority order:

User and Identity Isolation
Filesystem and Ownership
System Boundary Isolation
Process & Resource Isolation
Apps and Container Isolation
Database & Network Isolation

Note: This guide uses Debian 13 code examples.

1. User and Identity Isolation

User isolation, also known as “Tenant Isolation,” is the most important step. A reseller business with multiple tenants on the same physical infrastructure must provide each user with a separate Linux user account. On a Unix system, user IDs (UIDs) and group membership help determine which files and resources an account is allowed to access.

Whenever multiple tenants run on the same platform, shared accounts increase the risk of cross-tenant access. If one website gets compromised, an attacker might read another tenant’s data, modify its files, or steal credentials. Separate accounts provide the first and most important layer of account isolation.

1.1: How to Create Separate User Accounts:

We’ll use Debian 13 for the examples. The commands also work on Ubuntu Server.

First, create two customer accounts:

sudo adduser customer_1
sudo adduser customer_2

Each account gets its own UID, primary group, and home directory.

1.2: Verify User IDs and Group Membership

id customer_1
id customer_2

Separate users are only the starting point. You still need to configure file permissions, ownership, and directory access to prevent other users from reading or modifying.

Note: Account isolation helps comply with regulations like GDPR and HIPAA, reducing legal risks.

2. Filesystem and Ownership

Separate Linux users are a good start, but they don’t guarantee tenant isolation on their own. You also need to control who can read, modify, or execute files.

Linux uses file ownership and Linux file permissions to restrict access. So, without proper settings, one compromised website might gain access to another tenant’s configuration files, credentials, or app code.

This creates a risk of cross-tenant access and exposes sensitive data.

2.1: Set Linux File Ownership

On Debian, use chown to assign files to the correct customer:

sudo chown -R customer_1:customer_1 /home/customer_1
sudo chown -R customer_2:customer_2 /home/customer_2

Each customer should own its own files.

Important: Avoid assigning unrelated customer directories to the same user or group.

2.2: Set Linux File Permissions

Use the chmod command to restrict access:

sudo chmod 750 /home/customer_1
sudo chmod 750 /home/customer_2

With 750, the owner has read, write, and execute permissions.

Note: You can also use “600,” which only allows the owner to read and write.

3. System Boundary Isolation

With file permissions, we now have control over which user can access certain files, but they are still not fully hidden from the system itself. You also need to deploy system-level isolation to restrict which parts of the filesystem and operating environment a customer can see.

Without it, a compromised application might inspect system files, find configuration details, or access mounted directories. In a multi-tenant model, this increases the risk of cross-tenant access, especially when several customers share the same server.

On Debian, chroot changes the apparent root directory for a process. This limits its filesystem view, provided the environment is configured correctly.

sudo mkdir -p /srv/jails/customer_1
sudo chroot /srv/jails/customer_2 /bin/sh

The second command works only if the jail contains a compatible shell and its required libraries. A basic chroot is not a complete security boundary because it does not isolate processes, networking, or kernel.

For untrusted workloads, consider containers with properly configured namespaces, restricted capabilities, and filesystem mounts. For stronger separation between customers, virtual machines provide a separate guest operating system and kernel.

4. Process & Resource Isolation

Even with separate users and filesystem permissions, one customer’s application might consume too much CPU or memory, or attempt to inspect other running processes. We can’t allow this. Otherwise, other tenants could feel the impact.

Process isolation will limit what applications can access, while resource limits help prevent one tenant from affecting everyone else on a shared server.

4.1 Run Services Under Dedicated Users

On Debian, use systemd to run each application under its own unprivileged account.

sudo systemctl edit customer-1.service

Add the following configuration:

[Service]
User=customer_1
Group=customer_1
NoNewPrivileges=true
PrivateTmp=true

Note: Replace customer-1.service with your actual service name.

Apply the changes:

sudo systemctl daemon-reload
sudo systemctl restart customer-1.service

4.2: Limit CPU and Memory Usage

Add resource limits to the same systemd service override:

[Service]
CPUQuota=50%
MemoryMax=512M
TasksMax=100

This is just an example. Adjust the limit values to match the application’s requirements.

Note: Logical isolation prevents cross-account data access by using tenant identifiers in queries.

5. Apps and Container Isolation

By now, we already have strong isolation, but all applications still share the host kernel and other system resources. Containers add another layer by isolating processes, filesystem views, and network interfaces.

If we leave things as they are now, a compromised application might access sensitive host files, exploit excessive container privileges, or reach resources belonging to other tenants.

5.1: Run Containers as a Non-Root User

FROM debian:13-slim

RUN useradd --create-home appuser
USER appuser

CMD ["sleep", "infinity"]

For a real application, replace the placeholder “appuser” command with its normal startup command and ensure the user has access to required files.

5.2: Restrict Container Privileges

When starting a container, drop unnecessary Linux capabilities and prevent privilege escalation:

docker run -d \
  --name customer_a \
  --user 1000:1000 \
  --cap-drop ALL \
  --security-opt no-new-privileges:true \
  --read-only \
  --tmpfs /tmp \
  debian:13-slim sleep infinity

This example uses a read-only root filesystem, drops Linux capabilities, and prevents processes from gaining additional privileges.

Note: Avoid –privileged and unnecessary host directory mounts, since both weaken isolation.

6. Database & Network Isolation

Each tenant needs separate database privileges and controlled network access to prevent cross-tenant access. Network segmentation keeps data traffic separate within a multi-tenant architecture. Without these controls, a compromised application might access another customer’s database records, connect to internal services, or expose credentials.

6.1: Create Separate Database Users

For PostgreSQL, create a dedicated role for each application:

CREATE ROLE customer_a LOGIN PASSWORD 'REPLACE_WITH_STRONG_SECRET';
CREATE DATABASE customer_1_db OWNER customer_1;

Repeat the process for other customers, using unique credentials and databases. Store passwords securely rather than hardcoding them in application code.

6.2: Restrict Database Network Access

If PostgreSQL runs on the same server as the app, configure it to listen only on the required interface.

In postgresql.conf:

listen_addresses = 'localhost'

Then review pg_hba.conf to restrict which users and addresses are allowed to connect.

Note: Kubernetes supports multi-tenancy through namespaces and virtual clusters.

How to Verify Customer Account Isolation

After configuring each isolation layer, we strongly recommend testing them to verify permissions and security controls work as expected.

Verify User and Identity Isolation

id customer_1
id customer_2

Expected Output: Each user has a different UID and the intended group memberships. Neither account should have unnecessary administrative privileges.

Verify Permissions and Ownership

ls -ld /home/customer_1 /home/customer_2
ls -l /home/customer_a/.env

Expected Output: Each directory belongs to the correct customer. A sensitive .env file with mode 600 should be readable and writable only by its owner.

Verify System Boundary Isolation

sudo chroot /srv/jails/customer_1 /bin/sh -c \
  'ls -la /'

Expected Output: The command lists the jail’s root directory, not the host’s actual root filesystem. Remember, this test confirms the filesystem view only. It does not prove complete system isolation.

Verify Process & Resource Isolation

systemctl show customer-a.service \
  -p User -p Group -p CPUQuota \
  -p MemoryMax -p TasksMax

Expected Output: The service runs as customer_a with the configured CPU, memory, and task limits. Confirm the values match your service override.

Verify the Containerization Isolation

docker inspect customer_1 \
  --format 'User={{.Config.User}} ReadonlyRootfs={{.HostConfig.ReadonlyRootfs}}'

docker inspect customer_1 \
  --format '{{json .Mounts}}'

Expected Output: The configured non-root user is shown, ReadOnlyRootFs=true appears if you enabled a read-only root filesystem, and mounts include only the paths the application requires.

Verify Database and Network Isolation

sudo ss -lntp | grep 5432

Expected Output: If PostgreSQL is configured for local-only access, it should listen on 127.0.0.1:5432 or another intended local address, not a public interface.

What Is Physical Isolation in Hosting?

Physical isolation utilizes dedicated hardware for higher-security customers to prevent data sharing. It separates customer workloads onto dedicated hardware, creating isolated environments and reducing reliance on shared resources. It is best suited for resellers and other businesses with strict compliance requirements or a need for greater infrastructure control.

Physical isolation does not replace software security. Security depends on proper network rules, account permissions, and standard permissions such as group permissions and write access controls. All admins must also understand octal values, the set group ID bit, and the sticky bit when managing files.

The right isolation models depend on the context, the total number of tenants, and the required security level. Dedicated servers provide stronger hardware separation, while correct permissions and access policies help prevent unauthorized access without unnecessary operational overhead.

Multi-Tenant Reseller Hosting Infrastructure at ServerMania

ServerMania Dedicated Servers give hosting resellers the control and performance needed to manage multiple customer environments. Configure your infrastructure, apply the right isolation controls, and keep customer workloads separate with properly managed resources.

💬If you have questions, get in touch with our 24/7 customer support or book a free consultation to discuss your reseller business directly with an industry expert.

Frequently Asked Questions:

How do Linux permissions prevent unauthorized access?

When a user creates a regular file, Linux assigns ownership and permissions that determine who may access resources. Even when two users share a server, these controls limit access to files and prevent unauthorized attempts to share data.

How does the control plane manage customer access?

The control plane manages access policies and authentication. OAuth and JWTs are commonly used for authentication tokens to support precise access control, helping ensure users access only the resources permitted by their assigned roles.

How does memory protection improve isolation?

Hardware security tools such as Execute-no-Read (XnR) prevent reading executable memory, while Memory Protection Keys (MPKs) allow applications to control access to tagged memory pages. These mechanisms provide a certain level of memory protection, but they do not replace account isolation.

What happens to customer data after deletion?

Data blocks are zeroed out upon deletion to ensure data security between accounts. The exact method depends on the storage technology and deletion process. Access controls should also cover two modes of operation, such as reading and writing, and restrict executable permissions where they are not needed.

Customer Account Isolation | Multi-Tenant System Security