Cloud Architecture & Security
Can you do a better job of securing your network than a cloud provider like Microsoft Azure? Are you afraid to move critical workloads to the cloud? How should we look at architecture and security in the cloud? There are actually two questions in this one and both of them are monumental. When architecting a technology solution in the cloud there are many things to consider. Enough in fact that many books can and have been written on the subject. If you want to dive deeper on the subject, I recommend “Cloud Architecture Patterns: Using Microsoft Azure” by Bill Wilder. For the purpose of this article I want to focus on some simple concepts that should be considered for migrating any workload to the cloud. I will preface the discussion with these considerations:
If you are currently running on premises, or on a partner network you likely have an inherent “feature” built into your architecture. That feature is that all the servers and services can communicate with each other by default. This is a double-edged sword. On one side, management is super easy as there are no hoops you have to jump through to make different services communicate. The other side however is that if you have a breach there are no hoops the bad guys have to jump through to gain access to your entire infrastructure. Some companies for their on-premises systems put up many measures like firewalls, IPSec, and VLANs, etc. to combat this problem. These technologies are very helpful but they are expensive, and a nightmare to setup and manage. The cloud on the other hand has many inherent security boundaries that can be leveraged to help protect systems. Some of these include Account, Subscription, Storage Account, VM, VM Firewall, Network Security Group (NSG), Virtual Network Isolation, Access Control Lists (ACLS), Distributed Denial of Service (DDOS) and more. Adding to these natural boundaries and protections, connections into your cloud infrastructure does not even have to go over the public Internet. Instead, you could use ExpressRoute which is a private line. Basically you would get a direct private line from a provider (such as Sprint, AT&T or whomever) setup a demark location at your datacenter location and terminate the other end at the network provider. This termination point would then jump on the Microsoft dedicated fiber to go directly to your account services and infrastructure at a blazing speed. The same technologies (like IPSEC) that you can setup on premises, you can also use in your cloud infrastructure. When you put all this together, you can really setup some very secure and easy to manage and protect infrastructure. You can see in the network diagram below that these technologies working together can give you ultimate flexibility. It gives you the capability to isolate services, share services for full access, open ports, redirect, leverage access control and so much more. This makes for easy management of even multi-tenant environments.
Obviously, you could also configure your cloud infrastructure the same way on premises networking and security is configured. This would be as easy as have everything on the same network and setting up a VPN from on premises network to the cloud network. This is not a great idea. If you are in a hurry to lift-and-shift to the cloud, sure, go do it but recognize that you should go back and fix it as soon as possible. A better approach is to secure resources as you move them into the cloud. Measure twice, cut once. Plan and architect the migration so you are securing resources from the beginning. Save yourself some time and do it right the first time. Having said that, I also feel compelled to say, it is very easy to lift and shift. It is also very easy to migrate after you have shifted to Azure. Therefore, an equally effective solution is to Lift and Shift as the first step of your migration plan. This is perfectly acceptable and even recommended. I just want to make clear that you should not step after this first step. Doing the rest of the work is also needed.
A security mindset for the cloud forces a new way of thinking. In the old way of doing things (on premises or with hosting partners) the concepts that most companies deployed was defend the perimeter. This is an old way of thinking and simply does not work with the advancements of the evil doers of the world. We still want to defend the perimeter which includes firewalls, keeping systems patched/updated and the like. When the “defend the perimeter” mindset was created, we were dealing with a bunch of 10 year olds (and others) writing scripts to hack systems for fun. Now, the bad guys are far more sophisticated. We are dealing with terrorist organizations, organized crime, corporate espionage, and even nation state attacks. These people and organizations have enormous resources. Additionally, they often aggressively share so once you are compromised by one, you can easily be compromised by many. Once upon a time, when a system was compromised, we knew it almost instantly because the pranksters would pop-up annoying boxes or otherwise let us know that they were in. Now, they creep around under the covers with nobody the wiser trying to find how they can go deeper and gain advantage to make the breach beneficial. In this new world, we still have to defend the perimeter but we must also ASSUME BREACH!
Once a system has been compromised, you want to make it is as hard as possible for them to go any further. Your objective is to increase the cost for attackers to gain value out of your network. Raising the cost (time/resources) to gain value from you will hopefully encourage them to go elsewhere for an easier target. Some of the things discussed earlier like isolated networks, ACLs and leveraging the inherent benefits of the cloud are a first step to architecting a secure platform for your cloud resources. Let me pause for a second here to drive a very important point. I am not saying don’t move to the cloud without putting these practices in place. In fact, I would advocate just the opposite. Moving to the cloud for the sake of instantly gaining some inherent security advantage should be a key consideration. Once in the cloud you have a platform available to you for setting up isolation points easily and with little or no cost. Setting up similar capabilities on premises, would be very expensive and very difficult. The reality is that most do not have them in place to begin with and do not have the time, skills or money to deploy them. Therefore, there is more value in moving to the cloud now vs waiting until you have the time to do it right.
In the assume breach model you want to make sure the compromised system cannot be used to go deeper. By setting up isolation points like (Subscriptions, Accounts, Storage Accounts, Isolated Networks and other) if one gets compromised, only the data associated with those systems can be compromised. Let’s take this one step further by categorizing our data and services and apply different and higher levels of protection to higher priority data and services. This is often referred to in the security world as “don’t use the same money and energy to protect your paperclips that you use to protect your diamonds”. In order to see how this works let’s take a look at a web front end server. It is an Internet-facing service that frankly is subject to compromise. But once the system is compromised you want to make sure there is no path for the attacker to get to your data. It is even more important that there is no path for the attacker to get to the “diamonds” or the most valuable data. Data like trade secrets, domain controller, or certificate stores. In a cloud environment this is super simple. In an on-premises environment, it is super hard. There are lots of other things you can do to step up your internal security. Some of these include: only certain people are allowed to access high value resources and only from certain machines. Another key concept that can be deployed is “just in time administration” or “just in time access.” In these environments, the users that need the access rights are granted the access rights for the time and resources they are needed and then immediately taken away. As an example, if an engineer needs to work on a system, he has a work order and the expected time to complete the task is 1.5 hours and he is scheduled to start at 10am. Well, you would grant him the access rights to do that work for that time slot and then rights would immediately be removed. If he ended up needing more time, the window could be extended with the proper permissions. There are many other technologies and practices that can be deployed to make it incredibly difficult for attackers. Obviously, the more you do the more overhead of management you inevitably add. These are common practices in an Azure Datacenter. Another very simple but often over looked advantage is something referred to as “security by obscurity.” This is, it is hard to attack a company or resource if you cannot find it. In an on-premises environment, once someone gets your public IP address (eg. from your website) they now can very easily attack all of your other IP addresses because the likelihood is that the adjacent IP addresses are also owned by your company. In a cloud environment the IP addresses you are given are completely random. There is very little probability that if someone knows your website IP address that they can then easily find the IP address of other hosts or services.
As I talk to customers that are moving to the cloud I hear that in all cases they are finding they are more secure because they moved to the cloud. Many have also told me that before they moved to the cloud they “thought” they were going to have to sacrifice some security for the other very valuable advantages of the cloud. The reality is that the perception that the cloud was less secure was simply false. It was nothing more than a false understanding about the technology and forging and often even writing opinions based on conjecture instead of facts.
Another key concept to understand is the value of your cloud provider. The reality is that your cloud provider becomes your partner. Without this partner, you take on 100% of the risk which is what happens with your on-premises infrastructure. Once you start putting workloads in the cloud, your cloud partner starts assuming some of the risk for those assets. The type of systems you deploy to the cloud will determine the amount of risk that your cloud partner will assume on your behalf. In the case of Infrastructure as a Service (IaaS) also referred to as a VM in the cloud, you still have most of the responsibility/risk of those resources. Your cloud provider is taking on the risk and responsibility for the hardware of physical layer as well as the host and to some extent the networking infrastructure that ties it all together. As you move up the stack of cloud services to Platform as a Service (PaaS) your partner assumes more responsibility (often these services are cheaper too J). With these services you do not manage the virtual machines, you manage the applications. You are not responsible for what you do not manage. In this case, your provider (Azure) would manage the virtual machine, patch it, manage passwords, etc. so you do not take on that risk. You are responsible for making sure you are protecting access rights to your application and any application level controls. Since you may and often will connect your PaaS network to your IaaS network, and you often open up ports to your PaaS services there is a shared responsibility for the network controls. In the highest level of abstraction Software as a Service (SaaS) your provider continues to take on additional risk because now it is not your application that it is their application. They take on the risk for their applications. You still have to make sure your users use passwords, change them regularly, set minimum requirements, and don’t share them, etc. However, much of the responsibility will land on your provider.
Windows 10 Security
Cloud security is not the only security we should think about. If you have not looked at the massive changes in Windows 10 from a security stand point, what are you waiting for? There are lots of reasons to upgrade to Windows 10 but none of them more important in my eyes than the security enhancements built into the platform. Some of the key things you need to know are: Windows 10 is far more secure than any prior operating system, you will need to upgrade your standard hardware requirements to take advantage of many security enhancements, and the security enhancements alone are a good enough reason to start the process of planning your Windows deployment. Perhaps in a future article, we can dive much deeper into client security. For now, I just want to hit some of the highlights.
TechNet on Tour | What’s new in Microsoft Enterprise Mobility
|8:30AM||Registration / Welcome|
|9:30AM-2:45PM (Lunch @ noon)||Identity and Access Management Self-Service and Single Sign-on Manage and Control Access to Corporate Resources Mobile Device and Application Management Information Protection|
|2:45-4:30PM||Wrap-up & Raffle, Instructor led / Hands-on labs|
Don’t miss this free IT Pro event, created to help you enhance security and compatibility – where and when you need it most. We’ll also raffle off four (4) Visa gift cards, so be sure to stick around until the end of the day.
BEFORE YOU ATTEND
This is a hands-on event, so please ensure you’re ready to get the most out of this session:
- Bring your laptop and power supply
- Hands-on labs will require a subscription or 30-day trial of Microsoft Azure and Microsoft’s Enterprise Mobility Suite (including Office 365 and Microsoft Intune). Save time and set these up before you attend:
- Azure subscription or free 30-day trial Microsoft Azure account. Or, if you subscribe to MSDN, activate your free Azure MSDN subscriber benefits.
- Sign up for a free 30-day trial of Microsoft Enterprise Mobility Suite.
- Optional: Bring a mobile device (iOS, Android, or Windows) to test mobile device management (MDM).
We look forward to seeing you at the event!
Do to popular demand, this month’s topic was changed to security. Perhaps we can get to Enterprise Mobility (for now see MVA Enterprise Mobility Suite: Beyond “Bring Your Own Device”) and Windows Server 2016 (for now see How to deploy Nano Server Windows Server 2016 Step-By-Step) next month? Due to trying to catch up a bit to get the newsletter out earlier in the month, also delaying the resume/CV to a future edition. Please provide feedback or suggested topics for this newsletter by contacting Dan Stolts.
Please forward this message to others that may find the content of interest!!!! Thanks
If this message was forward to you or you are otherwise not registered, you can subscribe here