Безопасное соединение с базой данных. Лучшая практика архитектуры DAL .net

Question

У нас есть несколько приложений, установленных в нескольких отделах, которые взаимодействуют с базой данных через Интранет. Пользователи, как правило, используют слабые пароли или хранят логин / пароль, написанный на листах бумаги, где их могут видеть все. Я беспокоюсь о утечке логина / пароля и хочу свести к минимуму последствия. Также было бы неплохо минимизировать поверхность атаки сервера базы данных, скрывая сервер базы данных от доступа к интрасети.

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

Какие технологии .net и лучшие практики вы бы предложили?

Спасибо заранее!

Answer 1

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

Аутентификация и авторизация пользователя должны обрабатываться отдельно от доступа к БД.

Сама системная учетная запись БД должна иметь ТОЛЬКО привилегии для выполнения задач, необходимых для работы системы. Это означает только предоставление доступа к процедурам, выполняемым приложением, и, возможно, доступ к чтению любых таблиц или представлений, считываемых через LINQ to SQL.

Answer 2

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

1. У пользователей есть учетные записи на компьютере с БД? Удалите их, если это возможно
2. Предоставляются ли пользователям наименьшие права доступа? Используя любые механизмы, которые вы считаете подходящими, удалите как можно больше прав пользователей [exec]. Одна вещь, которую я видел в крайнем конце этого, - это хранить проки, которые на самом деле имели соответствующие права exec, а пользователь имел только права exec на procs.
3. Вы удалили права пользователя для запуска каких-либо команд изменения таблиц? В том числе возможность запуска системных хранимых процедур. Это может существенно сократить количество инцидентов (случайных и злонамеренных)
4. Имеют ли пользователи прямой доступ к необработанным бизнес-данным? Если это так, подумайте о перемещении доступа в представления, а также об удалении прав пользователя на сами таблицы. Это также решает некоторые проблемы с обслуживанием
5. У вас есть аудит? Уровень таблицы или пользовательский.

Если вы чувствуете, что у вас там цельный дизайн, тогда вы можете начать оборачивать свою БД внутри брокера / фасада для доступа. Помните, что это может быть дорогостоящим с точки зрения производительности, развертывания и безопасности, и это не так просто сделать. Несколько предложений по шаблонам для этого:

1. Посмотрите на брокера сервисов: например, WSO2 , и они являются другими, которые могут быть использованы для сокрытия важных бизнес-приложений (хотя его целью является публикация доступа к ним), предоставляя услуги кэширования и прокси для их. Это может немного уменьшить вашу атаку, но конфигурация и управление легко превзойдут любые выгоды.
2. Вы можете свернуть свои собственные брокерские услуги (на основе WCF и т. П.), Которые вам понадобятся, чтобы убедиться, что вы адекватно учитываете нагрузку и прогнозируемый рост, но это не является невозможным или даже недоступным, если вы действительно хотите это сделать и у вас есть время правильно его оформить.