Dynamics 365 Business Central has moved the ERP (core part of every corporate business) to the cloud and this was a huge step for many companies.

A SaaS ERP simplifies lots of administrative tasks (environment creation, backup/restore, platform updates, management, and more) but also opens an important (and sometimes under-evaluated) topic: security.

The world of business applications has changed a lot in the last few years. Before the cloud adoption, users of an ERP application were quite only the internal employees of a company, while now users can be employees but also external users like partners or customers.

The devices are changed: before the cloud, the access of the ERP application was only from corporate devices, while now you can have different types of devices (like tablets or smartphones) that connect from an outside network. And remote working has absolutely increased these types of access.

Are you ready to handle the security of your Dynamics 365 Business Central tenant at best?

I’m not so sure that all partners are ready to handle a SaaS tenant at best, so in this article, I want to emphasize some of the core security-related topics that you should be careful of.

The first important thing to say, before starting with the topis, is that Dynamics 365 Business Central is a SaaS service managed by Microsoft on its data centers across the globe and so the main security aspects and data protection policies are handled directly by Microsoft. Microsoft is rigorous on this. The corporate mantra is “we are one Blue Team” and what Microsoft is doing for itself in terms of security brings value also to customers and partners.

Some principles to understand the importance of security in your applications is:

• Assume that you’re in a world where everyone could attack you
• Verify your security adoption frequently
• Use least privilege access

When using Microsoft cloud solutions, you have some tools for managing the security of your Azure infrastructure, and also when thinking about the ERP security, you should start from securing your infrastructure.

The first security tool available on the Azure platform is Azure Security Center (now called Microsoft Defender for Cloud). Defender for Cloud provides the tools needed to harden your resources, track your security posture, protect against cyber-attacks, and streamline security management. Because it’s natively integrated, deployment of Defender for Cloud is easy, providing you with simple auto-provisioning to secure your resources by default.

Defender for Cloud continuously discovers new resources that are being deployed across your workloads and assesses whether they are configured according to security best practices. If not, they’re flagged and you get a prioritized list of recommendations for what you need to fix. Recommendations help you reduce the attack surface across each of your resources.

Image courtesy by Microsoft.

Defender for Cloud also includes a network map, an interactive view of the network topology of your Azure workloads, and the traffic routes that displays resources that have network recommendations with high or medium severity:

Image courtesy by Microsoft.

Another important tool is Microsoft Sentinel, defined as a scalable, cloud-native, security information and event management (SIEM) and security orchestration, automation, and response (SOAR) solution. Microsoft Sentinel delivers intelligent security analytics and threat intelligence across the enterprise, providing a single solution for attack detection, threat visibility, proactive hunting, and threat response.

Microsoft Sentinel correlates security alerts and signals from different data sources and you can respond to those alerts.

Microsoft Sentinel comes with a number of connectors for Microsoft solutions, available out of the box and providing real-time integration, including Microsoft 365 Defender (formerly Microsoft Threat Protection) solutions, and Microsoft 365 sources, including Office 365, Azure AD, Microsoft Defender for Identity (formerly Azure ATP), and Microsoft Defender for Cloud Apps, and more. In addition, there are built-in connectors to the broader security ecosystem for non-Microsoft solutions.

After you connected your data sources to Microsoft Sentinel, you can monitor the data using the Microsoft Sentinel integration with Azure Monitor Workbooks, which provides standard templates and gives you the versatility in creating custom workbooks across your data.

To help you reduce noise and minimize the number of alerts you have to review and investigate, Microsoft Sentinel uses analytics to correlate alerts into incidents. Incidents are groups of related alerts that together create an actionable possible threat that you can investigate and resolve:

Image courtesy by Microsoft.

Microsoft Sentinel has also deep investigation tools that help you to understand the scope and find the root cause, of a potential security threat. You can choose an entity on the interactive graph to ask interesting questions for a specific entity, and drill down into that entity and its connections to get to the root cause of the threat:

Image courtesy by Microsoft.

The Microsoft Sentinel data flow is described by Microsoft with the following diagram:

Image courtesy by Microsoft.

A common question that you could have is: what is the difference between these two tools?

Defender for Cloud gives you recommendations, alerts, and diagnostics. This set of information can then be used by Microsoft Sentinel to provide responses to threats. These two tools are absolutely complimentary.

These tools permit you to have a “big overview” of the security of your cloud infrastructure.

But what about security strictly related to the Dynamics 365 Business Central application?

I want to emphasize in this post 3 main topics:

• Authentication for external applications
• Delegated administrators
• Azure AD Conditional Access

Authentication for external applications

