Skip to main content

Deploying an Application with a database on an Innovate Landing Zone

Use cases​

  • You are interested in exposing an application on Internet with security guarantees
  • You have opted for PaaS services to minimize your operating expenses
  • You don't want to use Kubernetes
  • Your application does not handle C3 data

Architecture schema​

Design description​

On top of an Innovate Landing Zone, an infrastructure to host an application accessible from the Internet.

The application will not be directly exposed to the Internet but will be behind an Application Gateway.

The application will consume various Azure managed PaaS services such as:

  • a PostgreSQL database
  • a Keyvault for storing application certificate and database credentials
  • a storage account for your application static files

Every service will be accessed through a private link rather than over the public network.

7-level security will be ensured by enabling Web Application Firewall on the Application gateway.

For a custom public DNS zone, a delegation needs to be requested through the Service desk portal by providing the NS entries of the created zone.

Constraints

Application gateway is the only component to be exposed on the Internet.

ComponentConstraint
PostgreSQL databasereachable by the application privately
Applicationreachable from Internet through a public gateway
Keyvaultreachable by the application privately
Storage accountreachable by the application privately

Application Gateway Public Frontend IP​

  • You should use Standard SKU Public IP, the policies coming along with Innovate Landing Zone won't allow you to choose Basic SKU. Standard SKU makes the use of Network Security Groups mandatory. For more details on Public IP Addresses, refer to Azure documentation here.

Related policy: TDF_NET-012_Block_SKU_Basic_Public_IP

While choosing this Standard SKU Public IP, you will have to choose the SKU of the Application Gateway accordingly that's to say WAF_V2 or Standard_V2.

Application Gateway​

  • When deploying the Azure Application Gateway (Deploy Azure Application Gateway), choose either WAF_V2 or Standard_V2.
  • From the Backend settings, select "https" as the Backend protocol. In "Trusted root certificate" section, the backends must be in the allowlist of the application gateway. Upload the public certificate of the backend servers to this Backend setting.

Application Service Identity​

For your application service to access Keyvault, you may want to use a managed identity (user or system)

Application Service​

  • In Diagnostic settings, configure for sending logs to the Log Analytics workspace of the Landing Zone.
  • To ease and secure access to the database connection string, you can store the corresponding Keyvault secret reference as a value of an application setting (or in specific cases as a value of a connection string). If you're unsure of the format, refer to Microsoft Azure reference documentation here. If you're unsure where to store it exactly, refer to this entry of Microsoft Azure reference documentation here
  • Create a Private endpoint for privately accessing the application service rather than over the public network.
  • Activate VNET integration to enable the application to access its database service without going through the public network. Scale the subnet size used for VNET integration coherently to the Application instances scalability nedes.
  • For complying to TDF_INI-001_App_Service policy, go to the https settings of the application service then enable https only enforcing TLS 1.2 as the minor TLS protocol.

Keyvault​

  • Access policies > Grant your Application Service access to your database credentials.
  • Network Access > Create a private endpoint integrated to a subnet that doesn't contain the Application Gateway.

Private DNS zones​

  • You must use an Azure DNS private zone as you can check here from the Azure Documentation.
  • When you use Private Endpoint for backend service (storage account, database, keyvault,...), you must also use a DNS private zone, refer to the Azure documentation above

Certificate management​

Refer to this page

PostgreSQL Server​

  • You need to select General Purpose or Memory Optimized pricing tier, depending on your needs, to be able to deny Public Network Access and comply to the security policies. Then, you will have to change "Deny public network access" to Yes.
  • the PostgreSQL server will only be accessed from the web app. To achieve this purpose, you'll have to create a Private endpoint connected to services dedicated subnet. Its subnet must belong to the VNET your application is connected to through VNET integration mentioned above or to a VNET peered with.
  • Enforce TLS 1.2 version as the minimum TLS version to comply the TDF_DBA-017_Enforce_PostgreSQL_TLS_Version policy.

NSGs​

  • TDF_VirtualNetwork_Audit_Subnets_without_NSG compliance will be achieved by creating NSG for each of the subnets.
  • TDF_NET-016_Allow_443_only_from_Internet compliance will be achieved by implementing NSG rules that block all inbound traffic from Internet unless the destination port is 443 (or 80). For other destination ports, you will have to provide in the NSG rules restricted IP ranges as the source.

Troubleshooting​

Consult Troubleshooting page