Hlavní navigace

Připojení k Internetu

Jak se měří internet pomocí sond

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

uživatel si přál zůstat v anonymitě
19. 11. 2008 9:44 Nový

co na to aplikacni server?

celé vlákno
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 aura:80
19. 11. 2008 10:16 Nový

Re: co na to aplikacni server?

celé vlákno
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
pht (neregistrovaný)
19. 11. 2008 21:26 Nový

Re: co na to aplikacni server?

celé vlákno
no, to jen poukazuje na to, jak zkostnatela je architektura aplikacnich serveru.
Franta Kučera aura:80
19. 11. 2008 22:04 Nový

Re: co na to aplikacni server?

celé vlákno
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!
LENIN POWER! (neregistrovaný)
19. 11. 2008 23:05 Nový

architektura aplikaci

celé vlákno
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
pht (neregistrovaný)
20. 11. 2008 9:05 Nový

Re: co na to aplikacni server?

celé vlákno
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!
LENIN POWER! (neregistrovaný)
20. 11. 2008 9:55 Nový

Re: co na to aplikacni server?

celé vlákno
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
pht (neregistrovaný)
20. 11. 2008 21:08 Nový

Re: co na to aplikacni server?

celé vlákno
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 aura:80
20. 11. 2008 10:53 Nový

Re: co na to aplikacni server?

celé vlákno
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
pht (neregistrovaný)
20. 11. 2008 21:13 Nový

Re: co na to aplikacni server?

celé vlákno
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.
Franta Kučera aura:80
20. 11. 2008 21:58 Nový

Re: co na to aplikacni server?

celé vlákno
Doporučuji kouknout na JAAS http://java.sun.com/javase/technologies/security/ a http://java.sun.com/javase/6/docs/technotes/guides/security/

To, že přesuneš část bezpečnosti na aplikační server, neznamená, že si tam tu bezpečnost budeš bastlit* sám. Naštěstí :-)

*) if ("root".equals(uživatel)) {

} else {

}
Pavel Stěhule aura:89
21. 11. 2008 9:06 Nový

Re: co na to aplikacni server?

celé vlákno
Souhlas - základ je zabezpečení databáze. Osobně se s mírnou duplicitou kódu dokážu smířit - např. validace datumu (formátu) v javascriptu, a pak ještě další v db. Databáze je poslední instance - tu mi nikdo neobejde - na druhou stranu je docela daleko, a tak není na škodu některé kontroly umístit na klienta - výsledkem je duplicitní kód (jasně) ale také vyšší ergonomie aplikace a zároveň robustní aplikace (čím více kontrol, tím lépe).

Na úrovni databáze se poměrně snadno zajistí bezpečný přístup k datům - hůře už se bude omezovat přístup k funkcím aplikací (takže i určitá implementace práv uživatelů je od věci i na úrovni aplikace). Do jisté míry jde i o dvě různé věci - zabezpečení dat X zabezpečení funkcí (procesů) aplikace - je nutné řešit obojí.
Franta Kučera aura:80
21. 11. 2008 9:57 Nový

Re: co na to aplikacni server?

celé vlákno
"validace data (formátu) v javascriptu, a pak ještě další v db. Databáze je poslední instance - tu mi nikdo neobejde"

Tak tohle snad nikdo nezpochybňuje - kontrolovat datové typy a další omezení v databázi je základ, výhoda DB je v tom, že se tyhle pravidla definují deklarativně místo, aby se psaly do kódu aplikace. A ten javascript je jen pomůcka pro uživatele, aby se o případné chybě dozvěděl ještě před odesláním formuláře -- jen pro jeho pohodlí.

Nevýhodu dvouvrstvé architektury ale vidím v tom, že ne vždycky se podaří všechnu aplikační logiku nacpat do databáze a klient je pak tlustší, než bychom chtěli --> když pak budeme chtít přidat jinou prezentační vrstvu, duplikuje se nám kód.

Další problém nastává u složitějších aplikací: ne všechno musí být v databázi, natož jedné konkrétní databázi. Aplikace může chtít pracovat i s jinými zdroji* a pak se opravdu hodí, tam tu další vrstvu (AS) mít -- jinak tlustý klient nepříjemně naroste a už to není jen GUI k DB procedurám.

*) různé databáze, webové služby, protokoly jako SMTP, IMAP, LDAP, volání API nějakého jiného SW...
Pavel Stěhule aura:89
21. 11. 2008 10:26 Nový

Re: co na to aplikacni server?

celé vlákno
Architekturu beru dost pragmaticky - a přiznám se, že mám občas problém s definicí dvou/tří vrstvé architektury - dost se nám osvědčila kombinovaná architektura - většina operací nad daty, řízení procesů bylo umístěno v databázi - přičemž k této db mohl přistupovat tlustý klient, nad ní další vrsva v php, která řešila komunikaci - a samozřejmě koncový AJAX klient. Primárním cílem je ovšem co nejlepší (největší) zpřístupnění databáze (resp. dat) - tj. takže mám (a používám také třívrsvou architekturu) - ale prostřední vrstva mi slouží jenom pro komunikaci.
Franta Kučera aura:80
21. 11. 2008 11:43 Nový

