On 2011-06-28, Michal Kleczek <k...@g...com> wrote:
[...]
>>> Od dawna juz wiekszosc DBMS obsluguje autentykacje i autoryzacje oraz
>>> oferuje narzedzia do zarzadzania kontami uzytkownikow oraz uprawnieniami.
>>> Niektore posiadaja nawet mozliwosc integracji z zewnetrznymi systemami
>>> typu LDAP/Kerberos oferujac single sign-on. Czemu z nich nie skorzystac?
>>
>> Bo nie służą do kontroli dostępu na poziomie aplikacji używającej
>> danych.
>
> Dlaczego?

Bo granulacja kontroli dostępu w DBMS często nie przystaje do granulacji
potrzebnej do implementacji kontroli dostępu. Jak chcesz zorganizować
prawo do odczytu danych (np. faktur czy zamówień) związanych z jednym
tylko klientem dla opiekuna tego klienta?

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

> Powiedzialbym wrecz, ze system w ktorym rezygnuje sie z wbudowanych w DBMS
> mechanizmow zabezpieczen na rzecz tych wbudowanych w aplikacje jest z punktu
> widzenia bezpieczenstwa gorszy.

Chyba że jest lepszy, bo uprawnienia lepiej odzwierciedlają do czego
ktoś ma dostać prawa.

>> Służą do tego, żeby w sieci, gdzie serwerów bazodanowych jest
>> dużo, administratorzy i analitycy mogli połączyć się z bazami pod swoją
>> opieką, ale już nie z cudzymi.
>>
>
> Uwaga o single sign-on byla troche "na boku" - aczkolwiek wcale nie uwazam,
> zeby single sign-on byl uzyteczny tylko dla administratorow.

A ja się odniosłem do centralizacji zarządzania uwierzytelnianiem.

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.

--
Secunia non olet.
Stanislaw Klekot

do góry

Stachu 'Dozzie' K. wrote:

> On 2011-06-28, Michal Kleczek <k...@g...com> wrote:
> [...]
>>>> Od dawna juz wiekszosc DBMS obsluguje autentykacje i autoryzacje oraz
>>>> oferuje narzedzia do zarzadzania kontami uzytkownikow oraz
>>>> uprawnieniami. Niektore posiadaja nawet mozliwosc integracji z
>>>> zewnetrznymi systemami typu LDAP/Kerberos oferujac single sign-on.
>>>> Czemu z nich nie skorzystac?
>>>
>>> Bo nie służą do kontroli dostępu na poziomie aplikacji używającej
>>> danych.
>>
>> Dlaczego?
>
> 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.

> Jak chcesz zorganizować
> prawo do odczytu danych (np. faktur czy zamówień) związanych z jednym
> tylko klientem dla opiekuna tego klienta?
>

Chocby widoki?

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

>> Powiedzialbym wrecz, ze system w ktorym rezygnuje sie z wbudowanych w
>> DBMS mechanizmow zabezpieczen na rzecz tych wbudowanych w aplikacje jest
>> z punktu widzenia bezpieczenstwa gorszy.
>
> Chyba że jest lepszy, bo uprawnienia lepiej odzwierciedlają do czego
> ktoś ma dostać prawa.
>

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.

>>> Służą do tego, żeby w sieci, gdzie serwerów bazodanowych jest
>>> dużo, administratorzy i analitycy mogli połączyć się z bazami pod swoją
>>> opieką, ale już nie z cudzymi.
>>>
>>
>> Uwaga o single sign-on byla troche "na boku" - aczkolwiek wcale nie
>> uwazam, zeby single sign-on byl uzyteczny tylko dla administratorow.
>
> A ja się odniosłem do centralizacji zarządzania uwierzytelnianiem.
>
> 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
2) tworzymy narzedzia, ktore ulatwiaja osobom nietechnicznym zarzadzanie
uprawnieniami.
W obydwu przypadkach nie widac powodu, zeby rezygnowac z tego, co oferuje
DBMS.

--
Michal

do góry

W dniu 28.06.2011 17:00, Michal Kleczek pisze:
> Tego nie rozumiem - albo:
> 1) mamy administratora DBMS, ktory jest osoba techniczna
> 2) tworzymy narzedzia, ktore ulatwiaja osobom nietechnicznym zarzadzanie
> uprawnieniami.
> W obydwu przypadkach nie widac powodu, zeby rezygnowac z tego, co oferuje
> DBMS.
>

Co w takim razie z robieniem softu dla małych i średnich firm? Załóżmy
że chcemy coś ewidencjonować i pozwolić na dostęp zdalny. Piszemy w C++
a program nie może kosztować zbyt dużo bo inaczej się nie sprzeda. Taka
firma niekoniecznie ma administratora, który będzie w stanie pogrzebać
po plikach konfiguracyjnych. Nie lepiej wtedy zrobić zrobić uprawnienia
z poziomu własnego serwera przez co łatwiej można poniekąd obejść
skomplikowane mechanizmy zaszyte w bazie danych typu Postgresql?

do góry

wrote:

> W dniu 28.06.2011 17:00, Michal Kleczek pisze:
>> Tego nie rozumiem - albo:
>> 1) mamy administratora DBMS, ktory jest osoba techniczna
>> 2) tworzymy narzedzia, ktore ulatwiaja osobom nietechnicznym zarzadzanie
>> uprawnieniami.
>> W obydwu przypadkach nie widac powodu, zeby rezygnowac z tego, co oferuje
>> DBMS.
>>
>
> Co w takim razie z robieniem softu dla małych i średnich firm?

