Database Security, Privacy and Responsible Data Use

Introduction and Context

Database systems are strategic assets because they store the information that supports operations, analytics, customer relationships, public services, research and artificial intelligence. Their compromise can therefore cause more than technical disruption: it can produce financial loss, regulatory sanctions, discrimination, reputational damage and harm to individuals. Advanced database security is consequently concerned not only with preventing unauthorized access, but also with ensuring that data is accurate, available, appropriately used and handled throughout its life cycle.

Database security, privacy and responsible data use are related but distinct. Security protects systems and information against unauthorized actions. Privacy concerns the rights, expectations and legitimate interests of people whose data is processed. Responsible data use adds ethical and governance considerations, including fairness, proportionality, transparency and accountability. A technically secure database may still violate privacy if it retains excessive information or supports unjustified surveillance.

This chapter presents an integrated approach to authentication, authorization, encryption, auditing, masking, secure development, threat assessment, privacy-by-design, data minimization, regulatory compliance and ethical decision-making.

Learning Objectives

By the end of this chapter, students should be able to:

1. Distinguish authentication, authorization, accountability, confidentiality, integrity and availability.

2. Design database access controls using least privilege, roles and separation of duties.

3. Explain encryption at rest, encryption in transit, key management and tokenization.

4. Assess injection, privilege abuse, insider threats and insecure database development practices.

5. Select appropriate auditing, masking, pseudonymization and monitoring mechanisms.

6. Apply privacy-by-design, data minimization, retention and impact-assessment principles.

7. Relate database controls to regulatory and organizational governance requirements.

8. Evaluate security and privacy trade-offs in realistic enterprise scenarios.

1. The Security and Privacy Objectives of a Database

The conventional security triad is confidentiality, integrity and availability (CIA). Confidentiality means that information is disclosed only to authorized subjects. Integrity means that information and database operations are accurate, complete and protected from unauthorized alteration. Availability means that authorized users can obtain required services and data when needed.

Database systems also require:

• Authenticity: confidence that a user, service or data source is genuine.
• Accountability: the ability to associate actions with responsible identities.
• Non-repudiation: evidence that makes it difficult for a party to deny an action, subject to the limitations of logging and identity assurance.
• Resilience: the ability to continue or recover operations after failures or attacks.
• Privacy: appropriate control over the collection, use, disclosure and retention of personal information.

Security controls operate at several layers. The application authenticates users and validates requests; the database engine enforces privileges and constraints; the operating system protects processes and files; the network controls communication paths; and organizational governance defines acceptable use. No single layer is sufficient. For example, database privileges cannot compensate for stolen application credentials, while network isolation cannot prevent a legitimate administrator from misusing excessive privileges.

2. Threat Modeling for Database Systems

Threat modeling is a structured process for identifying assets, adversaries, attack paths, impacts and controls. A useful analysis begins by defining the system boundary and data flows. Important questions include:

• What data is stored, and which elements are sensitive?
• Who can access it, through which applications and interfaces?
• Which identities are human, service-based or privileged?
• Where are backups, replicas, exports and logs located?
• What happens if confidentiality, integrity or availability is lost?

The STRIDE model provides one classification scheme: spoofing, tampering, repudiation, information disclosure, denial of service and elevation of privilege. For privacy analysis, a complementary perspective considers collection, inference, unauthorized secondary use, excessive retention, linkage and re-identification.

A database threat register should distinguish likelihood from impact. Risk is often represented qualitatively as a combination of these factors; organizations may use numerical scoring, but scores are decision aids rather than objective measurements. A low-probability event involving millions of sensitive records may deserve priority because its impact is extreme.

Common database threats include:

• Credential compromise: stolen passwords, tokens or connection strings.
• SQL and NoSQL injection: attacker-controlled input changes the meaning of a query or command.
• Excessive privilege: users or services can read or modify more data than required.
• Insider misuse: authorized personnel intentionally or accidentally abuse access.
• Misconfiguration: public storage, weak network rules, default accounts or unencrypted backups.
• Inference and linkage: apparently harmless records are combined to reveal sensitive attributes.
• Ransomware and destructive attacks: data is encrypted, deleted or rendered unavailable.
• Supply-chain compromise: vulnerable drivers, libraries, extensions or managed services introduce risk.

3. Authentication and Identity Assurance