Re: co na to aplikacni server?

celé vlákno
"Primárním cílem je ovšem co nejlepší (největší) zpřístupnění databáze"
jj, taky nemám rád, když někdo nedoporučuje (nebo zakazuje) přímou práci s databází a musí se jít přes další vrstvu -- okecávat se to dá jakkoli, ale většinou to značí, že to nějak zprasili, neví, kde co mají a spoléhají se zbytečně na doprogramované kontroly v aplikaci.
IMHO by datový model měl být tak přehledný a dobře navržený/zabezpečený, aby s ním mohl pracovat přímo alespoň správce. Určitě by DB neměla být černá skříňka, do které smí přistupovat jen aplikace (což bývá další černá skříňka).
LENIN POWER!
LENIN POWER! (neregistrovaný)
21. 11. 2008 12:24 Nový

Re: co na to aplikacni server?

celé vlákno
jak chcete zajistit aby uzivatel mohl videt v tabulce jen urcite radky. Udelate view podle soucasneho uzivatele?
Co kdyz jsou ale pristupova pravidla slozitejsi:

Uzivatel X z oddeleni Y muze videt vsechny radky ktere zadalo oddeleni Z + vsechny radky co zadalo oddeleni Q a jsou ted ve stavu S2? To se nam uz zacina komplikovat. LBAC vetsinu techto problemu resi http://www.oracle.com/technology/deploy/performance/pdf/design_for_ols.pdf

Ovsem mam dojem ze se tu nebavite o databazi s LBAC ale o databazi co umi davat jen pristup podle tabulek v lepsim pripade i podle sloupecku. To bych tedy rad vedel jak tohleto chcete v praxi zajistit na urovni DB. Kdyz udelate SUID stored procedury, kdo vam zajisti ze v procedure neni security bug, protoze jak se zda tam vam vadi aplikacni servery prave z duvodu moznych security bugu kodu testujiciho pristup k datum.
Franta Kučera aura:80
21. 11. 2008 13:08 Nový

Re: co na to aplikacni server?

celé vlákno
Jde to přes role a pohledy. Ale právě proto píšu "přímo alespoň správce" -- vím, že udělat tohle na úrovni jednotlivých uživatelů je složitější, proto se taky spíš přikláním k tomu, aby existovala ještě nějaká mezivrstva (AS) mezi DB a klientem. Na druhou stranu, když autor aplikace z DB udělá černou skříňku a nesmí do ní přistupovat nikdo jiný než jeho aplikace, tak je to taky špatně.
Pavel Stěhule aura:89
21. 11. 2008 14:29 Nový

Re: co na to aplikacni server?

celé vlákno
Něco podobného se řeší docela běžně - např. v systémových pohledech - jen se tomu neříká LBAC. V pg můžete použít modul Veil http://ftp.iasi.roedu.net/mirrors/ftp.postgresql.org/projects/pgFoundry/veil/
Zdenek Kotala
Zdenek Kotala (neregistrovaný)
22. 11. 2008 10:14 Nový

Re: co na to aplikacni server?

celé vlákno
Jestli se nepletu tak integrace se SELinuxem/Trusted Solarisem, by mela byt obdobou LBAC. Minimalne cast z toho by se mela objevit jiz v 8.4.
Pavel Stěhule aura:89
21. 11. 2008 17:29 Nový

Re: co na to aplikacni server?

celé vlákno
V pg zrovna ještě můžu použít tzv. rules. Žádný problém, chce to jen trošku invence.
pht
pht (neregistrovaný)
19. 11. 2008 21:25 Nový

propojeni na ldap/krb

celé vlákno
bylo by mozne v nejakem pristim clanku popsat propojeni uzivatelu / roli s ldapem/kerberosem ? co jsem tak koukal do dokumentace, tak by to mel pg umet, ale neni nad praktickou zkusenost.
Pavel Stěhule aura:89
19. 11. 2008 22:30 Nový

Re: propojeni na ldap/krb

celé vlákno
Bohužel s tím nemám žádnou praktickou zkušenost - díval jsem se podporu ldapu v pg a ta je opravdu hodně minimalistická - v podstatě to dokáže jen ověřit heslo.
Jirka
Jirka (neregistrovaný) ---.cortex.cz
25. 5. 2010 16:11 Nový

Nastavování práv k tabulkám

chci se zeptat, jestli je možné nastavovat práva k tabulkám pro konkrétního uživatele nějak hromadně (ideálně jedním příkazem) nebo je nutné po vytvoření nového uživatele přidávat práva postupně k jednotlivým tabulkám,view­s,funkcím atd.. ?

Zasílat nově přidané příspěvky e-mailem