Nie widze roznicy.

> Załóżmy
> że chcemy coś ewidencjonować i pozwolić na dostęp zdalny. Piszemy w C++
> a program nie może kosztować zbyt dużo bo inaczej się nie sprzeda.

Taniej jest wykorzystac cos gotowego (czyli DBMS) niz wynajdywac kolo.

> Taka
> firma niekoniecznie ma administratora, który będzie w stanie pogrzebać
> po plikach konfiguracyjnych.

Zrob proste GUI do "grzebania w plikach konfiguracyjnych" (przypadek 2) ).

> Nie lepiej wtedy zrobić zrobić uprawnienia
> z poziomu własnego serwera przez co łatwiej można poniekąd obejść
> skomplikowane mechanizmy zaszyte w bazie danych typu Postgresql?

A dlaczego chcesz je obchodzic? One sa po to zeby bylo _latwiej_ i
_bezpieczniej_ .

--
Michal

do góry

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

do góry

On 28/06/2011 21:25, Zbigniew Malec wrote:
> On Tue, 28 Jun 2011 17:00:07 +0200, Michal Kleczek wrote:
>
>>> 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?

Dla bezpieczeństwa?

> Żeby osiągnąć odpowiednią elastyczność i tak będziesz
> musiał dobudować tyle infrastruktury, że dodatkowa tabelka z użytkownikami
> nie robi żadnej różnicy.

Przecież nie chodzi o dodatkową tabelkę, bo ta jak najbardziej może być.
Chodzi o to, żeby udostępniać użytkownikowi tylko takie dane i pozwalać
mu je modyfikować w taki sposób, do jakiego ma uprawnienia - już na
poziomie RDBMS. Czyli nie udostępniać tabel, tylko widoki, czyli nie
pozwalać na modyfikacje przez insert/update tylko przez stored
procedures itd. To nie jest jakaś gigantyczna ilość infrastruktury.

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

Powiedz to Sony.

do góry

On 28-06-2011 15:58, Stachu 'Dozzie' K. wrote:
> On 2011-06-28, Michal Kleczek<k...@g...com> wrote:
>> Mariusz Kruk wrote:
>>
>>> epsilon$ while read LINE; do echo \>"$LINE"; done< "Michal Kleczek"
>>>> Od dawna juz wiekszosc DBMS obsluguje autentykacje
>>>
>>> "Uwierzytelnianie"!
>>>
>>
>> Slusznie - aczkolwiek "autentykacja" wydaje mi sie na tyle juz powszechnie
>> uzywana kalka,
>
> Nie. Nadal używana jest tylko przez laików. Poprawnym terminem cały czas
> jest "uwierzytelnianie".
>
Sam jestes laikiem. Formy zagielszczone to norma. Polonista sie
znalazl. Przez takich jak ty mielibysmy miedzymordzie zamiast interfejsu.



Pozdr

Marek

do góry

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?

do góry

W dniu 2011-06-28 23:17, Lukasz pisze:

> W takim razie dobrze rozumiem że jest sensowne stosowanie serwera a nie
> cienkiego klienta.

Sensowne w jakim znaczeniu?

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

IMHO źle motywujesz. W każdym wariancie ktoś dużą dawką cierpliwości,
zaciekłości i wiedzy dobierze się do danych.
To w jakim modelu będzie stworzona aplikacja zależy bardziej od innych
czynników, takich jak zakładany koszt wytworzenia, dostępny czas,
zakładane wykorzystanie aplikacji itd itp. W zależności od tych (i nie
tylko) danych można zacząć wybierać pomiędzy dostępnymi modelami lub ich
kombinacjami.

pozdrawiam,
Przemek O.

do góry

W dniu 29.06.2011 00:10, Przemek O. pisze:
> W dniu 2011-06-28 23:17, Lukasz pisze:
>
>> W takim razie dobrze rozumiem że jest sensowne stosowanie serwera a nie
>> cienkiego klienta.
>
> Sensowne w jakim znaczeniu?
>

W takim że gruby może więcej, więc trochę łatwiej dobrać się do danych.
Cienki nie wie prawie nic, wtedy aplikację serwera trzeba odpowiednio
zabezpieczyć.

>> 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?
>
> IMHO źle motywujesz. W każdym wariancie ktoś dużą dawką cierpliwości,
> zaciekłości i wiedzy dobierze się do danych.
> To w jakim modelu będzie stworzona aplikacja zależy bardziej od innych
> czynników, takich jak zakładany koszt wytworzenia, dostępny czas,
> zakładane wykorzystanie aplikacji itd itp. W zależności od tych (i nie
> tylko) danych można zacząć wybierać pomiędzy dostępnymi modelami lub ich
> kombinacjami.

Nie ma stuprocentowych zabezpieczeń - z tym się zgadzam. Chyba wiem o co
Ci chodzi. Jak będę miał do wykonania aplikacji to wtedy posiedzę nad
kwestią bezpieczeństwa. Na pewno grupa dyskusyjna dała mi trochę do
myślenia. Sądzę jednak że to co wymyśliłem jest jednak lepsze niż np.
trzymanie hasła i loginu w pliku konfiguracyjnym aplikacji i jedynie
sprawdzanie w kodzie flagi od uprawnień, którą można łatwo zmanipulować.

Pozdrawiam

do góry