Authentication establishes who or what is requesting access. It should be distinguished from authorization, which determines what the authenticated identity may do. Authentication factors are commonly categorized as something the user knows, possesses or is. Multi-factor authentication (MFA) combines independent factors and reduces the impact of a compromised password, although phishing-resistant methods are stronger than one-time codes delivered through vulnerable channels.

Enterprise databases should normally integrate with centralized identity systems rather than maintaining unmanaged local accounts. Federation, single sign-on and short-lived credentials can improve consistency and reduce password exposure. Service accounts should use narrowly scoped identities, managed secrets and rotation procedures. Shared accounts undermine accountability and should be avoided except where technically unavoidable and tightly controlled.

Authentication design should address:

• credential enrollment, recovery and revocation;
• failed-login handling without enabling denial-of-service through trivial lockouts;
• session lifetime and reauthentication for sensitive actions;
• privileged access management and just-in-time elevation;
• machine identities, certificates and workload authentication; and
• emergency or break-glass access with post-event review.

Strong authentication does not authorize every operation. A valid administrator identity may still be restricted by purpose, time, location, data domain or approval workflow.

4. Authorization Models and Least Privilege

Authorization is the enforcement of permitted actions on specified resources. A permission is usually expressed as a subject, action and object, possibly with contextual conditions. Typical actions include SELECT, INSERT, UPDATE, DELETE, EXECUTE and administrative operations.

Role-Based Access Control

Role-based access control (RBAC) assigns permissions to roles and roles to users. Examples include billing-clerk, analyst, physician and database-operator. RBAC simplifies administration, but poorly designed roles can become excessively broad. Role engineering should reflect actual business responsibilities and avoid granting access merely because a person belongs to a department.

Attribute- and Policy-Based Control

Attribute-based access control (ABAC) evaluates attributes such as user department, record classification, purpose, time and device trust. A policy might allow a clinician to view records only for patients assigned to that clinician and only through an approved application. Policy-based systems provide flexibility but require reliable attributes, understandable policies and effective testing.

Database Enforcement Techniques

Important mechanisms include:

• object privileges and restricted views;
• stored procedures that expose approved operations;
• row-level security for record-specific filtering;
• column-level protection for sensitive attributes;
• database roles separated by environment and function;
• constraints and transaction rules that protect integrity; and
• approval workflows for exceptional access.

Least privilege means granting only the access necessary for an authorized task, for the shortest reasonable duration. It applies to humans, applications, batch jobs, administrators and monitoring tools. Separation of duties prevents one person or identity from completing a high-risk process alone—for example, creating a supplier and approving payment.

Access reviews should be periodic and event-driven. Joining, transfer, role change and termination should automatically trigger identity changes. Privilege creep is a major practical weakness: permissions accumulate unless actively removed.

5. Encryption, Tokenization and Key Management

Encryption transforms readable plaintext into ciphertext using a cryptographic algorithm and a key. Confidentiality depends not merely on selecting an algorithm but on protecting keys, managing access and avoiding insecure implementation.

Encryption in transit protects connections between clients, applications, database servers and replicas. Transport Layer Security (TLS), correctly configured and validated, helps prevent interception and tampering. Encryption at rest protects database files, disks, snapshots and backups if storage is stolen or improperly accessed. It does not necessarily protect data from a compromised database account that can issue legitimate queries.

Encryption may be applied at different levels:

• full-disk or volume encryption;
• database or tablespace encryption;
• column-level or application-level encryption; and
• field-specific tokenization or format-preserving protection.

Application-level encryption can reduce exposure to database administrators, but it complicates searching, indexing, sorting, key rotation and recovery. Deterministic encryption can permit equality queries but may reveal repeated values. Randomized encryption provides stronger semantic confidentiality but generally prevents direct equality matching without specialized techniques.

Tokenization replaces a sensitive value with a token whose meaning is held in a separate protected mapping system. It is useful for payment or identity workflows, but tokens are not automatically anonymous; the mapping service and operational context remain security-critical. Hashing is not encryption. A cryptographic hash is a one-way transformation commonly used for integrity checks and password verification. Passwords should be protected with slow, salted password-hashing schemes designed for that purpose, not with ordinary fast hashes.

Key management is often the decisive issue. Keys should be generated using approved cryptographic mechanisms, stored separately from protected data where feasible, access-controlled, rotated according to risk, backed up securely and destroyed when no longer required. Hardware security modules or managed key-management services may provide stronger controls, but they do not eliminate governance responsibilities. Loss of a key can make data unrecoverable; unauthorized key access can defeat encryption.

