Microsoft 是否有推荐的方法来处理 HttpClient 中 headers 中的机密？
Does Microsoft have a recommended way to handle secrets in headers in HttpClient?
非常密切相关：How to protect strings without SecureString?
也密切相关：When would I need a SecureString in .NET?
极其密切相关（OP 试图实现非常相似的东西）：
.NET Framework class 称为 SecureString。然而，即使是微软也不再推荐将其用于新的开发。根据第一个链接的问答，至少有一个原因是该字符串无论如何都会以明文形式在内存中至少 some 时间量（即使是非常短的时间）时间）。至少有一个答案还扩展了这样的论点，即如果他们无论如何都可以访问服务器的内存，那么实际上安全性可能无论如何都会被击中，所以它不会帮助你。 （第二个链接的问答暗示甚至讨论过完全从 .NET Core 中删除它）。
话虽这么说，Microsoft 关于 SecureString 的文档并不建议更换，并且对链接的问答的共识似乎是那种措施不会全部 that 反正有用。
我的应用程序是一个 ASP.NET 核心应用程序，它广泛使用 API 使用 HttpClient class 调用外部供应商。 HttpClient 的 generally-recommended best practice 是使用单个实例，而不是为每个调用创建一个新实例。
但是，我们的供应商要求所有 API 调用都包含我们的 API 密钥作为具有特定名称的 header。我目前安全地存储密钥，在 Startup.cs 中检索它，并将它添加到我们的 HttpClient 实例的 headers.
不幸的是，这意味着我的 API 密钥将在应用程序的整个生命周期内以明文形式保存在内存中。我发现这对于服务器上的 Web 应用程序尤其麻烦；即使服务器由公司 IT 部门维护，我也一直被教导要将公司网络视为 semi-hostile 环境，在这种情况下不要纯粹依赖公司防火墙来确保应用程序安全。
对于这种情况，Microsoft 是否有推荐的最佳做法？这是他们反对使用 SecureString 的建议的潜在例外吗？ （具体如何运作是一个单独的问题）。或者其他问答中的答案是否真的正确，我不应该担心像这样存在于内存中的明文字符串？
注意： 根据对这个问题的回答，我可能 post 一个 follow-up 关于是否可以使用类似 [=11] 的问题=] 作为 HttpClient header 的一部分。或者我是否必须做一些棘手的事情，比如在使用它之前填充 header 然后立即将它从内存中删除？ （虽然这会给并发调用带来绝对的噩梦）。如果人们认为我应该做这样的事情，我很乐意为此创建一个新问题。
你太偏执了。
首先，如果黑客获得了对您的网络服务器的根访问权限，那么您遇到的问题比您的绝密网络应用凭据被盗要大得多。方式，方式，更大的问题。一旦黑客来到密闭舱口的你这边，游戏就结束了。
其次，一旦您的信息安全团队检测到入侵（如果他们没有检测到，您又遇到了更大的问题），他们会告诉您，您要做的第一件事就是更改您知道的每个密钥和密码。
第三，如果黑客确实获得了对您的网络服务器的根访问权限，他们首先想到的不会是 "let's take a memory dump for later analysis"。转储文件相当大（通过网络传输需要时间，网络流量可能会很明显）并且（至少在 Windows 上）挂起进程直到它完成（所以你会注意到你的网络应用程序反应迟钝）——两者都可能引发一些危险信号。
不，黑客会在最短的时间内获取尽可能多的有价值信息，因为他们知道他们的访问随时可能被发现。因此，他们将首先获得容易获得的成果 - 用户名和密码。然后他们将继续尝试找出连接到该服务器的内容，并且由于您的数据库凭据可能位于该服务器上的配置文件中，因此他们几乎肯定会将注意力转移到那个更有趣的目标上。
所以考虑到所有因素，您的 API 密钥不太可能被泄露 - 即使是，也不会是因为您做了或没有做的事情。有比尝试保护已经（或应该）非常安全的东西更有效的方式来集中你的时间。而且，归根结底，无论您设置了多少层安全保护……API 或 SSL 密钥在某个阶段都将是原始的，在内存中。
非常密切相关：How to protect strings without SecureString?
也密切相关：When would I need a SecureString in .NET?
极其密切相关（OP 试图实现非常相似的东西）：
.NET Framework class 称为 SecureString。然而，即使是微软也不再推荐将其用于新的开发。根据第一个链接的问答，至少有一个原因是该字符串无论如何都会以明文形式在内存中至少 some 时间量（即使是非常短的时间）时间）。至少有一个答案还扩展了这样的论点，即如果他们无论如何都可以访问服务器的内存，那么实际上安全性可能无论如何都会被击中，所以它不会帮助你。 （第二个链接的问答暗示甚至讨论过完全从 .NET Core 中删除它）。
话虽这么说，Microsoft 关于 SecureString 的文档并不建议更换，并且对链接的问答的共识似乎是那种措施不会全部 that 反正有用。
我的应用程序是一个 ASP.NET 核心应用程序，它广泛使用 API 使用 HttpClient class 调用外部供应商。 HttpClient 的 generally-recommended best practice 是使用单个实例，而不是为每个调用创建一个新实例。
但是，我们的供应商要求所有 API 调用都包含我们的 API 密钥作为具有特定名称的 header。我目前安全地存储密钥，在 Startup.cs 中检索它，并将它添加到我们的 HttpClient 实例的 headers.
不幸的是，这意味着我的 API 密钥将在应用程序的整个生命周期内以明文形式保存在内存中。我发现这对于服务器上的 Web 应用程序尤其麻烦；即使服务器由公司 IT 部门维护，我也一直被教导要将公司网络视为 semi-hostile 环境，在这种情况下不要纯粹依赖公司防火墙来确保应用程序安全。
对于这种情况，Microsoft 是否有推荐的最佳做法？这是他们反对使用 SecureString 的建议的潜在例外吗？ （具体如何运作是一个单独的问题）。或者其他问答中的答案是否真的正确，我不应该担心像这样存在于内存中的明文字符串？
注意： 根据对这个问题的回答，我可能 post 一个 follow-up 关于是否可以使用类似 [=11] 的问题=] 作为 HttpClient header 的一部分。或者我是否必须做一些棘手的事情，比如在使用它之前填充 header 然后立即将它从内存中删除？ （虽然这会给并发调用带来绝对的噩梦）。如果人们认为我应该做这样的事情，我很乐意为此创建一个新问题。
你太偏执了。
首先，如果黑客获得了对您的网络服务器的根访问权限，那么您遇到的问题比您的绝密网络应用凭据被盗要大得多。方式，方式，更大的问题。一旦黑客来到密闭舱口的你这边，游戏就结束了。
其次，一旦您的信息安全团队检测到入侵（如果他们没有检测到，您又遇到了更大的问题），他们会告诉您，您要做的第一件事就是更改您知道的每个密钥和密码。
第三，如果黑客确实获得了对您的网络服务器的根访问权限，他们首先想到的不会是 "let's take a memory dump for later analysis"。转储文件相当大（通过网络传输需要时间，网络流量可能会很明显）并且（至少在 Windows 上）挂起进程直到它完成（所以你会注意到你的网络应用程序反应迟钝）——两者都可能引发一些危险信号。
不，黑客会在最短的时间内获取尽可能多的有价值信息，因为他们知道他们的访问随时可能被发现。因此，他们将首先获得容易获得的成果 - 用户名和密码。然后他们将继续尝试找出连接到该服务器的内容，并且由于您的数据库凭据可能位于该服务器上的配置文件中，因此他们几乎肯定会将注意力转移到那个更有趣的目标上。
所以考虑到所有因素，您的 API 密钥不太可能被泄露 - 即使是，也不会是因为您做了或没有做的事情。有比尝试保护已经（或应该）非常安全的东西更有效的方式来集中你的时间。而且，归根结底，无论您设置了多少层安全保护……API 或 SSL 密钥在某个阶段都将是原始的，在内存中。