Skip to content
allanninal.dev/build
Collaborate

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

How an account gets matched to a person

Matching an account to a person looks like a join on email address and is not, for reasons that are individually small and collectively cover about ten per cent of accounts in any real business.

Key takeaways

  • Match on email, then on alias, then on name, and record which matched.
  • Four kinds of unmatched account: leaver, contractor, shared, and service.
  • Only the first two are problems. The other two are findings to record and watch.
  • A shared account is never matched to a person, however obvious it seems.
  • A person with two accounts on one service is worth reporting as its own case.

Three ways to match

How a service account is matched to a person on the staff listA vertical chain of five steps entered by a box labelled An account, carrying an email and a display name. Step one asks whether the email is on the staff list, exactly, checking both current and past staff; a hit exits to Matched, the usual case. Step two asks whether it is a known alias such as a former or second address; a hit exits to Matched and records the alias. Step three asks whether the name matches exactly one person; one match exits to Probably matched, flagged for confirmation. Step four asks whether it looks like a shared or service account by pattern; if so it exits to Record as shared, never as a person. Step five is Matches nobody, which is the finding. A note says a name match is provisional and two people called J Smith is not a match at all.AWS ACCOUNTAn accountemail and display nameEmail on the staff list?exactStaff listcurrent and pastMatchedthe usual caseyesA known alias?former address, or a secondMatchedrecord the aliasyesName matches one person?exactly oneProbably matchedflag for confirmationoneLooks shared or service?by patternRecord as sharednever as a personyesMatches nobodythe findingA name match is provisional. Two people called J Smith is not a match at all.
Fig 1. How an account finds its person. The name-match tier is deliberately provisional, because confidently matching the wrong person is worse than reporting an unmatched account.
  • App integration
  • Machine learning
  • Networking
  • Security & identity
  • Management
  • Analytics
  • People

Aliases

People change email addresses more often than systems expect: a name change, a domain migration, a move from a personal address used during a trial to a work one. The account created under the old address frequently survives, and matching on the current address alone reports it as unmatched every week forever.

So the staff list carries known former addresses, and a match against one records the alias on the account. That both silences the false finding and produces something genuinely useful: a list of accounts still using an address that no longer routes, which is a password-reset problem waiting to happen.

Four kinds of unmatched

KindLooks likeWhat it means
LeaverMatches somebody on the past-staff listRemove it; this is the finding
ContractorA domain that is not yours, still activeCheck whether the engagement ended
Sharedinfo@, accounts@, a team nameRecord it; a different conversation
ServiceAn API key, a bot, an integrationRecord it and attach an owner

Only the first two are problems in the ordinary sense. The other two are legitimate, common, and worth having written down — a shared mailbox nobody owns and a service account nobody remembers creating are both real risks, and both need a conversation rather than a removal.

Shared accounts are never matched

The temptation with accounts@ is to match it to whoever mostly uses it, which makes the report tidier and destroys the finding. A shared account by definition has no individual accountable for it, and that is the thing worth recording.

So shared accounts get their own category, an owner is attached to the category rather than to the login, and the twice-yearly review asks a specific question about each: is this still needed, and could it be individual accounts instead. That question produces a genuine improvement about a third of the time and never gets asked without something prompting it.

Two accounts, one person

How a person holding two accounts on one service is reportedA horizontal row of five boxes. The address j dot reed at: active and current. The address jreed at: also active. Same person: matched by alias. Two logins: one of which is unused. Reported: as duplication rather than as a leaver. A note says this is common after a migration, and each unused login is a credential nobody rotates.ONE PERSON, TWO ACCOUNTSj.reed@active, currentjreed@also activeSame personby aliasTwo loginsone is unusedReportedas duplication, not a leaverCommon after a migration, and each unused login is a credential nobody rotates.
Fig 2. The duplication case. It is not a leaver and not shared, and it produces a live credential attached to nobody’s attention.
  • Networking
  • Analytics
  • People

This case is worth its own reporting line because it is invisible to both the leaver check and the entitlement review: the person works here and legitimately needs access, so nothing is wrong except that there are two credentials where there should be one, and one of them has not been used in eight months.

Next: the twice-yearly review.

All posts