Episode 17 — Symmetric vs. Asymmetric Encryption (1.3)
In this episode, we start by looking at the different levels where encryption can be applied, because encryption is not just one switch that protects everything in the same way. You may hear that a laptop is encrypted, a file is encrypted, a database is encrypted, or a specific record is encrypted, and each of those statements means something different. The level matters because encryption protects data in a particular place, during a particular state, against particular risks. Full-disk encryption may protect a stolen laptop, but it may not protect a sensitive file after a signed-in user opens it and sends it to the wrong person. Database encryption may protect stored information, but it may not stop an application with permission from reading that information. Your goal is to understand what each level protects, what it does not protect, and how to choose the right level based on the risk.
Before we continue, a quick note. This audio course is part of our companion study series. The first book is a detailed study guide that explains the exam and helps you prepare for it with confidence. The second is a Kindle-only eBook with one thousand flashcards you can use on your mobile device or Kindle for quick review. You can find both at Cyber Author dot me in the Bare Metal Study Guides series.
Before you compare the levels, it helps to remember what encryption is trying to do. Encryption transforms readable data into protected data that should not be understandable without the right key. That can protect confidentiality when information is stored on a device, saved in a file, written into a database, or moved between systems. But encryption does not automatically solve every security problem. If an authorized user opens encrypted data, the system may decrypt it for that user. If an attacker steals the user’s account, encryption may not help if the attacker can access the data through the normal application. If the key is stored carelessly, the protection may be weakened. Encryption is powerful, but it must be matched to the threat. You always want to ask what form the data is in, who can access it, where the key is, and what kind of failure you are trying to prevent.
Full-disk encryption protects the entire storage device, or nearly all of it, so the data on that device is not easily readable if the device is lost or stolen while powered off or locked. This is common for laptops because laptops leave buildings, sit in cars, pass through airports, and sometimes disappear. If someone steals an encrypted laptop and removes the drive, the data should still be protected because the drive contents are not readable without the right key or authentication process. That is a major benefit. Full-disk encryption helps protect data at rest on the device. Data at rest means data stored somewhere rather than actively moving across a network or being used in memory. For many end-user devices, full-disk encryption is a basic protection because physical loss is a realistic risk.
Full-disk encryption has limits that you need to understand. Once the authorized user signs in and the system unlocks the drive, the operating system can read and write data normally. That is necessary because the user needs to work. But it means full-disk encryption does not protect every file from every threat while the device is actively in use. If malware runs under the user’s account, it may be able to read files that the user can read. If the user copies a file to an unprotected location, full-disk encryption on the original device does not follow the file everywhere. If the user emails sensitive information, the disk encryption did not protect the message after it left. So full-disk encryption is very useful for lost or stolen devices, but it is not a complete answer for access control, data sharing, malware, or application-level misuse.
Volume encryption is similar in purpose but applies to a specific volume rather than necessarily the entire physical disk. A volume is a logical storage area that the system treats as a place where files can be stored. One physical drive may have more than one volume, or a volume may be built from storage provided in different ways. Volume encryption protects that logical storage area. This can be useful when only certain storage areas need protection, or when an organization wants to encrypt specific partitions, removable drives, or mounted storage containers. The idea is still focused on data at rest. If someone gains access to the raw storage without the proper key, the encrypted volume should not reveal useful data. Like full-disk encryption, volume encryption is strongest against offline access to storage, theft, and unauthorized reading outside the normal unlocked environment.
Partition encryption is closely related to volume encryption. A partition is a defined section of a physical drive. You might have one partition for the operating system and another for data, or separate partitions for different purposes. Encrypting a partition means protecting that section of the drive rather than the whole device. This gives more targeted protection, but it also requires careful planning. If sensitive files are stored outside the encrypted partition, they may not be protected. If temporary files, backups, cached data, or logs are written somewhere else, sensitive information may leak outside the protected area. That is one reason full-disk encryption is often simpler for laptops and general-purpose devices. Targeted encryption can be useful, but it depends on knowing where the data really goes. Security weakens when sensitive data quietly appears in places the encryption plan did not cover.
File-level encryption protects individual files rather than the whole disk or volume. This can be helpful when a specific document, spreadsheet, archive, image, export, or report needs protection even if it moves away from the original device. For example, a sensitive file might be encrypted before it is stored on shared storage or sent to another approved person. The advantage is that the protection can travel with the file in some situations. If someone copies the encrypted file without the key, the content should still be unreadable. File encryption can also support more selective protection. You may not need to encrypt every file in the same way, but certain files may contain sensitive information and deserve stronger handling. This level is useful when the risk follows the file itself, not just the device where the file was first stored.
File-level encryption also has limits. If an authorized user opens the file and saves an unencrypted copy, the protection may be lost. If the user copies text from the file into an email or another application, the encryption no longer protects that copied content. If the key or password used to protect the file is weak, shared carelessly, or stored in the same place as the file, the protection becomes much less meaningful. File encryption can also make collaboration harder if people cannot manage keys or access properly. You should think of file encryption as a targeted confidentiality control. It helps protect a file when it is stored, copied, or moved, but it still depends on good key handling, careful user behavior, and clear rules for when decrypted information can be used.
Database encryption protects information stored inside a database environment. A database is designed to organize and retrieve structured information, often for applications, websites, business systems, or reporting tools. Database encryption may protect the database files on disk, certain tables, certain columns, or the database backups. This can be very important because databases often store valuable information, such as customer records, account details, transaction history, employee information, or sensitive business data. Encrypting the database can reduce the risk if storage is stolen, backups are exposed, or someone gains access to raw database files without going through the normal application controls. It can also support compliance expectations when certain categories of sensitive data must be protected at rest. The key idea is that database encryption protects stored database content, but the exact protection depends on how and where encryption is applied.
You need to be careful not to overestimate database encryption. If an application is authorized to read the database, the database may decrypt data for that application during normal use. If an attacker compromises the application or steals credentials that allow normal database queries, encryption at the storage level may not stop the attacker from seeing data through the approved path. This is why encryption must work with authentication, authorization, logging, monitoring, and least privilege. A database should not only be encrypted. It should also limit who and what can connect, what actions are allowed, and what activity is recorded. Database encryption is very helpful when the threat is exposure of stored data, backups, or raw files. It is less helpful when the threat comes through an authorized application path that already has permission to read the data.
Record-level encryption is more targeted. A record is a single entry or row of data, depending on how the system is designed. Record-level encryption protects specific records so that access can be controlled more precisely. This may be useful when different users or applications should see different pieces of information inside the same larger system. For example, one record might contain especially sensitive personal or financial details that should remain protected except for a limited process. Record-level encryption can reduce exposure if only some data needs stronger protection, or if different records have different sensitivity levels. It can also help when sensitive data is stored alongside less sensitive data. Instead of treating the entire database the same way, the organization can protect specific records based on the risk attached to them.
Field-level encryption is another targeted approach, and it is often discussed alongside record-level encryption. A field is a specific value inside a record, such as a Social Security number, payment card value, medical detail, or other sensitive attribute. If you encrypt only that field, the rest of the record may remain usable while the most sensitive value stays protected. This can be very useful for applications that need to display general information without exposing the most sensitive parts to every user or process. It can also reduce the amount of sensitive data visible during support, reporting, or routine administration. But this approach requires careful design. The application must know when to decrypt the field, who is allowed to see it, how keys are protected, and how searching or reporting will work when the protected value is not readable in normal form.
Choosing the right encryption level depends on the risk you are trying to reduce. If your main concern is a lost laptop, full-disk encryption may be enough for that specific risk. If your concern is a sensitive file being copied outside the original device, file-level encryption may be more appropriate. If your concern is exposed database backups or raw database storage, database encryption may help. If your concern is that only certain sensitive values inside a database should be visible to certain users or processes, field-level or record-level encryption may be needed. You are not choosing the fanciest option. You are matching protection to the way the data is stored, used, moved, and attacked. Strong security usually comes from the right combination of controls, not from one control applied everywhere without thought.
The conclusion is that encryption level matters because data does not live in only one place or one form. Full-disk encryption protects a device when storage is lost or stolen, but it does not control every action after the device is unlocked. Volume and partition encryption protect specific storage areas, but they depend on sensitive data staying inside those areas. File encryption can protect selected files as they move, but users and keys must be managed carefully. Database encryption protects stored database content and backups, but it may not stop misuse through an authorized application. Record-level and field-level encryption protect more specific pieces of data when finer control is needed. As you study Security Plus, keep asking where the data is, who needs to use it, what threat you are reducing, and whether encryption at that level still protects the data when the situation changes.
