Product/service |
Artikel |
Webapplicatie |
|
Databank |
|
IoT-apparaat |
|
IoT Cloud Gateway |
|
Dynamics CRM mobiele client |
|
Dynamics CRM Outlook-client |
|
Identity Server |
|
Gebruik alleen goedgekeurde symmetrische blokcijfers en sleutellengtes
Titel |
Bijzonderheden |
Onderdeel |
Webapplicatie |
SDL-fase |
Bouwen |
Toepasselijke technologieën |
Algemeen |
Kenmerken |
Niet van toepassing. |
Verwijzingen |
Niet van toepassing. |
Stappen |
Producten mogen alleen die symmetrische blokcijfers en bijbehorende sleutellengtes gebruiken die expliciet zijn goedgekeurd door de Crypto Advisor in uw organisatie. Goedgekeurde symmetrische algoritmen bij Microsoft omvatten de volgende blokcijfers: - Voor de nieuwe code AES-128 zijn AES-192 en AES-256 acceptabel
- Voor achterwaartse compatibiliteit met bestaande code is 3DES met drie toetsen acceptabel
- Voor producten die symmetrische blok-coderingen gebruiken:
- Advanced Encryption Standard (AES) is vereist voor nieuwe code
- Three-key triple Data Encryption Standard (3DES) is toegestaan in bestaande code voor achterwaartse compatibiliteit
- Alle andere blokcijfers, waaronder RC2, DES, 2 Key 3DES, DESX en Skipjack, mogen alleen worden gebruikt voor het ontcijferen van oude gegevens en moeten worden vervangen als ze worden gebruikt voor versleuteling
- Voor symmetrische blokversleutelingsalgoritmen is een minimale sleutellengte van 128 bits vereist. Het enige blokcoderingsalgoritme dat wordt aanbevolen voor nieuwe code is AES (AES-128, AES-192 en AES-256 zijn allemaal acceptabel)
- 3DES met drie toetsen is momenteel acceptabel als het al in gebruik is in bestaande code; overgang naar AES wordt aanbevolen. DES, DESX, RC2 en Skipjack worden niet langer als veilig beschouwd. Deze algoritmen mogen alleen worden gebruikt voor het ontcijferen van bestaande gegevens omwille van achterwaartse compatibiliteit, en gegevens moeten opnieuw worden versleuteld met behulp van een aanbevolen blokcijfer
Houd er rekening mee dat alle symmetrische blokcijfers moeten worden gebruikt met een goedgekeurde coderingsmodus, die het gebruik van een geschikte initialisatievector (IV) vereist. Een geschikte IV is meestal een willekeurig getal en nooit een constante waarde Het gebruik van verouderde of anderszins niet-goedgekeurde crypto-algoritmen en kleinere sleutellengtes voor het lezen van bestaande gegevens (in tegenstelling tot het schrijven van nieuwe gegevens) kan worden toegestaan na de beoordeling van de Crypto Board van uw organisatie. U moet echter een uitzondering op deze vereiste aanvragen. Bovendien moeten producten in bedrijfsimplementaties overwegen om beheerders te waarschuwen wanneer zwakke crypto wordt gebruikt om gegevens te lezen. Dergelijke waarschuwingen moeten verklarend en bruikbaar zijn. In sommige gevallen kan het gepast zijn om het gebruik van zwakke crypto door groepsbeleid te laten controleren Toegestane .NET-algoritmen voor beheerde crypto-agility (in volgorde van voorkeur) - AesCng (voldoet aan FIPS)
- AuthenticatedAesCng (FIPS-compatibel)
- AESCryptoServiceProvider (voldoet aan FIPS)
- AESManaged (niet-FIPS-compatibel)
Houd er rekening mee dat geen van deze algoritmen kan worden gespecificeerd via de SymmetricAlgorithm.Create of-methoden CryptoConfig.CreateFromName zonder wijzigingen aan te brengen in het machine.config bestand. Houd er ook rekening mee dat AES in versies van .NET vóór .NET 3.5 de naam RijndaelManaged AesCng heeft en AuthenticatedAesCng beschikbaar is >via CodePlex en CNG vereist in het onderliggende besturingssysteem |
Gebruik goedgekeurde blokcoderingsmodi en initialisatievectoren voor symmetrische cijfers
Titel |
Bijzonderheden |
Onderdeel |
Webapplicatie |
SDL-fase |
Bouwen |
Toepasselijke technologieën |
Algemeen |
Kenmerken |
Niet van toepassing. |
Verwijzingen |
Niet van toepassing. |
Stappen |
Alle symmetrische blokcijfers moeten worden gebruikt met een goedgekeurde symmetrische cijfermodus. De enige goedgekeurde modi zijn CBC en CTS. Met name dient de werking van het elektronisch codeboek (ECB) te worden vermeden; het gebruik van de ECB vereist de beoordeling van de Crypto Board door uw organisatie. Al het gebruik van OFB, CFB, CTR, CCM en GCM of een andere coderingsmodus moet worden beoordeeld door de Crypto Board van uw organisatie. Het hergebruiken van dezelfde initialisatievector (IV) met blokcijfers in 'streaming ciphers-modi', zoals CTR, kan ertoe leiden dat versleutelde gegevens worden onthuld. Alle symmetrische blokcijfers moeten ook worden gebruikt met een geschikte initialisatievector (IV). Een geschikte IV is een cryptografisch sterk, willekeurig getal en nooit een constante waarde. |
Gebruik goedgekeurde asymmetrische algoritmen, toetslengtes en opvulling
Titel |
Bijzonderheden |
Onderdeel |
Webapplicatie |
SDL-fase |
Bouwen |
Toepasselijke technologieën |
Algemeen |
Kenmerken |
Niet van toepassing. |
Verwijzingen |
Niet van toepassing. |
Stappen |
Het gebruik van verboden cryptografische algoritmen brengt een aanzienlijk risico met zich mee voor de productbeveiliging en moet worden vermeden. Producten mogen alleen die cryptografische algoritmen en bijbehorende sleutellengtes en opvulling gebruiken die expliciet zijn goedgekeurd door het Crypto Board van uw organisatie. -
RSA- kan worden gebruikt voor codering, sleuteluitwisseling en ondertekening. RSA-versleuteling mag alleen de OAEP- of RSA-KEM-opvullingsmodi gebruiken. Bestaande code kan PKCS #1 v1.5 opvullingsmodus alleen gebruiken voor compatibiliteit. Het gebruik van null padding is expliciet verboden. Sleutels >= 2048 bits zijn vereist voor nieuwe code. Bestaande code ondersteunt mogelijk alleen sleutels < van 2048 bits voor achterwaartse compatibiliteit na een beoordeling door het Crypto Board van uw organisatie. Sleutels < 1024 bits mogen alleen worden gebruikt voor het decoderen/verifiëren van oude gegevens en moeten worden vervangen als ze worden gebruikt voor versleuteling of ondertekeningsbewerkingen
-
ECDSA- mag alleen worden gebruikt voor ondertekening. ECDSA met >=256-bit sleutels is vereist voor nieuwe code. Op ECDSA gebaseerde handtekeningen moeten een van de drie door NIST goedgekeurde curven gebruiken (P-256, P-384 of P521). Curves die grondig zijn geanalyseerd, mogen alleen worden gebruikt na een beoordeling met het Crypto Board van uw organisatie.
-
ECDH- mag alleen worden gebruikt voor sleuteluitwisseling. ECDH met >=256-bits sleutels is vereist voor nieuwe code. Voor de uitwisseling van sleutels op basis van het ECDH moet een van de drie door NIST goedgekeurde curven worden gebruikt (P-256, P-384 of P521). Curves die grondig zijn geanalyseerd, mogen alleen worden gebruikt na een beoordeling met het Crypto Board van uw organisatie.
-
DSA- kan acceptabel zijn na beoordeling en goedkeuring van de Crypto Board van uw organisatie. Neem contact op met uw beveiligingsadviseur om de Crypto Board-beoordeling van uw organisatie te plannen. Als uw gebruik van DSA is goedgekeurd, houd er dan rekening mee dat u het gebruik van sleutels met een lengte van minder dan 2048 bits moet verbieden. CNG ondersteunt 2048-bits en grotere sleutellengtes vanaf Windows 8.
-
Diffie-Hellman- mag alleen worden gebruikt voor sessiesleutelbeheer. Sleutellengte >= 2048 bits is vereist voor nieuwe code. Bestaande code ondersteunt mogelijk alleen sleutellengtes van < 2048 bits voor achterwaartse compatibiliteit na een beoordeling door het Crypto Board van uw organisatie. Toetsen < 1024 bits mogen niet worden gebruikt.
|
Gebruik goedgekeurde generatoren voor willekeurige getallen
Titel |
Bijzonderheden |
Onderdeel |
Webapplicatie |
SDL-fase |
Bouwen |
Toepasselijke technologieën |
Algemeen |
Kenmerken |
Niet van toepassing. |
Verwijzingen |
Niet van toepassing. |
Stappen |
Producten moeten gebruik maken van goedgekeurde generatoren voor willekeurige getallen. Pseudowillekeurige functies zoals de C runtime function rand, de .NET Framework class System.Random of systeemfuncties zoals GetTickCount mogen daarom nooit in dergelijke code worden gebruikt. Het gebruik van het algoritme voor de dubbele elliptische curve voor het genereren van willekeurige getallen (DUAL_EC_DRBG) is verboden -
CNG- BCryptGenRandom(gebruik van de BCRYPT_USE_SYSTEM_PREFERRED_RNG-vlag wordt aanbevolen, tenzij de aanroeper kan worden uitgevoerd op een IRQL groter dan 0 [dat wil zeggen, PASSIVE_LEVEL])
-
CAPI- cryptGenRandom
-
Win 32/64- RtlGenRandom (nieuwe implementaties moeten BCryptGenRandom of CryptGenRandom gebruiken) * rand_s * SystemPrng (voor kernelmodus)
-
. NET- RNGCryptoServiceProvider of RNGCng
-
Windows Store-apps- Windows.Security.Cryptography.CryptographicBuffer.GenerateRandom of . GenerateRandomNumber
-
Apple OS X (10.7+)/iOS(2.0+)- int SecRandomCopyBytes (SecRandomRef willekeurig, size_t aantal, uint8_t *bytes )
-
Apple OS X (<10.7) - Gebruik /dev/random om willekeurige getallen op te halen
-
Java (inclusief Google Android Java-code) - java.security.SecureRandom klasse. Houd er rekening mee dat ontwikkelaars voor Android 4.3 (Jelly Bean) de door Android aanbevolen tijdelijke oplossing moeten volgen en hun applicaties moeten bijwerken om de PRNG expliciet te initialiseren met entropie van /dev/urandom of /dev/random
|
Gebruik geen symmetrische stroomcijfers
Titel |
Bijzonderheden |
Onderdeel |
Webapplicatie |
SDL-fase |
Bouwen |
Toepasselijke technologieën |
Algemeen |
Kenmerken |
Niet van toepassing. |
Verwijzingen |
Niet van toepassing. |
Stappen |
Symmetrische stroomcijfers, zoals RC4, mogen niet worden gebruikt. In plaats van symmetrische stroomcijfers moeten producten een blokcijfer gebruiken, met name AES met een sleutellengte van ten minste 128 bits. |
Gebruik goedgekeurde MAC/HMAC/keyed hash-algoritmen
Titel |
Bijzonderheden |
Onderdeel |
Webapplicatie |
SDL-fase |
Bouwen |
Toepasselijke technologieën |
Algemeen |
Kenmerken |
Niet van toepassing. |
Verwijzingen |
Niet van toepassing. |
Stappen |
Producten mogen alleen gebruikmaken van goedgekeurde MAC-algoritmen (Message Authentication Code) of HMAC-algoritmen (Message Authentication Code) op basis van hash. Een berichtverificatiecode (MAC) is een stukje informatie dat is gekoppeld aan een bericht waarmee de ontvanger zowel de echtheid van de afzender als de integriteit van het bericht kan verifiëren met behulp van een geheime sleutel. Het gebruik van een MAC (HMAC) op basis van hash of een MAC op basis van blokcijfers is toegestaan zolang alle onderliggende hash- of symmetrische versleutelingsalgoritmen ook zijn goedgekeurd voor gebruik; momenteel omvat dit de HMAC-SHA2 functies (HMAC-SHA256, HMAC-SHA384 en HMAC-SHA512) en de CMAC/OMAC1 en OMAC2 blokcijfer-gebaseerde MAC's (deze zijn gebaseerd op AES). Het gebruik van HMAC-SHA1 kan zijn toegestaan voor platformcompatibiliteit, maar u moet een uitzondering op deze procedure indienen en de Crypto-beoordeling van uw organisatie ondergaan. Het afkappen van HMAC's tot minder dan 128 bits is niet toegestaan. Het gebruik van klantmethoden om een sleutel en gegevens te hashen is niet goedgekeurd en moet vóór gebruik de Crypto Board-beoordeling van uw organisatie ondergaan. |
Gebruik alleen goedgekeurde cryptografische hashfuncties
Titel |
Bijzonderheden |
Onderdeel |
Webapplicatie |
SDL-fase |
Bouwen |
Toepasselijke technologieën |
Algemeen |
Kenmerken |
Niet van toepassing. |
Verwijzingen |
Niet van toepassing. |
Stappen |
Producten moeten gebruikmaken van de SHA-2-familie van hash-algoritmen (SHA256, SHA384 en SHA512). Als een kortere hash nodig is, zoals een uitvoerlengte van 128 bits om te passen in een gegevensstructuur die is ontworpen met de kortere MD5-hash in gedachten, kunnen productteams een van de SHA2-hashes afkappen (meestal SHA256). Merk op dat SHA384 een afgekapte versie is van SHA512. Het afkappen van cryptografische hashes voor beveiligingsdoeleinden tot minder dan 128 bits is niet toegestaan. Nieuwe code mag geen gebruik maken van de MD2-, MD4-, MD5-, SHA-0-, SHA-1- of RIPEMD-hashalgoritmen. Hash-botsingen zijn computationeel haalbaar voor deze algoritmen, waardoor ze effectief worden gebroken. Toegestane .NET hash-algoritmen voor beheerde crypto-behendigheid (in volgorde van voorkeur): - SHA512Cng (voldoet aan FIPS)
- SHA384Cng (voldoet aan FIPS)
- SHA256Cng (voldoet aan FIPS)
- SHA512Managed (niet-FIPS-compatibel) (gebruik SHA512 als algoritmenaam in aanroepen naar HashAlgorithm.Create of CryptoConfig.CreateFromName)
- SHA384Managed (niet-FIPS-compatibel) (gebruik SHA384 als algoritmenaam in aanroepen naar HashAlgorithm.Create of CryptoConfig.CreateFromName)
- SHA256Managed (niet-FIPS-compatibel) (gebruik SHA256 als algoritmenaam in aanroepen naar HashAlgorithm.Create of CryptoConfig.CreateFromName)
- SHA512CryptoServiceProvider (FIPS-compatibel)
- SHA256CryptoServiceProvider (FIPS-compatibel)
- SHA384CryptoServiceProvider (FIPS-compatibel)
|
Gebruik sterke versleutelingsalgoritmen om gegevens in de database te versleutelen
Titel |
Bijzonderheden |
Onderdeel |
gegevensbank |
SDL-fase |
Bouwen |
Toepasselijke technologieën |
Algemeen |
Kenmerken |
Niet van toepassing. |
Verwijzingen |
Een versleutelingsalgoritme kiezen |
Stappen |
Versleutelingsalgoritmen definiëren gegevenstransformaties die niet gemakkelijk kunnen worden teruggedraaid door onbevoegde gebruikers. Met SQL Server kunnen beheerders en ontwikkelaars kiezen uit verschillende algoritmen, waaronder DES, Triple DES, TRIPLE_DES_3KEY, RC2, RC4, 128-bits RC4, DESX, 128-bits AES, 192-bits AES en 256-bits AES |
SSIS-pakketten moeten worden versleuteld en digitaal worden ondertekend
Titel |
Bijzonderheden |
Onderdeel |
gegevensbank |
SDL-fase |
Bouwen |
Toepasselijke technologieën |
Algemeen |
Kenmerken |
Niet van toepassing. |
Verwijzingen |
Identificeer de bron van pakketten met digitale handtekeningen, beperking van bedreigingen en kwetsbaarheden (integratieservices) |
Stappen |
De bron van een pakket is de persoon of organisatie die het pakket heeft gemaakt. Het uitvoeren van een pakket vanuit een onbekende of niet-vertrouwde bron kan riskant zijn. Om ongeoorloofd knoeien met SSIS-pakketten te voorkomen, moeten digitale handtekeningen worden gebruikt. Om de vertrouwelijkheid van de pakketten tijdens opslag/transport te waarborgen, moeten SSIS-pakketten ook worden versleuteld |
Voeg een digitale handtekening toe aan kritieke database-beveiligingsobjecten
Titel |
Bijzonderheden |
Onderdeel |
gegevensbank |
SDL-fase |
Bouwen |
Toepasselijke technologieën |
Algemeen |
Kenmerken |
Niet van toepassing. |
Verwijzingen |
HANDTEKENING TOEVOEGEN (Transact-SQL) |
Stappen |
In gevallen waarin de integriteit van een kritieke databank die kan worden beveiligd, moet worden geverifieerd, moeten digitale handtekeningen worden gebruikt. Database-beveiligbare items zoals een opgeslagen procedure, functie, assembly of trigger kunnen digitaal worden ondertekend. Hieronder ziet u een voorbeeld van wanneer dit nuttig kan zijn: Laten we zeggen dat een ISV (Independent Software Vendor) ondersteuning heeft geboden aan software die aan een van hun klanten is geleverd. Alvorens ondersteuning te bieden, wil de ISV zich ervan vergewissen dat er niet per ongeluk of door een kwaadwillige poging met een database is geknoeid die in de software kan worden beveiligd. Als het beveiligde object digitaal is ondertekend, kan de ISV de digitale handtekening verifiëren en de integriteit ervan valideren. |
SQL Server EKM gebruiken om coderingssleutels te beschermen
Titel |
Bijzonderheden |
Onderdeel |
gegevensbank |
SDL-fase |
Bouwen |
Toepasselijke technologieën |
Algemeen |
Kenmerken |
Niet van toepassing. |
Verwijzingen |
SQL Server Extensible Key Management (EKM),Extrinible Key Management met behulp van Azure Key Vault (SQL Server) |
Stappen |
Met SQL Server Extensible Key Management kunnen de versleutelingssleutels die de databasebestanden beveiligen, worden opgeslagen op een kant-en-klaar apparaat, zoals een smartcard, USB-apparaat of EKM/HSM-module. Dit maakt ook gegevensbescherming mogelijk tegen databasebeheerders (behalve leden van de sysadmin-groep). Gegevens kunnen worden versleuteld met behulp van coderingssleutels waartoe alleen de databasegebruiker toegang heeft op de externe EKM/HSM-module. |
Gebruik de functie AlwaysEncrypted als coderingssleutels niet mogen worden onthuld aan de database-engine
Titel |
Bijzonderheden |
Onderdeel |
gegevensbank |
SDL-fase |
Bouwen |
Toepasselijke technologieën |
SQL Azure, OnPrem |
Kenmerken |
SQL-versie - V12, MsSQL2016 |
Verwijzingen |
Altijd Versleuteld (Database Engine) |
Stappen |
Always Encrypted is een functie die is ontworpen om gevoelige gegevens te beschermen, zoals creditcardnummers of nationale/regionale identificatienummers (bijvoorbeeld Amerikaanse burgerservicenummers), die zijn opgeslagen in Azure SQL Database- of SQL Server-databases. Met Always Encrypted kunnen clients gevoelige gegevens in clienttoepassingen versleutelen en de versleutelingssleutels nooit zichtbaar maken voor de Database Engine (SQL Database of SQL Server). Als gevolg hiervan biedt Always Encrypted een scheiding tussen degenen die eigenaar zijn van de gegevens (en deze kunnen bekijken) en degenen die de gegevens beheren (maar geen toegang zouden moeten hebben) |
Bewaar cryptografische sleutels veilig op een IoT-apparaat
Titel |
Bijzonderheden |
Onderdeel |
IoT-apparaat |
SDL-fase |
Bouwen |
Toepasselijke technologieën |
Algemeen |
Kenmerken |
Besturingssysteem van het apparaat - Windows IoT Core, Apparaatconnectiviteit - SDK's voor Azure IoT-apparaten |
Verwijzingen |
TPM op Windows IoT Core, TPM instellen op Windows IoT Core, Azure IoT Device SDK TPM |
Stappen |
Symmetrische of gecertificeerde privésleutels veilig in een hardwarebeveiligde opslag zoals TPM- of smartcardchips. Windows 10 IoT Core ondersteunt de gebruiker van een TPM en er zijn verschillende compatibele TPM's die kunnen worden gebruikt: Discrete TPM (dTPM). Het wordt aanbevolen om een firmware of discrete TPM te gebruiken. Een Software TPM mag alleen worden gebruikt voor ontwikkelings- en testdoeleinden. Zodra een TPM beschikbaar is en de sleutels erin zijn ingericht, moet de code die het token genereert, worden geschreven zonder gevoelige informatie erin hard te coderen. |
Voorbeeld
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);
Zoals te zien is, is de primaire sleutel van het apparaat niet aanwezig in de code. In plaats daarvan wordt het opgeslagen in de TPM bij sleuf 0. TPM-apparaat genereert een SAS-token met een korte levensduur dat vervolgens wordt gebruikt om verbinding te maken met de IoT Hub.
Genereer een willekeurige symmetrische sleutel van voldoende lengte voor verificatie bij IoT Hub
Titel |
Bijzonderheden |
Onderdeel |
IoT Cloud Gateway |
SDL-fase |
Bouwen |
Toepasselijke technologieën |
Algemeen |
Kenmerken |
Gatewaykeuze - Azure IoT Hub |
Verwijzingen |
Niet van toepassing. |
Stappen |
IoT Hub bevat een identiteitsregister voor apparaten en genereert tijdens het inrichten van een apparaat automatisch een willekeurige symmetrische sleutel. Het wordt aanbevolen om deze functie van het Azure IoT Hub Identity Registry te gebruiken om de sleutel te genereren die wordt gebruikt voor verificatie. IoT Hub maakt het ook mogelijk om een sleutel op te geven tijdens het maken van het apparaat. Als een sleutel buiten IoT Hub wordt gegenereerd tijdens de inrichting van het apparaat, is het raadzaam om een willekeurige symmetrische sleutel of ten minste 256 bits te maken. |
Zorg ervoor dat er een beleid voor apparaatbeheer is dat een gebruikspincode vereist en wissen op afstand toestaat
Titel |
Bijzonderheden |
Onderdeel |
Dynamics CRM mobiele client |
SDL-fase |
Uitrol |
Toepasselijke technologieën |
Algemeen |
Kenmerken |
Niet van toepassing. |
Verwijzingen |
Niet van toepassing. |
Stappen |
Zorg ervoor dat er een beleid voor apparaatbeheer is dat een gebruikspincode vereist en wissen op afstand toestaat |
Zorg ervoor dat er een beleid voor apparaatbeheer is dat een pincode/wachtwoord/automatische vergrendeling vereist en alle gegevens versleutelt (bijv. BitLocker)
Titel |
Bijzonderheden |
Onderdeel |
Dynamics CRM Outlook-client |
SDL-fase |
Bouwen |
Toepasselijke technologieën |
Algemeen |
Kenmerken |
Niet van toepassing. |
Verwijzingen |
Niet van toepassing. |
Stappen |
Zorg ervoor dat er een beleid voor apparaatbeheer is dat een pincode/wachtwoord/automatische vergrendeling vereist en alle gegevens versleutelt (bijv. BitLocker) |
Zorg ervoor dat ondertekeningssleutels worden doorgerold wanneer u Identity Server gebruikt
Titel |
Bijzonderheden |
Onderdeel |
Identiteitsserver |
SDL-fase |
Uitrol |
Toepasselijke technologieën |
Algemeen |
Kenmerken |
Niet van toepassing. |
Verwijzingen |
Niet van toepassing. |
Stappen |
Zorg ervoor dat ondertekeningssleutels worden doorgerold wanneer u Identity Server gebruikt. De link in de sectie verwijzingen legt uit hoe dit moet worden gepland zonder storingen te veroorzaken in toepassingen die afhankelijk zijn van Identity Server. |
Zorg ervoor dat cryptografisch sterke client-ID en clientgeheim worden gebruikt in Identity Server
Titel |
Bijzonderheden |
Onderdeel |
Identiteitsserver |
SDL-fase |
Bouwen |
Toepasselijke technologieën |
Algemeen |
Kenmerken |
Niet van toepassing. |
Verwijzingen |
Niet van toepassing. |
Stappen |
Zorg ervoor dat cryptografisch sterke client-id en clientgeheim worden gebruikt in Identity Server. De volgende richtlijnen moeten worden gebruikt bij het genereren van een client-ID en geheim: - Genereer een willekeurige GUID als client-ID
- Genereer een cryptografisch willekeurige 256-bits sleutel als het geheim
|