# Cloud- en SaaS-beveiliging (FAQ)

> 25 vragen over Cloud- en SaaS-beveiliging, in gewone taal: wat u controleert, wat NetSenX laat zien en wat een sensor niet ziet.

Source page: https://netsenx.com/nl/faq/cloud

## Wat is het model van gedeelde verantwoordelijkheid in de cloud?

Het is de verdeling van beveiligingstaken tussen de cloudaanbieder en u, en de meeste cloudincidenten gebeuren aan uw kant van de lijn. De aanbieder beveiligt wat hij zelf beheert: datacenters, hardware, het netwerk daartussen en, afhankelijk van de dienst, het besturingssysteem en de applicatie zelf. U blijft verantwoordelijk voor het gebruik: wie accounts heeft en met welke rechten, meerfactorauthenticatie (MFA), hoe opslag en diensten zijn ingesteld, welke gegevens u erin zet, uw eigen applicaties en hun patches, en uw back-ups. De lijn verschuift met het soort dienst. Bij gehuurde virtuele servers beheert u bijna alles boven de hardware; bij een SaaS-product zoals een kantoorpakket beheert u vooral identiteiten, deelinstellingen en gegevens. Lees de verantwoordelijkheidsmatrix van uw aanbieder, wijs elk punt toe aan een benoemde eigenaar in uw bedrijf en controleer die bij elke nieuwe dienst. De certificaten van een aanbieder dekken zijn deel, niet uw configuratie.

https://netsenx.com/nl/faq/what-is-the-shared-responsibility-model-in-the-cloud

## Wat is het verschil tussen IaaS, PaaS en SaaS?

Ze beschrijven hoeveel van de stack de aanbieder voor u beheert, en dus hoeveel beveiligingswerk bij u blijft. Bij infrastructure as a service (IaaS) huurt u virtuele servers, opslag en netwerken; u installeert en patcht het besturingssysteem, stelt firewalls in en draait uw applicaties, dus het beveiligingswerk lijkt op dat van eigen servers. Bij platform as a service (PaaS) beheert de aanbieder besturingssysteem en runtime, zoals een beheerde database of een applicatieplatform; u blijft verantwoordelijk voor uw code, configuratie, identiteiten en gegevens. Bij software as a service (SaaS) gebruikt u een kant-en-klare applicatie zoals e-mail, CRM of boekhouding; uw deel gaat vooral over wie toegang heeft, met welke rechten en meerfactorauthenticatie, hoe gegevens worden gedeeld, en een eigen kopie van belangrijke gegevens. Veel bedrijven gebruiken alle drie tegelijk. Deel elke dienst in naar type, want de vragen van een auditor of verzekeraar verschillen per type, net als de logs die u kunt krijgen.

https://netsenx.com/nl/faq/what-is-the-difference-between-iaas-paas-and-saas

## Worden we veiliger door naar de cloud te gaan?

Dat kan, voor de delen die de aanbieder overneemt, maar het verplaatst risico meer dan dat het risico wegneemt. Een grote aanbieder patcht zijn infrastructuur, draait redundante datacenters en heeft securityteams die weinig middelgrote bedrijven zich kunnen veroorloven, dus fysieke beveiliging, hardwarestoringen en basisbeschikbaarheid worden meestal beter. Wat niet verhuist, is de verantwoordelijkheid voor identiteiten, configuratie en gegevens, en die liggen daarna meer open: een cloudbeheerdersaccount is overal op internet bereikbaar, een opslaginstelling kan bestanden met één klik openbaar maken, en een gestolen wachtwoord zonder meerfactorauthenticatie opent alles tegelijk. Aanvallers zijn bedrijven naar de cloud gevolgd, en veel incidenten die ze daar veroorzaken beginnen met een gephisht account of een uitgelekte toegangssleutel. Veilig verhuizen betekent MFA op elk account, minimale rechten voor beheerders, ingeschakelde en bekeken logging, back-ups die u zelf beheert en iemand die eigenaar is van de cloudconfiguratie. Ook uw kantoornetwerk blijft ertoe doen: laptops, printers en achtergebleven servers zijn vaak de plek waar een aanvaller het eerst binnenkomt.

https://netsenx.com/nl/faq/does-moving-to-the-cloud-make-us-safer

## Wat ziet een netwerksensor van ons cloud- en SaaS-verkeer?

