Tutorials

Building a Zero-Trust Network with OneDot SASE

A comprehensive guide to implementing zero-trust security architecture using OneDot SASE, from planning to deployment

Marcus Chen
8 min read
#Zero Trust#SASE#Security#Tutorial#Cloud Security#Network Architecture
Building a Zero-Trust Network with OneDot SASE

Building a Zero-Trust Network with OneDot SASE

The traditional security model of "trust but verify" is fundamentally broken in today's cloud-first, remote-work environment. Organizations need a new approach: Zero Trust, which operates on the principle of "never trust, always verify." This comprehensive guide will walk you through implementing a zero-trust security architecture using OneDot SASE (Secure Access Service Edge).

Understanding Zero Trust

Before diving into implementation, let's clarify what zero trust actually means.

Core Principles

Zero trust is built on three fundamental principles:

  1. Assume Breach – Act as if attackers are already inside your network
  2. Verify Explicitly – Always authenticate and authorize based on all available data points
  3. Least Privilege Access – Limit user access with just-in-time and just-enough-access (JIT/JEA)

Why Traditional Perimeter Security Fails

The traditional "castle and moat" model fails because:

  • No perimeter exists – Users access applications from anywhere
  • Cloud apps are outside the corporate network
  • Insider threats are as dangerous as external attacks
  • Lateral movement allows attackers to spread after initial compromise

What is SASE?

SASE (Secure Access Service Edge) combines network and security functions in a cloud-delivered service. It includes:

Network Functions:

  • SD-WAN
  • WAN optimization
  • CDN

Security Functions:

  • Secure Web Gateway (SWG)
  • Cloud Access Security Broker (CASB)
  • Zero Trust Network Access (ZTNA)
  • Firewall-as-a-Service (FWaaS)

OneDot SASE delivers all these capabilities in a unified platform.

Planning Your Zero-Trust Implementation

Step 1: Inventory Your Assets

Create a comprehensive inventory of:

# Example asset inventory structure
assets:
  applications:
    - name: "CRM System"
      type: "SaaS"
      sensitivity: "high"
      users: ["sales", "marketing", "support"]

    - name: "Internal Wiki"
      type: "self-hosted"
      sensitivity: "medium"
      users: ["all_employees"]

  data:
    - category: "customer_data"
      classification: "confidential"
      location: ["aws_s3", "salesforce"]

    - category: "financial_records"
      classification: "restricted"
      location: ["on_prem_db", "oracle_cloud"]

  users:
    - group: "engineering"
      count: 150
      locations: ["office", "remote"]
      devices: ["laptop", "mobile"]

    - group: "contractors"
      count: 45
      locations: ["remote"]
      devices: ["laptop"]

Step 2: Define Access Policies

Determine who should access what under which conditions:

Risk-Based Access Control:

  • User identity
  • Device posture
  • Location
  • Time of day
  • Behavior patterns

Example Policy Framework:

{
  "policy": "high_sensitivity_data_access",
  "conditions": {
    "required": [
      "verified_identity",
      "managed_device",
      "compliant_os_version",
      "healthy_security_posture"
    ],
    "location": {
      "allowed_countries": ["US", "UK", "CN"],
      "blocked_networks": ["public_wifi"]
    },
    "time": {
      "allowed_hours": "business_hours",
      "timezone": "user_local"
    }
  },
  "access_level": "read_write",
  "mfa_required": true,
  "session_duration": 3600,
  "logging": "detailed"
}

Step 3: Segment Your Network

Microsegmentation limits lateral movement:

Traditional Segmentation:

┌─────────────────────────────────────┐
│         Entire Corporate Network     │
│  (All resources accessible to all   │
│   users once inside the network)    │
└─────────────────────────────────────┘

Microsegmentation:

┌───────────┐ ┌───────────┐ ┌───────────┐
│ Segment A │ │ Segment B │ │ Segment C │
│ (Finance) │ │ (HR)      │ │ (Eng)     │
└───────────┘ └───────────┘ └───────────┘
     ↓              ↓              ↓
  Isolated     Isolated      Isolated
  Access       Access        Access

Implementing OneDot SASE

Phase 1: Deploy SASE Connectors

Start by deploying OneDot SASE connectors in your environment.

For Cloud Applications

