Biztonsági keret: Hitelesítés | Enyhítése

Termék/szolgáltatás Cikk
Webalkalmazás
Adatbázis
Azure Event Hub
Azure-megbízhatósági határ
Service Fabric megbízhatósági határa
Identitáskiszolgáló
Gép megbízhatósági határa
WCF
Webes API
Microsoft Entra-azonosító
IoT-mezőátjáró
IoT Cloud Gateway
Azure Storage

Fontolja meg egy szabványos hitelesítési mechanizmus használatát a webalkalmazásban való hitelesítéshez

Cím Részletek
Komponens Webalkalmazás
SDL-fázis Építés
Alkalmazható technológiák Általános
Attribútumok n/a
Hivatkozások n/a
Részletek

A hitelesítés az a folyamat, amelyben az entitások általában hitelesítő adatokkal, például felhasználónévvel és jelszóval bizonyítják az identitásukat. Több hitelesítési protokoll is elérhető, amelyek megfontolhatók. Ezek közül néhány az alábbiakban látható:

  • Ügyféltanúsítványok
  • Windows-alapú
  • Űrlapok alapján
  • Szövetség – ADFS
  • Szövetség – Microsoft Entra ID
  • Összevonás – Identitáskiszolgáló

Fontolja meg egy szabványos hitelesítési mechanizmus használatát a forrásfolyamat azonosításához

Az alkalmazásoknak biztonságosan kell kezelnie a sikertelen hitelesítési forgatókönyveket

Cím Részletek
Komponens Webalkalmazás
SDL-fázis Építés
Alkalmazható technológiák Általános
Attribútumok n/a
Hivatkozások n/a
Részletek

A felhasználókat explicit módon hitelesítő alkalmazásoknak biztonságosan kell kezelnie a sikertelen hitelesítési forgatókönyveket. A hitelesítési mechanizmusnak a következőnek kell lennie:

  • Jogosultsági erőforrásokhoz való hozzáférés megtagadása sikertelen hitelesítés esetén
  • Általános hibaüzenet megjelenítése a sikertelen hitelesítés és a hozzáférés megtagadása után