De verbindingen tussen uw apparaten en de cloud, niet wat er in de cloud gebeurt. Een sensor op het kantoornetwerk of een agent op een server ziet welke apparaten met welke cloud- en SaaS-diensten verbinden, wanneer, hoe vaak en hoeveel data in elke richting gaat, plus de servernaam in de TLS-handshake waar pakketten worden vastgelegd. Dat is genoeg om een laptop op te merken die gigabytes uploadt naar een opslagdienst die hij nooit gebruikte, een server die om de paar minuten contact zoekt met een gehuurde cloudmachine, of een apparaat dat met een onverwachte regio praat. Hij ziet niet wat gebruikers binnen een SaaS-applicatie doen, zoals een map openbaar delen, een doorstuurregel maken of een app toegang tot een mailbox geven; hij ziet geen verkeer tussen clouddiensten; en hij ziet geen medewerkers die thuis op onbeheerde apparaten werken. Dat komt uit de auditlogs en beheerconsoles van de aanbieder zelf. NetSenX dekt de netwerkkant: beaconing, scans, laterale beweging en ongewoon uitgaand volume op elk abonnement. Het vervangt de logs van uw cloudaanbieder niet.

https://netsenx.com/nl/faq/what-does-a-network-sensor-see-of-cloud-traffic

## Kan NetSenX onze servers in de cloud monitoren?

Gedeeltelijk: het ziet het netwerkgedrag van Linux-servers waarop zijn agent draait, waar die ook staan, maar het leest de beheerlaag van uw cloudaanbieder niet. De NetSenX-agent draait op Linux en macOS, dus een virtuele Linux-server die u bij een cloudaanbieder beheert, kan hem dragen zoals elke andere Linux-machine; de agent ziet dan de verbindingen van die server, en de kerndetecties werken op elk abonnement: beaconing naar een command-and-controlserver, scans, laterale beweging naar andere servers en ongewoon uitgaand datavolume. Elke zulke server telt als een apparaat in uw abonnement. Buiten beeld blijven: beheerde diensten die u niet zelf draait, zoals databases, serverloze functies en opslag; verkeer tussen clouddiensten dat nooit langs een server met agent komt; en alles in de beheerlaag van de aanbieder, zoals aanmeldingen op accounts, rechtenwijzigingen en configuratie. Zet daarvoor de audit- en flowlogs van de aanbieder zelf aan en stuur ze naar een plek waar iemand ze bekijkt. Samen geven beide beelden u het netwerkgedrag van uw servers en de accountactiviteit eromheen.

https://netsenx.com/nl/faq/can-netsenx-monitor-our-cloud-servers

## Hoe onderscheid ik legitiem cloudverkeer van de gehuurde server van een aanvaller?

Door te kijken wie de bestemming is, hoe de verbinding zich gedraagt en of iets in uw bedrijf haar verklaart. Aanvallers houden van gehuurde cloudservers, omdat iedereen er in minuten een kan aanmaken en het adres van een gerenommeerde aanbieder is, dus de naam van de aanbieder alleen bewijst niets. Betere vragen: past de bestemming bij een dienst die u gebruikt, volgens de naam in de TLS-handshake of DNS, en staat die dienst op uw leverancierslijst? Is de verbinding regelmatig, klein en dag en nacht, zoals een programma dat zich meldt, in plaats van door mensen tijdens werktijd gedreven? Begon ze direct na iets ongewoons op dat apparaat, zoals een nieuw programma of een aanmelding vanuit het buitenland? Opent een server die normaal alleen verbindingen ontvangt ineens zelf verbindingen naar buiten? Een legitieme back-up- of monitoringdienst heeft meestal een gedocumenteerde bestemming en een contract; een onbekende virtuele machine die een werkplek elke vijf minuten benadert, niet. NetSenX signaleert op elk abonnement dat patroon van regelmatige check-ins, beaconing genoemd, en ongewoon uitgaand volume, met de bestemming, zodat u de juiste eigenaar kunt vragen.

https://netsenx.com/nl/faq/how-to-tell-legitimate-cloud-traffic-from-an-attackers-server

## Welke van onze servers verbinden met goedkope cloudhostingproviders, en waarom?

Zoek het eerst uit aan de hand van de verbindingen en vraag het daarna de eigenaar van elke server, want de meeste van zulke verbindingen hebben een saaie verklaring en een paar niet. Legitieme redenen zijn monitoring- en back-updiensten, updatemirrors, de API van een leverancier, een testmachine van een ontwikkelaar of een SaaS-aanbieder die bij een goedkope hoster draait. Zorgwekkende tekenen zijn het omgekeerde: een server die zakelijk geen enkele reden heeft om met internet te praten, verbindingen die zich dag en nacht met vaste tussenpozen herhalen, verkeer dat begon na een incident of een nieuwe installatie, en bestemmingen die niemand in het bedrijf herkent. Gehuurde virtuele servers bij goedkope hosters zijn een veelgebruikte plek voor besturingsservers van aanvallers en om gestolen gegevens te verzamelen, juist omdat ze goedkoop, snel en anoniem te huren zijn. Houd per server een lijst van verwachte bestemmingen bij, bespreek die met de eigenaren en blokkeer uitgaand verkeer van servers die het niet nodig hebben. Op elk abonnement toont NetSenX verbindingen van uw hosts met hun bestemmingen en waarschuwt het bij beaconing en ongewoon uitgaand volume, de patronen die hier het zwaarst wegen.

