On 2011-06-28, Michal Kleczek <k...@g...com> wrote:
> Stachu 'Dozzie' K. wrote:
>
>> 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.
>
> I to jest czesto dobry argument.
> Z drugiej strony mozna sie zastanawiac, czy moze inny (oferujacy odpowiednie
> narzedzia/granulacje) DBMS jest lepszym rozwiazaniem?

Z reguły nie dobiera się silnika bazodanowego ze względu na uprawnienia
jakie oferuje. Zresztą wszystkie silniki oferują podobne uprawnienia.

>> Jak chcesz zorganizować
>> prawo do odczytu danych (np. faktur czy zamówień) związanych z jednym
>> tylko klientem dla opiekuna tego klienta?
>>
>
> Chocby widoki?

I co, osobny widok dla każdego klienta? Super. Tylko wiesz że tym by się
tragicznie zarządzało?

>>> 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?
>>
>
> Mialem nie miec dostepu do pewnych danych _niezaleznie_ od tego jakiej
> aplikacji uzywam do dostepu.
> Podobnie jak mam nie miec dostepu do danych w katalogu /home/iksinski
> niezaleznie od aplikacji jakiej uzywam.

Czyli ktoś zjebał aplikację, że mogłeś się do tych danych dokopać.
Mianowicie błąd był w tym, że mogłeś się w ogóle połączeć z bazą danych.

>>> 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.
>>
>
> W wiekszosci zastosowan komputerow przedmiotem ochrony sa _dane_ (pomijam
> przypadki, gdzie chroni sie dostep np. do zewnetrznych urzadzen).
> Z punktu widzenia bezpieczenstwa danych zezwolenie na to, zeby kazda
> aplikacja definiowala _swoj wlasny_ model ochrony danych jest ryzykowny.

Erm. To może zdefiniuj jeden model ochrony dla całego komputera
i przestań się przejmować co która aplikacja robi? Przecież to
niedorzeczny postulat.

>>>> 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.
>>
>
> Tego nie rozumiem - albo:
> 1) mamy administratora DBMS, ktory jest osoba techniczna

Chyba że nie mamy, bo to mała firemka z małym systemikiem do
fakturowania.

> 2) tworzymy narzedzia, ktore ulatwiaja osobom nietechnicznym zarzadzanie
> uprawnieniami.

Tylko że stworzenie takich narzędzi dla na przykład baz SQL-owych jest
trudne.

> W obydwu przypadkach nie widac powodu, zeby rezygnowac z tego, co oferuje
> DBMS.

W obydwu przypadkach nie widać możliwości, żeby używać tego, co oferuje
DBMS w zakresie autoryzacji, w samej aplikacji.

--
Secunia non olet.
Stanislaw Klekot