Параметры для защиты строк подключения

Question

Просто вопрос общей архитектуры.

Я знаю, что для веб-сайтов можно использовать функции, встроенные в IIS, для шифрования раздела строки подключения. Однако в чем я не уверен, так это ... Если я сделаю это, а затем скопирую файл web.config в другой проект, сможет ли новый проект по-прежнему дешифровать раздел строк подключения в файле конфигурации?

Где это становится проблемой - доступ к производственной базе данных. Мы не хотим, чтобы кто-либо имел возможность скопировать файл конфигурации из производства в свой проект и иметь карт-бланш доступ к производственной базе данных.

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

Кроме того, для приложений с толстым клиентом (WinForms, WPF и т. Д.) Это может быть немного более проблематично, поскольку еще раз, я не уверен, что трюк шифрования IIS будет работать, так как приложения не будут работать на IIS. В настоящее время у нас есть простое решение для этого, которое включает в себя то же самое домашнее приложение, но читает зашифрованную строку из двоичного файла и дешифрует на лету.

Кажется, что это очень сшито вместе, и мы ищем лучший способ сделать это (т. Е. Отраслевой стандарт, текущие технологии и т. Д.)

Итак, более общий вопрос заключается в следующем ...

Какие подходы вы использовали для защиты ваших строк подключения? Особенно, когда речь идет о нескольких типах приложений, обращающихся к нему, шифровании и т. Д.

Answer 1

Быстрый поиск в Google покажет вам попытки других людей зашифровать некоторые или все файлы конфигурации приложения (например, Google "расшифровывает файлы конфигурации приложения").

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

Если вы обеспокоены тем, что злоумышленник выполняет действие, которое даже ваше приложение не может выполнить(например, удаление базы данных), затем убедитесь, что учетные данные, которые использует приложение, также не имеют такого типа разрешений.Это, очевидно, не предотвращает атаку, но может уменьшить количество нанесенного ей ущерба.

Защита информации, хранящейся в файле конфигурации, расположенном на компьютере пользователя, обычно не стоит времени,ПО МОЕМУ МНЕНИЮ.В конце концов, само устройство должно будет иметь возможность дешифровать информацию, и если у машины есть средства для этого, то и пользователь тоже.Вы можете сделать это затруднительным для пользователя, но обычно это все еще выполнимо.

Это не совсем прямой ответ на ваш вопрос, но я надеюсь, что это заставит вас задуматься о другом пути, который может привестик приемлемому решению.

Answer 2

Насколько я понимаю, защита зашифрованных строк подключения, как, например, представлено в статье Импорт и экспорт защищенной конфигурации ключей RSA-ключей защищает строку подключения на уровне пользователя.

Это означает, что только учетная запись с IIS (NT AUTHORITY\NETWORK SERVICE) может получить доступ к криптографическим ключам для расшифровки строки подключения. Поэтому это защищено только от пользователей, которые могут войти на сервер, содержащий файл web.config. Но его можно расширить, чтобы ограничить доступ к определенному приложению.

Что касается толстого клиента, может быть способ немного сузить интерфейс:

Определите все команды SQL как хранимые процедуры на сервере и измените настройки используемой учетной записи пользователя, чтобы разрешить выполнение только этих хранимых процедур. Это ограничит доступ к базе данных операциями, которые могут быть выполнены с использованием учетных данных для входа в SQL.

Answer 3

Я бы использовал функции управления учетными записями в БД SQL, только с определенными разрешениями (например, в наиболее абстрактном - разрешить выполнение команд SQL только для чтения) и только с разрешенных хостов и / или областей.