Wealth-Planning App — Infrastructure POC

Demonstrating the security controls (H-1 to H-5) for the wealth-planning application, on a working live deployment. Prepared for review by Group CEO.

What this page is. A live web application running on the actual infrastructure described below. The page you are reading is being served from Azure App Service. The numbers in the "Clients" table below were just fetched from a private PostgreSQL database that has no public network exposure. You are looking at proof, not a slide.

Live status

Database connection: connected over private VNet (SSL enforced)

App Service host: app-appsvc-poc-01-btf0a3h0hqehaeet.southeastasia-01.azurewebsites.net
Runtime: Python 3.12 on Linux (App Service Premium V3)
Server time (UTC): 2026-05-28T16:11:04

What was asked for (Shilpi's email, paraphrased)

Build the platform for the wealth-planning app — used by RMs, eventually holding real client data (residency, NRIC/PAN, beneficiary details). Five security controls were specified:

Status of each control

Control Status Evidence / Notes
H-1
Private Postgres + SSL		 ✓ Built PostgreSQL Flexible Server provisioned with VNet integration (private access only). No public endpoint exists. SSL required on every connection (sslmode=require in the connection string). The "Clients" table below is proof: this page just queried that server.
H-2
Key Vault + Fernet secret		 Next step Not yet built in this POC. Current DB credentials are stored as an App Service environment variable. Next refinement: provision Azure Key Vault, store the DB credential and a Fernet master key, switch the app setting to a Key Vault reference. Standard pattern, ~30 min of work, no architectural change.
H-3
Managed Identity + Entra DB auth		 Next step Not yet built. App Service supports system-assigned Managed Identity natively. Once enabled, the app connects to Postgres using its Azure identity rather than a stored password. Eliminates the credential entirely. Pairs with H-2 in the same refinement step.
H-4
Corporate-CA TLS certificate		 Next step Currently served on Azure's default *.azurewebsites.net certificate. Binding the LCPL corporate CA certificate is a configuration step in App Service TLS/SSL settings. Done at the point we assign a friendly hostname (e.g. wealth.lighthouse-canton.com).
H-5
HTTPS-only binding		 ✓ Built App Service serves only HTTPS by default; HTTP requests are auto-redirected. The URL in your browser is https://. No code in the app accepts plain HTTP.

Technology stack

LayerTechnology
Frontend / hostingAzure App Service (Premium V3, Linux, Python 3.12)
Backend databaseAzure Database for PostgreSQL Flexible Server (private VNet-integrated, SSL enforced)
NetworkingDedicated Azure Virtual Network with delegated subnets for App Service and Postgres
Source codeAzure Repos (LCPL Azure DevOps tenant)
Build & deploymentAzure Pipelines (CI/CD)
Runtime auth (today)App Service environment variable
Runtime auth (next step)Azure Key Vault + system-assigned Managed Identity

How code reached this server (change-control evidence)

The deployment process leaves a full audit trail. Nobody logs into a server to copy files; nothing is manually edited in production.

  1. Reference application code was sourced from a public sample repository on GitHub and brought to a local development workstation.
  2. The code was tested locally first (Python + PostgreSQL in Docker) to confirm it behaved correctly before any cloud deployment.
  3. The code was then pushed to Azure Repos inside LCPL's Azure DevOps tenant. Source code does not live on personal GitHub or any external service.
  4. Every change is a Git commit, attributed to the engineer's Entra ID identity.
  5. An Azure Pipeline in Azure DevOps watches the repo. Every push to main triggers an automated build (install dependencies, package the app) and release (deploy to App Service).
  6. Each deployment is logged with build number, commit hash, timestamp, and the identity that triggered it. Rollback to any prior build is a 2-click operation.

Live data from the private database

The table below was just queried from the private PostgreSQL Flexible Server over the VNet. This is a placeholder schema (a simple clients table); when real wealth-planning schemas are designed by the dev team, they replace this one. The point here is to demonstrate that the App Service ↔ private database connection works.

Rows currently in the test table: 2

IDNameEmailCreated (UTC)
2Test Client Betabeta@example.com2026-05-28 12:11:48.591894
1Test Client Alphaalpha@example.com2026-05-28 12:11:48.591894

Add a test row (writes to the private database)

Before real client data lands on this platform, the following must be in place (none are blockers — all are standard next steps):

Prepared by Rajkumar Singh, IT Administrator, Lighthouse Canton
Internal POC link — please do not share externally.
JSON API: GET /api/clients · POST /api/clients · GET /healthz