Есть WinForm приложение, данные все хранятся в базе.
Нужно, чтобы человек заходя в приложение авторизовался, в зависимости от его роли ему доступны определенные права.

В общем в чем загвоздка. Если приложение само должно регулировать доступ, то программа должна иметь доступ к базе. То есть работать под юзером, под кем можно лезть в базу и вносить изменения.
Соответственно коннекшн стринга должна быть где то в конфиге забита, чтобы сервер БД можно было бы менять. Но тогда любой сможет достать ее и изменить что либо в базе.
Как от этого обезопасится? Шифровать пароль в конфиге, но при передаче он будет светится. Использовать виндовую авторизацию не получится, так как человек под своими кредами должен с любой машины заходить, даже не находящейся в домене.

Здравствуйте, Аноним, Вы писали:

А>Есть WinForm приложение, данные все хранятся в базе.
А>Нужно, чтобы человек заходя в приложение авторизовался, в зависимости от его роли ему доступны определенные права.

А>В общем в чем загвоздка. Если приложение само должно регулировать доступ, то программа должна иметь доступ к базе. То есть работать под юзером, под кем можно лезть в базу и вносить изменения.
А>Соответственно коннекшн стринга должна быть где то в конфиге забита, чтобы сервер БД можно было бы менять. Но тогда любой сможет достать ее и изменить что либо в базе.

Не надо тогда хранить Connection string. Храните имя сервера. бд, итд. А имя пользователя и пароль пусть храняться в зашифрованном виде, и программа уже будет стоить нужный connection string. Это конечно не супер безопасность, но по крайней мере она не будет взламываться простым открытием текстового файла

Здравствуйте, <Аноним>, Вы писали:

Вообще в таких случаях самая эффективная защита — открытие из базы безопасного интерфейса. Т.е. Зная логин и пароль с базой можно делать то и только то, что можно делать через программу. Это довольно трудоемко, но это единственная гарантия безопасности.

Здравствуйте, Аноним, Вы писали:

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

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

Здравствуйте, Ziaw, Вы писали:

Z>Здравствуйте, <Аноним>, Вы писали:

Z>Вообще в таких случаях самая эффективная защита — открытие из базы безопасного интерфейса. Т.е. Зная логин и пароль с базой можно делать то и только то, что можно делать через программу. Это довольно трудоемко, но это единственная гарантия безопасности.

То есть для данного пользователя закрыть доступ к таблицам, а открыть доступ только для хранимок?

Здравствуйте, <Аноним>, Вы писали:

А>То есть для данного пользователя закрыть доступ к таблицам, а открыть доступ только для хранимок?

Да, только каждому пользователю дать свой логин и раздать роли.

Здравствуйте, Ziaw, Вы писали:

Z>Здравствуйте, <Аноним>, Вы писали:
А>>То есть для данного пользователя закрыть доступ к таблицам, а открыть доступ только для хранимок?
Z>Да, только каждому пользователю дать свой логин и раздать роли.

Другой вариант навскидку -- реализовать на .net систему разграничения ролей и интерфейс в виде CLR-хранимок, и захостить это безобразие в SQL.

как вариант — приложение первый раз подключается под sql-аккаунтом guest с минимальными правами, переключается в AppRole (но опять вопрос шифрования пароля). Пользователь вводит логин-пароль внутренних аккаунтов задачи и дальше программа сама знает для какого юзера какие части задачи показывать. Все запросы идут из-под AppRole.

Здравствуйте, Аноним, Вы писали:

А>Есть WinForm приложение, данные все хранятся в базе.
А>Нужно, чтобы человек заходя в приложение авторизовался, в зависимости от его роли ему доступны определенные права.


NetSqlAzMan — .NET SQL Authorization
http://netsqlazman.codeplex.com/

Покатит? Хранилище правил авторизации можно будет юзать как из прикладухи, так и из базы

Здравствуйте, Аноним, Вы писали:

А>Есть WinForm приложение, данные все хранятся в базе.
А>Нужно, чтобы человек заходя в приложение авторизовался, в зависимости от его роли ему доступны определенные права.

Поддерживаю Ziaw'a. Самое лёгкое решение в плане сопровождения/администрирования.

А вот что делать в следующей ситуации:

У нас система безопасности сделана таким образом: все пользователи имеют свой аккаунт в базе, в программе хранится только строка подключения без логина и пароля — они вводятся пользователем и присоединяются к строке перед подключением к БД.

Пользователи обьеденены в роли, есть ХП, которая возвращает название ролей, к которым принадлежит текущий пользователь и на основании этого дисайблит определенные контролы/функции

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