https://netsenx.com/nl/faq/why-do-our-servers-connect-to-cheap-cloud-hosting-providers

## Kunnen aanvallers command-and-control verstoppen in vertrouwde clouddiensten?

Ja, en dat doen ze, omdat verkeer naar een bekende clouddienst zelden wordt geblokkeerd of in twijfel getrokken. Malware kan instructies ophalen uit een bestand in een publiek cloudopslagaccount, een gedeeld document, een site voor codehosting, de botinterface van een berichtenapp of een contentdeliverynetwerk, en gestolen gegevens langs dezelfde weg terugsturen. Voor een firewall die bestemmingen op reputatie beoordeelt, lijkt dat op een gewone medewerker die een populaire dienst gebruikt. Wat het toch verraadt, is gedrag. Een programma dat met vaste tussenpozen, dag en nacht, een cloudbestand opvraagt vanaf een apparaat waarvan de gebruiker niet aan het werk is, heeft een ritme dat mensen niet hebben; uploads kunnen voor dat apparaat ongewoon groot zijn; en de clientfingerprint in de TLS-handshake past misschien niet bij een browser of bij de officiële app van de dienst. Praktische stappen: sta alleen de clouddiensten toe die het bedrijf gebruikt, per tenant waar uw tools dat toelaten, en onderzoek apparaten die met privéaccounts van populaire diensten praten. NetSenX detecteert beaconing en ongewoon uitgaand volume op elk abonnement, wat de bestemming ook is, en TLS-fingerprints vanaf het Starter-abonnement waar de agent pakketten vastlegt.

https://netsenx.com/nl/faq/can-attackers-use-trusted-cloud-services-for-command-and-control

## Hoe onderscheiden we een legitieme cloudsynchronisatie van datadiefstal?

Vergelijk de overdracht met wat dat apparaat normaal doet en met de tools die uw bedrijf echt gebruikt. Een syncclient die bestanden naar de goedgekeurde opslagdienst stuurt, volgt een patroon: hij draait op werkplekken van mensen die hem gebruiken, het volume stijgt en daalt met de werktijden, en de bestemming is de dienst waarvoor u betaalt. Datadiefstal wijkt meestal op minstens één punt af: een server in plaats van een werkplek uploadt veel; de bestemming is een privé- of onbekend opslagaccount, een site voor bestandsdeling of een gehuurde server; het volume ligt ver boven het gebruikelijke niveau van die host; het gebeurt 's nachts of in het weekend; of het volgt op andere waarschuwingssignalen zoals scans of nieuwe beheerdersaanmeldingen. Tools die aanvallers hiervoor gebruiken, zoals commandoregelprogramma's voor synchronisatie, lijken vaak precies op een legitieme back-up. Vraag eerst de eigenaar van de host en bekijk daarna in de logs van de opslagaanbieder welk account is gebruikt. Op elk abonnement waarschuwt NetSenX bij ongewoon uitgaand datavolume per host en toont het de bestemming; welke bestanden zijn verstuurd, ziet het niet.

https://netsenx.com/nl/faq/how-to-tell-a-cloud-sync-from-data-theft

## Kunnen we zien of een vertrekkende medewerker bedrijfsgegevens naar de cloud uploadt?

U kunt zien of een bedrijfsapparaat ongewone hoeveelheden data naar clouddiensten stuurt, vaak het nuttigste vroege signaal, maar niet wie het deed of welke bestanden het waren. In de weken voor iemands vertrek is een sterke stijging van uploads vanaf diens laptop naar een privéopslagdienst, een site voor bestandsoverdracht of een AI-tool een gesprek waard, zeker op vreemde tijden. Een goed uitdienstproces telt zwaarder dan detectie: leg schriftelijk vast wat bij het bedrijf blijft, trek op de laatste dag de toegang tot SaaS- en cloudaccounts in, herroep tokens en app-wachtwoorden, controleer deellinks en doorstuurregels in mail en opslag, en neem apparaten in. Preventie van datalekken en de auditlogs van uw opslag- en maildiensten kunnen bestandsnamen tonen; een netwerksensor niet. Houd elke controle proportioneel, gericht op apparaten en bedrijfsgegevens, en afgestemd met HR en waar nodig de ondernemingsraad, want het monitoren van personeel is in elk EU-land gereguleerd. Op elk abonnement waarschuwt NetSenX bij ongewoon uitgaand datavolume vanaf een apparaat en toont het de bestemming.

