Bearbeiten

Freigeben über

Security Guide: How to Secure Business Central

This guide provides scenario-based security recommendations organized by persona. Each best practice includes context, solution, guidance, benefits, and trade-offs to help you make informed security decisions.

Partner scenarios

Ensure consultants don't have persistent access to all customers you manage

Context and problem:
Partners managing multiple customers through GDAP (Granular Delegated Admin Privileges) face a security risk when consultants have persistent, always-on administrative access to customer environments. A compromised consultant account could lead to unauthorized access across all customers. Compliance requirements and customer trust demand minimizing standing privileges.

Solution:
Implement time-bound privileged access using Microsoft Entra ID Privileged Identity Management (PIM) combined with granular delegated admin privileges (GDAP) group-based access control.

Learn more in Microsoft Entra Privileged Identity Management and Granular delegated admin privileges.

Guidance:

  1. Set up GDAP with groups:

    1. In your partner's Microsoft Entra ID tenant, create one security group per customer you have a GDAP relationship with (for example, GDAP-CustomerA-Admins, GDAP-CustomerB-Admins). Learn more in Manage Microsoft Entra groups and group membership.

      Don't directly assign consultants to these groups permanently.

    2. Establish the GDAP relationship with each customer, linking the relevant security group to the appropriate Microsoft Entra roles. Learn more in Manage Microsoft Entra groups and group membership.

  2. Configure PIM for time-bound access:

    1. Enable Microsoft Entra ID Privileged Identity Management (requires Microsoft Entra ID P2 or Microsoft Entra ID Governance license). Learn more in Start using Privileged Identity Management.
    2. Make the GDAP customer groups eligible for activation in PIM rather than permanently assigned. Learn more in Assign eligibility for a group in Privileged Identity Management.
    3. Configure activation requirements (for example, justification, approval workflow, maximum duration).
    4. Set appropriate activation duration limits (for example, 4-8 hours).

Consultant workflow: Here's the workflow for consultants when PIM is configured:

  • When a consultant needs to work on a specific customer, they request activation of the relevant customer group in PIM.
  • They provide business justification (for example, ticket number, task description).
  • Access is granted for the specified time window only.
  • Access automatically expires after the configured duration.

Benefits:

  • Reduced attack surface: Compromised credentials have limited blast radius and time window
  • Audit trail: Complete logging of who accessed what customer, when, and why
  • Compliance: Meets regulatory requirements for just-in-time access and least privilege
  • Customer trust: Demonstrates commitment to security best practices
  • Competitive advantage: Can be marketed as a security differentiator

Trade-offs:

  • Licensing cost: Requires Microsoft Entra ID P2 or Governance licenses
  • Initial setup complexity: Requires configuring PIM and GDAP groups for each customer
  • User friction: Consultants must request access before working, adding 1-5 minutes overhead
  • Administrative overhead: Might require approval workflows and monitoring

Secure API access for automation tools you build for customers

Context and problem:
Partners often build automation tools, integrations, or monitoring solutions that need to call Business Central APIs across multiple customer tenants. Using personal admin accounts or long-lived secrets creates security risks and operational fragility.

Solution:
Use managed identities with Federated Identity Credentials (FIC) when running in Azure, or implement secure credential management for non-Azure scenarios.

Learn more in Business Central Administration Center API, Automation APIs, and What are managed identities for Azure resources?.

Guidance:

If running in Azure (recommended):

  1. Deploy your automation as an Azure resource (Function App, Logic App, or Azure Container Instance). Learn more in Azure Functions, Azure Logic Apps, or Azure Container Instances.
  2. Enable system-assigned or user-assigned managed identity on the Azure resource. Learn more in How to manage user-assigned managed identities.
  3. Register an app in your partner's Microsoft Entra ID. Learn more in Register an application with the Microsoft identity platform.
  4. Configure Federated Identity Credential on the app registration, linking it to the Azure resource's managed identity. Learn more in Configure an application to trust a managed identity and Workload identity federation.
  5. Grant consent to the app in customer tenants as a partner or direct as a customer. Learn more in Manage Access to Environments.

