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. Moduł zarządzania użytkownikami DBMS jest
projektowany pod zupełnie inne zastosowania i jako taki nie nadaje się do
wykorzystania w aplikacji. Użytkownicy aplikacji to są "dane", a nie
element funkcjonalny bazy. Podstawowym kryterium wyboru DBMS na pewno nie
jest to, czy można użyć jego modułu zarządzania użytkownikami w swojej
aplikacji.

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

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

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


--
Pozdrawiam
Zbyszek Malec