HyperLink
Bejelentkezés
E-mail: 
Jelszó: 





Skip Navigation Links
 

A DTS csomag biztonsága


DTS 7. rész


Az SQL szerver kétféle hitelesítési lehetőségén túl a DTS csomagokat külön elláthatjuk biztonsági jelszavakkal, ráadásul kétféle jelszó lehetséges: felhasználói, és tulajdonosi. Ezzel a megoldással elérhető, hogy a csomagban tárolt információkhoz csak az illetékesek férjenek hozzá, de mégis használhatóvá váljanak a felhasználói jelszó segítségével, futtatásukra jogot szerezve.

A hálózaton a DTS csomagok megtekintéséhez, szerkesztéséhez, védelméhez, ütemezéséhez és futtatásához szükséges, hogy megértsük azokat a tényezőket, amelyek a csomagok elérését, jogosultságait és kapcsolatait jelentik.
DTS csomag jelszavak
Amikor egy csomagot elmentünk az SQL szerverbe, vagy egy tároló fájlba, használhatunk DTS csomag jelszavakat. A DTS jelszavakat a kapcsolódáshoz szükséges Windows és SQL szerver azonosításon túl használhatjuk. A következő típusú DTS csomag jelszavak az elérhetők:
  • Ha beállítunk egy tulajdonosi jelszót, akkor a csomag felhasználójának szüksége lesz erre a jelszóra, hogy módosítsa és futtassa azt.
  • Ha beállítunk egy felhasználói jelszót, akkor szintén szükséges a tulajdonosi jelszó megadása. Csak a felhasználói jelszót használók futtathatják a csomagot, viszont nekik sem megnyitási, sem szerkesztési joguk nem lesz, amíg nincs tulajdonosi hozzáférésük.
Mindenképpen javasolt a DTS csomag jelszók használata minden csomaghoz, hogy biztosítsuk a csomag és az adatbázis biztonságát, de legalábbis minimum akkor használjunk minden esetben DTS csomag jelszavakat, amikor adatforrás kapcsolat információkat mentünk el, a Windows hitelesítés használata nélkül.
Csomagütemezés és a biztonsági tényezők
Általában egy csomag a DTS tervezőből, DTS Import/Export varázslóból, DTS futtatóeszközből (DTS Run utility), vagy parancssorból, az aktuálisan belépett felhasználó biztonsági környezetéből fut. Egy csomag azonban ütemezetten futhat az SQL szerver Agent job-jának futtatókörnyezetében is. A job tulajdonosa akár más is lehet, mint az aktuálisan bejelentkezett felhasználó. Tekintsük át a következő tulajdonosi típusokat:
  • Azokban az esetekben, amikor Windows NT/2000/2003 azonosító alatt jött létre a csomag, a job az SQL szerver Agent-et indító user biztonsági környezetében fut.
  • Ha a job tulajdonosa sysadmin jogosultsággal rendelkező login, akkor a csomag alapértelmezett biztonsági környezetének megfelelő felhasználó nevében indul az SQL szerver Agent. Ha a kiszolgálón a Windows hitelesítés lett regisztrálva, akkor a job tulajdonosa lesz az SQL szerver Agent tulajdonosa. Ha a szerver SQL hitelesítést használ, akkor a job tulajdonosa ez a megadott SQL szerver login lesz.
  • Ha a job tulajdonosa egy olyan login, aki nem tagja a sysadmin szerver role-nak, akkor a csomag a job lépésének meghatalmazotti azonosítója alatt fut, annak jogosultságaival.
Tulajdonosi konfliktusok a következő típusú problémákat okozhatják:
  • A csomagban beállított fájlok útvonala nem lehet látható különféle biztonsági környezetekben. Ez azért van, mert különálló felhasználónak - aki indíthatja a csomagot – nem lehet ugyanolyan könyvtár megosztása, mint a csomag létrehozójának. (Például nem lehet olyan meghajtó címkéje, mint amit a csomagot létrehozó hozzárendelt.) Hogy védekezzünk az adott probléma ellen, használjunk univerzális elnevezési megállapodás (UNC) neveket a fájl útvonalak helyett, amikor meghatározunk külső állományokat.
  • A csomagot futtató SQL szerver Agent job tulajdonosának nincs jogosultsága ahhoz az útvonalhoz, vagy kapcsolathoz, ami a csomagban meghatározott. Például a job tulajdonosának csak helyi, szerveren belüli elérése lehet. Ha ilyen probléma jelentkezik, akkor vizsgáljuk meg a job biztonsági környezetét az SQL szerver Enterprise Manager-ben, és lépjünk ki az SQL példányból. Ezután lépjünk be ugyanarra a példányra a job által használt biztonsági környezettel, és próbáljuk meg futtatni a csomagot.
  • Azon csomagok esetében, amelyek COM komponenseket hívnak ActiveX script-ekből, a meghívott komponenseknek létezniük kell azokon a munkaállomásokon, ahol a csomag fut. Az SQL szerver Agent job fióknak szintén kell jogosultságokkal rendelkeznie, hogy futtassa a job-ot.