6. Auditing, Monitoring and Accountability

Auditing creates evidence about access and change. Useful audit records may include identity, timestamp, source, action, object, outcome, application context and approval reference. For sensitive operations, logging the reason or business purpose can improve accountability.

Audit design requires balance. Logging everything without a review process creates cost and noise; logging too little prevents investigation. High-value events commonly include privilege changes, failed authentication, access to sensitive records, bulk exports, schema changes, backup operations and disabling of security controls.

Logs should be protected against alteration, synchronized to a reliable time source, retained according to policy and monitored for suspicious patterns. Separation between database administrators and audit custodians reduces the risk that an administrator can erase evidence. Security information and event management systems can correlate database events with identity, network and endpoint signals.

Examples of suspicious behavior include access outside normal duties, unusually large result sets, repeated failed queries, use of dormant accounts and sudden changes to authorization tables. Monitoring should respect privacy and employment law; surveillance must be proportionate and transparent.

7. Data Masking, Pseudonymization and Anonymization

Masking limits exposure when full values are unnecessary. Static masking creates a sanitized copy, often for development or testing. Dynamic masking displays altered values at query time according to user privilege. Techniques include redaction, partial display, substitution, generalization and format-preserving replacement.

Pseudonymization replaces direct identifiers with pseudonyms while retaining a means of re-linking under controlled conditions. It reduces routine exposure but remains personal data where re-identification is reasonably possible. Anonymization aims to make re-identification impossible or sufficiently impracticable in the relevant context. It is difficult to achieve because auxiliary datasets can support linkage attacks.

A dataset containing age, postal area and rare occupation may identify individuals even after names are removed. Therefore, privacy assessment must consider uniqueness, external data, population size and the intended release environment. Masking is not a substitute for access control, and de-identification is not a guarantee of anonymity.

8. Secure Database Development

Secure coding should begin before implementation. Requirements should specify security and privacy properties, data classifications, retention, access purposes and failure behavior. Threat modeling, secure design review, code review, dependency management, testing and operational monitoring should continue throughout the development life cycle.

Injection Prevention

SQL injection occurs when untrusted input is interpreted as part of a query. The primary defense is parameterized queries or prepared statements, in which data values are transmitted separately from the query structure. Safe query builders and carefully reviewed stored procedures may also help. Input validation is valuable for business rules and expected formats, but validation alone is not a sufficient defense.

Unsafe pattern:

```text

query = "SELECT * FROM users WHERE name = '" + input + "'"

```

Safer pattern:

```text

query = "SELECT * FROM users WHERE name = ?"

execute(query, [input])

```

Dynamic identifiers, such as table or column names, require allow-list validation because they generally cannot be bound as ordinary values. Escaping is error-prone and should not replace parameterization.

NoSQL, graph and search systems also require secure construction. Injection can occur through operator objects, expressions, scripts or serialized filters. Developers should avoid evaluating user input as code, restrict query operators and use native parameterization mechanisms.

Additional Secure Practices

Applications should use separate database identities for separate services, limit returned columns, avoid embedding secrets in source code, handle errors without revealing schema details, validate authorization at the server, and use transactions for security-sensitive state changes. Backups, exports and temporary files must receive the same protection as production data. Security tests should include negative authorization tests, injection tests, dependency scanning, secret detection and abuse-case testing.

9. Insider Threats and Privileged Operations

An insider threat may involve a malicious employee, a compromised privileged account, an accidental disclosure or a contractor who retains inappropriate access. Insider risk is not solved by assuming that employees are untrustworthy; it is reduced through well-designed controls and fair governance.

Effective measures include least privilege, separation of duties, just-in-time administration, dual approval for high-impact operations, database activity monitoring, immutable or independently protected audit records, data-loss prevention and rapid offboarding. Administrators should not ordinarily access application-level personal data merely because they operate the platform. Where support access is necessary, it should be time-limited, approved and recorded.

Behavioral monitoring must be carefully governed. Automated alerts are indicators, not proof of misconduct. Investigations should preserve due process, limit access to investigative data and distinguish error from intentional abuse.

10. Privacy-by-Design and Data Minimization

Privacy-by-design integrates privacy into architecture rather than adding it after deployment. Its practical principles include proactive risk prevention, privacy as a default, full life-cycle protection, transparency and respect for user interests.

