Inviter Threat: Managing Security in a new Cloud Deployment Model

Inviter Threat: Managing Security in a New Cloud Deployment Model

Speakers: Meg Ashby

Conference: fwd:cloudsec North America 2025

YouTube: https://www.youtube.com/watch?v=ilnOvSV0QtY

Overview

Meg Ashby, from the late-stage fintech compliance startup Alloy based in New York City, returned to fwd:cloudsec for her second year to present on the security challenges of Bring Your Own Cloud (BYOC), an increasingly popular deployment model where the customer provides the cloud environment and the service provider manages resources within it. The talk walked through a structured framework for evaluating whether BYOC is appropriate for your organization, the real-world deployment pitfalls Alloy encountered, and the mitigating controls -- from SCPs and RCPs to private link integrations -- that make the model workable. This is a practical governance talk for organizations facing the decision of whether to adopt BYOC and, if so, how to do it without sacrificing security posture.

Background

▶ Watch: Existing cloud deployment models and where BYOC fits (1:30)

Cloud deployment models have traditionally fallen on a spectrum: DIY (vendor provides instructions, you build everything), assisted (vendor provides modules or helper tools), and API-based SaaS (vendor hosts everything, you just connect). BYOC occupies a new position where the client provides the cloud environment -- typically an AWS account -- and the service provider takes over management and maintenance of resources within it. The model has gained traction among early-stage companies as a competitive differentiator, particularly for use cases where data locality requirements or low-latency processing make it impractical for data to leave the customer's environment. Common BYOC product categories include database and data warehousing solutions, data streaming and replication services, and data operations platforms (ML, data classification).

The fundamental tension in BYOC is that the service provider needs significant permissions -- often including high-privilege IAM identities and network connectivity for database management -- within an environment the customer is responsible for securing. This creates a novel trust boundary that existing security patterns do not naturally accommodate.

Key Findings

▶ Watch: Need-to-haves vs want-to-haves: evaluating BYOC against compliance requirements (6:30)

Ashby presented a structured evaluation framework built around three layers of assessment:

Layer 1: Need-to-Haves vs. Want-to-Haves. The foundational question is whether the service provider's requirements conflict with your organization's non-negotiable security controls -- the controls you attest to in client contracts, regulatory commitments, audit programs, and published security policies. Ashby distinguished between these true requirements and the organization's chosen implementations of those requirements. One concrete example: Alloy's requirement that no persons or processes have static permanent access to decrypted client PII in production. A service provider whose BYOC model would grant their employees static access to data the service could access was incompatible. A different service provider handling only internal metadata with the same static access model was acceptable.

Layer 2: Organizational Peculiarities. Every organization has idiosyncratic deployment patterns, tooling assumptions, and architectural decisions that can conflict with BYOC's standardized deployment model. Alloy encountered several:

• AWS Config remediation loops: Config rules with auto-remediation would endlessly "fix" resources deployed by the service provider
• Remote state lookups in Terraform: Infrastructure modules assumed all VPCs were internally created, causing errors when deploying into vendor-managed VPCs
• EKS cluster access tooling: Their break-glass access product required managing the cluster, which was incompatible with vendor-managed EKS, forcing a fallback to EC2-based hosting
• Zero trust/RCP conflicts: Had they already implemented RCPs requiring VPC endpoint connections, these would have blocked the service provider's access patterns

Layer 3: Deployment Strategy. Ashby evaluated three options:

1. Initial-only deployment (vendor deploys, you maintain): Recommended against as a lose-lose -- you still encounter BYOC conflicts but also take on ongoing maintenance
2. VPC within existing account: Problematic because high-privilege IAM identities cannot be fully scoped to a VPC, and networking components may not align with risk tolerance
3. Dedicated AWS account (what Alloy chose): Leverages default account-level permission boundaries, billing isolation, and CSPM segregation, though it cannot remain fully isolated since the vendor's product needs access to the customer's data

Technical Deep Dive

▶ Watch: Zero trust architecture conflicts with BYOC -- a near miss (13:30)

For the dedicated account deployment strategy, Ashby detailed specific mitigating controls:

Network controls. Rather than allowing the service provider to allowlist their egress IPs or use SSH tunnels, Alloy pursued AWS PrivateLink integrations and resource-based endpoints restricted to specific accounts and resources. This aligns with zero trust principles by eliminating public internet paths. She noted mixed willingness from service providers to support these advanced integration options.

Service Control Policies. In BYOC accounts, SCPs are most effective when used to restrict access at the service level rather than attempting to carve out individual permission sets. The critical requirement is that the service provider must use an identity within the customer's owned AWS account -- not their external identity -- for SCPs to apply.

Resource Control Policies. RCPs can enforce configuration standards on supported services. Specific recommended RCPs include blocking the aws:SourceAccount condition from being outside both the customer's and vendor's attested AWS accounts (to prevent confused deputy attacks) and restricting STS from adding external OIDC providers.

Logging and monitoring. Organization-managed CloudTrail must be maintained within BYOC accounts, and organizations should maintain a runbook for cutting off service provider access during incident response.

The OU placement question for BYOC accounts remains open. Ashby referenced the AWS environment white paper's OU structure but noted there is no single correct placement.

Demo / Proof of Concept

▶ Watch: Three deployment strategies: initial-only, VPC in existing account, dedicated... (15:30)

No live demo was performed. The talk was based on Alloy's production experience implementing BYOC with multiple service providers.

Defensive Implications

▶ Watch: Closing: leaving with more questions than answers is expected (20:30)

Organizations evaluating BYOC should begin by documenting their actual compliance requirements (not their implementation choices) and testing whether the service provider's model conflicts with those requirements. Before adopting BYOC, defenders should audit their existing infrastructure-as-code for assumptions about resource ownership -- remote state lookups, CSPM remediation actions, and access tooling dependencies are likely failure points. Feature flags that can toggle deployment configurations (e.g., monitoring-only vs. monitoring-plus-remediation for Config rules) should be built proactively.

For organizations that proceed with BYOC, the dedicated AWS account approach with PrivateLink networking, service-level SCPs, targeted RCPs, and organization-managed CloudTrail provides the strongest control surface. Maintaining an incident response runbook for revoking service provider access is essential.

Key Takeaways

• Bring Your Own Cloud is an increasingly common deployment model, especially among early-stage companies, where the customer provides the cloud environment and the vendor manages resources within it
• Evaluate BYOC by starting with your non-negotiable compliance requirements -- if the vendor's model conflicts, stop there
• Audit your infrastructure-as-code for hidden assumptions (remote state lookups, auto-remediation, access tooling dependencies) that will break under BYOC
• A dedicated AWS account per BYOC vendor is the recommended deployment strategy, though it cannot remain fully isolated
• Use PrivateLink instead of IP allowlisting or SSH tunnels for vendor network access; apply service-level SCPs and targeted RCPs (confused deputy protection, OIDC restriction)
• Maintain organization-managed CloudTrail and an incident response runbook for cutting off vendor access

About the Speaker(s)

Meg Ashby works at Alloy, a late-stage fintech compliance technology startup based in New York City. She is an AWS-only specialist and a returning speaker at fwd:cloudsec, having presented the previous year as well. Her experience is rooted in managing cloud security in a regulated financial technology environment.