Vlákno názorů k článku Správa uživatelů a databázových objektů v PostgreSQL od anonym - Pokud pouzivate aplikacni server tak tezko asi nebudete...
-
anonymní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. -
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 -
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! (neregistrovaný)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. -
LENIN POWER! (neregistrovaný)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 (neregistrovaný)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. -
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 (neregistrovaný)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. -
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 {
} -
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í. -
"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... -
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.
-
"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! (neregistrovaný)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. -
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ě.
-
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 (neregistrovaný)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.
ČLÁNKY DO MAILU