An in-memory store is brought up with stock settings on a routable host — what reaches it, and what proves a caller's identity?

## The assumption that is still in the defaults An in-memory store of this class was designed as a component you ran on hardware you owned, on a network segment nobody else was on. Two choices followed from that assumption, and both are still visible when you start one today: the fast path carries no identity handshake, and the server starts and serves with no configuration at all. The assumption never changed. The network did. The same server image now runs inside a container platform with flat internal routing, on a cloud host that quietly has a public address, or beside an application whose other dependencies are not all trustworthy. So the honest answer to *what reaches it* is: **whatever can route to the listening address**, unless something outside the process stops it. ## Three questions people collapse into one - **What address is the process listening on?** Not what a configuration file says — what the running process is bound to. A binding to one local interface and a binding to every interface are different exposures, and an environment override or a platform's port forwarding can make the file and the process disagree. - **Who can route to that address?** The segment, the firewall or security-group rules, and the platform's internal traffic policy. A tier is not private because it lacks a public address; it is private because only its callers have a path to it. - **Does the server check anything about the caller at all?** This is a *variation point*, not a given, and the range across the family is wide. ## What varies across the family | Property | Range across this class of store | |---|---| | Listening address out of the box | some bind a local interface only; some refuse a non-local connection until an operator has configured one; others listen on every interface they find | | Server-side identity step | **none at all** on some; one shared server-wide credential on others; per-owner credential rules where the server has them | | Encrypting the hop | terminated by the server itself on some; on others provided by a terminating proxy or tunnel placed beside the process | | Operator reach | a host you can log into, or a managed instance where you reach only an operator interface and the platform's network rules | Getting this wrong in either direction is a weak answer. *"Just turn the password on"* is wrong for a store that has no identity step to turn on. *"These are all wide open"* is wrong for a managed instance that will not accept a connection from outside its own network grouping no matter what you send it. ## What one accepted connection is worth when the tier holds sessions The material point is the contents. A tier holding a replaceable copy of rows costs you a cold start. A tier holding sessions, claims and deduplication records holds state that exists nowhere else, so an accepted connection can: 1. **Read** the session and claim records of every user of the application, not only its own; 2. **Write** entries the application will trust the next time it looks; 3. **Delete** them — a lease disappears and two workers do the same job, a deduplication record disappears and a retried request is processed twice, the whole keyspace disappears and every signed-in user is signed out at once while the origin absorbs the full load; 4. on some stores, **change server settings at runtime or cause a write to disk**, which is how an exposed data store becomes an exposed host. Points three and four are why *"there is nothing secret in it"* is not an argument. Integrity and availability are exposed even where confidentiality is not. ## The order the controls actually go in 1. **Placement.** Decide which network the tier sits on and which workloads have a route to it. This is the only control that exists on every store in this class, so it carries the weight. 2. **Routing rules**, denying by default, with the allowed set being the callers rather than the subnet. 3. **The server's credential check, where the server has one** — required when it exists, with the narrowest per-owner rules the server can express. 4. **Encrypting the hop**, so the entries, and the credential on stores that present one at connection setup, are not readable by anything that can observe the traffic. 5. **The copies on disk**, if the deployment writes any. ## What to confirm before relying on any of this - The address the *running* process listens on, and from which networks that address answers. - Whether the server has an identity step at all, and whether the credential crosses the network in the clear. - Whether an ordinary connection can change settings or trigger a write to disk. - What the tier is actually holding, since that decides whether an incident is a cold start or an identity incident. Someone who has operated one of these does not answer *"set a password"*. They lead with placement, name the identity step as something they would confirm rather than assume, and say which parts of their answer change if the store on the other end is a different member of the family.