Network Segregation Documentation

Document Version: 1.0
Date: July 25, 2025
Owner: Dominick Pham, CTO
Classification: Internal Use - SOC2 Compliance

Executive Summary

This document provides evidence of network segregation between Qwestly's production, development, and other environments to satisfy SOC 2 Type II audit requirements. Our cloud-native serverless architecture implements logical network segregation through multiple layers including separate deployment environments, isolated databases, segregated access controls, and environment-specific configurations.

Environment Overview

Qwestly operates a cloud-native architecture with clear segregation between environments implemented through:

• Vercel Platform Isolation: Separate projects and deployment targets
• Database Environment Segregation: Isolated database instances and access controls
• AWS Resource Isolation: Environment-specific S3 buckets and CloudFront distributions
• Access Control Segregation: Role-based access with environment-specific permissions
• Configuration Isolation: Separate environment variables and secrets management

1. Environment Architecture and Segregation

graph TD
    %% Development Environment (Top Level)
    subgraph "🔧 Development Environment"
        direction TB
        subgraph "Local Development"
            LOCAL_DEV["👨‍💻 Developer Workstations"]
            LOCAL_TOOLS["🛠️ Local Tools & Testing"]
        end
        
        LOCAL_DEV --> PREVIEW_DEPLOY
        
        subgraph "Vercel Preview Deployments"
            PREVIEW_DEPLOY["🚀 Preview Deployments"]
            DEV_APPS["📱 Preview Apps
• Main App Preview
• Candidate Portal Preview
• Public Site Preview
• Python API Preview"]
        end
        
        PREVIEW_DEPLOY --> DEV_APPS
        DEV_APPS --> DEV_DATA
        
        subgraph "Development Data & Services"
            DEV_DATA["💾 Development Data Layer"]
            DEV_DETAILS["🔹 Dev MongoDB Cluster
🔹 Dev Supabase Project
🔹 Dev S3 Buckets
🔹 Auth0 Development"]
        end
    end
    
    %% Network Boundary
    DEV_DETAILS -.->|"🚫 Network Isolation"| STAGE_DATA
    
    %% Staging Environment (Middle Level)
    subgraph "🧪 Staging Environment"
        direction TB
        subgraph "Vercel Staging Platform"
            STAGE_DEPLOY["🎯 Staging Deployments"]
            STAGE_APPS["📱 Staging Apps
• Main App Staging
• Candidate Portal Staging
• Public Site Staging
• Python API Staging"]
        end
        
        STAGE_DEPLOY --> STAGE_APPS
        STAGE_APPS --> STAGE_DATA
        
        subgraph "Staging Data & Services"
            STAGE_DATA["💾 Staging Data Layer"]
            STAGE_DETAILS["🔸 Staging MongoDB Cluster
🔸 Staging Supabase Project
🔸 Staging S3 Buckets
🔸 Auth0 Development (Shared)"]
        end
    end
    
    %% Network Boundary
    STAGE_DETAILS -.->|"🚫 Network Isolation"| PROD_DATA
    
    %% Production Environment (Bottom Level)
    subgraph "🏭 Production Environment"
        direction TB
        subgraph "Vercel Production Platform"
            PROD_DEPLOY["⚡ Production Deployments"]
            PROD_APPS["📱 Production Apps
• hire.qwestly.com
• discover.qwestly.com
• qwestly.com
• api.qwestly.com"]
        end
        
        PROD_DEPLOY --> PROD_APPS
        PROD_APPS --> PROD_DATA
        
        subgraph "Production Data & Services"
            PROD_DATA["💾 Production Data Layer"]
            PROD_DETAILS["🔺 Production MongoDB Cluster
🔺 Production Supabase Project
🔺 Production S3 Buckets
🔺 Production CloudFront
🔺 Auth0 Production"]
        end
    end
    
    %% External Services (Side Panel)
    subgraph "🌐 External Services (Environment Isolated)"
        direction TB
        EXT_AI["🤖 AI Services
Environment-specific API Keys"]
        EXT_MONITOR["📊 Monitoring Services
Environment-tagged Analytics"]
        EXT_EMAIL["📧 Email Services
Environment-specific Config"]
    end
    
    %% Environment connections to external services
    DEV_APPS -.-> EXT_AI
    STAGE_APPS -.-> EXT_AI
    PROD_APPS -.-> EXT_AI
    
    DEV_APPS -.-> EXT_MONITOR
    STAGE_APPS -.-> EXT_MONITOR
    PROD_APPS -.-> EXT_MONITOR
    
    %% Cross-environment access restrictions (highlighted blocks)
    subgraph "🛡️ Security Boundaries"
        BLOCKS["❌ Blocked Cross-Environment Access
• Dev Apps → Production DB
• Preview → Production S3
• Local → Production APIs
• Staging → Production MongoDB"]
    end
    
    %% Styling for better visual hierarchy
    classDef development fill:#e3f2fd,stroke:#1976d2,stroke-width:3px
    classDef staging fill:#fff3e0,stroke:#f57c00,stroke-width:3px
    classDef production fill:#ffebee,stroke:#d32f2f,stroke-width:3px
    classDef external fill:#f3e5f5,stroke:#7b1fa2,stroke-width:2px
    classDef security fill:#ffcdd2,stroke:#d32f2f,stroke-width:2px,stroke-dasharray: 5 5
    
    class LOCAL_DEV,PREVIEW_DEPLOY,DEV_APPS,DEV_DATA,DEV_DETAILS development
    class STAGE_DEPLOY,STAGE_APPS,STAGE_DATA,STAGE_DETAILS staging
    class PROD_DEPLOY,PROD_APPS,PROD_DATA,PROD_DETAILS production
    class EXT_AI,EXT_MONITOR,EXT_EMAIL external
    class BLOCKS security

2. Vercel Platform Segregation

Project-Level Isolation

Qwestly implements strict environment segregation through Vercel's platform architecture:

Production Environment

• Project Isolation: Separate Vercel projects for production deployments
• Domain Isolation: Production-only domains (qwestly.com, app.qwestly.com, candidate.qwestly.com)
• Environment Variables: Production-specific secrets and configurations
• Access Control: Restricted team member access to production projects

Preview/Development Environment

• Automatic Preview Deployments: Every pull request generates isolated preview environments
• Temporary URLs: Unique URLs for each preview deployment (e.g., qwestly-app-git-feature-branch-qwestly.vercel.app)
• Development Variables: Separate environment variables pointing to development resources
• Unrestricted Access: All team members can access preview deployments

Configuration Evidence

Vercel Project Structure:

Production Projects:
├── qwestly-app (hire.qwestly.com)
├── candidate-portal (discover.qwestly.com)
├── public-site (qwestly.com)
└── api-python (api.qwestly.com)

Preview Projects:
├── qwestly-app-preview (auto-generated URLs)
├── candidate-portal-preview (auto-generated URLs)
├── public-site-preview (auto-generated URLs)
└── api-python-preview (auto-generated URLs)

3. Database Environment Segregation

MongoDB Atlas Segregation

Production Database Cluster

• Cluster Name: qwestly-production-cluster
• Network Access: Restricted IP allowlist containing only production Vercel IP ranges
• Database Authentication: Production-specific MongoDB connection strings
• Backup Configuration: Production-grade backup with point-in-time recovery
• Monitoring: Production alerting thresholds and monitoring

Development/Staging Database Cluster

• Cluster Name: qwestly-development-cluster
• Network Access: Open to development IP ranges and preview deployment IPs
• Database Authentication: Development-specific MongoDB connection strings
• Resource Allocation: Lower-tier instances appropriate for development workloads
• Data Isolation: Completely separate data from production

Network Access Control Evidence:

Production Cluster IP Allowlist:
- Vercel Production IP Range: 76.76.19.0/24
- Vercel Production IP Range: 64.23.132.0/24

Development Cluster IP Allowlist:
- Vercel Preview IP Range: 172.0.0.0/8
- Developer Home IPs: [Individual IP addresses]
- Office Network: [If applicable]

Supabase Environment Segregation

Production Supabase Project

• Project ID: qwestly-production
• Database: Isolated PostgreSQL instance for vector storage
• API Keys: Production-specific Supabase API keys
• Row Level Security: Production data access policies
• SSL Enforcement: Required for all connections

Development Supabase Project

• Project ID: qwestly-development
• Database: Separate PostgreSQL instance for development
• API Keys: Development-specific Supabase API keys
• Relaxed Policies: Development-appropriate access controls
• Data Seeding: Test data isolated from production

4. AWS Resource Segregation

S3 Bucket Segregation

Production S3 Buckets

Production Buckets:
├── qwestly-prod-documents
├── qwestly-prod-user-uploads
├── qwestly-prod-logs
├── qwestly-prod-backups
└── qwestly-prod-static-assets

Bucket Policies (Production):

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "RestrictToProductionOnly",
      "Effect": "Allow",
      "Principal": {
        "AWS": "arn:aws:iam::ACCOUNT:role/qwestly-production-role"
      },
      "Action": ["s3:GetObject", "s3:PutObject", "s3:DeleteObject"],
      "Resource": "arn:aws:s3:::qwestly-prod-*/*"
    }
  ]
}

Development S3 Buckets

Development Buckets:
├── qwestly-dev-documents
├── qwestly-dev-user-uploads
├── qwestly-dev-logs
└── qwestly-dev-static-assets

Bucket Policies (Development):

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "RestrictToDevelopmentOnly",
      "Effect": "Allow",
      "Principal": {
        "AWS": "arn:aws:iam::ACCOUNT:role/qwestly-development-role"
      },
      "Action": ["s3:*"],
      "Resource": "arn:aws:s3:::qwestly-dev-*/*"
    }
  ]
}

CloudFront Distribution Segregation

Production CloudFront

• Distribution ID: E1234567890ABC
• Origin: qwestly-prod-static-assets S3 bucket
• Domain: assets.qwestly.com
• SSL Certificate: Production wildcard certificate
• Cache Policies: Production-optimized caching

Development CloudFront

• Distribution ID: E0987654321XYZ
• Origin: qwestly-dev-static-assets S3 bucket
• Domain: dev-assets.qwestly.com
• SSL Certificate: Development certificate
• Cache Policies: Development-appropriate (shorter TTL)

5. Access Control Segregation

GitHub Repository Access Controls

Production Branch Protection

Production Branch (main):
  - Require pull request reviews: true
  - Required approvals: 2
  - Dismiss stale reviews: true
  - Require status checks: true
  - Restrict pushes to admins only: true
  - Allow force pushes: false
  - Allow deletions: false

Development Branch Access

Development Branches (feature/*):
  - Require pull request reviews: false
  - Required approvals: 1
  - Allow direct pushes: true (for development)
  - Unrestricted access for team members

Vercel Team Access Controls

Production Environment Access

Production Access (Restricted):
├── Adam Boender (CEO) - Admin
├── Dominick Pham (CTO) - Admin
└── Senior Engineers - Viewer (Deploy access restricted)

Development Environment Access

Development Access (Open):
├── All Team Members - Developer
├── Contractors - Viewer
└── External Contributors - No Access

Environment Variable Segregation

Production Environment Variables

Production Variables (Encrypted at Rest):
├── MONGODB_PROD_CONNECTION_STRING
├── SUPABASE_PROD_URL
├── SUPABASE_PROD_ANON_KEY
├── AUTH0_PROD_DOMAIN
├── AUTH0_PROD_CLIENT_ID
├── AWS_PROD_ACCESS_KEY_ID
├── ANTHROPIC_PROD_API_KEY
└── SENDGRID_PROD_API_KEY

Development Environment Variables

Development Variables:
├── MONGODB_DEV_CONNECTION_STRING
├── SUPABASE_DEV_URL
├── SUPABASE_DEV_ANON_KEY
├── AUTH0_DEV_DOMAIN
├── AUTH0_DEV_CLIENT_ID
├── AWS_DEV_ACCESS_KEY_ID
├── ANTHROPIC_DEV_API_KEY
└── SENDGRID_DEV_API_KEY

6. Network Traffic Flow Restrictions

Production Network Flow

sequenceDiagram
    participant User as Production User
    participant Vercel as Vercel Production
    participant Auth0 as Auth0 Production
    participant MongoDB as MongoDB Production
    participant S3 as S3 Production

    User->>+Vercel: HTTPS Request
    Vercel->>+Auth0: Authentication (Prod Keys)
    Auth0-->>-Vercel: JWT Token
    Vercel->>+MongoDB: Database Query (Prod Cluster)
    MongoDB-->>-Vercel: Data Response
    Vercel->>+S3: File Operation (Prod Bucket)
    S3-->>-Vercel: File Response
    Vercel-->>-User: Application Response

    Note over User,S3: All connections use production credentials and endpoints

Development Network Flow

sequenceDiagram
    participant Dev as Developer
    participant Preview as Vercel Preview
    participant Auth0Dev as Auth0 Development
    participant Mongodev as MongoDB Development
    participant S3Dev as S3 Development

    Dev->>+Preview: Preview Deployment
    Preview->>+Auth0Dev: Authentication (Dev Keys)
    Auth0Dev-->>-Preview: JWT Token
    Preview->>+Mongodev: Database Query (Dev Cluster)
    Mongodev-->>-Preview: Data Response
    Preview->>+S3Dev: File Operation (Dev Bucket)
    S3Dev-->>-Preview: File Response
    Preview-->>-Dev: Preview Response

    Note over Dev,S3Dev: Isolated development environment with separate credentials

7. Monitoring and Logging Segregation

Environment-Specific Monitoring

Production Monitoring

• Vercel Analytics: Production domain monitoring with alerting
• PostHog: Production user analytics with sensitive data handling
• MongoDB Atlas Monitoring: Production cluster performance monitoring
• AWS CloudWatch: Production S3 and CloudFront monitoring
• Alert Thresholds: Production-grade alerting (immediate for critical issues)

Development Monitoring

• Vercel Analytics: Preview deployment monitoring (informational only)
• PostHog: Development analytics with test data
• Relaxed Monitoring: Development-appropriate thresholds
• No Critical Alerts: Development issues don't trigger production alerts

Log Segregation Evidence

Production Log Streams

Production Logs (S3: qwestly-prod-logs):
├── application-logs/2025/07/25/prod-app-*.log
├── api-logs/2025/07/25/prod-api-*.log
├── auth-logs/2025/07/25/prod-auth-*.log
└── security-logs/2025/07/25/prod-security-*.log

Development Log Streams

Development Logs (S3: qwestly-dev-logs):
├── application-logs/2025/07/25/dev-app-*.log
├── api-logs/2025/07/25/dev-api-*.log
├── preview-logs/2025/07/25/preview-*.log
└── test-logs/2025/07/25/test-*.log

8. Data Flow Restrictions and Controls

Cross-Environment Access Restrictions

Blocked Connections (Enforced by Network Policies)

❌ Development → Production Database
❌ Preview Apps → Production S3 Buckets
❌ Development Auth0 → Production User Data
❌ Local Development → Production APIs
❌ Staging Environment → Production MongoDB

Permitted Connections

✅ Development → Development Database
✅ Production → Production Database
✅ Preview Apps → Development S3 Buckets
✅ Local Development → Development APIs
✅ Staging → Staging Database

Network Security Groups and Access Controls

AWS IAM Role Segregation

Production IAM Role (qwestly-production-role):
{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": ["s3:*"],
      "Resource": ["arn:aws:s3:::qwestly-prod-*/*"]
    },
    {
      "Effect": "Deny",
      "Action": ["s3:*"],
      "Resource": ["arn:aws:s3:::qwestly-dev-*/*"]
    }
  ]
}

Development IAM Role (qwestly-development-role):
{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": ["s3:*"],
      "Resource": ["arn:aws:s3:::qwestly-dev-*/*"]
    },
    {
      "Effect": "Deny",
      "Action": ["s3:*"],
      "Resource": ["arn:aws:s3:::qwestly-prod-*/*"]
    }
  ]
}