Teszt a következőhöz:

  • Kiemelt erőforrások védelme sikertelen bejelentkezések után
  • Általános hibaüzenet jelenik meg a sikertelen hitelesítés és a hozzáférés megtagadása esemény(ek) esetén
  • A fiókok a sikertelen kísérletek túlzott száma után le vannak tiltva

    Lépésenkénti vagy adaptív hitelesítés engedélyezése

    Cím Részletek
    Komponens Webalkalmazás
    SDL-fázis Építés
    Alkalmazható technológiák Általános
    Attribútumok n/a
    Hivatkozások n/a
    Részletek

    Ellenőrizze, hogy az alkalmazás rendelkezik-e további hitelesítéssel (például a többtényezős hitelesítéssel, például az OTP SMS-ben való küldésével, e-mailben stb.), hogy a felhasználót a bizalmas adatokhoz való hozzáférés engedélyezése előtt megtámadják. Ez a szabály egy fiók vagy művelet kritikus módosítására is vonatkozik

    Ez azt is jelenti, hogy a hitelesítés kiigazítását oly módon kell végrehajtani, hogy az alkalmazás megfelelően kényszerítse ki a környezetfüggő engedélyezést, hogy ne engedélyezze a jogosulatlan manipulációt például a paraméterek illetéktelen megváltoztatásával

    Győződjön meg arról, hogy a felügyeleti felületek megfelelően zárolva vannak

    Cím Részletek
    Komponens Webalkalmazás
    SDL-fázis Építés
    Alkalmazható technológiák Általános
    Attribútumok n/a
    Hivatkozások n/a
    Részletek Az első megoldás az, hogy csak egy adott forrás IP-címtartományból biztosít hozzáférést a felügyeleti felületnek. Ha ez a megoldás nem lenne lehetséges, akkor mindig ajánlott egy lépésenkénti vagy adaptív hitelesítést kényszeríteni a felügyeleti felületre való bejelentkezéshez

    Elfelejtett jelszófunkciók biztonságos implementálása

    Cím Részletek
    Komponens Webalkalmazás
    SDL-fázis Építés
    Alkalmazható technológiák Általános
    Attribútumok n/a
    Hivatkozások n/a
    Részletek

    Az első dolog az, hogy ellenőrizze, hogy az elfelejtett jelszó és más helyreállítási útvonalak egy hivatkozást küldenek, amely magában a jelszó helyett egy korlátozott ideig érvényes aktiválási jogkivonatot tartalmaz. A helyreállítható jogkivonatokon (például SMS-jogkivonaton, natív mobilalkalmazásokon stb.) alapuló további hitelesítésre is szükség lehet a hivatkozás elküldése előtt. Másodszor, nem szabad zárolnia a felhasználói fiókot, amíg az új jelszó lekérésének folyamata folyamatban van.

    Ez szolgáltatásmegtagadási támadáshoz vezethet, amikor egy támadó úgy dönt, hogy szándékosan zárolja a felhasználókat egy automatikus támadással. Harmadszor, amikor az új jelszókérés be lett állítva, a megjelenő üzenetet általánosítva kell megadni a felhasználónév számbavételének megakadályozása érdekében. Negyedszer, mindig tiltsa le a régi jelszavak használatát, és alkalmazzon erős jelszóházirendet.

    Győződjön meg arról, hogy a jelszó- és fiókszabályzat implementálva van

    Cím Részletek
    Komponens Webalkalmazás
    SDL-fázis Építés
    Alkalmazható technológiák Általános
    Attribútumok n/a
    Hivatkozások n/a
    Részletek

    A jelszó- és fiókszabályzatot a szervezeti szabályzatnak és az ajánlott eljárásoknak megfelelően kell megvalósítani.

    A találgatásos és szótáralapú találgatások elleni védelem érdekében: Erős jelszóházirendet kell alkalmazni annak biztosítása érdekében, hogy a felhasználók összetett jelszót hozzanak létre (pl. 12 karakter minimális hossz, alfanumerikus és speciális karakterek).

    A fiókzárolási szabályzatok a következő módon implementálhatók:

    • Lágy kizárás: Ez jó megoldás lehet a felhasználók találgatásos támadásokkal szembeni védelmére. Ha például a felhasználó háromszor ad meg hibás jelszót, az alkalmazás egy percre zárolhatja a fiókot, hogy lelassítsa a jelszó kényszerítésének folyamatát, így a támadó számára kevésbé jövedelmező a folytatás. Ha ehhez a példához kemény kizárási ellenintézkedéseket szeretne megvalósítani, akkor a fiókok végleges zárolásával "DoS"-t érhetne el. Másik lehetőségként előfordulhat, hogy az alkalmazás létrehoz egy OTP-t (egyszeri jelszó), és sávon kívül (e-mailben, SMS-ben stb.) küldi el a felhasználónak. Egy másik megközelítés a CAPTCHA implementálása a sikertelen kísérletek küszöbértékének elérése után.
    • Kemény zárolás: Ezt a zárolási típust akkor kell alkalmazni, amikor észlel egy felhasználót, aki megtámadja az alkalmazást, és ellenük lép fel azzal, hogy véglegesen zárolja a fiókját, amíg a válaszcsapatnak nem volt ideje elvégezni a kriminalisztikai műveleteket. A folyamat után dönthet úgy, hogy visszaadja a felhasználónak a fiókját, vagy további jogi lépéseket tesz ellenük. Ez a módszer megakadályozza, hogy a támadó tovább behatoljon az alkalmazásba és az infrastruktúrába.

    Az alapértelmezett és kiszámítható fiókok elleni védelem érdekében ellenőrizze, hogy az összes kulcs és jelszó lecserélhető-e, és a telepítés után létrejön vagy lecserélődik.

    Ha az alkalmazásnak automatikusan létre kell hoznia jelszavakat, győződjön meg arról, hogy a létrehozott jelszavak véletlenszerűek, és nagy entrópiával rendelkeznek.

    Vezérlők implementálása a felhasználónevek számbavételének megakadályozásához

    Cím Részletek
    Komponens Webalkalmazás
    SDL-fázis Építés
    Alkalmazható technológiák Általános
    Attribútumok n/a
    Hivatkozások n/a
    Lépések A felhasználónevek számbavételének megakadályozása érdekében minden hibaüzenetet általánosítottnak kell lennie. Emellett néha nem kerülheti el, hogy az információk kiszivárognak az olyan funkciókban, mint a regisztrációs oldal. Itt olyan sebességkorlátozó módszereket kell használnia, mint a CAPTCHA, hogy megelőzze a támadók automatikus támadását.

    Ha lehetséges, használja a Windows-hitelesítést az SQL Serverhez való csatlakozáshoz

    Cím Részletek
    Komponens Adatbázis
    SDL-fázis Építés
    Alkalmazható technológiák Helyszíni
    Attribútumok SQL-verzió – Minden
    Hivatkozások SQL Server – Hitelesítési mód kiválasztása
    Lépések A Windows-hitelesítés Kerberos biztonsági protokollt használ, jelszóházirend-kényszerítéseket biztosít az erős jelszavak összetettségének ellenőrzése tekintetében, támogatja a fiókzárolást, és támogatja a jelszó lejáratát.

    Ha lehetséges, használja a Microsoft Entra-hitelesítést az SQL Database-hez való csatlakozáshoz

    Cím Részletek
    Komponens Adatbázis
    SDL-fázis Építés
    Alkalmazható technológiák SQL Azure
    Attribútumok SQL-verzió – V12
    Hivatkozások Csatlakozás az SQL Database-hez Microsoft Entra-hitelesítéssel
    Lépések Minimális verzió: Azure SQL Database V12 szükséges ahhoz, hogy az Azure SQL Database Microsoft Entra-hitelesítést használhasson a Microsoft Directoryval

    SQL-hitelesítési mód használata esetén győződjön meg arról, hogy a fiók- és jelszóházirend kényszerítve van az SQL Serveren

    Cím Részletek
    Komponens Adatbázis
    SDL-fázis Építés
    Alkalmazható technológiák Általános
    Attribútumok n/a
    Hivatkozások SQL Server jelszóházirend
    Lépések AZ SQL Server-hitelesítés használatakor a bejelentkezések olyan SQL Serveren jönnek létre, amelyek nem Windows-felhasználói fiókokon alapulnak. A felhasználónév és a jelszó is az SQL Server használatával jön létre, és az SQL Serverben van tárolva. Az SQL Server használhatja a Windows jelszó házirend mechanizmusait. Ugyanezeket az összetettségi és lejárati szabályzatokat alkalmazhatja a Windowsban az SQL Serveren belül használt jelszavakra.

    Ne használja az SQL-hitelesítést egyben lévő adatbázisokban

    Cím Részletek
    Komponens Adatbázis
    SDL-fázis Építés
    Alkalmazható technológiák Helyszíni, SQL Azure
    Attribútumok SQL-verzió – MSSQL2012, SQL-verzió – V12
    Hivatkozások Ajánlott biztonsági eljárások a tartalmazott adatbázisokkal
    Lépések A kényszerített jelszóházirend hiánya növelheti annak valószínűségét, hogy gyenge hitelesítő adatokat hoz létre egy tárolt adatbázisban. Használja a Windows-hitelesítést.

    Eszközalapú hitelesítési adatok használata SaS-jogkivonatokkal

    Cím Részletek
    Komponens Azure Event Hubs
    SDL-fázis Építés
    Alkalmazható technológiák Általános
    Attribútumok n/a
    Hivatkozások Az Event Hubs-hitelesítés és a biztonsági modell áttekintése
    Lépések

    Az Event Hubs biztonsági modellje a közös hozzáférésű jogosultságkódok (SAS) jogkivonatainak és az eseménykiadóknak a kombinációján alapul. A közzétevő neve a jogkivonatot fogadó DeviceID azonosítót jelöli. Ez segít társítani a létrehozott tokeneket a megfelelő eszközökkel.

    A szolgáltatásoldalon minden üzenet küldő féllel van megjelölve, amely lehetővé teszi az adatcsomagban lévő forráshamisítási kísérletek észlelését. Az eszközök hitelesítésekor hozzon létre egy eszközenkénti SaS-jogkivonatot, amely egy egyedi közzétevőre terjed ki.

    Többtényezős Microsoft Entra-hitelesítés engedélyezése Azure-rendszergazdák számára

    Cím Részletek
    Komponens Azure megbízhatósági határvonal
    SDL-fázis Telepítés
    Alkalmazható technológiák Általános
    Attribútumok n/a
    Hivatkozások Mi a Microsoft Entra többtényezős hitelesítés?
    Lépések

    A többtényezős hitelesítés (MFA) egy olyan hitelesítési módszer, amely több ellenőrzési módszert igényel, és kritikus második biztonsági réteget ad hozzá a felhasználói bejelentkezésekhez és tranzakciókhoz. A következő ellenőrzési módszerek bármelyikének megkövetelésével működik:

    • Valami, amit tud (általában jelszó)
    • Valami, amellyel rendelkezik (egy megbízható eszköz, amely nem könnyen duplikálható, például egy telefon)
    • Valami, ami vagy (biometrikus adatok)

      A Service Fabric-fürthöz való névtelen hozzáférés korlátozása

      Cím Részletek
      Komponens A Service Fabric megbízhatósági határa
      SDL-fázis Telepítés
      Alkalmazható technológiák Általános
      Attribútumok Környezet – Azure
      Hivatkozások Service Fabric fürtbiztonsági forgatókönyvei
      Lépések

      A fürtök védelmét mindig biztosítani kell, hogy illetéktelen felhasználók ne csatlakozzanak a fürthöz, különösen akkor, ha éles munkaterhelés fut rajta.

      Service Fabric-fürt létrehozásakor győződjön meg arról, hogy a biztonsági mód "biztonságos" értékre van állítva, és konfigurálja a szükséges X.509 kiszolgálói tanúsítványt. A "nem biztonságos" fürt létrehozása lehetővé teszi, hogy bármely névtelen felhasználó csatlakozzon hozzá, ha felügyeleti végpontokat tesz elérhetővé a nyilvános interneten.

      Győződjön meg arról, hogy a Service Fabric ügyfél–csomópont tanúsítványa eltér a csomópontok közötti tanúsítványtól

      Cím Részletek
      Komponens A Service Fabric megbízhatósági határa
      SDL-fázis Telepítés
      Alkalmazható technológiák Általános
      Attribútumok Környezet – Azure, Környezet – Önálló
      Hivatkozások Service Fabric Ügyfél–csomópont tanúsítványbiztonság, Csatlakozás biztonságos fürthöz ügyféltanúsítvány használatával
      Lépések

      Az ügyfél-csomópont tanúsítványbiztonsága a fürt létrehozásakor konfigurálva van az Azure Portalon, a Resource Manager-sablonokon vagy egy különálló JSON-sablonon keresztül egy rendszergazdai ügyféltanúsítvány és/vagy egy felhasználói ügyféltanúsítvány megadásával.

      A megadott rendszergazdai ügyfél- és felhasználói ügyféltanúsítványoknak különböznie kell a csomópontok között történő biztonsághoz megadott elsődleges és másodlagos tanúsítványoktól.

      A Microsoft Entra ID használatával hitelesítheti az ügyfeleket a service fabric-fürtökben

      Cím Részletek
      Komponens A Service Fabric megbízhatósági határa
      SDL-fázis Telepítés
      Alkalmazható technológiák Általános
      Attribútumok Környezet – Azure
      Hivatkozások Fürtbiztonsági forgatókönyvek – Biztonsági javaslatok
      Lépések Az Azure-on futó fürtök az ügyféltanúsítványok mellett a Microsoft Entra ID használatával is biztosíthatják a felügyeleti végpontokhoz való hozzáférést. Azure-fürtök esetén ajánlott a Microsoft Entra security használatával hitelesíteni az ügyfeleket és a tanúsítványokat a csomópontok közötti biztonság érdekében.

      Győződjön meg arról, hogy a Service Fabric-tanúsítványok egy jóváhagyott hitelesítésszolgáltatótól (CA) származnak

      Cím Részletek
      Komponens A Service Fabric megbízhatósági határa
      SDL-fázis Telepítés
      Alkalmazható technológiák Általános
      Attribútumok Környezet – Azure
      Hivatkozások X.509-tanúsítványok és Service Fabric
      Lépések

      A Service Fabric X.509-kiszolgálótanúsítványokat használ a csomópontok és ügyfelek hitelesítéséhez.

      Néhány fontos dolog, amit érdemes megfontolni a tanúsítványok szolgáltatáshálókban való használata során:

      • Az éles számítási feladatokat futtató fürtökben használt tanúsítványokat megfelelően konfigurált Windows Server tanúsítványszolgáltatással vagy jóváhagyott hitelesítésszolgáltatótól (CA) kell létrehozni. A hitelesítésszolgáltató lehet jóváhagyott külső hitelesítésszolgáltató vagy megfelelően felügyelt belső nyilvános kulcsú infrastruktúra (PKI)
      • Soha ne használjon olyan ideiglenes vagy teszttanúsítványokat éles környezetben, amelyek olyan eszközökkel lettek létrehozva, mint a MakeCert.exe
      • Használhat önaláírt tanúsítványt, de csak tesztfürtök esetén, éles környezetben nem.

      Az Identity Server által támogatott standard hitelesítési forgatókönyvek használata

      Cím Részletek
      Komponens Identitáskiszolgáló
      SDL-fázis Építés
      Alkalmazható technológiák Általános
      Attribútumok n/a
      Hivatkozások n/a
      Lépések

      Az alábbiakban az Identity Server által támogatott tipikus interakciókat találja:

      • A böngészők kommunikálnak a webalkalmazásokkal
      • A webalkalmazások webes API-kkal kommunikálnak (néha önállóan, néha egy felhasználó nevében)
      • Böngészőalapú alkalmazások kommunikálnak a webes API-kkal
      • Natív alkalmazások kommunikálnak a webes API-kkal
      • A kiszolgálóalapú alkalmazások webes API-kkal kommunikálnak
      • A webes API-k kommunikálnak a webes API-kkal (néha önállóan, néha egy felhasználó nevében)

      Az alapértelmezett Identity Server-jogkivonat gyorsítótárának felülbírálása skálázható alternatívával

      Cím Részletek
      Komponens Identitáskiszolgáló
      SDL-fázis Telepítés
      Alkalmazható technológiák Általános
      Attribútumok n/a
      Hivatkozások n/a
      Lépések

      Az IdentityServer egy egyszerű beépített memóriabeli gyorsítótárral rendelkezik. Bár ez a kis léptékű natív alkalmazások esetében hasznos, a középszintű és háttéralkalmazások esetében nem skálázható a következő okok miatt:

      • Ezeket az alkalmazásokat egyszerre sok felhasználó érheti el. Ha az összes hozzáférési jogkivonatot ugyanabban az áruházban menti, elkülönítési problémákat okoz, és kihívást jelent a nagy léptékű működés során: sok felhasználó, amelyek mindegyike annyi jogkivonattal rendelkezik, mint az alkalmazás által a nevükben elért erőforrások, hatalmas számokat és nagyon költséges keresési műveleteket jelenthet.
      • Ezeket az alkalmazásokat általában elosztott topológiákon helyezik üzembe, ahol több csomópontnak is hozzá kell férnie ugyanahhoz a gyorsítótárhoz
      • A gyorsítótárazott jogkivonatoknak túl kell élnie a folyamat-újrahasznosításokat és -inaktiválásokat
      • A fenti okok miatt a webalkalmazások implementálása során ajánlott felülírni az alapértelmezett Identity Server token-gyorsítótárát egy méretezhető alternatívával, például az Azure Managed Redis-szel.

      Győződjön meg arról, hogy az üzembe helyezett alkalmazás bináris fájljai digitálisan aláírtak

      Cím Részletek
      Komponens Gép megbízhatósági határa
      SDL-fázis Telepítés
      Alkalmazható technológiák Általános
      Attribútumok n/a
      Hivatkozások n/a
      Lépések Győződjön meg arról, hogy az üzembe helyezett alkalmazás bináris fájljai digitálisan vannak aláírva, hogy a bináris fájlok integritása ellenőrizhető legyen

      Hitelesítés engedélyezése MSMQ-üzenetsorokhoz való csatlakozáskor a WCF-ben

      Cím Részletek
      Komponens WCF
      SDL-fázis Építés
      Alkalmazható technológiák Általános, NET-keretrendszer 3
      Attribútumok n/a
      Hivatkozások MSDN
      Lépések A program nem engedélyezi a hitelesítést az MSMQ-üzenetsorokhoz való csatlakozáskor, a támadók névtelenül küldhetnek üzeneteket az üzenetsorba feldolgozás céljából. Ha a hitelesítés nem egy MSMQ-üzenetsorhoz való csatlakozásra szolgál, amely egy üzenet egy másik programnak való továbbítására szolgál, a támadók névtelen, rosszindulatú üzenetet küldhetnek.

      Példa

      Az <netMsmqBinding/> alábbi WCF-konfigurációs fájl eleme arra utasítja a WCF-et, hogy tiltsa le a hitelesítést, amikor msMQ-üzenetsorhoz csatlakozik üzenetkézbesítés céljából.

      <bindings>
    <netMsmqBinding>
        <binding>
            <security>
                <transport msmqAuthenticationMode=""None"" />
            </security>
        </binding>
    </netMsmqBinding>
