Hoe AES-256 Encryptie CMMC-naleving ondersteunt
Defensie-aannemers die Cybersecurity Maturity Model Certification (CMMC) 2.0 nastreven, staan voor een fundamentele vereiste: bescherm gecontroleerde niet-geclassificeerde informatie (CUI) met encryptie die voldoet aan federale cryptografische standaarden. AES-256 Encryptie voldoet aan deze vereiste wanneer het wordt geïmplementeerd via FIPS-gevalideerde cryptografische modules, maar het gebruik van alleen het encryptie-algoritme garandeert geen naleving. CMMC-beoordelaars onderzoeken niet alleen of encryptie aanwezig is, maar ook of deze correct is geïmplementeerd, op de juiste wijze gevalideerd is en ondersteund wordt door solide sleutelbeheerpraktijken.
De meeste organisaties binnen de industriële defensiebasis (DIB) zullen streven naar CMMC Level 2-certificering, die alle 110 beveiligingsmaatregelen uit NIST SP 800-171 omvat. Verschillende van deze maatregelen vereisen expliciet cryptografische bescherming van CUI in rust en onderweg. Begrijpen hoe AES-256 Encryptie aansluit op deze specifieke vereisten—en waar implementatie vaak tekortschiet—is essentieel voor het behalen en behouden van certificering.
Deze gids onderzoekt de encryptievereisten binnen CMMC Level 2, legt uit waarom AES-256 voldoet aan federale standaarden wanneer het correct wordt geïmplementeerd, en behandelt de cruciale vraag rondom encryptiesleutelbeheer wanneer CUI zich op cloudinfrastructuur bevindt.
Belangrijkste inzichten
- CMMC Level 2 vereist FIPS-gevalideerde encryptie voor het beschermen van CUI in rust en onderweg, met specifieke vereisten gedefinieerd in NIST SP 800-171 controls SC.L2-3.13.8 en SC.L2-3.13.16.
- Defensie-aannemers moeten FIPS-gevalideerde cryptografische modules gebruiken, niet alleen FIPS-goedgekeurde algoritmen—FIPS 140-3 validatie is de huidige standaard en toont toekomstgerichte naleving aan.
- AES-256 Encryptie voldoet aan de CMMC-cryptografische vereisten wanneer het wordt geïmplementeerd binnen een gevalideerde module en consistent wordt toegepast op alle systemen en communicatiekanalen waar CUI zich bevindt.
- Wanneer CUI zich op FedRAMP Authorized cloudinfrastructuur bevindt, heeft het eigenaarschap van encryptiesleutels direct invloed op de CMMC-nalevingsstatus—klant-eigen sleutels (waar alleen u toegang heeft tot de sleutels) bieden duidelijke controlegrenzen in tegenstelling tot klant-beheerde sleutels (waar de cloudprovider toegang behoudt).
- Praktijken rondom encryptiesleutelbeheer worden grondig beoordeeld tijdens CMMC-audits, inclusief documentatie van procedures voor sleutelgeneratie, opslag, rotatie en vernietiging in het Systeembeveiligingsplan.
CMMC Encryptievereisten per certificeringsniveau
CMMC 2.0 kent drie certificeringsniveaus, elk met eigen vereisten gebaseerd op de gevoeligheid van de te beschermen informatie. Level 2 is van toepassing op organisaties die CUI verwerken en vertegenwoordigt het certificeringsniveau dat de meeste DIB-aannemers zullen nastreven.
CMMC Level 1 is gericht op organisaties die alleen federale contractinformatie (FCI) verwerken en omvat 17 basismaatregelen voor beveiliging. Deze fundamentele controls bevatten geen expliciete encryptievereisten, hoewel encryptie wel wordt aanbevolen voor het beschermen van gevoelige gegevens.
CMMC Level 2 omvat alle 110 controls uit NIST SP 800-171 Revisie 2, inclusief specifieke vereisten voor cryptografische bescherming. De System and Communications Protection (SC) control-familie bevat de belangrijkste encryptie-eisen. Control SC.L2-3.13.8 vereist cryptografische mechanismen om CUI tijdens transmissie te beschermen, terwijl SC.L2-3.13.16 bescherming van CUI in rust vereist. Deze controls specificeren AES-256 niet bij naam, maar vereisen encryptie-implementaties die gebruikmaken van FIPS-gevalideerde cryptografische modules.
CMMC Level 3 is bedoeld voor organisaties die de meest gevoelige CUI verwerken en voegt controls uit NIST SP 800-172 toe. Deze aangescherpte vereisten kunnen strengere sleutelbeheerprocedures omvatten, vaker cryptografische beoordelingen vereisen en extra bescherming bieden tegen Advanced Persistent Threat (APT). Organisaties die Level 3 nastreven, moeten rekenen op strengere beoordeling van hun encryptiearchitectuur en sleutelbeheerpraktijken.
CMMC 2.0-naleving Stappenplan voor DoD-aannemers
Waarom AES-256 voldoet aan CMMC Level 2-standaarden
De Advanced Encryption Standard met 256-bits sleutels (AES-256) is goedgekeurd door het National Institute of Standards and Technology (NIST) voor het beschermen van geclassificeerde en niet-geclassificeerde federale informatie. Deze goedkeuring maakt AES-256 de juiste keuze voor CMMC-naleving, maar een cruciaal onderscheid bepaalt of uw implementatie daadwerkelijk aan de beoordelingsvereisten voldoet.
CMMC-beoordelaars controleren of encryptie is geïmplementeerd via FIPS-gevalideerde cryptografische modules, niet alleen of een FIPS-goedgekeurd algoritme wordt gebruikt. Een organisatie kan AES-256 Encryptie implementeren met niet-gevalideerde softwarebibliotheken en alsnog falen voor de CMMC-audit, ondanks het gebruik van het juiste algoritme. De cryptografische module zelf—of het nu software, firmware of hardware is—moet een geldig FIPS 140-certificaat hebben.
De federale overheid stapt over van FIPS 140-2 naar FIPS 140-3 als validatiestandaard voor cryptografische modules. FIPS 140-2-certificaten blijven geldig tot hun vervaldatum, maar nieuwe validaties worden afgegeven onder FIPS 140-3. Organisaties die encryptieoplossingen selecteren, moeten prioriteit geven aan FIPS 140-3 gevalideerde producten, die aantonen dat ze voldoen aan de huidige federale cryptografische vereisten en het risico vermijden van verouderde FIPS 140-2-certificaten die mogelijk verlopen tijdens een contractperiode.
De 256-bits sleutelgrootte biedt de juiste veiligheidsmarge voor het beschermen van CUI. Hoewel AES-128 ook NIST-goedgekeurd is, biedt AES-256 meer weerstand tegen toekomstige cryptanalytische ontwikkelingen en sluit het aan bij de voorkeur van het DoD voor het beschermen van gevoelige defensie-informatie.
CUI in rust versleutelen voor CMMC-naleving
NIST SP 800-171 control SC.L2-3.13.16 vereist dat organisaties de vertrouwelijkheid van CUI in rust beschermen. Deze vereiste geldt overal waar CUI wordt opgeslagen: bestandsservers, databases, endpoints, back-upsystemen, e-mailarchieven en cloudopslag.
Defensie-aannemers moeten alle locaties waar CUI zich bevindt identificeren en verifiëren dat encryptie elke opslagplaats beschermt. Veelvoorkomende opslagscenario’s die encryptie vereisen zijn: technische tekeningen en specificaties opgeslagen op bestandsdeling, contractdocumenten en correspondentie in documentbeheersystemen, e-mailarchieven met CUI die is uitgewisseld met overheidsinstanties of onderaannemers, databaserecords met gecontroleerde technische informatie, back-uptapes en systemen voor disaster recovery, en endpointapparaten zoals laptops van medewerkers met toegang tot CUI.
Encryptie in rust kan op meerdere niveaus worden geïmplementeerd. Volledige schijfversleuteling beschermt hele opslagvolumes, terwijl bestandsniveau-encryptie individuele bestanden beschermt, ongeacht waar ze worden opgeslagen of naartoe worden verplaatst. Database-encryptie beschermt gestructureerde gegevens binnen databasebeheersystemen. Veel organisaties passen gelaagde encryptie toe, waarbij volume- en bestandsniveaubescherming worden gecombineerd voor defense-in-depth.
De encryptie-implementatie moet gebruikmaken van een FIPS-gevalideerde module. Zelfversleutelende schijven, encryptiefuncties van besturingssystemen en oplossingen van derden vereisen allemaal FIPS 140-validatie om aan de CMMC-vereisten te voldoen. Organisaties moeten documentatie bijhouden van de FIPS-certificaatnummers voor elk encryptieproduct dat in hun omgeving wordt ingezet.
CUI onderweg versleutelen voor CMMC-naleving
NIST SP 800-171 control SC.L2-3.13.8 vereist cryptografische mechanismen om ongeautoriseerde openbaarmaking van CUI tijdens transmissie te voorkomen. Deze vereiste geldt voor alle communicatiekanalen die worden gebruikt om CUI te verzenden: netwerkverbindingen, e-mail, bestandsoverdracht en API-communicatie.
Transportlaagbeveiliging (TLS) vormt de basis voor de meeste transmissieversleuteling. TLS 1.2 en TLS 1.3 ondersteunen ciphersuites die AES-256 gebruiken voor bulkversleuteling en voldoen daarmee aan de cryptografische sterktevereisten voor het beschermen van CUI. Organisaties moeten hun systemen configureren om TLS 1.2 of hoger te vereisen en oudere protocolversies met bekende kwetsbaarheden uit te schakelen. TLS 1.3 biedt verbeterde beveiliging en prestaties ten opzichte van TLS 1.2 en is de huidige beste practice voor het beschermen van CUI onderweg.
E-mail vormt een bijzondere uitdaging voor defensie-aannemers. Standaard e-mailtransmissie versleutelt de inhoud van berichten niet end-to-end, waardoor CUI wordt blootgesteld wanneer berichten mailservers passeren. Beveiligde e-mailoplossingen die AES-256 Encryptie toepassen op de berichtinhoud—en niet alleen op het transmissiekanaal—bieden de bescherming die CMMC vereist voor e-mail met CUI.
Bestandsoverdracht vereist vergelijkbare aandacht. Secure File Transfer Protocol (SFTP) en FTPS ondersteunen beide versleutelde transmissie, maar organisaties moeten verifiëren dat hun implementaties FIPS-gevalideerde cryptografische modules gebruiken. Grote bestandsoverdrachten tussen defensie-aannemers, onderaannemers en overheidsinstanties bevatten vaak CUI en vereisen consistente encryptiebescherming.
API-communicatie tussen systemen valt ook onder de encryptievereisten voor transmissie. Organisaties die integreren met overheidssystemen of CUI uitwisselen via geautomatiseerde interfaces, moeten ervoor zorgen dat deze verbindingen gebruikmaken van adequaat versleutelde kanalen.
Encryptiesleutelbeheer op FedRAMP Authorized infrastructuur
Veel defensie-aannemers maken gebruik van FedRAMP Authorized cloudservices voor het opslaan en verwerken van CUI. Hoewel FedRAMP-autorisatie bevestigt dat een cloudprovider aan federale beveiligingsvereisten voldoet, betekent dit niet automatisch dat de aannemer aan zijn eigen CMMC-verplichtingen voldoet. De aannemer blijft verantwoordelijk voor zijn eigen naleving, inclusief het aantonen van adequate controle over de toegang tot CUI.
Encryptiesleutelbeheer bepaalt wie daadwerkelijk toegang heeft tot versleutelde CUI, ongeacht waar deze is opgeslagen. Er bestaan drie sleutelbeheer-modellen voor cloud-gehoste data, elk met verschillende gevolgen voor CMMC-naleving.
Provider-beheerde sleutels zijn de eenvoudigste implementatie: de cloudprovider genereert, slaat op en beheert de encryptiesleutels. Hoewel de data is versleuteld, behoudt de provider de technische mogelijkheid om deze te ontsleutelen. Dit model roept tijdens CMMC-audits belangrijke vragen op over of de aannemer voldoende controle over de toegang tot CUI behoudt.
Klant-beheerde sleutels (vaak Bring Your Own Key of BYOK genoemd) geven de aannemer controle over de generatie en levenscyclus van sleutels, maar de sleutels worden geüpload naar en opgeslagen binnen de key management service van de cloudprovider. De provider behoudt technische toegang tot deze sleutels en kan worden verplicht data te ontsleutelen onder de CLOUD Act of andere juridische processen—vaak zonder de klant te informeren. Voor CMMC-doeleinden creëert dit model onduidelijkheid over wie daadwerkelijk toegang heeft tot CUI.
Klant-eigen sleutels (Hold Your Own Key of HYOK) bieden echte scheiding. De aannemer beheert encryptiesleutels uitsluitend in het eigen sleutelbeheersysteem of hardware security module (HSM), en de cloudprovider heeft nooit toegang tot de sleutels. Zelfs als de provider een gerechtelijk bevel ontvangt, kan deze de CUI niet ontsleutelen omdat de sleutels ontbreken. Dit model creëert duidelijke controlegrenzen die voldoen aan de eisen van CMMC-beoordelaars.
FedRAMP Authorized status zegt iets over de beveiligingsstatus van de cloudprovider, maar bepaalt niet het sleutelbeheer van de aannemer. CMMC-beoordelaars onderzoeken hoe de aannemer toegang tot CUI beheerst. Klant-eigen encryptiesleutels—waarbij de aannemer als enige partij CUI kan ontsleutelen—vormen sluitend bewijs van die controle. Klant-beheerde sleutels, ondanks de geruststellende terminologie, laten cloudproviders technische toegang houden, wat de nalevingspositie bemoeilijkt.
Veelvoorkomende CMMC-encryptietekortkomingen
CMMC-audits identificeren vaak encryptiegerelateerde tekortkomingen die certificering in de weg staan. Inzicht in deze veelvoorkomende gaten helpt organisaties zich beter voor te bereiden.
Het gebruik van niet-gevalideerde encryptiemodules blijft een veelvoorkomende bevinding. Organisaties kunnen AES-256 Encryptie implementeren via bibliotheken of producten zonder FIPS 140-validatie, waardoor niet aan de modulevereiste wordt voldaan, ondanks het juiste algoritme.
Onvolledige encryptiedekking veroorzaakt gaten wanneer CUI niet overal waar het zich bevindt wordt versleuteld. E-mailsystemen, samenwerkingsplatforms en endpointapparaten missen vaak encryptie, zelfs als de kernbestandsopslag wel is beschermd.
Onvoldoende documentatie in het Systeembeveiligingsplan (SSP) leidt tot bevindingen tijdens de audit, zelfs als technische maatregelen correct zijn geïmplementeerd. Het SSP moet encryptiemethoden, FIPS-certificaatnummers, procedures voor sleutelbeheer en de systemen die door encryptie worden beschermd documenteren.
Vertrouwen op cloudprovider-encryptie zonder inzicht in de gevolgen voor sleutelbeheer kan onduidelijkheid creëren over de toegang tot CUI. Beoordelaars zullen onderzoeken of de aannemer of de cloudprovider uiteindelijk toegang heeft tot versleutelde CUI.
Verouderde FIPS-validatiecertificaten vormen een nalevingsrisico als certificaten verlopen tijdens een contractperiode. Organisaties moeten de vervaldatums van certificaten voor alle encryptieproducten in hun omgeving bijhouden.
Gaten in encryptiedekking tijdens gegevensoverdracht ontstaan wanneer CUI in rust en bij externe overdracht wordt beschermd, maar onversleuteld tussen interne systemen wordt verplaatst. Beoordelaars onderzoeken de volledige gegevensstroom, niet alleen opslag en externe communicatie.
Bescherm CUI met de robuuste encryptiemogelijkheden van Kiteworks
CMMC Level 2-certificering vereist dat defensie-aannemers aantonen dat CUI wordt beschermd door FIPS-gevalideerde encryptie in rust en onderweg, ondersteund door gedocumenteerde sleutelbeheerpraktijken. AES-256 Encryptie voldoet aan de cryptografische vereisten wanneer het wordt geïmplementeerd via correct gevalideerde modules en consistent wordt toegepast op alle systemen die CUI verwerken.
De keuze van het sleutel-eigenaarschapsmodel heeft grote invloed op de CMMC-nalevingsstatus, vooral wanneer CUI zich op cloudinfrastructuur bevindt. Klant-eigen encryptiesleutels—waarbij alleen u de sleutels bezit en zelfs uw cloudprovider er geen toegang toe heeft—creëren duidelijke controlegrenzen die voldoen aan de eisen van beoordelaars en alle onduidelijkheid over toegang tot CUI wegnemen.
Kiteworks ondersteunt bijna 90% van de CMMC Level 2-vereisten direct uit de doos. Dit omvat FIPS 140-3 gevalideerde encryptie—de huidige federale validatiestandaard, niet de oudere FIPS 140-2—voor het beschermen van CUI in rust en onderweg. Het platform, een Private Data Network, beveiligt gegevens in beweging met TLS 1.3 encryptie, het sterkste beschikbare transportlaagprotocol, voor e-mail, bestandsoverdracht, beheerde bestandsoverdracht en webformulieren.
Voor e-mailcommunicatie met CUI past de Kiteworks email protection gateway automatisch AES-256 Encryptie toe op uitgaande berichten, waardoor de afhankelijkheid van eindgebruikers om encryptiebeslissingen te nemen wordt geëlimineerd en consistente bescherming wordt geboden in de defensieketen.
Kiteworks beschikt over een klant-eigen sleutelarchitectuur waarmee defensie-aannemers exclusief eigenaarschap over hun encryptiesleutels behouden, zelfs bij inzet op FedRAMP Authorized infrastructuur. Uw cloudprovider kan geen toegang krijgen tot uw CUI omdat zij nooit over de benodigde sleutels beschikken—dit levert sluitend bewijs van toegangscontrole tot CUI voor CMMC-beoordelaars.
Organisaties die het hoogste niveau van sleutelbescherming vereisen, kunnen Kiteworks integreren met hardware security modules (HSM’s) voor manipulatiebestendige sleutelopslag die voldoet aan FIPS 140-3 validatievereisten.
Wilt u weten hoe Kiteworks CMMC 2.0-naleving ondersteunt met FIPS 140-3 gevalideerde, klant-eigen encryptiesleutels? Plan dan een aangepaste demo, afgestemd op uw defensiecontractomgeving.
Veelgestelde vragen
CMMC vereist FIPS-gevalideerde encryptie maar schrijft AES-256 niet expliciet voor. AES-256 is echter het meest gebruikte FIPS-goedgekeurde algoritme voor het beschermen van gevoelige federale informatie en geldt als de standaardkeuze voor CUI-bescherming.
Controls SC.L2-3.13.8 (cryptografische bescherming tijdens transmissie) en SC.L2-3.13.16 (bescherming van CUI in rust) bevatten de belangrijkste encryptievereisten. Aanvullende controls behandelen gerelateerde onderwerpen zoals cryptografisch sleutelbeheer. Zie de volledige NIST 800-171 control-specificaties voor details.
Beide zijn nog toegestaan. FIPS 140-2-certificaten blijven geldig tot hun vervaldatum, maar nieuwe validaties worden afgegeven onder FIPS 140-3. Organisaties moeten prioriteit geven aan FIPS 140-3 gevalideerde oplossingen voor langdurige naleving.
Encryptie van de cloudprovider kan voldoen aan CMMC-vereisten als deze via FIPS-gevalideerde modules wordt geïmplementeerd. Het model voor sleutel-eigenaarschap bepaalt echter wie toegang heeft tot versleutelde CUI, wat beoordelaars zorgvuldig zullen onderzoeken.
Klant-eigen encryptiesleutels—waarbij alleen u de sleutels bezit—vormen sluitend bewijs van toegangscontrole tot CUI tijdens een CMMC-audit. Klant-beheerde sleutels (BYOK) laten cloudproviders technische toegang tot uw sleutels behouden, wat onduidelijkheid schept over wie toegang heeft tot CUI, zelfs op FedRAMP-infrastructuur.
CMMC Level 1 omvat 17 basismaatregelen voor FCI en bevat geen expliciete encryptievereisten. Encryptie blijft echter een aanbevolen praktijk voor het beschermen van gevoelige informatie.
Beoordelaars controleren FIPS-validatiecertificaten, beoordelen encryptieconfiguraties, verifiëren dekking op alle CUI-opslaglocaties en transmissiekanalen, en evalueren documentatie over sleutelbeheer in het Systeembeveiligingsplan (SSP).
Aanvullende bronnen
- Blog Post
Publieke versus private sleutelencryptie: een gedetailleerde uitleg - Blog Post
Essentiële beste practices voor data-encryptie - eBook
Top 10 trends in data-encryptie: een diepgaande analyse van AES-256 - Blog Post
E2EE verkennen: praktijkvoorbeelden van end-to-end encryptie - Blog Post
Ultieme gids voor AES 256 Encryptie: gegevensbescherming versterken voor onbreekbare beveiliging