[DCKing]

While it's true what you say, the underlying assumption is the general approach of "my network is secure and keeping track of what goes in and out is something I control". I won't comment on how it applies to your situation, but I do think this is assumption is outdated castle-and-moat security thinking. This assumption also falls apart on closer inspection in 99% of the situations and in my experience especially so in cases where people bring up this assumption.

[ocdtrekkie]

Large companies with very decentralized infrastructure (who also profit off selling clouds in many cases) promote zero-trust infrastructure models. This is predominantly based on what works for them (having hundreds of offices or large amounts of remote staff), and of course, a must to sell people on if you want to sell cloud services.

Zero-trust is not without merit, by any means. It is good to not assume there are no cracks in your walls, and you should indeed use as much internal security as possible wherever you can.

But you know what's really quite silly? Deciding to fill your moat in with dirt and knock over your castle wall because you think it's possible for someone to get in anyways.

You had better believe I'm going to use the latest authentication and encryption tools between machines that I can to ensure nobody can listen in from a stray network connection... and that I'm also going to put all of it behind a firewall.

Yeah, lock your doors inside your castle, but for heaven's sake, the moat and the castle walls still help. Defense-in-depth is a concept I swear everyone forgot when clouds became a thing.

[DCKing]

Ah yes, but now you're describing requiring you to set up engineering regiments within your castle, some portion of which you could outsource to your cloud provider in the alternative situation. My point is that this security boundary that you posit as an advantage in your original post is simply not very interesting (and often harmful) on its own.

[ocdtrekkie]

Cloud providers aren't very intelligent security layers.

My favorite example is my Google Voice account. It has a different area code (out of state) than my real phone number. I get a lot of spam calls, almost all through Google Voice, and I know not to answer them, because nobody legitimate calls me from the area code my Voice number is from.

Google has state-of-the-art artificial intelligence and spam filtering capabilities. It's arguably the two most sophisticated advantages Google has. And it is completely ineffective at blocking spam calls. If Google Voice gave me the ability to create my own filter rules, I could write a one-line rule that would drop any call from that one area code, and I would have perfect spam filtering for my account.

This isn't an example about Google Voice, but about the difference between generalized technologies that cloud providers use versus configurations you can apply yourself that are custom tailored. Obviously, Google can't block everyone in that area code as a spam filtering method... many people legitimately have that area code. But for my phone, it would be a good rule and would be nearly 100% effective.

Which is to say, my engineering regiments will always be more capable than my cloud provider's engineering regiments, because mine know my system and my customers and my use cases. I'm paying engineering regiments either way, so I might as well pay my own.

[DCKing]

> Cloud providers aren't very intelligent security layers.

I think I lost track of what you're trying to discuss now. I'm not arguing cloud providers are a security "layer" in any sense, just that they take responsibility for some things you otherwise need to do yourself. If you got that from my post I apologize. Even if I said something like this, I don't know how your Google Voice example (which is an application/service) applies to cloud infrastructure.

> Which is to say, my engineering regiments will always be more capable than my cloud provider's engineering regiments, because mine know my system and my customers and my use cases.

Good for you if true, but I've personally never seen an environment where such confidence on the part of infrastructure engineers has held up. At least not from a security perspective.

> I'm paying engineering regiments either way, so I might as well pay my own.

If it turns out the equation favors you, then great, those companies exist. But I don't think the equation favors many, at least not when including all the items you need to have for self hosting.

[ocdtrekkie]

> I don't know how your Google Voice example (which is an application/service) applies to cloud infrastructure

I tried to explain the concept above, but it's that whether it's an application/service or cloud platform, it's tooling has to be designed for the entire customer base. Often, a far stupider solution can be far more effective, if it only has to be written to apply to one use case.

> such confidence

Don't get me wrong: Nobody's perfect and everyone has security holes. But things like all of the public S3 bucket fiascos should remind you that the cloud is, by default, open to everyone, and people become incredibly overconfident that Amazon or Google or Microsoft will keep them safe.

> If it turns out the equation favors you

It almost always does. When I do something in house, I am paying for hardware, software, and engineers. When I do something on the cloud, I am paying for hardware I don't own, software I don't own, engineers who work for someone else, and a healthy profit margin for one of the five most valuable companies on the planet.

Cloud is a narrowly-effective solution for startups which can't size out their solution themselves fast enough, and short-time peak loads. For everything else, you should probably not cloud.