Over platform engineering hadden we het hier eerder al. Het draait erom dat je een technologieplatform bouwt waarop developers makkelijker, sneller en goedkoper ontwikkelen. Met BRYXX gaan we nog een stap verder: we zorgen ervoor dat elke applicatie die je met het platform bouwt automatisch veilig is.
Dit is het ideale scenario: een internal developer platform waarin security zodanig is ingebakken dat elke applicatie die je bouwt automatisch veilig is, zonder dat je daar extra moeite voor hoeft te doen. Daar heb je een zogenaamde security plane voor nodig: de noodzakelijke beveiligingslaag over het hele ontwikkelingsplatform heen.
Hoe veranker je security in het platform?
Die puzzel leg je met een combinatie van verschillende oplossingen, bijvoorbeeld een secrets manager. Als applicaties op eenzelfde platform met elkaar samenwerken via API’s, moet dat uiteraard volledig veilig verlopen. Je zou de wachtwoorden voor die beveiliging kunnen hardcoden in een applicatie, bewaren in een script of – nog erger – ergens in een verborgen bestand in een container. Security through obscurity, zoals dat dan heet.
Bij BRYXX pakken we dat anders aan. Neem nu het ontwikkelingsplatform dat we onlangs uitrolden bij een groot bedrijf. Als een developer daarop aan de slag gaat, krijgt die meteen een kant-en-klare template. De basisapplicatie staat al klaar, met een variabele waarin automatisch het juiste wachtwoord zit, aangeleverd door de secrets manager die standaard in het platform is geïntegreerd. De developer hoeft daar zelf geen werk meer van te maken, of er zelfs nog maar aan te denken.
Een andere onderneming vertelde ons onlangs dat ze het gebruik van SSH niet veilig genoeg vindt bij het gebruik van Ansible. Dan open je SSH namelijk vanuit één centraal punt naar alle servers. Je kan ervoor kiezen om geen enkele developer nog manueel te laten inloggen op een server via SSH. Puppet stelt de servers dan automatisch in. Tools zoals Splunk, Elastic en Dynatrace verzamelen en monitoren centraal alle logdata. Zelfs de Puppet-configuratie scherm je dan af tegen manuele toegang.
De veiligste weg is zo ook de makkelijkste
Door dat soort ingrepen ontstaat een situatie waarin je als developer niet eens meer aan security hoeft te denken. Je hoeft geen key management of user management meer op te zetten als je bijvoorbeeld voor SSH kiest. Er is zelfs geen access point meer dat je zou moeten beveiligen.
Bij de uitrol van die aanpak stoot je in het begin mogelijk op protest bij de developers, wanneer je een ontwikkelingsplatform met ingebakken security aanbiedt. Maar als ze protesteren, betekent dat vooral dat de minst veilige weg (bijvoorbeeld manueel inloggen op servers) voor hen blijkbaar de makkelijkste is. Tot ze enige tijd op het platform aan de slag zijn en beseffen dat dankzij die oplossing de veiligste weg nu net de makkelijkste is. Ze ontwikkelen er sneller op, terwijl elke ontwikkeling gegarandeerd en automatisch veilig is. Zo leg je security niet op als een last, maar draagt ze net bij aan vlotter werk.
Wat met het prijskaartje?
Jazeker, dit vraagt een zekere investering. Maar bedenk dan eens welke winst je boekt door veiliger te werken. Want de vraag is niet of je ooit gehackt wordt, maar wanneer, hoe zwaar en tegen welke prijs. Reken de kosten van een security breach maar eens uit. Met de juiste investering in security hou je het noodlot – en de kosten ervan – zo veel mogelijk op afstand. En als het dan toch toeslaat, staat alles klaar om het verlies tot een minimum te beperken. Al is het risico dan sowieso ook veel kleiner, net omdat elke ontwikkeling standaard veilig is. Je ontwikkelt dan niet alleen sneller en dus goedkoper op het platform, maar ook secure by default. Op die manier win je de investering snel terug.