GCP-beveiliging: datateams die niet voortdurend brandjes blussen

Dit patroon zie je vaker in datateams dan iemand wil toegeven: om 23.00 uur breekt een pipeline, drie mensen krijgen een melding (van wie er twee niet zeker weten waarom), en niemand weet precies wie eigenaar is van het probleem. Iemand lost het op door ongeveer te doen wat hij de vorige keer deed, het ticket wordt gesloten en voor de toekomst verandert er niets. Dat is geen beveiligingsincident. Dat is een gewone dinsdag.

De meeste datateams worstelen niet omdat ze tools missen. Google Cloud Platform (GCP) alleen al geeft je IAM, Security Command Center, Dataplex, beveiliging op kolomniveau in BigQuery, policies op organisatieniveau en meer. De tools zijn echt goed, maar het probleem is dat goede tools in een slecht gestructureerde omgeving die omgeving niet veilig maken.

Niemand wil een kwetsbare beveiliging bouwen

Vraag een datateam waarom een bepaalde toegangsregel bestaat en de helft van de keren weet niemand het. Misschien is hij twee jaar geleden tijdens een incident ingevoerd. Misschien kwam hij uit een ander project. Misschien had iemand snel toegang nodig om een deadline te halen en heeft niemand er daarna nog naar gekeken.

De complexiteit stapelt zich ongemerkt op.

Die BigQuery-dataset waar de hele organisatie bij kan? Iemand had een deadline. Dat serviceaccount met meer rechten dan het zou moeten hebben? De onderliggende oorzaak oplossen voelde als een grotere klus dan de rol een stapje ophogen. Het systeem onthoudt elke kortere weg, lang nadat de deadline vergeten is.

Hier doet eigenaarschap ertoe. Als duidelijk is wie verantwoordelijk is voor toegang, definities en doorlopend onderhoud, blijven beslissingen gebaseerd op de context. Als eigenaarschap op organisatieniveau onduidelijk is, vullen beveiligingstools dat gat in de verkeerde richting: meer complexiteit, niet meer effectiviteit.

Het gesprek over toegang dat teams blijven vermijden

Het principe van minimale rechten (least privilege) klinkt vanzelfsprekend tot je het echt probeert af te dwingen. Dan wordt het een onderhandeling. Teams willen ruime toegang omdat dat sneller is. Engineers willen serviceaccounts die gewoon werken, zonder elke keer een ticket in te dienen als er een nieuw recht nodig is. Het management wil beveiliging zonder wrijving, en dat is een redelijke wens en echt moeilijk waar te maken.

De teams die dit goed doen, zijn niet de teams met het strengste beleid. Het zijn de teams die vroeg structurele beslissingen hebben genomen. De tools daarvoor bestaan en zijn niet exotisch. Het lastige is eerst de organisatorische beslissingen te nemen: wat telt als gevoelig, wie is aanspreekbaar, welke omgevingen zijn productie. Liggen die vast, dan is de implementatie het eenvoudige deel. Zonder die beslissingen zet je alleen sloten op een gebouw waarin niemand het eens is over welke kamers ertoe doen.

Bij toegangsreviews blijkt of dit standhoudt of uit elkaar valt. Reviews per kwartaal die als serieuze oefening worden behandeld, en niet als vinkje, maken echt verschil. Vertrekt iemand of stopt een project, dan verdwijnen de rechten mee. Teams die deze stap overslaan, ontlopen het werk niet. Ze doen het alleen later, onder druk, nadat er al iets is misgegaan.

Als niemand de meldingen vertrouwt, heb je geen meldingen

Security Command Center is een capabel platform. Het brengt bevindingen in je hele GCP-omgeving aan het licht: verkeerde configuraties, blootgestelde data, afwijkende toegangspatronen, echte dreigingen. Teams die het invoeren zonder het goed te configureren, krijgen elke keer hetzelfde: een overweldigende hoeveelheid bevindingen, waarvan de meeste irrelevant voelen, en een geleidelijk gezamenlijk besluit om niet meer op de meldingen te letten.

De oplossing is niet ingewikkeld, maar vraagt tijd die niemand eraan wil besteden:

• Begrijp de ernstniveaus.
• Onderdruk bevindingen waar je in jouw specifieke omgeving niets mee kunt.
• Stuur meldingen naar mensen die de context hebben om ze te beoordelen (niet naar een gedeelde inbox die iedereen in de gaten houdt en niemand beheert).
• Behandel het afstellen als doorlopend werk, niet als eenmalige inrichtingstaak.

Het doel is een team dat vertrouwt op wat zijn meldingen zeggen, en de structuur heeft om ernaar te handelen.

De grens tussen omgevingen die het verdedigen waard is

Een harde scheiding tussen ontwikkeling en productie is zo'n beslissing die als overhead voelt tot het moment dat ze een ernstig incident voorkomt, en dan voelt ze als het slimste wat je ooit hebt gedaan.

Geen logische scheiding. Een fysieke scheiding: andere projecten, andere serviceaccounts, andere IAM-policies, andere factureringsaccounts. Ontwikkelomgevingen hebben bewust ruime rechten, omdat experimenteren flexibiliteit vraagt. Dat is prima. Wat niet prima is, is dat die omgevingen bij productiedata of -diensten kunnen, en dat gebeurt vaker dan zou moeten omdat de grens nooit duidelijk is getrokken.

Een cloud landing zone met een goede projecthiërarchie en policies op organisatieniveau maakt die scheiding de standaard, in plaats van iets wat ervan afhangt of individuele engineers eraan denken het goed te doen. Met organisatiepolicies in GCP dwing je beperkingen af op resourceniveau, ongeacht wat individuele projecteigenaren configureren, zodat de vangrails blijven staan ook als teams snel werken. In een goed ontworpen cloudfundament bouw je dit goed op, voordat de omgeving zo groot is dat achteraf aanpassen pijn doet.

Er is ook een kostenargument dat makkelijk over het hoofd wordt gezien. Een duidelijke scheiding tussen omgevingen dwingt teams om expliciet te zijn over wat er werkelijk in productie draait, en dat blijkt nuttige informatie. Het verband tussen onduidelijk eigenaarschap en onnodige infrastructuurkosten op GCP is directer dan de meeste teams verwachten, tot ze met een frisse blik naar hun factureringsdata kijken.

Achteraf aanpassen is moeilijk. Brandjes blijven blussen is moeilijker.

Beveiliging is geen project met een eindstreep. Maar er is een wezenlijk verschil tussen een team dat altijd reageert en een team dat genoeg structuur heeft opgebouwd om problemen zonder drama op te vangen. Is je omgeving al complex, dan betekent dat niet dat je opnieuw moet beginnen. Het betekent eerlijk zijn over waar de gaten zitten en ze in de goede volgorde dichten.

De meeste teams zijn dichterbij dan ze denken. De structuur hoeft niet perfect te zijn om veel beter te zijn dan wat brandjes blussen je elke week kost. Dat is het werk dat we doen met teams die er al middenin zitten en de saaie dingen goed willen regelen.