org_web/posts/career/database-permissions.org

#+TITLE: Database Permissions, Roles, and Accounts
#+OPTIONS: num:nil
#+DATE: <2026-01-18 Sun 23:00> 
#+filetags: :learning:notes:
#+WIP: 
#+COMMENTS: t
#+SLUG: database-permissions

* Introduction
Database security is a crucial part of database administration. It ensures that only authorised users can access, modify, or manage data. Three core concepts used to control access are:

1. Accounts (logins/users)
2. Roles
3. Permissions

These concepts work together to create structured and secure access control inside a database system.

* 1. Database Accounts

A *database account* represents an identity that can connect to the database system. In Microsoft SQL Server this is typically split into two layers:

- *Login* → Authentication at the server level
- *User* → Authorisation inside a specific database

** Login (Server Level)

A login allows someone or something to authenticate with the SQL Server instance.

Example: Creating a login

#+BEGIN_SRC sql
CREATE LOGIN student_user
WITH PASSWORD = 'StrongPassword123!';
#+END_SRC

You can also create a login linked to Windows authentication.

#+BEGIN_SRC sql
CREATE LOGIN [DOMAIN\Zaine] FROM WINDOWS;
#+END_SRC

** Database User

A login must be mapped to a user inside a database before it can access that database.

Example:

#+BEGIN_SRC sql
USE SchoolDB;

CREATE USER student_user
FOR LOGIN student_user;
#+END_SRC

Now the login can access the *SchoolDB* database as the user *student_user*.

* 2. Permissions

Permissions define *what actions a user can perform*. These actions include reading data, inserting rows, modifying tables, or executing procedures.

Common SQL Server permissions include:

- SELECT → Read data
- INSERT → Add new data
- UPDATE → Modify data
- DELETE → Remove data
- EXECUTE → Run stored procedures
- ALTER → Modify database objects
- CONTROL → Full control over an object

** Granting Permissions

Permissions are given using the *GRANT* statement.

Example: Allow a user to read data from a table.

#+BEGIN_SRC sql
GRANT SELECT
ON Students
TO student_user;
#+END_SRC

** Grant Multiple Permissions

#+BEGIN_SRC sql
GRANT SELECT, INSERT
ON Students
TO student_user;
#+END_SRC

This allows the user to read and add new rows.

** Revoking Permissions

If a permission should be removed:

#+BEGIN_SRC sql
REVOKE INSERT
ON Students
FROM student_user;
#+END_SRC

** Denying Permissions

A *DENY* explicitly blocks an action, even if another role grants it.

#+BEGIN_SRC sql
DENY DELETE
ON Students
TO student_user;
#+END_SRC

* 3. Roles

Roles are collections of permissions that can be assigned to multiple users. They simplify permission management by allowing administrators to assign permissions once and reuse them.

Instead of granting permissions to many individual users, you grant them to a role.

Example scenario:

- Many students should be able to view course data.
- Instead of assigning permissions to each student individually, create a role.

** Creating a Role

#+BEGIN_SRC sql
CREATE ROLE student_role;
#+END_SRC

** Assign Permissions to the Role

#+BEGIN_SRC sql
GRANT SELECT
ON Courses
TO student_role;
#+END_SRC

** Add Users to the Role

#+BEGIN_SRC sql
ALTER ROLE student_role
ADD MEMBER student_user;
#+END_SRC

Now *student_user* inherits all permissions from *student_role*.

* 4. Built-in Database Roles

SQL Server includes several predefined roles that already have common permission sets.

Examples:

| Role Name     | Purpose                           |
|---------------+-----------------------------------|
| db_owner      | Full control over the database    |
| db_datareader | Read all tables                   |
| db_datawriter | Insert/update/delete all tables   |
| db_ddladmin   | Create or modify database objects |

Example: Add a user to the read-only role.

#+BEGIN_SRC sql
ALTER ROLE db_datareader
ADD MEMBER student_user;
#+END_SRC

This allows the user to read all tables without giving modification rights.

* 5. Example: Simple University Database Security

Assume a database called *UniversityDB* with two tables:

- Students
- Courses

Goal:

- Students → Read course information
- Teachers → Modify course data
- Admin → Full control

** Step 1: Create Roles

#+BEGIN_SRC sql
CREATE ROLE student_role;
CREATE ROLE teacher_role;
CREATE ROLE admin_role;
#+END_SRC

** Step 2: Assign Permissions

Student role (read-only):

#+BEGIN_SRC sql
GRANT SELECT
ON Courses
TO student_role;
#+END_SRC

Teacher role:

#+BEGIN_SRC sql
GRANT SELECT, INSERT, UPDATE
ON Courses
TO teacher_role;
#+END_SRC

Admin role:

#+BEGIN_SRC sql
GRANT CONTROL
ON DATABASE::UniversityDB
TO admin_role;
#+END_SRC

** Step 3: Add Users

#+BEGIN_SRC sql
ALTER ROLE student_role ADD MEMBER student_user;
ALTER ROLE teacher_role ADD MEMBER teacher_user;
ALTER ROLE admin_role ADD MEMBER admin_user;
#+END_SRC

Now permissions are organised through roles instead of assigning them individually.

* 6. Why Roles Are Important

Roles provide several benefits:

- *Simpler management* → Change permissions in one place
- *Scalability* → Works well with many users
- *Security consistency* → Reduces risk of incorrect permissions
- *Easier auditing* → Clear structure of access control

Without roles, administrators would need to manually manage permissions for every individual user.

* Summary

Database access control relies on three key components:

- *Accounts* identify who is accessing the system (logins and users).
- *Permissions* define what actions can be performed.
- *Roles* group permissions together for easier management.

In Microsoft SQL Server, administrators typically create logins, map them to database users, assign them to roles, and grant permissions to those roles. This layered approach ensures a secure and manageable database system.