LEARN. PRACTICE. GROW.1. Describe the request that failed
Before editing policies, record identity, action, resource, network path, and the service returning the denial. In funds processing, GetObject can be authorized while the decryption step remains denied. Under FAS, the downstream service also evaluates the original principal permissions. Draw the chain to make both authorizations visible. Do not use one successful call as proof of every required call. The technical manager should request a testable hypothesis, the scope of the proposed change, and evidence that the legitimate flow recovered. A broader Allow does not fix an applicable explicit denial and can add exposure elsewhere without resolving the incident.
2. Distinguish direct and delegated requests
A VPC endpoint call has network context that is not carried in the same way into subsequent FAS. If policy requires SourceVpce at every step, a legitimate integration can fail. ViaAWSService identifies FAS; PrincipalIsAWSService distinguishes a direct service principal and does not mean the same thing. To restrict intermediaries, CalledVia permits chain-membership checks. When position matters, First and Last constrain endpoints; testing membership does not enforce order. In the exercise below, synthetic records are classified as perimeter-exception candidates or review candidates. The result is not IAM authorization: actions, resources, policies, and conditions evaluated by a real engine are absent.
3. Use identifiers for the intended scope
Two VPCs can use the same private CIDR. An isolated VpcSourceIp filter does not distinguish them; pair it with a supported VPC or endpoint identity. On an endpoint path, SourceIp does not substitute for VpcSourceIp. Also confirm identifier type: SourceVpce expects an endpoint ID, not a VPC ID or bucket ARN. In an S3-to-SNS integration, SourceArn identifies the bucket triggering the notification, not the operator role that configured the event. These distinctions help diagnose conditions that look correct because they contain a valid identifier but compare different properties. Keep a context sample in the change record without credentials or sensitive values.
4. Review every access interface
Endpoint policy is an additional layer and does not replace IAM or resource policies. Its default permits endpoint access; that does not mean universal data authorization. For gateway endpoints, Principal must be *, with identity constrained through PrincipalArn where needed. An S3 access point also needs authorization at the underlying bucket. Access-point restrictions apply to requests using it and do not automatically revoke existing direct access. In a segregation project, inventory old and new paths. A negative test on the new interface is insufficient when the role can still read through the bucket. Acceptance should track the access requirement, not merely interface installation.
5. Align clients and secret policies
A legacy client can send an ACL incompatible with Bucket owner enforced. AccessControlListNotSupported calls for reviewing the request and authorization model; adding PutObjectAcl does not change configuration support. To read a secret across accounts, coordinate identity policy, resource policy, and the KMS key. The AWS managed aws/secretsmanager key does not serve that cross-account access; the design needs an authorized customer managed key. BlockPublicPolicy helps control the secret resource policy but does not alone establish all effective access. Keep an inventory of associated policies, their owners, and testing evidence. That prevents one team closing its part while assuming another team dependency.
6. Accept the perimeter through representative tests
Prepare legitimate-access cases and cases that must be denied. Include the direct path, delegated chain, contingency origin, and relevant legacy interfaces. During daily close, an urgent correction needs clear scope, approval, and rollback conditions. Assign a rollback owner and repeat the prohibited-access test after reversal to detect segregation regressions. The FAS exception should represent the necessary integration without turning every service-mediated call into broad authorization. Hand RUN the evidence location, each policy owner, and symptoms warranting escalation. Summarize the decision in observable terms: which request passed, which was denied, under what identity, and with which policy version. The goal is to preserve the requirement during recovery and demonstrate it after the window.
# Original synthetic context classifier, not IAM policy evaluation.
# No credentials, network calls, or AWS changes.
def classify(row):
if row.get("source_endpoint") == "vpce-approved":
return "direct-candidate"
if row.get("fas") and "s3.amazonaws.com" in row.get("via", []):
return "delegated-candidate"
return "review-path"
assert classify({"source_endpoint": "vpce-approved"}) == "direct-candidate"
assert classify({"source_endpoint": "vpce-other"}) == "review-path"
assert classify({"fas": True, "via": ["s3.amazonaws.com"]}) == "delegated-candidate"
assert classify({"fas": True, "via": ["other.example"]}) == "review-path"
assert classify({"service_principal": True}) == "review-path"
assert classify({}) == "review-path"
print("six request-context cases passed; candidates are not authorized requests")
A direct test passes, but FAS fails because SourceVpce is absent; the team corrects the delegated-path condition and also tests prohibited requests.
Common pitfalls
Connectivity as permission; service principal as FAS; CIDR as unique identity; new interface as revocation of old access.
Related topics: Federation and KMS authorization · Infrastructure paths and governance
Access diagnosis must reconstruct the request and every layer authorizing or denying it.
Reference: Forward access sessions · SCS-C03