Your code acquires tokens automatically using the managed identity—no secrets to manage. Learn more in Access token request with a federated credential.

If not running in Azure:

  1. Create a dedicated app registration per integration/tool. Learn more in Register an application with the Microsoft identity platform.

  2. Use certificate-based authentication instead of client secrets. Learn more in Microsoft identity platform application authentication certificate credentials.

  3. Store certificates securely in Azure Key Vault or hardware security modules. Learn more in About Azure Key Vault certificates.

  4. Implement certificate rotation procedures (every 12 months minimum). Learn more in Automate the rotation of a secret for resources that have two sets of authentication credentials.

    Use separate credentials per customer environment when possible.

  5. Monitor API usage through telemetry. Learn more in Monitoring and Analyzing Telemetry.

Benefits:

  • No credential theft risk (managed identity scenario)
  • Fine-grained access control per customer
  • Complete audit trail of API calls
  • Compliance with zero-trust principles

Trade-offs:

  • Azure dependency for optimal security (managed identities)
  • Complexity in multitenant scenarios
  • Learning curve for FIC and managed identity concepts
  • Cost of Azure resources (minimal—Function Apps can run on consumption plan)

Administrator scenarios

Restrict access to externals services from Business Central calls

Context and problem:

Your Business Central environment (AppSource apps or per-tenant extensions) calls external services (APIs, Azure Storage, databases). You want to ensure only legitimate traffic from Business Central reaches these services. Business Central is an online (SaaS) solution where environments are regularly rebalanced and upgraded across application services with changing IP addresses. So you need a solution that works with Business Central's dynamic infrastructure.

Solution:
Use Azure service tags and network access controls to create allow lists based on Business Central's IP ranges.

Learn more in Use Azure security service tags and Azure service tags overview.

Guidance:

Scenario A: Destination service supports service tags natively
(only Azure functions or web apps (in Azure App Services) support service tags natively in firewall rules)

  1. Navigate to your Azure resource's networking settings.
  2. Configure firewall rules or network access controls.
  3. Add a rule allowing traffic from the Dynamics365BusinessCentral service tag.
  4. Remove any overly permissive rules (for example, "Allow all Azure services").

Scenario B: Destination is Azure Storage Account
(Special case due to internal routing)

  1. Create an Azure Function as a proxy in the same region as Business Central.
  2. Restrict Azure Function access using service tag-based access restriction: allow Dynamics365BusinessCentral.
  3. Create a private endpoint or virtual network integration from Azure Function to Storage Account.
  4. Configure your Business Central extension to call the Azure Function instead of Storage directly.
  5. Azure Function proxies requests to Storage Account.

Scenario C: Destination supports IP allowlisting only
(On-premises systems, non-Microsoft SaaS, custom APIs)

  1. Retrieve current Business Central IP ranges:

    $serviceTags = Get-AzNetworkServiceTag -Location eastus2
$bcTag = $serviceTags.Values | Where-Object { $_.Name -eq "Dynamics365BusinessCentral" }
$bcTag.Properties.AddressPrefixes

  2. Configure firewall/network rules on destination to allow these IP ranges.

  3. Monitor the ChangeNumber property and update rules when Microsoft updates the ranges.

  4. Consider automating updates using Azure Automation or scheduled scripts.

Benefits:

  • Prevents unauthorized access from non-Business Central sources
  • Reduces attack surface significantly
  • Compliance with network segmentation requirements

Trade-offs:

  • No per-environment granularity: Service tag includes all Business Central environments globally
  • Maintenance overhead: IP ranges change over time (though infrequently)
  • Proxy complexity: Storage Account scenario requires extra Azure Function
  • Regional limitations: Must be in supported Azure regions for some scenarios

Monitor and respond to suspicious sign-in attempts

Context and problem: Attackers might attempt credential stuffing, password spraying, or brute-force attacks against your Business Central users. Integration accounts might use incorrect credentials. You need visibility into authentication failures to detect threats early and respond appropriately.

Solution:
Implement comprehensive monitoring of authentication events using Microsoft Entra sign-in logs and Business Central telemetry.

