Блог

Наше приложение разработано в .net WinForms с SQL server, оно имеет собственный механизм аутентификации пользователей и авторизации профилей, сопоставленный с логином / пользователем / ролью SQL, развернутый в сети DMZ, доступный только для тех, кто авторизован.

ИТ-отдел потенциального клиента жалуется на поддержание сотен логинов / пользователей / ролей в SQL server, они хотят, чтобы только один логин / пользователь SQL был привязан к одной роли SQL server, а остальные вопросы безопасности должны управляться в клиентском приложении.

• а) Вместо того, чтобы иметь логин для каждого пользователя базы данных, могу ли я уменьшить количество учетных записей sql, сопоставив их с группой NT и связав с профилем пользователя приложения? Есть ли лучший способ?
• б) Как я могу сократить количество пользователей базы данных, не теряя возможности аудита? есть 150 активных пользователей, каждого из которых необходимо отследить.

Все зависит от того, насколько вы должны быть в безопасности.

Говоря о клиентских приложениях, у вас уже есть проблема с тем, что клиентские инструменты — по самой своей природе — подвержены злоупотреблениям; например, если у меня есть копия клиентского приложения, для меня относительно тривиально декомпилировать / перепроектировать все, что он делает, и изменить логику — полностью обходя любую безопасность в клиентском приложении. Потенциально вы все еще можете провести аудит на сервере базы данных, но, честно говоря: в большинстве случаев, если вы не поймаете вредоносный доступ к базе данных с поличным, будет очень трудно понять, что произошло — клиентское программное обеспечение можетвероятно, просто не выполняйте или выполняйте сбивающие с толку какие-либо шаги аудита. Теперь: если вы принимаете это положение, и использовать один логин, клиент подключается напрямую: ситуация будет становиться только хуже: эти учетные данные для входа должны быть встроены в приложения, так что приложение может войти от имени общих учетных данных (что означает: любой злоумышленник может заполучить их), и если вы делаете что-то поймать в законе: Вы увидите, что получилось из этих общих учетных данных, если вы можете взглянуть на данные по IP и т. д.

Если это не вектор атаки для вас: тогда, конечно, просто делайте то, что вам нужно, — но тот факт, что вы упомянули аудит, означает, что это, вероятно, нежелательно.

Вместо этого я бы предложил подумать о том, чтобы заставить клиента косвенно общаться с базой данных. Если клиентское приложение общается только через веб-службы (любого типа по вашему выбору), то у клиента гораздо более ограниченный набор действий, которые он может выполнять. Вы можете использовать существующую модель безопасности на уровне веб-служб, а затем, как только вы аутентифицируете пользователя и т. Д., переключитесь на модель доверенной подсистемы для взаимодействия с базой данных с помощью одних учетных данных — возможно, учетной записи AD, в которой запущены веб-службы. Веб-сервер является гораздо более сложной мишенью для атак и злоупотреблений. Теперь вы можете хранить всю свою логику, проверки безопасности, аудит и т. Д. На уровне веб-службы, а не на клиенте (вы, конечно, можете дублировать эти проверки на клиенте, чтобы обеспечить немедленную обратную связь с пользовательским интерфейсом о запрещенных операциях, не беспокоя веб-службу). Это дает вам лучшее из обоих миров и потенциально позволяет улучшить удаленное использование. Однако это почти наверняка означает перезапись всего уровня данных вашего приложения.