azure 配置vpn_ASP.NET和Azure中配置中的私有配置数据和连接字符串的最佳做法

azure 配置vpn

A reader emailed asking how to avoid accidentally checking in passwords and other sensitive data into GitHub or source control in general. I think it's fair to say that we've all done this once or twice - it's a rite of passage for developers old and new.

一位读者发了电子邮件，询问如何避免将密码和其他敏感数据意外地登录到GitHub或源代码控制中。 我认为可以公平地说，我们都做了一两次，这对新老开发人员来说都是一种通过。

The simplest way to avoid checking in passwords and/or connection strings into source control is to (no joke) keep passwords and connection strings out of your source.

避免将密码和/或连接字符串签入源代码管理的最简单方法是(不要开玩笑)将密码和/或连接字符串保留在源代码之外。

Sounds condescending or funny, but it's not, it's true. You can't check in what doesn't exist on disk.

听起来居高临下或有趣，但事实并非如此。 您无法检查磁盘上不存在的内容。

That said, sometimes you just need to mark a file as "ignored," meaning it's not under source control. For some systems that involves externalizing configuration values that may be in shared config files with a bunch of non-sensitive config data.

就是说，有时您只需要将文件标记为“已忽略”即可，这意味着该文件不受源代码控制。 对于某些涉及外部化配置值的系统，这些配置值可能与一堆非敏感配置数据一起出现在共享配置文件中。

ASP.NET 4.6机密和连接字符串 (ASP.NET 4.6 secrets and connection strings)

Just to be clear, how "secret" something is is up to you. If it's truly cryptographically secret or something like a private key, you should be looking at data protection systems or a Key Vault like Azure Key Vault. Here we are talking about medium business impact web apps with API keys for 3rd party web APIs and connection strings that can live in memory for short periods. Be smart.

需要明确的是，什么是“秘密”的事情取决于您。 如果它是真正的加密机密或诸如私钥之类的东西，则应查看数据保护系统或诸如Azure Key Vault之类的Key Vault 。 在这里，我们谈论的是具有中等业务影响力的Web应用程序，这些应用程序具有用于第三方Web API的API密钥和可以在内存中短期存在的连接字符串。 放聪明点。

ASP.NET 4.6 has web.config XML files like this with name/value pairs.

ASP.NET 4.6具有这样的带有名称/值对的web.config XML文件。

<appSettings>      
    <add key="name" value="someValue" />
    <add key="name" value="someSECRETValue" />
</appSettings>      

We don't want secrets in there! Instead, move them out like this:

我们不要在那里的秘密！ 而是将它们移出，如下所示：

<appSettings file="Web.SECRETS.config">      
    <add key="name" value="someValue" />
</appSettings>

Then you just put another appSettings section in that web.secrets.config file and it gets merged at runtime.

然后，您只需在该web.secrets.config文件中放置另一个appSettings部分，即可在运行时将其合并。

NOTE: It's worth pointing out that the AppSettings technique also works for Console apps with an app.config.

注意：值得指出的是，AppSettings技术也适用于带有app.config的控制台应用程序。

