Huge updates

posts/career/database-permissions.org

@@ -1,9 +1,245 @@
-#+TITLE: Database permissions, roles and accounts 
+#+TITLE: Database Permissions, Roles, and Accounts
 #+OPTIONS: num:nil
 #+DATE: <2026-01-18 Sun 23:00> 
 #+filetags: :learning:notes:
-#+WIP: t
+#+WIP: 
 #+COMMENTS: t
 #+SLUG: database-permissions
 
-* TODO
+* 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.