Data minimization has at least three dimensions:

1. Amount: collect only the attributes needed.

2. Detail: use the least precise form that supports the purpose.

3. Retention: keep information only for as long as justified.

For example, a service verifying age may need an age threshold result rather than a complete birth date. A delivery system may need a delivery address during fulfillment but not indefinitely afterward. Minimization should be documented as a design decision, not treated as an informal preference.

Purpose limitation requires that data collected for one legitimate purpose not be silently reused for an incompatible purpose. Secondary use may require notice, consent, a new legal basis, contractual assessment or governance approval, depending on the jurisdiction and context. Consent should be specific, informed, freely given where applicable and withdrawable; it is not a universal solution for every processing activity.

Privacy impact assessments are structured analyses of processing purposes, data categories, affected people, risks, safeguards and residual risk. They are particularly important for large-scale sensitive data, systematic monitoring, novel technologies and automated decisions with significant effects.

11. Regulatory Compliance and Governance

Regulatory requirements vary by jurisdiction and sector, but common themes include lawful and transparent processing, purpose limitation, data subject or consumer rights, security safeguards, breach response, retention controls, processor management and demonstrable accountability. Sectoral regimes may impose additional requirements for health, finance, education, telecommunications or payment data.

Compliance should not be reduced to a checklist. Organizations need a governance structure that assigns ownership for data assets, processing purposes, classifications, retention, access decisions and incident response. Data inventories and lineage help identify where information is collected, transformed, replicated and disclosed.

A useful governance framework includes:

• data classification and handling standards;
• policy-based access approval and periodic recertification;
• records of processing and data-flow documentation;
• retention and defensible deletion schedules;
• vendor and cloud-service due diligence;
• incident detection, escalation and notification procedures;
• individual rights request processes; and
• independent assurance through audits and control testing.

Cross-border transfers and cloud deployments require attention to jurisdiction, subcontractors, contractual obligations, key locations and government-access risks. Legal compliance is a baseline. An action may be legally permitted yet ethically questionable if it is unexpected, discriminatory or disproportionate.

12. Responsible Data Use and Artificial Intelligence

Advanced analytics and artificial intelligence increase both the value and the risks of databases. Models may infer sensitive attributes, reproduce historical discrimination or enable decisions that individuals cannot understand or challenge. Training data may contain inaccurate, biased or unlawfully obtained information.

Responsible use requires purpose definition, provenance, quality assessment, access restrictions, documentation and evaluation of impacts on affected groups. Data used for model development should be minimized and appropriately protected. De-identification must account for model memorization and linkage. Synthetic data can reduce exposure in some contexts, but it may reproduce bias or reveal information if generated from small or sensitive datasets.

Organizations should establish human oversight for high-impact decisions, monitor model and data drift, provide correction mechanisms and preserve audit evidence about datasets, features, versions and decisions. Fairness cannot be guaranteed by a single statistical test; relevant measures depend on the decision context, base rates, harms and legal requirements. Technical performance must therefore be evaluated alongside social and institutional consequences.

13. Illustrative Case: Regional Health Analytics Platform

Background

A regional health authority plans a cloud-based platform combining hospital records, laboratory results and appointment data. The stated purposes are clinical coordination, service planning and research. The platform will be accessed by clinicians, analysts, researchers, contractors and administrators.

Problem

The initial design proposes a shared database account for reporting, full production copies in development environments and indefinite retention. A vendor requests unrestricted administrator access for support. The authority also wants to provide researchers with detailed records containing dates, locations and rare diagnoses.

Analysis

The data is highly sensitive, and the purposes differ substantially. Clinical care requires identifiable, timely information; planning may need aggregated data; research may require controlled pseudonymized records. A shared account would prevent reliable accountability. Full copies would create unnecessary exposure, while indefinite retention would conflict with minimization and storage limitation. Rare combinations of diagnosis, date and location could re-identify patients even after names are removed.

Approach and Solution

The authority establishes a data inventory and separates processing purposes. Clinicians authenticate through the organizational identity provider with MFA and receive role- and context-based access. Researchers use a governed data enclave with pseudonymized identifiers, approved projects, output review and restricted export. Planning dashboards use aggregated results with suppression or generalization for small groups.