9. Compliance Evidence Summary

Network Topology Evidence

• Environment Isolation Diagrams: Clear separation between production, staging, and development
• Network Flow Diagrams: Documented traffic flows with restrictions
• Access Control Matrix: Role-based access for each environment

Configuration Evidence

• Vercel Project Configurations: Separate projects with environment-specific settings
• Database Cluster Configurations: Isolated MongoDB and Supabase instances
• AWS Resource Policies: S3 bucket policies and IAM roles enforcing segregation
• Environment Variable Isolation: Separate credentials and configurations

Access Control Evidence

• GitHub Branch Protection Rules: Production branch restrictions
• Vercel Team Access Controls: Environment-specific access permissions
• Database Access Logs: Evidence of segregated database access
• AWS CloudTrail Logs: API access segregation evidence

Monitoring Evidence

• Segregated Log Streams: Environment-specific logging with no cross-contamination
• Monitoring Dashboards: Separate monitoring for each environment
• Alert Configurations: Environment-appropriate alerting thresholds
• Audit Trail: Complete audit trail of cross-environment access attempts (should show none)

10. Incident Response and Breach Isolation

Incident Isolation Procedures

• Development Issues: Isolated to development environment with no production impact
• Preview Deployment Problems: Self-contained within preview URLs
• Production Incidents: Isolated from development with separate incident response procedures
• Cross-Environment Breach Prevention: Network policies prevent lateral movement between environments

Regular Verification Procedures

• Monthly Access Reviews: Verification that no unauthorized cross-environment access exists
• Quarterly Network Audits: Comprehensive review of environment segregation controls
• Automated Monitoring: Continuous monitoring for cross-environment access attempts
• Annual Penetration Testing: Third-party verification of environment isolation

Conclusion

Qwestly's network segregation implements defense-in-depth through multiple layers:

1. Platform-Level Isolation: Vercel project segregation
2. Database Isolation: Separate clusters and instances
3. Storage Isolation: Environment-specific S3 buckets and policies
4. Access Control Segregation: Role-based access with environment restrictions
5. Configuration Isolation: Separate environment variables and secrets
6. Monitoring Segregation: Environment-specific logging and alerting

This architecture ensures that production environments remain completely isolated from development and testing environments, satisfying SOC 2 requirements for network segregation and data protection.

Document Prepared By: Dominick Pham, CTO
Review Date: July 25, 2025
Next Review: October 25, 2025
Classification: Internal Use - SOC2 Audit Evidence