blocks|key|4106587|text|AWS提供了几种不同的服务来存储您的秘密。假设您在应用程序配置文件中有一个数据库密码，您可以使用AWS+secret+manager或AWS+Parameter+store将其存储为Secret。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|4106588|要安全地检索这些值，您不必存储应用程序中存储的另一个秘密。您可以在AWS中使用一种称为基于角色的访问的机制。|4106589|如果您在ec2实例上运行您的应用程序，您可以配置一个AWS角色/配置文件，并将其分配给ec2实例，该实例将安全地链接密钥管理器和ec2机器，并且您的应用程序具有解密密钥并在应用程序中使用的连接。|4106590|entityMap^0|0|0|0^^$0|@$1|2|3|4|5|6|7|H|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|I|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|J|8|@]|9|@]|A|$]]|$1|F|3|-4|5|6|7|K|8|@]|9|@]|A|$]]]|G|$]]

AWS offers few different services to store your secrets. Let's say if you have a database password in an application configuration file, you can use either AWS Secret manager or AWS Parameter store to store them as secret.
To retrieve these values securely, you do not have to store another secret stored in your application. You can use a mechanism called role-based access in AWS.
If you running your application on an ec2 instance, you can configure an AWS role/profile and assign it to the ec2 instance which is linking the secret manager and the ec2 machine securely and your application has connectivity to decrypt the secret and use it inside the application.

blocks|key|1310852|text|如果你正在使用Azure，答案是使用Managed+Identities。|type|unstyled|depth|inlineStyleRanges|offset|length|style|CODE|entityRanges|data|1310853|它的工作方式是为资源(虚拟机、WebApps等)分配身份需要访问密钥库的用户。这样，资源就像你的Azure+AD中的用户(非常像服务主体或任何其他用户)。然后，您可以使用Key+Vault访问策略将对Key+Vault中的密钥和机密的适当访问权限分配给这些托管身份。执行此操作不需要您指定客户端Id/客户端密码即可访问密钥库。|1310854|虽然托管标识是您分配给资源的东西，但如果您有许多资源，它可能会变得很麻烦。这就是User+Assigned+Managed+Identity的用武之地。User+Assigned+Managed+Identity是你的Azure订阅中的资源。该过程非常相似:您创建这样的身份，然后在您的Key+Vault资源上分配对此身份的适当访问权限。|1310855|现在，只要您需要在应用程序中访问Key+Vault，就需要指定此身份的id。使用适当SDK的应用程序将获得代表此身份的访问令牌，并使用该访问令牌连接到密钥库。|1310856|你可以在这里了解更多关于这些身份的信息：https://docs.microsoft.com/en-us/azure/active-directory/managed-identities-azure-resources/overview。|1310857|entityMap|0|LINK|mutability|MUTABLE|url|https://docs.microsoft.com/en-us/azure/active-directory/managed-identities-azure-resources/overview^0|I|I|0|0|14|U|24|U|0|0|K|2R|0|0^^$0|@$1|2|3|4|5|6|7|V|8|@$9|W|A|X|B|C]]|D|@]|E|$]]|$1|F|3|G|5|6|7|Y|8|@]|D|@]|E|$]]|$1|H|3|I|5|6|7|Z|8|@$9|10|A|11|B|C]|$9|12|A|13|B|C]]|D|@]|E|$]]|$1|J|3|K|5|6|7|14|8|@]|D|@]|E|$]]|$1|L|3|M|5|6|7|15|8|@]|D|@$9|16|A|17|1|18]]|E|$]]|$1|N|3|-4|5|6|7|19|8|@]|D|@]|E|$]]]|O|$P|$5|Q|R|S|E|$T|U]]]]

If you are using Azure, the answer is to use <code>Managed Identities</code>.
The way it works is that you assign an identity to the resources (VMs, WebApps etc.) that need access to Key Vault. That way the resource becomes like a user in your Azure AD (much like a Service Principal or any other user). Then you can make use of Key Vault Access Policies to assign appropriate access to keys and secrets in your Key Vault to these Managed Identities. Doing this would not require you to specify a Client Id/Client Secret to access the Key Vault.
While the Managed Identity is something you assign to a resource, it could become cumbersome if you have many resources. That's where <code>User Assigned Managed Identity</code> comes into picture. A <code>User Assigned Managed Identity</code> is a resource in your Azure Subscription. The process is very much similar: you create such identity and then assign appropriate access to this identity on your Key Vault resources.
Now wherever you need to access Key Vault in your applications, you will specify the id of this identity. The application using appropriate SDK will get an access token on behalf of this identity and connect to Key Vault using that access token.
You can learn more about these identities here: <a href="https://docs.microsoft.com/en-us/azure/active-directory/managed-identities-azure-resources/overview" rel="nofollow noreferrer">https://docs.microsoft.com/en-us/azure/active-directory/managed-identities-azure-resources/overview</a>.

