Claims Data: Persona Access, Region Filters, and Cross-Account Sharing
Account A owns a 3-year Parquet claims dataset in S3, registered in Lake Formation. Account B has 40 analysts in three personas. Claims adjusters must see only rows for their assigned region (7 regions, column region). The fraud team must see all rows but member_ssn and dob must be visible only to 5 named users. Auditors need read-only access to all columns, retained for 7 years. Account B queries with Athena and Redshift Spectrum, and a nightly Glue job in Account B writes aggregated tables to B's own bucket. After an engineer granted SELECT on the claims table to an analyst IAM role, analysts saw SSNs for every region. A later attempt to attach one Lake Formation data filter to the table caused the fraud team to lose access entirely.
1. Diagnose how the SELECT grant produced unrestricted PII access, and describe the access model you would build.
Read the worked answer
Check three things before changing anything, because the symptom fits several causes. First, confirm the table is not registered with IAM-only access control; if it is, Lake Formation grants are decorative and anyone holding s3:GetObject on the prefix reads everything. Second, check whether the grant was made at database level or with a column list that includes the PII columns, because Lake Formation grants are purely additive; there is no deny. A database-wide grant is not narrowed by a later table-level column restriction for the same principal. Third, check CloudTrail for direct GetObject calls from an analyst execution role, which means a second path around the catalog.
Target model:
- Three principal sets: persona_adjuster_ (7 groups), persona_fraud, persona_auditor, with users placed only in groups.
- Grant on the table, never on the database, with explicit column lists plus a data filter.
- Fraud gets SELECT on non-PII columns with an unfiltered row grant; the 5 named users are in a separate group granted the PII columns.
- Auditors get column-complete read-only grants and no write or alter permissions.
- Restrict the S3 bucket policy so only the Lake Formation service role can read the prefix, closing the bypass permanently.
2. Design the region restriction, and explain why attaching one data filter broke the fraud team.
Read the worked answer
A principal can only receive one data filter per table per grant, and separate grants to the same principal are unioned, not intersected. If fraud lost access when you attached a filter, the likely cause is that fraud's access was riding on the same table-level grant you just modified, or the resource link in Account B was not re-granted after the change.
Design:
- Create one named data filter per region with expression region = '' and grant it to the matching adjuster group together with the non-PII column list.
- Where a user legitimately covers multiple regions, use a single filter with region IN ('north','south') rather than two grants, because filters do not combine across grants.
- Give fraud a separate table grant: same columns as today, no row filter, and its own principal so future changes cannot silently affect it.
- Verify with GetEffectivePermissionsForPath for each role and test with one query per persona per engine, since Athena and Redshift Spectrum enforce through different paths.
Validate the resource link grants in Account B explicitly: permissions granted on the shared table in A do not automatically apply to the link object.
3. How do you make the cross-account path work end to end, including the nightly Glue job, without creating a PII leak into Account B?
Read the worked answer
Sharing over Lake Formation is a chain, and every link must be in place: grant in Account A to Account B's principals or to the organization, create a resource link in B, then grant on the link to B's roles. The Glue job's execution role must be the granted principal, not a role that happens to be able to read the bucket.
Encryption is the usual failure point. If the data is SSE-KMS with a customer managed key in A, the key policy must allow B's job role to decrypt, and the bucket policy must allow the cross-account access. Missing key permissions produce AccessDenied that looks like a catalog problem but is not.
Leak prevention: the nightly job must write only aggregates to B's bucket. Never allow a raw extract, and never cache the shared table into a B-owned staging prefix, because that silently re-implements the access controls you just built and breaks the auditor retention story. Put an SCP or bucket policy on the B write prefix that rejects writes from any role with a path to the raw share.
For the 7-year audit requirement, keep Lake Formation audit logging to CloudTrail enabled and centralize the trail in a dedicated log-archive account so B cannot alter its own access record.