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

Biztonsági keret: Titkosítás | Enyhítés

  • Cikk
Termék/szolgáltatás Cikk
Webalkalmazás
Adatbázis
IoT-eszköz
IoT Cloud Gateway
Dynamics CRM Mobile Client
Dynamics CRM Outlook-ügyfél
Identitáskiszolgáló

Csak jóváhagyott szimmetrikus blokktitkok és kulcshosszok használata

Cím Részletek
Összetevő 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 termékek csak azokat a szimmetrikus blokk titkosítókat és a hozzájuk tartozó kulcshosszokat használhatják, amelyeket a crypto advisor kifejezetten jóváhagyott a szervezetben. A Microsoft által jóváhagyott szimmetrikus algoritmusok a következő blokkfelfedéseket tartalmazzák:

  • Az új AES-128, AES-192 és AES-256 kód elfogadható
  • A meglévő kóddal való visszamenőleges kompatibilitás érdekében a háromkulcsos 3DES elfogadható
  • Szimmetrikus blokktitkos titkosítást használó termékek esetén:
    • Az új kódhoz speciális titkosítási szabvány (AES) szükséges
    • A háromkulcsos háromszoros adattitkosítási szabvány (3DES) a visszamenőleges kompatibilitás érdekében megengedett a meglévő kódban
    • Minden más blokktitkosítás, beleértve az RC2, a DES, a 2 Key 3DES, a DESX és a Skipjack titkosítást, csak a régi adatok visszafejtésére használható, és titkosítás esetén ki kell cserélni
  • Szimmetrikus blokktitkosítási algoritmusok esetén a kulcs minimális hossza 128 bit. Az új kódhoz ajánlott egyetlen blokktitkosítási algoritmus az AES (AES-128, AES-192 és AES-256)
  • A háromkulcsos 3DES jelenleg elfogadható, ha már használatban van a meglévő kódban; az AES-be való áttűnés ajánlott. A DES, a DESX, az RC2 és a Skipjack már nem tekinthető biztonságosnak. Ezek az algoritmusok csak a visszamenőleges kompatibilitás érdekében használhatók a meglévő adatok visszafejtésére, és az adatokat ajánlott blokktitkosítással kell újratitkosítani

Vegye figyelembe, hogy minden szimmetrikus blokktitkosítást jóváhagyott titkosítási móddal kell használni, amelyhez megfelelő inicializálási vektort (IV) kell használni. A megfelelő IV általában egy véletlenszerű szám, és soha nem állandó érték

A korábbi vagy más módon nem jóváhagyott kriptográfiai algoritmusok és kisebb kulcshosszok használata a meglévő adatok olvasásához (az új adatok írása helyett) a szervezet kriptográfiai testületének áttekintése után engedélyezhető. A követelmény alól azonban kivételt kell beiktatnia. Emellett a nagyvállalati üzemelő példányokban a termékeknek figyelmeztető rendszergazdákat kell figyelembe venniük, ha gyenge titkosítást használnak az adatok olvasásához. Az ilyen figyelmeztetéseknek magyarázónak és végrehajthatónak kell lenniük. Bizonyos esetekben célszerű lehet Csoportházirend szabályozni a gyenge kriptográfia használatát

Engedélyezett .NET-algoritmusok felügyelt titkosítási rugalmassághoz (előnyben részesített sorrendben)

  • AesCng (FIPS-kompatibilis)
  • AuthenticatedAesCng (FIPS-kompatibilis)
  • AESCryptoServiceProvider (FIPS-kompatibilis)
  • AESManaged (nem FIPS-kompatibilis)

Vegye figyelembe, hogy ezen algoritmusok egyike sem adható meg a vagy CryptoConfig.CreateFromName metódussal SymmetricAlgorithm.Create anélkül, hogy módosítanák a machine.config fájlt. Azt is vegye figyelembe, hogy a .NET 3.5 előtti verzióiban az AES neve RijndaelManaged, és AesCngAuthenticatedAesCng>a CodePlexen keresztül érhető el, és CNG-t igényel az alapul szolgáló operációs rendszerben

