5.5 KiB
Executable File
note type, date, done
| note type | date | done | ||
|---|---|---|---|---|
|
2026-06-03 | 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:
- Accounts (logins/users)
- Roles
- 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 studentuser.
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 studentuser inherits all permissions from studentrole.
4. Built-in Database Roles
SQL Server includes several predefined roles that already have common permission sets.
Examples:
| Role Name | Purpose |
|---|---|
| dbowner | Full control over the database |
| dbdatareader | Read all tables |
| dbdatawriter | Insert/update/delete all tables |
| dbddladmin | 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.