--- title: "Cloudbeveiliging: Fortinet 350, AWS 90 dagen" date: 2026-10-20 author: "Rik Hoogland" featured_image: "https://humanfirewall.nl/wp-content/uploads/2026/10/cloudbeveiliging-toegangssleutels-90-350-dagen.jpg" categories: - name: "Beveiligingsnieuws" url: "/category/beveiligingsnieuws.md" --- # Cloudbeveiliging: Fortinet 350, AWS 90 dagen **350 dagen**Sleuteltermijn in het Nederlandse Fortinet-persbericht van 19 oktober 2026. **90 dagen**Sleuteltermijn in AWS Security Hub-controle IAM.3. **2,3 miljard**Brute-forcepogingen die Fortinet telde, zonder noemer of slagingspercentage. 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. **Fortinet: 350 dagen**Een sleutel van 300 dagen is nog op tijd. **AWS IAM.3: 90 dagen**Dezelfde sleutel zit er 210 dagen overheen. Eén sleutel, twee oordelen. Bron: Fortinet-persbericht 19 oktober 2026 en AWS Security Hub-documentatie. ## 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. **Binnenkomen**Gestolen, uitgelekte of misbruikte inloggegevens **Opvallen**Nauwelijks: het lijkt op een gewone gebruiker **Buit**Amazon SES voor mail, cryptomining, Amazon Bedrock De route die Fortinet beschrijft. Bron: Fortinet-blog, 23 september 2026. ## 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. Pogingen volgens FortiCNAPPSoortAantalBrute-forcepogingen2,3 miljardExploitatiepogingen1,7 miljardVerkenningsactiviteiten150 miljoenTellingen van pogingen, geen incidenten. Periode en aantal omgevingen staan niet in blog of persbericht. ## 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. **350 dagen**Fortinet, Nederlands persbericht 19 oktober 2026: vervang toegangssleutels elke 350 dagen of vaker. **90 dagen**AWS Security Hub IAM.3: actieve sleutels van IAM-gebruikers binnen 90 dagen roteren. **45 dagen**AWS Security Hub IAM.22: inloggegevens die 45 dagen ongebruikt zijn verwijderen. Drie termijnen voor dezelfde sleutel. Bron: Fortinet en AWS-documentatie, gelezen 20 oktober 2026. ## 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. Sleutel- en poortcheck · rekent in je browser Plak je JSON-exportPeildatumControleer exportLaad fictief voorbeeldLeegmaken Voor deze check is JavaScript nodig. Handmatig: tel per sleutel de dagen sinds CreateDate en zoek in je security groups en netwerk-ACL’s naar inkomende regels met 0.0.0.0/0 en alle poorten. ## 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](https://www.ncsc.nl/wat-kun-je-zelf-doen/basisprincipes/beheer-toegang-tot-data-en-diensten) 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](https://humanfirewall.nl/openai-sso-forum-voordeur-koppelingen/): 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. **Weken naar uren**Tijd tussen ontdekken en misbruiken van een kwetsbaarheid, volgens Fortinet. **350 dagen**De sleuteltermijn in hetzelfde persbericht. Twee uitspraken uit één persbericht. Bron: Fortinet via Evoke, 19 oktober 2026. ## 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](https://humanfirewall.nl/tweefactorauthenticatie-vangrail/) beschermt de inlog van een mens, maar een toegangssleutel voor een script vraagt geen tweede factor. Daarom telt hier de inventaris, niet de inlogknop. 1. **Sleutel aangemaakt**Voor een script, test of koppeling. 2. **Eigenaar weg of project klaar**De sleutel blijft actief. 3. **Dag 45 zonder gebruik**AWS IAM.22: verwijderen. 4. **Dag 90**AWS IAM.3: roteren. 5. **Dag 350**Fortinet-persbericht: vervangen. Levensloop van een vergeten sleutel, met de termijnen uit AWS-documentatie en het Fortinet-persbericht. ## Bij de volgende controle: eerst de eigenaar, dan de leeftijd 1. **Haal per IAM-gebruiker de sleutels op.** `aws iam list-access-keys --user-name NAAM` geeft sleutel-ID, status en aanmaakdatum. 2. **Plak de uitvoer in de check hierboven.** Alles boven 90 dagen gaat op een lijst. 3. **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. 4. **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](https://humanfirewall.nl/cloudflare-quick-tunnel-laptop-op-internet/). **Eigenaar bekend**Vervangen volgens plan, script mee aanpassen **Geen eigenaar**Eerst op inactief, kijken wat stuk gaat, dan weg Volgorde voor sleutels boven 90 dagen. ## 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](https://humanfirewall.nl/) 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. **Wel bekend**Bron: FortiCNAPP-klantdata **Niet in blog of persbericht**Periode, aantal omgevingen, aandeel identiteitsmisbruik **Toegang**Rapport achter een formulier Wat de openbare stukken van Fortinet wel en niet vertellen. ## 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](#sleutelcheck)