Skip to content
allanninal.dev/build
Collaborate

Part 2 of 7 · Access review reporter series ~5 min read

How access lists get collected

The uncomfortable fact at the centre of this system is that a substantial fraction of the services a small business uses will not tell you who has access, and the ones that will require an admin credential to ask. Both are manageable and neither should be glossed over.

Key takeaways

  • Three tiers: an API, an export somebody drops in, and a manual list.
  • Each service’s credential is read-only where the service supports it, and separate always.
  • A manual entry is marked unverified, dated, and counted in the coverage figure.
  • Coverage is reported as a percentage of spend, not of services.
  • Every collection is a dated snapshot, never an overwrite.

Three tiers

Three tiers of access list collection converging on one account listThree boxes stacked on the left. API: collected weekly and automatically, labelled verified. Export: a CSV somebody drops into a folder, also labelled verified. Manual list: typed and dated, labelled unverified. All three converge on One account list per service, carrying its tier. Below it, connected by a downward arrow, is the Matcher, which works against the staff list. A note says the tier travels with the data, and a report that mixes them without saying so is lying.APIweekly, automaticverifiedExporta CSV somebody dropsverifiedManual listtyped, and datedunverifiedOne account listper service,with a tierMatcheragainst the staff listThe tier travels with the data. A report that mixes them without saying so is lying.
Fig 1. The three ways a user list arrives and the tier that travels with it. Keeping the distinction visible is what stops the review claiming more assurance than it has.
  • Storage
  • Database
  • Networking
  • Analytics
  • Front-end & mobile

The export tier

Between a full API and nothing there is a large middle: services whose admin panel has a download-users button but no programmatic access. Those are worth treating as verified rather than manual, because the list is machine-generated and complete — it just needs a person to press a button.

The practical handling is a monthly reminder to whoever owns that service, with a folder to drop the CSV into and a note of how old the current one is. An export that is four months old is reported as such, which is honest and also tends to produce a fresh one.

The credential problem

How a service's user list is collected weeklyA vertical chain of five steps entered by a box labelled A service with an API that lists users. Step one asks whether a read-only scope exists for user listing; if not it exits to Admin credential needed and records that fact. Step two uses the system's own credential rather than a person's login, stored as one secret each in Secrets Manager. Step three fetches the list weekly. Step four stores a dated snapshot that is never overwritten. Step five compares against last week for additions and removals. A note says several services only expose user lists to a full admin credential, and it is worth noting which.AWS ACCOUNTA service with an APIthat lists usersRead-only scope?for user listingAdmin credential neededrecord that it isnoOwn credentialnot a person's loginSecrets Managerone secret eachFetch the listweeklyStore a snapshotdated, never overwrittenCompare to last weekadditions and removalsSeveral services only expose user lists to a full admin credential. Note which.
Fig 2. How one service’s list is collected. The credential scope is worth recording per service, because an access review tool holding several admin credentials is itself an access concern.
  • Database
  • App integration
  • Security & identity
  • Management
  • Analytics
  • Outside AWS

The irony is worth naming: a system built to review access frequently needs elevated access to several services in order to do it. That is unavoidable for the services that offer no read-only scope, and the honest response is to record which services those are and to keep each credential in its own secret with its own rotation, rather than one credential that can read everything.

It is also a reason the system has no write path anywhere. A tool holding admin credentials to eleven services and able to modify access would be a genuinely attractive target; one that can only list is much less so.

Coverage, honestly

How access review coverage is reported across fourteen servicesA horizontal row of five boxes. Fourteen services that people log into. Nine by API: weekly and verified. Two by export: monthly and verified. Three manual: unverified. Coverage: ninety-four per cent of spend and seventy-nine per cent of services. A note says percentage of spend is the honest number and percentage of services flatters.COVERAGE, REPORTED TWO WAYS14 servicesthat people log into9 by APIweekly, verified2 by exportmonthly, verified3 manualunverifiedCoverage94% of spend, 79% of servicesPercentage of spend is the honest number. Percentage of services flatters.
Fig 3. How coverage is reported. Both percentages are true and they differ substantially, which is why the report carries the less flattering one first.
  • Storage
  • Machine learning
  • Analytics
  • Front-end & mobile
  • Outside AWS

Those two numbers usually differ a lot, because the services with good APIs tend to be the larger, more expensive ones and the manual ones tend to be small tools. Reporting only the spend figure would flatter; reporting only the service count would understate how much of the important estate is covered.

Reporting both, with the service count first, is the version that keeps somebody honest about the three services nobody can verify.

Next: matching accounts to people.

All posts