On Wed, 29 Jun 2011 09:49:32 +0200, Michal Kleczek wrote:

> 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

W DBMS masz granulację na poziomie obiektu, a nie rekordu, grupy rekordów,
czy nawet wybranych kolumn z danej grupy wierszy. I tak trzeba logikę
dostępu do danych gdzieś zaszywać z boku i same uprawnienia DBMS i tak nie
wystarczą.

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

Jedny z wielu, zgadzam się że może być brany pod uwagę. Myślę jednak, że są
dużo istotniejsze czynniki w wyborze i ten jeden akurat nie jest tak bardzo
istotny.

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

No właśnie i tak gdzies to trzeba zabezpieczenie zrealizować. Dodatkowy
koszt utworzenia tejże tabelki z użytkownikami będzie własnie pomijalny.
Argument kosztu do mnie tutaj nie przemawia, i tak to co jest już w bazie
do zarządzania trzeba dopiero wykorzystać w aplikacji, a więc dorobić całą
logikę dostępu do danych. No i jeszcze dostajemy rozwiązanie, które jest
mocno przywiązane do jednej konkretnej bazy danych. Owszem, zmiana DBMSa to
nie jest mała rzecz, ale jednak się zdarza. A gdzie wsparcie w postaci
technologii typu Hibernate i pokrewnych?

>> 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 bazie aplikacyjnej to właściwie można się nawet bez constraintów obejść -
aplikacja może wszystkiego przypilnować. W przypadku bazy integracyjnej,
gdzie twoja aplikacja jest tylko gościem, nie jest już tak różowo. Tutaj
nie ma mowy o przesuwaniu tej odpowiedzialności na aplikację i umywania
rąk. Baza danych dostarcza aplikacji pewnego API w postaci kolekcji
obiektów dostępnych w ramach uprawnień użytkownika aplikacyjnego. I teraz
wiadomo, że aplikacja namiesza najwyżej tyle, ile jest na to pozwala
publiczne API. Korzystanie z wbudowanych mechanizmów nic nam tu nowego nie
daje, bo i tak tę logikę dostępu trzeba zrealizować, czy to w postaci kodu
programu, czy też wyszukanego setupu z pomocą narzędzi za setki tysięcy
dolarów (no, trochę przesadzam). A w samej aplikacji trzeba oczywiście i
tak jeszcze odrębnie zakodować reguły dostępu, bo przecież nie będziesz
udostepniał użytkownikowi końcowemu interfejsu do zrobienia wszystkiego i
tylko polegał na tym, że się baza z odpowiednim wyjątkiem wywali. Nie wiem
też jak wyglądają te super rozwinięte narzędzia do obsługi DBMS (nie miałem
styczności), ale czy np. przewidują tworzenie roli i grup użytkowników (to
widzę że tak) i czy takim grupom/rolom można przypisać uprawnienia do
odpowiednio drobno granulowanych danych? Czy można do nich dodawać rózne
metadane? A czy takie narzędzia pozwalają na tworzenie relacji między
użytkownikami i udostępnienie danych w kontekście danej relacji (co
ostatnio w projekcie w którym biorę udział dość mocno jest praktykowane)
Czy do wszystkiego tego da się dostać z poziomu aplikacji? To jest dość
chyba podstawowa funkcjonalność której używa się w aplikacjach. A co z
aplikacjami rozproszonymi, gdzie jednego użytkownika używa się do
autoryzacji wielu niezwiązanych czynności w potencjalnie różnych bazach
danych i nie ma ścisłego powiązania między daną bazą a użytkownikiem
końcowym aplikacji?

Ataki SQL injection też nie mają prawa bytu, jeżeli aplikacja korzysta
wyłącznie z dobrze zdefiniowanego interfejsu bazy danych. Jeżeli aplikacji
nie pozwalamy robić przelewów, to mamy gwarancję, że żaden jej użytkownik
przelewu nie wykona. I to już jest bardzo dobre zabezpieczenie.
I nie bardzo sobie wyobrażam, żeby np. dało się za pomocą takich narzędzi
opisać sytuację, w której to pełnomocnik klienta może wykonywać przelewy w
imieniu klienta, ale tylko z konta danego typu.

Wbudowanie zabezpieczeń w DBMS - jak najbardziej tak! Koniecznie wręcz w
przypadku większych baz, gdzie dana aplikacja jest tylko gościem. Tylko ja
co innego rozumiem pod pojęciem wbudowania zabezpieczeń w bazę, niż
korzystanie z użytkowników samego DBMSa. Tworzenie użytkownika
aplikacyjnego i wytawienie dobrze zdefiniowanego API w ramach tego
użytkownika daje nam klarowną granicę zaufania i jasny podział
odpowiedzialności. A tak część logiki jest w bazie, część tej samej logiki
w aplikacji, a cześć w konfiguracji samej bazy.

Ad 2. Jeżeli każda aplikacja ma dobrze określony sposób dostępu do danych
to problem nie występuje. Masz określone grono użytkowników, które coś z
danymi mogą w ogóle zrobić. Konkretnie użytkownik techniczny aplikacji oraz
administratorzy.

Ad 3. To jest bardzo ogólne pytanie. To wszystko zależy o jakich
aplikacjach mówimy i jaki jest cel istnienia danej hierarchi użytkowników.
Uprawnienia użytkowników mogą być też różne w różnym kontekście, a co za
tym idzie różne w różnych aplikacjach.

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

Czyli nie ten poziom granulacji.

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

Nie bardzo rozumiem, co chciałeś przez to powiedzieć.
A poziomów zabezpieczeń powinno być conajmniej tyle ile granic zaufania w
całej aplikacji.

Zresztą cała ta nasza dyskusja jest niestety zawieszona w powietrzu. Co
innego jest w przypadku bazy aplikacyjnej, a co innego w przypadku bazy
integracyjnej. Co innego w przypadku aplikacji korporacyjnej a co innego w
przypadku aplikacji dla masowego użytkownika. Z tego wątku tu już chyba nic
nie będzie :]

--
Pozdrawiam
Zbyszek Malec