Witam,

ostatnio zastanawiam się nad poprawną architekturą aplikacji
bazodanowej, by była bezpieczna. Nie rozważam tutaj kwestii że będzie to
aplikacja na urządzenia mobilne, lub takie które mają bardzo ograniczone
zasoby. Język C++, może z wykorzystaniem Qt, relacyjna baza danych.
Program byłby pewną ewidencją na której wykonywałoby się odpowiednie
operacje(dodaj, usuń rekord, wystaw dokument itp. - bez większej
filozofii). Widzę dwa rozwiązania:

1) aplikacja w postaci grubego klienta - łączy się z bazą danych,
wykonuje operacje, posiada wszelkie funkcjonalności.

ZALETY:
- mniej roboty, jeden program

WADY:
- słaby stopień bezpieczeństwa bo np. mamy 100 użytkowników i każdy
program zna parametry dostępowe do bazy danych i można stosunkowo łatwo
je podpatrzeć.

2) aplikacja typu cienki klient - na serwerze przy bazie danych byłby
napisany serwer a klient jedynie wysyłałby żądania.

ZALETY:
- centralizacja dostępu,
- możliwość autoryzacji i autentykacji na maszynie gdzie dostęp ma tylko
admin,

WADY:
- konieczność stworzenie dwóch aplikacji: klient i serwer,
- program klienta działa jedynie gdy jest on-line(ewentualnie byłbym
ciekaw jak tutaj można coś zaradzić).

Przy okazji zapytam: jest sens np. trzymania zapytań tylko w aplikacji
serwera? Chodzi mi o to że klient nic nie wie o zapytaniach a jedynie
wysyła np. numer kontekstu z którego żądane są dane? Wtedy serwer
wyszukuje u siebie kontekst i wie jakie ma być zapytanie - wykonuje je i
wyniki odsyła do klienta. Dobry jest to zamysł czy przekombinowany?
Jakie są alternatywy?

Może ktoś ma jakieś komentarze do tego co napisałem? Byłbym wdzięczny za
wszelkie sugestie.

Pozdrawiam

do góry

W dniu 2011-06-28 14:55, Lukasz pisze:

> ZALETY:
> - centralizacja dostępu,
> - możliwość autoryzacji i autentykacji na maszynie gdzie dostęp ma tylko
> admin,

Ale przecież aplikacja i tak musi się rejestrować na serwerze w jakiś
sposób i też można ten sposób podejrzeć.

> Może ktoś ma jakieś komentarze do tego co napisałem? Byłbym wdzięczny za
> wszelkie sugestie.

Podstawową zaletą aplikacji serwerowej jest to, że nie wystawiasz bazy
danych na zewnątrz, co mogłoby skutkować ewentualnym niepowołanym
dostępem, a jedynie ograniczony interfejs do manipulowania danymi.

I nadrzędna zasada, jak komuś będzie odpowiednio mocno zależało, to
złamie każde zabezpieczenie.


pozdrawiam,
Przemek O.

do góry

wrote:

> Witam,
>
> ostatnio zastanawiam się nad poprawną architekturą aplikacji
> bazodanowej, by była bezpieczna. Nie rozważam tutaj kwestii że będzie to
> aplikacja na urządzenia mobilne, lub takie które mają bardzo ograniczone
> zasoby. Język C++, może z wykorzystaniem Qt, relacyjna baza danych.
> Program byłby pewną ewidencją na której wykonywałoby się odpowiednie
> operacje(dodaj, usuń rekord, wystaw dokument itp. - bez większej
> filozofii). Widzę dwa rozwiązania:
>
> 1) aplikacja w postaci grubego klienta - łączy się z bazą danych,
> wykonuje operacje, posiada wszelkie funkcjonalności.
>
> ZALETY:
> - mniej roboty, jeden program
>
> WADY:
> - słaby stopień bezpieczeństwa bo np. mamy 100 użytkowników i każdy
> program zna parametry dostępowe do bazy danych i można stosunkowo łatwo
> je podpatrzeć.

A to niby dlaczego?
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?

>
> 2) aplikacja typu cienki klient - na serwerze przy bazie danych byłby
> napisany serwer a klient jedynie wysyłałby żądania.
>
> ZALETY:
> - centralizacja dostępu,
> - możliwość autoryzacji i autentykacji na maszynie gdzie dostęp ma tylko
> admin,
>
> WADY:
> - konieczność stworzenie dwóch aplikacji: klient i serwer,
> - program klienta działa jedynie gdy jest on-line(ewentualnie byłbym
> ciekaw jak tutaj można coś zaradzić).
>
> Przy okazji zapytam: jest sens np. trzymania zapytań tylko w aplikacji
> serwera? Chodzi mi o to że klient nic nie wie o zapytaniach a jedynie
> wysyła np. numer kontekstu z którego żądane są dane? Wtedy serwer
> wyszukuje u siebie kontekst i wie jakie ma być zapytanie - wykonuje je i
> wyniki odsyła do klienta. Dobry jest to zamysł czy przekombinowany?
> Jakie są alternatywy?
>
> Może ktoś ma jakieś komentarze do tego co napisałem? Byłbym wdzięczny za
> wszelkie sugestie.
>

Generalnie - podzial aplikacji na warstwy logiczne jest ortogonalny do
podzialu "fizycznego" (rozproszenia systemu).
Ta sama aplikacja moze "zostac rozproszona" na wiele sposobow: od np. uzycia
przegladarki lub X-terminala (rozproszone jest GUI - tzw. cienki klient)
poprzez wszelkiego rodzaju architektury troj(lub wiecej)warstwowe az do
"grubego klienta" (gdzie warstwa dostepu do danych jest rozproszona).

--
Michal

do góry

