Az adatbázis kiszolgálókról
Az adatbázisok egy weboldal architektúrájának központi részét képezik. Segítségükkel a lehető legjobban lehet tranzakciókat kezelni, dinamikus adatokat szolgáltatni. Ahhoz, hogy a Web szolgáltatás biztonságát növeljük, az első szempont, az IIS szerver és az adatbázis szerver különválasztása. Ezzel növelni tudjuk a kiszolgálás teljesítményét is, de a biztonság a legfontosabb szempont a különválasztásnál. A különválasztott adatbázist mentesítjük a Web szervert érő hatásoktól.
Kiszolgálóként az Interneten a Web szerver felé irányul a legnagyobb figyelem, ez a legkedveltebb része a hálózatnak. Nem ajánlatos ezért adatainkat a leginkább sebezhető helyen tárolni. Támadóknak, akiknek sikerül a Web szerverbe behatolniuk, könnyű feladatot jelent rendszergazdai jogosultság megszerzése, és ez által a Web alkalmazások elérése. Ha az SQL szervert egy külön kiszolgálóra telepítjük, akkor ez a tény garantálja, hogy ezek a behatolók nem érik el a valódi értéket, céges adatainkat.
A legtöbb rendszermérnök letiltja a 80-as HTTP és a 433-as HTTPS port elérését azon a kiszolgálón, amely az SQL adatbázisokat tartalmazza. Gyakran használnak tűzfalat is, de kisebb cégeknél, ahol kevesebb erőforrás áll rendelkezésre, az IPSec segítségével blokkolják az SQL szerver elérését az általános Web portok felöl.
Adatbázis kapcsolatok kezelése
Ha a tűzfal megvalósítást tekintjük, vegyük figyelembe, hogy az SQL szerver alapértelmezésben a 1433-as port-on kommunikál, viszont ha különféle SQL szerver példányokkal dolgozunk, akkor azok a felfelé következő elérhető csatornákat használják. Különféle SQL példányok elérhetővé tesznek olyan adat környezeteket, amelyek többek között különálló folyamatokon keresztül kapcsolódnak alkalmazásainkhoz. A Microsoft Data Access Components (MDAC) szolgáltatás az, amely hozzáférést nyújt számunkra az adatbázishoz az IIS felől.
Miután telepítettük az MDAC-t szerverünkre, a Web alkalmazásunk használni fogja azt, hogy kapcsolódjon az SQL szerverhez. SQL szerver kapcsolatokat ODBC Data Source Name (DSN) segítségével állíthatunk be. A múltban az SQL szerverhez használt kapcsolatok tipikusan DSN alapúak voltak, amelyek a Web szerverre voltak telepítve az alkalmazás állományaitól elkülönítve. Ellenben az új alkalmazások már DSN nélkül kapcsolódnak. Ezek a kapcsolatok használatosak az ADO és az ADO.NET adatbázisoknál, és gyorsabban tudnak működni, mint a DSN alapú kapcsolatok (ugyanis elkerülik az ismételt registry használatot) és könnyebb telepíteni, karbantartani őket.
ADO és ADO.NET segítségével DSN nélkül tudunk kapcsolatokat létrehozni és szerver nevét, IP címet, adatbázis nevét, azonosító és jelszó adatokat szolgáltatni a kapcsolathoz. Ez a megközelítés sokkal inkább hordozható, mint a DSN alapú megközelítés, ugyanis nem kell kódolni a DSN nevet az alkalmazásban. ADO és ADO.NET megengedi az alkalmazásnak, hogy lekérje a connection-string információt bárhonnan a szerverről. A kapcsolat beállítási paraméterei tartalmazzák azt, hogy ki, mit, mikor, és hogyan kapcsolódik az adatbázishoz.
Server=127.0.0.1;
Initial catalog=sajatDB;
User id=sa;password=
A példa egy tipikus connection string-et ábrázol. Ez a beállítás meghatároz egy kapcsolatot a saját géphez, a sajatDB nevű adatbázishoz, és megpróbál kapcsolódni a system administrator fiók és üres jelszó segítségével. Ha az sa account jelszóval védett, akkor a kapcsolat lehal, és a rendszer nem ad meghatalmazást. Ez a példa nagyon egyszerűen bemutatja a beállítás = érték formátumot.
Connection String használata
Connection string-ek egyszerűek, és mivel a rendszer beállításaitól függenek, bárhol elhelyezhetjük őket alkalmazásainkban. Ez a képesség teher is lehet, hiszen a fejlesztő gyakran tévedésből beágyazza a connection string információt minden weblapba, és ezután aktualizálni, rendbe tenni azt rendkívül nehézkes lehet. Amikor ilyen adatbázis kapcsolatokkal dolgozunk, minden alkalmazásnak külön egy-egy darab kapcsolat információja kell, hogy legyen. Ezt az információt az állomány beemelésével (include) tudjuk meghatározni, vagy a registry segítségével, vagy ahogy a Microsoft ajánlja a .NET web.config állományban.
Az információ elhelyezése egy fájlba, ami a Web alkalmazás része egy jó ötlet, ugyanis a fájl mozog együtt a környezetével. Ha a környezetet egyik szerverről a másikra helyezzük át, akkor az adatbázis beállítások is vándorolnak. Aggasztó lehet az a tény, hogy a felhasználói név és jelszó hordozásával egyre inkább veszélynek tesszük ki a rendszert, lehetőséget adva betolakodók számára azok megszerzésére. Ez a megközelítés kockázatot rejt magában, de számos más előny csökkenti ennek a veszélyét. Például titkosítani lehet a felhasználói nevet és jelszót, és habár emeli a teljesítmény szükségletet, de dekódolni lehet azt, majd betölteni a tiszta verziót az alkalmazás memóriájába. Csökkenteni lehet továbbá ezt a kockázatot azzal, hogy megvonjuk a felesleges előjogokat az alkalmazás által használt felhasználói fióktól.
A registry egy kitűnő központi tároló az alkalmazás beállításoknak, ugyanis ASP és a komponensei könnyen elérik. Viszont a registry beállítások nem utaznak automatikusan a Web fájlokkal. Connection-string adat tárolás a registry-ben valószínűleg nem az egyetlen lehetséges megoldás az ASP oldalon. ASP-ben, az ASP.NET-el szemben, számos alkalmazás szintű beállítás, ami komponensekre hivatkozik valószínűleg a registry-ben található. Ámbár olyan eszközök, mint a Microsoft Application Center 2000 képes kezelni több Web szerver beállítását egy Web farm minden szerverén keresztül, a beállításokat a registry-ben hagyva nem adja meg mindazt az előnyt, amit a connection string nyújtani tud.
ASP.NET segítségével egy Web alkalmazásból csomagot képezhetünk, ami azon fájlok csoportját jelenti, amelyek a web.config állományt használják, hogy beemeljék a connection string beállításokat. Amikor a Web alkalmazás indul, betölti ezeket a beállításokat a memóriába, és elérhetővé teszi a Weboldal lapjainak és komponenseinek. Például a web.config állomány XML kódjában egy ASP.NET alkalmazásnak megtaláljuk a SessionState csomópontját. A SessionState beállításokon belül, a Visual Studio .NET automatikusan létrehoz egy connection string-et. Ezt a string-et használva, gyorsan beállíthatunk egy Web-farm-ot kiszolgáló alkalmazást, hogy automatikusan használja az SQL szerver fürtöt, hogy a session adat elérhető legyen minden szervernek a Web farm-ban.