Megosztás a következőn keresztül:

Szolgáltatások biztonságossá tétele

  • Cikk

A Windows Communication Foundation (WCF) szolgáltatás biztonsága két elsődleges követelményből áll: az átvitel biztonságából és az engedélyezésből. (A biztonsági események naplózására vonatkozó harmadik követelményt a Naplózás.) Röviden: az átvitel biztonsága magában foglalja a hitelesítést (a szolgáltatás és az ügyfél identitásának ellenőrzését), a bizalmasságot (üzenettitkosítást) és az integritást (az illetéktelen módosítás észleléséhez használt digitális aláírást). Az engedélyezés az erőforrásokhoz való hozzáférés vezérlése, például csak a jogosultsággal rendelkező felhasználók számára engedélyezi a fájlok olvasását. A WCF funkcióinak használatával a két elsődleges követelmény könnyen implementálható.

Az osztály (vagy a <konfiguráció alapszintűHttpBinding> eleme) kivételével BasicHttpBinding az átviteli biztonság alapértelmezés szerint engedélyezve van az összes előre definiált kötés esetében. Az ebben a szakaszban szereplő témakörök két alapvető forgatókönyvet tárgyalnak: az adatátvitel biztonságának és engedélyezésének implementálását az Internet Information Services (IIS) szolgáltatáson üzemeltetett intranetes szolgáltatáson, valamint az átvitelbiztonság és -engedélyezés implementálását egy IIS-en üzemeltetett szolgáltatáson.

Biztonsági alapismeretek

A biztonság a hitelesítő adatokra támaszkodik. A hitelesítő adatok azt bizonyítják, hogy egy entitás az, akinek állítja. (Egy entitás lehet egy személy, egy szoftverfolyamat, egy vállalat vagy bármi, amely engedélyezhető.) Egy szolgáltatás ügyfele például identitásigénylést végez, és a hitelesítő adatok valamilyen módon igazolják ezt az igényt. Egy tipikus forgatókönyvben hitelesítő adatok cseréje történik. Először is egy szolgáltatás személyazonossági jogcímet állít ki, és hitelesítő adatokkal igazolja azt az ügyfélnek. Ezzel szemben az ügyfél identitásigénylést végez, és hitelesítő adatokat ad át a szolgáltatásnak. Ha mindkét fél megbízik a másik hitelesítő adataiban, akkor biztonságos környezet hozható létre, amelyben az összes üzenet bizalmasan lesz kicserélve, és az összes üzenet aláírása az integritásuk védelme érdekében történik. Miután a szolgáltatás létrehozza az ügyfél identitását, a hitelesítő adatokban szereplő jogcímek egy csoporthoz tartozó szerepkörrel vagy tagsággal egyeznek. Mindkét esetben a szolgáltatás engedélyezi az ügyfél számára, hogy a szerepkör vagy csoport jogosultságai alapján korlátozott számú műveletet hajtson végre, vagy használja azt a csoportot, amelyhez az ügyfél tartozik.

Windows biztonság mechanizmusok

Ha az ügyfél és a szolgáltatás számítógépe olyan Windows-tartományon van, amelyhez mindkettőnek be kell jelentkeznie a hálózatra, a hitelesítő adatokat a Windows-infrastruktúra biztosítja. Ebben az esetben a hitelesítő adatok akkor jönnek létre, amikor egy számítógép-felhasználó bejelentkezik a hálózatra. A hálózat minden felhasználóját és minden számítógépét a megbízható felhasználók és számítógépek csoportjához tartozóként kell ellenőrizni. Windows rendszeren minden ilyen felhasználó és számítógép biztonsági tagként is ismert.

Egy Kerberos-vezérlő által támogatott Windows-tartományban a Kerberos-vezérlő egy sémát használ, amely az egyes biztonsági tagoknak szóló jegyek megadásán alapul. Azokat a jegyeket, amelyeket a vezérlő ad vissza, a rendszer többi jegymegadója megbízhatónak minősíti. Amikor egy entitás megpróbál valamilyen műveletet végrehajtani vagy hozzáférni egy erőforráshoz (például egy számítógépen található fájlhoz vagy könyvtárhoz), a rendszer megvizsgálja a jegy érvényességét, és ha áthalad, a rendszer egy másik jegyet kap a művelethez. A jegyek megadásának ez a módszere hatékonyabb, mint az egyszerűség ellenőrzése minden műveletnél.