# Install OneDot SASE connector for AWS
curl -O https://downloads.onedotnet.com/sase/aws-connector.sh
chmod +x aws-connector.sh
./aws-connector.sh --region us-east-1 --vpc-id vpc-12345678

# Verify connector status
onedot-sase connector status

For On-Premises Applications

# Docker deployment for on-prem connector
docker run -d \
  --name onedot-sase-connector \
  --restart always \
  -v /var/run/docker.sock:/var/run/docker.sock \
  -e SASE_TOKEN="your_token_here" \
  -e CONNECTOR_NAME="datacenter-1" \
  onedotnet/sase-connector:latest

# Kubernetes deployment
kubectl apply -f https://downloads.onedotnet.com/sase/k8s-connector.yaml

Phase 2: Configure Identity Provider Integration

OneDot SASE integrates with your existing identity provider.

SAML Integration Example

<!-- Configure SAML SSO with OneDot SASE -->
<EntityDescriptor entityID="https://sase.onedotnet.com">
  <SPSSODescriptor>
    <NameIDFormat>
      urn:oasis:names:tc:SAML:2.0:nameid-format:emailAddress
    </NameIDFormat>
    <AssertionConsumerService
      Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST"
      Location="https://sase.onedotnet.com/auth/saml/callback"
      index="1" />
  </SPSSODescriptor>
</EntityDescriptor>

OIDC Integration

// Configure OIDC with Okta
const config = {
  issuer: 'https://your-org.okta.com',
  clientId: 'your_client_id',
  redirectUri: 'https://sase.onedotnet.com/auth/callback',
  scopes: ['openid', 'profile', 'email', 'groups'],
  pkce: true
};

Phase 3: Set Up Device Posture Checks

Ensure only compliant devices can access resources.

Device Posture Requirements:

# Example device posture policy
device_policy = {
    "os_requirements": {
        "windows": {
            "min_version": "10.0.19041",  # Windows 10 20H1
            "required_updates": "all_critical"
        },
        "macos": {
            "min_version": "12.0",  # macOS Monterey
            "required_updates": "all_security"
        },
        "ios": {
            "min_version": "15.0",
            "jailbreak_allowed": False
        }
    },
    "security_software": {
        "antivirus": {
            "required": True,
            "definitions_age_max_days": 7
        },
        "disk_encryption": {
            "required": True
        },
        "firewall": {
            "required": True,
            "state": "enabled"
        }
    },
    "device_management": {
        "mdm_required": True,
        "enrollment_status": "verified"
    }
}

Phase 4: Create Access Policies

Define granular policies in the OneDot SASE console.

Example: Engineering Team Access to Production

policy_name: "Engineering Production Access"
description: "Allow engineering team to access production environment"

conditions:
  identity:
    groups: ["engineering", "devops"]
    mfa: required

  device:
    managed: true
    os_patch_level: current
    antivirus: active

  location:
    allowed_countries: ["US", "CN", "UK"]
    deny_vpn_exit_nodes: true

  time:
    allowed: "business_hours"
    timezone: "UTC"

  risk_score:
    max_acceptable: 60

actions:
  allow:
    - ssh_access
    - kubectl_access
    - database_read

  deny:
    - database_write
    - config_changes

  log: all_requests

  session:
    max_duration: 14400  # 4 hours
    idle_timeout: 1800   # 30 minutes
    recording: enabled

Phase 5: Enable Application-Level Security

Apply security controls at the application layer.

Secure Web Gateway (SWG)

// Configure URL filtering and threat protection
const swgPolicy = {
  categories: {
    block: [
      'malware',
      'phishing',
      'adult_content',
      'gambling',
      'illegal_activities'
    ],
    warn: [
      'personal_email',
      'social_media',
      'file_sharing'
    ],
    allow: [
      'business_tools',
      'research',
      'approved_saas'
    ]
  },

  ssl_inspection: {
    enabled: true,
    exempt_categories: ['healthcare', 'financial'],
    exempt_domains: ['*.bank.com', 'healthcare-provider.com']
  },

  data_loss_prevention: {
    scan_uploads: true,
    scan_downloads: true,
    block_sensitive_data: ['ssn', 'credit_card', 'api_keys']
  }
};

Cloud Access Security Broker (CASB)

