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

G>>Например есть функция F1, которая вызывает действия A, B, C. Если пользователю запрещено действие A, то ему фактически запрещена функция F1.
G>>Кроме того разрешение\запирещение некоторых действий может зависить от того в какой функции они вызываются.
G>>Разграничение доступа на уровне функций оказывается облее гибким и реализуется проще.
S>Ага. Понял к чему вы клоните. К запрету нескольких базовых действий, всё остальное работает через них — получает запрет. Так?
Нет, я как раз говорю о наложении ограничений на высокоуровневые функции. Низлежащие проверки в таком случае не нужны, но это при условии того, что никто не вызывает и не может вызвать низкоуровневые функции.

S>>>Вы можете гарантировать, что все потенциально небезопасные методы будут проверены именно на эту уязвимость?
G>>Да. Для этого тестирование и применяется.
S>Понимаете в чём дело. При таком подходе безопасность системы гарантируется только корректностью ваших тестов. Ещё Дейкстра писал, что тесты не гарантируют надёжность системы. Они только показывают возможность её работоспособности и только в определённых условиях.
Во времена Дейкстры дисциплины тестирования ПО еще не было. Если вы сделаете защиту кода декларативной (например через атрибуты в C#), то вам даже не придется тестировать защиту отдельных методов, вам достаточно будет протестировать работу механизма проверки ограничений и удостовериться что все высокоуровневые функции вызываются через этот механизм.
Это горздо проще, чем доказать корректность всяческих проверок в БД, написанных на SQL, которые в большенстве случаев даже протестировать нельзя.


G>>В общем случае получается Задача двух генералов, которая без промежуточной надежной службы не решается.
G>>Во-первых можно использовать Reliable messaging как MSMQ.
G>>Во-вторых можно использовать компенсационные действия в случае неуспеха одной из операций, чтобы свести к минимум вероятность рассогласовния данных.
G>>А по-хорошему надо настраивать управляемую синхронизацию между между базами.

S>Угу. Вот мы и пришли к распределённым транзакциям. Насколько я понимаю, они подерживаются только ограниченным набором хостов, например, WCF их помнится держит. Если вам не повезло, и сторонняя система их не держит — извините. Понимаете, веб-сервисы не панацея. Они страдают от тех же проблем взаимодействия, что и СУБД. ТОлько в случае СУБД эти проблемы решаются прямо из коробки (для большей части вендоров).
Если сторонняя система не поддерживает транзакции, то как эту проблему решает СУБД?


S>>>>>Не забываем, что веб-вервисы — очень тяжёлый протокол, и при активном обмене данными ваша система может просто загнуться. Напоследок. Вы замучаетесь синхронно реплицироваться через вебсервисы (пример — данные филиала одновременно заносятся и у них и в центральном офисе).
G>>>>От синхронной репликации через интернет загнется кто угодно.
S>>>Ну не надо, что ж вы так... Вполне осуществимая вешь.
G>>В локальной сети да, через инет, в случае 2-3 реплик уже слишком медленно работает. При этом все это жутко нерасширяемо.
S>Увы-увы Для медленных каналов можно в принципе сделать merge репликацию. Но всё-таки, согласитесь, лучше чем через веб-сервисы, а?
Что лучше? Веб-сервисы — более высокий уровень абстракции, чем БД. Пока этого не поймете толку вам от сервисов не будет.

S>>>Кстати, если не помните, я никогда не предлагал запихнуть ВСЮ БЛ в субд, а исключительно представление данных и контроль доступа к ним — то, что СУБД в принципе умеет гораздо лучше любого велосипеда.
G>>Вы рассказываете про контроль достпу к функциям системы, при этом пытаетесь такие задачи решать контролем доступа к данным.
G>>Это неправльный путь.

S>[Censored]!
S>Насколько помню, я нигде не говорил, про контроль доступа к функциям системы. Я говорил про представление данных и контроль доступа к ним. Если был не так понят — извините.
Еще раз. Если у вас полностью контролируется доступ к высокоуровневым функциям и все действия могут производиться только (!) через них, то вам контроль доступа к данным не нужен (если это только не Row Level Security).

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

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

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

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

G>... Если вы сделаете защиту кода декларативной (например через атрибуты в C#), то вам даже не придется тестировать защиту отдельных методов, вам достаточно будет протестировать работу механизма проверки ограничений и удостовериться что все высокоуровневые функции вызываются через этот механизм.
Согласен. Но у вас реально получается, что чтобы защитить доступ к конкретному набору сущностей, вам придётся заводить отдельный атрибут или enum, который будет храниться в атрибуте. Громоздко, не находите?

G>Это горздо проще, чем доказать корректность всяческих проверок в БД, написанных на SQL, которые в большенстве случаев даже протестировать нельзя.
Спорно. Но не будем

S>>Угу. Вот мы и пришли к распределённым транзакциям. Насколько я понимаю, они подерживаются только ограниченным набором хостов, например, WCF их помнится держит. Если вам не повезло, и сторонняя система их не держит — извините. Понимаете, веб-сервисы не панацея. Они страдают от тех же проблем взаимодействия, что и СУБД. ТОлько в случае СУБД эти проблемы решаются прямо из коробки (для большей части вендоров).
G>Если сторонняя система не поддерживает транзакции, то как эту проблему решает СУБД?
Никак. Просто шансы, что транзакции будут, если у нас обе стороны — СУБД — максимальны. ИМХО, мы ушли уже куда-то совсем в сторону...


S>>Увы-увы Для медленных каналов можно в принципе сделать merge репликацию. Но всё-таки, согласитесь, лучше чем через веб-сервисы, а?
G>Что лучше? Веб-сервисы — более высокий уровень абстракции, чем БД. Пока этого не поймете толку вам от сервисов не будет.
Прямая репликация эффективней, чем синхронизация через веб-сервисы. Не согласны?

S>>[Censored]!
S>>Насколько помню, я нигде не говорил, про контроль доступа к функциям системы. Я говорил про представление данных и контроль доступа к ним. Если был не так понят — извините.
G>Еще раз. Если у вас полностью контролируется доступ к высокоуровневым функциям и все действия могут производиться только (!) через них, то вам контроль доступа к данным не нужен (если это только не Row Level Security).
Ух... раз вы так считаете... //где-то выше мы вроде пришли к выводу вроде говорили что надо подымать прямую репликацию между СУБД.

G>Ваши все примеры показывают что как раз система хреново спроектирована. Каждый внешний компонент обращается к той части системы, к которой удобно.
G>У вас сильно нарушена инкапсуляция. Поэтому требуется защита на всех уровнях.
Ёк... Раз переходим на личности, то у _меня_ защита на _одном_ уровне! //воспринимать только как стёб

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

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

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

G>>Нет, я как раз говорю о наложении ограничений на высокоуровневые функции. Низлежащие проверки в таком случае не нужны, но это при условии того, что никто не вызывает и не может вызвать низкоуровневые функции.
S>Ага. Я вас всё-таки не понимаю Согласитесь, что высокоуровневых функций будет больше, и что проверка разрешений, получается, будет мешаться вместе с БЛ.
Как раз наоборот. Высокоуровневых функций получается примерно в два раза меньше сущностей в БД.
Кроме того вам надо будет заводить по 4 и боолее проверок в БД на каждую сущность.
То есть проверок в примерно в 8 раз меньше.
В высокоуровневом коде проверки можно сделать декларативными (буквально один атрибут на методе\классе и не надо лезть в БД чтобы выяснить что операцию нельзя выполнить.

G>>... Если вы сделаете защиту кода декларативной (например через атрибуты в C#), то вам даже не придется тестировать защиту отдельных методов, вам достаточно будет протестировать работу механизма проверки ограничений и удостовериться что все высокоуровневые функции вызываются через этот механизм.
S>Согласен. Но у вас реально получается, что чтобы защитить доступ к конкретному набору сущностей, вам придётся заводить отдельный атрибут или enum, который будет храниться в атрибуте. Громоздко, не находите?
Давайте сравним. Мне в веб-сервисе надо повесить на защищаемый метод атрибут
[PrincipalPermissionAttribute(SecurityAction.Demand, Role="Supervisor")]
И в констркторе написать Thread.CurrentPrincipal = HttpContext.Current.User;
Все.

Покажите ваш код проверок в БД.

Конечно в более сложных случаях надо свои атрибуты писать и с помощью АОП оборачивать классы для проверок атрибутов безопасности, но декларативность никуда не денется.
Хотя в подобных по сложности сценариях на БД организовать защиту гораздо сложнее, чем атрибутов написать.


G>>Это горздо проще, чем доказать корректность всяческих проверок в БД, написанных на SQL, которые в большенстве случаев даже протестировать нельзя.
S>Спорно. Но не будем
В каком месте спорно? Хотите сказать что SQL тестировать легче чем код на C# или другом высокоуровневом языке?

S>>>Угу. Вот мы и пришли к распределённым транзакциям. Насколько я понимаю, они подерживаются только ограниченным набором хостов, например, WCF их помнится держит. Если вам не повезло, и сторонняя система их не держит — извините. Понимаете, веб-сервисы не панацея. Они страдают от тех же проблем взаимодействия, что и СУБД. ТОлько в случае СУБД эти проблемы решаются прямо из коробки (для большей части вендоров).
G>>Если сторонняя система не поддерживает транзакции, то как эту проблему решает СУБД?
S>Никак. Просто шансы, что транзакции будут, если у нас обе стороны — СУБД — максимальны. ИМХО, мы ушли уже куда-то совсем в сторону...
Это вообще вопрос администрирования. Для репликации можно создать отдельного пользователя, с отдельным Endpoint, который может заходить только по VPN подключению c сервера с другой БД.

S>>>Увы-увы Для медленных каналов можно в принципе сделать merge репликацию. Но всё-таки, согласитесь, лучше чем через веб-сервисы, а?
G>>Что лучше? Веб-сервисы — более высокий уровень абстракции, чем БД. Пока этого не поймете толку вам от сервисов не будет.
S>Прямая репликация эффективней, чем синхронизация через веб-сервисы. Не согласны?
Что значит "эффективней"? Если у вас две одинаковые СУБД в разных местах, то смотрите выше.
Если надо синхронизироваться между базами разного происхождения (например MS SQL Server и 1C), то лучше это делать через сервисы, надежно защищенные сертификатами.
Причем тут ХП и прочая муть?