https://netsenx.com/nl/faq/can-we-see-if-a-leaving-employee-uploads-company-data-to-the-cloud

## Kan ransomware de bestanden bereiken die we in de cloud bewaren?

Ja, vooral via de apparaten en accounts die ze synchroniseren of beheren. Versleutelt ransomware bestanden op een laptop waarvan de mappen met cloudopslag worden gesynchroniseerd, dan uploadt de syncclient trouw de versleutelde versies, en veranderen de kopieën in de cloud ook. Een aanvaller met een gestolen beheerdersaccount kan gegevens rechtstreeks in de dienst wissen of versleutelen, back-ups en versies verwijderen, of eerst alles wegsluizen en dreigen met publicatie. Wat helpt: laat versiebeheer van bestanden aanstaan met voldoende geschiedenis en weet hoe u een hele map in één keer terugzet; bescherm beheerdersaccounts met phishingbestendige meerfactorauthenticatie en scheid ze van dagelijkse accounts; zet verwijderbeveiliging of bewaarvergrendeling aan waar de dienst dat biedt; houd een onafhankelijke back-up die dezelfde beheerders niet kunnen verwijderen; en beperk synchronisatie tot de mappen die mensen nodig hebben. Let op de stappen vóór de versleuteling, want daar kunt u nog ingrijpen: op elk abonnement detecteert NetSenX beaconing, scans, laterale beweging en ongewoon uitgaand volume, ook grote uploads naar cloudopslag. Acties in de beheerconsole van de clouddienst ziet het niet.

https://netsenx.com/nl/faq/can-ransomware-reach-our-cloud-files

## Maakt de SaaS-aanbieder een back-up van onze gegevens?

Meestal niet op de manier die u nodig hebt. SaaS-aanbieders beschermen hun dienst tegen hun eigen storingen, met redundante opslag en noodherstel, maar ze beloven doorgaans niet uw gegevens te herstellen na iets wat u of een aanvaller binnen uw account deed. Verwijderde items blijven een beperkte tijd in prullenbakken en versiegeschiedenis staan en verdwijnen daarna; een ransomwareaanval die gesynchroniseerde bestanden versleutelt, een kwaadwillende beheerder die mailboxen wist of een synchronisatiefout die een map overschrijft, kan langer duren dan die termijnen; en als een abonnement of gebruikerslicentie afloopt, kunnen de gegevens worden verwijderd. Lees de voorwaarden van uw aanbieder: de meeste beschrijven deze verdeling als onderdeel van gedeelde verantwoordelijkheid. Doen de gegevens ertoe, houd dan een eigen kopie: een back-updienst of export die mail, bestanden en belangrijke applicatiegegevens kopieert naar opslag die de SaaS-beheerders niet kunnen wissen, bewaard zo lang als uw zakelijke en wettelijke behoeften vragen. Test minstens één keer het herstel van een mailbox en een map, want dan komen de gaten aan het licht. Een netwerksensor helpt hier niet; dit is planning van back-ups en bewaartermijnen.

https://netsenx.com/nl/faq/is-our-saas-data-backed-up-by-the-provider

## Hoe beveiligen we onze Microsoft 365- of Google Workspace-accounts?

Begin bij identiteiten, want de meeste accountovernames starten met een gephisht of hergebruikt wachtwoord. De basis, op volgorde: meerfactorauthenticatie voor elke gebruiker, met phishingbestendige methoden zoals beveiligingssleutels of passkeys voor beheerders; aparte beheerdersaccounts die alleen voor beheer worden gebruikt, en zo weinig mogelijk globale beheerders; verouderde authenticatieprotocollen die MFA omzeilen uitgeschakeld; aanmeldbeleid dat risicovolle locaties of onbeheerde apparaten blokkeert waar uw licentie dat toelaat; auditlogging ingeschakeld en lang genoeg bewaard om te onderzoeken; waarschuwingen bij nieuwe doorstuurregels, nieuwe beheerdersrollen en nieuwe toestemmingen voor OAuth-apps; grenzen aan extern delen en aan apps van derden die gebruikers mogen koppelen; en een back-up van mail en bestanden buiten de aanbieder, want diens prullenbakken zijn geen back-up. Bekijk beheerdersrollen en gastaccounts elk kwartaal. Het meeste is configuratie waarvoor u al betaalt. Een netwerksensor ziet niet wat er binnen deze diensten gebeurt; wat hij toevoegt is zicht op de apparaten die ermee verbinden, zoals een laptop die met beaconing begint nadat iemand een phishingbijlage opende.

