Securing a Regulated Cloud Estate That Discloses by Design
The security architecture behind a production system whose core function is a disclosure: six trust zones with every crossing mediated, workload identity throughout, and controls that decline to open a conversation rather than hardening one.
- Cloud Security
- Zero Trust
- Regulated Environments
- Microsoft Azure
- 6
- Trust zones, every crossing mediatedFrom the customer handset to the corporate on premise core, plus a separate zone for external processors. Each crossing carries a named boundary control recorded in the design; nothing spans a boundary implicitly.
- Zero
- Production access held by the delivery teamProduction was excluded at subscription and network level rather than by policy or undertaking, for the duration of the engagement. One project lead held limited read access, and inspection of live data happened on a screen share with institution staff in control of the session.
Overview
Most security work protects a system from the outside. This one had to protect customers from what the system was designed to do.
The feature is the exposure. To confirm what the bank holds, the system displays a person's residential address, contact numbers, occupation and source of funds, on a mainstream consumer messaging platform, on infrastructure the bank does not own and cannot audit. There is no login, no app, no session, no password and no device binding. The claim to be speaking with the right person rests on possession of a phone number and knowledge of six digits from an identity document.
Strengthening that authentication was not available as an option, because removing friction from a compliance interaction is the whole reason the system exists. Identity assurance was therefore treated as a precondition evaluated before the interaction rather than as a gate inside it.
The Context
The client is not named. The system serves a regulatory obligation for a retail and commercial bank in a regulated market, running on a serverless Microsoft Azure estate across three isolated environments with private connectivity to on premise core systems.
The security posture derives from one property. The intended behavior is a disclosure of personal financial data, over a channel the institution does not own, to whoever is in possession of a handset, authenticated by a knowledge factor consisting of six digits of an identity document.
The Challenge
An attacker who has taken control of a number satisfies every check inside the conversation, because those checks are exactly what the legitimate customer would satisfy. Controls placed inside the exchange therefore cannot detect the case they exist to catch.
- No session, no device binding, no password, no application to install
- A knowledge factor of six identity digits standing in front of a financial disclosure
- A messaging vendor in the path that the institution cannot audit
- Instrumentation deep enough to trace one conversation end to end, over data that is personal and financial
- A delivery partner that would otherwise need production access to debug any of it
Where confidence in identity is insufficient, the system refuses to initiate rather than adding friction to the exchange. That axiom is the design, not a slogan attached to it.
What Was at Stake
SIM swap fraud transfers control of a number to an attacker. The opening sequence of this system would then hand that attacker a complete identity profile, followed by an authenticated route to alter the record it had just disclosed. Hardening the conversation does not address that, because the attacker passes every check the conversation contains.
The second case is not a security failure in the usual sense and matters as much. A customer recorded as deceased cannot consent to anything, and nobody writes that requirement into a specification. It is either reasoned about in advance, or found once, badly, in front of a family.
Our Role
Kainskep delivered the cloud and security architecture. The bank owned the parts that make an access boundary real rather than declared.
- Cloud architecture and configuration across three isolated environments
- DevOps, including authoring the deployment pipelines
- API development, integration, and data and application security design
- Client scope: infrastructure provisioning, deployment identity, acceptance testing and security review
A deployment pipeline is the standard route by which an access boundary becomes decorative, because automation typically holds permissions its authors do not. The split here was deliberate: we authored the pipelines, and the institution configured and owned the service accounts those pipelines used to reach each environment. One party defined what shipped. The other controlled the credential permitting it to ship. Neither held both halves.
What the Security Review Changed
A review that finds nothing is either lucky or shallow. Recording what changed is more useful than listing the controls that passed, because the second question has only one answer and it is not informative.
Connector availability was narrowed
Connector availability in the conversational tooling environment was restricted following security feedback, reducing what that component could reach. Elevated roles in the AI tooling were scoped to the development environment.
Function endpoints moved behind API management
An earlier design placed an application gateway in that position. Moving the endpoints behind API management changed how the system's own APIs were exposed, with an explicit per environment origin allow list and a restricted header set rather than a permissive default.
On premise event capture was rebuilt
The mechanism for capturing events from on premise systems was changed from the original approach, which altered the connectivity model between the cloud estate and the core.
Any organization evaluating a delivery partner should ask what a security review changed rather than whether it was passed.
The Controls That Carry the Weight
Six trust zones, from the customer handset to the corporate on premise core, with every crossing mediated by a named control. Nothing spans a boundary implicitly.
Refuse rather than harden
Before contact is initiated, telecom data is queried for how long the number has been associated with its current SIM. Under three months, no message is sent. Government population data is checked for deceased status. Failure of either check terminates the flow. In our experience this control is almost never present in comparable channels, because it requires treating your own product as the threat.
- SIM age
- Deceased check
- Pre-contact
Consent, then challenge, then disclose
The opening message identifies the institution and its verified account, names the obligation, links terms and asks whether the customer wishes to proceed. Only then is part of the identity number challenged. Only then is anything displayed. Information is released progressively across the exchange, so an abandoned session has released less than a completed one. A challenge placed after disclosure protects nothing.
Data minimization per processor
Address matching needs a mapping provider. A mapping provider does not need a bank's customers. The architecture records an explicit decision that no client data is passed to the geospatial service, so a third party in the critical path of the matching engine holds nothing that identifies a person. Credit bureau, population register and telecom services each receive what their specific check requires and nothing beyond it.
No credentials inside the estate
Components authenticate to one another by workload identity. Third party API keys exist because external providers will not federate, and they are confined to the key vault, retrieved at runtime by managed identity, and absent from application configuration, source, deployment artifacts and pipeline variables. No person or artifact in the delivery chain holds one. That is a materially different claim from no secrets, and it is the one that survives inspection.
- User assigned managed identity
- Key vault only
- No human handling
Personal data that cannot surface through telemetry
The usual answer is a redaction rule on log output, which works until somebody adds a field and forgets. Here personal fields are encoded at ingestion and travel the pipeline in that state, decoded only at the dispatch boundary to the messaging vendor. Matching, orchestration and state management operate on encoded values, so anything telemetry captures incidentally is captured encoded. An engineer in application monitoring sees structure, sequence and error state. Reading content is a separate, deliberate act with the key.
An access boundary the delivery team could not cross
Cloud access covered development and quality assurance only, through separate administration accounts. Production was excluded at subscription and network level rather than by undertaking. Debugging a live conversation over somebody else's screen share is slower and more frustrating than holding access, and choosing it anyway is a control that costs the delivery organization something rather than costing it nothing.
- Non-production only
- Supervised inspection
- Staged rollout
Three environments, each with its own resource groups, virtual networks, subnets and network security groups. Platform services reached over private endpoints rather than public service endpoints. Connectivity to on premise over a dedicated private circuit, selected over a virtual private network gateway and recorded as a decision with a rationale. Every component to component flow enumerated by source, destination, port and protocol, per environment, which is what deny by default looks like when somebody has done the work rather than described the intention.
What We Delivered
The artifacts a second line function can actually review.
A trust zone model
Six zones with contents, trust assumption and boundary control stated for each, plus the external processor zone and what each processor receives.
Documented request paths
Outbound initiation from the on premise core to the customer, and inbound response from the customer to the data plane, stage by stage, including where a payload is decoded and where it is not.
An identity and credential chain
Workload identity end to end, with the single external perimeter exception stated precisely rather than glossed over.
A data protection model
The state of personal data at every stage, and what each state means for what telemetry can see and what an operator can reconstruct.
A threat register with residual risk
Attack, control and what remains, per threat. A register without a residual risk column is marketing.
An enumerated network inventory
Every flow by source, destination, port and protocol, per environment, alongside a platform and pattern index with nothing aspirational listed in it.
Outcomes
This section states what the posture achieved and stops there. No penetration testing result, formal threat modeling exercise or certification outcome is claimed, because none is being evidenced.
- The system ran in production on a channel the institution does not own
- The delivery team had no path to production customer data, by capability rather than by policy
- A third party in the critical path of the matching engine holds nothing that identifies a person
- Rollout was staged into a low risk internal cohort, treating blast radius as a security parameter
Every organization eventually asks a delivery partner the same question: what could your engineers see in production? Most answers are about intent and policy. This one is about capability.
What This Page Does Not Cover
Published in anonymized form. Client identity, proprietary system names, vendor names, resource naming, network addressing and commercially sensitive figures are withheld. Four things were also out of scope or not reached before the engagement concluded, and are recorded here so a reader does not infer coverage.
- Key custody and rotation policy, and the behavior of in-flight conversations across a rotation event, were not established
- No throughput, concurrency or latency figures, because none were measured under representative load
- Availability and recovery design was carried as an open section in the infrastructure design and was not completed
- Cost modeling at scale is not evidenced, and should be done before applying this pattern at higher volume
- Release approval gating is not evidenced in the design record and is not claimed
Related Capabilities
The disciplines this engagement drew on, and where each is described in full.
Cloud Security & Compliance Readiness
Security design that starts from what the product itself exposes, rather than from a checklist applied to whatever was built.
Cloud security and compliance readinessCloud Infrastructure
Network segmentation, private connectivity to on premise systems, and an identity model with no stored credentials inside the estate.
Cloud infrastructure engineeringDevOps & Automation
Deployment pipelines authored on one side of an access boundary and credentialed on the other, so automation holds no permission its authors lack.
Engineering the path from code to production