Здравствуйте, Stalker., Вы писали:
S>Пользователи обьеденены в роли, есть ХП, которая возвращает название ролей, к которым принадлежит текущий пользователь и на основании этого дисайблит определенные контролы/функции

Надеюсь, это не сама защита, а только фича для удобства пользователя?

S>Все хорошо до тех пор, когда не захочется динамически настраивать доступ к функциям. Скажем, администратор захочет добавлять новые роли или например запретить доступ к какой-нибудь функции для определенной роли.
S>Как это делать ? Ничего в голову не приходит ...

У вас администратор СУБД определяет политику безопасности приложения? Просто добавление ролей обычно связано с изменением функционала, и здесь админ как бы ни при чём...

Можно сопоставить действие ролям, хранить в субд и вытаскивать инфу об этом на клиента.

Какая-то странная у вас система безопасности: действия разрешаются довольно гранулярно (раз уж речь идёт об отключении отдельных кнопок), но при этом разрешения действуют для всех сущностей. Либо недодизайненный row-level security, либо овердизайн role-based security.

Почитайте http://www.rsdn.ru/forum/design/3339717.1.aspx

Автор: Donz
Дата: 23.03.09

.

Здравствуйте, Sinix, Вы писали:

S>Надеюсь, это не сама защита, а только фича для удобства пользователя?

Интерфейс БД на хранимках, так что раздать права ролям на них не сложно, просто пока это не сделано ибо есть более насущные проблемы, чем хакерство пользователей


S>У вас администратор СУБД определяет политику безопасности приложения? Просто добавление ролей обычно связано с изменением функционала, и здесь админ как бы ни при чём...

нет нет, администратор не СУБД а администратор приложения, по сути пользователь. Функционал как раз не меняется — например он может захотеть ввести новую роль "чтец технологий и редактор нормочасов" и дать ей соответственные права


S>Можно сопоставить действие ролям, хранить в субд и вытаскивать инфу об этом на клиента.

т.е. фактически иметь таблицу с правами, где будут указаны списки прав и таблицу соответствия прав и ролей ? Например право "редактирование нормочасов" и список ролей, которые ей обладают ?


S>Какая-то странная у вас система безопасности: действия разрешаются довольно гранулярно (раз уж речь идёт об отключении отдельных кнопок), но при этом разрешения действуют для всех сущностей. Либо недодизайненный row-level security, либо овердизайн role-based security.

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

Здравствуйте, Stalker., Вы писали:

S>Интерфейс БД на хранимках, так что раздать права ролям на них не сложно, просто пока это не сделано ибо есть более насущные проблемы, чем хакерство пользователей

А зря, правило "потом==никогда" работает везде. Там не так уж и много надо (если хранимки раскиданы по схемам и разрешения на execute даются на эти схемы).

S>нет нет, администратор не СУБД а администратор приложения, по сути пользователь. Функционал как раз не меняется — например он может захотеть ввести новую роль "чтец технологий и редактор нормочасов" и дать ей соответственные права

Эххх. Чрезмерно-детализованная RBS бесполезна. Ролей должно быть как можно меньше. В идеале — по 1 на модуль системы. Тонкий тюнинг должен делаться как row-level-security (RLS) с конкретными принципалами и конкретными сущностями (обязательно с наследованием).

S>т.е. фактически иметь таблицу с правами, где будут указаны списки прав и таблицу соответствия прав и ролей ? Например право "редактирование нормочасов" и список ролей, которые ей обладают ?

Да-да. Но это кривой дизайн, т.к. вы совмещаете в 1 механизме 2 разных:
— проверку доступа к API (делается силами субд через роли)
— зачаточный RLS aka разрешения на конкретные действия над конкретными сущностями (тут нужен в принципе другой механизм).

S>тут не совсем понятно, речь идет об отдельных функциях и разрешениях на них для определенных ролей. По-моему как раз очень просто

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

Разрешения по отдельым модулям должны разруливаться отдельно.
Если смешивать — у вас один товарищ будет разрешать изменение зарплаты и выписку накладных на шнурки. Система безопасности, ёк

Почитайте линк что я вам кидал. Я там эту тему несколько раз расписывал.

Здравствуйте, Sinix, Вы писали:

S> <skipped>

Автору по-видимому ACL-система нужна. Обсасывалась это тема тут сто раз...

По теме — я бы сделал middle-tier, на который и возложил бы обеспечение безопасности. А там уже можно через имперсонацию и AD заюзать... Тогда вообще почти ничего писать не придётся — ну разве что "туннелирование" сиквельных команд.

Здравствуйте, koandrew, Вы писали:

K>Здравствуйте, Sinix, Вы писали:

S>> <skipped>