https://netsenx.com/nl/faq/how-to-secure-microsoft-365-and-google-workspace-accounts

## Wat is OAuth-consentphishing?

Het is een aanval waarbij het slachtoffer wordt verleid een kwaadaardige app toegang tot zijn account te geven, in plaats van een wachtwoord af te staan. De gebruiker krijgt een link naar iets dat lijkt op een handige app of een documentverzoek, meldt zich aan op de echte pagina van Microsoft of Google en klikt om rechten goed te keuren, zoals mail, bestanden of contacten lezen. Vanaf dat moment heeft de app van de aanvaller een token dat zonder wachtwoord werkt en vaak een wachtwoordwijziging en meerfactorauthenticatie overleeft, omdat de gebruiker toestemming gaf. Het werkt juist omdat elke pagina die het slachtoffer ziet echt is. Verdediging: beperk toestemming door gebruikers zodat alleen geverifieerde uitgevers of door de beheerder goedgekeurde apps toegang kunnen krijgen, eis beheerdersbeoordeling voor risicovolle rechten, laat waarschuwen bij nieuwe app-toestemmingen en bekijk regelmatig de lijst met gekoppelde apps, waarbij u verwijdert wat niemand herkent. Vindt u een kwaadaardige toestemming, trek dan de app en haar tokens in en controleer in de auditlogs waartoe ze toegang had. Een netwerksensor ziet toestemmingen niet, die gebeuren bij de identiteitsprovider; daar horen de controles.

https://netsenx.com/nl/faq/what-is-oauth-consent-phishing

## Welke cloud- en SaaS-logs moeten we aanzetten en bewaren?

De logs die u nodig hebt om na een incident te beantwoorden wat er gebeurde: wie zich aanmeldde, wat er veranderde en welke gegevens werden ingezien. Controleer voor elke cloud- of SaaS-dienst dat dit aanstaat: aanmeldlogs met locatie en apparaat; beheer- en configuratiewijzigingen, zoals nieuwe rollen, beleidsregels, doorstuurregels en app-toestemmingen; toegang tot bestanden en mailboxen waar de dienst dat biedt; API-activiteit voor cloudaccounts; en netwerkflowlogs voor uw cloudnetwerken als u daar servers draait. Kijk daarna hoe lang elk log standaard wordt bewaard, want sommige diensten bewaren maar een korte periode tenzij u meer betaalt of ze exporteert. Bewaar kopieën op een plek waar de beheerders van die dienst ze niet kunnen wissen, zodat een aanvaller met beheerrechten het spoor niet kan uitwissen. Bepaal wie ze bekijkt en welke gebeurtenissen een waarschuwing geven. Het melden van incidenten onder NIS2 en de AVG, en uw verzekeraar, verwachten dat u een tijdlijn kunt reconstrueren. Een netwerksensor levert de apparaatkant van die tijdlijn: NetSenX bewaart alerts gedurende de periode die uw abonnement omvat, met hosts, bestemmingen en tijdstippen.

https://netsenx.com/nl/faq/what-logs-should-we-keep-for-cloud-and-saas

## Wat gebeurt er als cloudtoegangssleutels uitlekken, bijvoorbeeld op GitHub?

Meestal niets goeds, en snel, want aanvallers doorzoeken publieke coderepository's voortdurend op sleutels. Een cloudtoegangssleutel of API-token werkt als een wachtwoord dat nooit om meerfactorauthenticatie vraagt; wie hem heeft, kan het account met de rechten van die sleutel overal vandaan gebruiken. Typisch misbruik loopt van dure rekenkracht starten voor cryptomining tot het kopiëren van opslagbuckets en databases, en het aanmaken van nieuwe gebruikers zodat de aanvaller toegang houdt nadat de sleutel is ingetrokken. Lekken ontstaan via code in publieke of gedeelde repository's, configuratiebestanden in back-ups, screenshots, CI-logs en chatberichten. Gebeurt het: trek de sleutel meteen in of roteer hem, niet pas na het onderzoek; controleer in de activiteitenlogs van het account alles wat er sinds het lek mee is gedaan, inclusief nieuwe gebruikers, sleutels en resources in ongebruikelijke regio's; verwijder wat de aanvaller heeft aangemaakt; en controleer de facturering. Om het te voorkomen: gebruik secret scanning in uw repository's, kortlevende inloggegevens in plaats van langlevende sleutels, smalle rechten per sleutel en budgetwaarschuwingen. Een netwerksensor ziet geen sleutel die op internet is gepubliceerd; de gevolgen op servers die hij in de gaten houdt, mogelijk wel.