Learn more in Monitoring and Analyzing Telemetry and Sign-in logs in Microsoft Entra ID.

Guidance:

  1. Set up Microsoft Entra ID sign-in logging:

    1. In Microsoft Entra admin center, open the Sign-in Logs. Learn more in View logs through the Microsoft Entra admin center.

    2. Configure diagnostic settings to route logs to:

  2. Create alert rules for suspicious patterns:

    • Multiple failed sign-ins: Alert when user has >5 failures in 10 minutes
    • Impossible travel: Alert when sign-ins occur from geographically distant locations within short timeframes
    • Unfamiliar locations: Alert when sign-ins come from countries/regions where you don't operate
    • Disabled accounts: Alert on any authentication attempt to disabled accounts

    Learn more in Create alert rules.

    Sample KQL query for Log Analytics:

    SigninLogs
| where AppDisplayName contains "Business Central"
| where ResultType != 0  // Failed sign-ins
| summarize FailureCount=count() by UserPrincipalName, IPAddress, bin(TimeGenerated, 10m)
| where FailureCount > 5

  3. Monitor Business Central telemetry:

    1. Enable Business Central telemetry to Azure Application Insights. Learn more in Turn environment telemetry on or off.
    2. Monitor authorization failures and permission errors and API authentication failures for service accounts. Learn more in Authorization trace telemetry Permission errors trace telemetry, and Web Services telemetry.

  4. Establish response procedures:

    • Investigate high-priority alerts within 1 hour
    • For confirmed attacks: Reset credentials, enable Conditional Access if not already active
    • For integration failures: Check service principal certificates/secrets expiration
    • Document incidents for trend analysis

Benefits:

  • Early threat detection before damage occurs
  • Forensic capability for security incidents
  • Operational insights (for example, expiring integration credentials)
  • Compliance evidence for audit requirements
  • Reduced MTTR (mean time to respond)

Trade-offs:

  • Alert fatigue: Too many alerts can desensitize teams
  • Cost: Log Analytics charges based on data ingestion and retention
  • Expertise required: Creating effective KQL queries requires learning curve
  • False positives: Legitimate scenarios (for example, VPN users) might trigger alerts

Enforce multifactor authentication for all users

Context and problem: Password-only authentication is vulnerable to phishing, credential theft, and account takeover. Regulatory requirements and security best practices mandate multifactor authentication (MFA), but enabling it requires balancing security with user experience.

Solution:
Implement Microsoft Entra Conditional Access policies to require MFA for Business Central access with modern authentication methods.

Learn more in Setting up Multifactor Authentication for Business Central, Conditional Access overview, and Authentication and Credential Types.

Guidance:

  1. Assess current authentication methods:

    • Review authentication methods report in Microsoft Entra ID.
    • Identify users still using SMS/voice call (less secure).
    • Plan migration to Microsoft Authenticator app or FIDO2 security keys.

  2. Configure Conditional Access policy:

    1. In Microsoft Entra admin center, navigate to Protection > Conditional Access.

    2. Create new policy. Learn more in Create a Conditional Access policy.

    3. Set assignments:

      • Users: Include "All users" or specific Business Central user groups
      • Target Resources: Select "Dynamics 365 Business Central". Learn more Conditional Access: Target resources
      • Access controls: Grant access, but require multifactor authentication
      • Session controls: Consider sign-in frequency (for example, require reauth every seven days)

  3. Enable modern authentication methods:

    Learn more in Manage authentication methods for Microsoft Entra ID.

  4. Plan rollout:

    • Phase 1 (report-only mode): Monitor impact without enforcing.
    • Phase 2 (pilot group): Enable for IT and early adopters.
    • Phase 3 (broad deployment): Roll out to all users with communication plan.
    • Provide user training and help desk preparation.

  5. Handle service accounts:

Benefits:

  • Reduction in account compromise risk
  • Compliance with regulations
  • User trust in platform security
  • Passwordless future: Foundation for eliminating passwords entirely
  • Conditional flexibility: Can exempt trusted locations if needed

