Beveilig de gegevens van uw organisatie met deze encryptie-algoritmen

Key Takeaways

• AES-256 (symmetrisch) is momenteel de standaard voor het versleutelen van opgeslagen en onderweg zijnde data. Combineer het met RSA-3072 of ECC P-384 (asymmetrisch) voor sleuteluitwisseling, TLS en digitale handtekeningen.
• NIST SP 800-57 stelt de minimale sleutelgrootte vast: RSA-2048/ECC P-256 blijven op korte termijn bruikbaar, maar NIST IR 8547 plaatst RSA en ECC rond 2030 op een uitfaseringstraject en rond 2035 op een lijst met niet-toegestane sleutels.
• Het implementeren of roteren van een encryptiealgoritme in een productieomgeving vereist voorwaarden, genummerde stappen, validatiecontroles, terugdraaimogelijkheden en auditregistratie, en geen ad-hoc sleutelwisseling.
• Bewaar en beheer sleutels in een HSM of een beheerde sleutelbeheerservice. Sleutelmateriaal mag nooit in applicatieconfiguratiebestanden, omgevingsvariabelen of versiebeheer worden opgeslagen.
• Post-kwantumalgoritmen (FIPS 203 ML-KEM, FIPS 204 ML-DSA, FIPS 205 SLH-DSA) zijn afgerond en verdienen nu al aandacht bij nieuwe architectuurbeslissingen, ook al richt deze handleiding zich op de huidige productiestandaardalgoritmen.

Gepubliceerd: juli 2022. Bijgewerkt: augustus 2026. Beoordeeld door het cryptografieteam van Encryption Consulting.

Wat is cryptografie en welke rol spelen encryptie en decryptie daarin?

Cryptografie is de praktijk van het beschermen van informatie met behulp van wiskundige technieken, zodat alleen bevoegde partijen de informatie kunnen lezen of gebruiken. Versleuteling en ontsleuteling zijn de twee kernbewerkingen: versleuteling zet leesbare gegevens (platte tekst) om in een onleesbare vorm (cijfertekst) met behulp van een algoritme en een sleutel, en ontsleuteling draait die transformatie om voor iemand die de juiste sleutel bezit. Deze handleiding gaat ervan uit dat u al bekend bent met de basisprincipes van versleuteling en ontsleuteling. Voor de volledige definities kunt u de artikelen in het Education Center van Encryption Consulting raadplegen over wat cryptografie is en wat versleuteling is . Wat hierna volgt, is operationeel: welke algoritmen u moet kiezen en hoe u deze in een productieomgeving implementeert, roteert, valideert en controleert.

Welke encryptiealgoritmes moet je tegenwoordig gebruiken?

Twee algoritmefamilies dekken vrijwel elke beslissing die in productieomgevingen wordt genomen met betrekking tot encryptie: symmetrische algoritmen, die één gedeelde sleutel gebruiken voor zowel encryptie als decryptie, en asymmetrische algoritmen, die een wiskundig gekoppeld paar van publieke en private sleutels gebruiken. AES behandelt de symmetrische kant. RSA en ECC behandelen de asymmetrische kant.

Advanced Encryption Standard (AES)

AES is een symmetrische blokversleuteling die door NIST is gestandaardiseerd in FIPS 197. Het versleutelt datablokken van vaste grootte met behulp van een gedeelde geheime sleutel van 128, 192 of 256 bits. AES-256 is de aanbevolen sleutelgrootte voor nieuwe implementaties ter bescherming van gevoelige bedrijfsgegevens, omdat het de grootste veiligheidsmarge biedt tegen brute-force-aanvallen en de geaccepteerde basislijn is voor compliance-frameworks zoals HIPAA, PCI DSS en GDPR-conforme gegevensbeschermingsmaatregelen. AES-128 blijft goedgekeurd en is sneller op hardware met beperkte middelen, maar AES-256 is de standaardkeuze wanneer gegevens een lange vertrouwelijkheidsperiode hebben.

RSA (Rivest-Shamir-Adleman)