In a traditional ERP project, normally you have external applications that need to interact with the ERP data and in the past, this type of integration use Basic Authentication as the authentication method with the ERP. But Dynamics 365 Business Central also supports the OAuth authorization protocol for APIs, SOAP, and OData web services.

OAuth is an open standard for authorizing access to web services and APIs from native clients and websites in Azure Active Directory (Azure AD). In Business Central, OAuth is useful when your deployment is configured for Azure Active Directory authentication, either through your own Azure subscription or a Microsoft 365 subscription. OAuth lets users sign in to Business Central web services using their Microsoft 365 or Azure AD credentials.

Starting from Dynamics 365 Business Central 2022 Wave 1 (version 20), OAuth 2 is the only supported authentication method for Dynamics 365 Business Central SaaS and you should immediately start to change all your integrations in order to use this new protocol (much more secure).

Starting from April 2022, OAuth protocol is also required to connect to Dataverse.

In particular, Service-to-Service (S2S) authentication is required on scenarios where integrations are required to run without any user interaction, and here you can find details on how to setup it.

At the time of writing this post, about 2400 Dynamics 365 Business Central SaaS tenants are still using Basic Authentication for some integrations. These are all integrations that will be broken in April 2022 if the authentication protocol is not changed.

If you have telemetry enabled on your tenant (recommended), you can use the Dynamics 365 Business Central telemetry data to discover if you have integrations in place that use Basic Authentication again. Just open the Azure Portal and on your Application Insights instance execute the following KQL query:

Delegated Administrators

When working with customers of Dynamics 365 Business Central SaaS as a partner, in order to be able to access the customer tenant and administer it you need to set up delegated administrators.

To enable this, you need to perform the following two main steps:

1. set up users in your own tenant in Partner Center by setting the Assists your customers as a field with the relevant role for this user to be able to login into your customers’ Business Central environments as either Admin agent or Helpdesk agent.
2. Requesting a reseller relationship with a customer and including delegated administration privileges for Azure Active Directory (Azure AD) and Office 365 in the requested email that will be sent to the customer.

When a customer grants the delegated administration privilege to a partner:

• The Admin Agent group is assigned to the Global Administrator role in the customer’s Azure AD tenant.
• The Helpdesk Agent group is assigned to the Helpdesk Administrator role in the customer’s Azure AD tenant.

When the relationship is established, you will be able to access the customer’s Business Central tenant with your partner account and without consuming the customer’s licenses.

Delegated administrators can access the Business Central application as admins, but with some small limitations on some features (see here).

What’s a possible security problem here? I can see two main problems:

1. The delegated admin privileges can give you access as Global Admin to your customer tenants and so if you are compromised (alias hacked) also your customers could be affected.
2. The relationship timeline is indefinite (it lives until the customer revokes it).

These two aspects could be a potential security risk.

This is why Microsoft has recently launched the new Granular Delegated Administrator privileges (GDAP).

With GDAP you can set up custom access roles with custom relationship timelines (maximum of 2 years, after that it must be renewed) by accepting a relationship from a customer-specific link. All GDAP related operations are logged into the Azure AD Activity logs for traceability.

With GDAP you can create security groups with specific roles:

And all activities of your GDAP users are logged:

Please remember that GDAP will replace delegated administrators in the near future.

For more information about GDAP and how to set up them, please refer to my article here.

Azure AD Conditional Access

Another interesting security feature that you can adopt is Azure Active Directory Conditional Access. In simple words, a Conditional Access policy is an if-then statement of Assignments and Access controls and you can specify them starting from the Azure Portal under Azure Active Directory > Security > Conditional Access.

You can have a pre-defined set of templates for creating access policies, like for example location-based policies (you can define the locations of the users that are allowed to access your tenant):

Or you can also have policies for blocking access to all apps in an azure AD tenant except for a particular app if users are not on a trusted network (see here an example).

When you create a conditional access policy, you can select Dynamics 365 Business Central as cloud apps to protect:

and then specifying an access policy for it (for example, MFA required):

NOTE: Using this feature requires an Azure AD Premium P1 license.

These are only some inputs that you can immediately adopt in order to enhance the level of the security of your Dynamics 365 Business Central SaaS tenant.

There are obviously other aspects that you could consider. For example, if users in your company use Power Automate to interact with Business Central, please be aware that it could be a potential risk if you don’t protect your flows or if you don’t use tenant isolation (I will talk a bit about this new feature at the upcoming DynamicsCon conference if you will be at my “Low code workflows for Dynamics 365 Business Central” session). Please also protect your Azure Functions or HTTP-triggered flows that you have in place.

More generally speaking, please remember that the security of your Business Central tenant is mainly handled by Microsoft, but there are other aspects where you should be the master.

Stay tuned, you’re not alone in a cloud world…