A Windows-tartományokban használt régebbi, kevésbé biztonságos mechanizmus az NT LAN Manager (NTLM). Azokban az esetekben, amikor a Kerberos nem használható (általában Windows-tartományon kívül, például munkacsoportban), az NTLM használható alternatívaként. Az NTLM biztonsági lehetőségként is elérhető az IIS-hez.

Windows rendszeren az engedélyezés úgy működik, hogy minden számítógépet és felhasználót szerepkörökhöz és csoportokhoz rendel. Például minden Windows rendszerű számítógépet egy személynek (vagy személyek csoportjának) kell beállítania és felügyelnie a rendszergazdai szerepkörben. Egy másik szerepkör a felhasználó szerepköre, amely sokkal korlátozottabb engedélykészlettel rendelkezik. A szerepkörön kívül a felhasználók csoportokhoz vannak rendelve. A csoportok lehetővé teszik, hogy több felhasználó is ugyanabban a szerepkörben teljesítsen. A gyakorlatban tehát egy Windows rendszerű gépet úgy felügyelnek, hogy felhasználókat rendelnek csoportokhoz. Egy számítógép felhasználói csoportjához például több felhasználó is hozzárendelhető, és a rendszergazdák csoportjához sokkal korlátozottabb felhasználók is hozzárendelhetők. A helyi gépeken a rendszergazdák új csoportokat is létrehozhatnak, és más felhasználókat (vagy akár más csoportokat) is hozzárendelhetnek a csoporthoz.

Windows rendszerű számítógépeken a címtárak minden mappája védhető. Vagyis kijelölhet egy mappát, és szabályozhatja, hogy kik férhetnek hozzá a fájlokhoz, és hogy átmásolhatják-e a fájlt, vagy (a legjogosabb esetben) módosíthatnak egy fájlt, törölhetnek egy fájlt, vagy fájlokat adhatnak hozzá a mappához. Ezt hozzáférés-vezérlésnek nevezzük, és a mechanizmust hozzáférés-vezérlési listának (ACL) nevezzük. Az ACL létrehozásakor hozzáférési jogosultságokat rendelhet bármely csoporthoz vagy csoporthoz, valamint egy tartomány egyes tagjaihoz.

A WCF-infrastruktúra ezeknek a Windows biztonsági mechanizmusoknak a használatára lett tervezve. Ezért ha intraneten üzembe helyezett szolgáltatást hoz létre, és amelynek ügyfelei a Windows-tartomány tagjaira korlátozódnak, a biztonság könnyen implementálható. Csak érvényes felhasználók jelentkezhetnek be a tartományba. A felhasználók bejelentkezése után a Kerberos-vezérlő lehetővé teszi, hogy minden felhasználó biztonságos környezeteket hozzon létre bármely más számítógéppel vagy alkalmazással. Egy helyi gépen egyszerűen létrehozhat csoportokat, és adott mappák védelmekor ezek a csoportok hozzáférési jogosultságok hozzárendelésére használhatók a számítógépen.

Windows biztonság megvalósítása intranetes szolgáltatásokon

A kizárólag Windows-tartományon futó alkalmazások védelméhez használhatja a kötés alapértelmezett biztonsági beállításait.WSHttpBindingNetTcpBinding Alapértelmezés szerint az ugyanazon a Windows-tartományban lévők hozzáférhetnek a WCF-szolgáltatásokhoz. Mivel ezek a felhasználók bejelentkeztek a hálózatra, megbízhatóak. A szolgáltatás és az ügyfél közötti üzenetek titkosítva vannak a bizalmasság érdekében, és az integritás érdekében alá vannak írva. A Windows-biztonságot használó szolgáltatások létrehozásával kapcsolatos további információkért lásd : Szolgáltatás védelme Windows hitelesítő adatokkal.

Engedélyezés a PrincipalPermissionAttribute osztály használatával

Ha korlátoznia kell az erőforrások elérését a számítógépen, a legegyszerűbben az PrincipalPermissionAttribute osztályt kell használnia. Ez az attribútum lehetővé teszi a szolgáltatásműveletek meghívásának korlátozását azáltal, hogy követeli, hogy a felhasználó egy adott Windows-csoportban vagy szerepkörben legyen, vagy hogy egy adott felhasználó legyen. További információ : Hozzáférés korlátozása a PrincipalPermissionAttribute osztálysal.

