Audit Findings on a Mixed-Purpose Production Environment
A health insurer runs its member portal (about 180,000 end users) and an internal back-office application in the same OutSystems Production environment, reached through one public hostname. An internal audit reports five findings: six shared "admin" IT user accounts with no named owner; 47 IT users holding Change and Deploy on Production; end-user sessions lasting eight hours with no re-authentication; a custom back-office login screen that validates credentials against a service account whose password is stored in a site property; and back-office screens reachable from the internet because there is no IP filtering. The security team has mandated SSO with Azure AD and MFA for staff, but the delivery team is under pressure to keep the change small, arguing that the portal and back office share screens and entities and that splitting them would take a quarter.
1. Rank the five findings by risk and justify the order. Where would you act this week?
Read the worked answer
Rank by exploitability multiplied by blast radius, not by how alarming each sounds.
- Back-office screens exposed to the internet. This is the only finding that lets an external actor reach privileged functionality today, and it is fixable at the network layer without touching code. Act this week.
- Shared admin accounts and 47 Production deployers. No attribution means no audit trail, and a leaked credential cannot be revoked for one person. Any of those 47 can publish a change that exfiltrates the member database. Act this week: cut to a named pipeline identity and a small, documented break-glass set.
- Service account password in a site property. High severity, because the property is readable to anyone with environment access and often leaks into exports and screenshots - but the exposure requires prior access, so it follows the first two.
- Eight-hour end-user sessions with no re-authentication. Real, especially for a health insurer handling sensitive data, but it is a session-hijack amplifier rather than an open door.
- Custom login screen for staff. The weakest of the lot on its own, but it is the thing that keeps staff outside your identity provider and is the reason MFA cannot be enforced yet.
Two judgement notes: findings 1 and 2 have network and identity-layer fixes that need no application refactor, so the "splitting takes a quarter" argument does not delay them. And findings 3 and 5 disappear as a side effect of the SSO work, which is the argument to make for funding it.
2. Design the target authentication, authorisation and exposure model. Be specific about what changes at environment level versus application level, and how the service account secret should be handled.
Read the worked answer
Exposure first. Keep one environment, but separate the network paths: put the back-office behind IP filtering or a reverse proxy that only corporate networks and VPN traverse, and stop publishing those screens on the public hostname. This is an environment and infrastructure control, not an application change, and it buys time while the split is planned. Schedule the eventual split into two applications and, ideally, two environments so the member portal's release cadence stops dragging back-office governance with it.
End-user authentication. Keep the built-in end-user provider for the 180,000 members, with a session timeout measured in minutes or low hours rather than eight, and idle-timeout re-authentication on sensitive screens. Members will not tolerate MFA for browsing, so scope step-up carefully.
Staff authentication. Configure IT authentication at the environment level against Azure AD, so Service Center and LifeTime users authenticate through the identity provider and MFA is enforced by policy rather than by an application screen. Delete the custom back-office login screen; back-office users become IT users or end users federated to Azure AD with roles supplied by group claims.
Authorisation. Map Azure AD groups to OutSystems roles per application, and grant LifeTime roles separately from Service Center roles - the 47 Change and Deploy holders should collapse to a pipeline identity plus a named release manager. Remove the six shared accounts and replace them with named accounts; keep one documented break-glass account with alerting on use.
The service account secret. A site property is a configuration store, not a secret store: it is readable to anyone with environment access and travels with module exports. Move the credential to a managed vault, store only a reference or key name in the site property, and retrieve the secret at runtime through an extension with a scoped identity. Rotate the credential immediately, since it must be assumed compromised.
Sequence: network restriction and account clean-up this week, SSO next sprint, secret migration alongside, application split according to the roadmap.