我的公司将为我们的客户存储敏感数据，并将使用托管的 .NET 加密算法类之一对数据进行加密。大部分工作已经完成，但我们还没有弄清楚如何/在哪里存储密钥。我做了一些简单的搜索和阅读，看起来硬件解决方案可能是最安全的。有人对密钥存储解决方案或方法有任何建议吗？
谢谢大家的回复。
spoulson，问题实际上是您提到的两个“范围”。我想我应该更清楚。
数据本身以及对其进行加密和解密的逻辑都被抽象到 ASP.NET 配置文件提供程序中。此配置文件提供程序允许加密的配置文件属性以及纯文本属性。加密属性值的存储方式与纯文本值完全相同 - 明显的例外是它们已被加密。
也就是说，出于以下三个原因之一，需要能够召唤钥匙：
我想象的方式是没有人真正知道密钥 - 会有一个软件控制数据的实际加密和解密。也就是说，密钥仍然需要来自某个地方。
完全披露——如果你还不能说，我以前从来没有做过这样的事情，所以如果我完全不知道这应该如何工作，请告诉我。
这个问题（技术方面）只有两个真正的解决方案。假设只有应用程序本身需要访问密钥......
硬件安全模块 (HSM) - 通常非常昂贵，而且实施起来并不简单。可以是专用设备（例如 nCipher）或特定令牌（例如 Alladin eToken）。然后你仍然必须定义如何处理该硬件......
DPAPI（Windows 数据保护 API）。System.Security.Cryptography（ProtectedMemory、ProtectedStorage 等）中有这方面的类。这会将密钥管理交给操作系统 - 它处理得很好。在“USER_MODE”中使用，DPAPI 会将密钥的解密锁定给加密它的单个用户。（不用太详细，用户的密码是加密/解密方案的一部分 - 不，更改密码不会弄乱它。）
添加：最好使用 DPAPI 来保护您的主密钥，而不是直接加密您的应用程序的数据。并且不要忘记在您的加密密钥上设置强 ACL...
回应OP这个答案的#3
授权成员能够查看加密数据但他们实际上不知道密钥的一种方法是使用密钥托管（rsa labs） （维基百科）
总之，密钥被分解成单独的部分并提供给“受托人”。由于私钥的性质，每个段本身都是无用的。然而，如果需要解密数据，那么“受托人”可以将他们的片段组装成整个密钥。
我们有同样的问题，也经历了同样的过程。
我们需要在一台计算机（客户端）上启动一个进程，然后登录到另一台计算机（数据库服务器）。
我们目前认为最佳做法是：
实际上，操作员的登录密码是关键，但它不会存储在任何地方。
Microsoft Rights Management Server (RMS)也有类似的问题。它只是通过使用主密码加密其配置来解决它。...密码上的密码，如果你愿意的话。
您最好的选择是物理保护密钥所在的硬件。此外，永远不要将它写入磁盘 - 找到一些方法来防止该部分内存被分页到磁盘。加密/解密时需要将密钥加载到内存中，并且对于不安全的硬件，总是存在这种攻击场所。
就像您说的那样，有硬件加密设备，但它们无法扩展-所有加密/解密都通过芯片。
您可以使用另一个对称密钥加密对称密钥，该对称密钥使用类似PBKDF2的密码派生而来。
让用户提供密码，生成用于加密数据的新密钥，使用密码生成另一个密钥，然后加密并存储数据加密密钥。
它不如使用硬件令牌安全，但它可能仍然足够好并且非常易于使用。
我想我误解了你的问题。您所要求的不是应用程序如何处理其密钥存储的范围，而是您的公司将如何存储它。
在这种情况下，您有两个明显的选择：
物理：写入 USB 驱动器、刻录到 CD 等。存储在物理上安全的位置。但是您遇到了递归问题：您将密钥存储在哪里？通常，您委派 2 人或更多人（或团队）持有钥匙。
软件：Cyber-Ark Private Ark 是我公司用来存储其秘密数字信息的工具。我们存储我们所有的管理员密码、许可证密钥、私钥等。它通过运行未加入域的 Windows“保险库”服务器来工作，防火墙除了它自己的端口之外的所有端口，并将其所有数据加密存储在磁盘上。用户通过 Web 界面进行访问，该界面首先对用户进行身份验证，然后通过类似资源管理器的界面与保管库服务器进行安全通信。记录所有更改和版本。但是，这也有同样的递归问题……主管理员访问 CD。这存储在我们的物理保险库中，访问受限。
在将生成的密钥写出之前，使用硬编码密钥对其进行加密。然后你可以在任何地方写它。
是的，您可以找到硬编码的密钥，但只要您假设可以在任何地方存储对称密钥，它的安全性也不会降低。
根据您的应用程序，您可以使用Diffie-Hellman方法让两方安全地就对称密钥达成一致。
在初始的安全交换之后，密钥被商定，会话的其余部分（或新会话）可以使用这个新的对称密钥。