blocks|key|1310865|text|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1310866|，但要访问它们，您需要一个clientId和clientSecret。这些需要存储在应用程序中的某个位置。例如app.config|blockquote|1310867|1310868|1310869|您可以使用运行时权限来访问密钥和参数。在Azure中它被称为托管身份，在AWS中有服务角色。我更熟悉AWS，所以我将使用它的术语，但每个较大的云提供商都有类似的方法，但名称不同。|1310870|基本上，您可以分配运行代码的计算资源(EC2/VM服务器、Lambda函数、ECS容器等)角色-您可以将其视为一组权限。使用AWS+API，您可以访问代码中的秘密或参数，而无需存储任何客户端凭据。|1310871|1310872|如果他们能够访问密钥管理器，他们将拥有所有的密钥和所有的密码。|1310873|1310874|1310875|这就是为什么我们都需要使用最少特权的原则，定义的运行时身份应该只有它真正需要的权限。|1310876|entityMap^0|0|0|0|0|0|0|0|0|0|0|0^^$0|@$1|2|3|-4|4|5|6|S|7|@]|8|@]|9|$]]|$1|A|3|B|4|C|6|T|7|@]|8|@]|9|$]]|$1|D|3|-4|4|5|6|U|7|@]|8|@]|9|$]]|$1|E|3|-4|4|5|6|V|7|@]|8|@]|9|$]]|$1|F|3|G|4|5|6|W|7|@]|8|@]|9|$]]|$1|H|3|I|4|5|6|X|7|@]|8|@]|9|$]]|$1|J|3|-4|4|5|6|Y|7|@]|8|@]|9|$]]|$1|K|3|L|4|C|6|Z|7|@]|8|@]|9|$]]|$1|M|3|-4|4|5|6|10|7|@]|8|@]|9|$]]|$1|N|3|-4|4|5|6|11|7|@]|8|@]|9|$]]|$1|O|3|P|4|5|6|12|7|@]|8|@]|9|$]]|$1|Q|3|-4|4|5|6|13|7|@]|8|@]|9|$]]]|R|$]]

<blockquote>
But to access these you need a clientId and clientSecret. These need to be stored somewhere on the app. eg app.config
</blockquote>
You can use runtime permissions to access the secrets and parameters. In Azure it is called Managed Identities, in AWS there are service roles. I am more familiar with AWS, so I will use its terminology, but every larger cloud provider has similar approach with different names.
Basically you can assign the compute resource where your code runs (EC2/VM server, Lambda function, ECS container,...) a role - you can consider it as set of permissions. Using AWS API you can access the secrets or parameters from the code without storing any client credentials.
<blockquote>
if they get access to the secrets manager they will have ALL THE KEYS and ALL the passwords.
</blockquote>
That's why we all need to use principle of the least privileges, the defined runtime identity should have only permissions it really needs.

People say not to store API Keys and passwords config files and instead to use a Secrets vault. eg. AWS or Azure.
But to access these you need a clientId and clientSecret. These need to be stored somewhere on the app. eg app.config. So I really don't understand what problem this solves if the hacker can use the clientId and clientSecret in the app the get the passwords or api keys anyway?
it seems even worse than the original problem storing one api key, since if they get access to the secrets manager they will have ALL THE KEYS and ALL the passwords.

secrets vaults: how to encrypt clientId and clientSecret in a web app?

翻译质量差，导致语言生硬或混乱。

没有提供实际的解决方法或示例。

解答不清晰，无法理解或解决问题。

页面排版不美观，阅读体验差。

文章

问答

视频

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

人们建议不要存储API密钥和密码配置文件，而是使用Secrets vault。例如：AWS或Azure。但要访问它们，您需要一个clientId和clientSecret。这些需要存储在应用程序中的某个位置。例如app.config。所以我真的不明白，如果黑客可以使用应用程序中的clientId和clientSecre...

问secrets :如何在web应用程序中加密clientId和clientSecret？
EN

Stack Overflow用户

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问secrets :如何在web应用程序中加密clientId和clientSecret？EN