Megszemélyesítés

A megszemélyesítés egy másik mechanizmus, amellyel szabályozhatja az erőforrásokhoz való hozzáférést. Alapértelmezés szerint az IIS által üzemeltetett szolgáltatás az ASPNET-fiók identitása alatt fut. Az ASPNET-fiók csak azokat az erőforrásokat érheti el, amelyekhez engedéllyel rendelkezik. Beállíthatja azonban, hogy egy mappa ACL-je kizárja az ASPNET szolgáltatásfiókot, de bizonyos más identitások is hozzáférhessenek a mappához. A kérdés ezután az lesz, hogyan engedélyezheti ezeknek a felhasználóknak, hogy hozzáférjenek a mappához, ha az ASPNET-fiók erre nem jogosult. A válasz a megszemélyesítés használata, amely lehetővé teszi, hogy a szolgáltatás az ügyfél hitelesítő adatait használja egy adott erőforrás eléréséhez. Egy másik példa egy olyan SQL Server-adatbázis elérése, amelyhez csak bizonyos felhasználók rendelkeznek engedéllyel. További információ a megszemélyesítés használatáról: Ügyfél megszemélyesítése szolgáltatáson és delegáláson és megszemélyesítésen.

Biztonság az interneten

Az internetes biztonság ugyanazokból a követelményekből áll, mint az intranetes biztonság. A szolgáltatásnak be kell mutatnia a hitelesítő adatait, hogy bizonyítsa hitelességét, és az ügyfeleknek igazolniuk kell személyazonosságukat a szolgáltatásban. Miután az ügyfél identitása bizonyított, a szolgáltatás szabályozhatja, hogy az ügyfél mennyi hozzáféréssel rendelkezik az erőforrásokhoz. Az internet heterogén jellege miatt azonban a megjelenített hitelesítő adatok eltérnek a Windows-tartományokban használt hitelesítő adatoktól. Míg a Kerberos-vezérlők a hitelesítő adatokra vonatkozó jegyekkel kezelik a tartomány felhasználóinak hitelesítését, az interneten a szolgáltatások és az ügyfelek a hitelesítő adatok bemutatásának bármely különböző módjára támaszkodnak. A témakör célja azonban egy olyan közös megközelítés bemutatása, amely lehetővé teszi az interneten elérhető WCF-szolgáltatás létrehozását.

IIS és ASP.NET használata

Az internetbiztonság követelményei és a problémák megoldására szolgáló mechanizmusok nem újak. Az IIS a Microsoft internetes webkiszolgálója, és számos biztonsági funkcióval rendelkezik, amelyek ezeket a problémákat kezelik; emellett ASP.NET olyan biztonsági funkciókat is tartalmaz, amelyeket a WCF-szolgáltatások használhatnak. Ezeknek a biztonsági funkcióknak a kihasználásához üzemeltetjen egy WCF-szolgáltatást az IIS-en.

ASP.NET tagság és szerepkör-szolgáltatók használata

ASP.NET tagságot és szerepkör-szolgáltatót is tartalmaz. A szolgáltató a hívók hitelesítéséhez használt felhasználónév-jelszó párok adatbázisa, amely lehetővé teszi az egyes hívók hozzáférési jogosultságainak megadását is. A WCF használatával egyszerűen használhat egy már meglévő tagságot és szerepkör-szolgáltatót a konfiguráción keresztül. Az ezt szemléltető mintaalkalmazásért tekintse meg a Tagság és szerepkör-szolgáltató mintát.

Az IIS által használt hitelesítő adatok

A Kerberos-vezérlők által támogatott Windows-tartományokkal ellentétben az internet olyan környezet, amely egyetlen vezérlő nélkül kezeli a több millió felhasználót, aki bármikor bejelentkezik. Ehelyett az interneten a hitelesítő adatok leggyakrabban X.509-tanúsítványok (más néven Secure Sockets Layer vagy SSL- tanúsítványok) formájában vannak. Ezeket a tanúsítványokat általában egy hitelesítésszolgáltató állítja ki, amely lehet egy harmadik féltől származó vállalat, amely a tanúsítvány hitelességéért és a kibocsátott személyért felelős. Ha a szolgáltatást az interneten szeretné elérhetővé tenni, egy ilyen megbízható tanúsítványt is meg kell adnia a szolgáltatás hitelesítéséhez.

