Ochrana údajů v connection stringu v aplikaci rubrika: Programování: .Net

2 petrnev
položil/-a 17.8.2022

Ahoj chtěl bych se zeptat, jak řešíte v neserverové aplikaci (tlustí klienti se připojují přímo do databáze pod jedním uživatelem) načítání connection strigu s heslem.

Psát heslo do konfiguračního souboru v plain textu nechci.

Existují na to nějaké doporučené principy?

Díky za info, P.

odkaz
8 rmaslo
odpověděl/-a 19.8.2022

Pokud je aplikace fyzicky dvouvrstvá (bez middleware vrstvy na serveru), tak databázový server musí fungovat i jako server aplikační. Což podle mne znamená především tyto věci:

  1. Obsahuje aplikační logiku (většinou uložené procedury, triggery)
  2. Stará se o práva a uživatele
  3. Případné požadavky na filesystem jdou přes něj
  4. Často je potřeba řešit práva i na úroveň řádků

Což bývá často problematické, protože mnohé SQL servery buď pro toto podporu nemají, anebo to nenabízí "hosting" (třeba ten v principu nekonečný počet zakládaných uživatelů). Proto se dvouvrstvé aplikace moc nedělají. Nicméně pokud mám server pod kontrolou a db stroj "je kvalitní" a obsahuje dostatečnou podporu pro mnou požadované akce, tak to realizovatelné je.

V tomto případě je podle mne jediné čisté řešení taková situace, kdy každý uživatel má svého uživatele založeného přímo v db (kde má nastavená své práva) a připojuje se na něj. Pak žádné jméno a heslo pro connect string není potřeba nikam ukládat, protože to je to přesně to jméno a heslo, kterým se uživatel přihlásí do aplikace.

Nějaké univerzální jméno a heslo do db pro všechny uživatele je podle mne špatná cesta protože to znamená, že tlustý klient někde něco šifruje/dešifruje (třeba požadavky na databázi) a databáze mu je v principu schopna provést více operací než na které má práva. A každé šifrování/dešifrování uložené někde na lokále lze podle mne v principu prolomit. Ať už je tím lokálem javascript aplikace v browseru, anebo .exe soubor.

Komentáře

  • petrnev : Jojo, je to špatně, s adminem na stanici si podle mne rozšifruju cokoliv. Jde mi spíše o nějaký rozumný poměr cena/výkon. AD není, databáze je jak oracle, tak MS. 19.8.2022
  • rmaslo : A kde je tedy vůbec uložena tabulka uživatelských jmen a (hashů) hesel? Předpokládám, že je to někde administrovatelné centrálně. Ten connect string by ta autentifikace uživatele pak mohla vracet jako odpověď toho, že uživatel je ok. Dokonce by mohla vracet pro každou skupinu jiný (jiný třeba pro fakturanty, jiný pro vedoucí a jiný pro obchodníky). Tím by v db mohl být pro každou skupinu jiný uživatel s jinými právy což by aspoň nějakým základním způsobem zajistilo bezpečnost. 19.8.2022
  • petrnev : Tabulka uživatelů a hashů je v databázi, ale ověřuje ji klient. Ale není špatný nápad vracet connectstring z databáze nějakou procedurou přístupnou pro všechny. 19.8.2022
  • harrison314 : "Tabulka uživatelů a hashů je v databázi, ale ověřuje ji klient." - to je upne zbytocne, kedze si klient vie aj tak vycitat vsetky udaje a vsteky modifikovat 20.8.2022
  • rmaslo : Souhlas s Harrison. Uživatele by měl v každém případě ověřovat server. I kdyby tam kvůli tomu měla být nějaká "mikroaplikace". Čímž ale vlastně zavádíme middleware vrstvu. 21.8.2022

Pro zobrazení všech 3 odpovědí se prosím přihlaste:

Rychlé přihlášení přes sociální sítě:

Nebo se přihlaste jménem a heslem:

Zadejte prosím svou e-mailovou adresu.
Zadejte své heslo.