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

Service Fabric-alkalmazás és szolgáltatásbiztonság

  • Cikk

A mikroszolgáltatás-architektúra számos előnnyel járhat. A mikroszolgáltatások biztonságának kezelése azonban kihívást jelent, és eltér a hagyományos monolitikus alkalmazások biztonságának kezelésétől.

Monolith esetén az alkalmazás általában egy vagy több kiszolgálón fut egy hálózaton belül, és könnyebb azonosítani a közzétett portokat és API-kat és IP-címeket. Gyakran van egy szegély vagy határ, valamint egy adatbázis, amelyet védeni kell. Ha a rendszer biztonsági incidens vagy támadás miatt sérül meg, valószínű, hogy a rendszeren belül minden elérhető lesz a támadó számára. A mikroszolgáltatások esetében a rendszer összetettebb. A szolgáltatások decentralizáltak és elosztottak számos gazdagépen, és gazdagépről gazdagépre migrálhatók. Megfelelő biztonsággal korlátozhatja azokat a jogosultságokat, amelyeket a támadók megkaphatnak, és az egyetlen támadásban elérhető adatok mennyiségét egyetlen szolgáltatás feltörésével. A kommunikáció nem belső, hanem hálózaton keresztül történik, és számos elérhető port és interakció van a szolgáltatások között. Az alkalmazás biztonsága szempontjából fontos tudni, hogy mik ezek a szolgáltatás-interakciók és mikor következnek be.

Ez a cikk nem útmutató a mikroszolgáltatások biztonságához, számos ilyen erőforrás érhető el az interneten, de leírja, hogyan valósíthatók meg a biztonság különböző aspektusai a Service Fabricben.

Authentication and authorization

Gyakran szükséges, hogy a szolgáltatás által közzétett erőforrások és API-k bizonyos megbízható felhasználókra vagy ügyfelekre korlátozódjanak. A hitelesítés a felhasználó identitásának megbízható megállapítására vonatkozó folyamat. Az engedélyezés az a folyamat, amely egyes hitelesített felhasználók számára elérhetővé teszi az API-kat vagy a szolgáltatásokat, mások számára azonban nem.

Authentication

Az API-szintű megbízhatósági döntések meghozatalának első lépése a hitelesítés. A hitelesítés a felhasználó identitásának megbízható megállapítására vonatkozó folyamat. Mikroszolgáltatási forgatókönyvekben a hitelesítést általában központilag kezelik. API-átjáró használata esetén ki lehet kapcsolni a hitelesítést az átjáróra. Ha ezt a módszert használja, győződjön meg arról, hogy az egyes szolgáltatások nem érhetőek el közvetlenül (az API Gateway nélkül), kivéve, ha további biztonság van érvényben az üzenetek hitelesítéséhez, függetlenül attól, hogy az átjáróból származnak-e.

Ha a szolgáltatások közvetlenül érhetők el, egy hitelesítési szolgáltatás, például a Microsoft Entra ID vagy egy biztonsági jogkivonat-szolgáltatásként (STS) működő dedikált hitelesítési mikroszolgáltatás használható a felhasználók hitelesítésére. A megbízhatósági döntéseket biztonsági jogkivonatokkal vagy cookie-kkal rendelkező szolgáltatások osztják meg.

A ASP.NET Core esetében a felhasználók hitelesítésének elsődleges mechanizmusa a ASP.NET Core Identity tagsági rendszere. ASP.NET Core Identity a fejlesztő által konfigurált adattárban tárolja a felhasználói adatokat (beleértve a bejelentkezési adatokat, a szerepköröket és a jogcímeket). ASP.NET Core Identity támogatja a kéttényezős hitelesítést. A külső hitelesítésszolgáltatók is támogatottak, így a felhasználók a meglévő hitelesítési folyamatokkal jelentkezhetnek be olyan szolgáltatóktól, mint a Microsoft, a Google, a Facebook vagy a Twitter.

Authorization

A hitelesítés után a szolgáltatásoknak engedélyeznie kell a felhasználói hozzáférést, vagy meg kell határozniuk, hogy mit tehet egy felhasználó. Ez a folyamat lehetővé teszi, hogy a szolgáltatás elérhetővé tegye az API-kat néhány hitelesített felhasználó számára, de nem mindenki számára. Az engedélyezés ortogonális és független a hitelesítéstől, amely annak megállapítására szolgáló folyamat, hogy ki a felhasználó. A hitelesítés egy vagy több identitást hozhat létre az aktuális felhasználó számára.

ASP.NET Alapszintű engedélyezés a felhasználók szerepkörei vagy egyéni szabályzatok alapján végezhető el, amelyek a jogcímek vagy egyéb heurisztika vizsgálatát is magukban foglalhatják.

Hozzáférés korlátozása és biztonságossá tétele API-átjáróval

