Модел на сигурност за .NET Windows Forms Application с Amazon RDS SQL Server

Ще се радвам на отзиви за най-добри практики относно модела за сигурност, който измислих за моето приложение. Гмуркам се с главата напред в надграждането на Microsoft Access Frontend/Backend до .NET WinForms/SQL Server с помощта на RDS на Amazon. Приложението ще бъде много потребителско, многосайтово (различни домейни) и ще съдържа чувствителна здравна информация.

Това е обобщението на 2 седмици изследване:

  1. Криптиран низ за свързване, съхраняван в приложението, използвайки смесено удостоверяване и SSL. Не е идеално, но мисля, че измислих начин да се оправи, ако низът за връзка бъде откраднат (вижте #5 по-долу).

  2. SQL Server приема връзки само от избрани IP адреси (всички ще бъдат статични).

  3. Низ за свързване на приложение, присвоен на един потребител на SQL Server, който има привилегии само за изпълнение. Цялото взаимодействие с DB ще се извършва с помощта на процедури. Разрешения за схема, използвани за ограничаване на потребителя на приложението до определени процедури.

  4. Потребителска таблица с SHA 256 осолени и хеширани пароли. Това осигурява първия слой на сигурност на приложението.

  5. ТОВА Е ЧАСТТА, В КОЯТО НЕ СЪМ СИГУРЕН: Всяка процедура ще се изпълни напълно само ако оператор IF, търсещ потребителското име и паролата, изпратени като една от променливите exec = True. UN/PW ще се съхранява временно за всяка сесия на приложението. Моята обосновка е, че това не позволява на потребител с низа за връзка, който по някакъв начин влиза от разрешен IP адрес, да получи/промени каквито и да било данни без валидна парола.

  6. Чувствителни колони, шифровани със симетричен ключ AES_256, шифровани от сертификат, използващ главен ключ на база данни. Потребителят на приложението има права да използва симетричен ключ и сертификат.

  7. Потребителските пароли трябва да следват правилата (дължина, комбинация от главни/малки букви, специални знаци).

Може ли някой да види някакви дупки в това или има добри алтернативи? Решава ли #5 присъщите дупки в сигурността на низа за свързване, които имат приложенията на Windows, които не могат да използват Windows Authentication?


.net security sql-server amazon-rds winforms
person JBL    schedule 04.12.2012    source източник

Отговори (1)


arrow_upward
2
arrow_downward

Като цяло вашият дизайн ми се струва като опит за дублиране на вградена функционалност (удостоверяване, оторизация, контрол на разрешенията) със собствен опит за копиране, само защото нямате доверие на вградените функции.

Използвайте SQL потребител/парола за удостоверяване/упълномощаване. НЕ създавайте таблица с потребители и хешове. НЕ изпращайте потребител и парола с всяка заявка за изпълнение (!).

Използвайте разрешения на SQL Server за контрол на достъпа. Използвайте подписване на код за детайлен контрол на изпълнението (подписани процедури). НЕ се опитвайте да изградите паралелна, дублирана инфраструктура за контрол на достъпа, НЕ съхранявайте временен потребител/парола за всяка сесия.

Използвайте инфраструктурата на защитната стена на AWS, за да контролирате IP адресите за достъп. НЕ преоткривайте своя собствена.

Ако използвате криптиране на ниво колона, разберете от какво се защитавате и каква е целта ви. Случайна загуба на медии? След това криптирайте с главен ключ на базата данни (т.е. TDE за бедните). Поверителност на данните? След това накарайте потребителя да въведе паролата за дешифриране на сертификата при всяка сесия.

разрешаване на присъщите дупки в сигурността на низа за връзка

Накарайте потребителя да въведе паролата, когато стартира приложението, така че да не излагате паролата във файловете в покой (.config). Това е всичко. SQL Server отдавна е спрял да обменя паролата по кабела за SQL удостоверяване.

person Remus Rusanu    schedule 04.12.2012
comment

http://resourcespace.org/ Изглежда отговаря на много от вашите изисквания и е специално предназначен като мениджър на изображения за използване в комбинация с други системи.

- person JBL; 04.12.2012
comment
Можете да шифровате app.config секции с помощта на DPAPI. С .Net 4.5 и нагоре имате защитени SqlCredential функция за потребител/парола вътре в процес. - person Remus Rusanu; 04.12.2012
comment
Леле, иска ми се да бях открил SQLCredential по-рано - оценявам го. - person JBL; 05.12.2012