Choosing and Integrating SDP for Production Admin Access
Helio SaaS runs a 300-engineer product organization across AWS and Azure and uses 40 contractors for release engineering. Production administration currently happens through a VPN concentrator into 10.0.0.0/8 with split tunneling; there is no device posture check, and contractors receive 90-day VPN accounts. Okta is the identity provider and Splunk is the SIEM. The company has 1,200 endpoints: macOS, Windows, and Linux. Engineers in APAC require interactive latency below 80 ms to production shell hosts. Contractors need just-in-time access to no more than six named hosts for four-hour windows, with session recording. Break-glass access must remain possible if Okta is unavailable. The CISO wants to retire VPN for admin access within one quarter but keep the change reversible. A vendor proposes a clientless SDP only; the alternative is a client-based controller with gateways deployable in cloud regions.
1. Which SDP deployment model should Helio choose: clientless only, client-based only, or a hybrid? Where should gateways be placed?
Read the worked answer
Choose a hybrid, but make client-based the default for engineers and clientless a narrow exception. Clientless SDP is attractive for contractors and break-glass because it avoids installing software, but it cannot reliably attest device posture, which is central to replacing VPN for production admin. Engineers already have managed macOS, Windows, and Linux endpoints; a lightweight client can provide device identity, posture, and a per-app tunnel.
Place gateways in the AWS and Azure regions where production shell hosts run, not in a central data center, to meet the APAC sub-80 ms interactive requirement. Use at least two gateways per region for availability, and keep the SDP controller SaaS-hosted or in a management VPC with no direct path to production. The controller makes authorization decisions; gateways only enforce. A clientless path should be limited to browser-based administrative consoles and emergency access, with stronger identity checks and session recording.
Reasoning: SDP separates the control plane from the data plane; the controller must not be reachable from the protected resources, and the gateway must be close to the resource to avoid latency. A clientless-only design would fail the device-posture requirement and push Helio back to VPN for shell access.
2. Design the authorization flow that combines Okta identity, device posture, and just-in-time approval.
Read the worked answer
Flow: (1) The user authenticates to Okta with phishing-resistant MFA; the SDP controller trusts Okta via OIDC or SAML and receives user, group, and authentication context. (2) The endpoint client collects device identity and posture signals from MDM/EDR, such as managed, disk encrypted, OS patched, EDR running, and certificate present; these are signed and sent to the controller. (3) For contractor or privileged access, the request includes the target host, duration, and ticket; an approval workflow grants a JIT entitlement for no more than four hours. (4) The policy engine evaluates identity, device, resource sensitivity, time, and approval against policy; the policy administrator instructs the gateway to create a short-lived per-session path. (5) The gateway presents a client certificate or mutual TLS and proxies only the approved host and port; session recording goes to Splunk. (6) Access expires automatically and is revoked if posture changes.
Reasoning: SDP is not just a hidden gateway; the decision must bind user, device, and resource. Short-lived entitlements reduce standing access, and per-session paths prevent lateral movement. Keep the controller out of the data path so a controller outage does not break established sessions, but design revocation to fail closed for new sessions.
3. How should Helio handle the 40 contractors and break-glass access if Okta is unavailable?
Read the worked answer
Contractors should not be in the same identity pool as employees. Create a contractor identity lifecycle with sponsor approval, expiration no longer than the engagement, and no standing VPN or SDP entitlements. Require managed devices or, if contractors use their own, route them through clientless browser isolation or a managed virtual desktop so posture is inherited. Each request should name the host, ticket, and window; approvals should be logged.
For break-glass, do not create a permanent bypass around the SDP. Use sealed emergency credentials held in a physical safe or offline vault, with hardware tokens, and a separate emergency gateway that is disabled by default. The emergency path should require two-person approval, alert the on-call security lead, and record the session. After use, rotate credentials and review the session within 24 hours. Reasoning: break-glass is an availability control, but it becomes the weakest link if it is always available. A separate path with strong custody and monitoring preserves recovery without recreating the VPN. For contractors, the main risk is unmanaged devices and long-lived accounts; JIT plus device inheritance addresses both. Test the break-glass path quarterly, because an untested emergency route is not a control.