RSA is een asymmetrisch algoritme dat gebaseerd is op de moeilijkheid om grote getallen te ontbinden in factoren. Het gebruikt een publieke sleutel om gegevens te versleutelen of een handtekening te verifiëren, en een privésleutel om gegevens te ontsleutelen of een handtekening te creëren. RSA wordt veel gebruikt voor TLS-sleuteluitwisseling, codeondertekening en certificaatuitgifte. Gebruik voor nieuwe implementaties RSA-3072 of hoger. RSA-2048 is nog steeds toegestaan ​​volgens de huidige NIST-richtlijnen, maar het bevindt zich dichter bij de grens van afschrijving en biedt minder bescherming tegen geavanceerde factorisatietechnieken dan RSA-3072. Zie RSA Padding Explained voor meer informatie over hoe de keuze van het padding-schema (PKCS#1 v1.5, OAEP of PSS) de daadwerkelijke RSA-beveiliging beïnvloedt.

ECC (elliptische curve-cryptografie)

ECC is een asymmetrische benadering gebaseerd op de algebraïsche structuur van elliptische krommen. Het biedt een vergelijkbare beveiliging als RSA, maar met een veel kleinere sleutelgrootte: een 256-bits ECC-sleutel (kromme P-256) biedt ongeveer dezelfde beveiligingsmarge als een 3072-bits RSA-sleutel, en een 384-bits ECC-sleutel (kromme P-384) biedt een nog hogere marge. Die kleinere sleutelgrootte betekent snellere handshakes en een lagere bandbreedte, waardoor ECC (doorgaans ECDSA voor handtekeningen en ECDH voor sleuteluitwisseling) de standaard asymmetrische keuze is geworden voor moderne TLS-, mobiele en IoT-implementaties. Gebruik P-256 als algemene basislijn en P-384 wanneer de data of de workload een hogere beveiligingsmarge vereist.

Triple DES (3DES): Verouderd, niet voor nieuw gebruik

Triple DES past de oorspronkelijke DES-codering drie keer toe met twee of drie 56-bits sleutels. Het was twintig jaar geleden een redelijk brugalgoritme, maar NIST heeft SP 800-67 Revisie 2, de publicatie die Triple DES goedkeurde, per 1 januari 2024 ingetrokken. Triple DES zou niet meer in nieuwe ontwerpen moeten voorkomen en elk systeem dat het nog gebruikt, heeft een migratieplan naar AES-256 nodig. Zie Waarom 3DES of Triple DES officieel wordt uitgefaseerd voor de volledige context van de migratie.

Symmetrisch versus asymmetrisch: welke voor welk gebruik?

Symmetrische encryptie (AES) is sneller en rekenkundig goedkoper, waardoor het geschikt is voor het verwerken van grote hoeveelheden data: databases, bestandssystemen, back-ups en de payload van een TLS-sessie zodra de handshake is voltooid. Asymmetrische encryptie (RSA of ECC) is trager, maar lost een probleem op dat symmetrische encryptie niet kan oplossen: het uitwisselen van een geheim met iemand met wie je geen gedeelde sleutel hebt, en het bewijzen van identiteit door middel van digitale handtekeningen. In de praktijk gebruiken productiesystemen beide methoden samen: asymmetrische algoritmen bouwen vertrouwen op en wisselen een sessiesleutel uit, en een symmetrisch algoritme voert de daadwerkelijke bulkencryptie uit. Voor een uitgebreidere uitleg van de werking van gedeelde sleutels, zie Wat is symmetrische encryptie? De beslissingstabel verderop in deze handleiding koppelt elk algoritme aan het typische productiegebruiksscenario en de aanbevolen sleutelgrootte.

Wat zijn de voorwaarden voor het implementeren of roteren van een encryptiealgoritme in een productieomgeving?

Voordat u een productieversleutelingsalgoritme of -sleutel aanraakt, moet u controleren of aan de volgende voorwaarden is voldaan:

1. Een cryptografische inventaris. Ken elk systeem, certificaat en opgeslagen dataset dat gebruikmaakt van het algoritme of de sleutel die u wilt wijzigen. U kunt niet iets roteren wat u niet hebt gevonden.
2. Essentiële beheerinfrastructuur. Een HSM of een beheerde sleutelbeheerservice (KMS) wordt gebruikt om de nieuwe sleutel te genereren, op te slaan en de toegang ertoe te beheren. Sleutels mogen nooit in de applicatiecode worden gegenereerd of opgeslagen.
3. Toegangscontrole en goedkeuringsworkflow. Er zijn duidelijke rollen vastgelegd voor wie een sleutelrotatie of algoritmewijziging kan aanvragen, goedkeuren en uitvoeren, met functiescheiding voor waardevolle sleutels.
4. Een back-up van de huidige sleutels en versleutelde gegevens. De gegevens zijn vastgelegd en de herstelbaarheid is geverifieerd voordat er wijzigingen worden aangebracht.
5. Een onderhoudsvenster of een venster met weinig verkeer, als de wijziging vereist dat de gegevens ter plaatse opnieuw worden versleuteld in plaats van alleen nieuwe schrijfbewerkingen.
6. Een terugdraaiplan en een logboekplan. Beide aspecten zijn vastgelegd en beoordeeld vóór de uitvoering, en worden niet geïmproviseerd nadat er iets misgaat.

Hoe implementeer of roteer je een encryptiealgoritme in een productieomgeving?

Volg deze stappen voor het implementeren van een nieuw algoritme of het uitvoeren van een geplande sleutelrotatie:

1. Genereer de nieuwe sleutel in de HSM of KMS. Gebruik hiervoor het gewenste algoritme en de sleutelgrootte (bijvoorbeeld AES-256 of RSA-3072). Exporteer het onbewerkte sleutelmateriaal nooit naar een algemeen bestandssysteem.
2. Registreer de nieuwe sleutel met een unieke sleutel-ID of versie. Zo kunnen applicaties er expliciet naar verwijzen en kunnen zowel de oude als de nieuwe sleutel naast elkaar bestaan ​​tijdens de overgang.
3. Implementeer de nieuwe sleutel eerst in een beperkte pilotomgeving. (één dienst, één gegevensopslag of één certificaat) in plaats van het volledige systeem.
4. Versleutel nieuwe gegevens met de nieuwe sleutel. waarbij de bestaande versleutelde tekst onder de oude sleutel behouden blijft, tenzij volledige herversleuteling vereist is volgens het beleid.
5. Voer de validatiecontroles uit. hieronder beschreven aan de hand van de pilot scope voordat deze verder wordt uitgebreid.
6. De resterende werkzaamheden gefaseerd uitrollen. Valideren in elke fase in plaats van in één keer uit te rollen naar de gehele omgeving.
7. Versleutel of migreer historische gegevens met de nieuwe sleutel. Indien het beleid dit vereist, de voortgang bijhouden ten opzichte van de volledige inventarisatie uit de fase van de randvoorwaarden.
8. De oude sleutel of het oude algoritme buiten gebruik stellen. pas nadat elke gebruiker de migratie heeft bevestigd en de bewaartermijn voor gegevens die met de oude sleutel zijn versleuteld, is verstreken.

Hoe valideer je een encryptie-implementatie voordat je het oude algoritme buiten gebruik stelt?

Controleer alles vóórdat u het buiten gebruik stelt, niet erna. Controleer in ieder geval het volgende:

• Gegevens die met de nieuwe sleutel of het nieuwe algoritme zijn versleuteld, worden correct gedecodeerd en komen overeen met de oorspronkelijke platte tekst (vergelijking van de checksum of hash met een bekende, correcte kopie).
• Alle gebruikers van de applicatie kunnen de nieuwe sleutel via de HSM of KMS bereiken met de juiste machtigingen, getest onder de verwachte productiebelasting.
• TLS-handshakes, digitale handtekeningen of certificaatketens die afhankelijk zijn van het nieuwe algoritme, worden correct gevalideerd door de betreffende clients, browsers of partnersystemen.
• De prestaties (latentie, doorvoer) van het nieuwe algoritme voldoen aan dezelfde serviceniveaus als het oude, omdat asymmetrische algoritmen met grotere sleutelgroottes meetbare overhead met zich meebrengen voor de handshake op grote schaal.
• Back-up- en noodherstelprocessen kunnen gegevens herstellen die zijn versleuteld met de nieuwe sleutel. Dit wordt getest aan de hand van een daadwerkelijke herstelprocedure, niet alleen een gedocumenteerde procedure.

Wat is de terugdraaiprocedure als een encryptie-implementatie mislukt?

Definieer de terugdraaitrigger en -procedure vóór de implementatie begint, niet tijdens een incident. Een typische terugdraaiing:

1. Stop nieuwe schrijfbewerkingen onder de nieuwe sleutel of het nieuwe algoritme en herstel de applicatieconfiguratie zodat deze weer verwijst naar de vorige sleutel-ID.
2. Controleer of de oude sleutel nog steeds actief is in de HSM of KMS (daarom wordt in de voorwaardestap gevraagd om co-existentie in plaats van onmiddellijke uitschakeling).
3. Herstel alle gegevens die tijdens de mislukte uitrol opnieuw zijn versleuteld vanuit de back-up van vóór de wijziging, indien het herversleutelingsproces al was gestart.
4. Controleer de functionaliteit van de applicatie aan de hand van de herstelde status met behulp van dezelfde validatiecontroles die werden gebruikt voor de implementatie naar de oorspronkelijke staat.
5. Registreer de terugdraaigebeurtenis, de triggerconditie en de onderliggende oorzaak, en houd de nieuwe sleutel- of algoritmewijziging tegen totdat de onderliggende oorzaak is opgelost en opnieuw is getest.

Een terugdraaiplan werkt alleen als het oude algoritme of de oude sleutel actief is gebleven tijdens de pilot en de gefaseerde uitrol. Daarom is de buitenbedrijfstelling de laatste stap in het bovenstaande implementatieproces, en niet een van de eerste.

Hoe moet u het gebruik en de rotatie van encryptiesleutels registreren en controleren?

Elke gebeurtenis met betrekking tot het genereren, openen, roteren en buitenbedrijf stellen van een sleutel vereist een auditspoor dat een compliance-auditor of incidentresponder onafhankelijk van het team dat de actie heeft uitgevoerd, kan controleren. Registreer minimaal het volgende:

• Wie (of welke service-identiteit) heeft elke gebeurtenis voor het genereren of roteren van sleutels aangevraagd, goedgekeurd en uitgevoerd, inclusief tijdstempel.
• Welke sleutel-ID of -versie werd gebruikt voor elke versleutelings- of ontsleutelingsbewerking, zodat u elke dataset kunt herleiden naar de exacte sleutel die deze beschermde.
• Elke mislukte decryptiepoging of geweigerde toegang tot een sleutel is vaak het eerste signaal van een verkeerde configuratie of een poging tot ongeautoriseerde toegang.
• Belangrijke gebeurtenissen in het ontmantelingsproces, waaronder de bevestiging dat alle afhankelijke afnemers eerst zijn gemigreerd.

De meeste HSM's en beheerde KMS-platforms genereren deze logboekregistratie standaard; de operationele uitdaging zit hem meestal in het doorsturen van die logboeken naar een SIEM- of auditsysteem dat uw compliance-team daadwerkelijk controleert, in plaats van ze in de lokale logopslag van de HSM te laten staan.

Wat zijn veelvoorkomende implementatiefouten en hoe los je ze op?

Symptoom	waarschijnlijke oorzaak	Probleemoplossing Stap
Na een sleutelrotatie mislukt decryptie.	De applicatie heeft de oude sleutelreferentie in de cache opgeslagen of is niet bijgewerkt naar de nieuwe sleutel-ID.	Controleer de configuratie van de belangrijkste referenties van de applicatie en forceer een cacheverversing of herstart in een gecontroleerd venster.
TLS-handshakefouten na overschakeling naar een grotere sleutelgrootte	Een oudere client of load balancer ondersteunt het nieuwe algoritme of de nieuwe curve niet.	Controleer de compatibiliteit van de client en tussenliggende partijen (browsers, API-clients, load balancers) vóór de pilotfase, niet na de volledige uitrol.
Onverwachte toename van de latentie	Asymmetrische bewerkingen (met name RSA) met een grotere sleutelgrootte verhogen de CPU-kosten per verbinding.	Controleer of TLS-sessiehervatting en verbindingpooling zijn ingeschakeld; overweeg ECC om de kosten per handshake te verlagen.
Sommige gegevens kunnen na "voltooiing van de rotatie" nog steeds met de oude sleutel worden gedecodeerd.	De cryptografische inventaris uit de stap met de voorwaarden miste een gegevensopslag of back-uparchief.	Voer de inventarisatie opnieuw uit, inclusief back-ups en gearchiveerde systemen, voordat u de oude sleutel buiten gebruik stelt.
Toegang tot een legitieme dienst is geweigerd.	Het toegangsbeleid voor de nieuwe sleutel is niet bijgewerkt om overeen te komen met de machtigingen van de oude sleutel.	Vergelijk het IAM- of HSM-toegangsbeleid tussen de oude en de nieuwe sleutel vóór de pilotfase.

Welke operationele resultaten moet u meten?

Volg deze resultaten om te weten of een implementatie of rotatie van een encryptiealgoritme daadwerkelijk is geslaagd, en niet alleen dat deze is voltooid:

• Geen ongeplande downtime toe te schrijven aan de sleutelrotatie of algoritmewijziging, gemeten aan de hand van uw standaard incidentregistratie.
• De volledige cryptografische inventaris is gemigreerd. overschakelen naar de nieuwe sleutel of het nieuwe algoritme binnen de geplande tijdlijn, zonder dat er nog systemen op de oude sleutel of het oude algoritme achterblijven.
• Slagingspercentage van de nalevingsaudit voor controles die verband houden met het beheer van encryptiesleutels (frequentie van sleutelrotatie, toegangsregistratie, goedkeuring van algoritmen), zoals blijkt uit het auditspoor van de registratiestap.
• Gemiddelde tijd om te roteren Een sleutel of algoritme, dat gedurende opeenvolgende rotaties wordt bijgehouden, zou een dalende trend moeten vertonen naarmate het draaiboek zich verder ontwikkelt.
• Er werden later nul buiten gebruik gestelde sleutels gevonden die nog steeds in gebruik waren. bevestigd door de ontdekkingsfase voorafgaand aan elke ontmanteling.

Welk encryptiealgoritme is het meest geschikt voor uw toepassing?

Algoritme	Type	Typisch gebruiksscenario	Aanbevolen sleutelgrootte
AES-256	Symmetrisch	Gegevens in rust (databases, schijven, back-ups), TLS-bulkversleuteling	256-bits sleutel
AES-128	Symmetrisch	Latentiegevoelige of resourcebeperkte workloads	128-bits sleutel (256-bits heeft de voorkeur voor langdurige gegevens)
RSA	asymmetrisch	TLS-sleuteluitwisseling, codeondertekening, certificaatuitgifte	Minimaal 3072-bit voor nieuwe implementaties; 2048-bit is momenteel de ondergrens.
ECC (ECDSA / ECDH)	asymmetrisch	Moderne TLS, certificaatondertekening, mobiele apparaten en IoT-apparaten	P-256 basislijn, P-384 voor een hogere veiligheidsmarge
ML-KEM (FIPS 203)	Post-kwantum, asymmetrische sleutelinkapseling	Vroege proefprojecten voor kwantumresistente sleuteluitwisseling naast klassieke algoritmen	ML-KEM-768 of ML-KEM-1024, afhankelijk van de implementatie.
Drievoudige DES (3DES)	Symmetrisch, erfgoed	Niet voor nieuw gebruik; NIST heeft de goedkeuring ingetrokken met ingang van 1 januari 2024.	Niet van toepassing, migreer naar AES-256

Waarom zouden we bedrijfsgegevens versleutelen en ontsleutelen?

• Beschermt de vertrouwelijkheid van gegevens.

  Als een systeem wordt gehackt, zijn correct versleutelde gegevens onleesbaar voor de aanvaller zonder de bijbehorende sleutel. Dit beperkt de schade van de inbreuk, zelfs nadat er ongeautoriseerde toegang heeft plaatsgevonden.

• Ondersteunt verificatie van de gegevensintegriteit.

  Digitale handtekeningen en hashfuncties stellen u in staat te bevestigen dat gegevens niet zijn gewijzigd tijdens overdracht of opslag, iets wat encryptie alleen niet garandeert.

• Beveiligt netwerkcommunicatie.

  Versleutelde kanalen (TLS, VPN's) voorkomen dat een aanvaller die netwerkverkeer onderschept de gegevens tijdens de overdracht kan lezen of manipuleren, waardoor man-in-the-middle-aanvallen worden geblokkeerd.

• Beschermt persoonsgegevens en medische gegevens.

  Door persoonsgegevens en beschermde gezondheidsinformatie te versleutelen, blijven deze gegevens onleesbaar, zelfs als onbevoegde gebruikers er toegang toe krijgen. Dit draagt ​​bij aan de naleving van HIPAA, GDPR en CCPA.

• Beschermt intellectueel eigendom.

  Het versleutelen van broncode, onderzoeksgegevens en vertrouwelijke content beperkt de blootstelling in geval van een inbreuk op opslag- of transportsystemen.

Wat zijn de beperkingen van deze encryptiealgoritmen?

Geen enkele algoritmekeuze is op zichzelf een complete oplossing. Houd rekening met de volgende beperkingen bij het plannen van een implementatie:

• Asymmetrische bewerkingen zijn op grote schaal rekenkundig zeer kostbaar. RSA en, in mindere mate, ECC voegen meetbare CPU-kosten en latentiekosten per verbinding toe. Daarom worden ze in productiesystemen gecombineerd met symmetrische encryptie in plaats van gebruikt voor bulkdata.
• Sleutelbeheer is lastiger dan algoritmeselectie. Een correct gekozen algoritme, beschermd door een zwak sleutelbeheerproces (sleutels in versiebeheer, geen rotatie, brede toegang), is niet echt veilig.
• RSA en ECC worden geconfronteerd met een kwantumdreiging op de lange termijn. Een cryptografisch relevante kwantumcomputer zou beide systemen kraken met behulp van Shors algoritme. Dit vormt voor de meeste organisaties geen direct operationeel risico, maar data met een lange geheimhoudingsperiode worden tegenwoordig al verzameld met de bedoeling om het later te decoderen.
• Post-kwantumalgoritmen zijn operationeel nog in ontwikkeling. FIPS 203, 204 en 205 zijn definitieve standaarden, maar de ondersteuning voor bibliotheken, hardwareversnelling en protocolintegratie (hybride klassieke/PQC-handshakes) wordt nog steeds door verschillende leveranciers uitgerold.
• Implementatiefouten ondermijnen sterke algoritmen. Zwakke opvulschema's, gebrekkige willekeurige getallengeneratie en nevenkanaallekken hebben allemaal geleid tot problemen in de praktijk met verder prima algoritmen; een algoritme is immers maar zo sterk als de implementatie ervan.

Wat zou Encryption Consulting aanbevelen?

Begin met de cryptografische inventarisatie. U kunt geen algoritme correct kiezen, implementeren of roteren voor gegevens die u niet hebt geïdentificeerd. CBOM Secure van Encryption Consulting detecteert en inventariseert de algoritmen, sleutels en certificaten die al in uw omgeving actief zijn, waardoor de bovenstaande beslissingstabel een concreet migratieplan wordt in plaats van een algemene referentie.

Zodra u weet wat u wilt beschermen, kunt u het genereren en opslaan van sleutels overzetten naar een hardwarematige beveiligingsmodule in plaats van sleutelmateriaal in de applicatieconfiguratie te laten staan. HSM-as-a-Service biedt u FIPS 140-gevalideerde sleutelopslag zonder de investeringskosten of operationele lasten van het zelf beheren van HSM-hardware. Bovendien gaan de implementatiestappen in deze handleiding ervan uit dat u deze infrastructuur al bezit.

Organisaties die hulp nodig hebben bij het ontwerpen van het draaiboek zelf, het selecteren van de juiste sleutelgroottes voor een specifieke complianceverplichting, of het plannen van de pilotfase tot volledige uitrol, kunnen bij Encryption Consulting's Encryption Advisory- service samenwerken met uw team om een ​​implementatieplan op te stellen dat is afgestemd op uw omgeving, in plaats van een generieke checklist. Encryption Consulting is ISO/IEC 27001:2022 en SOC 2 gecertificeerd, waardoor wij zelf dezelfde controles hanteren als in deze handleiding voor uw omgeving wordt aanbevolen.

Conclusie

Het kiezen van een encryptiealgoritme is het makkelijke deel: AES-256 voor data in rust en tijdens transport, RSA-3072 of ECC P-384 voor sleuteluitwisseling en digitale handtekeningen, en een gedocumenteerd migratieplan voor eventuele resterende Triple DES. Het moeilijkere deel, en het deel dat daadwerkelijk bepaalt of de data van uw organisatie beschermd blijven, is de operationele discipline rond de implementatie: een cryptografische inventarisatie voordat u begint, een gefaseerde uitrol met validatie bij elke stap, een getest terugdraaiplan, een auditlogboek voor elke belangrijke gebeurtenis en meetbare resultaten die u na elke rotatie evalueert. Behandel de implementatie van een encryptiealgoritme als een productiewijziging met dezelfde nauwkeurigheid als elke andere wijziging, en het voorkomt dat het een terugkerende bron van storingen, auditbevindingen en ongeplande terugdraaiingen wordt.

Veelgestelde Vragen / FAQ

Wat is momenteel het veiligste encryptiealgoritme voor bedrijfsgegevens? Voor symmetrische encryptie is AES-256 de huidige standaard voor gevoelige bedrijfsgegevens. Voor asymmetrische encryptie worden RSA-3072 of ECC P-384 aanbevolen voor nieuwe implementaties. Er bestaat geen enkel algoritme dat universeel "het veiligst" is, ongeacht het gebruik; de combinatie van AES voor bulkdata met RSA of ECC voor sleuteluitwisseling en digitale handtekeningen is wat in productiesystemen daadwerkelijk wordt gebruikt.

Moeten we overstappen op RSA-3072 als we momenteel RSA-2048 gebruiken? RSA-2048 blijft een geaccepteerd minimum volgens de huidige NIST-richtlijnen, dus er is geen noodsituatie die een onmiddellijke overstap vereist. Voor nieuwe systemen en voor gegevens met een lange geheimhoudingsperiode is het raadzaam om RSA-3072 te implementeren of over te stappen op ECC P-256/P-384, wat een gelijkwaardige of betere beveiliging biedt met een kleinere sleutelgrootte en lagere handshake-kosten.

Moeten we ons nu al zorgen maken over post-kwantumcryptografie? NIST heeft in augustus 2024 de eerste drie post-kwantumstandaarden, FIPS 203 (ML-KEM), FIPS 204 (ML-DSA) en FIPS 205 (SLH-DSA), afgerond. De meeste organisaties hoeven hun productiesystemen niet direct te migreren naar post-kwantumcryptografie-algoritmen, maar data met een meerjarige vertrouwelijkheidsvereiste worden al wel verzameld volgens het principe 'nu verzamelen, later decoderen'. Daarom is het verstandig om nu al te beginnen met het opstellen van een cryptografische inventaris en een plan voor cryptografische flexibiliteit, zelfs als de algoritme-omschakeling zelf pas later plaatsvindt.

Hoe vaak moeten we encryptiesleutels vernieuwen? De frequentie van het vernieuwen hangt af van de rol van de sleutel, de gegevens die deze beschermt en uw complianceverplichtingen; er is geen vast interval dat voor elke sleutel geldt. Belangrijker dan de exacte frequentie is dat het vernieuwen van sleutels altijd volgens een gedocumenteerd en getest stappenplan verloopt (voorwaarden, gefaseerde uitrol, validatie, terugdraaien), in plaats van een ad-hocproces dat varieert afhankelijk van wie het uitvoert.

Kunnen we tijdens een migratie verschillende encryptiealgoritmes in onze omgeving combineren? Ja, en in de praktijk is dat zelfs noodzakelijk. Bij een gefaseerde uitrol bestaan ​​oude en nieuwe algoritmes gedurende een bepaalde periode naast elkaar, terwijl gebruikers migreren. De in deze handleiding vereiste infrastructuur voor sleutelbeheer (een HSM of KMS met unieke sleutel-ID's) zorgt ervoor dat deze co-existentie veilig kan worden uitgevoerd en dat de implementatie indien nodig eenvoudig kan worden teruggedraaid.

Referenties

• NIST-onderzoek FIPS 197, Advanced Encryption Standard (AES)
• NIST-onderzoek SP 800-57 Deel 1 Revisie 5, Aanbeveling voor sleutelbeheer
• NIST-onderzoek SP 800-131A Revisie 2, Overgang naar andere cryptografische algoritmen en sleutellengtes
• NIST-onderzoek NIST trekt Special Publication 800-67 Revision 2 (Triple DES) in.
• NIST-onderzoek NIST publiceert de eerste 3 definitieve post-kwantumversleutelingsstandaarden (FIPS 203, 204, 205)