Jóváhagyott blokktitkosítási módok és inicializálási vektorok használata szimmetrikus titkosításokhoz

Cím Részletek
Összetevő 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 Minden szimmetrikus blokktitkos titkosítást jóváhagyott szimmetrikus titkosítási móddal kell használni. Az egyetlen jóváhagyott mód a CBC és a CTS. Különösen el kell kerülni az elektronikus kódjegyzék (EKB) működési módját; az EKB használatához a szervezet kriptográfiai tanácsának felülvizsgálatára van szükség. Az OFB, a CFB, a CTR, a CCM és a GCM, illetve bármely más titkosítási mód használatát a szervezet kriptográfiai táblájának kell áttekintenie. Ha ugyanazt az inicializálási vektort (IV) újra felhasználja blokkfelfedésekkel a "streamelési titkosítási módban", például a CTR-ben, a titkosított adatok felfedését okozhatja. Minden szimmetrikus blokktitkosítást megfelelő inicializálási vektorral (IV) is használni kell. A megfelelő IV egy kriptográfiailag erős, véletlenszerű szám, és soha nem állandó érték.

Jóváhagyott aszimmetrikus algoritmusok, kulcshosszok és kitöltés használata

Cím Részletek
Összetevő 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 tiltott titkosítási algoritmusok használata jelentős kockázatot jelent a termékbiztonság szempontjából, ezért el kell kerülni. A termékeknek csak azokat a titkosítási algoritmusokat, valamint a hozzájuk tartozó kulcshosszokat és kitöltéseket kell használniuk, amelyeket a szervezet kriptográfiai táblája kifejezetten jóváhagyott.

  • RSA- használható titkosításhoz, kulcscseréhez és aláíráshoz. Az RSA-titkosítás csak OAEP- vagy RSA-KEM-kitöltési módokat használhat. A meglévő kód csak a kompatibilitás érdekében használhatja a PKCS #1 v1.5 kitöltési módot. A null kitöltés használata kifejezetten tiltott. Kulcsok >= 2048 bit szükséges az új kódhoz. A meglévő kód a 2048 bites kulcsokat < csak a visszamenőleges kompatibilitás érdekében támogatja, miután a szervezet kriptográfiai igazgatósága áttekinti. Az 1024 bites kulcsok < csak a régi adatok visszafejtésére/ellenőrzésére használhatók, és a titkosítási vagy aláírási műveletekhez használt kulcsokat ki kell cserélni
  • ECDSA- csak aláíráshoz használható. Az új kódhoz =256 bites kulcsokkal rendelkező >ECDSA szükséges. Az ECDSA-alapú aláírásoknak a NIST által jóváhagyott három görbe (P-256, P-384 vagy P521) egyikét kell használniuk. Az alaposan elemezett görbék csak a szervezet kriptotáblájával végzett felülvizsgálat után használhatók.
  • ECDH- csak kulcscserére használható. Az új kódhoz =256 bites kulcsokkal rendelkező >ECDH szükséges. Az ECDH-alapú kulcscserének a NIST által jóváhagyott három görbe egyikét kell használnia (P-256, P-384 vagy P521). Az alaposan elemezett görbék csak a szervezet kriptotáblájával végzett felülvizsgálat után használhatók.
  • A DSA- elfogadható lehet a szervezet kriptográfiai igazgatóságának áttekintése és jóváhagyása után. Vegye fel a kapcsolatot a biztonsági tanácsadóval, hogy ütemezze a szervezet crypto board felülvizsgálatát. Ha a DSA használatát jóváhagyják, vegye figyelembe, hogy meg kell tiltani a 2048 bitesnél rövidebb kulcsok használatát. A CNG támogatja a 2048 bites és a nagyobb kulcshosszokat a Windows 8.
  • A Diffie-Hellman- csak munkamenetkulcs-kezelésre használható. Kulcshossz >= 2048 bit szükséges az új kódhoz. A meglévő kód a 2048 bites kulcshosszokat < csak a visszamenőleges kompatibilitás érdekében támogatja a szervezet kriptográfiai táblájának áttekintése után. 1024 bites kulcsok < nem használhatók.

    Jóváhagyott véletlenszerű számgenerátorok használata

    Cím Részletek
    Összetevő 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 termékeknek jóváhagyott véletlenszerű számgenerátorokat kell használniuk. A pseudorandom függvényeket, például a C futtatókörnyezeti függvényt, a System.Random .NET-keretrendszer osztályt vagy a GetTickCounthoz hasonló rendszerfüggvényeket ezért soha nem szabad használni ilyen kódban. A kettős elliptikus görbe véletlenszerű számgenerátor (DUAL_EC_DRBG) algoritmus használata tilos

    • CNG- BCryptGenRandom(a BCRYPT_USE_SYSTEM_PREFERRED_RNG jelző használata ajánlott, hacsak a hívó nem futhat 0-nál nagyobb IRQL-en [azaz PASSIVE_LEVEL])
    • CAPI – cryptGenRandom
    • Win32/64- RtlGenRandom (az új implementációknak a BCryptGenRandom vagy a CryptGenRandom értéket kell használniuk) * rand_s * SystemPrng (kernelmódhoz)
    • . NET – RNGCryptoServiceProvider vagy RNGCng
    • Windows Áruházbeli alkalmazások– Windows.Security.Cryptography.CryptographicBuffer.GenerateRandom vagy . GenerateRandomNumber
    • Apple OS X (10.7+)/iOS(2.0+)- int SecRandomCopyBytes (SecRandomRef random, size_t count, uint8_t *bájt )
    • Apple OS X (<10.7)– A /dev/random függvény használata véletlenszerű számok lekéréséhez
    • Java (beleértve a Google Android Java-kódot)- java.security.SecureRandom osztály. Vegye figyelembe, hogy az Android 4.3 -hoz (Jelly Bean) a fejlesztőknek követniük kell az Android által javasolt kerülő megoldást, és frissíteniük kell az alkalmazásaikat, hogy explicit módon inicializálják a PRNG-t a /dev/urandom vagy /dev/random entrópiával

    Ne használjon szimmetrikus streamjeleket

    Cím Részletek
    Összetevő 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 Szimmetrikus adatfolyam-titkosítók( például RC4) nem használhatók. A szimmetrikus streames titkosítások helyett a termékeknek blokktitkos titkosítást kell használniuk, különösen az AES-t, amelynek kulcshossza legalább 128 bit.

    Jóváhagyott MAC/HMAC/kulcsos kivonatolási algoritmusok használata

    Cím Részletek
    Összetevő 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 termékek csak jóváhagyott üzenethitelesítő kódot (MAC) vagy kivonatalapú üzenethitelesítési (HMAC) algoritmusokat használhatnak.

    Az üzenethitelesítési kód (MAC) egy üzenethez csatolt információ, amely lehetővé teszi, hogy a címzett titkos kulcs használatával ellenőrizze a feladó hitelességét és integritását. A kivonatalapú MAC (HMAC) vagy a blokkfelfedés-alapú MAC használata megengedett, feltéve, hogy az összes mögöttes kivonat- vagy szimmetrikus titkosítási algoritmust is jóváhagyják a használathoz; Jelenleg ez magában foglalja a HMAC-SHA2 függvényeket (HMAC-SHA256, HMAC-SHA384 és HMAC-SHA512), valamint a CMAC/OMAC1 és OMAC2 blokktitkos titkosításon alapuló MAC-okat (ezek az AES-en alapulnak).

    A HMAC-SHA1 használata megengedett lehet a platformkompatibilitás érdekében, de kivételt kell tennie ebben az eljárásban, és át kell esnie a szervezet kriptográfiai felülvizsgálatán. A HMAC-k 128 bitesnél kisebbre való csonkolása nem engedélyezett. A kulcs és az adatok kivonatolásának ügyfélmetodusokkal történő használata nem engedélyezett, és használat előtt át kell esnie a szervezet kriptotábla-felülvizsgálatán.

    Csak jóváhagyott titkosítási kivonatfüggvények használata

    Cím Részletek
    Összetevő 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 termékeknek az SHA-2 kivonatoló algoritmuscsaládot (SHA256, SHA384 és SHA512) kell használniuk. Ha rövidebb kivonatra van szükség, például egy 128 bites kimeneti hosszra, hogy illeszkedjen a rövidebb MD5 kivonattal tervezett adatstruktúrához, a termékcsapatok csonkíthatják az SHA2 kivonatok egyikét (általában SHA256). Vegye figyelembe, hogy az SHA384 az SHA512 csonkolt verziója. A titkosítási kivonatok 128 bitesnél kisebb biztonsági célú csonkolása nem engedélyezett. Az új kód nem használhatja az MD2, MD4, MD5, SHA-0, SHA-1 vagy RIPEMD kivonatoló algoritmusokat. A kivonatütközések számításilag megvalósíthatók ezekhez az algoritmusokhoz, amelyek hatékonyan megszakítják azokat.

    Engedélyezett .NET-kivonatolási algoritmusok felügyelt titkosítási rugalmassághoz (a beállítások sorrendjében):

    • SHA512Cng (FIPS-kompatibilis)
    • SHA384Cng (FIPS-kompatibilis)
    • SHA256Cng (FIPS-kompatibilis)
    • SHA512Managed (nem FIPS-kompatibilis) (az SHA512-t használja algoritmusnévként a HashAlgorithm.Create vagy CryptoConfig.CreateFromName hívásaiban)
    • SHA384Managed (nem FIPS-kompatibilis) (használja az SHA384-et algoritmusnévként a HashAlgorithm.Create vagy CryptoConfig.CreateFromName hívásaiban)
    • SHA256Managed (nem FIPS-kompatibilis) (az SHA256-ot használja algoritmusnévként a HashAlgorithm.Create vagy CryptoConfig.CreateFromName hívásaiban)
    • SHA512CryptoServiceProvider (FIPS-kompatibilis)
    • SHA256CryptoServiceProvider (FIPS-kompatibilis)
    • SHA384CryptoServiceProvider (FIPS-kompatibilis)

    Erős titkosítási algoritmusok használata az adatbázisban lévő adatok titkosításához

    Cím Részletek
    Összetevő Adatbázis
    SDL-fázis Létrehozás
    Alkalmazható technológiák Általános
    Attribútumok N/A
    Hivatkozások Titkosítási algoritmus kiválasztása
    Lépések A titkosítási algoritmusok olyan adatátalakításokat határoznak meg, amelyeket a jogosulatlan felhasználók nem tudnak könnyen visszafejteni. SQL Server lehetővé teszi a rendszergazdák és fejlesztők számára, hogy számos algoritmus közül válasszanak, például a DES, a Triple DES, a TRIPLE_DES_3KEY, az RC2, az RC4, a 128 bites RC4, a DESX, a 128 bites AES, a 192 bites AES és a 256 bites AES közül

    Az SSIS-csomagokat titkosítva és digitálisan alá kell írni

    Cím Részletek
    Összetevő Adatbázis
    SDL-fázis Létrehozás
    Alkalmazható technológiák Általános
    Attribútumok N/A
    Hivatkozások A csomagok forrásának azonosítása digitális aláírásokkal, fenyegetés- és biztonságirés-elhárítással (integrációs szolgáltatások)
    Lépések A csomag forrása a csomagot létrehozó személy vagy szervezet. A csomagok ismeretlen vagy nem megbízható forrásból történő futtatása kockázatos lehet. Az SSIS-csomagok jogosulatlan illetéktelen illetéktelen megváltoztatásának megakadályozása érdekében digitális aláírásokat kell használni. Emellett a csomagok titkosságának biztosítása érdekében a tárolás/átvitel során az SSIS-csomagokat titkosítani kell

    Digitális aláírás hozzáadása a kritikus fontosságú adatbázisok biztonságossá tételéhez

    Cím Részletek
    Összetevő Adatbázis
    SDL-fázis Létrehozás
    Alkalmazható technológiák Általános
    Attribútumok N/A
    Hivatkozások ALÁÍRÁS HOZZÁADÁSA (Transact-SQL)
    Lépések Olyan esetekben, amikor a kritikus fontosságú adatbázisok integritását ellenőrizni kell, digitális aláírásokat kell használni. Az adatbázisok biztonságossá tétele, például egy tárolt eljárás, függvény, szerelvény vagy eseményindító digitálisan aláírható. Az alábbiakban egy példa látható arra, hogy ez mikor lehet hasznos: Tegyük fel, hogy egy független szoftverszállító (független szoftverszállító) támogatást nyújtott egy olyan szoftvernek, amelyet az egyik ügyfélnek szállítottak. A támogatás biztosítása előtt az ISV meg szeretné győződni arról, hogy a szoftverben biztonságos adatbázist sem véletlenül, sem rosszindulatú kísérlettel nem módosították. Ha a biztonságos eszköz digitálisan van aláírva, az ISV ellenőrizheti a digitális aláírását, és ellenőrizheti annak integritását.

    Az SQL Server EKM használata a titkosítási kulcsok védelméhez

    Cím Részletek
    Összetevő Adatbázis
    SDL-fázis Létrehozás
    Alkalmazható technológiák Általános
    Attribútumok N/A
    Hivatkozások SQL Server Bővíthető kulcskezelés (EKM), Bővíthető kulcskezelés az Azure Key Vault használatával (SQL Server)
    Lépések SQL Server Bővíthető kulcskezelés lehetővé teszi, hogy az adatbázisfájlokat védő titkosítási kulcsok egy külső eszközön, például intelligens kártyán, USB-eszközön vagy EKM/HSM-modulban legyenek tárolva. Ez lehetővé teszi az adatbázis-rendszergazdák adatvédelemét is (kivéve a sysadmin csoport tagjait). Az adatok titkosíthatók olyan titkosítási kulcsokkal, amelyekhez csak az adatbázis-felhasználó fér hozzá a külső EKM/HSM modulon.

    Az AlwaysEncrypted funkció használata, ha a titkosítási kulcsokat nem szabad felfedni az adatbázismotor számára

    Cím Részletek
    Összetevő Adatbázis
    SDL-fázis Létrehozás
    Alkalmazható technológiák SQL Azure, Április
    Attribútumok SQL-verzió – V12, MsSQL2016
    Hivatkozások Always Encrypted (adatbázismotor)
    Lépések A Always Encrypted egy olyan funkció, amely az Azure SQL Database-ben vagy SQL Server-adatbázisokban tárolt bizalmas adatokat, például hitelkártyaszámokat vagy nemzeti/regionális azonosító számokat (pl. egyesült államokbeli társadalombiztosítási számokat) védi. Always Encrypted lehetővé teszi az ügyfelek számára a bizalmas adatok ügyfélalkalmazáson belüli titkosítását, és soha nem fedik fel a titkosítási kulcsokat az adatbázismotornak (SQL Database vagy SQL Server). Ennek eredményeképpen a Always Encrypted elkülöníti azokat, akik az adatok tulajdonosa (és megtekinthetik) és azok között, akik kezelik az adatokat (de nem rendelkezhetnek hozzáféréssel)

    Titkosítási kulcsok biztonságos tárolása IoT-eszközön

    Cím Részletek
    Összetevő IoT-eszköz
    SDL-fázis Létrehozás
    Alkalmazható technológiák Általános
    Attribútumok Eszköz operációs rendszere – Windows IoT Core, eszközkapcsolat – Azure IoT-eszközoldali SDK-k
    Hivatkozások TPM Windows IoT Core-on, TPM beállítása Windows IoT Core-on, Azure IoT Device SDK TPM
    Lépések Szimmetrikus vagy tanúsítványalapú titkos kulcsok biztonságosan egy hardveres védelem alatt álló tárolóban, például TPM-ben vagy intelligenskártya-chipekben. Windows 10 IoT Core támogatja a TPM felhasználóját, és számos kompatibilis TPM használható: Különálló TPM (dTPM). Javasoljuk, hogy belső vezérlőprogramot vagy különálló TPM-et használjon. A Szoftver TPM-et csak fejlesztési és tesztelési célokra szabad használni. Miután elérhetővé válik egy TPM, és a kulcsok ki lesznek építve benne, a jogkivonatot létrehozó kódot anélkül kell megírni, hogy a benne lévő bizalmas adatokat nem kell szigorúan beírni.

    Példa

    TpmDevice myDevice = new TpmDevice(0);
