TUDS Azure TLS Endpoint Customer FAQ

This FAQ is written for customer admins, IT contacts, and implementation teams who want a clear explanation of the Azure Bridge connection model, what TUDS hosts, what remains customer-controlled, and what setup looks like in practice.

What is the Azure TLS endpoint?

The Azure TLS endpoint is Azure Bridge — the TUDS-hosted Azure connection path for approved Vista SQL workflows.

TUDS hosts the connection layer in Azure. Customers configure the connection in Mission Control → Team Settings → Connectors → Azure Bridge and do not install, expose, or maintain bridge or tray software in their own environment.

What is the final Azure architecture?

The final structure is:

TUDS API -> Azure Front Door Premium + WAF -> private Azure TLS relay -> private SQL execution/admin services -> Azure Key Vault and customer SQL Server

Azure Front Door Premium with Web Application Firewall is the only public Azure edge for this path. The relay App Service, SQL execution service, and credential-admin service are private and are not intended to be directly reachable from the public internet.

What is public versus private in this architecture?

The public component is Azure Front Door Premium with WAF. It is the public HTTPS edge for Azure TLS traffic.

The private components are the Azure TLS relay, the SQL execution service, and the credential-management service. Direct public access to those App Services is blocked.

Does this expose SQL Server directly to the internet?

No. The customer's SQL Server is not the public integration point.

TUDS traffic reaches Azure Front Door first. From there, approved traffic is routed to a private relay and then to private Azure services. The private SQL execution service is the component that connects to SQL Server using the configured credentials.

What does Azure Front Door and WAF do?

Azure Front Door Premium is the public edge for the service. It provides the public HTTPS entry point and routes traffic to the private relay through a private origin path.

The Web Application Firewall adds managed-rule protection at the public edge before traffic reaches the private relay. It helps detect and block common web attack patterns and gives TUDS a central place to monitor public-edge security events.

Is Azure Front Door Premium + WAF considered a strong security choice?

Yes. Azure Front Door Premium with Web Application Firewall is generally considered an enterprise-grade, top-tier cloud edge and WAF option in the market.

It is a Microsoft-managed global edge service used for production internet-facing applications, comparable in role to other major cloud-provider edge and WAF offerings. In the Azure TLS model, TUDS uses it as the only public edge while keeping the relay, SQL execution service, and credential-management service private behind it.

What exactly does the private relay do?

The relay is a narrow private routing and validation layer for approved Azure TLS traffic.

The relay:

• receives traffic only after it passes through Azure Front Door
• validates the TUDS-issued request before forwarding it
• allows only explicitly approved methods and routes
• forwards SQL execution traffic to the private SQL service
• forwards credential-management traffic to the private admin service
• rejects requests outside the approved route surface
• does not execute SQL itself
• does not store SQL credentials
• does not read secrets directly from Azure Key Vault

What do the private services do?

The Azure TLS model uses private services behind the private relay.

One private service handles the database-facing work. It loads the SQL credential from Azure Key Vault, connects to SQL Server, and carries out the approved SQL-backed operations needed for enabled TUDS workflows.

A separate private admin service handles credential-management tasks such as secure updates and deletion.

Where are SQL credentials stored?

SQL credentials are stored in Azure Key Vault, not in Front Door and not in the relay.

That keeps the public edge and relay separated from database passwords. The credential is retrieved only by the private service that needs it for approved work.

Does the relay have SQL credentials?

No. The relay is designed so it does not store secrets.

It does not keep the SQL username or password and does not act as the database client. That work happens only in the private SQL service after the request has passed the Front Door and relay checks.

How is access secured?

Access is secured in layers rather than through a single control.

In plain terms, the model uses HTTPS, Azure Front Door Premium, WAF protection, a private relay origin, TUDS-issued request validation at the relay, an explicit allowlist of approved relay routes, rejection of everything outside that approved surface, private Azure services that are not publicly reachable, and protected credential storage in Azure Key Vault.

That means the public entry point is not a public SQL endpoint and is not a public relay App Service. It is a controlled Azure Front Door edge that filters traffic before any private service work is allowed to happen.

Can someone bypass Front Door and call the relay directly?

Direct public relay access is blocked. The relay App Service is private and is intended to be reached through the Azure Front Door private origin path only.

The SQL execution and credential-admin services are also private, so they are not exposed as public customer-facing endpoints.

How does TUDS handle forwarded client IPs safely?

The relay trusts forwarded client IP information only when the request arrives through the configured Azure Front Door identity.

This prevents a direct public caller from simply adding forwarded headers and making the relay treat those headers as trusted. In the final structure, direct public relay access is blocked and trusted forwarded-client-IP handling is tied to the real Front Door path.

Why are the relay and private services kept private?

The relay and private Azure services are not directly exposed to the public internet.

Azure Front Door and WAF become the controlled public edge, while the relay and private Azure services stay behind that edge.

What does TUDS host and manage?

In this model, TUDS hosts and manages Azure Front Door Premium, WAF, the private Azure TLS relay, the private SQL execution service, the private credential-admin service, monitoring, and the Azure Key Vault integration used by those services.