https://netsenx.com/nl/faq/what-happens-if-cloud-access-keys-leak

## Wat is een verkeerd ingestelde opslagbucket en hoe voorkomen we die?

Het is cloudopslag die door meer mensen leesbaar of zelfs beschrijfbaar is dan bedoeld, vaak door iedereen op internet. Diensten voor objectopslag laten u een bucket of container met één instelling of link openbaar delen, handig voor de afbeeldingen van een website en gevaarlijk voor back-ups, exports, facturen of klantbestanden. Veel geruchtmakende datalekken waren helemaal geen hacks, maar bestanden die iemand vond die naar open buckets zocht. U voorkomt het met een paar gewoontes: zet bij de aanbieder de accountbrede blokkade van openbare toegang aan, tenzij een bucket echt openbaar moet zijn, en zet openbare inhoud in aparte, duidelijk benoemde buckets; geef de voorkeur aan ondertekende links met beperkte geldigheid boven openbaar delen; versleutel gegevens en beperk wie deelinstellingen mag wijzigen; gebruik de configuratiecontroles van de aanbieder of een postuurtool die openbare opslag signaleert; en bekijk deellinks in SaaS-opslag, zoals links die werken voor iedereen die ze heeft. Controleer na elk nieuw project, want testbuckets zijn vaak de boosdoener. Een netwerksensor ziet geen bucketinstellingen; dat hoort bij het configuratiebeheer van de cloud.

https://netsenx.com/nl/faq/what-is-a-misconfigured-storage-bucket

## Wat is de metadataservice in de cloud, en waarom willen aanvallers erbij?

Het is een speciaal intern adres op elke virtuele machine in de cloud waar de machine informatie over zichzelf kan opvragen, inclusief tijdelijke inloggegevens voor de rechten die eraan zijn toegekend. Software op de server gebruikt die inloggegevens om opslag, databases en andere clouddiensten te bereiken zonder wachtwoord in de configuratie, wat een goede praktijk is. Het risico is dat alles wat de server een webverzoek naar dat adres kan laten sturen, de inloggegevens ook kan lezen. Een veelvoorkomende route is server-side request forgery (SSRF): een fout in een webapplicatie waardoor een aanvaller de server een URL naar keuze laat ophalen. Met de inloggegevens in handen handelt de aanvaller in uw cloudaccount met de rechten van de server. Verdediging: eis de nieuwere, sessiegebaseerde versie van de metadataservice waar uw aanbieder die biedt, want die blokkeert eenvoudige vervalste verzoeken; geef elke serverrol alleen de rechten die nodig zijn; herstel SSRF-fouten en valideer URL's die applicaties ophalen; en laat waarschuwen wanneer inloggegevens uit de rol van een server van buiten uw omgeving worden gebruikt, wat de activiteitenlogs van de aanbieder kunnen tonen.

https://netsenx.com/nl/faq/what-is-the-cloud-metadata-service-and-why-do-attackers-want-it

## Hoe herkennen we cryptomining in een gecompromitteerd cloudaccount?

Meestal eerst op de rekening, en daarom zijn budgetwaarschuwingen de goedkoopste detectie die u kunt instellen. Aanvallers die cloudinloggegevens in handen krijgen, starten vaak veel krachtige virtuele machines of containers, regelmatig in regio's die u nooit gebruikt, om op uw kosten cryptovaluta te minen. Tekenen: een plotselinge stijging van de rekenkosten of van het aantal instances, machines met GPU-types die niemand heeft besteld, nieuwe resources in onbekende regio's, nieuwe toegangssleutels of gebruikers die rond dezelfde tijd zijn aangemaakt, en servers die dag en nacht op volle CPU draaien. Op een server die u zelf beheert, is een miningproces ook op het netwerk te zien: gestage, langdurige verbindingen met miningpools, vaak op ongebruikelijke poorten, vanaf een machine die normaal alleen webverzoeken bedient. Reageer door de gebruikte inloggegevens in te trekken, alles te verwijderen wat de aanvaller in alle regio's heeft aangemaakt, te zoeken naar persistentie zoals nieuwe gebruikers, rollen en geplande functies, en de aanbieder naar de kosten te vragen. NetSenX ziet het netwerkgedrag van servers met zijn agent, zoals regelmatige verbindingen met een onbekende bestemming; uw cloudrekening of resources zonder agent bewaakt het niet.

