← Back to quizzesFree quiz

Access Control and Database Security Fundamentals

Access control is the cornerstone of information security . It determines who can access which resources and under what conditions. The most widely used models include Discretionary Access…

10 questions~5 min
Access Control and Database Security Fundamentals — Qwi
0 / 10
Score: 0%
1

Which access control model determines permissions based on user roles and predefined rules?

2

In a UNIX file system, what does the sticky bit on a directory enforce?

3

A database administrator wants to grant a user the ability to read and update a table but not to delete rows. Which SQL command best expresses this intent?

4

Which statement best distinguishes ABAC from RBAC?

5

During a SQL injection attack, an attacker terminates the original query string with "--". What is the primary purpose of this comment marker?

6

A protection domain in an access matrix corresponds to which of the following?

7

Which of the following is a key limitation of encrypting an entire database rather than individual fields?

8

In the context of data center tiers defined by TIA‑942, which tier provides the highest level of redundancy and fault tolerance?

9

When implementing a discretionary access control (DAC) scheme, which structure is most commonly used to represent permissions?

10

A user attempts to access a file, but the system first selects the most appropriate ACL before checking permissions. What is the purpose of this two‑step process?

Understanding Access Control Models

Access control is the cornerstone of information security. It determines who can access which resources and under what conditions. The most widely used models include Discretionary Access Control (DAC), Mandatory Access Control (MAC), Role‑Based Access Control (RBAC), and Attribute‑Based Access Control (ABAC). This section focuses on the model that bases permissions on user roles and predefined rules.

Role‑Based Access Control (RBAC)

RBAC assigns permissions to roles rather than to individual users. A user acquires the permissions of a role by being assigned to that role. This approach simplifies administration, especially in large organizations where many users share similar job functions.

  • Key Benefits: Centralized policy management, reduced risk of privilege creep, and easier compliance auditing.
  • Typical Use Cases: Enterprise applications, cloud platforms, and database systems where job titles (e.g., analyst, manager) map directly to access rights.

When you see a question like "Which access control model determines permissions based on user roles and predefined rules?", the correct answer is Role‑Based Access Control (RBAC).

UNIX File System Permissions and the Sticky Bit

UNIX and Linux file systems use a combination of read (r), write (w), and execute (x) bits to control access. An often‑overlooked permission is the sticky bit, represented by the letter t in the permission string.

What Does the Sticky Bit Do?

When set on a directory, the sticky bit restricts file deletion and renaming to the file’s owner, the directory’s owner, or the super‑user. This is why shared directories such as /tmp use the sticky bit: any user can create files, but only the creator (or root) can remove or rename them.

  • Example permission string: drwxrwxrwt – the final t indicates the sticky bit is active.
  • Without the sticky bit, any user with write permission could delete or rename any file in the directory.

Therefore, the correct answer to "In a UNIX file system, what does the sticky bit on a directory enforce?" is: Only the file owner may rename, move, or delete that file.

Granular Database Privileges with SQL GRANT

Database administrators (DBAs) often need to grant specific rights without exposing unnecessary capabilities. The SQL GRANT statement lets you assign SELECT, INSERT, UPDATE, DELETE, and other privileges on a per‑object basis.

Granting Read and Update, but Not Delete

To allow a user to read (SELECT) and modify (UPDATE) rows while preventing them from deleting rows, you would issue a command such as:

GRANT SELECT, UPDATE ON table_name TO user_name;

This command explicitly omits the DELETE privilege, ensuring the user cannot remove records.

Thus, the correct answer to the quiz question about granting read and update rights without delete is the GRANT SELECT, UPDATE ON table_name TO user_name; statement.

Comparing ABAC and RBAC

Both ABAC and RBAC are modern access‑control frameworks, but they differ fundamentally in how policies are evaluated.

Attribute‑Based Access Control (ABAC)

ABAC evaluates access decisions based on a combination of attributes:

  • Subject attributes – e.g., user department, clearance level.
  • Object attributes – e.g., data classification, owner.
  • Environmental attributes – e.g., time of day, location, device type.