Ezen a ponton felmerül a kérdés, hogyan szerezhet be ilyen tanúsítványt? Az egyik módszer egy külső hitelesítésszolgáltató , például az Authenticode vagy a VeriSign megnyitása, amikor készen áll a szolgáltatás üzembe helyezésére, és megvásárol egy tanúsítványt a szolgáltatáshoz. Ha azonban a WCF fejlesztési fázisában van, és még nem áll készen arra, hogy tanúsítványt vásároljon, az X.509-tanúsítványok létrehozásához léteznek olyan eszközök és technikák, amelyekkel éles környezeteket szimulálhat. További információ: A tanúsítványok használata.

Biztonsági módok

A WCF-biztonság programozása néhány kritikus döntési pontot von maga után. Az egyik legalapvetőbb a biztonsági mód kiválasztása. A két fő biztonsági mód az átviteli mód és az üzenet mód.

A harmadik mód, amely mindkét fő mód szemantikáját egyesíti, az átvitel az üzenet hitelesítő adataival.

A biztonsági mód határozza meg az üzenetek védelmének módját, és minden választásnak vannak előnyei és hátrányai, ahogy az alábbiakban ismertetjük. A biztonsági mód beállításával kapcsolatos további információkért lásd : Útmutató: A biztonsági mód beállítása.

Átviteli mód

A hálózat és az alkalmazás között több réteg is van. Ezek egyike a *,* átviteli réteg, amely kezeli az üzenetek végpontok közötti átvitelét. Jelenleg csak azt kell megértenie, hogy a WCF több átviteli protokollt használ, amelyek mindegyike képes biztosítani az üzenetek átvitelét. (A szállításokkal kapcsolatos további információkért lásd: Szállítások.)

A gyakran használt protokoll a HTTP; a másik a TCP. Ezen protokollok mindegyike képes biztosítani az üzenetek átvitelét egy, a protokollhoz tartozó mechanizmussal (vagy mechanizmusokkal). A HTTP protokollt például SSL-lel védik HTTP-en keresztül, amelyet gyakran "HTTPS"-ként rövidítünk. Így amikor a biztonsági átviteli módot választja, a protokoll által diktált mechanizmust választja. Ha például az osztályt WSHttpBinding választja ki, és annak biztonsági módját Átviteli módra állítja, akkor az SSL-t HTTP-n (HTTPS) keresztül választja ki biztonsági mechanizmusként. Az átviteli mód előnye, hogy hatékonyabb, mint az üzenet mód, mivel a biztonság viszonylag alacsony szinten van integrálva. Átviteli mód használata esetén a biztonsági mechanizmust az átvitel specifikációjának megfelelően kell megvalósítani, így az üzenetek csak pontról pontra haladva haladhatnak biztonságosan az átvitelen keresztül.

Üzenet mód

Ezzel szemben az üzenetmód úgy biztosítja a biztonságot, hogy minden üzenet részeként tartalmazza a biztonsági adatokat. Az XML- és SOAP-biztonsági fejlécek, a hitelesítő adatok és az üzenet integritásának és titkosságának biztosításához szükséges egyéb adatok minden üzenetben megtalálhatók. Minden üzenet tartalmaz biztonsági adatokat, ezért a teljesítmény díjköteles, mivel minden üzenetet külön-külön kell feldolgozni. (Átviteli módban az átviteli réteg védelme után az összes üzenet szabadon áramlik.) Az üzenetbiztonságnak azonban van egy előnye a közlekedésbiztonsággal szemben: rugalmasabb. Vagyis a biztonsági követelményeket nem a szállítás határozza meg. Az üzenet védelméhez bármilyen típusú ügyfél-hitelesítő adatot használhat. (Átviteli módban a átviteli protokoll határozza meg a használható ügyfél-hitelesítő adatok típusát.)

Átvitel üzenet hitelesítő adataival

A harmadik mód ötvözi az átvitel és az üzenetbiztonság legjobb előnyeit. Ebben a módban a szállítási biztonság az összes üzenet bizalmasságának és integritásának hatékony biztosítására szolgál. Ugyanakkor minden üzenet tartalmazza a hitelesítő adatait, ami lehetővé teszi az üzenet hitelesítését. Hitelesítéssel az engedélyezés is implementálható. A feladó hitelesítésével az erőforrásokhoz való hozzáférés a feladó identitásának megfelelően biztosítható (vagy megtagadható).

