AP Cybersecurity Topic 2.5: Access Controls | Complete Lesson
Topic 2.5: Access Controls
Who gets in, what they can do, and how the system enforces both — the identity and authorization layer that determines whether a breach stops at the perimeter or reaches the data.
- 2.5.1 — Learning Objectives(3 min)
- 2.5.2 — Authentication vs. Authorization(8 min)
- 2.5.3 — Essential Vocabulary & Exam Tips(10 min)
- 2.5.4 — The Three Authentication Factors In Depth(10 min)
- 2.5.5 — Access Control Models(10 min)
- 2.5.6 — Least Privilege, Separation of Duties & Privilege Creep(8 min)
- 2.5.7 — Real-World Case Studies(8 min)
- 2.5.8 — Defense Strategies(6 min)
- 2.5.9 — Worked Examples: Predict First(5 min)
- 2.5.10 — AP Exam Strategy(5 min)
- 2.5.11 — Frequently Asked Questions(3 min)
12.5.1 — Learning Objectives
By the end of this lesson, you will be able to:
- Distinguish precisely between authentication (AuthN) and authorization (AuthZ) — and explain why authentication must precede authorization in every access control sequence
- Classify authentication mechanisms into their correct factor category (something you know, have, or are) and explain the strength and weakness of each factor type
- Define MFA, explain why combining two factors from the same category does not constitute MFA, and identify which factor combinations provide genuine multi-factor protection
- Compare and contrast RBAC, DAC, and MAC access control models, identify the distinguishing characteristic of each, and determine which model a described system uses
- Explain the principle of least privilege, identify privilege creep, and describe the access review process that prevents it
- Define separation of duties and explain how it limits both fraud and the impact of account compromise
- Apply access control concepts to Vantex Financial Group’s identity architecture and identify gaps in the Network Security Audit Report project
- Recognize and avoid the four most common AP exam traps on authentication and authorization questions
22.5.2 — Authentication vs. Authorization: The Two-Step Gate
Every access control system answers two sequential questions. First: Who are you? Second: What are you allowed to do? The first question is authentication; the second is authorization. They are distinct processes that must occur in order — authorization without prior authentication is a critical security failure.
Purpose: Verify that the entity claiming an identity is actually that entity. Establishes identity before granting any system access.
Mechanisms: Something you know (password, PIN), something you have (hardware token, smart card, phone), something you are (fingerprint, retina, face). MFA combines two or more different factor types.
Failure mode: If authentication fails or is bypassed, an unauthorized entity gains access as a legitimate user. Every privilege that user would have been granted is now available to the attacker.
- Logging in with username + password = AuthN
- Swiping a badge at a door = AuthN
- Completing an MFA prompt = AuthN
- Biometric scan at a secure terminal = AuthN
Purpose: Determine what resources and actions an authenticated entity is permitted to access. Enforces the principle of least privilege by granting only the access the entity’s role requires.
Mechanisms: Access Control Lists (ACLs), Role-Based Access Control (RBAC), permission sets, group memberships. Enforced by the operating system, database, or application after authentication succeeds.
Failure mode: If authorization is misconfigured, an authenticated user can access data or perform actions beyond their permitted scope. A teller can view executive accounts; a read-only user can write to a database.
- Loan Officer role can view balances but not approve transfers = AuthZ
- File permission “owner read/write, others read-only” = AuthZ
- Database grant “SELECT only on client_accounts” = AuthZ
- Admin group membership allows system configuration = AuthZ
The Mandatory Sequence: AuthN Before AuthZ
Authentication must precede authorization. Logically: you cannot determine what someone is allowed to do until you know who they are. A system that checks authorization before confirming identity is flawed by design.
Vantex authentication-authorization flow:
- Employee opens the Vantex internal portal and enters username + password. (Authentication attempt begins)
- The system verifies the credentials against the directory. MFA prompt sent to employee’s registered device. Employee approves. (Authentication succeeds)
- The system retrieves the employee’s role from the identity provider: “Loan Officer.” (Identity established — authorization can now begin)
- The authorization engine checks: does the Loan Officer role have permission to view the mortgage application module? Yes. View the wire transfer approval module? No. (Authorization enforced)
- Employee’s session is established with access to only the modules and data their role permits. (Authorized session active)
This demonstrates the difference between:
32.5.3 — Essential Vocabulary & Exam Tips
| Term | Definition | Exam Trap / Critical Distinction |
|---|---|---|
| Multi-Factor Authentication (MFA) | Authentication using two or more factors from different categories: something you know, something you have, something you are. Each additional factor must be from a different category to constitute genuine MFA. | TRAP Password + security question is NOT MFA — both are “something you know.” True MFA requires crossing factor categories: password (know) + hardware token (have) = MFA. Two passwords, two questions, or two biometrics = stronger single-factor, not MFA. |
| RBAC (Role-Based Access Control) | Access permissions are assigned to roles (job functions), not individuals. Users inherit permissions by virtue of their role assignment. The most common enterprise access control model. Administrators manage roles; users cannot grant themselves access. | KEY RBAC is the dominant model in enterprise environments. When the exam describes “permissions based on job title,” “role-based,” or “users inherit access based on function,” the answer is RBAC. |
| DAC (Discretionary Access Control) | The resource owner controls who has access to their resources. The owner “discretionarily” grants or revokes access to other users. Most personal operating systems (Windows, macOS) use DAC for file permissions. | KEY DAC is identified by the owner having control. When the exam says “the file owner can grant other users access,” “users can share their files,” or “the creator controls permissions,” the model is DAC. DAC is flexible but creates risk: owners may grant inappropriate access. |
| MAC (Mandatory Access Control) | Access is controlled by the system based on classification labels assigned to both subjects (users) and objects (files/resources). Users cannot change their own clearance level or grant access to classified data. Used in military and high-security government systems. | KEY MAC is identified by classification labels and system-enforced access. When the exam describes “Top Secret / Secret / Confidential labels,” “users cannot grant access beyond their clearance,” or “the OS enforces access regardless of user preference,” the model is MAC. MAC is the most restrictive model. |
| Principle of Least Privilege | Every user, process, and system should have only the minimum access rights required to perform their function. Nothing more. Limits the damage an attacker (or accidental action) can cause if an account is compromised. | KEY Least privilege is enforced through RBAC (define roles narrowly) and access reviews (remove excess access over time). A common AP exam scenario: an employee who has accumulated permissions across multiple roles violates least privilege even if each individual permission was originally justified. |
| Separation of Duties | No single person should have sufficient access to complete a sensitive transaction alone. Critical processes require the involvement of two or more individuals with different access rights, making fraud or error much harder to execute and conceal. | KEY Separation of duties is a fraud-prevention and error-prevention control. Classic examples: the person who initiates a wire transfer cannot also approve it; the person who creates a vendor record cannot also approve payments to that vendor. When the exam describes a scenario where one person can both initiate and complete a critical action, separation of duties is the missing control. |
| Privilege Creep | The gradual accumulation of access rights beyond what a user’s current role requires, typically as the user changes roles over time and old access is not removed when new access is granted. | KEY Privilege creep is prevented by: (1) revoking old access when new access is granted during role changes, and (2) periodic access reviews (quarterly is standard) where managers certify that each employee’s access reflects their current role. The fix for privilege creep is always a review-and-revoke process. |
| Just-in-Time (JIT) Access | Privileged access is granted only when needed for a specific task and automatically revoked after a defined time window. No standing privileged access exists — access is provisioned on-demand and expires automatically. | NOTE JIT access is an advanced least-privilege implementation. Standard privileged access management (PAM) vaults credentials; JIT eliminates standing access entirely. AP exam questions about “time-limited access” or “access that expires automatically” are testing JIT access concepts. |
| Access Review | A periodic process (typically quarterly) in which managers review and certify that all access rights assigned to their team members are still appropriate for their current roles. Identifies and removes privilege creep and orphaned accounts. | KEY Access reviews are the primary control for privilege creep and orphaned accounts (accounts of former employees). When the exam asks “which control prevents an employee from retaining access from a previous role,” access review (combined with immediate revocation during role transitions) is the answer. |
| Account Lockout Policy | A policy that disables an account after a defined number of consecutive failed authentication attempts. Prevents brute-force and credential-stuffing attacks by making automated credential testing impractical. | TRAP Account lockout creates a denial-of-service risk — an attacker who intentionally triggers lockouts can deny access to legitimate users. Balance lockout threshold against lockout duration and recovery method. A threshold too low (2 attempts) disrupts users; too high (100 attempts) provides inadequate protection. |
Match each description to the correct access control model.
42.5.4 — The Three Authentication Factors In Depth
Every authentication mechanism in existence falls into one of three factor categories. Understanding each category’s mechanism, strengths, weaknesses, and bypass techniques is essential for both AP exam questions and real security architecture decisions.
Why MFA Works: The Attacker’s Problem
MFA dramatically increases the cost and complexity of credential attacks. Stealing a password requires phishing or a data breach — achievable at scale. Simultaneously stealing a password and a hardware token requires either physical theft or a sophisticated real-time relay attack. Adding a biometric factor requires physical presence of the target.
The mathematical reality: if an attacker has a 1% monthly probability of successfully compromising each individual factor, a single-factor system has a 1% monthly breach probability. A two-factor system requires both factors to be compromised simultaneously: 1% × 1% = 0.01% monthly breach probability — a 100x reduction. A three-factor system reduces this further to 0.0001% — a 10,000x reduction from single-factor authentication.
The phishing-resistance exception: Not all MFA is equal against phishing. SMS OTP and authenticator app codes can be intercepted in real time by a phishing site that acts as a man-in-the-middle — the attacker captures your password and OTP and immediately uses them on the real site before they expire. FIDO2/passkey authentication is phishing-resistant because the cryptographic challenge is tied to the specific domain — a fake domain cannot complete the authentication even if the user attempts to log in there. AP exam note: “phishing-resistant MFA” = FIDO2/hardware security keys, not SMS or TOTP codes.
Which principle is violated, and what is the risk?
52.5.5 — Access Control Models In Depth
Access control models define the rules by which a system determines who can access what. The model chosen for a system reflects the organization’s security requirements, user trust level, and administrative capacity. The three primary models — RBAC, DAC, and MAC — differ fundamentally in who controls access decisions and how granular those decisions can be.
| Model | Full Name | Who Controls Access | How Access Is Determined | Typical Environment |
|---|---|---|---|---|
| RBAC | Role-Based Access Control | System administrators define roles; access is inherited by users assigned to those roles. Individual users cannot grant access. | User → Role → Permissions. A “Loan Officer” role has specific permissions; all loan officers inherit exactly those permissions. | Corporate IT systems, cloud platforms, healthcare systems, financial institutions (Vantex) |
| DAC | Discretionary Access Control | The resource owner controls access. Owners can grant, modify, or revoke other users’ access to their resources at their discretion. | Each resource has an access control list (ACL) set by the owner. Owner can add any user to the ACL with any permission level. | Personal operating systems (Windows, macOS, Linux file permissions), shared file servers, consumer cloud storage |
| MAC | Mandatory Access Control | The operating system or security kernel controls access based on classification labels. Users cannot override or modify access rules. | Both subjects (users) and objects (files/resources) have security labels. System compares labels to grant or deny access per a fixed policy. | Military information systems, classified government networks, high-security environments requiring strict need-to-know enforcement |
Deep Dive: Why RBAC Dominates Enterprise Security
RBAC is the dominant access control model in enterprise cybersecurity because it scales efficiently and aligns with organizational structure. Rather than assigning permissions to thousands of individual users, administrators define a manageable set of roles (50–200 for a mid-size organization) and assign users to roles. When a user’s job function changes, only their role assignment needs updating — the role’s permissions remain stable.
Vantex RBAC implementation: Vantex has 23 defined roles spanning its 5 business lines and 3 technical functions. Examples:
- Teller: Read access to assigned customer accounts; cannot approve transactions over $10,000; cannot access loan origination module
- Loan Officer: Read/write access to loan applications for assigned portfolio; cannot access wire transfer approval; cannot view accounts outside assigned portfolio
- Treasury Manager: Read access to all accounts; approve wire transfers up to $500,000; initiate bulk payments; cannot modify user access rights
- IT Administrator: System configuration access; cannot access client financial records; cannot approve transactions; separate account required for privileged actions (PAM)
- Security Analyst: Read-only access to logs, SIEM, and security tooling across all systems; cannot modify production data or configurations
The RBAC compliance advantage: Financial regulators (OCC, FDIC, FFIEC) require organizations to demonstrate that access to sensitive data is restricted to personnel with a legitimate business need. RBAC provides a clear, auditable record: “User X has Role Y; Role Y has these permissions; User X was assigned Role Y on date Z by Manager W.” This audit trail satisfies regulatory access control requirements far more efficiently than individual permission management.
Complete the MFA authentication framework.
Requiring two or more different credential types is called authentication (MFA).
A password is classified as (a knowledge factor).
A phone authenticator app is classified as (a possession factor).
A fingerprint scan is classified as (a biometric factor).
62.5.6 — Least Privilege, Separation of Duties, and Privilege Creep
Three closely related concepts govern how access rights are scoped, distributed, and maintained over time. Together they form the operational core of the user/identity layer in defense-in-depth.
Least Privilege — Minimum Access for Maximum Security
Separation of Duties — No Single Person Controls a Critical Process
Privilege Creep: How Least Privilege Dies in Practice
The Vantex Privilege Creep Case Study — Five Years in the Life of One Account
Which principle would have prevented this?
Select ALL actions that should be part of an employee offboarding checklist.
Why is administrator access on workstations dangerous in this scenario?
92.5.9 — Worked Examples: Predict First, Then Classify
Separate the Two Processes
Authentication: the employee entered credentials and completed MFA. Result: authentication succeeded correctly — the system correctly identified the employee as the Teller. No authentication failure here.
Authorization: the system checked whether the Teller role permits access to executive compensation. It found “yes” (incorrectly, due to migration error) and granted access. The authorization check failed — not in its mechanics but in its configuration.
Classify the Failure
This is an authorization failure — specifically, an RBAC misconfiguration where the Teller role was granted permission it should not have. The authentication process was correct. The authorization policy was wrong.
Authorization failure (RBAC misconfiguration). The fix: immediately audit all roles modified during the system migration to verify permissions are correct. Remove the executive compensation permission from the Teller role. Implement a post-migration access review as a standard control to catch these errors before they are discovered via incident. AP exam takeaway: strong authentication (including MFA) does not compensate for authorization misconfiguration. An attacker who knows this misconfiguration exists can exploit it with entirely legitimate credentials.
Map Current Access to Current Role
Level 1 Help Desk requires: standard employee access + ticketing system + password reset tool. That’s it. Network monitoring read-only and firewall rule modification are both far beyond what Level 1 Help Desk requires.
Identify the Violations
Privilege creep: permissions accumulated over time from temporary assignments were never revoked. Least privilege violated: current access far exceeds current role requirements. No evidence of quarterly access reviews catching this over 18 months.
Privilege creep + least privilege violation. The most dangerous access is firewall rule modification: a Level 1 Help Desk account that can modify firewall rules is a massive security gap — if compromised, an attacker can open network access to any system. Immediate fix: revoke network monitoring and firewall access. Long-term fix: implement quarterly access reviews that catch 18-month-old emergency grants. Implement a policy that temporary access grants automatically expire after a defined period (30–90 days) unless renewed with business justification.
Match each control to the access control principle it enforces.
102.5.10 — AP Exam Strategy: Access Control Questions
Strategy 1: AuthN vs. AuthZ
Every access control scenario involves one or both. Ask: “Did the failure occur during identity verification, or during permission enforcement?”
- Stolen credentials, phished password, bypassed login = AuthN failure
- Authenticated user accessed data they shouldn’t have = AuthZ failure
- MFA strengthens AuthN; RBAC enforces AuthZ. They are independent.
- A question asking “what CIA property does MFA protect?” = Confidentiality (not Authentication — that’s the mechanism)
Strategy 2: Identify the Model
When the exam describes an access control system, look for the key identifier:
- Job title / role inherits permissions: RBAC
- File owner can grant/revoke access: DAC
- Classification labels, system enforces, user cannot override: MAC
- Military / Top Secret / clearance levels: MAC
- Windows/Linux file permissions: DAC
- Corporate enterprise systems: RBAC (almost always)
Strategy 3: The Four Fatal Traps
- Trap 1 — Password + security question = MFA: Wrong. Both are “something you know.” MFA requires different category factors.
- Trap 2 — Authentication = CIA property: Wrong. Authentication is a mechanism. The CIA property is Confidentiality.
- Trap 3 — Separation of duties = least privilege: Wrong. Least privilege limits what one account can do. Separation of duties distributes a process across multiple accounts.
- Trap 4 — MFA prevents authorization misuse: Wrong. MFA only strengthens identity verification. It cannot prevent an authenticated user from misusing their legitimate permissions.
Strategy 4: Scenario Diagnosis Framework
When a question presents an access control scenario, use this mental checklist:
- Was identity verified? If not: AuthN gap → add MFA
- Did verified user exceed their permissions? If yes: AuthZ gap → fix RBAC
- Did one person control an entire sensitive process? If yes: separation of duties gap
- Does current access exceed current role? If yes: least privilege/privilege creep → access review
- Is a terminated employee’s account active? Access revocation failure → deprovisioning process
/app/billing to /app/admin by modifying the URL. The admin panel loads, giving her full control over user accounts. She was authenticated but not authorized for admin access.This vulnerability is called:
?2.5.11 — Frequently Asked Questions
Q: Why do password + security question fail to qualify as MFA?
Multi-factor authentication requires factors from different categories — not just two different pieces of information. Both a password and a security question are “something you know.” An attacker who compromises your knowledge base (through a data breach, social media research, or phishing) can obtain both simultaneously. The security model of MFA is that the different factor categories require the attacker to use entirely different attack techniques — stealing a password requires a different attack than stealing a physical hardware token. Two knowledge factors share the same vulnerability surface. They provide defense-in-depth within the knowledge category but do not constitute MFA.
Q: What is the difference between least privilege and separation of duties?
Least privilege asks: “Does this individual account have only the access it needs?” Separation of duties asks: “Can this process be completed unilaterally by one person?” They address different risks. Least privilege limits the damage when a single account is compromised (the attacker only gets what that account is allowed to do). Separation of duties prevents a single person from committing fraud or error by distributing critical processes across multiple people who would need to collude. You can have least privilege without separation of duties (every account is minimally privileged, but one person still initiates and approves their own wire transfers — just with a minimal-permission account). Both principles together provide the strongest protection.
Q: When would an organization choose MAC over RBAC?
MAC is chosen when the organization requires strict, system-enforced access control that users cannot override under any circumstances, typically where even well-intentioned sharing of information could cause catastrophic harm. Military systems, intelligence agencies, and classified government networks use MAC because the consequence of a user accidentally or intentionally granting a colleague access to a higher-classified document is unacceptable. The tradeoff is inflexibility and administrative overhead. RBAC is far more practical for commercial organizations because it accommodates the fluid nature of business roles, project assignments, and changing access needs without requiring a security clearance infrastructure. Most financial institutions (like Vantex) use RBAC with strong access governance rather than MAC.
Q: What is privilege creep and how is it different from a permission misconfiguration?
Privilege creep is the gradual accumulation of excess access rights over time as a user changes roles but old access is not removed. Each individual permission grant may have been appropriate at the time it was made. Over years, the accumulation creates a far over-privileged account that violates least privilege. A permission misconfiguration is a single incorrect permission assignment — a role that was incorrectly configured to include a permission it should not have. The remediation differs: privilege creep requires regular access reviews to identify and remove accumulated excess; misconfiguration requires auditing role definitions and correcting the incorrect assignments. Both result in over-privileged access, but through different mechanisms.
Q: How does UEBA differ from standard log monitoring?
Standard log monitoring detects known-bad events: failed login attempts, access to a specific high-sensitivity file, commands that match known attack patterns. It is rules-based — if event X occurs, fire alert Y. UEBA builds a behavioral baseline for each user and entity, then detects deviations from that baseline — even if the deviant behavior does not match any known-bad rule. A user who normally accesses 50 records per day downloading 50,000 records is not triggering any specific rule (the access is technically authorized), but the deviation from baseline is enormous. UEBA catches insider threats, compromised accounts used by attackers, and novel attack patterns that rules-based systems miss. It is more computationally intensive and generates more false positives than rule-based monitoring, requiring analyst triage.
Q: How do access controls apply to the Vantex Network Security Audit Report?
The audit’s identity and access section (Layer 6 in the DiD framework from 2.2) should evaluate: MFA coverage (are all accounts, especially privileged accounts, using genuine multi-factor authentication?), RBAC role definitions (are roles defined narrowly enough to enforce least privilege?), access review process (is there a regular review that catches privilege creep?), service account governance (do service accounts follow the same least-privilege standards as human accounts?), separation of duties enforcement (are critical financial processes built with technical controls preventing single-person completion?), and offboarding process (is access revoked immediately upon employee separation?). Each gap should be quantified using the risk assessment framework from 2.4: what is the ALE of the over-privileged account scenario, and what is the cost of implementing PAM or tightening the access review cycle?
Select ALL consequences of infrequent access reviews.
Tanner has taught AP Computer Science for 11+ years and built APCSExamPrep.com to give every student access to the same resources his own students use. He holds 1,845+ verified tutoring hours on Wyzant with a 5.0 rating from 451+ reviews. His AP CSA students score 5s at more than double the national average (54.5% vs. 25.5% nationally).
+Continue Learning
Practice what you learned, then move to the next topic in Unit 1:
Lesson → Exercise 1 → Exercise 2 → Lab → Quiz
Get in Touch
Whether you're a student, parent, or teacher — I'd love to hear from you.
Just want free AP CS resources?
Enter your email below and check the subscribe box — no message needed. Students get daily practice questions and study tips. Teachers get curriculum resources and teaching strategies.
Message Sent!
Thanks for reaching out. I'll get back to you within 24 hours.
Prefer email? Reach me directly at [email protected]