背景：我在数据库中使用 AES（即对称加密）加密了一些数据。在（假定的）安全且隔离的 Linux 机器上运行的服务器端应用程序使用此数据。它从数据库中读取加密数据，并写回加密数据，只处理内存中未加密的数据。因此，为了做到这一点，应用程序需要将密钥存储在内存中。
问题是，有没有什么好的最佳实践呢？保护内存中的密钥。
一些想法：
SHM_LOCK使用shmctl(2)? 设置）关于为什么密钥可能泄漏的一些场景：邪恶的人掌握了内存转储/核心转储；错误的代码边界检查导致信息泄露；
第一个似乎是一件好事且非常简单的事情，但是其余的呢？其他想法？任何标准规范/最佳实践？
感谢您的任何意见！
一切都取决于您的偏执程度和密钥/数据的敏感性。在极端情况下，只要您在内存中有未加密的密钥，就可以使用冷启动技术检索它。freezecache有一个有趣的发展来试图克服这一点。我只是随便读了一遍，没有在实践中尝试过，但这似乎是一种有趣的尝试方法。
摘掉锡箔帽后，-(1)、(2)、(3) 似乎是合理的。（4）不会因为你提到的原因而精确切割它。（不仅它很慢，而且假设您读入堆栈，具有不同的堆栈深度，键可能会多次可见）。
假设解密的数据是值得的，并且它会在可交换的内存中，你肯定也应该加密交换本身。此外，根、/tmp 分区也应该加密。这是一个相当标准的设置，在大多数操作系统指南中都很容易找到。
然后，当然，您希望确保机器本身的高水平物理安全性并最小化它执行的功能 - 运行的代码越少，暴露的越少。您可能还想看看如何绝对最小化远程访问这台机器的可能性 - 即使用基于 RSA 密钥的 ssh，它会被另一个主机控制的另一个 ACL 阻止。在能够登录到第二台主机之前，端口敲击可以用作额外的身份验证向量之一。以确保如果主机是妥协，更难将数据取出，确保该主机没有直接可路由的连接到互联网。一般来说，获取敏感数据的过程越痛苦，有人去那里的机会就越小，但这也会让普通用户的生活变得痛苦 - 所以需要有一个平衡。
如果应用程序很严重并且风险很大，最好构建更明确的整体威胁模型，看看您可以预见哪些可能的攻击向量，并验证您的设置是否有效地处理它们。（并且不要忘记包括人为因素:-)
更新：确实，您可以使用专用硬件来处理加密/解密。然后您不必处理密钥的存储 - 请参阅 Hamish 的答案。
如果您对安全性很认真，那么您可能会考虑使用单独的加密子系统。最好是经过FIPS 140-2/3认证的（认证模块列表）。
然后密钥保存在防篡改内存中（不可提取），所有加密操作都在加密边界内执行。
昂贵，但对于一些必要的应用程序。
也不要忘记核心转储和内存被换出的威胁！
在 POSIX（如 Linux）和 Windows 系统上，如果您使用 C 语言，有一些技术可以防止这种情况发生 - 请参阅 CERT 安全编码标准中的本节：
最大的问题是程序必须从某个地方读取密钥。除非您在每次服务器重新启动时都接受直接键盘输入，否则它几乎必须存在于磁盘上的某个地方。
通常，您必须假设作恶者无法访问根级别的操作系统或硬件，因为在这种情况下，即使密钥仅在 RAM 中，他们最终也会设法获得密钥。
所以你假设服务器的操作系统是安全的。但是假设有人可以来偷硬盘驱动器，所以启动服务器会给他们钥匙。然后让服务器向另一台服务器请求一半的密钥，远程服务器验证请求（使用 ip、私钥/公钥对）并提供一半的密钥。那么你的服务器就有一个完整的密钥，而远程服务器永远不会超过一半。在我看来，这似乎是一种改进的保护水平。
使用“超级超级用户”硬件内存是理想的。所有英特尔 Mac 都有这个 SecureEnclave 内存区域，它还包括硬件中的 AES 解密，因此应用程序和操作系统永远无法访问原始私钥。当机器启动时，输入密码（可选），SecureEnclave 将其冷闪存加密版本的密钥解密到主操作系统无法访问的 RAM 区域。
不错的副作用是硬件加速加密：我在一个新格式化的加密磁盘上对我的 PCIe 存储以 600 MB/秒的速度进行了基准测试。
在云中，亚马逊拥有这项 AWS Key Management Service (KMS) 托管服务，让您可以轻松创建和控制用于加密数据的加密密钥，并使用 FIPS 140-2 验证的硬件安全模块来保护你的钥匙：https ://aws.amazon.com/kms/