A felhőalapú alkalmazásokhoz általában előtér-átjáró szükséges, amely egyetlen belépési pontként szolgálhat a felhasználók, eszközök és egyéb alkalmazások számára. Az API-átjáró az ügyfelek és a szolgáltatások között helyezkedik el, és az alkalmazás által nyújtott összes szolgáltatás belépési pontja. Fordított proxyként működik, az ügyfelektől a szolgáltatások felé irányuló kérések átirányítása. Emellett különböző horizontális feladatokat is elvégezhet, például hitelesítést és engedélyezést, TLS-lezárást és sebességkorlátozást. Ha nem helyez üzembe átjárót, az ügyfeleknek közvetlenül az előtérbeli szolgáltatásoknak kell küldenie a kéréseket.

A Service Fabricben az átjáró lehet bármilyen állapot nélküli szolgáltatás, például egy ASP.NET Core-alkalmazás vagy egy forgalomforgalom-forgalomra tervezett szolgáltatás, például a Traefik, az Event Hubs, az IoT Hub vagy az Azure API Management.

Az API Management közvetlenül integrálható a Service Fabric szolgáltatással, így számos útválasztási szabályt tartalmazó API-kat tehet közzé a háttérbeli Service Fabric-szolgáltatásokban. A háttérszolgáltatásokhoz való hozzáférést biztonságossá teheti, szabályozhatja a DOS-támadásokat, vagy ellenőrizheti az API-kulcsokat, JWT-jogkivonatokat, tanúsítványokat és egyéb hitelesítő adatokat. További információért olvassa el a Service Fabric és az Azure API Management áttekintését.

Titkos alkalmazáskulcsok kezelése

A titkos kulcsok lehetnek bizalmas információk, például tárolási kapcsolati sztring, jelszavak vagy más értékek, amelyeket nem szabad egyszerű szövegben kezelni. Ez a cikk az Azure Key Vault használatával kezeli a kulcsokat és titkos kulcsokat. A titkos kódok alkalmazásbeli használata azonban felhőalapú platformfüggetlen, így lehetővé teszi az alkalmazások üzembe helyezését egy bárhol üzemeltetett fürtön.

A szolgáltatáskonfigurációs beállítások kezelésének ajánlott módja a szolgáltatáskonfigurációs csomagokon keresztül történik. A konfigurációs csomagok verziószámozottak és frissíthetők felügyelt gördülő frissítésekkel, állapot-ellenőrzéssel és automatikus visszaállítással. Ez előnyben részesíti a globális konfigurációt, mivel csökkenti a globális szolgáltatáskimaradás esélyét. A titkosított titkos kódok nem kivételek. A Service Fabric beépített funkciókkal rendelkezik egy konfigurációs csomag értékeinek titkosításához és visszafejtéséhez Gépház.xml fájlban tanúsítványtitkosítással.

Az alábbi ábra egy Service Fabric-alkalmazás titkos kulcskezelésének alapfolyamatát mutatja be:

secret management overview

A folyamat négy fő lépésből áll:

  1. Szerezze be az adatfelfedési tanúsítványt.
  2. Telepítse a tanúsítványt a fürtben.
  3. Titkos értékek titkosítása egy alkalmazás tanúsítványsal való üzembe helyezésekor, majd a szolgáltatás Gépház.xml konfigurációs fájljába való injektálásakor.
  4. A titkosított értékeket az Gépház.xml fájlból olvashatja be ugyanazzal a titkosítási tanúsítvánnyal való visszafejtéssel.

Az Azure Key Vault a tanúsítványok biztonságos tárolási helyeként és a tanúsítványok Azure-beli Service Fabric-fürtökön való telepítésének módjaként szolgál. Ha nem az Azure-ban telepít, a Key Vault használatával nem kell titkos kulcsokat kezelnie a Service Fabric-alkalmazásokban.

Példa: Alkalmazás titkos kulcsainak kezelése.

Az üzemeltetési környezet védelme

Az Azure Service Fabric használatával biztonságossá teheti a fürtön futó alkalmazásokat különböző felhasználói fiókokban. A Service Fabric emellett segít az alkalmazások által az üzembe helyezéskor használt erőforrások védelmében a felhasználói fiókok alatt– például fájlok, könyvtárak és tanúsítványok. Ez még megosztott üzemeltetett környezetben is biztonságosabbá teszi az alkalmazások egymástól való futtatását.

Az alkalmazásjegyzék deklarálja a szolgáltatás(ok) futtatásához és az erőforrások biztonságossá tételéhez szükséges biztonsági tagokat (felhasználókat és csoportokat). Ezekre a biztonsági tagokra a szabályzatok hivatkoznak, például a futtatókörnyezetre, a végpontkötésre, a csomagmegosztásra vagy a biztonsági hozzáférési szabályzatokra. A szabályzatok ezután az alkalmazásjegyzék ServiceManifestImport szakaszában lesznek alkalmazva a szolgáltatáserőforrásokra.

