05 · Architecture · Export and privilege
Being able to see one store does not mean being able to export every member
The security architect writes over-privilege export, privilege inheritance, and audit as constraints—forbid first, then allow. This role writes how it should be. Security testing proves there is no bypass.
| Action | Allowed | Left behind |
|---|---|---|
| Query members by store | That store's operations | Who queried, when, the filter |
| Export mobile numbers | Separate authorization, with an end date | File watermark, row count, approval document |
| HQ sees the full set | Not open by default | Reason and scope of each request |
| API bulk pull | The same privilege as the page | Reject records; hiding the button is not enough |
The security architect translates a convenience request into what happens when it runs away
The most common security incident in a business system is not an outside break-in. It is an internal account that can export data it must not export. The security architect's mark is writing constraints at design time: least privilege, privilege that does not inherit into export, enforced on the server, audit that can be traced. A design that only hides the export button on the frontend, while an API can still pull the full table with a script, is sent back. This role does not replace Security tester. He writes how it should be. Testing proves the implementation has no bypass.
He also checks whether the identity lifecycle has landed in the design. Leaving accounts, shared accounts, and temporary administrators during implementation all need an end date. An administrator with no end date is the largest hole after the project ends. If a temporary convenience becomes a permanent role, he lists it on its own in the go-live check. It is not folded into “known issues.”
Why export needs its own authorization
Query and export do different damage. A query sees one page. An export takes the whole store. The security architect requires export as a separate privilege, with approval, a row cap, and a watermark. The watermark includes who exported, so a leak can be traced. Approval cannot be the requester themselves. An HQ role does not automatically own export for every store. Otherwise one HQ intern equals every member.
Audit fields are at least who, when, the filter, the row count, and whether the result was success or reject. With no reject records, later you cannot know who was trying. Log retention is written into the design from the customer's compliance requirement. It is not written as “look at the logs later.”
The time member export was treated as an everyday button
Store operations needed to issue coupons to a batch of members. Development put export on the list page, with privilege equal to anyone who could see the list. In review the security architect called the API with a store account, dropped pagination, and got other stores' mobile numbers, because the store filter was only selected on the page and the server did not check. The design was changed: the server filters by the account's store scope; export must go through approval; a single run caps at five thousand and is watermarked; the API uses the same policy as the page. Security testing later retested with a script and no pagination parameter, and confirmed over-privilege no longer returned data.
Operations felt the extra approval step. That step is deliberate. The coupon list can be finished in the file after approval. Every clerk does not need a permanent right to download the whole store. Where export files are kept is also written as a constraint. Files may only go into an approved directory. They must not be forwarded out through a personal mailbox. Once forwarded, the watermark can still be traced, but the approval chain is already broken. He requires the mail gateway or the operating note to block at least one of the most common forwards, and to try it once in a drill. Production data used for testing also needs approval. The member table must not be copied into the development database just because looking up a problem is easier. Take as many rows as the problem needs. Write the masking rule. Delete when debugging ends.
For administrator accounts during implementation, the security architect requires a close date, and puts it on the go-live check. Still in use when the date arrives is treated as not done, not leftover polish. If a shared account named “implementation” stays in production, every dangerous action in the audit becomes the same person, and an incident cannot be traced to a shift.