https://netsenx.com/nl/faq/how-to-spot-cryptomining-in-a-compromised-cloud-account

## Hoe vinden we SaaS-apps die niemand heeft goedgekeurd?

Combineer een paar goedkope bronnen, want geen enkele ziet alles. De identiteitsprovider toont bij welke apps mensen zich met hun bedrijfsaccount aanmelden, inclusief OAuth-apps die ze aan mail of bestanden hebben gekoppeld. Declaraties en creditcardafschriften laten abonnementen zien die teams hebben gekocht. Browser- en endpointbeheer kan geïnstalleerde extensies en desktopapps opsommen. DNS-logs en logs van firewall of proxy tonen welke diensten bedrijfsapparaten bereiken. Sorteer de lijst daarna: tools die een goedgekeurde tool dubbelen, tools die bedrijfs- of klantgegevens bevatten, en onschuldige. Besluit voor elke tool die gegevens verwerkt of u hem netjes goedkeurt, met contract en beheer, vervangt of uitfaseert, en leg gebruikers uit waarom. Eén keer per kwartaal gedaan, blijft de lijst kort. Een netwerkbeeld helpt bij het deel over bereik: NetSenX toont welke hosts met welke bestemmingen verbinden, met een eigen overzicht voor AI-diensten vanaf het Pro-abonnement; het herkent niet elke SaaS-applicatie bij naam en ziet geen aanmeldingen of app-toestemmingen, die bij de identiteitsprovider liggen.

https://netsenx.com/nl/faq/how-to-find-saas-apps-nobody-approved

## Wat zijn CSPM, CASB en SSPM, en hebben we ze nodig?

Het zijn drie soorten cloudbeveiligingstools die naar verschillende dingen kijken. Cloud security posture management (CSPM) controleert de configuratie van uw cloudaccounts, zoals openbare opslag, open firewallregels, ontbrekende versleuteling of te ruime rechten, tegen goede praktijk en meldt afwijkingen. SaaS security posture management (SSPM) doet hetzelfde voor SaaS-applicaties en controleert instellingen zoals verplichte MFA, extern delen en beheerdersrollen. Een cloud access security broker (CASB) zit tussen gebruikers en clouddiensten, via een proxy of de API's van de aanbieders, om te ontdekken welke diensten worden gebruikt en beleid af te dwingen, zoals het uploaden van gevoelige gegevens blokkeren. Of u ze nodig hebt, hangt af van de schaal. Een bedrijf met één cloudaccount en één kantoorpakket komt vaak ver met de ingebouwde aanbevelingen en beveiligingsscores van de aanbieders, zonder extra kosten. Meerdere cloudaccounts, veel SaaS-tools of gereguleerde gegevens maken aparte tools zinvoller. Geen ervan kijkt naar het gedrag van apparaten op uw netwerk; dat is een andere laag, die netwerkdetectie dekt.

https://netsenx.com/nl/faq/what-are-cspm-casb-and-sspm

## Wat moeten we een SaaS-leverancier over beveiliging vragen voordat we tekenen?

Stel vragen waarvan u de antwoorden kunt controleren en die ertoe doen als er iets misgaat. Bewijs: welke onafhankelijke rapporten of certificaten dekken de dienst die u koopt, zoals een SOC 2 Type II-rapport of een ISO/IEC 27001-certificaat, met reikwijdte en datum, en mag u ze inzien? Gegevens: waar worden ze opgeslagen en verwerkt, welke subverwerkers zijn betrokken, worden ze gebruikt om modellen te trainen, hoe lang worden ze bewaard en hoe krijgt u ze bij vertrek terug in een bruikbaar formaat? Toegang: single sign-on, verplichte MFA, rolgebaseerde rechten en exporteerbare auditlogs. Incidenten: hoe snel informeren ze u, via welk kanaal, en welke steun bieden ze bij uw eigen meldplichten onder de AVG of NIS2? Weerbaarheid: back-ups, hersteldoelen en bescherming tegen misbruik van een beheerdersaccount. Kwetsbaarheden: hoe behandelen ze meldingen en hoe snel patchen ze? Zet de belangrijkste antwoorden in het contract of de verwerkersovereenkomst, niet alleen in een vragenlijst. Een kleinere leverancier met duidelijke, eerlijke antwoorden kan veiliger zijn dan een grote met vage.

https://netsenx.com/nl/faq/what-should-we-ask-a-saas-vendor-about-security

## Wie is verantwoordelijk als onze SaaS-aanbieder wordt gehackt?

