Přepnout na plnou verzi

Root.cz

Názory k článku Správa uživatelů a databázových objektů v PostgreSQL

Přidat názor
19. 11. 2008 9:44

co na to aplikacni server?

Pokud pouzivate aplikacni server tak tezko asi nebudete pouzivat spolecneho databazoveho uzivatele. Nevim zda je vubec mozne aby se stateless J2EE komponenty prihlasovali do DB podle toho ktery uzivatel je zavola. Museli by si odnekud vycarovat pristup do db (jdbc url a autorizacni udaje).

Pokud nepouzivate aplikacni server a mate aplikaci spojenou primo do db tak ano, v tomto pripade je nepouzivani spolecneho uzivatele zadouci.
Franta Kučera 19. 11. 2008 10:16

Re: co na to aplikacni server?

U AS je minimálně dobré mít několik úrovní oprávnění (několik uživatelů) -- např. oddělit ověřování hesel* od veřejně dostupných informací pro zobrazování na webu od důvěrnějších informací zobrazovaných po přihlášení uživatele --> tzn. mít třeba tři uživatele a tři DS v AS.


*) přístup k tabulce s hesly a volání procedury, která kontroluje hesla
pht 19. 11. 2008 21:26

Re: co na to aplikacni server?

no, to jen poukazuje na to, jak zkostnatela je architektura aplikacnich serveru.
Franta Kučera 19. 11. 2008 22:04

Re: co na to aplikacni server?

Jakou architekturu bys místo toho doporučoval? Klasickou dvouvrstvou klient-server? Nebo SOA? Nebo něco jiného? Nebo jen tak rýpeš?

(AS tady beru jako třívrstvou architekturu: databáze – aplikační logika – tenký/tlustý klient)

BTW: jde vůbec takhle obecně říct, která architektura je dobrá a která špatná, když neznáme její využití? :-)
LENIN POWER! 19. 11. 2008 23:05

architektura aplikaci

trivrstva je dneska vicemene standard pokud nemame vsechny klienty pod velmi dobrou kontrolou, coz obvykle nemame.

Pravda je to i neco mezi - pouzivani SUID stored procedur na vsechno a odmitnuti uzivatelum se primo hrabat v tabulkach, lepsi volbou je LBAC, ale databaze s LBAC jsou az EE edice a ty nejsou pro socky.
pht 20. 11. 2008 9:05

Re: co na to aplikacni server?

Doporucoval bych tu "dvouvrstvou", kde to jen jde. Nerikam spatna, ale zkostnatela. Z hlediska bezpecnosti je vzdy vhodne delegovat spravu prav az co nejdale, namisto pristupu 'resim si to sam'.
LENIN POWER! 20. 11. 2008 9:55

Re: co na to aplikacni server?

jenomze bez LBAC nebo masivniho kodovani suid procedur musite nagrantovat RW pristup ke vetsine tabulek, takze ta 2vrstva bezpecnost je dost iluzorni. Pravda taky se da pouzivat writeable views aby treba uzivatel mohl modifikovat jen sve zaznamy, to se ale moc nedela.

Kdo vam u 2 vrstve aplikace zaruci ze si uzivatel nespusti DB SQL klienta a nezacne se hrabat v datech primo kdyz ma ke vetsine rw pristup? A muze se i odmazavat z audit logu? Naprosta vetsina aplikaci je takto napsana. S bezpecnosti si zacnou lidi delat starosti az kdyz je nektery zamestnanec okrade.
pht 20. 11. 2008 21:08

Re: co na to aplikacni server?

No tady jde prave o to, nebo alespon bych to tak chapal, ze i kdyby si uzivatel pustil SQL klienta, tak diky spravne nastavenym pravum si ani nepr... tudiz "aplikacni server"/"tlusty klient"/whatever do tohoto schematu neprinasi zadnou novou bezpecnostni funkci. Takhle je to "ciste" a "spravne", ne nutne "prakticky nejlepe".

Kdyz je vse v db (nebo i na file systemu) pod jednim userem, tak staci uhodnout to jedno heslo, nebo nejak exploitnout pristup toho "aplikacniho serveru".

Audit logy by mely z principu dovolovat jen operaci pridani a nikoliv mazani dat. A to i v pripade ze mate jen jednoho master uzivatele. Jinak vam to neprojde zadnou rozumnou kontrolou.
Franta Kučera 20. 11. 2008 10:53

Re: co na to aplikacni server?

1) „delegovat spravu prav az co nejdale, namisto pristupu 'resim si to sam'.“
To je pravda: nagrantování práv v SŘBD se dá věřit víc než vlastnímu řešení téhož v aplikační vrstvě.
ALE: ne vždy to jde (jeden koncový uživatel = jedno spojení do DB, což si často nemůžeme dovolit) a také je často tlustý klient jen zástěrkou, která „jako“ funguje, ale kdyby se uživatel připojil k DB přímo nějakým SQL klientem, ukáže se, že je tam bezpečnost velmi mizerná.

2) bezpečnost není jediné kritérium: více vrstev znamená větší flexibilitu, ve dvouvrstvé architektuře spojuješ část aplikační logiky a prezentační logiku do jednoho tlustého klienta → pokud budeš chtít vytvořit jinou prezentační logiku (např. Web, nebo veřejné API), budeš toho muset přepsat mnohem víc, kód se ti duplikuje…

Pokud budeš chtít nacpat veškerou aplikační logiku do databáze, děláš z toho vlastně zase třívrstvou architekturu: tabulky – procedury – tlustý klient. Akorát k psaní aplikační logiky používáš jiný jazyk než ve skutečném aplikačním serveru, což může a nemusí být dobré (IMHO to obecně moc dobré není*) a hlavně SŘBD není navrhován jako náhrada aplikačního serveru, tudíž nenabízí stejné služby jako AS → musíš si toho dost napsat sám, nebo to nějak zbastlit.

*) do DB bych dal jen část logiky, ne všechnu.
pht 20. 11. 2008 21:13

Re: co na to aplikacni server?

S tou zasterkou to je presne ten duvod proc jako odberatel mam velmi vyhraneny nazor vuci reseni ktere nevyuziva nativnich sluzeb zabezpeceni (prava v databazi, filesystemu, atp.) do maximalni mozne miry. To, ze je tam nekde proprietarni kod, ktery ma "chranit" (proti komu, sekretarce?), a pak master ucet s heslem "123", je opravdu vrchol a bohuzel se s tim setkavam velmi casto :-(

Samozrejme lze na tento bezpecnostni model naroubovat i trivrstvy model aplikace. Pokud aplikacni server poskytuje pridanou hodnotu nad daty v databazi, tak proc ho tam nemit. Ale proc by mel proboha resit neco co uz umi nize polozena vrstva? TO je duplicita kodu.
další
Přidat nový názor Přepnout na plnou verzi