Secure Internal Web App for Sensitive Financial Data

0) Problem Restatement

Bloomberg asked (90-minute round): design an internal web application that supports:

1. User onboarding (new employees or clients get accounts),
2. Password reset,
3. Requesting company information (reports, documents),
4. IT help requests (tickets).

Requirements: parts of the system can be deployed independently, every request is authenticated and validated, and the data is highly sensitive financial information. Expect questions on SQL vs NoSQL, ACID and CAP, load balancing, caching, blue/green deployments, API gateways, and cloud vs on-premise.

1) Architecture

flowchart LR
    U["Employees - browser"] --> WAF["WAF + load balancer (TLS)"]
    WAF --> GW["API gateway - token validation, rate limits, request validation"]
    IDP["Identity provider - SSO, MFA"] --> GW
    GW --> ON["Onboarding service"]
    GW --> PW["Password / account recovery service"]
    GW --> INFO["Company info service"]
    GW --> IT["IT help desk service"]
    ON --> SQL1[("Postgres - users, roles")]
    INFO --> DOCS[("Document store + object storage - encrypted")]
    INFO --> CACHE[("Cache - non-sensitive metadata")]
    IT --> SQL2[("Postgres - tickets")]
    ON --> AUD[("Audit log")]
    INFO --> AUD

• Separate services per capability, each with its own database and CI/CD pipeline → independent deployments.
• API gateway: one entry point that validates tokens, enforces rate limits and request schemas, and routes traffic.

2) Authentication and Authorization

• SSO via a central identity provider (OIDC/SAML), with MFA required (hardware keys or an authenticator app for sensitive roles).
• Short-lived access tokens, and RBAC: roles like analyst, manager, IT agent, with least privilege. Sensitive documents are checked per request against entitlements.
• Password reset: prefer passwordless/SSO. If passwords exist: time-limited single-use reset tokens sent to a verified channel, identity verification (MFA or manager approval for privileged accounts), rate limiting, and notifications to the user.
• Onboarding: triggered from the HR system, creates accounts with default roles, and requires manager approval for extra access. Offboarding revokes everything immediately.

3) Data Stores (SQL vs NoSQL)

• Users, roles, tickets: relational (PostgreSQL). We need ACID transactions and integrity (a ticket assigned to exactly one agent, role changes consistent). Data sizes are moderate.
• Documents and reports: object storage (encrypted), with metadata in SQL, and a search index if needed.
• CAP choice: for financial and account data, prefer consistency (CP): better to reject a request briefly than show wrong or stale permissions.
• Caching: only non-sensitive or permission-safe data (e.g., the list of report categories). Never cache documents across users.

4) Security in Depth

• TLS everywhere (mTLS between services), encryption at rest with managed keys (KMS/HSM), and field-level encryption for the most sensitive fields.
• Input validation at the gateway and in each service, with protection against injection attacks and CSRF.
• A complete audit log (who viewed or changed what), which is immutable and monitored for anomalies (bulk downloads).
• Network segmentation: services in private subnets, with the admin tools reachable only via VPN or a zero-trust proxy.

5) Reliability and Deployments

• Stateless services behind load balancers across zones, and database primaries with standby replicas and backups.
• Blue/green deployments: run the new version (green) alongside the old (blue), switch traffic after checks, and switch back instantly if problems appear. Database changes must be backward-compatible (expand/contract migrations).
• Cloud vs on-prem: cloud gives managed security services and elasticity. On-prem may be required by regulations or data residency. Hybrid is common. Discuss the compliance requirements (e.g., SOC 2 and financial regulators).

6) Wrap-Up

Split the app into independently deployable services behind a WAF, load balancer and API gateway that validates every request. Authenticate with SSO + MFA, authorize with least-privilege RBAC and per-document entitlements, and handle password reset and onboarding with verified, time-limited, audited flows. Use ACID relational stores for users and tickets and encrypted object storage for documents, cache only permission-safe data, encrypt everything, audit every access, and release with blue/green deployments and backward-compatible migrations.