## 1. Zero External Exposure (No Public Route)
The most common reason for a database breach is a database being accidentally exposed to the public internet.
On our platform, **databases have no public IP addresses and no route to the outside world**. The database service runs in a private,
isolated virtual network. There is no "front door" for an attacker to knock on, meaning brute-force attacks or
credential-stuffing attempts against your database are architecturally impossible from the outside.
## 2. Multi-Layered Logical and Physical Isolation
We utilize a defense-in-depth approach to ensure that your data is siloed:
* **Environment Isolation**: Every environment (Production, Staging, Dev) is fully isolated. We use Linux **namespaces, seccomp, and cgroups** to ensure that processes in one environment cannot see or interact with another.
* **Project Isolation**: Each project is restricted by strict filtering rules. Communication between two projects is only possible
via public APIs/Web requests; they cannot "talk" to each others' internal services.
## 3. Explicit Service Authorization (The "Need-to-Know" Principle)
In a traditional network, if an attacker gains access to any server, they can often "scan" the internal network
for other services (like a DB).
In our architecture, **nothing is accessible by default**. For an application to talk to a database,
the connection must be **explicitly declared** in the configuration. If the relationship is not defined,
the network routing literally does not exist between those two containers. This implements a "Zero Trust" model within your own cluster.
## 4. Secure Administrative Access via SSH Tunneling
When a human developer needs to access the database, they do not connect to the database port directly.
Instead, they must use a **secure SSH tunnel**.
* This requires **SSH Key-based authentication**, which is significantly more secure than a standard password.
* The user must have **explicit permission** (RBAC) to access the environment via the CLI.
* The **tunnel encrypts the data** in transit and ensures that only authorized, authenticated users can bridge the gap between their local machine and the private network.
## 5. Compliance and Third-Party Validation
Our security model isn't just a theoretical preference; it is audited and validated by leading global security standards. We maintain compliance with:
* **PCI DSS**: For handling payment card data.
* **SOC 2 Type 2**: For operational security and data privacy.
* **ISO 27001**: For information security management systems.
Numerous highly regulated organizations across financial and consumer sectors have conducted deep technical due diligence on this architecture and have verified that it meets or exceeds strict internal and global security standards.
## 6. Flexibility: Optional Password Generation
While we believe network isolation is a stronger security primitive than a shared secret, we recognize that certain organizational
policies or specific application requirements may still require a password.
The platform remains flexible: if your security policy mandates a password, you can explicitly enable **password generation**
for your MySQL/PostgreSQL services as documented [here](https://docs.upsun.com/add-services/mysql.html#password-generation).
***
As organizations continue to evolve their security strategies, moving beyond traditional password-based protection is becoming essential. Solutions like Upsun leverage network isolation to offer a robust alternative, reducing the risks associated with credential leaks and unauthorized access. However, true security is never about a single solution — it’s about building multiple layers of defense. By combining network isolation with other best practices, you can create a resilient environment that protects your data from emerging threats. Now is the time to evaluate your own infrastructure and consider how these principles, as implemented by Upsun, can help you stay ahead in the ever-changing landscape of cybersecurity.