“Every program and every user of the system should operate using the least set of privileges necessary to complete the job.”Jerome Saltzer, Michael Schroeder · The Protection of Information in Computer Systems · 1975 · The Protection of Information in Computer Systems, Proceedings of the IEEE 63(9), 1975 — §I.A.3, principiul (f), least privilege
Any privilege you cannot justify by a task is one to remove.
A source system exposes one customer; the warehouse exposes all of them, with history. That is why the 1975 principle is more concrete here than anywhere. Least privilege applies on three axes: tables (a role sees only the schemas it needs), columns (dynamic masking: the analyst sees the last four digits, accounting sees everything) and rows (row-level security: a sales agent sees only their region, through the same view, without copies of the table). Access to the identity vault from lesson 18 is a separate role, granted separately. Underneath, two layers that are not negotiable: encryption at rest, with keys managed outside the warehouse and rotated, and encryption in transit. On top, audit: every query on sensitive tables is recorded — who, when, what was read, how many rows — retained and, above all, read by someone. The usual traps are mundane, which is why they are common: a service account for the BI tool with rights over the whole warehouse, used by everyone; secrets pasted into SQL; shared accounts that make the audit useless. Saltzer and Schroeder's rule, read backwards: any privilege you cannot justify by a task is one to remove.
Why it matters A single over-privileged service account turns a breach in a reporting tool into a leak of the company's entire history.