Administrace komentářů

Ad. Everest, MySQL není pupkem světa, ale předmět dotazu je jasný :)

Tazatel nepíše nic o centrální autentizaci. Uživatele nabušíte do mysql přes myadmin stejně dobře jako byste je bušil do té aplikace.

Ad. Centrální heslo, kde ? co ? jak ?, každá aplikace má vlastní každý server má vlastní (je to jen jiný pohled na bezpečnost, Vám hesla kolují světem a je jich hodně, ale zajišťují oprávněnost požadavku na každé úrovni, a někomu jedno silné skryté heslo, které nikde nekoluje).

To jste ještě úplně asi nepochopil tu myšlenku. Bude-li N uživatelů, budu já mít N hesel, zatímco Vy budete mít N+1 hesel, kde právě to plus první bude heslo, kterým se aplikace připojuje do databáze. Uživatelská hesla budou kolovat světem stejně v obou modelech. Ve Vašem modelu navíc musíte dbát nejen o vysokou bezpečnost toho aplikačního hesla ale i o integritu celé aplikace. To jsou tisíce řádků navíc a tedy tisíce možných problémů. Ve Vašem modelu stačí najít jednu problematickou část a BANG uživatel aplikace má najednou všechna práva. To je pak bezvadné, když já jako registrovaný zákazník e-shopu můžu měnit stavy zásob na skladě.

A ano, každá aplikace může mít svoje vlastní heslo. Více aplikací neřeším bez újmy na obecnosti. Řeším jen více uživatelů s různými právy v rámci jedné aplikace.

tak si ten audit (chcete-li kontrolu) udělám abych zjistil jestli tam není nějaké potenciální riziko

Aha. Takže zřejmě máte schopnost najít všechny chyby v aplikaci během jednoho večera (nebo jak dlouho auditujete:)

A nebo ne? Jakou metodiku a nástroje používáte? Kolik lidí a jakých má Váš auditovací tým? Kolik času věnujete auditu? Auditujete i proces vývoje u dodavatele? Co děláte s chybami, opravujete je, posíláte patche? Ukažte reference na Vaši auditorskou činnost u několika OSS projektů.

Ad. Váš model (je jeden z modelů), ale je si třeba uvědomit, že tím musíte hlídat bezpečnost všech článků - DB server musí být odolný vůči vnějším útokům.

A Vy bezpečnost všech článků nehlídáte? Pak máte bezpečnost závislou na nejslabším z nich, tj. zřejmě velmi nízkou. To je ostatně vidět i na konceptu "aplikačního hesla". Jedna úroveň ochrany a konec.

100% integritu

Proč ne rovnou 110 :)

Všimněte si že připouštím více uživatelů na DB (read/write) a těch může být více (zmiňované role) - je to další stupeň bezpečnosti, eliminující jisté chyby v aplikaci.

To je hezké, ale pokud jsou hesla ke všem rolím na jednom místě, tak to zas tak moc velká výhra není.

Ruku na srdce jste schopen nastavit jednotlivé uživatele na velkém projektu přesně a do detailu tak aby měli oprávnění přesně na každý sloupec databáze (struktura DB se pak řídí jen bezpečnostním modelem)?

Ano jsem. V definici takových pravidel není rozdíl proti "programování aplikační logiky". Samozřejmě ta politika musí mít hlavu a patu nebo se z toho zblázníte. Jen v databázi je výsledek že to nenadefinujete, zatímco v "aplikační logice" to nějak uděláte, ale bude neprůhledné a pravděpodobně ochcatelné.

Rozlišit oprávnění na data a současně na procesy a akce na úrovni DB vyžaduje mít nastavenu 100% aplikační logiku v DB na vše VIEW a funkce metody a trigery. Samozřejmě je to cesta, a perfektní, ale realizace je mnohem náročnější a zrovna na intranet(záleží co to obnáší) mi to nepřipadne vhodná.

Vážně? Když bude mít Franta přístup do "objednávek" jen pro čtení a Honza jen pro připisování, tak mi na to stačí dva SQL příkazy při inicializaci účtů. Pak tato pravidla budou platit univerzálně, i kdyby se aplikační logika postavila na hlavu. Ve Vašem případě budete mít u každé činnosti deset ifů a pokud něco někde zmrvíte, tak objednávku přepíšete třeba jen omylem.

Triggery a funkce budete potřebovat až v druhé fázi (a to kdoví jestli). Například když budete chtít aby se při každé nové objednávce něco stalo. Jenže to může zrovna tak dělat ta aplikační logika jako dřív, protože to s bezpečností nesouvisí.