# Monitor and control cloud app usage
casb_policies:
  - name: "Restrict Shadow IT"
    action: block
    conditions:
      app_category: "unsanctioned"
      risk_level: "high"

  - name: "Monitor File Sharing"
    action: alert
    conditions:
      activity: "external_share"
      data_classification: "confidential"

  - name: "Enforce DLP in SaaS"
    action: block_and_alert
    conditions:
      data_patterns:
        - "credit_card"
        - "ssn"
        - "api_credentials"
      destination: "external"

Monitoring and Maintenance

Real-Time Visibility

OneDot SASE provides comprehensive visibility into:

Access Logs:

-- Query access logs
SELECT
  timestamp,
  user_id,
  device_id,
  source_ip,
  destination_app,
  action,
  risk_score,
  policy_applied
FROM access_logs
WHERE timestamp > NOW() - INTERVAL '24 hours'
  AND action = 'blocked'
ORDER BY risk_score DESC;

Security Analytics:

  • Anomalous access patterns
  • Impossible travel scenarios
  • Brute force attempts
  • Data exfiltration indicators

Automated Response

Configure automated responses to security events:

# Example automated response configuration
incident_response = {
    "brute_force_detected": {
        "actions": [
            "lock_user_account",
            "require_password_reset",
            "notify_security_team",
            "trigger_investigation"
        ],
        "threshold": {
            "failed_attempts": 5,
            "time_window": 300  # 5 minutes
        }
    },

    "impossible_travel": {
        "actions": [
            "challenge_with_mfa",
            "limit_access_scope",
            "alert_user",
            "log_detailed_session"
        ],
        "detection": {
            "distance_km": 500,
            "time_hours": 2
        }
    },

    "data_exfiltration_attempt": {
        "actions": [
            "block_transfer",
            "quarantine_user",
            "immediate_security_review",
            "preserve_forensic_data"
        ],
        "indicators": [
            "large_download",
            "unusual_hours",
            "unapproved_destination"
        ]
    }
}

Best Practices

1. Start with Visibility

Before enforcing policies:

  • Monitor existing access patterns
  • Identify legitimate use cases
  • Understand business workflows

2. Implement Gradually

Roll out in phases:

  1. Week 1-2: Deploy connectors, visibility only
  2. Week 3-4: Enable monitoring and alerting
  3. Week 5-6: Enforce policies for non-critical apps
  4. Week 7-8: Full enforcement for all applications

3. User Education

Zero trust requires user buy-in:

  • Explain the "why" behind changes
  • Provide clear documentation
  • Offer training sessions
  • Establish support channels

4. Continuous Improvement

Zero trust is not set-and-forget:

  • Review policies quarterly
  • Adjust based on new threats
  • Update device requirements
  • Refine access patterns

Measuring Success

Track these key metrics:

Security Metrics:

  • Reduction in security incidents
  • Mean time to detect (MTTD)
  • Mean time to respond (MTTR)
  • Percentage of policy violations

Operational Metrics:

  • User satisfaction scores
  • Support ticket volume
  • Time to provision access
  • False positive rate

Business Metrics:

  • Compliance audit results
  • Insurance premium changes
  • Cost of security operations
  • Business enablement velocity

Common Challenges and Solutions

Challenge 1: Legacy Applications

Problem: Old applications don't support modern authentication.

Solution:

  • Use OneDot SASE's application connector
  • Implement step-up authentication
  • Plan for application modernization

Challenge 2: User Friction

Problem: Too many authentication prompts frustrate users.

Solution:

  • Implement adaptive authentication
  • Use device certificates for trusted devices
  • Enable SSO across applications
  • Set appropriate session timeouts

Challenge 3: Performance Concerns

Problem: Security checks add latency.

Solution:

  • Deploy SASE points of presence near users
  • Use intelligent caching
  • Optimize policy evaluation
  • Monitor and tune performance

Conclusion

Building a zero-trust network with OneDot SASE is a journey, not a destination. By following this guide, you can systematically implement zero-trust principles while minimizing disruption to your organization.

The key is to:

  • Start with clear objectives
  • Implement incrementally
  • Monitor continuously
  • Adjust based on learnings

With OneDot SASE, you have a powerful platform that makes zero trust achievable for organizations of any size.


Need help planning your zero-trust implementation? Contact our security experts for a free consultation.

Share this article

Back to Blog