Configure AWS Verified Access to provide VPN-less zero trust network access to internal applications using identity and device posture verification with Cedar policy language.
Standardmäßig ist der Prompt ausgewählt, der zuerst die Quelle prüft. Sie können zu einem direkten Befehl wechseln oder eine lokale Kopie herunterladen.
Quelldateien prüfen
Lesen Sie SKILL.md und alle von SkillsMP angezeigten Begleitdateien, bevor Sie sich für eine Installation entscheiden.
Mit Codex oder Claude installieren Kopieren Sie diesen Prompt, fügen Sie ihn in Codex, Claude oder einen anderen Assistant ein und lassen Sie die Skill-Seite prüfen und installieren.
Ein direkter Befehl überspringt den Prüf-Prompt. Prüfen Sie die Quelle, bevor Sie ihn ausführen.
Configure AWS Verified Access to provide VPN-less zero trust network access to internal applications using identity and device posture verification with Cedar policy language.
AWS Verified Access is a Zero Trust Network Access (ZTNA) service that provides secure, VPN-less access to corporate applications hosted in AWS. It evaluates each access request in real-time against granular conditional access policies written in the Cedar policy language, ensuring access is granted per-application only when specific security requirements such as user identity and device security posture are met and maintained. Verified Access integrates with AWS IAM Identity Center, third-party identity providers (Okta, CrowdStrike, JumpCloud, Jamf), and device management solutions. For multi-account deployments, AWS Resource Access Manager (RAM) enables sharing Verified Access groups across organizational units.
When to Use
When deploying or configuring configuring aws verified access for ztna capabilities in your environment
When establishing security controls aligned to compliance requirements
When building or improving security architecture for this domain
When conducting security assessments that require this implementation
Common Misconfigurations & Verification
Origin still reachable directly: the internal ALB/ENI keeps its own security group and private DNS. If the ALB SG allows 0.0.0.0/0 or a broad VPC range on 443, users skip the Verified Access endpoint entirely. Lock the ALB security group to ONLY the Verified Access security group, never to the world.
Policy permits without a device signal: a Cedar policy like permit(principal, action, resource) when { context.okta.groups.contains("employees") }; verifies identity but ignores context.crowdstrike.assessment.overall, so an unmanaged laptop passes. Always AND a device-trust clause into group- and endpoint-level policies.
Device trust provider attached but never referenced: attaching a CrowdStrike/Jamf provider does nothing unless its policy_reference_name appears as a context.<ref> namespace in the Cedar policy. Confirm it is actually evaluated.
Logging disabled: with no CloudWatch/S3 access logs you cannot prove enforcement. Enable aws_verifiedaccess_instance_logging_configuration before go-live.
Verify: from an off-corp host, resolve and curl -k https://<alb-dns> and the ENI private IP directly; both must refuse/time out, and only the *.edge.vpce-...amazonaws.com endpoint should answer. Then connect from a non-compliant device (stop the CrowdStrike sensor) and confirm a denial in the logs via --filter-pattern '{ $.status_code = "403" }'.
Prerequisites
AWS account with appropriate IAM permissions
Identity provider (AWS IAM Identity Center, Okta, or OIDC-compatible)
// Allow access for users in the engineering group with compliant devices
permit(principal, action, resource)
when {
context.okta.groups.contains("engineering") &&
context.crowdstrike.assessment.overall > 70 &&
context.crowdstrike.assessment.sensor_config.status == "active"
};
// Deny access from unmanaged devices
forbid(principal, action, resource)
when {
!context.crowdstrike.assessment.sensor_config.status == "active"
};
Advanced Policy Examples
// Time-based access - only during business hours (UTC)
permit(principal, action, resource)
when {
context.okta.groups.contains("contractors") &&
context.http_request.http_method == "GET" &&
context.crowdstrike.assessment.overall > 80
};
// Restrict admin access to specific user group with high device trust
permit(principal, action, resource)
when {
context.idc.groups.contains("admins") &&
context.crowdstrike.assessment.overall > 90 &&
context.crowdstrike.assessment.os_version.startswith("Windows 11") ||
context.crowdstrike.assessment.os_version.startswith("macOS 14")
};
// Allow read-only access for lower trust levels
permit(principal, action, resource)
when {
context.okta.groups.contains("read-only") &&
context.crowdstrike.assessment.overall > 30 &&
context.http_request.http_method == "GET"
};
Group-Level vs Endpoint-Level Policies
// Group-level policy (applies to all endpoints in the group)
// Set on the Verified Access Group
permit(principal, action, resource)
when {
context.okta.groups.contains("employees") &&
context.crowdstrike.assessment.overall > 50
};
// Endpoint-level policy (additional restrictions for specific app)
// Set on the Verified Access Endpoint
permit(principal, action, resource)
when {
context.okta.groups.contains("hr-team") &&
context.okta.email.endsWith("@company.com")
};