Finally, be sure to add Web.secrets.config (or, even better, make it *.secrets and use a unique extension to identify your sensitive config.

最后，请确保添加Web.secrets.config(或者甚至更好，使其成为* .secrets并使用唯一的扩展名来标识您的敏感配置。

This externalizing of config also works with the <connectionStrings> section, except you use the configSource attribute like this:

config的这种外部化也可以与<connectionStrings>部分一起使用，除非您使用configSource属性，如下所示：

<connectionStrings configSource="secretConnectionStrings.config">
</connectionStrings>

Azure中的连接字符串/应用程序机密 (Connection Strings/App Secrets in Azure)

When you're deploying a web app to Azure (as often these apps are deployed from source/GitHub, etc) you should NEVER put your connection strings or appSettings in web.config or hard code them.

将Web应用程序部署到Azure时(这些应用程序通常是从源代码/ GitHub部署的，等等)，您永远不要将连接字符串或appSettings放在web.config中或对其进行硬编码。

Instead, always use the Application Settings configuration section of Web Apps in Azure.

相反，请始终使用Azure中Web Apps的“应用程序设置”配置部分。

These collection strings and name value pairs will automatically be made available transparently to your website so you don't need to change any ASP.NET code. Considered them to have more narrow scope than what's in web.config, and the system will merge the set automatically.

这些收集字符串和名称值对将自动透明地提供给您的网站，因此您无需更改任何ASP.NET代码。 认为它们的范围比web.config中的范围更窄，并且系统将自动合并该集合。

Additionally they are made available as Environment Variables, so you can Environment.GetEnvironmentVariable("APPSETTING_yourkey") as well. This works in any web framework, not just ASP.NET, so in PHP you just getenv('APPSETTING_yourkey") as you like.

此外，它们还可以作为环境变量使用，因此您也可以使用Environment.GetEnvironmentVariable(“ APPSETTING_yourkey”)。 这可以在任何Web框架中运行，而不仅限于ASP.NET，因此在PHP中，您可以随意获取getenv('APPSETTING_yourkey“)。

The full list of database connection string types and the prepended string used for environment variables is below:

下面是数据库连接字符串类型的完整列表以及用于环境变量的前置字符串：

• If you select “Sql Databases”, the prepended string is “SQLAZURECONNSTR_”
  如果选择“ Sql数据库”，则前置字符串为“ SQLAZURECONNSTR_”
• If you select “SQL Server” the prepended string is “SQLCONNSTR_”
  如果选择“ SQL Server”，则前置字符串为“ SQLCONNSTR_”
• If you select “MySQL” the prepended string is “MYSQLCONNSTR_”
  如果选择“ MySQL”，则前置字符串为“ MYSQLCONNSTR_”
• If you select “Custom” the prepended string is “CUSTOMCONNSTR_”
  如果选择“自定义”，则前置字符串为“ CUSTOMCONNSTR_”

ASP.NET 5 (ASP.NET 5)

ASP.NET 5 has the concept of User Secrets or User-Level Secrets where the key/value pair does exist in a file BUT that file isn't in your project folder, it's stored in your OS user profile folder. That way there's no chance it'll get checked into source control. There's a secret manager (it's all beta so expect it to change) where you can set name/value pairs.

ASP.NET 5具有用户密钥或用户级​​别密钥的概念，其中键/值对确实存在于文件中，但该文件不在您的项目文件夹中，而是存储在OS用户配置文件文件夹中。 这样，就没有机会将其检入源代码管理。 有一个秘密管理器(都是beta版，因此期望它会更改)，您可以在其中设置名称/值对。

ASP.NET also has very flexible scoping rules in code. You can have an appSettings, then an environment-specific (dev, test, staging, prod) appSettings, then User Secrets, and then environment variables. All of this is done via code configuration and is, as I mentioned, deeply flexible. If you don't like it, you can change it.

ASP.NET在代码中也具有非常灵活的作用域规则。 您可以拥有一个appSettings，然后一个特定于环境的(开发，测试，登台，生产)appSettings，然后是User Secrets，然后是环境变量。 所有这些都是通过代码配置完成的，并且正如我提到的那样，它非常灵活。 如果您不喜欢它，可以更改它。

var builder = new ConfigurationBuilder()
    .AddJsonFile("appsettings.json")
    .AddJsonFile($"appsettings.{env.EnvironmentName}.json", optional: true);

if (env.IsDevelopment())
{
    // For more details on using the user secret store see http://go.microsoft.com/fwlink/?LinkID=532709
    builder.AddUserSecrets();
}

builder.AddEnvironmentVariables();
Configuration = builder.Build();

So, in conclusion:

因此，结论是：

• Don't put private stuff in code.
  不要在代码中放入私人内容。

• • Seems obvious, but...

    似乎很明显，但是...

• Avoid putting private stuff in common config files

  避免将私有内容放入通用配置文件中

  • Externalize them AND ignore the externalized file so they don't get checked in
    将其外部化，并忽略外部化的文件，因此不会被检入

  Avoid putting private stuff in common config files

  避免将私有内容放入通用配置文件中

• Consider using Environment Variables or User-level config options.

  考虑使用环境变量或用户级别的配置选项。

  • Keep sensitive config out of your project folder at development time
    在开发时将敏感的配置保留在项目文件夹之外

I'm sure I missed something. What are YOUR tips, Dear Reader?

我确定我错过了一些东西。 亲爱的读者，您的秘诀是什么？

资源资源 (Resources)

• Best practices for deploying passwords and other sensitive data to ASP.NET and Azure App Service

  将密码和其他敏感数据部署到ASP.NET和Azure App Service的最佳实践

Image Copyright Shea Parikh - used under license from http://getcolorstock.com

图片版权Shea Parikh-根据http://getcolorstock.com的许可使用

Sponsor: Big thanks to Infragistics for sponsoring the blog this week! Responsive web design on any browser, any platform and any device with Infragistics jQuery/HTML5 Controls.  Get super-charged performance with the world’s fastest HTML5 Grid - Download for free now!

赞助商：非常感谢Infragistics本周赞助了该博客！ 带有Infragistics jQuery / HTML5控件的任何浏览器，任何平台和任何设备上的响应式Web设计。 使用世界上最快HTML5网格获得超强的性能-立即免费下载！

翻译自: https://www.hanselman.com/blog/best-practices-for-private-config-data-and-connection-strings-in-configuration-in-aspnet-and-azure

azure 配置vpn