Az egyszerű felhasználók deklarálásakor felhasználói csoportokat is definiálhat és hozhat létre, hogy egy vagy több felhasználót lehessen hozzáadni az egyes csoportokhoz, amelyeket együtt kell felügyelni. Ez akkor hasznos, ha több felhasználó is van a különböző szolgáltatásbeléptetési pontokhoz, és bizonyos közös jogosultságokkal kell rendelkezniük, amelyek a csoport szintjén érhetők el.

Alapértelmezés szerint a Service Fabric-alkalmazások azon a fiókon futnak, amelyen a Fabric.exe folyamat fut. A Service Fabric azt is lehetővé teszi, hogy az alkalmazásokat helyi felhasználói fiók vagy helyi rendszerfiók alatt futtassa, amely az alkalmazásjegyzékben van megadva. További információ: Szolgáltatás futtatása helyi felhasználói fiókként vagy helyi rendszerfiókként. A szolgáltatásindítási szkriptet helyi felhasználóként vagy rendszerfiókként is futtathatja.

Ha a Service Fabricet önálló Windows-fürtön futtatja, a szolgáltatást Active Directory tartományi fiókok vagy csoportosan felügyelt szolgáltatásfiókok alatt futtathatja.

Biztonságos tárolók

A Service Fabric egy olyan mechanizmust biztosít, amellyel a tárolón belüli szolgáltatások hozzáférhetnek egy Windows- vagy Linux-fürt csomópontjaira telepített tanúsítványhoz (5.7-es vagy újabb verzió). Ez a PFX-tanúsítvány használható az alkalmazás vagy szolgáltatás hitelesítéséhez vagy más szolgáltatásokkal való biztonságos kommunikációhoz. További információ: Tanúsítvány importálása tárolóba.

A Service Fabric emellett támogatja a gMSA-t (csoportos felügyelt szolgáltatásfiókokat) a Windows-tárolókhoz. További információ: GMSA beállítása Windows-tárolókhoz.

Biztonságos szolgáltatáskommunikáció

A Service Fabricben egy szolgáltatás valahol egy Service Fabric-fürtben fut, amely általában több virtuális gép között oszlik meg. A Service Fabric számos lehetőséget kínál a szolgáltatáskommunikáció védelmére.

A HTTPS-végpontokat a ASP.NET Core- vagy Java-webszolgáltatásokban engedélyezheti.

Biztonságos kapcsolatot létesíthet a fordított proxy és a szolgáltatások között, így lehetővé téve a végpontok közötti biztonságos csatornát. Csatlakozás biztonságos szolgáltatások csak akkor támogatottak, ha a fordított proxy a HTTPS figyelésére van konfigurálva. A fordított proxy konfigurálásával kapcsolatos információkért olvassa el a Fordított proxyt az Azure Service Fabricben. Csatlakozás egy biztonságos szolgáltatáshoz, amely leírja, hogyan hozható létre biztonságos kapcsolat a fordított proxy és a szolgáltatások között.

A Reliable Services alkalmazás keretrendszere néhány előre összeállított kommunikációs vermet és eszközt biztosít, amelyekkel javíthatja a biztonságot. Megtudhatja, hogyan javíthatja a biztonságot szolgáltatásátírás (C# vagy Java nyelven) vagy WCF használata esetén.

Végponttanúsítvány belefoglalása a Service Fabric-alkalmazásokba

Az alkalmazásvégpont-tanúsítvány konfigurálásához adja hozzá a tanúsítványt úgy, hogy hozzáad egy EndpointCertificate elemet az egyszerű fiók Felhasználói elemével együtt az alkalmazásjegyzékhez. Alapértelmezés szerint az egyszerű fiók a NetworkService. Ez biztosítja az alkalmazástanúsítvány titkos kulcsának ACL-jének kezelését a megadott tag számára.

<ApplicationManifest … >
  ...
  <Principals>
    <Users>
      <User Name="Service1" AccountType="NetworkService" />
    </Users>
  </Principals>
  <Certificates>
    <EndpointCertificate Name="MyCert" X509FindType="FindByThumbprint" X509FindValue="[YourCertThumbprint]"/>
  </Certificates>
</ApplicationManifest>

Alkalmazásadatok titkosítása inaktív állapotban

Az Azure-ban futó Service Fabric-fürtök mindegyik csomóponttípusa egy virtuálisgép-skálázási csoporton alapul. Egy Azure Resource Manager-sablonnal adatlemezeket csatlakoztathat a Service Fabric-fürtöt alkotó méretezési csoport(ok)hoz. Ha a szolgáltatások adatokat mentenek egy csatolt adatlemezre, titkosíthatja ezeket az adatlemezeket az alkalmazásadatok védelme érdekében.

Következő lépések