vault/Career/Database - SQL/Database Permissions, Roles, and Accounts.md

---
note type:
  - database
  - note
date: 2026-06-03
done: true
---
# 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

``` sql
CREATE LOGIN student_user
WITH PASSWORD = 'StrongPassword123!';
```

You can also create a login linked to Windows authentication.

``` sql
CREATE LOGIN [DOMAIN\Zaine] FROM WINDOWS;
```

## Database User

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

Example:

``` sql
USE SchoolDB;

CREATE USER student_user
FOR LOGIN student_user;
```

Now the login can access the **SchoolDB** database as the user **student<sub>user</sub>**.

# 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.

``` sql
GRANT SELECT
ON Students
TO student_user;
```

## Grant Multiple Permissions

``` sql
GRANT SELECT, INSERT
ON Students
TO student_user;
```

This allows the user to read and add new rows.

## Revoking Permissions

If a permission should be removed:

``` sql
REVOKE INSERT
ON Students
FROM student_user;
```

## Denying Permissions

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

``` sql
DENY DELETE
ON Students
TO student_user;
```

# 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

``` sql
CREATE ROLE student_role;
```

## Assign Permissions to the Role

``` sql
GRANT SELECT
ON Courses
TO student_role;
```

## Add Users to the Role

``` sql
ALTER ROLE student_role
ADD MEMBER student_user;
```

Now **student<sub>user</sub>** inherits all permissions from **student<sub>role</sub>**.

# 4\. Built-in Database Roles

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

Examples:

| Role Name               | Purpose                           |
| ----------------------- | --------------------------------- |
| db<sub>owner</sub>      | Full control over the database    |
| db<sub>datareader</sub> | Read all tables                   |
| db<sub>datawriter</sub> | Insert/update/delete all tables   |
| db<sub>ddladmin</sub>   | Create or modify database objects |

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

``` sql
ALTER ROLE db_datareader
ADD MEMBER student_user;
```

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

``` sql
CREATE ROLE student_role;
CREATE ROLE teacher_role;
CREATE ROLE admin_role;
```

## Step 2: Assign Permissions

Student role (read-only):

``` sql
GRANT SELECT
ON Courses
TO student_role;
```

Teacher role:

``` sql
GRANT SELECT, INSERT, UPDATE
ON Courses
TO teacher_role;
```

Admin role:

``` sql
GRANT CONTROL
ON DATABASE::UniversityDB
TO admin_role;
```

## Step 3: Add Users

``` 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;
```

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.