Policies are expressed as logical expressions (e.g., subject.department == "HR" && object.classification == "confidential").

Key Distinction

The statement that best distinguishes ABAC from RBAC is: "ABAC evaluates policies based on attributes of subjects, objects, and environment, while RBAC relies solely on role assignments." This highlights ABAC’s dynamic, context‑aware nature versus RBAC’s static role mapping.

SQL Injection and the Use of Comment Markers

SQL injection remains one of the most common web‑application vulnerabilities. Attackers manipulate input fields to alter the intended SQL query. A typical technique involves appending the double‑dash comment marker (--) to truncate the original query.

Purpose of the -- Marker

When an attacker adds --, everything that follows on the same line is treated as a comment and ignored by the database engine. This effectively removes any legitimate clauses that might otherwise cause a syntax error or reveal the injection.

  • Example vulnerable query: SELECT * FROM users WHERE username = '$input'
  • Injected payload: admin' --
  • Resulting query: SELECT * FROM users WHERE username = 'admin' -- (the trailing part is ignored).

Consequently, the primary purpose of the comment marker is to prevent the database from executing any further legitimate clauses.

Understanding Protection Domains in Access Matrices

An access matrix is a conceptual model that maps subjects (users, processes) to objects (files, databases) and the rights each subject holds over each object. Within this matrix, a protection domain represents a row that defines a set of objects and the associated rights for a particular subject.

Why Rows Matter

Each row (protection domain) groups all permissions granted to a single subject, making it easier to manage and audit security policies. Columns, on the other hand, represent individual objects.

Therefore, the correct answer to the question about a protection domain is: A row defining a set of objects and associated rights.

Full‑Database Encryption vs. Field‑Level Encryption

Encrypting data at rest is a critical defense against unauthorized disclosure. However, the granularity of encryption—whether the entire database or specific fields—is an important design decision.

Key Limitation of Whole‑Database Encryption

When the entire database is encrypted, the key management overhead increases dramatically. Every backup, replication, and restore operation must handle the encryption keys securely. Additionally, performance can suffer because the database engine must decrypt large volumes of data for routine queries.

  • Field‑level encryption allows selective protection of sensitive columns (e.g., credit‑card numbers) while keeping the rest of the data readily searchable.
  • Whole‑database encryption simplifies the encryption process but can hinder fine‑grained access control and auditing.

The quiz answer reflecting this limitation is: Key management becomes more complex and performance degrades.

Data Center Tier Classification (TIA‑942)

The Telecommunications Industry Association (TIA) defines four tiers for data‑center infrastructure, each offering increasing levels of redundancy and fault tolerance.

Tier Overview

  • Tier I – Basic site infrastructure with no redundancy.
  • Tier II – Redundant components for non‑critical systems.
  • Tier III – Concurrently maintainable; any component can be taken offline without affecting operations.
  • Tier IV – Fault‑tolerant; provides multiple independent distribution paths and fully redundant components.

Thus, the tier that provides the highest level of redundancy and fault tolerance is Tier IV.

Putting It All Together: Best Practices for Secure Access Control and Database Protection

Combining the concepts covered above yields a robust security posture:

  • Adopt RBAC for most user‑role scenarios, and supplement with ABAC when context‑aware decisions are needed.
  • Use the sticky bit on shared directories to prevent accidental or malicious file deletions.
  • Grant the least privileges required—e.g., GRANT SELECT, UPDATE without DELETE—to reduce the impact of compromised accounts.
  • Sanitize inputs and employ prepared statements to mitigate SQL injection attacks; understand how comment markers are used by attackers.
  • Model your access matrix carefully; recognize that each protection domain (row) encapsulates a subject’s rights.
  • Balance encryption strategies: use whole‑database encryption for broad protection, but apply field‑level encryption for highly sensitive data to maintain performance and manageability.
  • When designing or selecting a data center, aim for at least Tier III availability, with Tier IV for mission‑critical workloads.

By integrating these practices, organizations can achieve a layered defense that safeguards both access control mechanisms and the underlying data.