Чи є гарною практикою встановлення рядків підключення у веб-конфігурації?

Нещодавно я мав дискусію з деякими колегами по моїй роботі, тому що вони сказали, що краще мати .DLL зашифрований рядок. І я сказав, чому просто не використовувати рядкове з'єднання, визначене в зашифрованому web.config? це те саме, і це краще, тому що фреймворк об'єкта, наприклад, шукає назву з'єднання у веб-конфігурації програми, тепер я хочу дізнатися з точки зору безпеки, що краще чи що найкраща практика ??

Суттєвої різниці немає, окрім того, що вам доведеться насправді створити двійковий файл, якщо ви хочете внести зміни в конфігурацію, якщо помістити його в DLL, тоді як адміністратор може просто змінити конфігурацію за допомогою добре зрозумілих нестандартних інструментів якщо він знаходиться в налаштуваннях. Вже є механізм шифрування конфігураційних рядків та додаткові вказівки щодо MSDN . Поточні версії Asp.Net можуть мати альтернативні механізми, тому пройдіть кілька додаткових досліджень, перш ніж приймати підхід.

Тільки тому, що щось сидить у DLL, це не робить його більш захищеним. Текстовий редактор може так само добре відкривати двійкові файли, такі інструменти, як Reflector, можуть забезпечити приємніший інтерфейс для навігації по .Net DLL; DLL не надасть жодного "додаткового" шифрування.

Не має значення, де зберігаються зашифровані дані, важливо, як вони зашифровані.

Зашифровані розділи в web.config, як правило, шифруються API захисту даних , що зламати надзвичайно важко без шкоди для всієї машини. Ви також можете використовувати контейнер з ключами RSA, який подібний (важко дістати їх з машини).

Якщо ви хочете зберегти зашифровану рядок у DLL, це гарно, я думаю, хоча вона не є більш надійною, ніж зашифрований web.config (хтось може зазирнути в цю DLL за допомогою Reflector ), і очевидно важче змінити (ви мені потрібно перекомпілювати). Але знову ж таки, що набагато важливіше - це те, як генерувався той зашифрований рядок; імовірно, ви не використовуєте тих самих постачальників, що і для зашифрованого web.config, тож що ви використовуєте?

Схема шифрування настільки ж сильна, як приватний ключ або загальний секрет. Якщо цей ключ також зберігається у вашій збірці, то ви також можете взагалі не мати шифрування. Якщо вона зберігається у якійсь зовнішній базі даних, тоді виникає питання про те , як захищено рядок з'єднання цієї бази даних. Це дійсно може призвести лише до слабшої безпеки в цілому.

З іншого боку, якщо ви були постачальником послуг, а рядок з'єднання було зашифровано паролем користувача , то це було б більш безпечно, ніж використання статичного ключа машини. Знову ж таки, якщо ви використовуєте паролі користувачів для шифрування, навряд чи вам буде важко кодувати зашифровані дані у вашій збірці, оскільки їх потрібно генерувати та зберігати у відповідь на дії користувача (а не розробника).

Дійсно, я не можу придумати надто багато ситуацій, коли жорстке кодування (зашифрованого) рядка з'єднання в DLL є більш безпечним, ніж шифрування відповідного розділу web.config. У кращому випадку це просто додає незручностей, а в гіршому - це покладається на якусь незграбно написану власну безпеку, пронизану дірками. Зробіть собі прихильність і зробіть те, що рекомендує Microsoft - просто зашифруйте вашу web.config, якщо там є конфіденційні дані.

Найкращою практикою для ASP.NET є розміщення всіх конфігурацій / налаштувань у файлі web.config або файлі app.config (для інших типів проектів).

Про шифрування та про причину використання його у ваших рядках з'єднання має бути дуже особливим випадком. Тому що в більшості випадків до 99% вам не потрібно шифрувати рядки з'єднання. У власних корпоративних програмах Майкрософт розміщено рядок підключення у файлі web.config / app.config. Я думаю, ви надто ускладнюєте безпеку.

Ще одне - жорстке кодування ваших рядків з'єднання - це погана практика. Наприклад, не ставте жодну рядок з'єднання (він же з'єднання) в DLL або .aspx / .ascx / .cshtml або код-позаду.