Trade-offs:

  • User friction: Extra authentication step at sign-in
  • Support burden: Initial increase in help desk calls during rollout
  • License requirements: Conditional Access requires Microsoft Entra ID P1 minimum
  • Legacy app challenges: Some integrations might not support modern auth
  • Offline scenarios: Users need device access for authenticator app

Important

Introducing new CA policies prompts users to reauthenticate. Plan changes during maintenance windows and communicate clearly to minimize disruption. Update background job credentials and service accounts before enforcement.

Implement separation of duties for financial transactions

Context and problem:
A single user with unrestricted access can create fraudulent transactions, approve their own payments, or modify critical master data without oversight. Regulatory frameworks (SOX, internal controls) require separation of duties to prevent fraud and errors.

Solution:
Implement Business Central's Approval Workflows combined with role-based permissions to enforce multi-person authorization for sensitive operations.

Learn more in Assign Permissions to Users and Groups and Use Approval Workflows.

Guidance:

  1. Identify sensitive operations requiring approval:

    • Payment journals exceeding threshold (for example, >$10,000)
    • Vendor master data changes (bank account modifications)
    • User permission changes or role assignments
    • Fixed asset disposals
    • Inventory adjustments above threshold
    • Customer credit limit increases

  2. Configure Approval Workflows:

    • In Business Central, go to Workflows.
    • Create approval workflow for each sensitive operation type.
    • Define approval hierarchy (for example, manager approval, finance director for large amounts).
    • Set threshold amounts where applicable.
    • Configure notifications (email, in-app).
    • Enable delegation for approver absence scenarios.

    Learn more in Use Approval Workflows.

  3. Design segregated permission sets:

    • Requester role: Can create payment journals but can't post
    • Approver role: Can approve but can't create their own requests
    • Posting role: Can only post preapproved transactions
    • Ensure no single user has all three capabilities
    • Use security groups for easier management

    Learn more in Assign Permissions to Users and Groups.

  4. Implement audit logging:

    • Monitor sensitive fields tables (like Vendor Bank Account or company's IBAN number). Learn more in Monitor sensitive fields
    • Monitor approval workflow telemetry.
    • Regular review of who approved what (monthly reconciliation).

  5. Handle exceptions:

Benefits:

  • Fraud prevention: Reduces risk of unauthorized transactions by 80%+ (industry data)
  • Error reduction: Second review catches mistakes before posting
  • Regulatory compliance: Meets SOX, GDPR accountability requirements
  • Audit trail: Complete history of approval decisions
  • Cultural impact: Reinforces accountability and control consciousness

Trade-offs:

  • Process delays: Approvals add time to transaction completion (hours to days)
  • User resistance: Perceived as bureaucratic or lack of trust
  • Complex setup: Requires careful workflow design and testing
  • Approver availability: Vacation/absence can block operations (mitigate with delegation)
  • Overhead for small transactions: Might need threshold-based rules

Best practice:
Start with high-risk, high-value transactions only. Expand separation of duties gradually based on risk assessment and user feedback. Balance control with operational efficiency.

Developer scenarios

Secure API calls from your Business Central extension to external services

Context and problem:
Your extension needs to call external APIs (payment gateways, shipping providers, tax services) and requires credentials or API keys. Hardcoding secrets in code or storing them in plain text creates severe security vulnerabilities.

Solution:
Use Azure Key Vault for secret storage, accessed via secure authentication patterns from AL code.

Learn more in What is Azure Key Vault? and HttpClient Data Type.

Guidance:

  1. Set up Azure Key Vault:

  2. Access from Business Central:

  3. AL code pattern: Use AL HttpClient data type with certificate authentication.

    Note

    The following example is conceptual and shows the general pattern. For complete implementation details including OAuth token acquisition, certificate management, and error handling, see Azure Key Vault REST API and HttpClient.AddCertificate Method.

    local procedure GetApiKey(): Text
var
    Client: HttpClient;
    Headers: HttpHeaders;
    Response: HttpResponseMessage;
    Certificate: SecretText;
    AccessToken: SecretText;
    KeyVaultUrl: Text;
begin
    // Retrieve certificate from Azure Key Vault
    Certificate := GetCertificateFromKeyVault();

    // Add certificate for authentication
    Client.AddCertificate(Certificate);

    // Acquire OAuth token using certificate (implementation required)
    AccessToken := AcquireTokenWithCertificate();

    // Add authorization header
    Client.DefaultRequestHeaders(Headers);
    Headers.Add('Authorization', SecretStrSubstNo('Bearer %1', AccessToken));

    KeyVaultUrl := 'https://mykeyvault.vault.azure.net/secrets/api-key?api-version=7.3';

    if not Client.Get(KeyVaultUrl, Response) then
        Error('Failed to retrieve secret from Key Vault');

    // Parse JSON response and return secret value (implementation required)
    exit(ParseSecretFromResponse(Response));
end;

  4. Implement secret rotation:

    • Rotate secrets every 90 days minimum.
    • Use Key Vault secret versions.
    • Update references in Business Central setup tables without code changes.
    • Monitor Key Vault access using Business Central telemetry to track secret retrieval patterns and troubleshoot failures. Learn more in App Key Vault Secrets Telemetry.

Benefits:

  • Centralized secret management: Single source of truth
  • No secrets in code: Source control remains clean
  • Audit trail: All secret access logged
  • Rotation without deployment: Update secrets without recompiling extension
  • Compliance: Meets encryption key management standards

Trade-offs:

  • Azure dependency: Requires Azure subscription
  • Latency: Extra network call to Key Vault (cache appropriately)
  • Complexity: More complex than hardcoded values
  • Cost: Key Vault operations are metered
  • Error handling: Need robust retry logic for Key Vault unavailability

Auditor scenarios

Verify that appropriate security controls are in place

Context and problem:
As an auditor (internal or external), you need to verify that Business Central deployments meet security standards, compliance requirements, and internal policies. Manual verification is time-consuming and incomplete.

Solution:
Use a checklist-based approach combining automated queries and manual verification procedures.

Learn more in Security and Protection, Business Central Online Security, and Microsoft Dynamics 365 Cloud Services Compliance.

Guidance:

Authentication controls verification:

  1. Confirm MFA is enforced:

    • Review Microsoft Entra Conditional Access policies.
    • Verify "Require MFA" is enabled for Business Central app.
    • Check for exemptions or exclusions (should be minimal/none).
    • Sample authentication logs to confirm MFA claims in tokens.

  2. Check for legacy authentication blocks:

    • Review sign-in logs for BasicAuth protocol usage.
    • Confirm Conditional Access blocks legacy auth protocols.
    • Verify no app passwords are enabled.

Authorization controls verification:

  1. Review separation of duties:

    • Export user permission sets.
    • Verify no user has both "Create Payment" and "Approve Payment".
    • Check approval workflow configurations.
    • Review override/emergency access logs.

  2. Audit privileged access:

    • List all users with SUPER permission set.
    • Verify justification for each (should be minimal).
    • Check if PIM is used for admin access (time-bound).
    • Review admin action logs.

    Learn more in Assign Permissions to Users and Groups.

Data protection verification:

  1. Confirm encryption at rest:

    • Verify TDE is enabled on database (online: automatic; on-premises: check SQL Server).
    • For on-premises: Confirm backup encryption enabled.
    • Check for customer-managed key (CMK) if required by policy.

    Learn more in Transparent Data Encryption and Data Encryption at Rest.

  2. Verify network encryption:

    • Confirm HTTPS/TLS 1.2+ for all client connections.
    • Check certificate validity and strength.
    • Review network service tag configurations.

    Learn more in Using Security Certificates with Business Central on-premises.

Monitoring and detection:

  1. Verify logging is enabled:

    • Confirm Microsoft Entra sign-in logs retention (90+ days).
    • Verify Business Central telemetry is flowing to Application Insights.
    • Check change log is enabled for sensitive tables.
    • Review alert configurations.

  2. Test incident response:

    • Verify security runbooks exist.
    • Confirm contact procedures are documented.
    • Review past security incident reports.

Compliance artifacts:

  1. Collect evidence:

    • Export Conditional Access policies (JSON).
    • Screenshot approval workflow configurations.
    • Export user permission reports with dates.
    • Collect security alert reports from last quarter.

  2. Document findings:

    • Use standardized control testing templates.
    • Rate controls: Effective / Needs Improvement / Ineffective.
    • Provide remediation recommendations with priority.

Benefits:

  • Standardized assessment: Consistent audit approach
  • Evidence-based: Objective verification vs. self-attestation
  • Comprehensive coverage: Technical and process controls
  • Remediation roadmap: Clear action items from audit

Trade-offs:

  • Technical expertise required: Auditor needs Azure/Business Central knowledge
  • Time investment: Thorough audit takes 8-16 hours per environment
  • Access requirements: Needs elevated privileges to review all settings
  • Point-in-time: Snapshot of controls, not continuous assurance

Audit frequency recommendation:

  • External compliance audits: Annual (SOC 2, ISO 27001)
  • Internal security reviews: Quarterly
  • Privileged access review: Monthly
  • Automated control testing: Continuous (where possible)

Track and report on data access patterns

Context and problem:
For compliance and security investigations, you need to understand who accessed what data, when, and from where. Business Central doesn't enable comprehensive data access logging by default.

Solution:
Implement multi-layered audit logging using Business Central change log, sensistive field monitoring, database auditing, and telemetry.

Learn more in Auditing Changes in Business Central, Monitoring and Analyzing Telemetry, and Transparent Data Encryption.

Guidance:

  1. Enable Business Central change log and/or sensitive field monitoring.

Note

Change logging and sensitive field monitoring add overhead, which impacts performance. Sensitive field monitoring has significantly less performance impact than the change log feature, making it a recommended alternative.

Enable change logging:

  1. In Business Central, go to Change Log Setup.

  2. Enable change logging for sensitive tables:

    • Customer, Vendor, Bank Account
    • G/L Entry, Customer Ledger Entry, Vendor Ledger Entry
    • User, User Group, Permission Set

  3. Select fields to track: All fields versus critical fields only.

Enable sensitive field monitoring:

  1. In Business Central, go to Monitor Field Change Setup.
  2. Specify the fields that you want to monitor based on filter criteria, such as the data sensitivity classification for the fields.
  3. After you finish the guide, you can manage settings for field monitoring on the Field Monitoring Setup page.

Learn more in Auditing Changes in Business Central.

  1. Configure SQL Server Auditing (on-premises). Learn more in Create a Server Audit and Server Audit Specification.

  2. Use Business Central telemetry (online):

    1. Enable environment telemetry to Application Insights. Learn more in Turn environment telemetry on or off.
    2. Monitor custom telemetry events:

  3. Create access reports using KQL queries in Application Insights:

    • Daily access summary:

      • Who accessed which companies
      • Failed permission checks
      • After-hours access (outside 7am-7pm)

    • Sensitive data access:

      • Bank account field reads
      • Salary information views
      • Customer credit card data (if stored)

    Learn more in Kusto Query Language (KQL) overview and Create a report in Business Central.

  4. Retention and archival:

    • Change log: Archive monthly to separate table and retain 13 months.
    • SQL Audit files: Retain 90 days active, 7 years archive.
    • Telemetry: Application Insights defaults 90 days. Export to storage for long-term.

Benefits:

  • Forensic capability: Investigate security incidents with complete history
  • Compliance evidence: Demonstrate data access controls for audits
  • Insider threat detection: Identify unusual access patterns
  • Performance insights: Identify inefficient data access

Trade-offs:

  • Performance impact: Logging adds 5-15% overhead depending on scope
  • Storage costs: Audit logs can be substantial (GB per month)
  • Analysis complexity: Raw logs require queries/tools to extract insights
  • Privacy considerations: Logging employee activity requires policy disclosure

Best practice for auditors:
Don't enable logging reactively after an incident. Implement comprehensive audit trails proactively. The data you didn't log yesterday can't be retrieved for today's investigation.

Security and protection
Business Central online security
Business Central on-premises security
Security tips for business users
Use Azure Service Tags
Setting up multifactor authentication
Manage access to environments

  • Last updated on