W dniu 28.06.2011 22:25, Zbigniew Malec pisze:
> 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.
>

Z góry przepraszam za brak cięcia ale ciężko mi było coś wywalić by nie
zagubić kontekstu poprzedniej wypowiedzi do której chcę nawiązać.

W takim razie dobrze rozumiem że jest sensowne stosowanie serwera a nie
cienkiego klienta. Motywuję to tym że w grubym kliencie ktoś z dużą
dawką cierpliwości i zaciekłości może dojść np. do zmiennej trzymającej
uprawnienie przez co można by było zmienić dane bez upoważnienia. W
przypadku połączenia z serwerem, który zapytuje bazę, byłaby możliwość
przy każdej operacji sprawdzanie użytkownika i hasła, które oczywiście
byłyby w tabeli z użytkownikami.

Użytkownicy z bazy danych z kolei posłużyć by mogli do zawężenia dostępu
do konkretnych tabel, procedur, schematów lecz nie są w stanie zastąpić
użytkowników aplikacji.

Trzyma się to kupy?