12 Chapter 12 Protecting the DBMS
Fred Strickland
Original Material to the textbook: Fred Strickland
Learning Outcomes
Computing Sub Discipline |
Document Code, Reference Code, and Page Number |
Text |
National Security Agency |
Database Management Systems (DMS) |
4. Describe DBMS access controls, privilege levels, and security principles and apply them to a simple database. |
Introduction to Chapter 12
This chapter continues what Chapter 11 did not cover. We will look at protecting the DBMS.
Access Controls
As noted in Chapter 11, a functioning DBMS needs to provide support for
- Access controls
- Privilege levels
- Security principles
- Facilities for sequence of data
- Storing and processing large volumes of data
Chapter 11 looked briefly at access controls, privilege levels, security principles, and the means for sequencing data. In this chapter, we will go into greater detail concerning access controls.
There are different ways of providing access control services. Most authorities1 list the following four approaches:
- Discretionary Access Control (DAC)
- Mandatory Access Control (MAC)
- Role Based Access Control (RBAC)
- Attributed Based Access Control (ABAC)
Geeks for Geeks added the following approaches:
- History-Based Access Control (HBAC)
- Identity-Based Access Control (IBAC)
- Organization-Based Access Control (OrBAC)
- Rule-Based access Control (RAC
Omada added the following unique approaches:
- Policy-Based Access Control (PBAC)
- Time-Based Access Control (TBAC)
- Context-Based Access Control (CBAC)
- Break-Glass Access Control (BGAC)
- Risk-Adaptive Access Control (RAdAC)
The National security Agency in its Databases (DAT) Knowledge Unit requires that students be exposed to DAC, MAC, RBAC, and Clark-Wilson2.
There are three “players.”
- The user wishes to enter a restricted area.
- The administrator is the gatekeeper to the restricted area.
- The system infrastructure provides the necessary mechanisms.
We will examine at a high level how the various access controls function.
Discretionary Access Control (DAC)
Discretionary Access Control (DAC) uses the concept of resource owners. The owner creates the resource. The owner decides who will have access to that resource. In addition, the owner determines what the person can do with the resource, such as read, write, or execute3. With numerous owners of the numerous resources, there is no centralized office.
Example:
The share feature in Google Docs.
Pros of DAC
Flexibility: Resource owners can easily grant and revoke access permissions. It is straightforward to add or remove users or change their level of access as needed.
Simplicity: DAC systems do not need complex policies or central administration to implement – users directly manage access rights themselves. For small organizations, DAC the workload for a small IT team.
Cons of DAC
High-security risks: DAC systems are prone to data leaks. A user with sufficient access rights could make unauthorized changes or grant access to unauthorized users. Sometimes, the data leak may not even be intentional, especially for non-technical folks who may not know how access control works. They may end up accidentally sharing sensitive files with everyone instead of a specific group, for instance. (Have you ever e-mailed the wrong person?)
Weak ability to scale. In DAC, access is managed individually and becomes impractical as the number of resources increases. For example, when a new employee joins a company and requires access to multiple documents owned by different people, coordinating this access in a DAC system can be a total time drain – each document owner must individually grant access. (Have you ever dealt with an office and the task could not be done, because the person is on vacation?)
Propensity for permission creep: Over time, users might accumulate more permissions than they need for their current role, a phenomenon known as “permission creep.” This usually happens since permissions are added as users require access to new resources but the previous, unneeded resource accesses are not revoked. In a DAC environment, where users or resource owners manage permissions, the tracking and the auditing actions for preventing permission creep can be extremely challenging at scale.
Lack of centralized control: DAC systems lack a centralized directory of resources and access permissions. This makes it tough to enforce uniform security policies across the organization. It becomes nearly impossible to ensure everyone has the appropriate access level.
Challenges in role changes and user offboarding: In a DAC system, updating access rights when users change roles or leave the organization can be labor-intensive and prone to mistakes – access needs to be revoked and granted per resource. It is not uncommon for employees to continue having access to company resources long after termination. (Have you left an organization and later discovered that you still have access to the log-in system?)
Mandatory Access Control (MAC)
Mandatory Access Control (MAC) uses the concept of security labels. The owner creates the resource, but the owner does not decide who will have access to a resource. A hierarchical approach is used.
- Multiple levels with the higher levels being more restrictive.
- Individuals are cleared (approved) to a certain level and may see less restrictive documents.
There is a centralized office. There are security policies for classifying data and granting access.
Example:
The United States military uses Top Secret (TS), Secret (S), Confidential (C), and For Official Use Only (FOUO)4. Canada5 uses TS, S, C, Protected “C,” Protected “B,” and Protected “A.” An office would determine what the access level will be for a resource. A person cleared to access S would be able to access S and C, but not TS. Also, a person would need to have a valid reason to see something. Being a general in the United States Army does not grant access to an United States Air Force document. A military member stationed in North America does not have access to NATO information6.
|
|
|
|
A. Top Secret |
B. Secret |
C. Confidential |
D. For Official Use Only |
Figure 12.1 Four cover sheets used in the United States government
A. Top Secret cover sheet. Source of image: https://www.outsidethebeltway.com/wp-content/uploads/2008/04/top-secret-cover-sheet.jpg.
B. Secret cover sheet. Source of image: https://mediad.publicbroadcasting.net/p/kedm/files/styles/medium/public/201702/secret.jpg
C. Confidential cover sheet. Source of image: https://www.pdffiller.com/preview/0/58/58769/large.png
D. For Official Use Only cover sheet. Source of image: https://pdf4pro.com/cache/preview/9/a/b/2/d/f/d/4/thumb-9ab2dfd40bbdc1751f7188ec34f51581.jpg
Pros of MAC
Enhanced security: Once security policies are set, users cannot modify these security policies nor grant access to other users, even for the resources they create. Access has to be set by a central authority.
High level of data integrity and confidentiality: MAC systems enforce the Principle of Least Privilege (PLP). Users are on a need-to-know basis – they only access data absolutely necessary for their job which significantly reduces unauthorized data exposure or modification.
Cons of MAC
It is rigid: MAC struggles with temporary access needs for higher-level data. While there are workarounds, like resource reclassification or temporarily changing user clearance level, these efforts conflict with MAC’s fundamental principle of sticking strictly to set security protocols7.
Administrative overhead: MAC requires intensive upfront planning to properly classify every resource and assign users clearance. It is usually a never-ending task of regularly checking and updating classifications and categorizations8.
MAC is implemented in Security Enhanced Linux9.
Role-Based Access Control (RBAC)
Role-Based Access Control (RBAC) uses the concept of roles for determining access. In a civilian environment, these roles might be human resource manager, IT manager, intern, sales representative. In a military environment, these roles might be combat unit, missile unit, special police, and so on. These roles are based on an organization’s structure and the operational needs. The roles would have a set of responsibilities and duties. A person would be assigned a role and that in turn would grant access to the necessary resources. A person could be assigned a second role. Or a person could change roles. It would be a simple matter of adding or removing a role from the person’s profile. This approach supports the security principles of least privilege and the separation of privileges.
- A manager would have the worker role profile plus some extras.
Example:
A person filling the role of human resource manager would be able to see all the information for employees of the company, but not the work orders. A person filling the role of office manager would see only the details needed for making work assignments and the details on the work orders.
Pros of RBAC
Efficient management of permissions: It is easy to handle changes like employees joining, or leaving, or moving within the organization. Instead of reconfiguring the permissions for each user, administrators would simply update the user’s role assignments.
Scalability: As an organization grows or departments are restructured, new roles can be added, modified, or removed. It is easier to do a mass reassignment for groups of users at the same time.
Consistent permissions: RBAC ensures all users with the same role have the same access rights. This reduces inconsistencies where some users have more access rights than their role requires.
Easy to monitor: The management is at the role or group level instead of at the individual level.
Simple to review: Groups of roles is easier to review and update than attempting to do these tasks at the individual level.
Cons of RBAC
Role proliferation: Over time, the number of roles can grow excessively. This can lead to role proliferation. The system can become cluttered, making it harder for administrators to keep track of the permissions that each role has.
Limited scope: In organizations, where job roles are not well-defined or employees frequently switch roles or take on multiple roles, RBAC may be too rigid. Administrators would need to change employees’ role every time they take on a project outside their usual role.
Not granular enough: If a person takes on a special project, then the administrator would need to define a unique role. That increases the workload and the risk that the unique role is not revoked at the end of the project.
Attributed-Based Access Control (ABAC)
Attribute-Based Access Control (ABAC) combines features of the user’s attributes such as the department or job title (RBAC like), the resource’s status such as confidentiality level (MAC like) and ownership (DAC like), and the current environment such as time of access or location. This provides more granular control than RBAC or the other access control schemes.
Example:
A person filling the role of human resource manager would be able to see all the information for employees of the company, but not the work orders. Access would only be granted during the work week and when the person is in the building (no remote access).
Outside of the United States, citizens of the host country are prevented from viewing certain documents.
Pros of ABAC
This has the benefits of DAC, of MAC, and of RBAC.
Fine-grained access control: ABAC provides highly granular control over access to resources. It allows for precise definitions of access rules based on multiple attributes of users, resources, and the environment. This granularity ensures that users have access to exactly what they need, no more and no less.
Flexibility and adaptability: Policies can be updated without the need to reconfigure the entire access control system.
Dynamic policy enforcement: ABAC can make access decisions in real time by taking into account the current context including factors such as the time of day, the user location, or the current network threat level.
Cons of ABAC
This has the drawbacks of DAC, of MAC, and of RBAC.
Complex policy management: ABAC is complex, because it is involved in defining and managing access control policies. As the number of attributes increases, the policies become more complex and the system becomes more difficult to manage and to understand. This complexity can lead to errors in configuring and assigning policies and potentially cause security vulnerabilities.
Implementation challenges: Setting up an ABAC system requires a deep understanding of the kind of access control the organization needs and a thorough mapping of attributes and policies.
Challenging to launch: This requires spending time understanding the needs of the organization and defining the rules for access the resources.
Omada and Geeks for Geeks listed several access control systems that are rarely mentioned. These will be covered quickly in order to have complete coverage of the various access control systems.
History-Based Access Control (HBAC)
History-Based Access Control (HBAC) looks at the history of the person. Is the request normal for this person? Is the timing of this request normal for this person?
The drawback of this approach is that should there be a surge requirement this approach might block access to the needed resources.
Identity-Based Access Control (IBAC)
Identity-Based Access Control (IBAC) grants access based on the identity of the user and on the granted credentials. This is similar to DAC in that the access control is done on an individual level instead of a group level.
Organization-Based Access Control (OrBAC)
Organization-Based Access Control (OrBCA) separates the security policy from the activities that must implement a security policy.
Policy-Based Access Control (PBAC)
Policy-Based access Control (PBAC) evaluates access rights and entitlements based on new organizational policies. This may require changing previously defined accesses. This is similar to ABAC, but the difference is that organizational policies are fed into the PBAC “black box.”
Example:
A university has had a long-standing policy of shutting down access to computer labs on the weekend. A new computer lab manager has been hired and that person wants the computer labs to be available on weekends. The PBAC would receive this policy change and immediately translate this into a new access control.
Pros of PBAC
This has the benefits of RBAC.
Fine-grained access control: PBAC provides highly granular control over access to resources. It allows for precise definitions of access rules based on multiple attributes of users, resources, and the environment. This granularity ensures that users have access to exactly what they need, no more and no less.
Reactive to changed and to new organizational policies: Policies are the driver of the entire access control system.
Achieves compliance: PBAC implements any policies that the governance committee determines. The governance committee understands the international requirements, the central government laws, the local area government requirements, and the organization requirements. The IT department does not have this deep understanding of these items.
Better placement of responsibilities: Since the governance committee has the better understanding of the compliance requirements, they can do a better job of ensuring compliance. The responsibilities will be on the governance committee instead of the IT department.
Cons of PBAC
This has the drawbacks of RBAC.
Quality of the implementation: The governance committee needs to understand their role and the impact their actions will have on the organization.
Rule-Based access Control (RAC)
Rule-Based Access Control (RAC) is based on a set of predefined rules. This is similar to PBAC, except there is no governance committee creating the rules.
Time-Based Access Control (TBAC)
Time-Based Access Control (TBAC) grants access to users based on specific timeframes.
Context-Based Access Control (CBAC)
Context-Based Access Control (CTAC) makes access decisions based on the context of the request such as location, device used, or the user’s behavior patterns.
Example
An individual is granted access to a list of call signs that become operational at the beginning of the workday, but is not granted access to call signs for a future day.
Break-Glass Access Control (BGAC)
Break-Glass Access Control (BGAC) permits users to bypass a regularly used access control system during an urgent situation. The name comes from the old fire alarm boxes. See Figure 12.2
Figure 12.2 A break-glass fire alarm box. Source of image: https://5.imimg.com/data5/YO/QY/MY-24188010/manual-fire-alarm-system-500×500.jpg
Example
There is a fire in a secure area. Fire fighters would be granted access to the secure area. The normal access procedures would be set aside. At the end of the fire episode, then they would be documented and debriefed.
Risk-Adaptive Access Control (RAdAC10)
Risk-Adaptive Access Control (RAdAC) adjusts the access in real time based on the current risk level, users’ behaviors, the network conditions, and the potential threats.
Example
An office is located outside of North America in a third world location. Things are peaceful. Then one day, the barbarians (see Figure 12.3) cross the border and begin to destroy things. The threat level has gone up greatly. It is possible that employees could be captured and forced to reveal their login credentials. RAdAC would require more effort to log onto the network. It might turn off remote access to the network.
Figure 12.3 An artist depiction of Vandals marching on Rome in A.D. 45 (Image Credit: Lanmas via Alamy Stock Photo). Source of image: https://www.livescience.com/who-were-the-vandals
The Clark-Wilson Model
In a cybersecurity program, there may be a course that covers classic security models such as the Bell-LaPadula model, the Biba model, and the Clark-Wilson model11.
The first two models had an approach that related to a person with a certain clearance can view and can create. In contrast, the Clark-Wilson Model strives to ensure the integrity and confidentiality of data. This is different from the previously covered access control models, which addressed only permission to access a resource.
The Clark-Wilson Model has three entities:
- Subject: This is any user that is request a data item.
- Constrained Data Item: The subject is not permitted to directly access the desired data item.
- Unconstrained Data Item: The subject can make direct access to the desired data item.
In addition to the three entities, there are two components:
- The Transformation Process Component: The subject’s request for accessing a constrained data item is routed to the transformation process. The transformation process converts the request into a permission and forwards the package to the integration verification process.
- Integration Verification Process Component: This component will perform Authentication and Authorization actions. If these two are successful, then the subject is granted access to the desired constrained data item.
Figure 12.4 illustrates the steps in the Clark-Wilson Model.
Figure 12.4 The Clark-Wilson Model. Source of image: https://www.geeksforgeeks.org/introduction-to-classic-security-models/
The Geeks for Geeks article did not mention that the Clark-Wilson Model enforces the principle of separation of duties and tracks a person’s activities and actions. VPN Unlimited provided some tips on how to implement the Clark-Wilson Model and the first tip directed the reader to implement RBAC12.
What Access Controls Cannot Address
Access controls cannot three major areas:
- Inside threats. Access controls are designed to prevent unauthorized access. Access controls cannot stop an authorized user from misusing their access or stealing data.
- Human error. Access controls are defined and managed by humans. And humans do make mistakes. A common mistake would be the incorrect setting of permissions. Access controls will faithfully support those permission settings.
- Non-access related security threats. Access controls cannot address external cybersecurity threats such as hackers, viruses, malware, and phishing attacks. Access controls cannot prevent data loss such as from accidental deletion, or data corruption. Access controls cannot prevent data leakage that would happen if the data is sent over insecure channels13.
Access Control and Securing the SQL Server
Cybersecurity practitioners talk about defense in layers.
The Physical Security Layer
This would be locked rooms with restricted access to the database server hardware and the supporting networking devices.
The Operating System Security Layer
Operating systems need to be updated in order to have good security.
Host firewalls14 add another piece to the operating system security layer. A firewall is a separator or a restrictor of network traffic. The firewall supports an organization’s data security policy.
The Microsoft SQL Server uses the operating system for its operation and for data storage. The operating system can be configured to restrict access to these files.
Microsoft’s Use of the Role-Based Access Control (RBAC)
Recall that RBAC defines roles and individuals are assigned to those roles. Microsoft defines three types of SQL server roles:
- Fixed SQL Server Roles: These are predefined roles. These cannot be changed nor deleted. These roles were created during the installation of the SQL Server.
- sysadmin
- bulkadmin
- dbcreator
- diskadmin
- User-Defined SQL Server Roles: These are created to support the needs of the organization. The following are some examples of these:
- Operations manager role
- Human resource worker role
- SQL Server Application Roles: These are used by an application instead of by individuals. The intent is to keep regular users and application users separate and safe.
These same roles are defined at the database level:
- Fixed SQL Server Database Roles: These are predefined roles. These cannot be changed nor deleted. These roles were created during the creation of a database.
- db_owner
- db_accessadmin
- db_backupoperator
- db_datatreader
- User-Defined SQL Server Database Roles: These are created to support the needs of the organization. These provide more granular control over what users may access.
- SQL Server Application Database Roles: These are used by an application instead of by individuals. This adds another layer of security.
In addition to defining roles, Microsoft expresses the RBAC concept in terms of principals, securables, and permissions.
A principal is an entity that can be authenticated. The Windows login can be used as a principal for determining who may connect to a SQL Server database. SQL Server supports three principals types:
- Logins: These exist at the server level.
- Users: These exist at the database level.
- Roles: These can exist at either level as noted previously.
A securable is a SQL Server resource that can be accessed by a principal. These are the actual resources that need to be protected at the sever level or at the database level or at the schema level.
A permission is an access that is granted on a securable for a specific principal. For example, a person logs in via a Windows login (the principal) and this grants the ability to view data (the permission) in a specific database schema (the securable).
Encryption and Certificates
Encryption makes a text unreadable and thus limits the loss of data should a hacker is able to penetrate the previous layers. Given enough time, any encryption scheme can be broken. In 2024, a 56-bit size encryption key could be broken in a day or two. A 256-bit has so many combinations that it would take millions of years to try every combination15.
A certificate is a software key that is shared between servers that enables secure communications by way of strong authentication. Certificates are created by using the SQL Server Transact-SQL commands. These are used to enhance object and connection security.
Application Security
Client programs can play a part by being written in a secure fashion. The topic of secure coding will be addressed in another chapter.
On Windows computers, the Windows Defender Application Control prevents unauthorized code execution.
Other Security Layers and Tools
SQL Server has tools and utilities for configuring and administering security.
The SQL Server’s Database Engine exposes security information. A view limits what a person can see and can do. Functions can restrict what can be accessed.
Key Terms
access control: This is a method for restricting access to certain resources by certain individuals.
Attribute-Based Access Control (ABAC): This combines features of the user’s attributes such as the department or job title (RBAC like), the resource’s status such as confidentiality level (MAC like) and ownership (DAC like), and the current environment such as time of access or location.
Break-Glass Access Control (BGAC): This permits users to bypass a regularly used access control system during an urgent situation. The name comes from the old fire alarm boxes.
Clark-Wilson Model: This strives to ensure the integrity and confidentiality of data. This is different from the various access control models, which addressed only permission to access a resource.
Context-Based Access Control (CTAC): This makes access decisions based on the context of the request such as location, device used, or the user’s behavior patterns.
Discretionary Access Control (DAC): This uses the concept of resource owners. The owner created the resource. The owner decides who will have access to a resource. In addition, the owner determines what the person can do with the resource, such as read, write, or execute. With numerous owners of the numerous resources, there is no centralized office.
encryption: This makes a text unreadable and thus limits the loss of data should a hacker is able to penetrate the previous layers.
firewall: This is a separator or a restrictor of network traffic.
Fixed SQL Server Database Roles: These are predefined roles. These cannot be changed nor deleted. These roles were created during the creation of a database
Fixed SQL Server Roles: These are predefined roles. These cannot be changed nor deleted. These roles were created during the installation of the SQL Server.
History-Based Access Control (HBAC): This looks at the history of the person.
functions: These are pieces of code that can restrict what is accessed
Identity-Based Access Control (IBAC): This grants access based on the identity of the user and on the granted credentials.
logical access controls: These limit connections to computer networks, system files, and data. These are provided via software and these support letting certain individuals or groups to gain access to sensitive information
Mandatory Access Control (MAC): This uses the concept of security labels. The owner creates the resource, but the owner does not decide who will have access to a resource. A hierarchical approach is used.
Organization-Based Access Control (OrBCA): This separates the security policy from the activities that must implement a security policy.
permission: In the context of Microsoft usage of RBAC, this is an access that is granted on a securable for a specific principal.
physical access controls: These are physical means such as fences, locked doors, and guards.
Policy-Based access Control (PBAC): This evaluates access rights and entitlements based on new organizational policies.
principal: In the context of Microsoft usage of RBAC, this is an entity that can be authenticated.
Principle of Least Privilege (PLP): This directs that users can only see what they need for their job.
Risk-Adaptive Access Control (RAdAC): This adjusts the access in real time based on the current risk level, users’ behaviors, the network conditions, and the potential threats.
Role-Based Access Control (RBAC): This uses the concept of roles for determining access.
Rule-Based Access Control (RAC): This is based on a set of predefined rules. This is similar to PBAC, except there is no governance committee creating the rules.
securable: In the context of Microsoft usage of RBAC, this is a SQL Server resource that can be accessed by a principal.
SQL Server Application Database Roles: These are used by an application instead of by individuals. This adds another layer of security.
SQL Server Application Roles: These are used by an application instead of by individuals. The intent is to keep regular users and application users separate and safe.
Time-Based Access Control (TBAC): This grants access to users based on specific timeframes.
User-Defined SQL Server Database Roles: These are created to support the needs of the organization. These provide more granular control over what users may access.
User-Defined SQL Server Roles: These are created to support the needs of the organization.
view: In the context of Microsoft usage, this limits what a person can see and can do.
Exercises
1. Describe DBMS access controls, privilege levels, and security principles. 14 access controls were covered in this chapter. Answer for DAC, for MAC, for RBAC, and for Clark-Wilson plus six more.
[CS2013 IM/Database Systems 2 and National Security Agency DMS 4]
2. Define or explain the following terms:
- access control
- Attribute-Based Access Control (ABAC)
- authentication
- authorization
- Include in your answer five examples.
- Break-Glass Access Control (BGAC)
- Clark-Wilson Model
- Context-Based Access Control (CTAC)
- Discretionary Access Control (DAC)
- encryption
- firewall
- Fixed SQL Server Database Roles
- Fixed SQL Server Roles
- History-Based Access Control (HBAC)
- functions
- Identity-Based Access Control (IBAC)
- logical access controls
- Mandatory Access Control (MAC)
- Organization-Based Access Control (OrBCA)
- permission
- physical access controls. These are physical means such as fences, locked doors, and guards.
- Policy-Based access Control (PBAC)
- principal
- Principle of Least Privilege (PLP)
- Risk-Adaptive Access Control (RAdAC)
- Role-Based Access Control (RBAC)
- Rule-Based Access Control (RAC)
- securable
- SQL Server Application Database Roles
- SQL Server Application Roles
- Time-Based Access Control (TBAC)
- User-Defined SQL Server Database Roles
- User-Defined SQL Server Roles
- view
3. List the three players in an access control system.
4. What is the concept of separation of duties?
5. List and explain the three situations that access controls cannot address.
6. List and explain the five security layers used by Microsoft for securing SQL Server.
7. In the context of the Microsoft SQL Server, explain principals, securables, and permissions.
Bonus Questions
BQ1. Which company was involved in the development of SELinux?
BQ2. Research and write about the Bell-LaPadula model.
BQ3. Research and write about the Biba model.
A Running Project
Continue to work on your project.
Attribution
This chapter of Database Design is a brand-new addition.
This chapter drew from many sources.
Image Attribution
No second edition images were used.
References
“4 Types of Access Control: What you Need to Know + How to Implement,” WorkOS, April 24, 2024. https://workos.com/blog/access-control
Access Control 101: A Comprehensive Guide to Database Access Control,” Satori, n.d. https://satoricyber.com/access-control/access-control-101-a-comprehensive-guide-to-database-access-control/
“Access Control in Computer Network,” Geeks for Geeks, July 19, 2024. https://www.geeksforgeeks.org/access-control-in-computer-network/
“Clark-Wilson Model: Enhancing Data Integrity and Security,” VPN Unlimited, n.d. https://www.vpnunlimited.com/help/cybersecurity/clark-wilson-model
“Introduction To Classic Security Models,” Geeks for Geeks, July 11, 2022. https://www.geeksforgeeks.org/introduction-to-classic-security-models/
“Oracle Database 19c Technical Architecture,” Oracle, 2019. https://www.oracle.com/webfolder/technetwork/tutorials/architecture-diagrams/19/pdf/db-19c-architecture.pdf
Oracle does have a tutorial that explains the architecture in understandable terms. See “Oracle Database Architecture,” Oracle Tutorial, n.d. https://www.oracletutorial.com/oracle-administration/oracle-database-architecture/
Robert Sheldon. “SQL Server Access Control: The Basics,” redgate, August 2, 2016. https://www.red-gate.com/simple-talk/databases/sql-server/database-administration-sql-server/sql-server-access-control-basics/
Nivritti Suste. “SQL Server Database and Server Roles for Security and Permissions,” MS SQL Tips, August 13, 2024. https://www.mssqltips.com/sqlservertip/8045/sql-server-database-and-server-roles-for-security-and-permissions/
Van To, William Assaf, Dennis Rea, et al. “Securing SQL Server,” Learn Microsoft, August 25, 2023. https://learn.microsoft.com/en-us/sql/relational-databases/security/securing-sql-server
“What are the Different Types of Access Control?” Omada, n.d. https://omadaidentity.com/resources/blog/what-are-the-different-types-of-access-control/