Securing Microsoft Azure resources for a Sitecore deployment

Last updated Thursday, February 2, 2017 in Sitecore Experience Platform for Administrator, Developer

All Microsoft Azure® resources used by a Sitecore deployment have some form of security control, each with varying levels of granularity. This topic describes securing:

Access in the Microsoft Azure portal

In your Sitecore environment, you use the Azure portal and the Azure Resource Manager REST API to perform management operations on all of your resources. This includes: creating and deleting resources, getting and setting resource properties, as well as scaling and monitoring availability. You control who can perform management operations on which resources by using role-based access control (RBAC) roles such as Owner, Contributor, and Reader. Each of the roles provides a decreasing level of permissions:

  • The Owner role has full permissions to the resource.
  • The Contributor role has full permissions, but can neither grant nor revoke access to the resource, nor manage security policies and custom roles.
  • The Reader role can only read the resource status and basic properties.

Consult the Microsoft Azure documentation for more information about using role-based access control in the Azure portal.

Web Apps

Sitecore uses Microsoft Azure Web Apps® to host its web front end including, for example, Content Management (CM), Content Delivery (CD), Processing, and Reporting. Web Apps offers two main options to lock down access to your environment: IP whitelisting, and authentication (the Web Apps authentication sits on top of Sitecore’s authentication and does not replace it).

You can use your Azure authentication to provide an extra layer of your security on your CM and Processing roles. You cannot add this extra layer to your Reporting role because your CM and CD roles need to call this service. Consult the Microsoft Azure documentation for more information about authentication and authorization in the Microsoft Azure App service.

IP whitelisting limits which IP addresses can access a Web app, which is mainly useful for controlling access to the CM, Processing, and Reporting roles. Make IP whitelisting one of the first tasks you perform on your new Sitecore deployment. It is good practice to make the Content Management role only accessible from your company’s IP, the Processing role not accessible to anyone, and the Reporting role only accessible from within Azure. Consult the Microsoft Azure documentation for more information on how to find your outgoing Microsoft Azure App Service® IP address.

You cannot limit access to only your Sitecore Web Apps, so you must lock it down to the four outgoing IP addresses that your Web Apps will share. This reduces the amount of people who can access your Web Apps.

Important

Remember, it is possible that those four outgoing IP addresses that you and a subset of other Web Apps users in the data center share, can change over time. So if you choose to use these IP addresses, do so with caution.

Azure SQL database

Sitecore uses Microsoft Azure SQL® to host all of its databases because it also comes with many security capabilities.

Your newly provisioned Sitecore environment also creates a different user for each role and each database that it needs to access. For example, there is a CM-core user, and a CM-master user. This level of granularity gives you a lot of flexibility in controlling precisely who can access what. You can change the passwords and permissions of these users by managing the SQL database logins.

By default, you can only access Azure SQL instances from inside the Azure environment. You can expand your access to external IPs, such as your corporate environment, by following the steps in the following documentation:

Send feedback about the documentation to docsite@sitecore.net.