TUDS also manages the shared routing for this connection model through a common Azure TLS entry point rather than separate public URLs for each team.

What remains customer-controlled?

The customer still controls the SQL Server, the SQL account, the allowed workflows, and the network approval needed for the SQL connection path.

Customers also continue to control their own database permissions and can require least-privilege SQL access for the TUDS-supported workflows.

What are the main benefits of this model?

The main benefits are operational simplicity, a narrower public exposure model, and less customer-managed infrastructure.

• TUDS hosts the entire Azure connection layer — no customer-side bridge or tray installation
• Azure Front Door Premium + WAF is the only public Azure edge for this path
• the relay, SQL execution service, and credential-management service remain private
• SQL credentials are stored in Azure Key Vault rather than in the public-facing layer
• the relay validates and route-filters requests before private service work is performed
• TUDS manages connection-layer hosting, monitoring, and operations

How would this impact our usage of TUDS?

For most end users, day-to-day usage of TUDS should not change in a major way.

The main impact is on how the SQL-backed connection is hosted and supported behind the scenes, not on how users normally work in the platform. Customers configure Azure Bridge in Team Settings, provide SQL connection details, approve the connection path, and control database permissions while TUDS manages the hosted Azure connection layer.

From an implementation and support standpoint, setup and troubleshooting stay in TUDS because the connection path is TUDS-hosted and centrally monitored.

Is this a per-team public endpoint model?

No. This is not a per-team public URL model.

TUDS uses a shared Azure TLS entry point for this traffic. Team-specific connection details are handled behind that shared entry point rather than by giving each team its own public connection address.

What does customer IT need to provide?

Before setup, customer IT should be prepared to provide:

• the SQL Server or TLS endpoint host
• the SQL Server port
• the database name
• the SQL username and password
• any required customer-side network approvals or allowlisting steps
• confirmation that the SQL account has the right level of access for the agreed workflows

What does setup look like at a high level?

The normal setup flow is:

1. Open Mission Control → Team Settings → Connectors → Azure Bridge.
2. Customer IT provides the SQL connection details and any required network approvals.
3. TUDS saves the connection details through the private credential-management path.
4. The SQL credential is stored securely in Azure Key Vault.
5. TUDS runs connection testing through the Azure TLS path.
6. TUDS and the customer validate at least one real workflow successfully.

How do we validate that setup is complete?

Setup should not be considered complete until all of the following are true:

• the TUDS-managed Azure connection services are healthy
• Front Door can reach the private relay successfully
• direct public access to the private Azure services remains blocked
• the credential was stored successfully
• the connection test succeeds
• at least one real workflow succeeds end to end
• logs do not show a blocking network, credential, or SQL permission error

What kinds of workflows are supported?

The Azure TLS endpoint model is intended to support the approved TUDS SQL-backed workflows for a customer, not just a basic connectivity check.

Examples can include metadata lookups, reporting-related queries, and other approved SQL-backed operations required by enabled TUDS features.

What if Front Door is healthy but a workflow still fails?

That usually means the public edge is up, but something deeper in the connection path still needs attention.

Common causes include an issue in a private Azure service, a secure credential access problem, incorrect SQL connection details, missing customer-side network approval, or SQL permissions that do not match the workflow being attempted.

How does TUDS monitor this path?

TUDS monitors the Azure TLS path through Azure diagnostics, Log Analytics, and alerting for important failure and drift signals.

Examples include Front Door health, WAF activity, App Service server errors, direct public access boundaries, and configuration changes that could affect the intended private topology.

Who usually owns troubleshooting?

Troubleshooting is usually shared between TUDS and the customer IT team.

In general:

• TUDS typically owns Azure Front Door, WAF, the private relay, the private Azure services, Key Vault integration, monitoring, and the application-side workflow behavior
• customer IT typically owns the target SQL environment, the SQL account, and any customer-side approval or allowlisting requirements
• some issues still require joint troubleshooting because the full path crosses both environments

What should customer IT know before approving this model?

The key points are:

• SQL Server is not directly exposed to the internet by this model
• Azure Front Door Premium + WAF is the only public Azure edge for the Azure TLS path
• the relay App Service is private and direct public relay access is blocked
• the SQL execution service is private
• the credential-management service is private
• the relay validates TUDS-issued requests before forwarding them
• the relay only exposes explicitly approved methods and routes
• the relay does not store SQL credentials
• the relay does not read secrets directly from Azure Key Vault
• SQL credentials are stored in Azure Key Vault and retrieved by the private SQL service
• customers still control the SQL environment and database permissions

What is the simplest way to explain this model to a customer?

Use this:

Azure Bridge is a TUDS-hosted Azure connection path with Azure Front Door Premium + WAF as the only public edge and private services behind it. The private relay accepts only approved TUDS traffic from Front Door, does not hold SQL credentials, and does not connect to SQL Server directly. The actual SQL execution and credential-management work happens only in private Azure services, so TUDS can run approved SQL-backed workflows without exposing the customer's SQL Server directly to the internet.