.NET Core 6: для защиты потенциально конфиденциальной информации в строке подключения

Вам нужно сделать небольшой шаг назад и рассмотреть инструменты, которые ASP.NET Core/.NET предоставляет для работы с конфигурацией.

Из DbContext Lifetime, Configuration and Initialization doc вы можете увидеть, что одним из распространенных шаблонов является использование внедрения зависимостей и настройка строки подключения при запуске приложения. Для этого потребуется добавить конструктор в контекст (и изменить/удалить OnConfiguring перегрузку — документы):

public class ApplicationDbContext : DbContext
{
    public ApplicationDbContext(DbContextOptions<ApplicationDbContext> options)
        : base(options)
    {
    }
}

И:

builder.Services.AddDbContext<ApplicationDbContext>(
        options => options.UseSqlServer("ConnectionStringHere")); // or AddDbContextFactory

Следующий шаг — прочитать строку подключения из настроек:

builder.Services.AddDbContext<ApplicationDbContext>(
        options => options.UseSqlServer(builder.Configuration.GetConnectionString("ConnStringName"))); // or AddDbContextFactory

Для этого потребуется прочитать строку подключения из конфигурации, например, из appsetting.json:

{
  "ConnectionStrings": {
    "ConnStringName": "ACTUAL_CONNECTION_STRING"
  },
}

Также вы можете переместить строку подключения к любому из поддерживаемых поставщиков конфигурации , например - Secret Manager (обратите внимание, это только для среды разработки, для других сред лучше использовать либо переменные среды, либо защищенные хранилища ключей) .

На рабочем сервере вам необходимо создать ключ конфигурации с тем же именем, что и строка производственного подключения.

Установите для переменной ASPNETCORE_ENVIRONMENT значение «Производство».

Когда среда «ASPNETCORE_ENVIRONMENT» находится в «Производстве», источник secrets.json игнорируется. Вы можете проверить это в Источники конфигурации приложений по умолчанию

Согласно документации ASP.NET Core

WebApplication.CreateBuilder инициализирует новый экземпляр класса WebApplicationBuilder с предварительно настроенными значениями по умолчанию. Инициализированный WebApplicationBuilder (построитель) предоставляет конфигурацию по умолчанию для приложения в следующем порядке, от самого высокого до самого низкого приоритета:

1. Аргументы командной строки с использованием поставщика конфигурации командной строки.
2. Переменные среды без префикса с использованием поставщика конфигурации переменных среды без префикса.
3. Секреты пользователя, когда приложение запускается в среде разработки.
4. appsettings.{Environment}.json с помощью поставщика конфигурации JSON. Например, appsettings.Production.json и appsettings.Development.json.
5. appsettings.json с помощью поставщика конфигурации JSON.
6. Откат к конфигурации хоста, описанной в следующем разделе.

При запуске производственных приложений в AWS, GCP или Azure мы храним все секреты в соответствующем диспетчере секретов облачного провайдера (например, AWS Secrets Manager) и используем сценарии при создании среды выполнения для внедрения этих секретов в переменные среды.

Обратите внимание, что под диспетчером секретов я не подразумеваю .NET Secret Manager, который просто хранит секреты в файле на машине разработки.

.NET может считывать конфигурацию из среды, включая строки подключения.

При таком подходе только доверенные сотрудники DevOps имеют возможность просматривать строку подключения. Его никогда нет в файле и уж точно никогда в системе управления версиями.

Лучшее, что вы можете сделать для строки подключения на рабочем сервере, — это настроить проверку подлинности Windows.

1. Должен быть настроен сетевой пользователь. Этому пользователю должны быть предоставлены разрешения в SQL Server.
2. Когда вы настраиваете пул веб-серверов, запустите этот пул под удостоверением, созданным в # 1.
3. На этом этапе ваша строка подключения будет выглядеть так Server=MyServerName;Database=MyDbName;Trusted_Connection=SSPI;Encrypt=false;TrustServerCertificate=true. Как видите - нет password или user

С этой настройкой, если злоумышленник не знает пароль к учетной записи, под которой работает ваш пул, это достаточно безопасно.

Если вы настаиваете на использовании Sql-аутентификации, вам необходимо сохранить свои учетные данные в диспетчере секретов безопасности (даже если они созданы самостоятельно), а затем получить их и создать строку подключения во время выполнения.