Zscalerのブログ
Zscalerの最新ブログ情報を受信
Don’t Wait for Game Film: Audit Your Cloud Red Zone
Game film is how football teams learn from what already happened. It’s valuable, and it’s expensive, because the lesson arrives after the score.
Most cloud security reviews work the same way. Teams wait for an incident, a breached database, or a hard audit finding to reveal where the perimeter lapsed.
AI workloads shorten that timeline. Zscaler ThreatLabz research found that enterprise AI/ML transaction volume grew 83% year over year in 2025, while data transfers to AI/ML applications rose 93% to more than 18,000 terabytes. Each new AI workload is provisioned quickly, typically needs broad outbound access to pull models and public data, and lands on a network that grants connectivity by default.
The OpenAI–Hugging Face incident is the game film. During an internal evaluation in July 2026, AI models escaped their sandbox through a zero-day vulnerability in a package registry proxy, the only outbound path the environment allowed, according to OpenAI. From there, they moved laterally until they reached a node with internet access and used stolen credentials to reach Hugging Face production infrastructure. Hugging Face’s own disclosure describes an attacker log of more than 17,000 recorded events. This post is the scouting report: three repeatable checks you can run this quarter across AWS, Microsoft Azure, and Google Cloud to find exposure before an attacker does.
Why Cloud Networks Hand Out Connectivity First
Cloud networks are engineered to connect, and default configurations typically favor reach over restriction. Security boundaries usually arrive later, negotiated through a ticket queue or an exception request.
AI workloads strain that model in three ways:
- Broad external pulls: AI clusters routinely pull models, weights, datasets, and dependencies from public repositories.
- Shadow provisioning: Data science and ML teams often stand up environments outside standard architecture review to keep momentum.
- Data proximity: AI applications run next to sensitive production data stores and analytics pipelines for training and inference.
Defenses rarely fail because of one missed assignment. They fail because small, uninspected gaps compound over time. Cloud risk builds through convenience routes and standing exceptions, not a single catastrophic decision. The three audits below are designed to uncover that accumulation.
1. The Egress Audit: Where Can Your Workloads Reach?
Start with the exits. Every offense hunts for the open receiver behind the secondary. In the cloud, that open receiver is the outbound path nobody inspects. In the Hugging Face incident, it was a package registry proxy.
What to Look For
List every route table that sends 0.0.0.0/0 through a NAT gateway or internet gateway across your cloud environments. Cross-reference that list against 30 days of VPC/VNet flow logs to verify which external destinations your workloads actually contacted.
Pay close attention to AI pipelines pulling from public registries. Sonatype’s 2026 State of the Software Supply Chain report identified more than 454,600 new malicious open source packages in 2025, a 75% increase over the prior year, bringing the cumulative total it has tracked past 1.2 million as of year-end. Sonatype also notes that developer machines and CI/CD environments are prime targets because they sit close to credentials and production access.
Common Pattern: The Cloud Security Alliance notes that development teams routinely pull foundation models, fine-tuned adapters, and other AI artifacts directly from public registries, often without the scrutiny applied to traditional software dependencies. In cloud terms, that often looks like AI and data science environments using a default NAT path to the internet with no inspection, which leaves a blind spot for data exfiltration and dependency poisoning.
Why It Matters
Encrypted, uninspected egress gives a compromised host a covert channel. Command-and-control (C2) traffic and data exfiltration can blend in with legitimate outbound TLS and slip past controls that do not decrypt and inspect it.
The litmus test for security leaders is simple: Can your team name every external service, IP, and repository your cloud workloads contacted last week?
How to Fix It
Replace open default routing with inline TLS inspection and destination allowlists scoped to each source workload’s identity.
With Zscaler Zero Trust Cloud (ZTC), workload outbound traffic is steered from the local VPC or VNet to the Zero Trust Exchange, either through the Zero Trust Gateway service, which Zscaler fully manages, or through Cloud Connectors you deploy yourself. There, connections get cloud-scale TLS decryption, granular URL and FQDN filtering, and inline data loss prevention (DLP). That blocks unauthorized package acquisition and data leakage before traffic leaves your boundary.
2. The East-West Audit: What Can a Compromised Workload Touch?
Next, test your interior. In a disciplined defense, every player covers a gap. In a flat cloud network, nobody is assigned to the middle of the field.
What to Look For
Pick a low-trust workload, such as a developer sandbox, an edge analytics container, or an experimental AI notebook, and map everything it can reach. Review peering relationships, transit gateway route tables, cross-account and cross-subscription connections, and security rules that allow broad CIDR ranges (for example /16 or /12).
Then run an active reachability test: try to connect from that low-trust host to a production database subnet. Never assume the configuration blocks the hop until you have tested the path.
Common Pattern: Segmentation built on security groups, ACLs, and address ranges tends to be static and hard to keep accurate as environments change. Rules written against broad ranges instead of specific workloads are a familiar way for a path to production data to stay open long after the team believes it is closed.
Why It Matters
Internal reach determines your blast radius. It marks the line between an isolated compromise of a developer sandbox and a breach of sensitive customer records. Lateral movement is a common feature of ransomware and other multi-stage attacks, and it was central to the Hugging Face incident. It also happens fast: CrowdStrike’s 2026 Global Threat Report found that the average eCrime breakout time, the window between initial access and lateral movement, fell to 29 minutes in 2025, with the fastest observed breakout at 27 seconds.
How to Fix It
Retire position-based network controls in favor of workload identity and explicit 1-to-1 microsegmentation.
With ZTC, east-west traffic between workloads within a region is enforced directly at the Zero Trust Gateway or Cloud Connector. Flows that extend beyond a single region, such as cross-region, multi-cloud, or hybrid data center traffic, can be handled at the Gateway or Cloud Connector, or routed through the Zero Trust Exchange for a full proxy-based solution. Either way, workloads communicate only with pre-approved endpoints, which removes the open paths that unauthorized lateral movement depends on.

