Times Have Changed – For the Better
It wasn’t long ago – maybe 10 years – that the headline of this article would have blown my mind. And I’d probably have dismissed this whole blog post as ridiculous propaganda. But times have changed.
If you’re still a cloud naysayer, even after all this time, I don’t expect this little post to fully change your mind. But maybe it can put a chip in your preconceptions. And I’m not going deep here. If you want to talk more, question my assumptions, or even rage from your rooftop, please feel free to email me or come to one of our AWS User Group Meetups. I’d love to chat.
AWS Disclaimer
Oh – and one more caveat before the real content: I am a believer in Amazon Web Services (AWS). I don’t know enough about GCP or Azure to fully condemn them as inferior, but I know that AWS fully scratches my cloud itch by driving down cost and increasing capabilities regularly. So when I say “CLOUD”, I’m talking AWS. If you want to throw stones at that decision, we’re both free to form our own opinions.
The Power of the Cloud
Public cloud infrastructure has come a long way in the last decade and a half. It’s no longer simply a haven for public-facing applications and components that really don’t need security around them because they’re intended to be publicly consumed.
Now you can create virtual private enclaves that:
- Act as extensions to your data center
- Serve up internal or external content
- Host your backups
- Automate your business processes
- And serve a bevy of other purposes that you may never have been able to bring into your old on-prem world due to the high cost of entry
Security Considerations
Today, when properly configured*, the cloud opens your hosting environment to a highly secured buffet of IT capabilities that used to be available only to the largest and most avant garde of corporate juggernauts.
If you’re working at one of those juggernaut companies that has a ton of resources spread across different regions, some of my comparisons below are not 100% applicable to you. But some may apply…
And even if you have a lot of data centers and resources, that doesn’t mean you’re leveraging them in a cloud-like fashion to get the most out of them.
Location, Location, Location
Where’s your on-prem data center? On your premises. I know where that is. If I want to take your systems down, I know which lines to cut, poles to crash into, or parking lots to drop USB sticks in. Even if you’re at a CoLo, their data center locations are very knowable, and I can do the same nefarious things there.
Good luck finding AWS’s data centers. Even if you know the region… Even if you know the availability zone (AZ)… Each AZ has multiple data centers. And while the forces of evil are trying hard to find them, they’re not very findable.
How’s Your Physical Security?
Can I get a tour of your on-prem data center? Your CoLo? Sure! Most likely, you or your hosting provider would love to show off your arrays of blinky lights. It’s natural to want to show how cool your stuff is.
Good luck getting a tour of an AWS data center. There’s no reason for it. Their business is keeping the data center safe – and they take it seriously.
Availability – Remember That Part of Your Security Triad?
Do you have a load balancer in front of your application server? Cool! Is it load balancing between different data centers in the same metropolitan area? Probably not…
With AWS, depending on the service(s) you’re using to host your application or capability, you’re either in multiple availability zones by default, prompted to configure it up front, or have it easily enabled after the fact. One of the cloud’s major tenets is availability. If you’re hosting something on AWS on a single instance, you’re actively working against the pattern. In other words, you’re doing it wrong.
More Benefits: IT Team’s Focus
Note: For the most part, I’m keeping cost out of this article — but along with elasticity, this section highlights one of the biggest money differences between on-prem and cloud operations. Running a data center is expensive! In the cloud, that expense is allocated across the services. So to complain that you “could run that server for way less money” is likely not factoring in all of the elements of cost you ignore on premises.
If you’re running your own data center, you are in one of two IT configurations. You might have dedicated staff keeping the hardware healthy, replacing faulty parts, upgrading firmware, ensuring redundancy in all things, ensuring the power and cooling in the data centers is appropriate, and doing all of the other things it takes to keep a data center operational.
Or, you might have staff that has to do all of those things as a part of their job, but also focus on operating system and application deployments, patching, networking, layer 4-7 security, and all of the other stuff that comes with being that type of a sysadmin.
In the cloud, your IT staff not only don’t have to worry about the conditions in the data center — but they really can’t! There are some base level components that are benefitted from a lower level knowledge of data center operations (i.e. constructing VPNs, handling the allocation of network segments, etc.) but for the most part, the IT staff has their attention turned towards the payload of the applications — that the user/customer gets what they need, rather than whether a piece of hardware is faulting or not.
Embracing Your SaaS
Do you enjoy patching your domain controllers? How about backing up your file servers? Running mail servers? Mail relays? Load balancers? API servers? Middleware?
Core infrastructure components are becoming commodities. Stop running them yourself. Focus on the differentiating factors for your organization or offering.
*But… What If You Don’t Configure It Right?
You thought I forgot about that asterisk above. Didn’t you?
So, this is the BIG “BUT” of the article…
Yes, the cloud is a far better choice for hosting pretty much anything that runs on a x86 (or, as of late, ARM) processor. But if you don’t know what you’re doing, you can screw it up. The news over the last few years is full of instances where someone didn’t know what “Public” meant on a S3 bucket, so they leaked sensitive information to the world.
Or how about people not configuring a Security Group properly, thus leaving SSH open on their servers for the world to attack? And then there is the confusing world of IAM permissions, where you grant permission between components in AWS — a breeding ground for configuration screw-ups.
The interesting thing is, these same problems exist on premises. You can just as easily misconfigure your storage array and firewall to leak data directly to the Internet. You can misconfigure your web server so that it’s not just serving HTTPS, but also SSH to the world. These problems are not unique to the Cloud. They’re endemic in the industry.
How to Ensure Proper Configuration
How do you fix poor cloud configuration? You get training, do code reviews, and get external review done on your environment. Just like you have your network penetration tested on premises, have your AWS environment tested.
Nobody’s perfect – do your best and get more eyes on it. Make sure you have security representation on the project team from the beginning, so that they can be sure to train up on the applicable technologies and help close the gaps. A mindful security architect or engineer will welcome the opportunity to comprehend and secure a new capability.
Seize the Opportunity
I hope you can take away from this that the cloud is not something for an information security professional to fear — it’s an opportunity to do more with less, and reprioritize the savings to help close gaps in other areas of your environment.
Stay safe… and cloudy, my friends.
—
Photo by Juhasz Imre
