The Most Sensitive Data You Hold
In one line: you have built continuous recording of identifiable people in private spaces, and the access model matters more than the encryption.
What the breach taught
In March 2021, a group obtained access to roughly 150,000 cameras operated by a cloud surveillance vendor. Affected sites included hospitals, prisons, schools, police stations and factories, and the access included live feeds and archived footage.
The entry point was not an exotic vulnerability. It was a set of super-admin credentials found publicly exposed, which had not been rotated. What turned that into 150,000 cameras was the access model behind it: reporting afterwards indicated that super-admin privileges were held extremely broadly inside the company, extending well beyond the engineers who plausibly needed them.
Two lessons, and the second is the architectural one.
The first is ordinary: rotate credentials, require multi-factor on privileged accounts, monitor for exposure. Necessary, and it is hygiene rather than design.
The second is the one to build around: a role that sees every camera should not exist as a normal operating state. The credential leaked because credentials leak. The damage was a function of what that credential could reach, and that is a design decision.
Authorization is per camera, not per user
The natural model — roles like viewer, operator, admin — is too coarse for footage. Access has to be scoped along three axes at once.
Which cameras. A site manager sees their site. A regional lead sees their region. Nobody sees everything by default. This maps neatly onto the key layout, since site and camera are prefixes.
Which time range. An investigator granted access for one incident should get that window, not the entire archive of those cameras. Access grants carry start and end times.
For how long. Grants expire. A grant issued for an investigation that ended in March should not still be live in September, and the way to guarantee that is an expiry on the grant rather than a process for revoking it.
Where genuinely-unrestricted access is needed — an emergency, a system-wide investigation — it should be a break-glass path: explicitly requested, time-boxed to hours, approved by a second person, and loudly audited. Its use should generate an alert that a human reads, not a log line nobody opens.
| Coarse role model | Scoped grant model | |
|---|---|---|
| Blast radius of a leak | Everything the role can see | One site, one window |
| Expiry | Until someone revokes it | Built into the grant |
| Audit answer to 'who saw this?' | Anyone with the role | A specific list |
| Emergency access | Already granted, invisibly | Break-glass, alerted |
URLs are capabilities
Playback works by handing the client URLs to storage objects, which means a URL is access. Three rules follow.
Signed URLs are short-lived — minutes, matched to playback rather than to the session. Objects are never publicly readable, so a leaked key is useless without a signature. And URL issuance is the authorization checkpoint: the check happens when the manifest is generated, against the requester's grant for that camera and time range, and it is logged there. Checking at the storage layer is too late, because storage only sees a valid signature.
The audit trail is a feature
For most systems an access log is an operational convenience. Here it is part of the product, because "who viewed this footage" is a question that gets asked by regulators, in litigation, and during internal investigations.
Log the identity, the cameras, the time range requested, the reason or case reference, and the timestamp — on every manifest issued and every export. Make it append-only and retain it longer than the footage, since questions about who watched something outlive the something.
Exports deserve their own treatment. Once footage is downloaded it leaves every control you have, so exports should be a distinct, more heavily audited action, ideally watermarked with the requesting identity so a leaked file traces back.
Privacy is not only access control
Two obligations sit above the access model.
Purpose limitation. Footage collected for premises security is not available for measuring how long staff take breaks. That is a governance rule, and the technical expression of it is that access grants carry a stated purpose which appears in the audit trail.
Minimisation. The strongest privacy control in this entire design is the retention policy. Footage deleted on schedule cannot be breached, subpoenaed, mined or leaked. This is the same lever as the cost argument, arriving from the opposite direction, and it is worth pointing out that they agree: shorter retention is both cheaper and safer, which is a rare alignment.
Masking is the narrower tool — permanently blacking out a region of the frame that should never have been recorded, such as a neighbouring property or a screen displaying customer data. Applied at the camera it is genuinely irreversible, which is what makes it worth doing there rather than at playback.
Key takeaway
Assume the credential leaks, and design so that what it reaches is small: scope access by camera, by time range and by expiry rather than by coarse role, and make unrestricted access a break-glass path that is time-boxed, second-approved and alerted. Treat signed URLs as capabilities, checking authorization when the manifest is issued rather than at storage. Keep an append-only audit of who viewed what, retained longer than the footage. And note that retention is simultaneously the biggest cost lever and the strongest privacy control — the two arguments point the same way.
Next: the whole design, assembled under interview conditions.