Stachu 'Dozzie' K. wrote:

> On 2011-06-28, Michal Kleczek <k...@g...com> wrote:
>>> 1) aplikacja w postaci grubego klienta - łączy się z bazą danych,
>>> wykonuje operacje, posiada wszelkie funkcjonalności.
>>>
>>> ZALETY:
>>> - mniej roboty, jeden program
>>>
>>> WADY:
>>> - słaby stopień bezpieczeństwa bo np. mamy 100 użytkowników i każdy
>>> program zna parametry dostępowe do bazy danych i można stosunkowo łatwo
>>> je podpatrzeć.
>>
>> A to niby dlaczego?
>> 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?
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.

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.

> 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.
Wrecz przeciwnie - single sign-on jest wygodne dla wszystkich uzytkownikow
bazy danych (potencjalnie podnosi tez bezpieczenstwo systemu, bo uzytkownicy
nie musza uzywac zoltych karteczek przyklejanych na monitorach zeby
zapamietac hasla do wszystkich swoich kont ;) ).

--
Michal