Zbigniew Malec wrote:

> On Tue, 28 Jun 2011 17:00:07 +0200, Michal Kleczek wrote:
>
>>> 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?
>> Oraz czy przypadkiem _rzeczywiscie_ nie przystaje.
>
> Nie ma co tego na DBMSa zwalać, bo zwyczajnie nie jesteś w stanie osiągnąć
> wystarczającej elastyczności.

Tzn. czego np?
Dobry DBMS oferuje duza elastycznosc jesli chodzi o zarzadzanie dostepem do
danych - w koncu to system zarzadzania bazami danych.
Taki Oracle daje chocby VPD.
Ale i bez tego daje sie sporo osiagnac - chocby:
http://technet.microsoft.com/en-us/library/cc966395.
aspx

> Moduł zarządzania użytkownikami DBMS jest
> projektowany pod zupełnie inne zastosowania i jako taki nie nadaje się do
> wykorzystania w aplikacji.

A to niby dlaczego?
Wydaje mi sie, ze jest dokladnie odwrotnie - modul zarzadzania uprawnieniami
w DBMS jest projektowany dokladnie po to, zeby wielu uzytkownikow moglo
korzystac z roznych (przeznaczonych dla nich) podzbiorow danych w bazie
danych.

> Użytkownicy aplikacji to są "dane", a nie
> element funkcjonalny bazy.

A to niby dlaczego?

> Podstawowym kryterium wyboru DBMS na pewno nie
> jest to, czy można użyć jego modułu zarządzania użytkownikami w swojej
> aplikacji.
>

Jest jednym z wielu kryteriow, ktore wynikaja z wymagan dot. sytemu.

>>> Jak chcesz zorganizować
>>> prawo do odczytu danych (np. faktur czy zamówień) związanych z jednym
>>> tylko klientem dla opiekuna tego klienta?
>>>
>>
>> Chocby widoki?
>
> Można, ale po co? Żeby osiągnąć odpowiednią elastyczność i tak będziesz
> musiał dobudować tyle infrastruktury, że dodatkowa tabelka z użytkownikami
> nie robi żadnej różnicy.
>

Nie bardzo rozumiem o co chodzi z ta dodatkowa tabelka z uzytkownikami.
Natomiast jesli chodzi o "dobudowe infrastruktury", to i tak musisz _gdzies_
te zabezpieczenia zaimplementowac. Moim zdaniem:
1) Bedzie taniej wykorzystac to, co juz jest zaimplementowane w DBMS
2) Bedzie _bezpieczniej_ uzywac zabezpieczen w DBMS, bo wszelkie rozwiazania
"custom made" w aplikacji nie moga byc tak dobrze zweryfikowane pod katem
bezpieczenstwa jak DBMS z polki.

>>>> 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.
>
> W przypadku osób generujących raporty z bazy, albo w inny sposób
> korzystających bezpośrednio z danych zawartych w bazie danych naturalne
> jest korzystanie z użytkowników bazodanowych. W przypadku aplikacji
> korzystającej z tych danych za pośrednictwem serwera aplikacji (albo
> grubego klienta) już takie naturalne to nie jest, bo użytkownik jest od
> tej bazy odseparowany i jego tożsamość, to jest tylko kojelny parametr w
> wykonywanych zapytaniach, a nie element funkcjonalny aplikacji.

Sa przynajmniej dwa problemy z tym rozumowaniem:
1. To jest tylko przesuniecie rozwiazania problemu z DBMS do aplikacji.
Klopot polega na tym, ze weryfikacja oprogramowania pod katem bezpieczenstwa
jest droga i co za tym idzie aplikacja jest znacznie bardziej narazona na
bledy niz DBMS (najlepszym przykladem sa wszystkie ataki typu SQL injection
- wbudowanie zabezpieczen w DBMS chroni dane przed atakami wykorzystujacymi
bledy w aplikacjach).
2. W przypadku aplikacji typu "gruby klient" - jak zapewnic, ze dostep do
danych bedzie sie odbywal _tylko_ przy pomocy tejze aplikacji?
3. Jak rozwiazac problem wielu aplikacji korzystajacych z jednej bazy
danych. Kazda ma swoj wlasny system zabezpieczen?

>
>> 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.
>
> Rezygnację całkowitą z uprawnień nadawanych przez DB można uznać za
> nierozsądną, ale nie można też popadać w przesadę. Typowy wzorzec ich
> wykorzystania to tworzenie użytkowników pod dane aplikacje i udostępnianie
> tym użytkownikom pewnego podzbioru obiektów w bazie. Pozdbiór ten w
> założeniach ma tworzyć spójne API dostępu do danych z punktu widzenia
> danej aplikacji.
> Ja bym wręcz zaryzykował twierdzenie, że utożsamianie użytkowników
> aplikacji z użytkownikami DB zmniejsza bezpieczeństwo, bo zamiast mieć
> jednego dobrze opisanego użytkownika na poziomie bazy danych (a więc w
> warstwie dostępu do danych), trzeba dbać o poprawne opisanie wszystkich
> jej (aplikacji) użytkowników.

Od tego DBMS maja na przyklad RBAC lub inne mechanizmy ulatwiajace
zarzadzanie uprawnieniami i uzytkownikami (grupy itp). Niczym sie to nie
rozni od zabezpieczania dostepu do danych na dyskach sieciowych (w koncu
system plikow to taki DBMS).

> W opisanym przeze mnie typowym przypadku
> uprawnienia użytkowników aplikacji są odseparowane od uprawnień samej
> aplikacji a co za tym idzie łatwiej jest postawić wyraźną granicę, co
> aplikacji wolno a czego jej nie wolno.
>

Ale jak zapewnic separacje uprawnien uzytkownikow w ramach aplikacji majacej
(z powodu wymagan funkcjonalnych) dostep do zbioru danych bedacego
nadzbiorem danych dostepnych kazdemu uzytkownikowi tejze aplikacji? To tylko
przesuniecie problemu i - poprzez wprowadzenie kolejnego mechanizmu
zabezpieczen - niepotrzebna komplikacja systemu.

--
Michal