K>Автору по-видимому ACL-система нужна. Обсасывалась это тема тут сто раз...
Гммм... дык пусть он определится — я пока вижу только overdesigned role-based security. О защите на уровне сущностей речи пока не шло.


K>По теме — я бы сделал middle-tier, на который и возложил бы обеспечение безопасности. А там уже можно через имперсонацию и AD заюзать... Тогда вообще почти ничего писать не придётся — ну разве что "туннелирование" сиквельных команд.

// не холивара ради

А вы уверены что здесь аппсервер себя оправдает? Безопасность куда дешевле делается силами СУБД — всё нужное там есть. Кстати аутентификацию по kerberos может не только MS SQL.

А писать придётся, это гемморой дичайший, делать всё с нуля и своими руками. Нафик-нафик

Здравствуйте, Sinix, Вы писали:

S>Гммм... дык пусть он определится — я пока вижу только overdesigned role-based security. О защите на уровне сущностей речи пока не шло.
Ну так ACL-защита в её простейшем виде и есть RBS, тока с более человеческим лицом

S>// не холивара ради

S>А вы уверены что здесь аппсервер себя оправдает? Безопасность куда дешевле делается силами СУБД — всё нужное там есть. Кстати аутентификацию по kerberos может не только MS SQL.
Ты не понял. Как я понял, автора устраивает использование AD и MSSQL'ной системы безопасности, но есть проблема в том, что в некоторых точках доступа нет домена. Соответственно задача состоит в том, чтобы этот домен туда "доставить". Из "искоробочных" решений для этого можно заюзать, например, VPN, но у него тоже есть недостатки — например, он влияет на другие приложения. Я предлагаю сделать сервис внутри домена, который служит неким прокси для SQL сервера, т.е. он получает SQL-запрос от приложения и тупо переправляет его SQL Server'у (и, соответственно, пересылает ответ обратно приложению), но делает это в контексте пользователя, логин-пароль которого ему передаёт приложение в процессе авторизации (то есть имперсонируя этого пользователя). Соответственно сам прокси-сервис не будет содержать никакой логики, касающейся безопасности приложения, а просто будет так сказать "доставлять" домен к приложению. Физически это можно реализовать в виде ADO.NET провайдера (реализовав IDb* интерфейсы) — тогда всю эту кухню вообще можно будет включать-выключать прозрачно для приложения (просто переключая провайдера). Вот как это выглядит в графическом виде:


S>А писать придётся, это гемморой дичайший, делать всё с нуля и своими руками. Нафик-нафик
В свете выжесказанного я не вижу тут "геморроя дичайшего"...

Здравствуйте, koandrew!

K>Ну так ACL-защита в её простейшем виде и есть RBS, тока с более человеческим лицом
Согласен, слишком привык выделять RBS в отдельный паттерн.

K>Ты не понял. Как я понял, автора устраивает использование AD и MSSQL'ной системы безопасности, но есть проблема в том, что в некоторых точках доступа нет домена. ... Я предлагаю сделать сервис внутри домена, который служит неким прокси для SQL сервера, т.е. он получает SQL-запрос от приложения и тупо переправляет его SQL Server'у (и, соответственно, пересылает ответ обратно приложению)

Превед параллельной реальности! Из-за гадских квантовых флуктуаций (тм) упоминания об AD/VPN/etc наблюдаются только в ваших постах

По теме — то что вы предлагаете — дичайший идиотизм, сорри что так резко, но идея остаётся дурацкой кто бы её не предложил.

Вы предлагаете кучу кода, которая будет дублировать функционал SqlClient вместо того чтобы включить шифрованные соединения|поднять VPN|ограничить порты. Это либо незнание матчасти, либо диверсия. Признавайтесь

K>В свете выжесказанного я не вижу тут "геморроя дичайшего"...
Вы даже примерно не прикинули трудозатраты на создание протокола, сравнимого по перформансу/защищённости с TDS.
Я молчу про авторизацию, хранение сессии (ваш "сервис внутри домена" элементарно сдохнет от переполнения пула соединений), про транзакции (в том числе распределённые), bulk load...

P.S. Не обижайтесь — я начинаю звереть когда мне впаривают явную чушь. Ничего против вас лично, разумеется, не имею

Здравствуйте, Sinix, Вы писали:

S>Превед параллельной реальности! Из-за гадских квантовых флуктуаций (тм) упоминания об AD/VPN/etc наблюдаются только в ваших постах
Наличие AD и сценарий "intra-extranet client" я предположил исходя из этого:

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

S>По теме — то что вы предлагаете — дичайший идиотизм, сорри что так резко, но идея остаётся дурацкой кто бы её не предложил.

