openskills.info
Course Preview

Database Privilege and Access Control

Database privilege and access control is the part of a database that decides which identity may connect, which data or administrative objects it may use, and which operations it may perform. Accounts, roles, grants, ownership, and row policies turn an organization’s access rules into checks the database enforces.

itDatabases and data storage

Database Privilege and Access Control

Database privilege and access control is the authorization layer inside a database system. It answers a narrow question for every attempted operation: may this identity perform this action on this object in this context? Authentication establishes the identity. Authorization evaluates its privileges. Keeping those two decisions separate makes failures easier to diagnose and policies easier to review.

A useful mental model has five parts:

  1. A principal represents a person, application, administrator, or workload.
  2. A role groups privileges around a job or service responsibility.
  3. A privilege permits an operation such as reading a table or creating a schema.
  4. A securable object is the database, schema, table, view, routine, column, or other resource being protected.
  5. A policy adds conditions that are finer than an object grant, such as which rows a tenant may see.

The database combines these parts into an effective permission set. Direct grants, inherited roles, ownership, built-in administrative powers, and public defaults may all contribute. A correct-looking role can therefore still produce excess access when another path adds privileges.

The authorization flow

A client first connects through an authentication method. The database maps the authenticated identity to a database principal and establishes session context. Some systems activate default roles automatically. Others let a session select or assume a role.

When the principal submits a statement, the database resolves the requested operation and target objects. A query can require more than one permission. Reading a view may also touch its underlying tables. Calling a routine may run with the caller's rights or the routine owner's rights. Creating an object can require permission on its parent schema as well as permission for the object type.

Continue the course

This section is part of the paid course.

See pricing to subscribe, or log in if you already have access.

Where this skill leads

Relevant careers

See how this topic contributes to broader role-level skill maps.

Sources