Operations, Security & Reliability

Roles, Privileges, and Least Authority

Least authority gives each human, service, and automation identity only the operations it needs, for only as long as it needs them, while separating login, membership, ownership, and emergency elevation so access remains reviewable and revocable.

Identity, role membership, ownership, and object privileges are separate controls.
Applications should not own their schema.
Future objects need an explicit grant policy.
Escalation paths are part of the model.
Access expires unless renewed.
Emergency access needs stronger evidence, not a permanent superuser.

Ownership and grant model

PostgreSQL: separate owner, runtime, and migration identities

CREATE ROLE commerce_owner NOLOGIN;
CREATE ROLE orders_runtime NOLOGIN;
CREATE ROLE orders_app LOGIN NOINHERIT;
GRANT orders_runtime TO orders_app;

CREATE SCHEMA commerce AUTHORIZATION commerce_owner;
GRANT USAGE ON SCHEMA commerce TO orders_runtime;
GRANT SELECT, INSERT ON commerce.orders TO orders_runtime;
GRANT SELECT, INSERT ON commerce.order_items TO orders_runtime;
REVOKE CREATE ON SCHEMA public FROM PUBLIC;

-- Run as the role that will create future objects.
ALTER DEFAULT PRIVILEGES FOR ROLE commerce_owner IN SCHEMA commerce
  GRANT SELECT, INSERT ON TABLES TO orders_runtime;

Quarterly access-review evidence
Question	Evidence	Action
Who can log in?	principal, owner, last use, credential age	disable dormant/shared identities
What is inherited?	membership graph and admin options	remove transitive or circular elevation
Who owns objects?	schema/object/routine owners	move ownership from people/apps
How can policy be bypassed?	superuser, bypass, definer, extension, replication paths	narrow, monitor, or remove
Are grants still justified?	service catalog and approved capability	renew with expiry or revoke