Ah, good ol’ buzzword bingo. You’ve played it. When a new paradigm is needed to synergize with our innovations teams and create solutions to charm our valued partners, you’ve claimed triple word score, right?
Security and hyperscale get tossed around a lot, lately. But it IS a thing – and we’re going to break it down.
What is hyperscale, anyway?
“Highly scalable” (duh). “Distributed.” “Fast.” “Cost Effective.” Okay, those are still pretty buzzy. What hyperscale really does is allow for extremely rapid provisioning, reallocation, balancing and destruction of compute resources to either grow with a business; allow for rapid response to increased workloads; scale down to reduce power, bandwidth, or processor utilization (and cost expenditure); or allow workloads to peak and ebb on an underlying infrastructure. This all started with local hypervisors, then “private clouds” after a fashion, and now, of course, public cloud, which is really where and when hyperscale came into its own.
All of these resources were suddenly able to be stood up quickly, rapidly and with very little intervention. Got a Windows server that you need cloned? Simply click, “Next, Next, Yes, Finish.” Done! SQL? Repeat. Desktops? “Oh, yeah. I made a perfect Golden Master desktop; let’s clone that baby for my entire VDI infrastructure!” Easy-peasy, as the saying goes.
Oh. But now look. I have the same incorrectly configured or non-hardened Windows server cloned 300 times. My lovely Golden Master Windows image has a known vulnerability. How do I fix that? Do I manually patch 12,000 machines? What about the next patch cycle? How do I show in my audit that I’ve done all those things? Who knows when or how the last server was laid out before moving from dev to production?
The importance of a security strategy
If you haven’t moved a lot of workloads to a public cloud already, you have a great opportunity to lay out a security strategy before you make a mess of it. Plan it out, think it through, and make it clean, clear, repeatable and scalable. You do HAVE a security strategy, don’t you? (I can help, if not.)
If you have already moved workloads, now is the time to review your security policy and architecture. How are you handling patch management? If you “can’t upgrade/patch/fix because ______,” then isolate that machine (more on that later). Where are you storing the OS data? Where is the app data? Customer data? Did you segregate each customer? Did you need to? What rules and regulations are you subject to? Do you have proper account management on your public cloud and private clouds? What about multi-factor authentication? Are you encrypting data? Do you have a plan for data migration between different providers?
Clear policies, step-by-step runbooks and automation
If all this sounds a bit intimidating, that’s okay. It can be, but it can also be planned for and made a bit less painful with the help of clear policies, step-by-step runbooks and automation. If you can’t automate parts of your workflow, it’s not clear enough. The more unique steps you have to take in any urgent situation is another step where failure occurs, and time is wasted. Can you automate your patching? Can you automate firewall deployment? Can you automate VM migration? Can you automate log collection?
For example, think about putting virtual firewalls between different groups of virtual machines (if you’re not doing this, you should definitely talk to me). You can automate certain classes – engineering desktops, sales desktops, SQL servers, domain controllers, etc. – and they all SHOULD have their own up-to-date images and up-to-date firewalls with centralized audit and logging. That “unpatchable” machine? Isolate it. Do you have a clear picture of your network? Do you know how it works before it scales out?
Security at hyperscale IS possible – but it starts with clear policy, some thoughtful planning and consistent application of methodology before any new technology.
Let Arrow and me help you – contact us today!