De 8 grootste Google Cloud-beveiligingsfouten.
Goede technologie biedt alleen bescherming als deze correct wordt geïmplementeerd. Organisaties die nieuw zijn met Google Cloud kunnen belangrijke functies die gegevens of virtuele machines beschermen over het hoofd zien of buiten beschouwing laten. Van het blootstellen van gevoelige gegevens in BigQuery-tabellen tot het overautoriseren van toegang tot nieuwe projecten en het onbewaakt achterlaten van virtuele machines:
Hier zijn acht belangrijke Google Cloud-beveiligingsfouten die niet over het hoofd gezien mogen worden:
- Het niet implementeren van segmentatie op applicatieniveau
Google’s VPC Service Controls implementeren segmentatie op een slimmere manier over servers, waardoor meerdere virtuele machines met databases kunnen praten. Gebruikers maken vaak gebruik van VPC bij het bouwen of verplaatsen van applicaties.
De tool stelt segmentatiebeleidslijnen op applicatieniveau in, wat betekent dat databases met persoonlijke klantgegevens worden geïdentificeerd en alleen specifieke applicaties toegang krijgen. VPN Service Controls bieden een eenvoudig, gemakkelijk te gebruiken beleid en zorgen ervoor dat tegenstanders geen toegang kunnen krijgen tot een database, zelfs als de poort open is gelaten.
VPC Service Controls hebben een vergelijkbaar doel als de firewall, maar firewalls vooral gebruikt voor externe communicatie, terwijl de tool van Google bedoeld is om intern te segmenteren. Het wordt aangeboden als een ingebouwde mogelijkheid binnen Google Cloud.
- Configuratie-instellingen in Gmail over het hoofd zien
Organisaties die zowel Google Cloud als Gmail gebruiken, moeten enkele configuraties definiëren in termen van gebruikerstoegang en hoe projecten plaatsvinden. Hoe Gmail abonnementen en groepen voor gebruikers definieert, heeft invloed op het Google Cloud Platform als de gebruiker begint met Gmail en vervolgens verhuist naar Google Cloud. Organisaties moeten daarom in hun achterhoofd houden dat de huidige structuur van abonnementen en groepen van invloed is op hoe mensen Google Cloud in de toekomst kunnen gebruiken. Het proces voor het verlenen van machtigingen en toegang in Google is enigszins vergelijkbaar met Active Directory in Azure.
- Niet beoordelen hoe aan de zichtbaarheidseisen kan worden voldaan
Google Cloud heeft de afgelopen twee jaar veel gedaan op het gebied van beveiliging, met als hoogtepunt de nieuwe diensten en functionaliteiten die zijn geïntroduceerd in het Security Command Center van het bedrijf.
Als bedrijven met het Google Cloud Platform werken, is het van belang om te achterhalen of het Security Command Center hen voldoende zicht geeft op al hun cloudimplementaties. De best practice is dat organisaties multi-cloud inzicht moeten krijgen en houden, omdat het er moeilijk is om te beveiligen wat ze niet kunnen zien.
Bedrijven die succes hebben met cloudbeveiliging loggen belangrijke informatie, brengen die logs in context, houden een inventaris bij en controleren wie toegang heeft tot hun gegevens en wat ermee gebeurt. Organisaties moeten investeren in gegevensplatforms voor cloudbeveiliging die compatibel zijn met meerdere providers, aangezien maar weinig bedrijven slechts in één enkele publieke cloud werken.
- Ontbreken van vangrails rond het gebruik van Kubernetes
Containerisatie en Kubernetes hebben het paradigma veranderd waarin de cloud kan migreren en bestaan, en de unieke mentaliteit en denkwijze van Google zorgt voor flexibiliteit en verschillende manieren waarop deze platforms kunnen worden geconsumeerd en geadopteerd.
Kubernetes is ontstaan uit hoe Google zijn eigen software ontwikkelde voor zijn producten, en het bedrijf bracht de technologie vervolgens naar de massa om het bouwen van omgevingen gemakkelijker te maken door gebruik te maken van herhaalbare en geautomatiseerde functiesBovendien brengt Google met Anthos een unieke dimensie op tafel, die klanten flexibiliteit biedt door hen de mogelijkheid te geven om op andere clouds te draaien.
Als een organisatie Anthos in meerdere clouds draait, moet zicht hebben op alle implementaties, de mogelijkheid hebben om te automatiseren en te orkestreren op alle platforms, en de mogelijkheid hebben om gedetailleerde rapporten te krijgen. En aangezien Kubernetes een native integratie heeft in het Google-platform, worden bedrijven aangeraden aan om vangrails aan te brengen rond wat ze doen met Kubernetes.
- Virtuele machines vatbaar maken voor aanvallen
Wanneer traditionele VM’s worden opgestart, is Google niets anders beveiligd dan wat de hypervisor onder zijn dekking biedt. Als gevolg daarvan zijn de VM’s gevoelig voor aanvallen op afstand en voor bevoorrechte insiders.
Google’s Virtual Trust Platform Module (vTPM) is zeer veilige firmware die zorgt voor een diepere bewaking van de integriteit van het systeem. Het maakt deel uit van Google’s Shielded VM, dat een aantal functies en mogelijkheden in één platform samenbrengt om bijvoorbeeld elke VM voortdurend te controleren op sporen van manipulatie.
Shielded VM’s helpen traditionele VM’s veiliger te maken tegen zeer lage kosten de vTPM is na een paar jaar investeren sneller en completer is geworden. Nu de optimalisatie is voltooid zijn afgeschermde VM’s standaard ingeschakeld.
- Blootstelling van gevoelige gegevens in BigQuery-tabellen
Veel bedrijven gebruiken de BigQuery-tabellen van Google om gegevensanalyses uit te voeren, en ze moeten ervoor zorgen dat ze geen gevoelige gegevens blootstellen aan iemand die geen deel uitmaakt van hun organisatie. Het vereist wat extra denkwerk over hoe machtigingen te structureren om ervoor te zorgen dat alleen mensen die toegang moeten hebben tot de tabellen dat ook daadwerkelijk doen.
Er zijn kleine tabellen binnen Google die meer granulariteit bieden in het definiëren van welke mensen toestemming hebben om toegang te krijgen tot die diensten. Maar het beheer van machtigingen voor BigQuery-tabellen is niet zo eenvoudig als voor andere diensten.
Bedrijven moeten bepalen welke tabellen het gevoeligst zijn en de toegang beperken tot de mensen die het echt nodig hebben. Er zijn tools van zowel Google als derden die organisaties inzicht kunnen geven in hun tabellen en tegelijkertijd onnodige toegang kunnen beperken.
- Te veel toegang verlenen bij het starten van een project
Alle machtigingen en beveiligingsstructuren worden per project ingesteld in Google Cloud om botsingen te voorkomen, en projecten kruisen elkaar niet, tenzij er een verbinding tussen de twee wordt gemaakt voor specifieke services. Als gevolg hiervan moeten voor elk afzonderlijk project beveiligingsbeslissingen worden genomen.
Dit kan een uitdaging zijn omdat de tooling van Google nog in ontwikkeling is om het gemakkelijk te maken cookie-cutter-instellingen toe te passen op elk project. Wanneer een project wordt aangemaakt, heeft het volgens hem standaard nergens toegang toe, en moet de gebruiker expliciet alles inschakelen wat nodig is, zoals het opstarten van een API. Bij andere publieke cloudplatforms zijn de API’s volgens hem automatisch toegankelijk.
Als gevolg daarvan overautoriseren ontwikkelaars volgens hem vaak heel snel in Google om een open en permissief kader te krijgen bij de start, en de ingeschakelde mogelijkheden blijven vaak aanstaan, of ze nu nodig zijn of niet. Een aanpak waarbij ontwikkelaars vooraf moeten nadenken over wat er in het project gevraagd wordt, kan pijnlijk zijn, maar het is uiteindelijk veiliger als ze zo weinig mogelijk privileges autoriseren.
- Abnormale toegang tot gevoelige gegevens toestaan
Telkens wanneer een organisatie gegevens in een emmer opslaat, moet zij DLP (data loss prevention) hebben ingeschakeld om ervoor te zorgen dat de emmers consequent worden gescand op gevoelige gegevens, zoals persoonlijk identificeerbare informatie (PII) of gegevens waarvoor PCI-compliance geldt.
Als iemand buiten de context toegang krijgt tot gevoelige gegevens of PII-gegevens exfiltreert, markeert de DLP-tool van Google dit. Google Cloud DLP maakt gebruik van geavanceerde data lake-technologie die het bedrijf al jaren toepast in de consumentenbranche, waar DLP is ingebouwd in de mogelijkheden van Gmail.
Google Cloud heeft een sterk geoptimaliseerde runtime, maar verbruikt wel compute time om gegevens te scannen. Klanten moeten daarom naar de gegevensbeschermingspagina gaan om DLP-mogelijkheden in te schakelen wat op dezelfde manier gebeurt als het inschakelen van opslagmogelijkheden. Zorgen over de bijbehorende compute overhead en de nominale compute kosten hebben ertoe geleid dat sommige klanten DLP niet hebben ingeschakeld.
Bron: crn.com
