Wij zijn goed van vertrouwen, zie onze oudere IT systemen. Voor handmatige correctie en onderhoud zijn die systemen vriendelijk toegankelijk gemaakt alsof er een touwtje uit de brievenbus hangt. Daar komen nu ook “foute” specialisten op af met soms heel vervelende gevolgen. We moeten van dat handmatige af, dan kan dat touwtje weg. Pas die systemen aan. Met hedendaagse technieken en wat inspanning krijgen we ze weer betrouwbaar en veilig. Wacht er niet te lang mee. Doe het nu!
Goed van vertrouwen
Dat is eigenlijk een gunstige eigenschap, kennelijk vertrouwen wij elkaar en zijn we verbaasd maar ook boos als iemand dat vertrouwen schaadt. Te goed van vertrouwen is een vorm van naïviteit die genadeloos kan worden afgestraft, sprookjes zijn soms wreed maar je kan er wat van leren.
Wie is daar? Ik ben het Grootmoe, Roodkapje! Ik breng U appels en wijn; doe maar vlug open! “Trek maar aan het touwtje, dan zal de deur wel open gaan!” antwoordde Grootmoe. Nu sprong de deur vanzelf open…
De stafchef van Navalny betichtte onze parlementariërs van naïviteit, zijn zij sukkels? Nee, wij zijn hier in Nederland gewoon niet gewend aan zulke brutaliteit maar we worden er helaas mee geconfronteerd. Zie het als een wijze les, dat is ook de moraal van het sprookje. En trap er een tweede keer niet in.
Vroeger…
Bij de laatste reünie van mijn middelbare school leken de gangen krapper, er stonden rijen kluisjes, dat was vroeger niet zo. Wij gooiden onze pukkel op de grond in de gang en we waren niet bang dat er iets gestolen werd.
Veel van onze IT systemen zijn gebouwd in die onbezorgde tijd, en vaak zijn ze nog actief. Misschien is het slot intussen verbeterd maar Jan en alleman heeft een sleutel en gaat naar binnen voor noodzakelijk werk zoals corrigeren en onderhouden. Binnen is echter niks afgeschermd, daar gaat alles op vertrouwen. Laat niemand zijn sleutel verliezen!
Dacht je vroeger nog: wat moet iemand met mijn gegevens? Nu wil je beslist voorkomen dat jouw gegevens te koop worden aangeboden en dat je op de koop toe nog een boete krijgt vanwege nalatigheid.
Betrouwbaarheid in relatie tot veiligheid
De vroegere achtergrond systemen zijn meestal niet ontworpen om volledig automatisch te werken. Als er wat mis ging dan had je altijd iemand die met de hand een correctie kon doen en het systeem daarna weer op kon starten. Tegenwoordig zien we het veiligheidsrisico hiervan, om te corrigeren moeten mensen toegang hebben tot het IT systeem. Als ze daar binnen zijn, hebben ze vaak (te) ruime bevoegdheden en is het soms moeilijk te zien wat er precies gedaan is. Dat kan voor iemand die naar beste eer en geweten werkt, enorme stress opleveren omdat ieder foutje grote gevolgen kan hebben. In de Media is te volgen wat er kan gebeuren als iemand met een duister doel toegang heeft gekregen.
De druk om die systemen goed te testen was minder omdat men bij fouten terug kon vallen op de corrigerende menselijke hand.
Beveiligen van gegevens
Aan versleutelen van opgeslagen gegevens werd vroeger nauwelijks gedacht. Dat werd als ingewikkeld beschouwd en men was bang voor verlies van performance. Tijdens transport werden gegevens wel weer vaker versleuteld.
Nu complete gegevens bestanden verkocht worden op het “dark web”, is de overtuiging om te versleutelen wel doorgedrongen.
Nog steeds geldt dat een versleutelde opslag de meeste hoofdbrekens kost omdat aanpassen van het bestaande systeem een flink werk lijkt te zijn. Toch kan dat meevallen. Transport versleutelen is in veel gevallen makkelijker aan te passen.
Zorgvuldig omgaan met geheimen (secrets)
De oude systemen willen nog wel eens slordig omgaan met geheimen zoals toegangsgegevens tot databases en andere belangrijke beveiligde plekken. Je mag de geheimen niet prijsgeven dus moet je ze adequaat beveiligen.
Het fabrieksmodel
De fabriek kan symbool staan voor een IT systeem. Het heeft een verwerkingsproces met grondstoffen als invoer en als resultaat een product. De oude fabriek staat symbool voor het naïeve systeem, en de nieuwe voor het betrouwbare en veilige systeem.
Stel je maar een oude fabriek voor, in de hal is het enorm druk, toeleveranciers brengen de grondstoffen en vervoerders halen de eindproducten op. Verderop sleutelt iemand aan de machine en daar werkt (gedeeltelijk) gespecialiseerd personeel aan de productie op basis van een redelijk recent handboek. Er is een discussie gaande of de laatste revisie van de machine ongedaan gemaakt is vanwege een probleem en dat daarom de oude instructies weer gelden. Er is iemand die het allemaal haarfijn weet maar die heeft vandaag een begrafenis en kan eigenlijk niet gestoord worden.
De nieuwe fabriek ziet er anders uit: een gesloten fabriekshal met gekoppelde kluizen voor toevoer van grondstoffen en afvoer van producten.
In de gesloten fabriekshal staat een grote machine. Aan de buitenkant zijn kluizen waar toeleveranciers met hun sleutel grondstoffen kunnen deponeren, het kan er alleen in maar niet uit. Aan de fabriekszijde kan de machine de grondstoffen uit de kluizen halen en via een magisch proces worden de eindproducten gemaakt die door de machine in afhaalkluizen worden gezet. Deze afhaalkluizen zijn aan de buitenkant van de fabriek te openen door vervoerders met een speciale sleutel die de producten vanuit de kluis in de auto kunnen zetten.
Naast de fabriek is er nog een laboratorium waar de machine wordt aangepast voor nieuwe of gewijzigde producten, daar werken specialisten aan. Zij testen de nieuwe machine totdat die goed bevonden is. Dan vervangt hij de oude machine in de fabriekshal.
Wat zijn de verbeteringen?
De fabriek wil constante kwaliteit op alle productie locaties, door te ontwikkelen in het veilige laboratorium verzekert men zich van voorspelbaar gedrag op locatie. Door de grondstoffen, het proces en het eindproduct te beschermen tegen diefstal en sabotage wordt de gewenste kwaliteit bereikt.
De vertaling van fabriek naar IT systeem
De ontwikkel omgeving staat voor het laboratorium. De specialisten van het “DevOps” team werken hier aan de software van de services die gezamenlijk de machine vormen. Door het source control systeem, meestal Git, kunnen ze iedere wijziging traceren. Dat is belangrijk, want als er wat fout gaat is de eerste vraag: wat is er het laatst veranderd, wanneer en door wie? In Git worden meerdere versies bijgehouden: zoals een versie voor de nieuwe aanpassing die nog getest wordt en de versie voor de huidige productiestand die op termijn door de nieuwe aanpassing vervangen wordt. Er is een productie locatie en er zijn (meerdere) test locaties. De bronnen in Git worden gebruikt om automatisch de juiste versies op die locaties uit te rollen. Daarvoor wordt extra informatie bijgehouden.
Zit alles in Git? Nee, gegevens die geheim moeten blijven worden in speciale kluizen opgeslagen.
Door de volautomatische verwerking is er, behalve bij het eenmalig uitrollen, geen behoefte om op locatie te komen. Er wordt daar immers niks van waarde bewaard. De interactieve shell, een heel krachtig maar gevaarlijk hulpmiddel voor menselijke correcties, kan verwijderd worden.
De (cloud)storage containers zijn de kluizen van de fabriekshal, zij voldoen aan alle veiligheidseisen. Per leverancier maak je zo’n container aan en je geeft haar/hem een schrijfsleutel. Alles wat daar geschreven wordt, kan je ophalen en verwerken. De hulpmiddelen en documentatie komen van jouw storage provider. Omdat het systeem van de storage provider er tussen zit, ben je losgekoppeld van jouw toeleverancier.
Het IT systeem maakt altijd een verslag van de verwerking, deze log bevat maar al te vaak gegevens die je niet openbaar wil hebben. Het is belangrijke informatie dus sla je die op in een datakluis.
Het productieproces wordt beschermd tegen ongewenste wijzigingen, dat zijn aanpassingen die niet via Git zijn aangebracht. De machine werkt daarom als een draaiorgel en bestaat uit twee delen, de instructies (orgelboek) en het gedeelte dat die instructies uitvoert (draaiorgel). De instructies zijn versleuteld, aanpassen maar ook lezen is onmogelijk.
Wat is het benodigde werk om een naïef systeem te verbeteren?
Een formele beschrijving maken
De services worden volledig beschreven. De beschrijving wordt verwerkt en het resultaat wordt gebruikt om een instantie van een machine te draaien. Er is extra informatie in de beschrijving, die gebruikt wordt voor het controleren, testen en versioneren.
Een runtime systeem beheren
Dit is de machine, die werkt op basis van de geïmporteerde versleutelde beschrijving. Het verbergt bijvoorbeeld sources van scripts en voorkomt ongewenst parallel draaien (bron van veel ellende) maar maakt gewenst parallel draaien mogelijk. Het faciliteert diensten die het mogelijk maken bestaande programma’s en scripts zonder aanpassingen te laten werken met nieuwe technieken.
Draait de machine normaal gesproken zijn services repeterend, zij is ook inzetbaar op een ontwikkel systeem om een niet repeterende test uit te voeren voordat de instructies gepubliceerd worden.
Versie beheer
Op basis van een aanpassing, een change, ga je een nieuwe versie van de machine ontwikkelen, sommige onderdelen worden vernieuwd, andere worden verwijderd en nieuwe ontstaan. Van al die geraakte onderdelen maak je een nieuwe versie en die koppel je aan de change. Deze heeft een levensloop met als start de ontwikkelfase en als eind de productiefase. Deze kennis wordt gebruikt voor het automatisch samenstellen van de juiste versies voor iedere fase.
Bestaande programma’s aanpassen aan de gewijzigde omstandigheden
Je wilt de bestaande programmatuur het liefst niet aanpassen. Om toch gebruik te maken van versleutelde gegevens uit kluizen, kan je gebruik maken van faciliteiten van het runtime systeem.
Het runtime systeem kan bestanden voor gebruik ontcijferen en bij aanmaak versleutelen. Dat kan geheel onzichtbaar via streams of ultra kort zichtbaar door tijdelijk het filesysteem te gebruiken. Dan hoeft het programma niet aangepast te worden, maar het runtime systeem moet wel extra geconfigureerd worden.
Zichtbare geheimen moeten verwijderd worden uit Git. Neem ze op in de versleutelde instructies van het proces vanuit een sleutelkluis of je kan ze live op halen uit zo’n kluis. Dat laatste kan je het runtime systeem laten doen die het geheim via een “environment variable” kan doorgeven aan het programma.
Gegevens vastleggen voor controle en automatisch testen
De inhoud van Git wordt gebruikt om de instructies van de machine (orgelboek) te maken. De functie die daarvoor opdracht krijgt, kan allerlei eigen controles doen en een laatste controle kan een uitgebreide test van de service zijn.
In de beschrijving van een service wordt daarom verwezen naar de testflow. Die flow is meestal een combinatie van een stap die de testgegevens klaar zet, gevolgd door de stap die de trigger conditie test, om daarna de verwerkingsstap uit te voeren en te eindigen met het opruimen van de rommel. Behalve stap 1, het klaar zetten en stap 4 het opruimen zijn de andere stappen al aanwezig. Die aanwezige stappen zijn zich bewust van de fase waarin ze werken of hun instructies zijn verschillend per fase. Zo kunnen zij bijvoorbeeld een andere database benaderen in de Test fase dan in de Productie fase.
Testen is belangrijk, het gebeurt daarom automatisch voordat de instructies gepubliceerd worden. Omdat pre-publicatie testen niet repeterend uitgevoerd worden, zijn er aparte testomgevingen waar langdurig getest kan worden waarna iemand beslist of de test geslaagd is en de change naar een volgende fase mag gaan.
Op naar betrouwbare en veilige IT, laten we de krachten bundelen!
Naar mijn beste weten is er werk te doen. Er zijn vast en zeker nog veel naïeve systemen. Via de Media horen wij waarschijnlijk slechts het topje van de ijsberg.
Met mijn uitgewerkte methodiek, op basis van moderne technieken, jarenlange ervaring en gezond verstand, ben ik er klaar voor. Wie durft?