Securing Apps in the Open-By-Default Cloud

## Overview

Winston House (application security, Snapchat) and Michael Wozniak (infrastructure security, Snapchat) presented architectural challenges and solutions for securing cloud-native applications deployed on AWS/GCP when cloud platforms default to internet-routable services. Problem statement: cloud vendors (AWS, GCP, Azure) prioritize rapid deployment—new projects/services come up routable on the public internet by default (both ingress and egress). App Engine specifically is open by default with limited built-in firewall controls. Snapchat runs primarily on cloud infrastructure across disjoint networks, multiple VPCs, and accounts—no single internal corporate network behind NAT. Snapchat experimented with several security approaches: billing control (condition cloud resource access on security review—failed due to required billing for many features); auth library enforcement (request developers implement standard auth—failed due to misimplementation and high audit burden); network firewalls (gate access to corporate network—failed due to granularity/visibility issues); Google Identity-Aware Proxy (OAuth-based access control—failed due to manual OAuth client creation bottleneck). Each approach fell short of providing both scalability and granular access control across diverse technology stack. Snapchat redesigned access control around two core requirements: (1) security team must gate access before developers code (project creation, not deployment); (2) minimal developer instrumentation burden.

## Cloud-Native Security Architecture and Firewall Automation

**Network Segregation and Inventory Management**: Snapchat's cloud architecture emphasizes IAM isolation rather than network-based segregation. This results in numerous disjoint VPCs and cloud projects, requiring internet transit for cross-service communication (internal traffic goes over public internet). Traditional network-centric security fails: firewalling to corporate network lacks granularity (any employee reaches any service); service-to-service communication invisible to IP-based filtering. Solution architecture requires two capabilities: (1) centralized inventory of all cloud infrastructure (projects, services, compute instances, App Engine deployments, databases, etc.); (2) centralized service enabling cloud billing while granting security team network management and visibility access. Firewall manager component continuously imports infrastructure inventory changes, automatically triggering firewall rule updates. This automation is critical for scalability—new projects are gated to firewall rules within seconds of creation, before developers gain production access. Base-level firewall rules establish default deny-all posture, requiring explicit approval for any network communication.

**Stateless Authentication and Access Control Granularity**: Authentication/authorization implemented via stateless authentication proxy deployed in front of all cloud services. Proxy intercepts requests, validates user identity (via Snapchat identity provider), enforces access-control decisions (which users/services can access which endpoints). Stateless design avoids need to instrument individual applications—security controls exist at network edge, decoupled from application code. Enables granular access policies: "this user set can access these services," "service A can communicate with service B," all defined centrally. Decoupling also accommodates Snapchat's diverse technology stack (multiple languages, frameworks, deployment models) without forcing standardization. Authentication happens transparently; developers neither implement nor explicitly configure auth—proxy handles it.

## Managed vs. Unmanaged Services and Development Lifecycle Transformation

**Unmanaged Services**: Lower-scale deployments including proof-of-concepts, experimental services, internal-only tools. These receive immediate billing enablement but require authentication/authorization controls before internet exposure. Two sub-categories treated identically from security perspective: (1) development/POCs—low risk, short-lived, never reaching public endpoints; (2) internal tools—employee-only access, scale appropriate for authentication controls. Both require firewall gating and auth proxy in front but don't require full security review due to limited exposure surface.

**Managed Services and Pre-Launch Security Review**: Production services intended for scale and public exposure require security review before launch (or before opening internet access). Development lifecycle previously exposed apps to internet during entire development lifecycle (project creation through post-launch iteration)—security team could only guarantee security during narrow window. New model: apps created in unmanaged state (firewalled, authenticated, gated); developers work on unmanaged services; before moving to managed/production status, security team conducts review, validates architectural decisions, ensures defense-in-depth. This shifts security involvement from reactive post-deployment to proactive pre-launch stage. Managed state maintains firewall + auth proxy requirements with higher standards.

**Flexibility and Developer Experience**: Solution designed to minimize developer overhead—no requirement to instrument services with custom auth libraries, no need to manage OAuth credentials manually, no need to understand firewall mechanics. Developers create project; system automatically gates it. They build and test; system provides transparent authentication. When ready for production, security review validates but doesn't require code changes or architectural rework. Approach trades off immediate deployment speed (projects no longer instantly routable) for security assurance (projects never exposed without controls). Alternative approaches (billing delay, library requirements, granular firewall policies) created exceptions and operational overhead; automatic gating requires no exceptions, scales with organization size.