Java, postgres kapcsolat

Java

Udv,

Hogyan lehetne azt megoldani,hogy csak az altalam alairt(signed) java program tudjon kapcsolodni egy postgres adatbazishoz (+ user/passwd) ?
Tehat siman jdbc-vel az user/pass ne legyen eleg!
...vagy esetleg mas hasonlo megoldas ?

  • 1797 megtekintés

( _Franko_ v | 2009. 01. 19., h – 16:21 )

Mivel az adatbázis oldalán senki nem tud arról, hogy a kliensed alá van-e írva vagy sem... ezért sehogy.

Esetleg az SSL-el lehet varázsolni, hogy a kliense SSL certet kapnak, a szerveren pedig csak azokat engeded be, akik ezzel kapcsolódnak. De a cert másolható.

Mire kell? Mi lenne a feladat? Mert a nagyvilágon át simán beengedni valakit egy adatbázisba, az nagy botorság mostanában. :)
--
http://wiki.javaforum.hu/confluence-2.10/display/FREEBSD

Igen,pont ez lenne a cel,ne legyen mindenki siman beengedve az adatbazisba.
csak nem tudom,hogy milyen lehetosegek vannak erre ha a klines egy java alk. lenne...,
vagy irni kell egy szerver oldali programot amin keresztul mehet csak a db kapcsolat ?
Nincs erre valami egyszerubb megfejtes ?

Koszonet

Szerintem megoldható, ha olyan SSL kapcsolatot készítesz, amelyben saját SSL cert-et csinálsz, és ezt saját magad hitelesíted, s úgy állítod be a PostgreSQL-t, hogy csak a hiteles klienst kapcsolatot fogadja el.

Meg kell mondjam, hogy később eléggé nehéz lesz ezt a fejlesztési modellt ellátni megfelelő jogosultságkezeléssel...
--
http://wiki.javaforum.hu/confluence-2.10/display/FREEBSD

( lguru | 2009. 01. 19., h – 16:49 )

Esetleg a hba.conf -on keresztül maximálisan korlátozni ip-re, ami nyilván messze nem lesz elég. Ezt még lehetne központi autentikálással nehezíteni (Kerberos pl.) ld. itt, de akkor sem a programhoz ragasztod. És grant csak annak a felhasználónak, akinek a nevével kapcsolódik a programod - természetesen akkor ezt más nem tudhatja.

( meepmeep v | 2009. 01. 19., h – 18:20 )

Internet -> java ee alkalmazas szerver (webservice, servlet), vagy mas szerveroldali megoldas -> postgre localhoston vagy helyi halon. Szerintem ez a nyero.

Esetleg meg lehet valamilyen php/cgi interfeszen keresztul kommunikaltatni az egeszet, ha nagyon strict, hogy mi mehet ki a webszerverre. Nalunk pl. megszoritas, hogy csak C cgi meg kliensoldali cuccok lehetnek a webszerveren, php, asp, jsp semmi.
-- 


()=() Ki oda vagyik,
('Y') hol szall a galamb
C . C elszalasztja a
()_() kincset itt alant.

Nalunk pl. megszoritas, hogy csak C cgi meg kliensoldali cuccok lehetnek a webszerveren, php, asp, jsp semmi.

Ennek milyen racionális oka van? Mert nem tudok olyan helyzetet mondani, ahol a C cgi veszélytelenebb, mint például a JSP/Servlet.
--
http://wiki.javaforum.hu/confluence-2.10/display/FREEBSD

Az, hogy a website teljes chroot-ban fut. A tomcat-et viszont baromi nehez chroot-ba tenni, mert egy csomo locitrom kell neki, ennyi erovel virtualgep - de az meg draga.
Amugy meg policy. Tudod, aminek sosem szabad az okat kerdezni.
-- 


()=() Ki oda vagyik,
('Y') hol szall a galamb
C . C elszalasztja a
()_() kincset itt alant.

Szerintem a chroot nem véd illetéktelen adatlopás ellen, mivel ott egy adatbázis valahol, amihez lehet kapcsolódni a chroot-ból... :)

Namindegy, fura, hogy bankok számlamenedzselő rendszereket bíznak Java-ra, máshol meg félnek... :)
--
http://wiki.javaforum.hu/confluence-2.10/display/FREEBSD

A vicc az, hogy ott nincs semmilyen adatbazis, a cgi is egy szerverhez kapcsolodik, ami ket tovabbi masik szerveren keresztul vegzi a 1) kliens ellenorzeset 2) az adatok integritasanak ellenorzeset 3) a kert tranyok vegrehajtasat. Az egesz titkositott protokollon megy, meg a belso rendszerben is. Valoban van adatbazis, csak annyira melyen, hogy szornyen nehez hozzajutni. Ja, es semmikepp sem a webszerveren.

Btw, nalatok kinek lehet referalni a javaforum hibairol? Nem tudok igazan kommentet irni, mindig valami hulye helyre iranyit. Oke, hogy buntetve vagyok a feledekenysegemert, de ez mar tulzas...
-- 


()=() Ki oda vagyik,
('Y') hol szall a galamb
C . C elszalasztja a
()_() kincset itt alant.

Ok, ezt mind értem, de ha meg tudja tenni egy program chroot-ból, akkor betörés után bárki más is meg tudja tenni ezeket. És én még mindig úgy érzem, hogy a Java jobban védett, mint a PHP vagy a C programok.

Javaforum ügyben pedig nekem kell szólni... például magánban... :)
--
http://wiki.javaforum.hu/confluence-2.10/display/FREEBSD

?! Azt, hogy bekuld egy amugy invalid, enkriptalt csomagot? Ha jo napja van, valaszt sem kap, ha rossz, akkor fel perccel utana mar ertesulunk rola, hogy fel vagyon torve a webszerver. Es mindig van koztunk ejjeli bagoly, aki odaul es lenyomja a megfelelo gombokat.
Amugy meg, ha a tomcat-ben vagy a javaban van valami exploitolhato hiba, az nem nagyon kepes chroot-ba futni, onnantol meg azt csinal amit akar a _valodi rendszeren_.
-- 


()=() Ki oda vagyik,
('Y') hol szall a galamb
C . C elszalasztja a
()_() kincset itt alant.

( sibidiba | 2009. 01. 20., k – 09:07 )

Aki le tudja masolni az alkalmazasban levo jelszot, az jo esellyel a kliens barmilyen viselkedeset is utanozni tudja.
Szerintem ha a jelszo nem eleg, akkor mar mas szinten kellene tovabbi vedelmet talalni pl. tunnel, VPN vagy IP szures a szerverhez valo csatlakozaskor. Tovabba a klienst is biztonsagos kornyezetben szabad csak hagyni futtatni.

--
The Net is indeed vast and infinite...
http://gablog.eu