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


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

Termék/szolgáltatás Cikk
Webalkalmazás
Adatbázis
Azure Event Hub
Azure Trust Boundary
A Service Fabric megbízhatósági határa
Identitáskiszolgáló
Gép megbízhatósági határa
WCF
Webes API
Microsoft Entra ID
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 Létrehozá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
  • Összevonás – ADFS
  • Összevonás – Microsoft Entra-azonosító
  • Ö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 Létrehozá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 Létrehozá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 Létrehozá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 Létrehozá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 Létrehozá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:

    • Helyreállítható 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 Létrehozá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 Létrehozá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 Létrehozá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 Létrehozá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.

    Sql-hitelesítés használata nem tartalmazott adatbázisokban

    Cím Részletek
    Komponens Adatbázis
    SDL-fázis Létrehozá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özhitelesítési hitelesítő adatok használata SaS-jogkivonatokkal

    Cím Részletek
    Komponens Azure-eseményközpontok
    SDL-fázis Létrehozá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 jogkivonatokat a megfelelő eszközökkel.

    A szolgáltatásoldalon minden üzenet feladóval van megjelölve, amely lehetővé teszi a hasznos adatokon belüli 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 Trust Boundary
    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ürt biztonsági forgatókönyvei
      Lépések

      A fürtöket mindig védeni kell, hogy illetéktelen felhasználók ne csatlakozzanak a fürthöz, különösen akkor, ha éles számítási feladatok futnak 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-ban futó fürtök az ügyféltanúsítványokon kívül 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 Létrehozás
      Alkalmazható technológiák Általános
      Attribútumok n/a
      Hivatkozások IdentityServer3 – A nagy kép
      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 Identitáskiszolgáló üzembe helyezése – Gyorsítótárazás
      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ülbírálni az alapértelmezett Identity Server jogkivonat-gyorsítótárát egy méretezhető alternatívával, például az Azure Cache for Redisszel

      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 Létrehozá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 egyikre sem

      Cím Részletek
      Komponens WCF
      SDL-fázis Létrehozá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éket egyikre sem

      Cím Részletek
      Komponens WCF
      SDL-fázis Létrehozá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 átvitelét windowsosra 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 Létrehozá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
      • Összevonás – ADFS
      • Összevonás – Microsoft Entra-azonosító
      • Ö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 Létrehozá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 Létrehozás
      Alkalmazható technológiák Általános
      Attribútumok n/a
      Hivatkozások Jogkivonat-gyorsítótár szerializálása a MSAL.NET
      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ő. Azonban különböző lehetőségek állnak rendelkezésre, amelyeket alternatívaként használhat, például elosztott jogkivonat-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 Comsos 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 Létrehozá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 meghatározzon egy token-visszajátszási gyorsítótárat, egy tárolót, amely a jogkivonatok mentéséhez használható annak ellenőrzéséhez, hogy egyetlen token sem használható többször.

      Ez egy gyakori támadás elleni intézkedés, az a találóan token-visszajátszásos támadás: a bejelentkezéskor küldött jogkivonatot elfogó támadó megpróbálhatja újra elküldeni az alkalmazásnak ("visszajátszás"), hogy létrehozhassa az új munkamenetet. 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ódtárak használatával kezelheti az OAuth2-ügyfelektől a Microsoft Entra-azonosítóig (vagy a helyszíni AD-ig) érkező jogkivonat-kérelmeket

      Cím Részletek
      Komponens Microsoft Entra ID
      SDL-fázis Létrehozá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ásplatform a felhasználók hitelesítéséhez és a biztonságos webes API-k eléréséhez. 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 számos platformhoz konzisztens 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 jogkivonat-gyorsítótárat is tart fenn, és a lejáratuk előtt frissíti a jogkivonatokat. 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 Létrehozá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 Létrehozá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ójá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=<HostName>DeviceId=<DeviceId>SharedAccessKey=<SharedAccessKey>';
        var client = clientFromConnectionString(connectionString);
        

        SAS-jogkivonat

      • 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 = "<deviceName >";
        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 = '<connectionString>';
        var registry = iothub.Registry.fromConnectionString(connectionString);
        var deviceJSON = {deviceId:"<deviceId>",
        authentication: {
            x509Thumbprint: {
            primaryThumbprint: "<PrimaryThumbprint>",
            secondaryThumbprint: "<SecondaryThumbprint>"
            }
        }}
        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=<HostName>DeviceId=<DeviceId>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 Létrehozá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 Az IoT Hub-szintű megosztott hozzáférési szabályzatok helyett használjon eszközhitelesítési hitelesítő adatokat az eszközkulcson vagy ügyféltanúsítványon alapuló SaS-jogkivonatokkal. 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 Létrehozá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 Létrehozá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 olyan ügyfél számára szeretne hozzáférést biztosítani a tárfiók erőforrásaihoz, amely nem megbízható a fiókkulcskal. 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.