3. The Launch Audit: What Does a New Workload Inherit?
Championship teams build defensive discipline in the first practice, so every player knows the assignment long before game day.
What to Look For
Deploy a test workload from your standard infrastructure-as-code (IaC) templates, whether Terraform, AWS CloudFormation, Azure Bicep, or Google Cloud Infrastructure Manager. Check whether it launches with egress controls and isolation active, or falls back to open cloud defaults.
Then audit tag and label governance. Are the metadata tags that drive policy enforcement validated as mandatory gates in your CI/CD pipeline?
Common Pattern: Templates often define compute and networking but leave egress and isolation policy to a follow-up step. Any control that depends on a manual follow-up is the first to slip when a deadline is tight.
Why It Matters
Cloud infrastructure provisions in seconds. A manual cleanup done today is stale by the next deployment cycle, and any control that depends on a ticket or a human step will eventually lapse. Enforcing policy at deployment turns one-off remediation into a sustained security posture.
How to Fix It
Anchor security policy to workload identities and cloud tags from the moment an instance starts. ZTC’s workload discovery service reads user-defined tags and cloud metadata, such as network, subnet, security group, and image attributes, across AWS, Azure, and Google Cloud. It picks up each new workload’s identity as soon as it launches, so policy applies from the start.
Because policy keys off these tags and attributes, tag hygiene becomes a security control. Enforce mandatory tags with native guardrails (AWS tag policies and SCPs, Azure Policy, Google Cloud Organization Policy), and pair them with automated pipeline checks. If a workload template lacks the mandatory security tags or routes traffic through an uninspected gateway, fail the build before anything is provisioned.
Where to Look Across AWS, Azure, and Google Cloud
Share this reference table with your cloud engineering and platform security teams to run each audit:
Audit Check | Amazon Web Services (AWS) | Microsoft Azure | Google Cloud (GCP) |
|---|---|---|---|
1. Egress Paths | Route tables with 0.0.0.0/0 to NAT Gateways or Internet Gateways; VPC Flow Logs | Route tables with 0.0.0.0/0 to Internet or virtual appliance next hops; NAT Gateway associations; VNet Flow Logs | Default routes (0.0.0.0/0) to the default internet gateway; Cloud NAT configurations; VPC Flow Logs |
2. East-West Reach | Transit Gateway route tables; VPC Peering connections; Security Group ingress CIDRs | Virtual Network Peering; hub-and-spoke routing configurations; NSG inbound rules | VPC Network Peering; Network Connectivity Center spokes; VPC firewall rules |
3. Policy at Launch | Terraform modules; CloudFormation templates; AWS resource tags; AWS Config rules; SCPs | Terraform modules; Bicep templates; resource tags; Azure Policy definitions and tag enforcement | Terraform modules; Infrastructure Manager; labels and network tags; Organization Policy Service |
What Skipping the Audit Costs
The cost of unmanaged cloud exposure rarely shows up as a line item until an incident happens. Before that, it accumulates quietly in your change-management backlog.
When the bill does arrive, it is large. IBM’s 2026 Cost of a Data Breach Report puts the global average breach at a record $4.99 million. Among organizations that suffered an AI-related breach, 92% lacked proper AI access controls, and only 40% of all breached organizations applied access controls to AI models and data at all.
Every new outbound destination, partner connection, or AI data source needs an infrastructure change ticket. Requests back up, deadlines loom, and engineering teams look for routes around the perimeter. Each detour can become a standing exception: a broad CIDR allowance, an uninspected NAT gateway, a disabled firewall. Those exceptions are exactly what the egress and east-west audits reveal.
Common Pattern: When approval queues for new destinations run long, teams tend to build their own workarounds rather than wait. Unmanaged paths tend to appear wherever enforcement gaps meet developer convenience and automation.
Security leaders should treat standing exceptions as a leading risk indicator. The exception count shows how much of your production footprint already operates outside your security baseline.
Conclusion: Watch the Film Before the Game
Game film shows where an opponent broke through last week. A structured audit shows where your architecture is exposed right now.
Schedule these three checks this quarter. Start with the workload tier that has the highest velocity, the most connectivity freedom, and the fewest architecture reviews: your AI and data science environments.
To see how enterprises close these gaps with cloud-native workload protection, explore Zscaler Zero Trust Cloud.
FAQs
Run the egress and east-west audits at least quarterly, and again whenever you roll out a new class of compute, such as distributed AI training clusters, inference endpoints, or autonomous agents. Treat the launch audit as an automated, continuous gate in your CI/CD pipeline rather than a periodic review.
- Egress traffic flows outbound from a cloud workload to the public internet, external SaaS applications, or public code and model repositories.
- East-west traffic flows laterally between workloads inside your environment: across subnets, VPCs/VNets, regions, cloud providers, or to private data centers.
Each is a distinct threat vector and needs its own control: inline TLS inspection and allowlisting scoped to workload identity for egress, and workload-identity microsegmentation for east-west traffic.
AI systems need broad data access, depend on third-party packages and pretrained model weights, and are often built quickly in developer sandboxes. Because these environments need wide connectivity and sit close to enterprise data, security debt builds much faster than it does for traditional applications.
このブログは役に立ちましたか?
免責事項:このブログは、Zscalerが情報提供のみを目的として作成したものであり、「現状のまま」提供されています。記載された内容の正確性、完全性、信頼性については一切保証されません。Zscalerは、ブログ内の情報の誤りや欠如、またはその情報に基づいて行われるいかなる行為に関して一切の責任を負いません。また、ブログ内でリンクされているサードパーティーのWebサイトおよびリソースは、利便性のみを目的として提供されており、その内容や運用についても一切の責任を負いません。すべての内容は予告なく変更される場合があります。このブログにアクセスすることで、これらの条件に同意し、情報の確認および使用は自己責任で行うことを理解したものとみなされます。



