This document outlines the architectural blueprints, security postures, and data boundary layers governing internal and external communications on our Sovereign Infrastructure platform.
Our systems reject the traditional, wide-open “guest access” model in favor of a Zero-Trust Boundary Framework. By separating identity directories from real-time media routing and data-sharing pipelines, we mirror the exact security postures deployed by enterprise industry leaders like Microsoft Teams and Zoom.
🛠️ The Three-Tier Boundary Framework
Our appliance operates on a modular, tiered architecture. By default, your core data systems and internal communication grids are hidden entirely from public view, allowing you to selectively open secure, audited pathways to the outside world.
Tier 1: The Sovereign Base (Defederated Fortress) — DEFAULT POSTURE
- The Perimeter Posture: 100% closed, dark, and private.
- Technical Reality: The appliance initializes with global Matrix federation entirely deactivated, and all core data platforms completely locked down. The internal database engines, the LiveKit real-time media streaming fabric, and local storage arrays are bound strictly to private interfaces. They communicate exclusively over the cryptographically secure, kernel-level Defguard WireGuard VPN network layer.
- Nextcloud Layer-7 Edge Isolation: While internal employees access the full Nextcloud administrative workspace behind the Defguard VPN, public file sharing is hardened out of the box. Our custom Traefik reverse proxy perimeter gate applies an aggressive whitelist policy at the HTTP request path level (Layer 7). It explicitly drops all public internet traffic targeting the file domain unless the URL matches the precise cryptographic paths Nextcloud uses to render public shares (e.g.,
/s/). - Security Outcome: Complete immunity to public internet port scanning, malicious metadata harvesting, and external spam vectors. If a bad actor or automated bot attempts to access your login or admin pages (
/login,/admin,/remote.php), the edge proxy terminates the request instantly with an HTTP 403 Forbidden error. Your authentication endpoints are entirely invisible to the public internet, rendering brute-force and credential-stuffing attacks impossible.
Tier 2: Controlled Federation (The Inclusion Toggle) — INCLUDED
- The Perimeter Posture: Explicit boundary permission and cross-domain trust.
- Technical Reality: Administrators can optionally enable public federation routes via a simple environment variable toggle. When enabled, the core
tuwunelservice securely exposes standard Matrix federation endpoints through the Traefik reverse proxy. This allows external users operating on public networks (such asmatrix.org) or foreign corporate homeservers to communicate with internal staff. - Security Outcome: Your organization hosts zero guest accounts and inherits zero metadata or caching overhead. External users maintain their own identities on their own home servers. However, when collaborating inside your infrastructure, your local LiveKit/CoTurn engine retains full media routing authority. You command the performance and data transport of the room without exposing your identity directories.
Tier 3: The Isolated DMZ Server (Premium Compliance Add-On) — UPGRADE
- The Perimeter Posture: Complete Air-Gapped Network Segmentation.
- Technical Reality: Tailored for environments operating under strict legal frameworks (e.g., defense contracting, corporate law, financial compliance) that strictly forbid public federated connections from piercing internal storage volumes. We deploy a secondary, completely independent Tuwunel server instance on a distinct Virtual Machine (VM) boundary inside a restricted DMZ (Demilitarized Zone). External guests register local accounts only on this node via standard password authentication. Internal staff oversee this node seamlessly via a private, backend ChatOps automation bot.
- Security Outcome: Total physical and cryptographic separation between proprietary corporate assets and unvetted guest data caches. External metadata, file attachments, and profile databases never touch your internal storage arrays, yet internal staff communicate effortlessly without managing secondary logins.
📊 Industry Alignment: How We Mirror Teams and Zoom
Our multi-tiered philosophy isn’t an experimental approach—it is the direct translation of modern enterprise security standards. Both Microsoft Teams and Zoom split their collaboration architectures into distinct layers to separate internal workflows from guest data.
| Collaboration Layer | Microsoft Teams Model | Zoom Model | Our Sovereign Solution |
|---|---|---|---|
| Transient / External Collaboration | External Access (Federation) Allows 1:1 chat and calls with external addresses. The guest remains on their own corporate/personal tenant. No account is created in your directory. | External Meeting Link Guests join transient video meetings via a browser or personal account. Guests gain zero visibility into internal chat spaces, whiteboards, or corporate directories. | Tier 2: Controlled Federation External users enter your meeting spaces using their existing matrix.org or corporate identity. You handle the media routing; they handle their own account overhead. |
| Strict Boundary Collaboration | Guest Access (Entra ID B2B) For deep collaboration. Microsoft provisions a guest profile inside your private directory. The user must explicitly switch corporate profiles to enter your locked perimeter. | External Channels / Managed Domains To prevent random abuse, admins must explicitly whitelist external email domains or invite vetted users into strict, boundary-controlled, audited chat channels. | Tier 3: Isolated DMZ Server An entirely separate guest homeserver deployed on an isolated VM network boundary. Secured and automated via an internal ChatOps bot layer to prevent any data contamination. |
1. The Microsoft Teams Topology Match
Microsoft Teams explicitly separates External Access (Federation) from Guest Access. In the core tier, external users are merely participants in a shared space—they cannot browse your internal channels, look at company files, or touch your underlying SharePoint assets. When deep access is required, they utilize Entra ID B2B guest provisioning, forcing a hard profile switch inside the app to jump from one security context to another.
2. The Zoom System Topology Match
Zoom structures its network around the axiom that meetings are fleeting, but corporate spaces are permanent. While anyone can hit a public meeting link to pass media through their routing pipelines, a guest has absolute zero visibility into internal Zoom Team Chat nodes or phone networks. For permanent partner collaboration, they switch to audited “External Channels” bound by administrative whitelists.
Security Architecture Summary
By designing our Sovereign Appliance around these exact boundary lines, we offer a system that adapts natively to your compliance requirements:
- Data Isolation by Default: Your internal company communications, passwords, internal documents, and emails are locked inside an un-scannable network perimeter managed by Defguard.
- Reputation & Resource Protection: Forcing public guests to use federated identities (
matrix.org) prevents third-party actors from utilizing your client’s hardware resources, disk blocks, and IP reputation for non-business related activities. Meanwhile, our Layer-7 proxy filtering guarantees that public file links can be shared freely without exposing the server’s underlying system portals. - Instant Offboarding Control: When a contract ends or a project concludes, your administrative team simply removes the external user from the shared room. Because no local account was ever provisioned for them, their access to your corporate perimeter drops to absolute zero instantly.
🔄 Cloud Storage Disruption: Defeating the “Big Cloud” Security Paradigm
Traditional enterprise file sharing relies on public cloud providers—such as Google Drive, Microsoft OneDrive, Dropbox, and Box. While convenient, these platforms operate under a multi-tenant cloud storage model that forces organizations to accept massive security trade-offs, configuration liabilities, and data exposure vectors.
By running our Sovereign Base Appliance with Hardened Nextcloud Ingress, your data security profile shifts from reactive cloud protection to absolute physical and logical isolation.
Here is how our architectural model directly compares to the public standard, and why it is fundamentally more secure.
1. Architectural Blueprint Comparison
| Security Vector | Google Drive / OneDrive / Dropbox / Box | Our Hardened Nextcloud Appliance |
|---|---|---|
| Data Residency | Shared Public Cloud Infrastructure (Multi-Tenant). Your data sits on shared physical drives alongside millions of other companies. | Single-Tenant Private Infrastructure. Your data lives on a dedicated virtual engine inside your own sovereign perimeter. |
| Encryption Keys | Vendor-Managed Keys. The cloud provider holds the keys and can decrypt your files for indexing, scanning, or government data requests. | Sovereign-Controlled Keys. You retain 100% ownership of your cryptographic keys. No third-party corporate entity can read your data blocks. |
| Attack Surface | Global Public Ingress. The login portal, file sharing API, and authentication endpoints are permanently exposed to the open web. | Layer-7 Edge Isolation. The entire administrative console, web DAV paths, and login screens are 100% invisible to the public internet. |
| Authentication Risk | Vulnerable to global credential stuffing, brute-force attacks, and session token hijacking from the public web. | Protected behind kernel-level Defguard WireGuard VPN authentication. Zero public authentication exposure. |
2. Three Reasons Our Nextcloud Configuration Outperforms Public Big Cloud
I. Total Eradication of the Public Login Vector
When you use Dropbox, Box, or OneDrive, your employees log into the exact same public URL endpoints as the rest of the world. Because these landing pages must remain accessible to the open internet so users can sign in, they are constantly subjected to automated credential-stuffing bots, brute-force attacks, and targeted phishing loops.
Our architecture completely removes this entry point. Because the Nextcloud login, administrative workspace, and synchronization APIs are bound tightly inside your private network, there is no public page to attack. Bad actors cannot brute-force a login screen that literally does not exist to the public web.
II. Granular Isolation of Directory Configuration Leaks
In standard public cloud environments, a single user configuration error can expose an entire internal account directory. If an internal endpoint or WebDAV path is accidentally shared or exposed, the entire root interface becomes an active target for external discovery.
Our custom Traefik Layer-7 filtering rules act as an absolute perimeter constraint. While a user can still generate a public /s/ link to share an individual file or an entire project folder, the edge proxy guarantees that public access is strictly isolated to that specific tokenized pathway. Even if internal configuration files or broader application paths are inadvertently referenced or exposed internally, Traefik stubbornly drops any incoming public request targeting standard directory roots, global app paths, or raw internal endpoints (like /remote.php/dav/). External visibility is structurally bottlenecked only to what is explicitly served within the /s/ architecture.
III. True Data Privacy vs. Vendor Processing
Public cloud operators like Microsoft and Google routinely scan corporate documents, emails, and images to train AI models, generate search metadata, and build user profiles. Even when wrapped in “enterprise compliance” agreements, your intellectual property is processed on third-party computing systems.
Our platform guarantees absolute digital sovereignty. Your data is never indexed, parsed, or scanned by an outside corporation. It remains stored natively on your single-tenant appliance, processed exclusively by open-source code running under your direct oversight.