Skip to content
Notifications
Clear all

Unpopular opinion: Prisma Cloud and Prisma Access are a forced marriage that doesn't work.

3 Posts
3 Users
0 Reactions
1 Views
(@data_meets_ops)
Estimable Member
Joined: 2 months ago
Posts: 88
Topic starter   [#22284]

I've been running a hybrid data stack for a few years now, with analytics workloads split between on-prem and cloud. When we started looking at SASE for secure access, the promise of Prisma Access combined with Prisma Cloud's CSPM features seemed like a neat, unified story from Palo Alto. After a lengthy POC and now 10 months of production use, I'm convinced this is more of a forced product bundling than a truly integrated platform.

From a data operations perspective, the seams show. Managing policies for data egress from our on-prem data lake to cloud analytics services (BigQuery, Snowflake) via Prisma Access is one console, with one logic set. But then, trying to apply Prisma Cloud's posture rules to those same cloud data warehouses feels completely disconnected. The logging and telemetry don't unify in a way that's useful for building a single view of data flow security.

Some specific friction points:
* **Policy Lag:** A security group change in Prisma Cloud (for a cloud data store) doesn't reflect in Prisma Access policies in real-time. We've had to build our own sync checks.
* **Visibility Silos:** The network traffic logs (Prisma Access) and the cloud security alerts (Prisma Cloud) live in different places. Correlating an access issue with a potential misconfiguration in our Snowflake account is a manual, investigative task.
* **Operational Overhead:** It feels like we're managing two separate products that happen to share a logo. The teams that handle network security (managing Prisma Access) are different from cloud ops (who look at Prisma Cloud), and the platform doesn't bridge that gap effectively.

I'm left wondering if we'd be better served with a best-of-breed approach—a dedicated SASE provider for secure access and a separate, specialized CSPM/CNAPP tool built with cloud-native visibility in mind. Has anyone else in data-heavy environments hit these integration walls? How are you handling the governance of data flows when the network and cloud security controls are so loosely coupled?



   
Quote
(@harryp)
Eminent Member
Joined: 1 week ago
Posts: 28
 

Yeah, the policy lag you mentioned hits home. We've seen similar issues where a developer spins up a new cloud storage bucket, and the access policies don't get the updated context for hours. It creates a weird window where the asset is visible in one console but not properly governed by the other.

It feels like they're still two different product teams working on different release cycles, and the "integration" is more about single sign-on than shared policy logic. I keep hoping for a truly unified policy layer, but for now, building those sync checks you mentioned is unfortunately the norm for advanced use cases.

Do you find the telemetry gap is worse for certain cloud providers over others?


~Harry


   
ReplyQuote
(@git_ops_guy)
Estimable Member
Joined: 4 months ago
Posts: 127
 

That policy lag sounds rough. We tried to codify some of those sync checks with GitOps workflows for our cloud configs, but hit similar telemetry gaps. If the logs don't unify, it's impossible to build a proper drift detection loop.

Have you found any workable pattern for correlating those network logs with the cloud alerts, or is it all manual dashboards?


git push and pray


   
ReplyQuote