org_roam/20260305130457-database_perms_roles_accounts.org

Database Permissions, Roles, and Accounts

• Introduction
• 1. Database Accounts
  • Login (Server Level)
  • Database User
• 2. Permissions
  • Granting Permissions
  • Grant Multiple Permissions
  • Revoking Permissions
  • Denying Permissions
• 3. Roles
  • Creating a Role
  • Assign Permissions to the Role
  • Add Users to the Role
• 4. Built-in Database Roles
• 5. Example: Simple University Database Security
  • Step 1: Create Roles
  • Step 2: Assign Permissions
  • Step 3: Add Users
• 6. Why Roles Are Important
• Summary

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

CREATE LOGIN student_user
WITH PASSWORD = 'StrongPassword123!';

You can also create a login linked to Windows authentication.

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:

USE SchoolDB;

CREATE USER student_user
FOR LOGIN student_user;

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.

GRANT SELECT
ON Students
TO student_user;

Grant Multiple Permissions

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:

REVOKE INSERT
ON Students
FROM student_user;

Denying Permissions

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

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

CREATE ROLE student_role;

Assign Permissions to the Role

GRANT SELECT
ON Courses
TO student_role;

Add Users to the Role

ALTER ROLE student_role
ADD MEMBER student_user;

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.

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

CREATE ROLE student_role;
CREATE ROLE teacher_role;
CREATE ROLE admin_role;

Step 2: Assign Permissions

Student role (read-only):

GRANT SELECT
ON Courses
TO student_role;

Teacher role:

GRANT SELECT, INSERT, UPDATE
ON Courses
TO teacher_role;

Admin role:

GRANT CONTROL
ON DATABASE::UniversityDB
TO admin_role;

Step 3: Add Users

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.