epsilon$ while read LINE; do echo \>"$LINE"; done < "Michal Kleczek"
>Od dawna juz wiekszosc DBMS obsluguje autentykacje

"Uwierzytelnianie"!

--
\------------------------/
| K...@e...eu.org | http://www.nieruchomosci.pl/mieszkanie,38804171
| http://epsilon.eu.org/ |
/------------------------\

do góry

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, ze moznaby uznac ja za czesc jezyka (przy odrobinie dobrej
woli :) )

--
Michal

do góry

On 2011-06-28, Lukasz <k...@a...pl> wrote:
> ostatnio zastanawiam się nad poprawną architekturą aplikacji
> bazodanowej, by była bezpieczna. Nie rozważam tutaj kwestii że będzie to
> aplikacja na urządzenia mobilne, lub takie które mają bardzo ograniczone
> zasoby. Język C++, może z wykorzystaniem Qt, relacyjna baza danych.
> Program byłby pewną ewidencją na której wykonywałoby się odpowiednie
> operacje(dodaj, usuń rekord, wystaw dokument itp. - bez większej
> filozofii). Widzę dwa rozwiązania:
>
> 1) aplikacja w postaci grubego klienta - łączy się z bazą danych,
> wykonuje operacje, posiada wszelkie funkcjonalności.
>
> ZALETY:
> - mniej roboty, jeden program
>
> WADY:
> - słaby stopień bezpieczeństwa bo np. mamy 100 użytkowników i każdy
> program zna parametry dostępowe do bazy danych i można stosunkowo łatwo
> je podpatrzeć.

- Źle się synchronizuje dostęp przez wielu klientów.
- Na dłuższą metę duże problemy z aktualizacją (nie da się wyłączyć
klientów w starej wersji).

> 2) aplikacja typu cienki klient - na serwerze przy bazie danych byłby
> napisany serwer a klient jedynie wysyłałby żądania.
>
> ZALETY:
> - centralizacja dostępu,
> - możliwość autoryzacji i autentykacji na maszynie gdzie dostęp ma tylko
> admin,

Co to jest autentykacja? Chodzi ci o uwierzytelnianie?

> WADY:
> - konieczność stworzenie dwóch aplikacji: klient i serwer,
> - program klienta działa jedynie gdy jest on-line(ewentualnie byłbym
> ciekaw jak tutaj można coś zaradzić).

Uważasz że dostęp do centralnej bazy danych nie wymaga dostępu
sieciowego? Może za pomocą TTP, Telepathic Transmission Protocol?

> Przy okazji zapytam: jest sens np. trzymania zapytań tylko w aplikacji
> serwera? Chodzi mi o to że klient nic nie wie o zapytaniach a jedynie
> wysyła np. numer kontekstu z którego żądane są dane? Wtedy serwer
> wyszukuje u siebie kontekst i wie jakie ma być zapytanie - wykonuje je i
> wyniki odsyła do klienta. Dobry jest to zamysł czy przekombinowany?
> Jakie są alternatywy?

Alternatywą jest odbieranie zapytań SQL (albo ich dużych fragmentów) od
klienta, co jest niedorzeczne, albo stworzenie własnego języka zapytań,
co z kolei chyba przekracza twoje możliwości, skoro pytasz o komentarze
do architektury.

--
Secunia non olet.
Stanislaw Klekot

do góry

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

> ze moznaby uznac ja za czesc jezyka (przy odrobinie dobrej
> woli :) )

Przy bardzo dużej (0.75l+) ilości dobrej woli.

--
Secunia non olet.
Stanislaw Klekot

do góry

On 2011-06-28, Michal Kleczek <k...@g...com> wrote:
>> 1) aplikacja w postaci grubego klienta - łączy się z bazą danych,
>> wykonuje operacje, posiada wszelkie funkcjonalności.
>>
>> ZALETY:
>> - mniej roboty, jeden program
>>
>> WADY:
>> - słaby stopień bezpieczeństwa bo np. mamy 100 użytkowników i każdy
>> program zna parametry dostępowe do bazy danych i można stosunkowo łatwo
>> je podpatrzeć.
>
> A to niby dlaczego?
> 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. 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.

--
Secunia non olet.
Stanislaw Klekot

do góry

epsilon$ while read LINE; do echo \>"$LINE"; done < "Stachu 'Dozzie' K."
>Bo nie służą do kontroli dostępu na poziomie aplikacji używającej
>danych. 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.

Niestety, to czasami tylko pobożne życzenie :-/
#v+
1> select count(*) from syslogins
2> go
110|
#v-

--
\------------------------/
| K...@e...eu.org | http://www.nieruchomosci.pl/mieszkanie,38804171
| http://epsilon.eu.org/ |
/------------------------\

do góry

Stachu 'Dozzie' K. wrote:

> On 2011-06-28, Michal Kleczek <k...@g...com> wrote:
>>> 1) aplikacja w postaci grubego klienta - łączy się z bazą danych,
>>> wykonuje operacje, posiada wszelkie funkcjonalności.
>>>
>>> ZALETY:
>>> - mniej roboty, jeden program
>>>
>>> WADY:
>>> - słaby stopień bezpieczeństwa bo np. mamy 100 użytkowników i każdy
>>> program zna parametry dostępowe do bazy danych i można stosunkowo łatwo
>>> je podpatrzeć.
>>
>> A to niby dlaczego?
>> 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?
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.

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.

> 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.
Wrecz przeciwnie - single sign-on jest wygodne dla wszystkich uzytkownikow
bazy danych (potencjalnie podnosi tez bezpieczenstwo systemu, bo uzytkownicy
nie musza uzywac zoltych karteczek przyklejanych na monitorach zeby
zapamietac hasla do wszystkich swoich kont ;) ).

--
Michal

do góry