Stachu 'Dozzie' K. wrote:

> On 2011-06-28, Michal Kleczek <k...@g...com> wrote:
>>
>> 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.

Dlaczego?

> Zresztą wszystkie silniki oferują podobne uprawnienia.
>

Nie - taki np. Oracle Advanced Security option oferuje znacznie wiecej niz
dajmy na to Postgresql. A Postgresql oferuje wiecej niz MySQL.
Oczywiscie - za Oracle trzeba zaplacic. Pytanie tylko, czy zrobienie tego w
aplikacji nie bedzie drozsze niz koszt licencji dobrego DBMS.

>>> 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?
>

Przez "klienta" rozumiesz aplikacje czy uzytkownika?
Zreszta niezaleznie od tego nie ma potrzeby tworzyc oddzielnych widokow dla
kazdego klienta. Przeczytaj np:
http://technet.microsoft.com/en-us/library/cc966395.
aspx

>>>> 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.
>

Wrecz przeciwnie - bylo wszystkim znacznie latwiej, bo uprawnieniami dostepu
do danych zarzadzalo sie w jednym miejscu i nikogo nie obchodzilo w jaki
sposob (przy uzyciu jakiego oprogramowania) do tych danych sie dostawalem.
Mogla to byc nawet "zjebana aplikacja".

>>
>> 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.
>

Codziennie lacze sie po ssh z komputerem uzywanym jednoczesnie przez wielu
uzytkownikow i nie mam dostepu do danych do ktorych dostepu miec nie
powinienem. Co wiecej - proby nieautoryzowanego dostepu so monitorowane. Co
wiecej - do niektorych danych dostep jest audytowany nawet jak mam do nich
uprawnienia. I to wszystko niezaleznie od tego jakich aplikacji zechce mi
sie uzywac.
Co w tym niedorzecznego???

>>> 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.
>

Co trudnego w zrobieniu GUI ktore wykonuje np. "GRANT admins TO joe;" lub
"REVOKE admins FROM joe;" lub "CREATE USER davide WITH PASSWORD
'jw8s0F4';"???

>> 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.
>

Patrz wyzej - wydaje mi sie, ze widac...

--
Michal