Production, testing and development environments are separated. Test data is masked or synthetically generated. Service accounts are unique and narrowly scoped. Vendor support uses time-limited, approved access through a monitored privileged-access system; the vendor cannot routinely view clinical content. TLS protects connections, storage and backups are encrypted, and keys are managed independently of database administrators.

Parameterized queries, secure views and row-level controls are incorporated into applications. Audit records capture sensitive access, exports, privilege changes and support sessions. A retention schedule defines when clinical, operational and research copies are reviewed or deleted. A privacy impact assessment documents risks, safeguards, residual risk and consultation with affected stakeholders.

Outcome

The platform supports the intended services while reducing unnecessary exposure. Some analytics become less granular, and research workflows require additional approval, but the authority gains stronger accountability, clearer purpose limitation and greater public trust.

Learning Points

The case illustrates that security and privacy are architectural decisions. Encryption alone would not solve excessive access, inappropriate retention or re-identification. Effective controls combine identity, authorization, secure development, monitoring, minimization, governance and ethical judgment.

14. Challenges, Limitations and Strategic Trade-offs

Security controls can reduce convenience, performance or analytical flexibility. Fine-grained authorization may increase application complexity. Encryption can complicate search and recovery. Extensive logging can create privacy risks and storage costs. Data minimization may reduce future analytical opportunities, while excessive retention increases exposure.

Controls also fail in practice through misconfiguration, outdated dependencies, unreviewed exceptions, poor key recovery, weak vendor governance and alert fatigue. Zero-trust architecture, managed services and automation can improve consistency but introduce dependency on providers and policy engines. Compliance certifications provide evidence of control design, not proof that every deployment is secure.

Senior decision-makers should evaluate residual risk rather than seeking absolute security. Decisions should consider the sensitivity and volume of data, affected populations, reversibility of harm, attack surface, regulatory duties, operational necessity and available safeguards. Exceptions should be documented, approved by an accountable owner and given an expiry or review date.

15. Best-Practice Blueprint

A mature database security and privacy program should:

1. Inventory data, flows, owners, purposes and sensitivity.

2. Classify threats and perform security and privacy impact assessments.

3. Centralize identity and require strong authentication for privileged access.

4. Enforce least privilege, separation of duties and periodic access review.

5. Use parameterized queries and secure development practices.

6. Encrypt connections, storage and backups, with disciplined key management.

7. Separate production from development and mask or synthesize test data.

8. Monitor high-risk activity and protect audit evidence.

9. Define retention, deletion, correction and disclosure procedures.

10. Govern vendors, replicas, exports, cloud services and cross-border transfers.

11. Test recovery, incident response and access-control failure scenarios.

12. Review ethical effects, stakeholder expectations and residual risks continuously.

Chapter Summary

Database security protects confidentiality, integrity, availability, authenticity and accountability, while privacy and responsible data use address the legitimate interests and rights of people represented in data. Effective protection is layered: strong authentication identifies subjects; authorization and least privilege constrain actions; encryption protects data in transit and at rest; key management preserves the value of encryption; auditing supports accountability; and masking or pseudonymization reduces unnecessary exposure.

Threat modeling should consider injection, misconfiguration, credential compromise, insider misuse, inference and availability attacks. Secure development relies primarily on parameterized queries, safe APIs, server-side authorization, dependency control and testing. Privacy-by-design requires purpose limitation, data minimization, controlled retention, transparency and impact assessment. Regulatory compliance should be supported by inventories, ownership, access review, incident response and evidence, but ethical responsibility extends beyond legal minimums.

The strategic objective is not simply to make a database difficult to attack. It is to ensure that data is collected, accessed, used, shared, retained and destroyed in ways that are secure, proportionate, accountable and worthy of trust.

Key Terms

Authentication: Process of verifying the identity of a user, service or device.

Authorization: Determination and enforcement of actions an authenticated identity may perform.

Accountability: Ability to associate actions with responsible identities and evidence.

Least privilege: Granting only the access necessary for an authorized task.

Separation of duties: Dividing sensitive responsibilities so that no single party controls an entire high-risk process.

RBAC: Role-based access control, in which permissions are assigned through organizational roles.

ABAC: Attribute-based access control, in which policies evaluate identity, resource and contextual attributes.

Encryption at rest: Protection of stored data using cryptographic transformation.

Encryption in transit: Protection of data while moving between systems or components.

Key management: Generation, storage, use, rotation, recovery and destruction of cryptographic keys.

Tokenization: Replacement of sensitive values with tokens linked through a protected mapping.

