Least Privilege Starts with the Data Model

Learning outcomes

Security starts before permissions are granted. A database model defines ownership boundaries, identities, and relationships that make access-control rules either clear or fragile. Least privilege means every human, service, job, and integration receives only the permissions required for its purpose—and no broader capability by default.

Least privilege as a modeling concern

If every table mixes public, operational, administrative, and sensitive fields, permissions become coarse. Separating data by responsibility can make privilege boundaries enforceable.

Example: Customer data

Customer(  customer_id,  display_name,  billing_email,  internal_risk_note,  tax_identifier)

A technician may need display_name but should not automatically receive tax_identifier or internal risk notes.

Split by sensitivity when useful

Customer(  customer_id,  display_name,  service_contact_email)CustomerBillingProfile(  customer_id,  tax_identifier,  billing_email,  billing_terms)

This is not mandatory in every design, but a separate table can create a clean authorization boundary.

Database roles

app_readapp_writereporting_readmigration_adminsupport_readonly

Use roles that correspond to capabilities rather than individual users when possible.

Application roles are not the same

The application may define:

techniciandispatcherbilling_managertenant_admin

while the database connection may use one service account. Authorization can exist in both layers, but the database should still limit the service account to what that service truly needs.

Avoid universal database credentials

A single credential with:

SELECT, INSERT, UPDATE, DELETEON ALL TABLES

for every service increases blast radius. Separate services should generally have separate credentials and grants.

Views as permission boundaries

CREATE VIEW technician_work_order_view ASSELECT work_order_id,       asset_id,       status_code,       problem_descriptionFROM work_order;

A role can receive SELECT on the view without direct access to every WorkOrder column.

Stored operations

Instead of granting broad table UPDATE, a service can be allowed to execute a narrow operation such as:

close_work_order(work_order_id, actor_id)

when the DBMS/security model supports safe encapsulation.

Column-level permissions

Some databases support column-specific grants. These can help with a few sensitive fields, though many fine-grained column grants become operationally hard to manage.

Row-level security

Row-level policies can restrict which rows a role sees:

tenant_id = current_tenant()

This is especially useful for multi-tenant systems, but policy correctness and connection context must be tested rigorously.

Read-only really means read-only

Reporting and support roles should not receive write privileges unless there is a specific operational requirement. Separate repair/admin tooling from ordinary diagnostic access.

Migration privileges

Schema migrations may require:

CREATEALTERDROPINDEXREFERENCES

The runtime application account usually should not have all of those privileges.

Ownership and DDL

Table ownership can bypass ordinary grants in some DBMSs. Use dedicated ownership roles carefully and avoid making routine application connections object owners.

Secrets are not ordinary columns

Database passwords, API keys, and encryption keys should not be stored as plaintext application data merely because “the database is secure.” Use secret-management systems and scoped credentials.

Service-to-table map

Permission review

Audit grants periodically. Privileges accumulate over time through debugging, incidents, and migrations. Remove obsolete grants instead of treating permissions as permanent.

Practice: technician access

Summary and next lesson

Least privilege begins with clear ownership and separable data responsibilities. Database roles, scoped service accounts, views, row-level controls, and restricted migration credentials reduce blast radius. The next lesson focuses on the data itself: classification, minimization, encryption, and privacy-aware modeling.

References

• NIST guidance on least privilege and access control.
• OWASP guidance on database security and authorization.
• DBMS documentation for roles, grants, views, and row-level security.