UPI Study › Courses › Ethics in Technology › Free lessons › Lesson 8.2 Free with a free account
Protecting Data Inside Databases
Ethics in Technology · Chapter 8: Guarding the Data Vault: Database Protection, Cloud Risks, and Intrusion DetectionSection 8.2 · lesson 36 of 11615 min · free with a free account
Free preview
Create a free account to keep watching
It takes a minute and costs nothing. Your free account unlocks all of Chapter 1 and 3 more lessons of Ethics in Technology.
Lesson complete
Earn the 3 college credits for Ethics in Technology
Enrolling adds a quiz after each lesson, the graded work and the official transcript. Recommended for credit by NCCRS.
Next lesson: Database Roles and Accountability →← What Database Management Systems Do and Why Protecting Them Is CriticalNext lesson: Database Roles and Accountability →
In this lesson
Roles, encryption, masking, evidence, and tested recovery.
- Match database controls to distinct failure scenarios
- Design roles and finer restrictions around real duties
- Distinguish encryption, masking, and protected evidence
- Set recovery objectives and reconcile copies with retention
Free study notes
Get this lesson's notes by email
The key points and 4 practice questions with answers, in your inbox. One email, free.
One email. Unsubscribe in one click.
Transcript
Everything said in the video, section by section (1,815 words). Read along, or search it.
Chapter 8
Protecting Data Inside Databases
Databases need controls inside the system, because reaching the service does not establish a legitimate purpose. An accepted account can be misused, while a defective application may request more information than intended. A copied backup or compromised supplier device introduces another route with different protection needs. This lesson matches controls to those situations, rather than treating one feature as complete security. We begin with roles, least privilege, separation of duties, and regular access review. Then we narrow access using views, selected columns, relevant rows, and appropriate context. Encryption protects different paths, depending on where data is decrypted and who can use the keys. Masking, tokenization, and redaction can reduce the real information exposed for a particular purpose. Hardening and updates remove unnecessary exposure, while proportionate auditing supplies protected evidence. Finally, we choose recovery objectives, test restoration, and protect copies against their intended failure scenarios. These decisions also support privacy by limiting access, exposed values, and unnecessary retention.
Layered Defense
A Request Reaching the Database Still Needs Appropriate Limits
The source presents layers that answer different questions about the same information. Network and host controls govern the routes and machines that may reach a service. Authentication checks the presented identity or credentials, without proving every later request is appropriate. Roles and privileges limit what an accepted account can read, change, or administer. Views and masking narrow which rows, fields, and values should be exposed. Stored-data encryption affects whether taken files remain readable when the necessary keys are unavailable. Auditing records relevant activity, while recovery prepares to restore an appropriate system state. These functions work together, but are not literally checks performed in one universal sequence. A backup file taken from storage may bypass permissions inside the running database. A person with valid access may receive plaintext despite transparent encryption protecting the files. Ask which scenario each control addresses, then identify the paths and consequences that remain uncovered.
Role Design
Reusable Job Permissions Need Least Privilege and Regular Review
Role-based access control assigns permissions to roles, and then assigns people to appropriate roles. This makes a job's permissions reusable, rather than requiring a separate design for every individual. Joining and leaving can involve role membership changes, making administration easier to review. Transfers still require obsolete access to be removed, rather than merely adding the new role. Least privilege limits each role to what its duties actually require. Separation of duties divides sensitive decisions, such as creating a payment and approving it. Periodic review checks membership and permissions, including direct grants or nested access that might remain. Service identities deserve the same attention, because an application's broad privileges can amplify a compromise. Give applications only required access, and prevent unnecessary interactive use where the platform supports it. Protect credentials through an appropriate secrets service, rather than committing them to a source repository. Roles improve administration when maintained; a poorly designed or forgotten role can still grant excessive authority.
Finer Restrictions
A Job Title Alone Cannot Express Every Legitimate Need
A view exposes a selected query result, often providing a department with a useful slice. Its permissions must be designed alongside the underlying tables and the product's actual behavior. Column permissions can limit particular fields in an otherwise useful table. Row-level policies can restrict records according to tenants, regions, assignments, or other relevant conditions. Check privileged bypasses and policy details, rather than assuming every account is filtered identically. A job title alone may not describe the patient's current relationship with a clinician. Context-sensitive attributes can supplement roles, helping avoid a proliferation of narrowly defined job roles. Emergency access may need controlled, temporary exceptions, with a purpose, review, and strong evidence. A restricted view also does not guarantee that the returned information is anonymous. A small aggregate group, or repeated overlapping queries, can reveal a particular individual. Limit both direct exposure and foreseeable inference, while preserving appropriate access for legitimate work.
Encryption Choices
Stored-File Encryption Does Not Restrict Ordinary Decrypted Queries
Transparent data encryption protects covered stored files, and supported backups, under the chosen implementation. It normally decrypts information for accepted queries, so it does not replace account permissions. A hospital enabling it has improved one layer, rather than secured every possible patient-data use. Staff browsing without a clinical purpose may still receive readable values through an accepted account. Column encryption protects selected fields, but the separation depends on keys and where decryption happens. Application-level encryption encrypts before storage, moving important duties to clients and their key arrangements. Both can limit searching, sorting, joins, or other operations, depending on their design. Some implementations permit selected encrypted queries or protected processing, so the restrictions are not universal. Encryption in transit protects communication, separately from how stored files are protected. Clinical access rules, monitoring, hardening, recovery, and appropriate communication protection therefore remain necessary. Choose the encryption boundary deliberately, and verify which paths still provide readable information.
Key Management
Encryption Depends on Who Can Use and Recover the Keys
Encryption depends on who can obtain or use the necessary key material. A suitable managed key store or hardware module can separate important authority from ordinary storage access. The actual identities and permissions matter more than the physical location alone. An account allowed to use both storage and keys may still undermine that separation. Limit key use to justified duties, and protect evidence of sensitive key operations. Plan rotation or replacement according to risks, requirements, and the selected product. Preserve the material and dependencies needed to restore each encrypted copy. Test that recovery, rather than assuming a key name or old certificate will be sufficient. Taken files may become readable if the same intruder can also use their keys. Losing all usable keys can make the data unrecoverable, unless another recoverable copy exists. A locally stored key may have other protection; neither local storage nor remote storage determines the outcome alone.
Masking and Minimization
Change What Users Receive, or Remove Real Values from a Copy
Static masking changes selected real values permanently in a separate copy, leaving production unchanged. It suits testing, training, and demonstrations that do not require real identities. Dynamic masking changes what a particular user receives, while the stored value remains real. It can reduce casual exposure, but flexible queries may still allow sensitive values to be inferred. Tokenization substitutes tokens, with any reversible mapping protected separately from ordinary users. Redaction removes fields entirely when an export or report does not need them. For testing, produce a minimized or safely masked dataset through a repeatable delivery process. Preserve required formats, distributions, and relationships so the dataset supports realistic work. Check rare combinations and correlated fields, because replacing a name alone does not guarantee anonymity. Consistent substitutions may preserve useful relationships while also requiring careful assessment of reversibility and linkage. Assign an owner, expiry, access rules, and evidence; a transformed copy still needs appropriate protection.
Patching and Hardening
Remove Unnecessary Exposure and Verify the Actual Service Boundary
Hardening reduces a system to the functions and access paths it actually needs. A prioritized update process addresses known defects, with a faster route for urgent risks. Replace unsafe default credentials, and remove unnecessary sample data and demonstration accounts. Disable unused features and protocols after checking that required work will continue correctly. Restrict network reachability to necessary application, administration, and service paths. Separate powerful administration from everyday activity, and apply appropriate strong authentication. Maintain a configuration baseline, then investigate unexplained changes and drift. Cloud services change responsibilities according to the product, configuration, and contract. A managed provider may maintain certain layers, while customers retain duties for their applicable controls. Check identities, permissions, connectivity, data, keys, and backup settings against that actual boundary. Do not assume every hosted product patches every layer, or that convenience removes the need for careful configuration.
Audit Design
Record Useful Actions Without Creating an Unnecessary Data Replica
Access rules describe what may happen; auditing supplies evidence of relevant activity that did happen. Useful records include identity, origin, objects, action type, outcome, volume, and time. Permissions, roles, accounts, administration, and audit-setting changes deserve particular attention. Monitoring can flag unusual hours, large reads, or unexpected exports for investigation. An alert is a reason to assess context, rather than automatic proof of misconduct. Avoid unnecessary returned records, credentials, tokens, and plaintext values embedded in query text. Logging complete results may create another sensitive replica with different readers and retention. Even action metadata and record identifiers can reveal personal behavior, so protect their use. Send suitable evidence to a protected destination that observed administrators cannot casually change. Restrict readers and choose a justified retention period that supports investigation and applicable duties. The proposed seven-year archive of full queries and results needs redesign, rather than assuming more logging always helps.
Recovery Objectives
Choose Acceptable Data Loss and Recovery Duration Deliberately
Recovery planning distinguishes the point to which data must be recovered from the time available to recover. The recovery point objective expresses the recoverable point required after a disruption. It reflects how much data loss the relevant process can tolerate. The recovery time objective sets a target duration for recovering the relevant system or service. A twenty-four-hour recovery point may permit up to a day's work to be lost. A four-hour recovery time requires tested capabilities and people available to use them. Those are example decisions, rather than universal objectives for every database. Payment processing and an internal reporting system may have very different consequences from lost work. Backup frequency, successful completion, transaction-log recovery, and recovery architecture affect the recoverable point. A rehearsal measures whether restoration, dependencies, validation, and coordination can meet the target time. Assign owners to these choices, so acceptable losses and the cost of meeting them are explicit.
Protected Copies and Retention
A Copy Must Survive the Failure It Is Intended to Address
Keep recoverable copies separated from the failures they are intended to survive. Several copies may still share one fire, account, storage service, or production administration path. Offline or appropriate immutable protection can reduce deletion risks, but settings and privileged bypasses matter. Some immutability modes permit authorized overrides, so verify the required resistance in practice. Protect backup contents with suitable encryption, and preserve the key material required for restoration. Separate applicable backup authority from routine production administration, and restrict reading, copying, changes, and deletion. Audit sensitive backup operations, including attempts to remove protected copies. Restore exercises should measure duration, validate information and dependencies, and address failures before an incident. An untested backup exists, but its ability to meet recovery needs remains unproven. Apply justified retention schedules to copies, including a procedure for reapplying valid deletions after restoration. Older backups must not silently revive information that the organization has decided should remain deleted.
Worked Review
Choose the Control by the Failure, Then Check Its Remaining Gaps
Choose controls by the particular failure, then check which gaps remain. Curiosity with a valid account calls for limited privileges, relevant records, reduced exposure, and fair review. A copied backup needs protected storage access and encryption with controlled key use. An unintended application query needs narrow service permissions, secure query design, and appropriate evidence. Administrative destruction calls for separated recoverable copies, suitable deletion resistance, and tested restoration. Development needs can often be met through minimized or safely masked data, controlled delivery, and expiry. A published defect requires affected systems to be identified and a tested update to be prioritized. No single feature replaces these different protections, and no alert or role name guarantees correct behavior. Least privilege limits people, masking limits exposed values, and retention limits duration. Recovery also needs to preserve valid deletion decisions when older information is restored. Responsible database protection combines practical security, privacy, reliable recovery, and clear ownership across every sensitive copy.
About Ethics in Technology at UPI Study
Ethics in Technology (Computer Science 195) is a self-paced online course of 116 video lessons in 15 chapters, from cybersecurity basics, privacy and surveillance to big data, hacking, malware, network defense, intellectual property, cybercrime, encryption, emerging technology and digital citizenship. It carries a NCCRS credit recommendation for 3 semester credits.
Every lesson transcript is free on pages like this one, and the videos are free with a free UPI Study account. Enrolling adds a practice quiz after each lesson, the graded work and final exam that earn the credit, lifetime access, and an official transcript on completion. UPI Study has helped over 130,000 students with college credits. ACE and NCCRS have over 2,100 cooperating colleges that will consider accepting credits; the final decision is with the universities.
Enroll now → Course details Download the syllabus All Computer Science courses
Compare: Cybersecurity vs Ethics in Technology · Which ethics course?
Why take it here
Why students take Ethics in Technology with UPI Study
Where the credit goes
Universities that work with NCCRS
Ethics in Technology carries a NCCRS credit recommendation. These universities work with NCCRS; some are UPI Study's signed partners. ACE and NCCRS have over 2,100 cooperating colleges that will consider accepting credits; the final decision is with the universities.
Thomas Edison State UniversitySigned partner
University of the PeopleSigned partner
Charter Oak State CollegeSigned partner
Strayer UniversitySigned partner
Columbia Southern UniversitySigned partner
Indiana TechSigned partner
Penn StateWorks with NCCRS
Southern New Hampshire UniversityWorks with NCCRS
SUNYWorks with NCCRS
+many more cooperating universitiesFind my college →Find my college → Not listed? Ask Athena in the corner of this page, or book a 15-minute call.
FAQ
Questions students ask us
About Protecting Data Inside Databases
What is role-based access control in a database?
Does transparent data encryption stop insiders from reading data?
What is the difference between static and dynamic data masking?
What is the difference between RPO and RTO?
About the Ethics in Technology course
How many college credits is Ethics in Technology?
How much does Ethics in Technology cost and what is included?
Which universities accept UPI Study credits?
How long does Ethics in Technology take?
How are the exams done?
How do my credits reach my college?
Ready for the full course? Earn 3 credits in Ethics in Technology.
116 video lessons, a quiz after each one, and the graded work that earns the credit. Recommended for credit by NCCRS.
3 credits · NCCRSEnroll →