// Use logical device 0 on the TPM 
string hubUri = myDevice.GetHostName(); 
string deviceId = myDevice.GetDeviceId(); 
string sasToken = myDevice.GetSASToken(); 

var deviceClient = DeviceClient.Create( hubUri, AuthenticationMethodFactory. CreateAuthenticationWithToken(deviceId, sasToken), TransportType.Amqp);

    Mint látható, az eszköz elsődleges kulcsa nincs jelen a kódban. Ehelyett a TPM tárolja a 0. ponton. A TPM-eszköz létrehoz egy rövid élettartamú SAS-jogkivonatot, amelyet aztán a IoT Hub való csatlakozáshoz használ.

    A hitelesítéshez megfelelő hosszúságú véletlenszerű szimmetrikus kulcs létrehozása IoT Hub

    Cím Részletek
    Összetevő 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 N/A
    Lépések IoT Hub tartalmaz egy eszközidentitás-beállításjegyzéket, és az eszköz kiépítésekor automatikusan létrehoz egy véletlenszerű szimmetrikus kulcsot. A hitelesítéshez használt kulcs létrehozásához ajánlott a Azure IoT Hub Identity Registry ezen funkciójának használata. IoT Hub egy kulcs megadását is lehetővé teszi az eszköz létrehozásakor. Ha a kulcs az eszköz kiépítése során IoT Hub kívül jön létre, akkor ajánlott véletlenszerű szimmetrikus kulcsot vagy legalább 256 bitet létrehozni.

    Győződjön meg arról, hogy olyan eszközfelügyeleti szabályzat van érvényben, amely használatához PIN-kód szükséges, és lehetővé teszi a távoli törlést

    Cím Részletek
    Összetevő Dynamics CRM Mobile Client
    SDL-fázis Üzembe helyezé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 olyan eszközfelügyeleti szabályzat van érvényben, amely használatához PIN-kód szükséges, és lehetővé teszi a távoli törlést

    Győződjön meg arról, hogy olyan eszközfelügyeleti szabályzat van érvényben, amely PIN-kódot/jelszót/automatikus zárolást igényel, és titkosítja az összes adatot (pl. BitLocker)

    Cím Részletek
    Összetevő Dynamics CRM Outlook-ügyfél
    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 olyan eszközfelügyeleti szabályzat van érvényben, amely PIN-kódot/jelszót/automatikus zárolást igényel, és titkosítja az összes adatot (pl. BitLocker)

    Győződjön meg arról, hogy az aláírókulcsok át lettek állítva az Identitáskiszolgáló használatakor

    Cím Részletek
    Összetevő Identitáskiszolgáló
    SDL-fázis Üzembe helyezés
    Alkalmazható technológiák Általános
    Attribútumok N/A
    Hivatkozások Identity Server – Kulcsok, aláírások és titkosítás
    Lépések Győződjön meg arról, hogy az aláírókulcsok át lettek állítva az Identitáskiszolgáló használatakor. A hivatkozások szakasz hivatkozása bemutatja, hogyan kell ezt megtervezni anélkül, hogy az identitáskiszolgálóra támaszkodó alkalmazások kimaradását okozná.

    Győződjön meg arról, hogy kriptográfiailag erős ügyfél-azonosítót, titkos ügyfélkulcsot használ az Identity Server

    Cím Részletek
    Összetevő Identitáskiszolgáló
    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 kriptográfiailag erős ügyfél-azonosítót, ügyfélkulcsot használnak az Identity Serverben. Az ügyfélazonosító és titkos kód létrehozásakor a következő irányelveket kell alkalmazni:

    • Véletlenszerű GUID létrehozása ügyfélazonosítóként
    • Kriptográfiailag véletlenszerű, 256 bites kulcs létrehozása titkos kulcsként