Defense in Depth Architecture

The Challenge

As a cybersecurity professional building a personal brand and business presence, I faced a critical architectural decision: should business services, personal portfolio, mentorship platform, and professional network all live under a single domain?

The answer was clear — no. In cybersecurity, we preach defense in depth. It was time to practice what I teach.

Why Domain Separation Matters

Attack Surface Isolation: A vulnerability in one site shouldn't compromise the other
Credential Separation: Different origins prevent session and cookie sharing across domains
Infrastructure Independence: Updates, deployments, and configurations remain isolated
Professional Compartmentalization: Business services separate from personal mentorship content
Deployment Risk Management: Experimental changes to one site won't affect the other's operations

                    Core Principle: In security architecture, assume breach. When (not if) one asset is compromised, the blast radius should be minimized.
                

The Solution

I architected a dual-domain strategy with complete infrastructure isolation between the personal brand and the business-facing site. Each property operates independently with its own codebase, deployment pipeline, hosting configuration, and security policies.

Architecture Principles

Separate domains — Each site has its own domain, keeping business and personal identities distinct
Isolated codebases — Independent repositories with no shared dependencies or configuration
Independent deployments — Changes to one site deploy without touching the other
Hardened security posture — Custom security headers enforced at the edge, including CSP, framing protections, and permissions policies
Automated CI/CD — Push-to-deploy pipelines for both sites with zero manual intervention

Both sites run on edge infrastructure with CDN-backed delivery, SSL encryption, and proxied DNS — keeping origin servers hidden and traffic encrypted end-to-end.

Implementation Journey

What seemed straightforward on paper became a masterclass in reading documentation and troubleshooting deployment pipelines. The process reinforced a lesson every engineer learns eventually: the gap between "it should work" and "it works" is where the real learning happens.

Platform Selection

Choosing the right hosting product was the first hurdle. Cloud platforms often offer multiple products that sound similar but serve fundamentally different purposes. One is designed for serverless compute and edge functions. The other is designed for static site hosting with automatic deployments from version control. Selecting the wrong one led to an immediate deployment failure and a lesson in reading product documentation more carefully.

                    Critical Learning: Serverless compute platforms and static site hosting platforms are fundamentally different products, even when offered by the same provider. Know the difference before you deploy.
                

DNS and SSL

Connecting custom domains required configuring DNS records and provisioning SSL certificates. The process was straightforward once I understood the expected setup, but testing too early — before propagation completed — led to false negatives that initially looked like configuration errors.

Security Hardening

Both sites were hardened with custom security headers enforced at the edge. This includes protections against clickjacking, MIME-type sniffing, cross-site scripting, and unauthorized framing. Content Security Policies restrict what resources the browser is allowed to load, limiting the impact of any injected content.

Cross-Site Linking

The two sites link to each other via navigation elements, using proper security attributes to prevent tab-napping and referrer leakage. The sites are connected for user experience but remain architecturally isolated.

The Results

Complete infrastructure isolation — Neither site shares hosting, code, credentials, or deployment pipelines with the other
Zero-downtime deployment — Both sites went live with no service interruption
Hardened security posture — Security headers, SSL, and edge-proxied DNS protecting both properties
Automated deployments — Code pushed to version control deploys automatically, no manual steps required
Minimal blast radius — A compromise of one site cannot propagate to the other

Lessons Learned

1. Read the Documentation First

Cloud platforms move fast. Product names change, features overlap, and assumptions from past experience don't always hold. Taking 30 minutes to read the documentation before deploying would have saved hours of troubleshooting.

2. DNS Propagation Requires Patience

SSL certificate provisioning and DNS propagation take time. Testing immediately after configuration often leads to false negatives. Give the infrastructure time to settle before assuming something is broken.

3. Document During Implementation, Not After

Writing this case study while implementing (rather than weeks later) captured authentic decision points and troubleshooting moments that would have been forgotten.

4. Defense in Depth Is More Than Theory

Implementing domain separation isn't just a security best practice — it's a forcing function for better architecture. Separate repositories, isolated credentials, independent deployments, and compartmentalized risk all emerged naturally from the decision to separate domains.

                    Final Thought: The best security architectures are the ones you can explain clearly. If you can't articulate why you made a decision, you probably haven't thought it through.
                

Want to Know More?

This writeup covers the strategy and outcomes without exposing implementation specifics. If you're interested in the technical details, how this architecture could apply to your own business, or want to discuss security-first design, reach out.

Join the community — Sign up for the waitlist to get updates on projects like this
Reach out directly — [email protected]