Recently I finished off a 10-part series on the top mistakes to avoid when getting started in Azure. I’d like to complement that content with a follow-up pair of posts focused specifically on security. My objective here is to provide a quick-reference checklist you can use to maximize security benefits from the beginning.

Once again, I’m going with the number 10. This first post covers five key ideas, to be followed by another set of five in the second post. All these tips are drawn from experience working with hundreds of clients. In almost every Azure environment I go through, I see issues that need addressing with the concepts laid out here.

Note these aren’t in any order of priority. When it comes to security basics, you need to cover the whole ground.

#10 – Implement micro-network segmentation for resource groups with traditional virtual machines. 

The number-one problem in traditional “corpnet” network environments is horizontal interconnectedness among systems that don’t fundamentally need to talk to each other. That’s the essential architectural problem with the traditional model. It’s the root cause of vulnerabilities to lateral threat movements. It’s why contractor machines, say, that should have had access to just one system might instead access Active Directory and then more and more systems—and aren’t discovered for months.

As you transition to Azure, you need to work to segregate systems. Abandon the paradigm in which everything is joined together with everything else. New resource groups should have their own network security groups. Work toward segregating your desktop and end-user computing environments from your application servers and other core resources. Ultimately your user machines should be on a guest network and not joined to a “corpnet” structure at all.

This is a vertical network model rather than a horizontal one. With these vertical divisions in place, all machines and applications can to talk to each other only to the extent they need to. The way to get there is to start applying micro-network segregation as you build out your Azure environment—not waiting till later.

#9 – Deploy operational needs and process, such as patching, logging, and alerting. 

Moving a resource into the cloud doesn’t mean you no longer need to patch it! Far too often I’ve seen Azure environments with no patching structure built out. That’s a failure to maintain basic blocking and tackling.

Don’t take this to mean you should bring everything in your physical environment with you into Azure. That’s definitely not the case. Don’t look to duplicate the specific mechanisms you use for blocking and tackling. Take advantage, for example, of native Azure capabilities such as Desired State Configurations and Azure Monitor, which provides log analytics and monitoring. (And, to the extent you need to, feel free to bring your SCCM temporarily into Azure to fill any gaps.)

Using Azure Monitor, fully define the operational processes to occur when a security failure occurs. How should you and your team be alerted? Define the steps you will take in response to an auto-created ticket in your case management system or to a pager alert or to whatever other notification fits your business process. But whatever that process is, define it clearly. As you establish those definitions, you’ll be forced to grapple with how responses to cloud-security incidents necessarily differ from on-premises patterns and practices.

In short, of all the things you take with you to the cloud, your existing commitment to blocking and tackling is among the most important.

#8 – Understand modern App Services, App Service Environments and Serverless models and how these change topology. 

The nature of App Services makes them relatively more available—and therefore less isolated—than most resources. That’s because App Services are intended to be externally accessible, with internet IP addresses. You can apply IP restrictions, monitor access and leverage various security tools, but the fact remains that these App Services are relatively accessible, by their nature.

Given that, in many organizations, their use is limited—at least at first—to building out internal use-case scenarios. This is a rational way to gain experience protecting App Services, before using them for production purposes.

As you learn, one critical concept to understand (but likely minimize) is App Service Environments, which are constructs that encapsulate the App Service itself as well as a network security group. In this way, you can isolate the App Services from the outside world and separate them your other resources. You can use network security group policy to deny general internet access to the App Services. Within the constructs, you can house Window web apps, Linux web apps, docker containers, mobile apps, functions and more. I don’t recommend using App Services Environments for most use cases because they are both more expensive and can be limiting. I suggest your first priority should be to build outside of App Services Environment and optimize how you leverage the native scalability, security, and capabilities of the App Service technology, as well as the many other Azure technologies that would not be deployed in an App Service Environment.

 #7 – Store Corp IT configuration as code in source code repo and be able to restore. 

Here’s a shorthand way to way to state this key point: “No clicky-clicky!”

That is, do NOT deploy your corporate IT environment by means of “click-click-clicking” your way through the Azure portal. Instead, embrace “re-deployability” as a security feature. You need to be able to count on your ability to quickly and seamlessly re-deploy your Azure infrastructure in the event something goes wrong—whether by malicious intent or by accident. Doing so is impossible if your original setup relied upon a “clicky-clicky” approach.

So, what’s needed is deployment via a source-code repository. To get there, start thinking of your infrastructure the same way you do your applications. That is, apply a DevOps mentality. This mentality will force you to have backups of your infrastructure deployments in the same way you do your other resources. And carry it through!—Make sure your resource groups are tied into Azure Backup and you audit the arrangement with Azure Policy tools.

And remember this: if your application teams are building things that aren’t getting backed up, ultimately that’s a problem that comes back to haunt the corporate IT group—not the developers. You need to ensure you can readily execute recovery processes.

More broadly, commit to forcing Azure Backup for all resource groups: anything that gets deployed also gets backed up.

#6 – Implement RBAC around resource groups for application teams and subscriptions for application groups. 

There’s an unfortunate trend toward giving too many people ownership of Azure environments, with admin rights and access. This is a fundamental violation of role-based access control (RBAC) principles. Don’t fall into this trap. To avoid it, focus on the ROLE not the PERSON.

You need to ensure that application teams have access to ONLY application resource groups and not admin-level access. This is a basic security principle.

Where things sometimes get muddied is when a particular person is part of the application group and ALSO has admin (owner) credentials that permit deployments. In this case, you need to enforce use of separate credentials. One set for the application group and a separate set (perhaps with additional controls applied) for admin/deployment purposes.

And with respect to those deployment credentials, you should further control their use. Structure deployments to be automated from source code in your repository. Deployment credentials should therefore permit read-only access to monitor the automated deployment—but not open-ended access to deployment tools.

The bottom line is to stick to RBAC principles. Keep resource group ownership (and admin rights, such as deployments) separate from application-group rights.

Next steps

That’s the first five. Here’s a preview of key topics to come in the next post: Azure policy, ARM template rules, Security Center, Privileged Identity Management and other helpful tools.

I recommend you put all 10 together to form a checklist to ensure you get going in the right direction from the start as you implement cloud security best practices, including essential monitoring, scanning, and access control.