On 2011-06-28, Michal Kleczek <k...@g...com> wrote:
[...]
>>> Od dawna juz wiekszosc DBMS obsluguje autentykacje i autoryzacje oraz
>>> oferuje narzedzia do zarzadzania kontami uzytkownikow oraz uprawnieniami.
>>> Niektore posiadaja nawet mozliwosc integracji z zewnetrznymi systemami
>>> typu LDAP/Kerberos oferujac single sign-on. Czemu z nich nie skorzystac?
>>
>> Bo nie służą do kontroli dostępu na poziomie aplikacji używającej
>> danych.
>
> Dlaczego?

Bo granulacja kontroli dostępu w DBMS często nie przystaje do granulacji
potrzebnej do implementacji kontroli dostępu. Jak chcesz zorganizować
prawo do odczytu danych (np. faktur czy zamówień) związanych z jednym
tylko klientem dla opiekuna tego klienta?

> Wielokrotnie uzywalem narzedzi w rodzaju np. SQL Navigator lub Crystal
> Reports do dostepu do danych w srodowiskach gdzie nie do wszystkich danych w
> bazie danych moglem miec dostep. Mialem swoje konto w DBMS z przypisanymi
> uprawnieniami i tyle.

Nie rozumiem. Miałeś nie mieć dostępu w aplikacji FooBarBaz do pewnych
danych, ale uzyskiwałeś go bo łączyłeś się z bazą ręcznie zamiast używać
FooBarBaz?

> Powiedzialbym wrecz, ze system w ktorym rezygnuje sie z wbudowanych w DBMS
> mechanizmow zabezpieczen na rzecz tych wbudowanych w aplikacje jest z punktu
> widzenia bezpieczenstwa gorszy.

Chyba że jest lepszy, bo uprawnienia lepiej odzwierciedlają do czego
ktoś ma dostać prawa.

>> Służą do tego, żeby w sieci, gdzie serwerów bazodanowych jest
>> dużo, administratorzy i analitycy mogli połączyć się z bazami pod swoją
>> opieką, ale już nie z cudzymi.
>>
>
> Uwaga o single sign-on byla troche "na boku" - aczkolwiek wcale nie uwazam,
> zeby single sign-on byl uzyteczny tylko dla administratorow.

A ja się odniosłem do centralizacji zarządzania uwierzytelnianiem.

Uprawnienia w bazie danych nie służą do kontroli dostępu w aplikacji, bo
nie mają odpowiedniej granulacji i zarządzanie nimi jest trudne dla
osoby nietechnicznej.

--
Secunia non olet.
Stanislaw Klekot