Pseudonymization: Replacement of identifiers while retaining controlled potential for re-linking.

Anonymization: Processing intended to prevent reasonable re-identification in a given context.

SQL injection: Manipulation of query meaning through untrusted input.

Audit trail: Protected record of system actions and security-relevant events.

Data minimization: Limiting data amount, detail and retention to what is necessary.

Purpose limitation: Restricting processing to specified and legitimate purposes.

Privacy-by-design: Integrating privacy safeguards into system architecture and life-cycle processes.

Privacy impact assessment: Structured evaluation of privacy risks, safeguards and residual effects.

Insider threat: Harm caused by an authorized person or compromised authorized account.

Review Questions

Short Answer Questions

1. Distinguish authentication from authorization and accountability.

2. What are the main purposes of encryption in transit and encryption at rest?

3. Why is pseudonymized data not necessarily anonymous?

4. State two important controls for reducing insider threat.

5. Why are parameterized queries preferred to string concatenation?

Long Answer Questions

1. Explain how RBAC and ABAC differ, and discuss circumstances in which each is appropriate.

2. Describe a complete key-management life cycle and explain why encryption alone is insufficient.

3. Discuss how privacy-by-design principles affect database architecture and retention decisions.

4. Explain how auditing, monitoring and separation of duties contribute to accountability.

5. Evaluate the relationship between regulatory compliance, ethical data use and organizational governance.

Analytical / Application Questions

1. A university wants to give external researchers detailed student records. Design a security and privacy architecture addressing authorization, masking, retention, audit and re-identification risk.

2. An application uses dynamically assembled SQL queries and a shared database account. Identify the threats and propose a prioritized remediation plan.

3. A hospital discovers that a contractor exported records outside normal working hours. Analyze the incident using authentication, authorization, auditing, insider-threat and privacy-impact perspectives.

Multiple Choice Questions with Answers

Question 1

Which control primarily determines what an authenticated user is permitted to do?

A. Authentication

B. Authorization

C. Encryption

D. Hashing

Correct Answer: B. Authorization

Question 2

What is the strongest primary defense against SQL injection in ordinary value parameters?

A. Parameterized queries

B. Longer database passwords

C. Full-disk encryption

D. Database replication

Correct Answer: A. Parameterized queries

Question 3

Which statement about pseudonymization is correct?

A. It always makes data anonymous

B. It removes the need for access control

C. It replaces identifiers while retaining possible controlled re-linking

D. It is identical to password hashing

Correct Answer: C. It replaces identifiers while retaining possible controlled re-linking

Question 4

Which practice best represents least privilege?

A. Giving all analysts administrator rights

B. Granting access only to data and operations needed for a defined task

C. Using one shared account for convenience

D. Keeping permissions permanently after a role change

Correct Answer: B. Granting access only to data and operations needed for a defined task

Question 5

What does encryption in transit primarily protect?

A. Data moving between communicating systems

B. Deleted database records

C. The accuracy of business rules

D. The completeness of audit policies

Correct Answer: A. Data moving between communicating systems

Question 6

Which control most directly improves accountability for privileged activity?

A. Shared administrator credentials

B. Independent, protected audit logging

C. Removing timestamps from logs

D. Disabling failed-login records

Correct Answer: B. Independent, protected audit logging

Question 7

A service needs to verify that a customer is over a required age but does not need the birth date. Which principle is most directly applied by storing only the threshold result?

A. Data minimization

B. Privilege escalation

C. Non-repudiation

D. Database normalization

Correct Answer: A. Data minimization

Question 8

Why can removing names from a dataset fail to achieve anonymity?

A. Names are required for every database query

B. Other attributes may permit linkage or re-identification

C. Encryption automatically restores names

D. Pseudonyms are always public

Correct Answer: B. Other attributes may permit linkage or re-identification

Question 9

Which situation is an example of separation of duties?

A. One administrator creates and approves a payment

B. A user receives every available role

C. One employee creates a supplier while another approves payment

D. A developer uses production credentials in testing

Correct Answer: C. One employee creates a supplier while another approves payment

Question 10

What is a major limitation of encryption at rest?

A. It cannot protect files or backups

B. It necessarily prevents all authorized queries

C. It may not protect data from a compromised account issuing legitimate queries

D. It eliminates the need for key management

Correct Answer: C. It may not protect data from a compromised account issuing legitimate queries