Az ügyfél hitelesítő adattípusának és hitelesítő értékének megadása

A biztonsági mód kiválasztása után előfordulhat, hogy meg kell adnia egy ügyfél hitelesítőadat-típusát is. Az ügyfél hitelesítő adatainak típusa határozza meg, hogy az ügyfél milyen típusú hitelesítést használjon a kiszolgálón.

Azonban nem minden esetben van szükség ügyfél-hitelesítő adatokra. Az SSL HTTP-en (HTTPS) keresztül történő használatával egy szolgáltatás hitelesíti magát az ügyfélnek. Ennek a hitelesítésnek a részeként a szolgáltatás tanúsítványát a rendszer egy tárgyalás nevű folyamat során küldi el az ügyfélnek. Az SSL által védett átvitel biztosítja, hogy minden üzenet bizalmas.

Ha olyan szolgáltatást hoz létre, amely megköveteli az ügyfél hitelesítését, az ügyfél hitelesítő adatainak kiválasztása a kiválasztott átviteltől és módtól függ. A HTTP-átvitel és az átviteli mód kiválasztása például számos lehetőséget kínál, például az Alapszintű, a Kivonatoló és más lehetőségeket. (További információ ezekről a hitelesítő adatok típusairól: A HTTP-hitelesítés ismertetése.)

Ha olyan szolgáltatást hoz létre egy Windows-tartományon, amely csak a hálózat többi felhasználója számára lesz elérhető, a legegyszerűbben a Windows ügyfél hitelesítő adatainak típusa használható. Előfordulhat azonban, hogy egy szolgáltatást tanúsítványsal kell ellátnia. Ez az Ügyfél hitelesítő adatainak megadása című témakörben látható.

Hitelesítő adatok értékei

A hitelesítő érték a szolgáltatás által használt tényleges hitelesítő adat. Miután megadta a hitelesítő adatokat, előfordulhat, hogy a szolgáltatást a tényleges hitelesítő adatokkal is konfigurálnia kell. Ha a Windowst választotta (és a szolgáltatás windowsos tartományban fog futni), akkor nem ad meg tényleges hitelesítő értéket.

Identitás

A WCF-ben az identitás kifejezésnek más jelentése van a kiszolgálóra és az ügyfélre vonatkozóan. Röviden, egy szolgáltatás futtatásakor a rendszer identitást rendel a biztonsági környezethez a hitelesítés után. A tényleges identitás megtekintéséhez ellenőrizze az WindowsIdentity osztály tulajdonságait és PrimaryIdentity tulajdonságait ServiceSecurityContext . További információ : Útmutató: A biztonsági környezet vizsgálata.

Ezzel szemben az ügyfélen az identitás a szolgáltatás ellenőrzésére szolgál. A tervezéskor az ügyfélfejlesztő beállíthatja az <identitáselemet> a szolgáltatásból beszerzett értékre. Futásidőben az ügyfél ellenőrzi az elem értékét a szolgáltatás tényleges identitása alapján. Ha az ellenőrzés sikertelen, az ügyfél megszakítja a kommunikációt. Az érték lehet egyszerű felhasználónév (UPN), ha a szolgáltatás egy adott felhasználó identitása vagy egyszerű szolgáltatásnév (SPN) alatt fut, ha a szolgáltatás gépfiók alatt fut. További információ: Szolgáltatás identitása és hitelesítése. A hitelesítő adatok lehetnek tanúsítvány vagy a tanúsítványt azonosító tanúsítványon található mező is.

Védelmi szintek

A ProtectionLevel tulajdonság több attribútumosztályban (például az és az ServiceContractAttributeOperationContractAttribute osztályokban) fordul elő. A védelmi szint egy érték, amely meghatározza, hogy a szolgáltatást támogató üzenetek (vagy üzenetrészek) aláírással, aláírással és titkosítással vannak-e aláírva, aláírva és titkosítva, illetve aláírás vagy titkosítás nélkül küldve. A tulajdonságról további információt a Védelmi szint ismertetése és a programozási példák című témakörben talál : Útmutató: A Védelmi szint tulajdonság beállítása. A szolgáltatási szerződés környezettel való tervezésével kapcsolatos további információkért lásd: ProtectionLevel Szolgáltatásszerződések tervezése.

Lásd még