N

client · case study

Operations Centre Shared-Secret Tool on AWS

There was no auditable credential-handover path in the Operations Centre, with secrets moving by email, chat or shared spreadsheets. Built an AWS-hosted shared-secret app with one-time retrieval links and retrieval logging. Still in active use across the centre.

All work

results

What shipped.

  • /01

    Shared-secret site running on AWS, available to the whole Operations Centre.

  • /02

    Replaced ad-hoc password and credential handover paths that were neither secure nor auditable.

  • /03

    Still in active use across the centre.

architecture

How it fits together.

Hover a node to highlight its connections. Click one to read what it does and why it is there.

AWS — Operations Centre tenancyauthone-time linkexternalEngineer sendingsecurityOperations Centre IdPcomputeShared-secret appdataOne-time storeobservabilityRetrieval logexternalReceiving engineer

The brief

The Operations Centre routinely needed to hand out secrets (one-time passwords, RSA tokens, credentials for customer system access) and had no decent tool for it. The available options were email, chat, or shared spreadsheets. None of those passed a security review and none of them aged well.

What I did

Stood up a small AWS-hosted shared-secret application that took a secret in on one end and produced a one-time retrieval link on the other. Linked it into the Operations Centre's authentication so it was available across the team without per-tool credentials. Documented enough for the next engineer to operate it.

Why it mattered

The centre got off the worst credential-handover paths and onto something with retrieval logging and time-bounded links. The tool has been in continuous use across the team since.