AWS Data Platform Security Architect

AWS Data Platform Security Architect

About the role

The client needs the access model that would let a Databricks workspace profile data across their AWS accounts — from a governance standpoint, not a business one. A scanning identity with broad read access across a regulated estate attracts real scrutiny, and security approval lead times can exceed the length of this engagement. You exist to get that answer early, and in a form the client’s information security function will accept.

You also own the single question that most shapes the recommendation: how much of the in-scope S3 estate is registered in the AWS Glue Data Catalog. Collibra’s S3 profiling depends on it, so that number largely decides the target-state option. Nobody currently knows it.

What you will do

1. Establish AWS Glue Data Catalog coverage across the in-scope accounts and buckets, and quantify the gap. This is the first deliverable and it gates the option recommendation.
2. Document how the incumbent product authenticates and reaches data today — cross-account roles, network paths, endpoints — as the baseline for any replacement.
3. Design the least-privilege cross-account access model for a Databricks-based scanning workload: IAM roles and trust policies, S3 bucket policies, and cross-account KMS key policies.
4. Design network access — VPC endpoints, PrivateLink, and serverless networking configuration as applicable.
5. Produce security-review-ready documentation: data flows, trust boundaries, identities, permission scopes, data classification per flow, and compensating controls. Assume a formal threat model is required.
6. Secure the information security review slot in week 1 rather than week 9, and steer the design through to approval.
7. Identify a pre-approved non-production account and dataset in which the prototype can legitimately run.
8. Author the security and governance model deliverable, and the operating model for running the scanning workload in production.

What you need

• 7+ years in cloud or data platform security architecture, with deep AWS.
• Cross-account IAM design role and trust policy authoring, permission boundaries, condition keys, and least-privilege scoping for a deliberately broad-read workload.
• S3 security at depth — bucket policies, access points, and how they interact with cross-account roles.
• Cross-account KMS key policies and grants. This is the most commonly missed failure point in cross-account scanning and will be probed at interview.
• AWS Glue Data Catalog and crawlers — what gets registered, what does not, classifier behavior, and Lake Formation permissions where in play.
• VPC endpoints, PrivateLink and private networking for managed data services.
• Databricks on AWS security, or a directly comparable managed-service security model.
• A track record of security designs that passed formal enterprise security or architecture review in a regulated organization — and the ability to describe how objections were closed.

Nice to have

• Threat modelling — STRIDE, data flow diagrams, or an equivalent structured method.
• Financial services or other regulated-sector security review experience.
• AWS Security Specialty or equivalent certification.
• Multi-account governance at scale — Control Tower, service control policies, hub-and-spoke topologies.
• Experience securing data discovery or DSPM-style scanning workloads.

This role is not

A general AWS landing-zone architect post — scope is the scanning access model and getting it approved. Not a security operations or incident response function. And not the approver: this role prepares and defends the design; the client approves it.