Meestal allebei, voor verschillende dingen. De aanbieder is verantwoordelijk voor de beveiliging van zijn dienst, en onder de AVG moet een aanbieder die als uw verwerker optreedt u zonder onredelijke vertraging informeren nadat hij kennis heeft gekregen van een inbreuk in verband met persoonsgegevens. U blijft als verwerkingsverantwoordelijke voor de gegevens van uw klanten of medewerkers verantwoordelijk voor het beoordelen van het risico voor de betrokkenen en, waar nodig, voor melding aan de toezichthouder binnen 72 uur nadat u ervan kennis kreeg, en voor het informeren van de betrokkenen bij een hoog risico. Valt uw bedrijf onder NIS2, dan kan een significant incident bij een leverancier uw eigen meldplichten activeren, en NIS2 verwacht dat u de beveiliging van de toeleveringsketen beheert als onderdeel van uw risicobeheersmaatregelen. Veel van de praktijk wordt in contracten geregeld: meldtermijnen, samenwerking, informatie die u krijgt en aansprakelijkheid. Bereid u vooraf voor: weet welke leveranciers welke gegevens hebben, houd hun beveiligingscontacten bij de hand en neem een inbreuk bij een leverancier op in uw incidentplan. Uw nationale NIS2-wet kan details toevoegen; controleer die.

https://netsenx.com/nl/faq/who-is-responsible-when-a-saas-provider-is-breached

## Maakt NIS2 ons verantwoordelijk voor de beveiliging van onze cloudaanbieders?

Niet voor het beheer ervan, wel voor het beheersen van het risico dat het voor u oplevert, als uw bedrijf onder NIS2 valt. Richtlijn (EU) 2022/2555 noemt de beveiliging van de toeleveringsketen, inclusief beveiligingsaspecten van de relaties met rechtstreekse leveranciers en dienstverleners, onder de maatregelen voor het beheer van cybersecurityrisico's in artikel 21. In de praktijk betekent dat: weten van welke cloud- en SaaS-aanbieders uw belangrijke diensten afhangen, hun beveiliging beoordelen, eisen in contracten opnemen en plannen voor hun uitval of compromittering. Aanbieders van cloudcomputingdiensten staan zelf in NIS2 als entiteiten in de sector digitale infrastructuur, dus veel van hen hebben eigen verplichtingen; dat helpt, maar vervangt uw beoordeling niet. Nuttig bewijs van aanbieders zijn onafhankelijke auditrapporten, certificeringen met een duidelijke reikwijdte, toezeggingen over het melden van incidenten en exitvoorwaarden. Houd een leveranciersregister bij met de gegevens en diensten die elk ondersteunt, en bekijk het jaarlijks en na incidenten. Nationale omzettingen kunnen eisen of richtlijnen toevoegen; controleer de wet van uw land en de publicaties van uw autoriteit.

https://netsenx.com/nl/faq/does-nis2-make-us-responsible-for-our-cloud-providers

## Wat doen we als een cloud- of SaaS-account is gecompromitteerd?

Eerst indammen, dan uitzoeken wat er gebeurde, en onderweg alles vastleggen. Indammen: reset het wachtwoord en trek alle actieve sessies en tokens van het account in; verwijder MFA-methoden die u niet hebt geregistreerd en registreer opnieuw; zoek en verwijder nieuwe doorstuurregels, app-toestemmingen, API-sleutels, gebruikers of beheerdersrollen die de aanvaller heeft aangemaakt; en ging het om een beheerdersaccount, bekijk dan de hele tenant of het hele cloudaccount, want aanvallers maken achterdeurtjes. Onderzoek: gebruik de aanmeld- en auditlogs van de aanbieder om vast te stellen wanneer de toegang begon, vanwaar, en wat er werd gelezen, gewijzigd, gedeeld of gedownload; controleer of hetzelfde wachtwoord elders werd gebruikt. Bepaal daarna de verplichtingen: toegang tot persoonsgegevens kan een melding onder de AVG binnen 72 uur na kennisname betekenen, en een significant incident kan in uw land onder NIS2 meldplichtig zijn. Kijk ook naar de apparaten: het gestolen wachtwoord kwam vaak van een besmette laptop of een phishingpagina. Op elk abonnement kan NetSenX laten zien of een apparaat in uw netwerk rond die tijd begon met beaconing, scans of ongewone hoeveelheden uitgaande data. De aanmeldingen op het cloudaccount ziet het niet.

https://netsenx.com/nl/faq/what-to-do-if-a-cloud-account-is-compromised

FAQ: https://netsenx.com/nl/faq