|
The short answer: CloudConnexa delivers all three Security Service Edge pillars from a single Wide-area Private Cloud (WPC): Zero Trust access through identity-aware Applications and Access Groups, internet security through the built-in Cyber Shield (DNS-based filtering plus IDS/IPS), and SaaS protection through fixed egress IP allowlisting. Teams that need full HTTPS decryption or deep packet inspection can route through a third-party stack via CloudConnexa's Internet Gateway. |
Security Service Edge (SSE) asks a platform to do three things well: secure access to private applications, secure access to the internet, and secure access to cloud/SaaS services. Security Service Edge (SSE) CloudConnexa addresses all three through its Wide-area Private Cloud (WPC) — a virtual private overlay network that behaves like a distributed cloud router and next-generation firewall. Here's how it maps to each SSE requirement.
1. ZTNA: CloudConnexa as an identity-aware proxy
The heart of SSE is Zero Trust Network Access (ZTNA), and this is where CloudConnexa is strongest. Instead of dropping users onto a flat network the way a legacy VPN does, CloudConnexa brokers access to individual destinations defined as Applications.
Applications and domain-based routing
In CloudConnexa, a private service or sanctioned SaaS app is defined as an Application identified by its domain name. CloudConnexa uses Application Domain-based Routing, which routes by domain and cloaks the underlying server IP addresses so they are never disclosed to the client. The result is true per-application micro-segmentation — the user can reach the one app they're authorized for and has no visibility into anything else on the network.
Access Groups map identity to applications
Access is governed by Access Groups, which connect:
- Sources (Who?) — User Groups, Hosts, and Networks. Identity attributes from your SAML or LDAP provider map each user into a Primary User Group (and up to 20 secondary groups).
- Destinations (What?) — the specific Applications or IP Services that source is permitted to reach.
When you set the WPC topology to Custom, enforcement becomes deny-by-default: nothing is reachable unless an Access Group explicitly allows it. Combined with identity, device posture, and location context, this delivers the least-privilege, continuously-evaluated access model described in NIST SP 800-207. Notably, CloudConnexa proxies any TCP/UDP application — not just web/HTTP apps — so client-server tools are covered too.
Legacy VPN vs. CloudConnexa ZTNA: A VPN grants broad network access after one login. CloudConnexa grants access to one Application at a time, hides every other resource, and re-checks identity and context — closing the lateral-movement risk that makes flat VPN access dangerous.
2. Internet security: Cyber Shield and full-tunnel DPI routing
SSE also requires safe internet access. CloudConnexa includes Cyber Shield at no extra cost, with two layers:
- Domain Filtering (content filtering): DNS-based filtering that blocks malicious and suspicious websites and classifies web content into dozens of categories. Preset protection levels (Monitor Only, Basic Protection, Safe Browsing, High Productivity) plus custom allow/block lists make policy easy to tune.
- Traffic Filtering (IDS/IPS): Built-in intrusion detection and prevention that classifies threats by priority (Critical, High, Medium) across categories like malware, phishing, and exploits — passively alerting as an IDS or actively dropping malicious packets as an IPS.
CASB-style visibility from DNS logs
The SSE stack also calls for CASB-style insight into cloud and SaaS usage. Because Domain Filtering resolves DNS for traffic across the WPC, CloudConnexa's DNS logs reveal which SaaS and cloud applications your users are actually reaching — by domain. That gives administrators practical visibility for shadow IT detection: spotting unsanctioned apps, understanding adoption, and deciding what to block, allow, or bring under formal Access Group control. It's a lightweight, agentless way to answer “what cloud apps are in use here?”
One important boundary: Cyber Shield's IDS/IPS inspects traffic metadata and packet patterns, but it does not perform deep packet inspection (DPI). It does not decrypt encrypted HTTPS sessions to examine the unencrypted payload inside. That's a deliberate, privacy-respecting design — and the reason the option below exists for teams that need full payload inspection.
Need DPI-level inspection? Route to a third-party stack
For organizations that require deep packet inspection — including HTTPS decryption and payload analysis — CloudConnexa supports full-tunnel mode (Split Tunnel OFF). All internet traffic can be routed out through a network configured as an Internet Gateway, and that gateway can sit in front of a third-party DPI or NGFW appliance that handles TLS inspection and payload analysis. This lets you centralize advanced inspection wherever your security stack lives while CloudConnexa handles secure transport and identity.
3. SaaS protection: turn cloud apps into private resources
The third SSE job is protecting SaaS. CloudConnexa's approach is elegant: define the SaaS app's domain as an Application that egresses through a network you control (for example, your cloud VPC). Traffic then leaves with that network's fixed public source IP.
You then allowlist that egress IP in the SaaS provider's security settings so only logins from your IP are accepted. See the step-by-step SaaS allowlisting tutorial for the configuration. The payoff is significant:
- Stolen credentials become useless from the outside. Even if an attacker has a valid username, password, and bypasses 2FA, their login is rejected because it doesn't originate from your allowlisted IP.
- SaaS behaves like a private app. Public cloud services effectively become private resources, governed by the same identity-based Access Groups as your internal apps.
Frequently asked questions
Is CloudConnexa a full SSE platform?
CloudConnexa provides built-in SSE and ZTNA essentials and is an excellent foundation for an SSE strategy — strongest on ZTNA, with included internet security via Cyber Shield and a practical SaaS protection model. Cyber Shield's IDS/IPS does not perform DPI or decrypt HTTPS; for payload-level inspection it pairs cleanly with a third-party DPI stack via full-tunnel routing.
Does CloudConnexa replace my VPN?
Yes — it replaces broad VPN access with identity-aware, least-privilege access to specific Applications, while remaining easy to deploy.
How does egress IP allowlisting stop 2FA bypass?
Because the SaaS provider only accepts logins from your fixed egress IP, an attacker who has stolen credentials and defeated 2FA still can't authenticate from their own network.
Does CloudConnexa provide CASB-style visibility into SaaS usage?
Yes, in a lightweight way. CloudConnexa's DNS logs show which SaaS and cloud apps users reach by domain — agentless visibility that supports shadow IT detection and helps you decide what to block, allow, or bring under Access Group control.
Does CloudConnexa integrate with identity providers like Okta or Microsoft Entra ID?
Yes. Access Groups map users into groups using identity attributes from your SAML or LDAP provider, so an existing Okta, Entra ID, or other IdP deployment plugs into the same least-privilege model described above. See “CloudConnexa vs. Microsoft Entra” for a side-by-side look at identity-centric SSE approaches.
What's the difference between Cyber Shield and a full DPI/NGFW stack?
Cyber Shield inspects traffic metadata and DNS/packet patterns — it doesn't decrypt HTTPS or examine payload contents. For organizations that require that level of inspection, CloudConnexa's Internet Gateway can route full-tunnel traffic to a third-party DPI or NGFW appliance instead.
Can CloudConnexa secure non-web applications, not just SaaS or HTTP traffic?
Yes. CloudConnexa proxies any TCP/UDP application, not just web-based ones — so internal client-server tools, databases, and other non-HTTP services get the same identity-aware, per-Application access control as SaaS apps.
See it in your environment: Start a free CloudConnexa trial and build your first identity-aware Application policy in minutes.
Related posts
- What Is Security Service Edge (SSE)? A Beginner's Guide
- How Does ZTNA Work? Zero Trust Explained for Business Security
- SASE vs. ZTNA: What You Need to Know
- What Are the Top SASE Use Cases?
- CloudConnexa vs. Microsoft Entra: ZTNA & SSE Comparison
- Announcing Device Posture
- Announcing Location Context Policy
Sources: OpenVPN CloudConnexa documentation (Applications, Access Groups, Cyber Shield, Internet Gateway, SaaS whitelisting tutorials); NIST SP 800-207 Zero Trust Architecture. Note: Cyber Shield IDS/IPS provides signature/pattern-based detection and prevention and does not perform deep packet inspection or HTTPS decryption.