</bindings>

      Konfigurálja az MSMQ-t úgy, hogy a bejövő vagy kimenő üzenetekhez mindig Windows-tartomány- vagy tanúsítványhitelesítést igényeljen.

      Példa

      Az <netMsmqBinding/> alábbi WCF-konfigurációs fájl eleme arra utasítja a WCF-et, hogy engedélyezze a tanúsítványhitelesítést az MSMQ-üzenetsorhoz való csatlakozáskor. Az ügyfél hitelesítése X.509-tanúsítványokkal történik. Az ügyféltanúsítványnak szerepelnie kell a kiszolgáló tanúsítványtárolójában.

      <bindings>
    <netMsmqBinding>
        <binding>
            <security>
                <transport msmqAuthenticationMode=""Certificate"" />
            </security>
        </binding>
    </netMsmqBinding>
</bindings>

      WCF - Ne állítsa az Message clientCredentialType értékét nincsre

      Cím Részletek
      Komponens WCF
      SDL-fázis Építés
      Alkalmazható technológiák .NET-keretrendszer 3
      Attribútumok Ügyfél hitelesítő adatainak típusa – Nincs
      Hivatkozások MSDN,Fortify
      Lépések A hitelesítés hiánya azt jelenti, hogy mindenki hozzáférhet ehhez a szolgáltatáshoz. Egy olyan szolgáltatás, amely nem hitelesíti az ügyfeleit, lehetővé teszi az összes felhasználó elérését. Konfigurálja az alkalmazást az ügyfél hitelesítő adataival való hitelesítéshez. Ezt úgy teheti meg, hogy a clientCredentialType üzenetet Windows vagy Tanúsítvány értékre állítja.

      Példa

      <message clientCredentialType=""Certificate""/>

      WCF-Ne állítsa a Transport clientCredentialType értékét "none"-ra.

      Cím Részletek
      Komponens WCF
      SDL-fázis Építés
      Alkalmazható technológiák Általános, .NET-keretrendszer 3
      Attribútumok Ügyfél hitelesítő adatainak típusa – Nincs
      Hivatkozások MSDN,Fortify
      Lépések A hitelesítés hiánya azt jelenti, hogy mindenki hozzáférhet ehhez a szolgáltatáshoz. Egy olyan szolgáltatás, amely nem hitelesíti az ügyfeleit, lehetővé teszi, hogy minden felhasználó hozzáférjen a funkcióihoz. Konfigurálja az alkalmazást az ügyfél hitelesítő adataival való hitelesítéshez. Ezt úgy teheti meg, hogy a clientCredentialType beállítását Windowsra vagy tanúsítványra állítja.

      Példa

      <transport clientCredentialType=""Certificate""/>

      Győződjön meg arról, hogy a webes API-k védelméhez szabványos hitelesítési technikákat használnak

      Cím Részletek
      Komponens Webes API
      SDL-fázis Építés
      Alkalmazható technológiák Általános
      Attribútumok n/a
      Hivatkozások Hitelesítés és engedélyezés ASP.NET Webes API-ban, külső hitelesítési szolgáltatások ASP.NET Webes API-val (C#)
      Lépések

      A hitelesítés az a folyamat, amelyben az entitások általában hitelesítő adatokkal, például felhasználónévvel és jelszóval bizonyítják az identitásukat. Több hitelesítési protokoll is elérhető, amelyek megfontolhatók. Ezek közül néhány az alábbiakban látható:

      • Ügyféltanúsítványok
      • Windows-alapú
      • Űrlapok alapján
      • Szövetség – ADFS
      • Szövetség – Microsoft Entra ID
      • Összevonás – Identitáskiszolgáló

      A hivatkozások szakaszban található hivatkozások alacsony szintű részleteket tartalmaznak arról, hogy az egyes hitelesítési sémák hogyan implementálhatók a webes API-k védelme érdekében.

      A Microsoft Entra ID által támogatott standard hitelesítési forgatókönyvek használata

      Cím Részletek
      Komponens Microsoft Entra ID
      SDL-fázis Építés
      Alkalmazható technológiák Általános
      Attribútumok n/a
      Hivatkozások Hitelesítési forgatókönyvek a Microsoft Entra-azonosítóhoz, Microsoft Entra-kódminták, Microsoft Entra fejlesztői útmutató
      Lépések

      A Microsoft Entra ID leegyszerűsíti a fejlesztők hitelesítését azáltal, hogy szolgáltatásként biztosítja az identitást, és támogatja az olyan iparági szabványoknak megfelelő protokollokat, mint az OAuth 2.0 és az OpenID Connect. Az alábbiakban a Microsoft Entra ID által támogatott öt elsődleges alkalmazásforgatókönyvet találja:

      • Webböngészőből webalkalmazásba: A felhasználónak be kell jelentkeznie egy olyan webalkalmazásba, amelyet a Microsoft Entra ID véd
      • Egyoldalas alkalmazás (SPA): A felhasználónak be kell jelentkeznie egy olyan egyoldalas alkalmazásba, amelyet a Microsoft Entra-azonosító biztosít
      • Natív alkalmazás a webes API-ba: A telefonon, táblagépen vagy PC-n futó natív alkalmazásnak hitelesítenie kell a felhasználót, hogy erőforrásokat szerezzen be a Microsoft Entra ID által védett webes API-ból
      • Webalkalmazás a Web API-ba: A webalkalmazásnak erőforrásokat kell lekérnie a Microsoft Entra ID által védett webes API-ból
      • Démon- vagy kiszolgálóalkalmazás webes API-hoz: Egy démonalkalmazásnak vagy egy webes felhasználói felület nélküli kiszolgálóalkalmazásnak erőforrásokat kell beszereznie egy Microsoft Entra-azonosítóval védett webes API-ból

      Az alacsony szintű megvalósítás részleteiért tekintse meg a hivatkozások szakaszban található hivatkozásokat.

      Az alapértelmezett MSAL-jogkivonat gyorsítótárának felülbírálása elosztott gyorsítótárral

      Cím Részletek
      Komponens Microsoft Entra ID
      SDL-fázis Építés
      Alkalmazható technológiák Általános
      Attribútumok n/a
      Hivatkozások Token gyorsítótár szerializálása az MSAL.NET-ben
      Lépések

      Az MSAL (Microsoft Authentication Library) által használt alapértelmezett gyorsítótár egy memóriabeli gyorsítótár, és méretezhető. Bár különböző lehetőségek állnak rendelkezésre, amelyeket alternatívaként használhat, például elosztott token gyorsítótárat. Ezek L1/L2 mechanizmusokkal rendelkeznek, ahol az L1 a memóriában, az L2 pedig az elosztott gyorsítótár implementációja. Ezek ennek megfelelően konfigurálhatók az L1 memória korlátozására, a titkosításra vagy a kizárási szabályzatok beállítására. Egyéb alternatív megoldások például a Redis, az SQL Server vagy az Azure Cosmos DB-gyorsítótárak. Az elosztott jogkivonat-gyorsítótár implementációja a következő oktatóanyagban található: Első lépések ASP.NET Core MVC-vel.

      Győződjön meg arról, hogy a TokenReplayCache az MSAL-hitelesítési jogkivonatok visszajátszásának megakadályozására szolgál

      Cím Részletek
      Komponens Microsoft Entra ID
      SDL-fázis Építés
      Alkalmazható technológiák Általános
      Attribútumok n/a
      Hivatkozások Modern hitelesítés a Microsoft Entra-azonosítóval webalkalmazásokhoz
      Lépések

      A TokenReplayCache tulajdonság lehetővé teszi a fejlesztők számára, hogy beállítsanak egy token-visszajátszási gyorsítótárat, ami egy olyan tároló, amely tokenteket képes menteni annak érdekében, hogy ellenőrizhető legyen: egyetlen token sem használható fel többször.

      Ez egy gyakori támadás elleni intézkedés, az úgynevezett token visszajátszási támadás ellen: a bejelentkezéskor küldött jogkivonatot elfogó támadó megpróbálhatja újra elküldeni azt az alkalmazásnak, hogy ezzel új munkamenetet hozzon létre. Például az OIDC kódátadási folyamatában a sikeres felhasználói hitelesítés után a függő entitás "/signin-oidc" végpontjára irányuló kérés "id_token", "code" és "state" paraméterekkel történik.

      A függő entitás ellenőrzi ezt a kérést, és létrehoz egy új munkamenetet. Ha egy támadó rögzíti ezt a kérést, és visszajátssza azt, létrehozhat egy sikeres munkamenetet, és meghamisítást végezhet a felhasználóval. A nonce jelenléte az OpenID Connectben korlátozhatja, de nem szüntetheti meg teljesen a támadás sikeres végrehajtása körülményeit. Az alkalmazások védelme érdekében a fejlesztők biztosíthatják az ITokenReplayCache implementációját, és hozzárendelhetnek egy példányt a TokenReplayCache-hez.

      Példa

      // ITokenReplayCache defined in MSAL
public interface ITokenReplayCache
{
bool TryAdd(string securityToken, DateTime expiresOn);
bool TryFind(string securityToken);
}

      Példa

      Íme egy példa az ITokenReplayCache felület implementálására. (Szabja testre és implementálja a projektspecifikus gyorsítótárazási keretrendszert)

      public class TokenReplayCache : ITokenReplayCache
{
    private readonly ICacheProvider cache; // Your project-specific cache provider
    public TokenReplayCache(ICacheProvider cache)
    {
        this.cache = cache;
    }
    public bool TryAdd(string securityToken, DateTime expiresOn)
    {
        if (this.cache.Get<string>(securityToken) == null)
        {
            this.cache.Set(securityToken, securityToken);
            return true;
        }
        return false;
    }
    public bool TryFind(string securityToken)
    {
        return this.cache.Get<string>(securityToken) != null;
    }
}

      A implementált gyorsítótárra az alábbiak szerint kell hivatkozni az OIDC-beállításokban a "TokenValidationParameters" tulajdonságon keresztül.

      OpenIdConnectOptions openIdConnectOptions = new OpenIdConnectOptions
{
    AutomaticAuthenticate = true,
    ... // other configuration properties follow..
    TokenValidationParameters = new TokenValidationParameters
    {
        TokenReplayCache = new TokenReplayCache(/*Inject your cache provider*/);
    }
}

      Vegye figyelembe, hogy a konfiguráció hatékonyságának teszteléséhez jelentkezzen be a helyi OIDC által védett alkalmazásba, és rögzítse a végpontra "/signin-oidc" irányuló kérést a Fiddlerben. Ha a védelem nincs érvényben, a kérés fiddlerben való ismételt elhelyezése új munkamenet-cookie-t állít be. A TokenReplayCache-védelem hozzáadása után a kérés újrajátszása után az alkalmazás kivételt fog eredményezni az alábbiak szerint: SecurityTokenReplayDetectedException: IDX10228: The securityToken has previously been validated, securityToken: 'eyJ0eXAiOiJKV1QiLCJhbGciOiJSUzI1NiIsIng1dCI6Ik1uQ19WWmNBVGZNNXBPWWlKSE1iYTlnb0VLWSIsImtpZCI6Ik1uQ1......

      MSAL könyvtárak használatával kezelheti az OAuth2-ügyfelektől a Microsoft Entra azonosítóhoz (vagy a helyszíni AD-hez) érkező token kérelmeket

      Cím Részletek
      Komponens Microsoft Entra ID
      SDL-fázis Építés
      Alkalmazható technológiák Általános
      Attribútumok n/a
      Hivatkozások MSAL
      Lépések

      A Microsoft Authentication Library (MSAL) lehetővé teszi a fejlesztők számára, hogy biztonsági jogkivonatokat szerezzenek be a Microsoft identitásplatformtól a felhasználók hitelesítésére és biztonságos webes API-k elérésére. Segítségével biztonságos hozzáférést biztosíthat a Microsoft Graphhoz, más Microsoft API-khoz, külső webes API-khoz vagy saját webes API-khoz. Az MSAL számos különböző alkalmazásarchitektúrát és platformot támogat, például .NET, JavaScript, Java, Python, Android és iOS rendszert.

      Az MSAL számos módot kínál a jogkivonatok beszerzésére, és több platformhoz egységes API-t biztosít. Nincs szükség az OAuth-kódtárak vagy -kódok közvetlen használatára az alkalmazásban lévő protokollon, és jogkivonatokat szerezhet be egy felhasználó vagy alkalmazás nevében (ha az a platformra vonatkozik).

      Az MSAL emellett egy token-gyorsítótárat is tart fenn, és frissíti a tokeneket, amikor közel van a lejártához. Az MSAL segítségével megadhatja, hogy az alkalmazás melyik célközönséget szeretné bejelentkezni, és segítséget nyújthat az alkalmazás konfigurációs fájlokból való beállításában, valamint az alkalmazás hibaelhárításában.

      A Mezőátjáróhoz csatlakozó eszközök hitelesítése

      Cím Részletek
      Komponens IoT-mezőátjáró
      SDL-fázis Építés
      Alkalmazható technológiák Általános
      Attribútumok n/a
      Hivatkozások n/a
      Lépések Győződjön meg arról, hogy az egyes eszközöket a Field Gateway hitelesíti, mielőtt adatokat fogad el tőlük, és mielőtt megkönnyítené a felhőátjáróval folytatott felsőbb rétegbeli kommunikációt. Emellett győződjön meg arról, hogy az eszközök eszköznkénti hitelesítő adatokkal csatlakoznak, hogy az egyes eszközök egyedileg azonosíthatók legyenek.

      Győződjön meg arról, hogy a felhőátjáróhoz csatlakozó eszközök hitelesítése megtörtént

      Cím Részletek
      Komponens IoT Cloud Gateway
      SDL-fázis Építés
      Alkalmazható technológiák Általános, C#, Node.js,
      Attribútumok N/A, Átjáróválasztás – Azure IoT Hub
      Hivatkozások N/A, Azure IoT Hub a .NET-tel, az IoT Hub és a Node JS használatának első lépései, az IoT biztonságossá tétele SAS-sel és tanúsítványokkal, Git-adattár

      | Lépések |

      • Általános: Az eszköz hitelesítése a Transport Layer Security (TLS) vagy az IPsec használatával. Az infrastruktúrának támogatnia kell az előre megosztott kulcs (PSK) használatát azokon az eszközökön, amelyek nem tudják kezelni a teljes aszimmetrikus titkosítást. Használja a Microsoft Entra ID, OAuth azonosítót.
      • C#: DeviceClient-példány létrehozásakor alapértelmezés szerint a Létrehozás metódus létrehoz egy DeviceClient-példányt, amely az AMQP protokollt használja az IoT Hubbal való kommunikációhoz. A HTTPS protokoll használatához használja a Create metódus felülírását, amely lehetővé teszi a protokoll megadását. HA a HTTPS protokollt használja, akkor a Microsoft.AspNet.WebApi.Client NuGet-csomagot is hozzá kell adnia a projekthez, hogy belefoglalja a System.Net.Http.Formatting névteret.
      |

      Példa

      static DeviceClient deviceClient;

static string deviceKey = "{device key}";
static string iotHubUri = "{iot hub hostname}";

var messageString = "{message in string format}";
var message = new Message(Encoding.ASCII.GetBytes(messageString));

deviceClient = DeviceClient.Create(iotHubUri, new DeviceAuthenticationWithRegistrySymmetricKey("myFirstDevice", deviceKey));

await deviceClient.SendEventAsync(message);

      Példa

      Node.js: Hitelesítés

      Szimmetrikus kulcs

      • IoT Hub létrehozása az Azure-ban
      • Bejegyzés létrehozása az eszközidentitás-beállításjegyzékben 
        var device = new iothub.Device(null);
device.deviceId = <DeviceId >
registry.create(device, function(err, deviceInfo, res) {})
      • Szimulált eszköz létrehozása 
        var clientFromConnectionString = require('azure-iot-device-amqp').clientFromConnectionString;
var Message = require('azure-iot-device').Message;
var connectionString = 'HostName=<host-name>DeviceId=<device-id>SharedAccessKey=<shared-access-key>';
var client = clientFromConnectionString(connectionString);

        SAS-token

      • A rendszer belsőleg generálja a szimmetrikus kulcs használatakor, de explicit módon is létrehozhatjuk és használhatjuk
      • Protokoll definiálása: var Http = require('azure-iot-device-http').Http;
      • Sas-jogkivonat létrehozása: 
        resourceUri = encodeURIComponent(resourceUri.toLowerCase()).toLowerCase();
var deviceName = "<device-name>";
var expires = (Date.now() / 1000) + expiresInMins * 60;
var toSign = resourceUri + '\n' + expires;
// using crypto
var decodedPassword = new Buffer(signingKey, 'base64').toString('binary');
const hmac = crypto.createHmac('sha256', decodedPassword);
hmac.update(toSign);
var base64signature = hmac.digest('base64');
var base64UriEncoded = encodeURIComponent(base64signature);
// construct authorization string
var token = "SharedAccessSignature sr=" + resourceUri + "%2fdevices%2f"+deviceName+"&sig="
+ base64UriEncoded + "&se=" + expires;
if (policyName) token += "&skn="+policyName;
return token;
      • Csatlakozás sas-jogkivonat használatával: 
        Client.fromSharedAccessSignature(sas, Http);

        Diplomák

      • Hozzon létre egy önaláírt X509-tanúsítványt bármely olyan eszközzel, mint az OpenSSL, amely .cert és .key fájlokat hoz létre a tanúsítvány és a kulcs tárolásához
      • Biztonságos kapcsolatot elfogadó eszköz kiépítése tanúsítványok használatával. 
        var connectionString = '<connection-string>';
var registry = iothub.Registry.fromConnectionString(connectionString);
var deviceJSON = {deviceId:"<device-id>",
authentication: {
    x509Thumbprint: {
    primaryThumbprint: "<primary-thumbprint>",
    secondaryThumbprint: "<secondary-thumbprint>"
    }
}}
var device = deviceJSON;
registry.create(device, function (err) {});
      • Eszköz csatlakoztatása tanúsítvány használatával 
        var Protocol = require('azure-iot-device-http').Http;
var Client = require('azure-iot-device').Client;
var connectionString = 'HostName=<host-name>DeviceId=<device-id>x509=true';
var client = Client.fromConnectionString(connectionString, Protocol);
var options = {
    key: fs.readFileSync('./key.pem', 'utf8'),
    cert: fs.readFileSync('./server.crt', 'utf8')
};
// Calling setOptions with the x509 certificate and key (and optionally, passphrase) will configure the client //transport to use x509 when connecting to IoT Hub
client.setOptions(options);
//call fn to execute after the connection is set up
client.open(fn);

      Eszközenkénti hitelesítési hitelesítő adatok használata

      Cím Részletek
      Komponens IoT Cloud Gateway
      SDL-fázis Építés
      Alkalmazható technológiák Általános
      Attribútumok Átjáróválasztás – Azure IoT Hub
      Hivatkozások Azure IoT Hub biztonsági jogkivonatok
      Lépések Használjon eszközönkénti hitelesítési adatokat az eszközkulcson vagy ügyféltanúsítványon alapuló SaS-jogkivonatokkal az IoT Hub-szintű megosztott hozzáférési szabályzatok helyett. Ez megakadályozza az egyik eszköz vagy mezőátjáró hitelesítési jogkivonatainak egy másik általi újrafelhasználását

      Győződjön meg arról, hogy csak a szükséges tárolók és blobok kapnak névtelen olvasási hozzáférést

      Cím Részletek
      Komponens Azure Storage
      SDL-fázis Építés
      Alkalmazható technológiák Általános
      Attribútumok StorageType – Blob
      Hivatkozások Tárolókhoz és blobokhoz való névtelen olvasási hozzáférés kezelése, közös hozzáférésű jogosultságkódok, 1. rész: Az SAS-modell ismertetése
      Lépések

      Alapértelmezés szerint előfordulhat, hogy egy tárolóhoz és a benne lévő blobokhoz csak a tárfiók tulajdonosa fér hozzá. Ha névtelen felhasználók számára olvasási engedélyeket szeretne adni egy tárolóhoz és annak blobjaihoz, beállíthatja a tárolóengedélyeket a nyilvános hozzáférés engedélyezéséhez. A névtelen felhasználók a kérés hitelesítése nélkül is olvashatnak blobokat egy nyilvánosan elérhető tárolóban.

      A tárolók a következő lehetőségeket biztosítják a tárolóhozzáférés kezeléséhez:

      • Teljes nyilvános olvasási hozzáférés: A tároló- és blobadatok névtelen kéréssel olvashatók. Az ügyfelek névtelen kéréssel számba tudják venni a tárolón belüli blobokat, de a tárfiókon belüli tárolókat nem tudják számba venni.
      • Csak blobok nyilvános olvasási hozzáférése: A tárolóban lévő blobadatok névtelen kéréssel olvashatók, de a tároló adatai nem érhetők el. Az ügyfelek névtelen kéréssel nem tudnak blobokat számba kérni a tárolóban
      • Nincs nyilvános olvasási hozzáférés: A tároló- és blobadatok csak a fióktulajdonos számára olvashatók

      A névtelen hozzáférés olyan helyzetekben a legjobb, amikor bizonyos bloboknak mindig elérhetőknek kell lenniük a névtelen olvasási hozzáféréshez. A részletesebb szabályozás érdekében létrehozhat egy közös hozzáférésű jogosultságkódot, amely lehetővé teszi a korlátozott hozzáférés delegálását különböző engedélyekkel és meghatározott időintervallumon keresztül. Győződjön meg arról, hogy a bizalmas adatokat esetleg tartalmazó tárolók és blobok nem kapnak véletlenül névtelen hozzáférést

      Korlátozott hozzáférés biztosítása objektumokhoz az Azure Storage-ban SAS vagy SAP használatával

      Cím Részletek
      Komponens Azure Storage
      SDL-fázis Építés
      Alkalmazható technológiák Általános
      Attribútumok n/a
      Hivatkozások Közös hozzáférésű jogosultságkódok, 1. rész: Az SAS-modell ismertetése, közös hozzáférésű jogosultságkódok, 2. rész: SAS létrehozása és használata Blob Storage-tárolóval, Hozzáférés delegálása a fiókban lévő objektumokhoz közös hozzáférésű jogosultságkódok és tárolt hozzáférési szabályzatok használatával
      Lépések

      A közös hozzáférésű jogosultságkód (SAS) hatékony módja annak, hogy korlátozott hozzáférést biztosítson a tárfiók objektumaihoz más ügyfelek számára anélkül, hogy el kellene fednie a fiók hozzáférési kulcsát. Az SAS egy URI, amely magában foglalja a lekérdezési paraméterekben a tárerőforráshoz való hitelesített hozzáféréshez szükséges összes információt. A tárolóerőforrások sassal való eléréséhez az ügyfélnek csak a megfelelő konstruktornak vagy metódusnak kell átadnia az SAS-t.

      SAS-t akkor használhat, ha hozzáférést szeretne biztosítani a tárfiók erőforrásaihoz egy olyan ügyfélnek, amelyre nem lehet rábízni a fiókkulcsot. A tárfiókkulcsok egy elsődleges és egy másodlagos kulcsot is tartalmaznak, amelyek mindegyike rendszergazdai hozzáférést biztosít a fiókjához és az abban lévő összes erőforráshoz. A fiókkulcsok felfedése megnyitja a fiókját a rosszindulatú vagy gondatlan használat lehetőségére. A közös hozzáférésű jogosultságkódok biztonságos alternatívát kínálnak, amely lehetővé teszi, hogy más ügyfelek a megadott engedélyeknek megfelelően, a fiókkulcs nélkül olvassák, írsák és törölhessék a tárfiókban lévő adatokat.

      Ha minden alkalommal hasonló logikai paraméterekkel rendelkezik, a tárolt hozzáférési szabályzat (SAP) használata jobb ötlet. Mivel a tárolt hozzáférési szabályzatból származtatott SAS használatával azonnal visszavonhatja az SAS-t, ajánlott mindig a tárolt hozzáférési szabályzatokat használni, ha lehetséges.
      • Last updated on