Securing ILAP Analytics — reference example

This page describes an example of how the Azure resources created by the ILAP Analytics installation can be protected — network isolation with private endpoints, an optional web application firewall, controlled egress, monitoring, and the Entra ID controls that limit who can sign in and from which devices. A matching, deployable Bicep template ships in the deployment package under Azure.IaC/Reference-Security/. It is written for the IT administrator hardening an ILAP Analytics environment. Because ILAP Analytics may hold sensitive scheduling information, protection matters — but the right design is specific to each organisation.

This is an example only. It is not a finished, production-ready configuration and not a security guarantee. Each company is responsible for how protection is done and will have its own requirements. Review, adapt, and test everything here, and add whatever additional controls your policies require. The Bicep is provided as a starting point, not a turnkey solution.

Install first, then secure

Deploy ILAP Analytics in its default (publicly reachable) configuration and verify it with the Checklist after deployment before applying any of the protection below. Locking down the network first makes failures much harder to diagnose; a verified baseline isolates installation problems from lock-down problems.

What the reference protects, and how

Reaching the apps when there is no corporate network yet

Private endpoints mean the apps have no public URL, so something must connect you into the VNet. If you already have a corporate network / VPN / ExpressRoute, use it. If you are still building and testing and do not have one, the reference includes an optional Tailscale subnet router (a small VM, deployed only when deployTestAccess = true) that lets developers reach the private resources from any office. An Azure point-to-site VPN Gateway is the Azure-native alternative. Turn the test-access option off for a real corporate deployment.

Full setup steps (approving the subnet route, split DNS for the private-endpoint names) are in the Azure.IaC/Reference-Security/README.md.

Troubleshooting connectivity

Once public access is disabled, the apps reach SQL, Storage, Key Vault, the IDE / ILAP Data Exchange API, the Timephasing API, and DNS only over the private path — so a missing private DNS record, an unapproved private endpoint, or missing VNet integration will break one or more of those lines (and can also make the app unreachable over SSH). The deployment package ships a troubleshooting guide and diagnostic scripts under Azure.IaC/Reference-Security/ for exactly this:

• TROUBLESHOOTING.md — a symptom → cause → verify → fix guide covering every communication line, an "if you cannot SSH in" path, and how to recover an app that was locked down before its private path was verified.
• Scripts/diagnose-connectivity.sh — run inside the API or Background Jobs container over SSH to test every line live.
• Scripts/diagnose-connectivity.azcli / .ps1 — run from an admin machine; needs no SSH, so it works even when the environment is fully locked down. Start here — it usually pinpoints the missing private endpoint, DNS record, or VNet integration on its own.
• Scripts/connectivity-queries.kql — Log Analytics queries for reading failures after the fact.

Verify before you lock down. Disabling public network access on an environment whose private path is not yet working strands the apps from their dependencies and from SSH. Confirm connectivity first (the scripts above go green), then run harden-public-access.

Limiting the number of users who can sign in

Entra ID does not cap sign-ins by a number. You enforce it by requiring user assignment on the API enterprise application and assigning only a specific group — the "number" is the group membership you manage. This is a one-line change (appRoleAssignmentRequired = true on the service principal) plus assigning your allowed group; see the README and Application Registrations / User Permissions.

Allowing only known devices (and requiring MFA)

Restricting access to known/managed devices is done with Conditional Access — an Entra ID control, not part of the Bicep. Create a policy scoped to the ILAP Analytics apps that requires multi-factor authentication and a compliant device (managed by Intune) or a Hybrid Entra joined device, optionally only from your trusted network locations. Always exclude two break-glass accounts so a misconfigured policy cannot lock everyone out, and roll it out in report-only mode first.

Conditional Access and device compliance require Entra ID P1 (P2 for risk-based policies) and Intune (or Hybrid Entra join). Confirm your licensing before relying on these controls.

Did we miss anything? (recommended additions)

Beyond your stated requirements, the reference also recommends: MFA (pairs with the device policy), locking down the data plane (SQL/Storage/Key Vault), keeping egress to the IDE API / time-phasing / Entra working, Key Vault hardening (RBAC, soft-delete, purge protection), monitoring/auditing (Log Analytics, SQL auditing, Defender), and break-glass accounts. Cost-heavy options (Application Gateway, Azure Firewall, Bastion, Defender, DDoS) are left as toggles you enable per environment.

Next steps

Use the template and detailed steps under Azure.IaC/Reference-Security/ (see its README.md). For the original high-level checklist, see Securing ILAP Analytics; for the overall install flow and permissions, see the Installation Overview.