I generally dislike Snowflake in this case and think they're attempting to deflect the blame off themselves for the architecture you get forced into as a tenant of theirs. I have some experience going through their docs and asking some exactly-how questions for implementations on the tenant end. I think Snowflake can both deflect blame correctly but inherently be the root cause making it hard to get perfect and right in a security context as a tenant like Ticket Master (unaffiliated to me).
If they had real dedicated tenant services available, I'd probably feel they could defend themselves here. But that'll start an interpretation of meaning argument of dedicated vs. private with folks at SF due again to their architecture and thus the only context they speak. Private or dedicated to org only is neither easy to achieve via a lengthy list of security controls nor available to buy outright ... and their ask of SF tenant's to do better about the variety of hard-to-get-layered-right controls is too much sand paper for my liking.
Another starter point on interpretation and SF's context, I've had at length discussions with them on; IP filtering such as actual packet drops / time outs at network firewalls vs. HTTP 403 errors responses at ip filtering layer, which occur at SF's shared layer7 ALB's services, actually matters. Tenant's should not have externally resolvable endpoints to worry about IP filtering or their interpretation of default deny (like their IP filtering choice of interpretation). [0]
> - Credentials acquired for a Ticketmaster account at Snowflake.
Tenant organizations like Ticketmaster here must enforce 2FA on accounts themselves proactively. Most times, regardless of 100% of interactive user accounts with 2FA, you'll still need system to system 1FA API type credentials for automation or large batch processing. These 1FA Service type accounts are usually static API key type credentials or a role where the credentials rotate but the role becomes static / assumable by another federation layer before that like in your IDP, LDAP, etc. These types of accounts still need to be usable and stored somewhere, it's a bad assumption that everyone does SOPS, key store, hashi vault, credentials manager, secrets store, and the like perfectly at all times.
I'll hold off on the variety of ways you can choose to expose and share your data to 3rd parties. I don't think it's entirely a factor but folks should worry about this in other contexts too.
> - Log-in effortlessly because of single-factor auth.
Perhaps not effortlessly find, but it's not exactly easy to actually only expose your Snowflake instance to only your organization. Variety of reasons like shared authz/n happening in Layer7 at Snowflake ensure you can't go private exposure via private-link only, without also having externally resolvable addresses existing for your instance. Thus forcing you to layer IP whitelists, again poorly chosen by Snowflake at Layer7, wherever you can find how to apply it to all your instances (prod, dev, other subdomain tenant named instances). Thus creating an open loop in Ops for maintaining these SAAS software firewall lists. And eventually always having some ALB level HTTP web servers exposed to internet doing the IP filtering HTTP:40X error somewhere at Snowflake ALB's ensuring externally resolvable at least. Snowflake's fault here for never building true dedicated org capabilities with private hosting so far as I can tell.
> - Gain immediate access to a production environment and dump the database.
Not everyone will get a 403 when finding these Snowflake doors... and when you get a 200 with an SSO prompt you can usually start with username enumeration as a feature for getting true/false exists. These tenant's are almost always subdomain resolvable, picking one at random https://epa06486.snowflakecomputing.com/ exists and happily receiving the IP filter at HTTP 403. You can find more using tools like https://dnsdumpster.com/ (unaffiliated) or other relevant DNS toolsets you can walk subdomains for a lot of this information. As mentioned, these always end up with externally resolvable points of Snowflake tenant's interest in my experience because of Snowflake architecture choices not the tenant's mistakes like how to get IP filtering 100% right and have confidence in what is/not exposed to login attempts.
[0]https://docs.snowflake.com/en/user-guide/network-policies
[0]https://docs.snowflake.com/en/user-guide/security-encryption...
[0]https://docs.snowflake.com/en/sql-reference/functions/system...
[0]https://docs.snowflake.com/en/developer-guide/sql-api/authen...