与所有行业一样，信息安全行业（通常被称为“网络安全”）的激烈讨论聚焦于一小撮最佳的实践。
此系列中最高的一个是全磁盘加密，安全专家认为它是神圣不可侵犯的，每个人都应该最少或最低限度地使用它。这种加密技术可以确保抢走您设备的人无法知道保存在设备上的所有信息。
但我想说，你们中的大多数人最好不要使用它。我知道这听起来很疯狂，因为我正是安全行业从业人员之一，但请听我说。
我绝不会说服您不要使用加密-如果没有加密，我们每天依赖的数字工具将无法使用。这也是为什么我不反对有期限加密。但特别地，针对全盘加密，针对某些用户，希望你们不要使用。
我想说的是，对于大多数计算机只处理普通事物的人来说，全盘加密过犹不及。与其他静态数据加密相比，这些用户无法从全盘加密获得可观的安全性提高，却付出了可衡量的性能代价。这不仅是使效率或加载时间出现问题，也增加了用户的成本。
事实上存在可以为普通用户解决日常安全问题的替代方案，他们也可以提供与全盘加密所提供的保护水平相当的保护级别。由于大多数消费类科技公司都采用了全磁盘加密，它们确实少见，但是它们已经存在了。
必须有另一种方式
全磁盘加密是迄今为止最常用的静态数据加密方案。将静止数据视为保存在某种存储介质（如硬盘驱动器）上以备后用的数据，而不是通过某些通信通道（如Internet）移动的数据（即传输中的数据）。
通常，全盘加密在计算机复杂性的级别上实现，处理如何在硬盘驱动器上组织与信息表示环境分离的原始字节。我们称之为块设备级别，因为全磁盘加密已应用于作为硬盘驱动器分区的块设备（对于大部分硬盘来说只是一个奇特的名称）。
该级别高于电子信号，但低于文件系统，在文件系统中，文件系统是您的计算机将字节视为文件而不是字节的地方。文件系统是一种组织结构图，它告诉您的计算机如何分辨组成文件的字节，以及如何区分文件和文件类型。
那么，不是全盘加密的磁盘加密到底是什么呢？
答案是文件系统级加密。在文件系统级加密（也称为“基于文件的加密”）下，系统对某些目录（即文件夹）及其中所有的文件和目录进行加密，然后递归进行到最高目录最终包含的所有内容。文件系统级加密还可以加密整个文件系统，从而自动保护保存在其上的所有内容。但针对我们的目的，我们考虑一种基于文件的加密，该加密使用户可以选择要加密的文件和目录，而不用考虑其余部分。
确切地说，我想到的模型是仅加密用户文档，媒体和其他文件的模型，在Unix系统上，这些文件最终将位于用户/ home目录下的子目录中。这样一来，用于运行程序的核心系统文件和软件二进制文件就被保留了下来，仅保护您实际的个人数据。
顾名思义，这发生在文件系统级别，是从全磁盘加密开始的一级。这产生了一些重要的含义。首先，您所有的加密文件都已经被理解为文件，这意味着它们可以单独解密。
它还允许用户使用文件权限控制来增强文件加密。由于已使用全盘加密对整个磁盘进行加密，因此知道磁盘解密密码的用户必须先输入该密码，然后才能进行其他操作。但是和用户文件一样，操作系统需要运行的所有文件也都被锁定。操作需要将整个块设备解锁，并且一旦磁盘被解锁，便全部打开。
通过文件级加密，您的完整操作系统将区分解密内容和解密时间。每个用户都可以定义加密哪些文件，使用哪些密码。因此，使用基于文件的加密，一个用户可以解密他们的文件，而仍然将另一用户的数据锁定。如果不想，则不必解密加密的目录-如果您不想打开任何文档或媒体文件，则可以使用计算机程序，而将个人文件锁定，这样，恶意软件则无法感染它们。
告诉我你得到了什么
如果基于文件的加密没有比全盘加密真正的优势，我不会提出。基于文件的加密的最大优势在于其速度使全盘加密成为现实。这是因为基于文件的加密系统可以更有效地读写磁盘。
要了解这种情况为什么会出现，我们需要了解加密块设备（例如闪存）的工作方式。就像术语更新一样，“密文”是信息的加密形式，没有正确的密钥就无法读取，而“明文”是信息原始可理解的形式。
当您解密静止的加密数据时，您的计算机实际上并没有将存储硬件上的所有位从密文更改为明文。这将花费很长时间，并且每次启动和关闭设备时，都会立即关闭整个驱动器，而驱动器上的物理位保持原样。但是在应用正确的密钥后，它们会通过内存中存在的缓冲区进行读写。缓冲区在读取信息时执行解密操作，并在写入时执行加密操作。在对数据进行解密和读取时，纯文本将保留在内存中，以便在完成处理之前可以方便地使用。
与未加密的读取和写入相比，添加这么多额外的步骤会使事情变慢，速度降低了十倍之多。对于全盘加密，您在计算机上所做的每件事都必须通过此解密缓冲区读取，因为整个块设备及其内容均已加密。至关重要的是，这包括运行操作系统本身的所有二进制文件及其上的所有软件。
但是使用我们选择的基于文件的加密配置，仅您的用户文档和媒体文件需要解密。您每天使用的大多数软件都不在这些文件中。许多计算任务根本不需要解密任何东西。仅举一个例子，我们在网络浏览器中的生活是如此之多，你也许可以试着数数24小时内打开的用户文件数量。
显然，您的计算机有时必须解密一些数据，但是即使那样，由于加密是在文件系统级别实现的，基于文件的加密OS可以比全盘加密模拟软件更有效率地进行解密。
最终，所有磁盘访问，无论是对完全加密的磁盘还是对文件系统加密的磁盘，都需要获得操作系统核心内核的批准。但是，由于全盘加密中的加密由系统管理特权级别进行管理，因此内核也必须参与通过解密缓冲区读取块设备的操作。
基于文件的加密不会遇到这个障碍，因为它只需要非特权用户权限即可解密用户自己的文件。与基于文件的模型下的相同过程相比，全磁盘加密必须获得内核的额外权限才能读取或写入磁盘。
减少磨损，提高效率
文件系统加密的另一个主要方面是，它可以减少驱动器的磨损。与基于全盘加密的系统相比，文件系统加密对于每个单独的操作仅写入较少的数据。
同样，用于全盘加密的加密是在块设备级别上的，它只能看到大小统一的字节块。但是，并非所有数据都占用整个块。实际上，很多都不是。因此，块级加密实际上阻碍了计算机的内置效率机制，该机制仅更改文件中实际更改的部分。如果没有全盘加密，计算机则可以将内存中文件的更新版本与驱动器上的先前版本进行比较，确定现在哪些部分不同，然后将这些新的不同部分写入文件中。
您的计算机也可以通过基于文件的加密来实现类似有效益的写入：更新内存中文件的纯文本版本时，该文件将通过加密缓冲区进行过滤并暂时保存在内存中，然后操作系统会比较新的加密版本与驱动器上的先前加密版本进行比较，以确定实际更改的位，并仅写入这些位。全盘加密则是另一回事。在这种模型下，OS知道文件的哪些部分已更改，但是由于加密是按块而不是按文件进行的，因此OS现在必须将文件转换为块，对块进行加密，并将这些块写入块设备。文件中的修改不等于一个块的数据量，可以跨越多个块，然后必须通过加密的缓冲区对所有这些块进行过滤，再将其全部写回到块设备中。即使所有更改过的数据都存储在一个块中，全部块都会被重写，这导致大量的写入消耗。
就其本质而言，文件系统级加密具有灵活性，而全磁盘替代方案则没有。如上所述，全磁盘加密是全部。它会加密整个系统，核心文件和所有用户数据。这意味着您想要更快加载的非敏感数据（例如，用于编辑的视频或音频媒体）会因读写速度变慢而受到阻碍。
全盘加密对于多用户系统（例如共享家用设备）也不是理想的选择。任何想要使用该设备的人都必须知道全盘解密密码，否则该设备甚至无法启动进入操作系统。为任何一个用户解锁设备都会为所有用户解锁数据。这也意味着您无法启用可以使用操作系统访问被阻止用户文件的非特权“客人”帐号之类的功能。
最后，基于文件的加密对于大多数人来说更合理。我说过，安全涉及不便，这是事实。但是，在设计一组安全性实践时，为减轻攻击风险而带来的不必要的麻烦是没必要的。实际上，这只会带来伤害：如果用户的安全程序过于繁琐，则该用户最终会被‘偷工减料’。
简而言之，对于您最可能使用而言，全盘加密是过大的。我们并列的两种加密配置以不同的方式保护您。它们之间的安全程度的主要区别在于，基于文件的加密仅保护用户文档和媒体文件。相比之下，全盘加密会加密那些文件以及核心OS文件。
一些潜在的缺点
您可能由猜到，不像全盘加密那样对所有内容进行加密是有弊端的。从理论上讲，使用基于文件的加密对设备进行物理访问的攻击者可能会更改未加密的OS数据。这样，攻击者要么启动您的计算机以运行他们刚才放置在其中的代码，要么在您启动计算机后他们的恶意代码才能窃取您的数据。
听起来很糟糕，事实也的确如此，但也可能并不会发生。确实，通常甚至没有对手会尝试。它们要么太原始以至于文件系统级别的加密足以阻止它们，要么太复杂（即功能强大）以至于拥有更有效的获取数据的方法。
对于绝大多数用户而言，静态数据加密解决的问题是阻止盗窃物理设备的小偷获取数据。这就是为什么聪明的盗贼不依靠获取您的数据，而是求助于设备来赚钱。在这种情况下，基于文件的加密和全盘加密都可以很好地工作。
相对的，如果您的对手是政府机构（例如执法部门），则基于文件的加密和全盘加密都不会为您提供帮助。根据司法管辖区，他们可以合法地命令您解锁设备。几乎在所有其他地方，政府都可以向将您的数据存储到其云中的服务商发出命令，以移交他们想要的东西，而在管控之下，我们只能说，有更直接更痛苦的方式使您遵从。
假设出于争辩目的，您正在监视一个政府行为者，并且上述所有技术均无效。只有在政府没有更复杂的方式来攻击您的系统时，全盘加密才会起作用。对于世界上大多数强大的政府来说，这不是一个问题，因为它们足够先进，可以以某种方式进行暴力破解或回避加密。
因此，在很多情况下，全盘加密确实可以为您省钱：当您的敌人是政府时，您可以承受身体上的酷刑，但是政府没有能力进行基本上每个G20国家可以做到的，动作电影中酷炫的黑客攻击。
这并不是说，根据您的对手，没有什么可以阻碍的方法-使攻击者的获得尽可能艰难是一种历史悠久的安全策略-只是要意识到这一切都已充分-磁盘加密可以保证您的安全。但是，并不是每个人都需要这个。
实用加密，不切实际的实现
那些确信并想要您的读写性能和SSD寿命的人，可能想知道您可以在哪里找到这种出色的文件级加密技术。好吧，那就是事情变得复杂的地方。您会看到，这很难在实践中进行设置。
主要原因是主流的消费者操作系统已经进行了全盘加密。苹果和谷歌已经为其移动设备配置了全盘加密，并拒绝用户禁用它。苹果和微软默认情况下启用全盘加密，但是它们都提供了强行禁用全盘加密的方法。
对于基于Linux的桌面操作系统（个人喜好），安装使用文件系统级别的加密为您的系统充电就像检查一个复选框一样容易，但是这很快就成为了dodo的方式。 Ubuntu最近在其图形安装程序中弃用了该安装选项，而Linux Mint是我所知的唯一仍提供它的发行版。即使是Arch Linux之类的DIY发行版，也会阻止您尝试配置文件级加密。相反，他们引导您针对文档更详尽的信息进行块加密。
如果您愿意按照要求的长度关闭全盘加密，则可以使用一些选项。 VeraCrypt是更强大的选项之一。 VeraCrypt诞生于放弃已经失效的TrueCrypt套件的愿望，它是一种图形工具，用于在现有文件系统之上创建加密的目录结构。它拥有与未加密文件系统相当的读写速度选项，甚至还有诸如可拒绝加密之类的超级间谍功能，其中加密数据看起来就像驱动器上的正常未使用空间。
那么，为什么我要花所有时间告诉您这些并非最多（但肯定不是最少）访问的东西？从根本上讲，重要的是要知道有什么可能，这样您才可以做出最明智的选择，从而创建对您的需求最敏感的计算体验。计算机是可以无限定制的，因此用户没有理由也不应该拒绝最适合他们的设置-不了解您的选择是最糟糕的原因。
欣赏可能性不仅关乎拥有最好的数字生活，还包括向开发人员提供支持（即使只是用户服务），使之成为可能。如果这听起来可以使您的生活变得更好，那我想对对您说，请继续努力吧！
The Case Against Full-Disk Encryption (computing data management)
Like with any industry, the information security industry, more commonly referred to as "cybersecurity," for all its raging debates, has rallied around a small corpus of best practices.
One of the highest on this list is full-disk encryption, which security experts regard as sacrosanct, a no-brainer that everyone should use at the barest of minimums. This is the encryption that ensures that someone who snatches your device won't be able to know everything you've got saved on it.
I'm here to make the case that most of you are better off not using it. I know this might sound crazy, since I'm kind of the security guy here, but hear me out.
I am in no way about to talk you out of using encryption -- without it, the digital tools that we rely on every day would be unusable. That's why I'm not arguing against encryption, period; but specifically against full-disk encryption, and only for certain users.
What I contend is that, for most people facing the overwhelmingly most common use cases, full-disk encryption is overkill. These users enjoy no measurable gain in security compared to alternative data at rest encryption, yet they pay for it with a measurable performance hit. This isn't just a matter of efficiency or load times, but literal increased cost to users, too.
Alternatives exist which afford normal everyday users, with normal everyday security concerns, a level of protection commensurate with what full-disk encryption offers. They are admittedly a bit off the beaten path, as most consumer tech companies have adopted full-disk encryption, but they're out there.
There Has to Be Another Way
Today, full-disk encryption is by far the most common kind of encryption scheme for data at rest. Think of data at rest as the data you keep on some kind of storage medium (like a hard drive) for use later, not the kind of data that is moving over some communication channel like the Internet (that would be data in transit).
In general, full-disk encryption is implemented on a level of computer complexity that deals with how raw bytes, decoupled from the context of information representation, are organized on the hard drive. We will refer to this as the block device level, since the full-disk encryption is applied to the block device that is a hard drive partition (just a fancy name for a large segment of your hard drive).
This level is higher than the electrical signal level, but below the filesystem, the latter of which is the point at which your computer sees bytes as files instead of just bytes. The filesystem serves as a kind of org chart that tells your computer how to tell what bytes go together to make up files, and how to tell files and file types apart.
So what exactly is this disk encryption that isn't full-disk encryption?
The answer is filesystem-level encryption. Under filesystem-level encryption, also called "file-based encryption," a system encrypts certain directories (i.e. folders) and all the files and directories within them, recursively down to everything that the uppermost directory ultimately contains. Filesystem-level encryption can also encrypt an entire filesystem, automatically protecting everything that gets saved on it. For our purposes, though, we will consider the kind of file-based encryption that lets users choose which files and directories to encrypt, leaving the rest alone.
To be precise, the model I have in mind is one which encrypts only the user documents, media, and other files which on Unix systems would end up in the user's subdirectory under the /home directory. This way, the core system files and software binaries for running programs are left alone, and only your actual personal data is guarded.
This, as the name implies, occurs at the level of the filesystem, which is one level up from where full-disk encryption is operative. This yields some important implications. To start with, all your encrypted files are already understood as being files, meaning they can be decrypted individually.
It also allows users to augment file encryption with file permission controls. Because the full disk is encrypted under full-disk encryption, a user who knows the disk decryption password has to enter it before anything else can proceed. But along with the user files, all the files the OS needs to run are also locked. A successful boot requires the whole block device to be unlocked, and once the disk is unlocked, it's all open.
With file-level encryption, your full OS enforces the distinctions for what gets decrypted and when. Each user can define which of their files are encrypted, and with which passwords. So, with file-based encryption, one user could decrypt their files and still leave another user's data locked up. You don't have to decrypt an encrypted directory if you don't want to -- if you don't intend to open any of your document or media files, you can use the computer's programs while leaving your personal files locked up where, for instance, malware can't infect them.
Show Me What You've Got
I wouldn't go to the trouble of putting forward file-based encryption if it didn't have some real advantages over full-disk encryption. To that end, file-based encryption's greatest strength is that its speed leaves full-disk encryption in the dust. That's because file-based encrypted systems read and write to the disk more efficiently.
To understand why that is, let's get into how encrypted block devices (like a flash storage) work. Just as a refresher on terminology, "ciphertext" is the encrypted form of information, which is unreadable without the correct key, while "plaintext" is the information in its original, comprehensible form.
When you decrypt encrypted data at rest, your computer isn't literally changing all the bits on the storage hardware from ciphertext to plaintext. That would take too long, and it would fry your drive in no time from writing to the entire drive every time you booted and shut down your device. Instead, the physical bits on your drive stay as they are, but they are read and written through a buffer that exists in memory after the correct key is applied. The buffer applies a decryption operation as the information is read, and an encryption operation as it is written, to the drive. While your data is decrypted and read, the plaintext is held in memory so it can be easily referenced until you are done with it.
Adding this many extra steps slows things way down compared to unencrypted reads and writes, by as much as a factor of ten. For full-disk encryption, every single thing you do on your computer has to be read through this decrypting buffer, because your entire block device, and its contents, is encrypted. Crucially, this includes all the binaries that run the OS itself and all the software on it.
But with our chosen configuration of file-based encryption, only your user document and media files need decryption. Most of the software you use on a daily basis isn't among these files. There are plenty of computing tasks that wouldn't need to decrypt anything at all. As just one example, we live in our web browsers so much that you can probably count on one hand the number of user files you've opened in the last 24 hours.
Obviously, your computer will have to decrypt some data some of the time, but even then, because the encryption is implemented at the filesystem level, your file-based encrypted OS can do so more efficiently than the full-disk encrypted analog would.
Ultimately, all disk access, whether to a fully encrypted or filesystem encrypted disk, requires approval from the core of the operating system, the kernel. However, because the encryption in full-disk encryption is managed at the system administrative privilege level, the kernel has to get involved for reading the block device through the decryption buffer, too.
File-based encryption doesn't face this obstacle, because it only requires unprivileged user rights to decrypt the user's own files. As a result, full-disk encryption has to get an additional permission from the kernel for reading or writing to the disk, compared to the same process under the file-based model.
More Efficient With Less Wear and Tear
Another major upside to filesystem encryption is that it cuts way down on wear to your drive. For every individual write operation, a system with file-based encryption simply writes less data than one with full-disk encryption.
Again, the encryption at work for full-disk encryption is on the block device level, which sees only blocks, uniformly sized units, of bytes. Not all data takes up an entire block, though. In fact, a lot of it doesn't. So encryption at the block level actually thwarts the computer's built-in efficiency mechanism that is only changing the parts of a file that actually changed. Without full-disk encryption, a computer can compare the updated version of a file in memory to the previous version on the drive, determine which parts are now different, and write those new different parts to the file.
Your computer can achieve a similar economy of writes with file-based encryption, too: when the plaintext version of your file in memory is updated, the file is filtered through the encryption buffer and held in memory temporarily, and then the OS compares the new encrypted version against the previous encrypted version on your drive to determine which bits actually changed, and only writes those.
Full-disk encryption is another story.
Under that model, the OS knows what parts of the file changed, but because the encryption is by block and not by file, the OS now has to translate files into blocks, encrypt the block, and write those blocks to the block device. Revisions in a file that don't add up to a block's worth of data can span multiple blocks, all of which must then be filtered through the encrypted buffer and written in their entirety back to the block device. Even if all the altered data is stored in one block, the whole block is rewritten, resulting in significant write overhead.
By its very nature, filesystem-level encryption yields flexibility where the full-disk alternative does not. As noted above, full-disk encryption is all or nothing. It encrypts your whole system, the core files and all user data. That means that non-sensitive data that you want to load faster (e.g. video or audio media for editing) gets hit with the read-write slowdown.
Full-disk encryption also isn't ideal for multi-user systems, such as a shared household device. Anyone who wants to use the device has to know the full-disk decryption passphrase, or the device can't even boot into the OS. And unlocking the device for any one user unlocks the data for all users. That also means you can't enable features like unprivileged "guest" accounts that can use the OS with access to user files blocked.
Finally, file-based encryption is more reasonable for what most people need. I've said it myself that security involves inconvenience, and this is true. But when designing a set of security practices, taking on more inconvenience than necessary to mitigate the risk of attack doesn't help. In fact, it only hurts: if a user's security procedures are too onerous, that user will eventually cut corners.
Simply put, full-disk encryption is overkill for the use case you most likely have. The two encryption configurations we've been juxtaposing protect you in different ways. The main difference in the degree of security between them is that file-based encryption only protects your user document and media files. By contrast, full-disk encryption encrypts those plus core OS files.
Some Potential Downsides
As you might easily guess, there are drawbacks to not encrypting everything the way full-disk encryption does. In theory, an attacker with physical access to your device employing file-based encryption could alter the unencrypted OS data. From there, the attacker either boots your machine to run the code they just put there, or they wait until you boot your machine so that their malicious code does something to snag your data.
That sounds bad, and it is, but it also probably won't happen to you. Really, most or none of your adversaries will even attempt it. They are either so primitive that filesystem-level encryption is enough to thwart them, or so sophisticated (i.e. powerful) that they have more efficient methods for obtaining your data.
For the overwhelming majority of users, the problem that data-at-rest encryption solves is keeping thieves who physically steal your device from getting your data. That's why smart thieves don't count on getting your data, and instead resort to fencing the device for money. File-based encryption and full-disk encryption both work equally well in this scenario.
Conversely, if your adversary is a government authority (e.g. law enforcement), neither file-based encryption nor full-disk encryption will save you. Depending on the jurisdiction, they can legally order you to unlock your device. Almost everywhere else, governments can issue orders to services that store your data in their cloud to just hand over what they want -- and under repressive regimes, let's just say they have more direct and painful ways of getting you to comply.
Let's say, for the sake of argument, you are staring down a government actor, and all the aforementioned techniques haven't worked. Full-disk encryption would only work if the government did not have a more sophisticated way of attacking your system. This is not an issue for most of the world's powerful governments, as they are advanced enough that they can brute force or sidestep the encryption in some way.
So, there aren't that many cases where full-disk encryption will really save you: when your enemy is a government and you can withstand physical torture, but the government isn't capable of the really cool action movie hacking that basically every G20 nation can do.
That's not to say that, depending on your adversary, there is nothing to be gained from making things difficult for your attacker -- making your attacker's life as hard as possible is a time-honored security strategy -- but just realize that that's all full-disk encryption can guarantee you. But, again, that's not what almost any of you are looking at.
Practical Encryption, Impractical Implementation
Those of you who are convinced and want your read-write performance and SSD longevity back are probably wondering where you can get your hands on this sweet file-level crypto. Well, that's where things get complicated. You see, it's hard to set it up in practice.
The main reason for this is that major consumer OSes are already full-disk encrypted. Apple and Google have configured their mobile devices for full-disk encryption, and deny users the ability to disable it. Apple and Microsoft also enable full-disk encryption by default, but both offer ways of disabling it for the intrepid.
For Linux-based desktop OSes (my personal preference), installing your system with filesystem-level encryption used to be as easy as checking a box, but this is quickly going the way of the dodo. Ubuntu recently deprecated this installation option in their graphical installer, leaving Linux Mint as the only distribution I know of which still offers it. Even DIY distros like Arch Linux discourage you from trying to configure file-level crypto. Instead, they steer you toward block encryption, for which documentation is much more thorough.
If you are willing to go to the required lengths to turn off your full-disk encryption, there are some options available to you. One of the more robust options is VeraCrypt. Born of the desire to don the defunct TrueCrypt's mantle, VeraCrypt is a graphical tool for creating encrypted directory structures on top of an existing filesystem. It boasts options for read-write speeds on par with unencrypted filesystems, and even super-spy features like deniable encryption, where your encrypted data will just look like normal unused space on your drive. An exploration of even basic VeraCrypt capabilities would be beyond the scope of this already lengthy piece, but perhaps it has the makings of a future article.
So why did I take all this time to tell you about something that is not the most (though certainly not the least) accessible? Fundamentally, it's important to know what's possible so you can make the most informed choices, to create the computing experience that is most responsive to your needs. Computers are infinitely customizable, so there is no reason a user should be denied the setup that is best for them -- not knowing your options is the worst such reason.
Appreciating what's possible is about more than living your best digital life, but about providing the support, even if it's just usership, to the developers making it possible. If this sounds like something that could make your life better, I say to you, go forth and tinker!
作者：Jonathan Terrasi
https://www.technewsworld.com/story/data-management/86774.html
