Cloudbeveiliging: Fortinet 350, AWS 90 dagen
Cloudbeveiliging volgens Fortinet: vervang toegangssleutels binnen 350 dagen. AWS vlagt ze na 90. Toets je eigen AWS-export in de browser, zonder geheimen.
Fortinet zet AI in de kop van zijn nieuwe cloudrapport, maar de grootste deur die het beschrijft is ouderwets: een geldige sleutel. Voor cloudbeveiliging adviseert het Nederlandse persbericht om toegangssleutels “elke 350 dagen of vaker” te vervangen. De eigen controle van Amazon Web Services vlagt een sleutel al na 90 dagen.
Neem een sleutel van 300 dagen oud. Bij Fortinet is hij nog op tijd, bij AWS zit hij er 210 dagen overheen (300 min 90). Hieronder staat wat het rapport wel en niet laat zien, en een check waarmee je je eigen AWS-export tegen allebei de drempels legt, zonder dat er een geheim de browser uit gaat.
Aanvallers loggen in, ze breken niet in
Fortinet publiceerde het 2026 Cloud-Native Threat Landscape Report op 23 september 2026 met een blog. Het Nederlandstalige persbericht volgde op 19 oktober, Risk & Business nam het op 20 oktober over. De kern staat in het blog: identiteitsmisbruik is “by far the dominant intrusion vector”.
Aanvallers gebruiken volgens Fortinet gestolen, uitgelekte of misbruikte inloggegevens en komen binnen via legitieme toegangswegen. Daardoor lijkt hun activiteit op die van een gewone gebruiker. In Azië-Pacific kwam identiteitsmisbruik relatief het vaakst voor, op de voet gevolgd door Noord- en Zuid-Amerika.
Data stelen blijft een doel, maar veel aanvallers zijn alleen uit op rekenkracht. Het rapport noemt misbruik van Amazon Simple Email Service, cryptomining en ongeoorloofd gebruik van Amazon Bedrock. Een onverwachte stijging van je cloudrekening kan dus wijzen op een gecompromitteerde omgeving, niet alleen op slordig kostenbeheer.
Miljarden pogingen, geen noemer
De koppen in het nieuws gaan over 150 miljoen verkenningsactiviteiten, 2,3 miljard brute-forcepogingen en 1,7 miljard exploitatiepogingen. Dat zijn tellingen van pogingen, geen incidenten en geen ondervraagde organisaties. Hoeveel daarvan slaagde, staat er niet bij.
Wie telde? Het persbericht zegt het zelf: het rapport is “volledig gebaseerd op informatie uit FortiCNAPP”, Fortinets eigen cloudbeveiligingsproduct. Het meet dus de omgevingen van Fortinet-klanten. Een periode, het aantal omgevingen en een percentage voor identiteitsmisbruik staan niet in het blog of het persbericht. Het volledige rapport zit achter een formulier met naam, functie en telefoonnummer.
Ook het verband met pentesten verdient een rem. Fortinet zag minder geslaagde identiteitsaanvallen bij organisaties die vaker testen. Dat is een samenhang, geen oorzaak. Wie vaak test, kan ook de rest beter op orde hebben, en blog en persbericht houden die twee niet uit elkaar. En de drie prioriteiten in het blog wijzen stuk voor stuk naar Fortinet-producten, van FortiCNAPP tot FortiDAST.
| Soort | Aantal |
|---|---|
| Brute-forcepogingen | 2,3 miljard |
| Exploitatiepogingen | 1,7 miljard |
| Verkenningsactiviteiten | 150 miljoen |
Cloudbeveiliging met drie controles die vaak ontbreken
Het bruikbaarste deel van het persbericht is een kort rijtje. Drie maatregelen die volgens Fortinet in cloudomgevingen vaak ontbreken: vervang toegangssleutels elke 350 dagen of vaker, laat netwerk-ACL’s geen onbeperkt inkomend verkeer toe, en laat geen security group aan een netwerkinterface hangen die inkomend verkeer op alle poorten toestaat.
Het Engelse blog noemt die 350 dagen niet; het Nederlandse persbericht wel. Leg je hem naast de documentatie van AWS zelf, dan schuurt het. Security Hub-controle IAM.3 zegt dat sleutels van IAM-gebruikers binnen 90 dagen geroteerd moeten zijn. Controle IAM.22 gaat verder: inloggegevens die 45 dagen niet gebruikt zijn, horen weg.
Punt twee heeft een tweede verrassing. Volgens de VPC-handleiding van AWS laat de standaard-netwerk-ACL al het verkeer in en uit, met regel 100 voor 0.0.0.0/0. Een omgeving waar nooit iemand aan die ACL heeft gezeten, zakt dus al voor Fortinets tweede controle. Dan blijven de security groups de echte drempel.
Toets je eigen export tegen 90 en 350 dagen
Plak hieronder de JSON-uitvoer van een of meer van deze AWS CLI-commando’s: aws iam list-access-keys --user-name NAAM, aws ec2 describe-security-groups en aws ec2 describe-network-acls. De check leest alleen de aanmaakdatum van sleutels en de inkomende regels. Alles blijft in je browser; er wordt niets verstuurd of opgeslagen.
Zie je in je plakwerk een geheime sleutel of sessietoken staan, dan weigert de check en maakt hij het veld leeg. Geen echte export bij de hand? Laad dan de fictieve voorbeeldomgeving. Die rekent met peildatum 20 oktober 2026.
Een sleutel van 350 dagen is een vergeten sleutel
Fortinets eigen verhaal is snelheid. De tijd tussen het ontdekken en misbruiken van een kwetsbaarheid is volgens het rapport “teruggelopen van weken naar uren”. Wie dat schrijft, kan in hetzelfde persbericht niet geloofwaardig zeggen dat bijna een jaar per sleutel prima is.
Een toegangssleutel van een jaar oud hoort vaak bij iets wat niemand meer bekijkt: een script van een collega die al weg is, een testomgeving, een koppeling die marketing ooit liet maken. Dat is het menselijke deel van identiteitsmisbruik. Niemand voelt zich eigenaar, dus niemand merkt het als een ander de sleutel gebruikt.
Het NCSC zegt het in zijn basisprincipe over toegangsbeheer zonder omweg: ook de toegang van service-accounts, machine-accounts en functionele accounts moet beperkt blijven tot wat nodig is. Een sleutel die 45 dagen niets deed, is niet nodig.
Dezelfde redenering zag je bij het hulpforum dat de voordeur van OpenAI bleek: de zwakke plek zat niet in het systeem met de meeste data, maar in een vergeten ingang met dezelfde inlog. Een cloudsleutel is zo’n ingang zonder gezicht.
Roteren helpt niet tegen een sleutel die gisteren uitlekte
De 90 dagen van AWS zijn ook maar een afspraak. Een sleutel van tien dagen oud die in een openbare repository belandt, is net zo open als een van vierhonderd dagen. Leeftijd is een maat voor verwaarlozing, geen bewijs van veiligheid.
Blind roteren kan bovendien iets stilzetten. Wie niet weet welk script een sleutel gebruikt, breekt dat script bij de vervanging. De eerlijke volgorde is dus: eerst uitzoeken van wie een sleutel is en of hij nog gebruikt wordt, dan pas vervangen of weggooien.
En sterke authenticatie lost dit niet op, zegt ook Fortinet: het is “slechts één beveiligingslaag”. Tweefactorauthenticatie beschermt de inlog van een mens, maar een toegangssleutel voor een script vraagt geen tweede factor. Daarom telt hier de inventaris, niet de inlogknop.
- Sleutel aangemaaktVoor een script, test of koppeling.
- Eigenaar weg of project klaarDe sleutel blijft actief.
- Dag 45 zonder gebruikAWS IAM.22: verwijderen.
- Dag 90AWS IAM.3: roteren.
- Dag 350Fortinet-persbericht: vervangen.
Bij de volgende controle: eerst de eigenaar, dan de leeftijd
- Haal per IAM-gebruiker de sleutels op.
aws iam list-access-keys --user-name NAAMgeeft sleutel-ID, status en aanmaakdatum. - Plak de uitvoer in de check hierboven. Alles boven 90 dagen gaat op een lijst.
- Zet bij elke sleutel op die lijst een naam. Geen eigenaar te vinden? Zet de sleutel op inactief en kijk wat er stuk gaat, voordat je hem verwijdert.
- Loop daarna de security groups na. Een regel met 0.0.0.0/0 op alle poorten is zelden bewust, net als een laptop die met één commando online staat.
Het volledige rapport moet de noemer nog laten zien
Wie het rapport via het formulier downloadt, ziet of Fortinet daar wel een periode, een aantal omgevingen en een aandeel voor identiteitsmisbruik noemt. Staat dat er niet in, dan blijft “veruit de belangrijkste” een kwalitatieve uitspraak uit klantdata van één leverancier.
De 350 dagen blijven intussen het advies in het Nederlandse persbericht. Zolang AWS op 90 en 45 dagen staat, is de strengste termijn de veiligste om je aan te houden. Een human firewall begint hier bij een simpele vraag die geen tool beantwoordt: van wie is deze sleutel?
Bronnen: Fortinet-blog, 23 september 2026; Fortinet-persbericht, 19 oktober 2026, ook gepubliceerd door Belgium Cloud; Risk & Business, 20 oktober 2026; AWS Security Hub-documentatie (IAM-controles) en AWS VPC-handleiding (standaard-netwerk-ACL), gelezen 20 oktober 2026; NCSC, basisprincipe toegang beheren.
Van wie is deze sleutel?
Plak je export, zie welke sleutels boven 90 of 350 dagen zitten en welke poorten open staan. Er gaat niets je browser uit.
Controleer mijn export
Rik Hoogland
Rik begeleidde jarenlang phishing-simulaties en awareness-programma's bij Nederlandse organisaties. Op Humanfirewall.nl legt hij uit hoe oplichters mensen bespelen en hoe je daar als team tegen bestand raakt. Stel Rik je vraag.
Zelf een situatie die niet vertrouwd voelt?
Beschrijf wat er gebeurde of waar je over twijfelt, dan denkt Rik mee over de juiste reactie.