Het grootste aanvalsoppervlak van nu is uw cloud.
Een doorlichting van configuratie, identiteit en segmentatie in AWS, Azure en GCP. De meeste cloudincidenten beginnen niet met een storing bij de provider, maar met een te ruim recht, een resource die per ongeluk openstaat of een vergeten geheim.
In de cloud ligt de fout zelden bij de provider
Het model van gedeelde verantwoordelijkheid verdeelt het werk: de provider beveiligt de infrastructuur, de configuratie is van u. Incidenten gebeuren op uw helft — een bucket opengezet voor het gemak van een test, een rol die haastig beheerdersrechten kreeg, een netwerk dat ongesegmenteerd bleef omdat een deadline knelde. Niets daarvan verschijnt als kwetsbaarheid in een scan; het verschijnt als een configuratiebeslissing die niemand opnieuw heeft bekeken.
- Een recht dat als tijdelijke maatregel is verleend, wordt vrijwel nooit later ingetrokken.
- Een resource die buiten het standaardproces is aangemaakt, erft de bescherming van dat proces niet.
- Geheimen in omgevingsvariabelen en repositories blijven de kortste weg naar binnen.
- Zonder segmentatie reikt één enkel steunpunt tot accounts en omgevingen die gescheiden hadden moeten zijn.
Wat inbegrepen is
De scope hieronder is de standaard voor een gebruikelijke opdracht. Alles is tijdens de scoping aan te passen, kosteloos.
- Ruime policies en wildcards in acties en resources
- Aanneembare rollen en ketens van privilege-escalatie
- Langlevende toegangssleutels en rotatie
- Federatie, identity provider en sessies
- Serviceaccounts en rechten van workloads
- Scheiding tussen beheer en gebruik
- Publieke blootstelling van objecten en containers
- Versleuteling in rust en sleutelbeheer
- Toegangsbeleid en delen tussen accounts
- Versiebeheer, bewaartermijn en verwijderbeveiliging
- Back-ups en het beproeven van herstel
- Gevoelige gegevens buiten hun bedoelde opslag
- Inkomende regels die openstaan voor het hele internet
- Segmentatie tussen omgevingen en accounts
- Load balancers, gateways en terminatie van verkeer
- Beheerdiensten die van buitenaf bereikbaar zijn
- Private connectiviteit en netwerkpeering
- Oppervlak van containers en orchestratie
- Audittrail ingeschakeld in elke regio
- Bewaring en bescherming van de logs zelf
- Dekking van gebeurtenissen op de control plane
- Alarmering bij wijziging van gevoelige rechten
- Centralisatie in een apart account
- Koppeling met de bestaande monitoring
- IAM, rollen, policies en identiteitsfederatie
- VPC, security groups, NACL's, peering en publieke blootstelling
- S3, RDS, DynamoDB, Blob Storage en Cloud Storage
- EC2, Lambda, ECS, EKS, AKS en GKE
- CloudTrail, AWS Config, Microsoft Sentinel en Security Command Center
- Identity providers en gefedereerde SSO
Varianten
aan te passen aan de scopeConfiguratiedoorlichting
Een systematische lezing van de omgeving vanuit een auditrol: identiteit, netwerk, opslag, logging en gegevensbescherming, vergeleken met de documentatie van de provider zelf en met openbare benchmarks.
Padonderzoek
In plaats van configuratie op te sommen beginnen wij vanuit een aannemelijke positie — een applicatie-inloggegeven, een gecompromitteerde container, een gewone gebruiker — en stellen vast hoe ver die binnen de omgeving reikt.
Doorlopende toetsing en infrastructuur als code
Analyse van de templates en modules die de omgeving opbouwen, plus een terugkerende controlecyclus. Bij de bron herstellen voorkomt dat dezelfde afwijking terugkeert bij elk nieuw account, project of uitrol.
Wanneer een cloudomgeving doorgelicht moet worden
Cloudconfiguratie verandert dagelijks, door veel handen. Sommige momenten concentreren het risico meer dan andere.
Een omgeving die haastig is verhuisd draagt meestal ruime rechten die zijn verleend om de overgang vlot te trekken, met de belofte ze later te versmallen — en dat later komt zelden.
Elk team maakte er een aan, elk project opende er nog een. Zonder centrale standaard lopen de beschermingen uiteen en heeft niemand overzicht over het geheel.
Afwijkende kosten zijn soms verspilling en soms een resource die is aangemaakt door iemand die daar geen recht toe had. Het loont te weten welke van de twee.
Bewijs van cloudmaatregelen is inmiddels een standaardpunt in de meeste vragenlijsten. Beter dat u het gat vindt dan de beoordelaar.
Hoe wij het uitvoeren
[pipeline]In kaart brengen van de omgeving
Wij beginnen bij wat er is: accounts, abonnementen, projecten, actieve regio's en resources in gebruik. Een cloudlandschap is bijna altijd groter dan de documentatie doet vermoeden, en juist de resource die in de inventaris ontbreekt is meestal de onbeschermde.
Analyse van identiteit en rechten
Wij brengen in kaart wie wat kan, inclusief wat mogelijk is via overerving en het aannemen van rollen. Niet de geschreven policy telt, maar het effectieve recht — en dat is doorgaans veel ruimer dan degene die het verleende zich voorstelt.
Doorlichting van de configuratie
Opslag, netwerk, versleuteling, logging, back-up en beheerde diensten worden vergeleken met de documentatie van de provider en met openbare benchmarks voor veilige configuratie, waarbij elke afwijking wordt vastgelegd met de reden waarom zij in déze omgeving telt.
Toetsen van de reikwijdte
Wij simuleren realistische startposities en meten hoe ver elk daarvan komt: wat een applicatie-inloggegeven kan lezen, wat een gecompromitteerde container raakt, of het mogelijk is van de ene omgeving naar de andere over te steken. Dat onderscheidt een lijst afwijkingen van aangetoond risico.
Beoordeling van logging en alarmering
Wij controleren of de handelingen die wij uitvoerden een spoor achterlieten, of dat spoor beschermd is tegen verwijdering en of wijzigingen in gevoelige rechten alarm slaan. Een omgeving zonder betrouwbaar spoor is na een incident niet te onderzoeken.
Rapport en herstelplan
Afwijkingen worden gegroepeerd naar oorzaak in plaats van naar resource: tien punten die uit één policy voortkomen zijn één oplossing, geen tien. Elke groep krijgt toepasbaar advies en een suggestie om herhaling bij de bron te voorkomen.
Openbare referenties achter het werk
De doorlichting steunt op de documentatie van de providers zelf en op open configuratiebenchmarks, waardoor elk punt onafhankelijk verifieerbaar is.
- CIS Benchmarks
- De configuratiebasislijnen voor AWS, Azure en GCP geven een objectieve referentie, punt voor punt, om de staat van de omgeving tegen af te zetten.
- Well-Architected (securitypijler)
- De architectuurrichtlijnen van elke provider verwoorden hun eigen aanbevolen praktijk, wat elke discussie wegneemt over waar een aanbeveling vandaan komt.
- Model van gedeelde verantwoordelijkheid
- Het legt precies vast waar de verantwoordelijkheid van de provider eindigt en de uwe begint — exact de grens waar de meeste incidenten plaatsvinden.
- MITRE ATT&CK for Cloud
- De cloudspecifieke matrix benoemt technieken voor misbruik van identiteit, persistentie en verzameling, en dient om de dekking van de detectie te beoordelen.
- NIST SP 800-53
- De catalogus met beheersmaatregelen is de brug tussen een technische bevinding en de taal die governance en audit al spreken.
- Minimale rechten
- Geen standaard maar het criterium dat de rechtenanalyse stuurt: elke identiteit hoort alleen te reiken tot wat zij nodig heeft, en elke afwijking vraagt om een uitdrukkelijke onderbouwing.
- Azure Security Benchmark
- De eigen basislijn van Microsoft voor Azure, gebruikt wanneer het landschap overwegend Azure is en de audit die referentie verwacht.
- CSA Cloud Controls Matrix
- De matrix van de Cloud Security Alliance brengt cloudsecuritydomeinen in kaart en verwijst naar andere standaarden, wat helpt zodra de vragenlijst van een klant lang wordt.
- ISO/IEC 27017 en 27018
- De standaarden specifiek voor cloudsecurity en voor persoonsgegevens in de cloud, die veel in zakelijke contracten worden genoemd.
- Koppeling met AVG en PCI-DSS
- Verwerkt de omgeving persoonsgegevens of kaartgegevens, dan wordt elke bevinding ook gekoppeld aan de bijbehorende eis, zodat zij rechtstreeks als bewijs dient.
Opleveringen
twee lagen · NDAInventaris van wat er is
De werkelijke lijst met accounts, projecten, regio's en actieve resources. Voor veel teams is dit de eerste bruikbare oplevering, omdat er omgevingen boven komen waarvan niemand zich herinnerde dat ze bestonden.
Kaart van effectieve rechten
Wie in de praktijk waarbij komt, inclusief indirecte paden via overerving en het aannemen van rollen. Dit verrast doorgaans meer dan de lijst met configuratiepunten.
Afwijkingen gegroepeerd naar oorzaak
Bevindingen geordend naar gemeenschappelijke oorsprong, elk met de openbare referentie erbij. De oorzaak herstellen sluit meerdere punten tegelijk en voorkomt terugkeer.
Aangetoonde paden
Voor de meest relevante risico's de concrete route: waar zij begint, wat zij bereikt en waarom dat uitmaakt. Zo wordt een configuratieafwijking een risico dat ook een niet-specialist kan wegen.
Beoordeling van spoor en detectie
Wat er van onze handelingen is vastgelegd, wat uitstond en welke gevoelige wijzigingen vandaag onopgemerkt zouden blijven.
Geprioriteerd herstelplan
Een werkvolgorde die risico en inspanning afweegt, en die scheidt wat in configuratie te herstellen is van wat in infrastructuur als code moet veranderen om niet terug te keren.
Veelgestelde vragen
Nee. De doorlichting draait vanuit een auditrol met alleen leesrechten, die alle drie de providers standaard bieden. Voor het toetsen van reikwijdte spreken wij afzonderlijk specifieke, beperkte inloggegevens af, met scope en looptijd schriftelijk vastgelegd.
Het vult die aan in plaats van te vervangen. Posture-tooling dekt volume af en volgt afwijking doorlopend, wat waardevol is. Wat zij niet doet, is rechten aaneenketenen om te tonen dat een applicatie-inloggegeven bij gegevens komt die geïsoleerd zouden moeten zijn — en juist die demonstratie verandert prioriteiten.
Ja. Gemengde landschappen zijn eerder regel dan uitzondering, en de vergelijking tussen providers legt meestal ongelijke bescherming bloot: hetzelfde type resource dichtgezet bij de een en open bij de ander, omdat verschillende teams ze hebben gebouwd.
Orchestratie valt binnen de scope: rollen en bindings, security contexts van containers, netwerkbeleid tussen services, blootstelling van de control plane, beheer van geheimen, en de koppeling tussen clusteridentiteit en cloudidentiteit — een veelvoorkomend escalatiepad.
Ten minste de omgeving die productie bedient. Ontwikkel- en stagingaccounts horen erbij zodra zij een netwerk- of identiteitspad naar productie hebben, wat vaker voorkomt dan gedacht — en precies daar is de bescherming meestal het losst.
Door ze bij de bron te herstellen. Wordt de omgeving vanuit infrastructuur als code gebouwd, dan gaat de oplossing in de module en geldt zij voor elke volgende uitrol. Voor elke groep afwijkingen zegt het rapport of die op de resource of in het template dat haar aanmaakt moet worden aangepakt.
Ja. Elk punt draagt zijn openbare referentie en het bewijs van de waargenomen configuratie, in een vorm die een auditor zelfstandig kan verifiëren zonder de analyse over te doen.