S>Вы предлагаете кучу кода, которая будет дублировать функционал SqlClient вместо того чтобы включить шифрованные соединения|поднять VPN|ограничить порты. Это либо незнание матчасти, либо диверсия. Признавайтесь

На самом деле вы будете смеяться, то такое решение у нас реально работает у одного заказчика. Ибо другого способа достучаться до их SQL-сервера снаружи нету. Правда там идёт 1 запрос в час и только один клиент.

Поскольку топикстартер не указал никаких требований, то ИМХО самый оптимальный подход — не гадать на кофейной гуще, а устроить "мозговой штурм", когда чем больше идей, тем лучше, а их применимость/целесообразность/идиотство будет обсуждаться позже. Так что в определённых условиях это таки way to go

S>Вы даже примерно не прикинули трудозатраты на создание протокола, сравнимого по перформансу/защищённости с TDS.
S>Я молчу про авторизацию, хранение сессии (ваш "сервис внутри домена" элементарно сдохнет от переполнения пула соединений), про транзакции (в том числе распределённые), bulk load...
Я в курсе всех этих проблем. Но опять-таки есть ситуации, когда часть проблем можно решить, а на другую часть просто забить

S>P.S. Не обижайтесь — я начинаю звереть когда мне впаривают явную чушь. Ничего против вас лично, разумеется, не имею
Это вы правильно делаете — тока вот звереть не стоит Просто мы по-разному подошли к задаче — я вбрасываю всё, что приходит в голову, с тем чтобы в процессе дальнейшего обсуждения и, возможно, комментациев вопрошающего определиться с их применимостью, а вы же пытаетесь приподнести на блюдечке готовое решение... Я предпочитаю набросать идеи, дабы спрашивающий имел почву для размышлений, вместо того, чтобы подумать за него и выложить ответ сюда... Всё-таки мне кажется, что данный форум (в отличие от специализированных форумов а-ля .NET) предназначен для обсуждения возможных подходов к решению задач, а не методов реализации этих подходов (этим обсуждениям ИМХО место в специализированных форумах), а потому думать за спрашивающего тут очень чревато тем, что какая-нибудь мелочь, о которой автор не сообщил, может перевернуть все ваши рассуждения с ног на голову...

Здравствуйте, koandrew!

K>Наличие AD и сценарий "intra-extranet client" я предположил исходя из этого:

От оно что... Ваше предложение от этого не выигрывает, это типичный пример: из-за одного мелкого требования корёжится весь дизайн системы. Нет блин, лучше написать свой шлюз/протокол чем ассоциировать пользователя с несколькими логинами/сделать vpn. Не забываем: свежеизобретённый велосипед тоже надо поддерживать — и ресурсов в конечном счёте уйдёт не меньше чем на допиливание штатного.

K>На самом деле вы будете смеяться, то такое решение у нас реально работает у одного заказчика. Ибо другого способа достучаться до их SQL-сервера снаружи нету. Правда там идёт 1 запрос в час и только один клиент.

А-а-а. Можно спросить — сценарий с VPN / proxy не рассматривался? или было решено что квалификации саппорта не хватит? Это ж блин джамшутинг — городить самописный шлюз из-за отсутствия админа...

---

K>Поскольку топикстартер не указал никаких требований, то ИМХО самый оптимальный подход — не гадать на кофейной гуще, а устроить "мозговой штурм", когда чем больше идей, тем лучше, а их применимость/целесообразность/идиотство будет обсуждаться позже. Так что в определённых условиях это таки way to go

Понимаете, когда я обсуждаю архитектурные вопросы, я сразу смотрю: а что будет если этот участок станет боттлнеком?
И что мне за это сделают. Отрицательная обратная связь — оччень дисциплинирует. Идеи типа "а если побольше пороху — то оно и в космос выйдет" отметаются моментально. Заодно и время экономится.

K>Я в курсе всех этих проблем. Но опять-таки есть ситуации, когда часть проблем можно решить, а на другую часть просто забить

Неа Это очень хреновая философия — сделаю абы как, потом решим. А потома не будет. Будет вечный дедлайн из-за того что у вас не хватает времени разгрестись с предыдущими проблемами (которые основная причина дедлайна). Вот эта вечная дурная вера в "потом": потом будет время — сделаю, потом будут деньги — верну кредит, потом займусь здоровьем... — она больше всего проблем и создаёт.

---

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

Уххх... вот как оно со стороны выглядит... Я просто пытаюсь сэкономить время — на основе того что предложили выдаю решение с наибольшим запасом прочности, когда тыкнут в узкие места — подправляю. Но ни один из своих советов "решением на блюдечке" не назову — как всегда, дьявол в мелочах, которые дольше расписывать чем додуматься самому. В конце-концов, каждый ССЗБ