Az összes fenti esetben, másoljuk a csomag által használt külső állományokat ugyanarra a szerverre, így a tulajdonosi problémák által okozott hibákat kiszűrhetjük. Azokban az esetekben, ahol COM komponenseket használ egy ütemezett csomag, a meghívott komponensnek ugyanazon a szerveren betöltöttnek kell lennie, ahol az SQL szerver példány telepítve van, és az SQL szerver Agnet-nek jogot kell adni, hogy használja ezeket az objektumokat. Ellenkező esetekben a csomag nem fut le rendben.
Ha egy DTS csomagot felhasználói jelszóval ütemezünk tulajdonosi jelszó helyett, az ütemezett job nem tudósít hibáról, hacsak a csomag futása meg nem áll az első hibás lépésnél. Ez azért van, mert a felhasználónak nincs joga a csomag státuszát olvasni, miután a csomag futása megkezdődött. Ez a körülmény nem igaz arra az esetre, ha az indítás tulajdonosi jelszóval történik.
Data Link fájlok és a biztonság
Microsoft Data Link (.udl) fájlok kódolatlan text állományok, amelyeket arra használhatunk, hogy beágyazzunk egy connection string-et egy csomagba. Semmiképpen sem javasolt, hogy jelszavakat tároljunk ilyen állományokban, mert bárki elolvashatja azokat, aki a fájlt eléri. Ha data link fájlokat szándékozunk használni connection string tárolásra, akkor használjuk a Windows hitelesítést a kapcsolatban. Ez a hitelesítés nem igényli, hogy bejelentkező információkat tároljunk a fájlban. Csak egy jelölés szükséges, hogy "trusted connection"-t használunk. Ez a kapcsolatfajta biztonságos data link fájlok esetén.
Csomag biztonsági információinak elmentése
Alapértelmezésben mindkét SQL azonosítási típus esetén az adatforráshoz szükséges login információk együtt tárolódnak a csomaggal. Hogy folytatólagosan kontrolláljuk az azonosítási információkat, használjuk a "Persist Security Info" opciót az "Advanced Connection Properties" dialógusdobozban a DTS tervezőben. Ez a lehetőség csak az SQL szerver kapcsolatoknál található meg.
Lehetnek esetek, amikor kikapcsoljuk az azonosítási információk kontrollját a csomagban. Például tegyük fel, hogy létre akarunk hozni egy csomagot, amely egy különálló környezetben volt tesztelve, mint ahol létrehozzuk. Ebben az esetben nem akarhatjuk, hogy a kapcsolat biztonsági információi együtt tárolódjanak a csomaggal, ugyanis ezek az információk nem használhatók az újabb környezetben kapcsolódásra. Készítsünk kapcsolatokat adat link-ek segítségével, amelyek a beállításaikat data link fájlból kapják, és használjuk a Windows hitelesítést a kapcsolathoz. Ez növeli a csomag hordozhatóságát, és megőrzi a biztonságát is.

Cikksorozat

#IDKategóriaCikk címeSorozat
3643DelphiFormEditor1. rész
3689DelphiProject és modul információk2. rész
3719DelphiMegnyitás, mentés3. rész
3749DelphiKódszerkesztő4. rész
3778DelphiForráskód írása, olvasása5. rész
3809DelphiInterfész a kódszerkesztő ablakhoz6. rész
3839DelphiKijelölt blokkok7. rész
3869DelphiA buffer beállításai8. rész
3899DelphiKörnyezeti és Project opciók9. rész
3929DelphiKurzor a kódszerkesztőben10. rész
3959DelphiKeresés és csere beállításai11. rész


Könyv
Ez a cikk megtalálható ebben a könyvben: Windows Software Offline 2003 évkönyv 338. oldal

Felhasználási feltételek
A Software Online szoftverfejlesztői magazin mindegyik cikke, minden megjelent képe, és egyéb publikált anyaga szerzői jog védelme alatt áll! Bármilyen formában történő másodlagos terjesztésük, közzétételük vagy felhasználásuk kizárólag a kiadó előzetes írásbeli engedélyével történhet!

Copyright © 1999-2012 Animare Software Kft. Minden jog fenntartva!
| Készült: Animare Stúdió | Adatvédelem | Kapcsolat |