De oude websitebeheerder werkt keurig mee aan de overdracht. Hij levert de bestanden aan, maakt een database-export en geeft de nieuwe partij toegang tot de hosting. Er zijn nog wat vragen over een geplande update, maar verder verloopt alles soepel. Tot de nieuwe beheerder de DNS-instellingen wil bekijken. Die staan bij Cloudflare. Of hij daar even toegang toe kan krijgen? Dat kan niet zomaar. De vorige beheerder heeft destijds alle websites die hij onderhoudt ondergebracht in één Cloudflare-account. Daar zitten ook andere klanten in, dus de inloggegevens afgeven is geen optie.
Hij wil best helpen. Als de nieuwe beheerder doorgeeft wat er gewijzigd moet worden, zal hij dat uitvoeren. Maar dat was nu juist niet de bedoeling van de overstap. Er is hier overigens niemand die iets verkeerds hoeft te hebben gedaan. Die gezamenlijke beheeromgeving was destijds waarschijnlijk gewoon handig. De klant hoefde nergens naar om te kijken en de beheerder kon snel wijzigingen doorvoeren. Alleen heeft niemand bedacht wat er moest gebeuren als de samenwerking ooit zou stoppen.
Een website die ergens anders óók bestaat
Het merkwaardige aan Cloudflare is dat een behoorlijk deel van de technische inrichting zich buiten de website bevindt. Stel dat je een Drupal-website verhuist naar een andere server. Je neemt de code, database en bestanden mee. Je controleert de PHP-versie, zorgt dat de cronjobs draaien en past de configuratie aan. Dat is werk, maar je weet tenminste ongeveer waar je moet zoeken.
Bij Cloudflare kunnen in de loop der jaren allerlei instellingen zijn toegevoegd die je in die Drupal-installatie nergens terugvindt. Een uitzondering voor een pagina die niet gecachet mag worden. Een blokkade van bepaalde verzoeken. Een redirect die ooit nodig was na een wijziging van de URL-structuur.
Misschien heeft iemand drie jaar geleden een beveiligingsregel toegevoegd omdat er veel verdachte verzoeken binnenkwamen. Die regel doet inmiddels al zo lang zijn werk dat niemand er meer naar omkijkt. Moet die mee naar het nieuwe account? Waarschijnlijk wel. Maar waarom staat hij daar precies? En wat gebeurt er wanneer je hem weglaat? Dat laatste is een vervelende vraag. Bij beveiligingsinstellingen merk je soms pas dat er iets ontbreekt wanneer het misgaat. Cloudflare heeft gelukkig mogelijkheden om DNS-records te exporteren. Alleen is DNS maar een gedeelte van het verhaal. De export bevat niet vanzelf alle instellingen voor caching, beveiliging, certificaten en andere diensten.
Er zit bovendien een addertje onder het gras. DNS-records worden niet alleen gebruikt om bezoekers naar de website te sturen. Ook e-mail is ervan afhankelijk. Je kunt dus de website keurig overzetten en vervolgens ontdekken dat bepaalde e-mail niet meer wordt afgeleverd.
Het account verhuizen dan maar?
Dat zou mooi zijn, maar een domein overzetten naar een ander Cloudflare-account is geen administratieve naamswijziging. Cloudflare heeft er een aparte handleiding voor. Daarin staat onder andere dat certificaten opnieuw moeten worden uitgegeven en instellingen uit het oude account handmatig moeten worden overgenomen. Ook moet je rekening houden met DNSSEC, eventuele abonnementen en de DNS-records. Wanneer Cloudflare de nameservers beheert, moeten die bij de domeinregistrar worden aangepast. Tijdens de overgang kan er tijdelijk verschil zitten tussen de oude en nieuwe situatie.
Dat hoeft allemaal geen groot probleem te zijn. Een eenvoudige website met een handvol DNS-records is waarschijnlijk vrij snel overgezet. Maar een website waarvoor jarenlang allerlei beveiligings- en cachingregels zijn gemaakt, is een ander verhaal. Ik vind vooral de positie van de organisatie interessant. Die kan netjes eigenaar zijn van haar domeinnaam en een volledige kopie van haar website hebben, terwijl een belangrijk deel van de technische werking buiten haar bereik ligt.
Formeel hoeft dat overigens geen eigendomskwestie te zijn. De vraag is vooral wie wijzigingen kan doorvoeren, wie toegang kan verlenen en of je de bestaande inrichting kunt meenemen. Stel dat de oude leverancier morgen niet meer bereikbaar is. Dan kun je met toegang tot de domeinregistrar de DNS elders onderbrengen. De website hoeft dus niet definitief vast te zitten aan het oude Cloudflare-account. Maar de configuratie die daar in de loop der jaren is opgebouwd, krijg je op die manier niet terug.
Waarom zou de beheerder het account eigenlijk bezitten?
Voor het dagelijkse werk is dat nergens voor nodig.
Cloudflare heeft een systeem van gebruikersrollen, waarmee een organisatie een externe beheerder toegang kan geven tot haar account. Die beheerder kan vervolgens de benodigde DNS-wijzigingen uitvoeren, beveiligingsregels aanpassen en andere technische werkzaamheden verrichten. De organisatie zelf houdt de hoogste beheerdersrechten. Bij Cloudflare heet die rol Super Administrator. Dat klinkt misschien als onnodig gedoe voor een organisatie die juist het beheer wil uitbesteden. Maar na de eerste inrichting hoeft er nauwelijks iets te veranderen. De beheerder blijft gewoon zijn werk doen.
En als er over vijf jaar een andere partij komt, worden de toegangsrechten aangepast. De instellingen kunnen blijven staan waar ze staan. Ik zou daarbij ook even kijken naar het e-mailadres waarmee het account is geregistreerd en hoe de tweefactorauthenticatie en het accountherstel zijn geregeld. Een account op naam van de organisatie is weinig waard als uitsluitend een voormalige medewerker kan inloggen.
De vijfminutentest
Stel dat je websitebeheerder morgen niet meer bereikbaar is. Niet voor een dagje, maar helemaal niet meer. Kun je dan iemand anders inschakelen die de website draaiend houdt?
Je hoeft daarvoor geen verstand van DNS te hebben. Zoek eens uit wie toegang heeft tot de domeinregistrar, wie de hoogste rechten heeft binnen Cloudflare en of iemand buiten de huidige leverancier weet welke instellingen daar actief zijn. Het aardige is dat je voor deze test helemaal niets hoeft te wijzigen.
Als je de antwoorden niet kunt achterhalen zonder je huidige beheerder te bellen, heb je in ieder geval iets ontdekt.
Voor bestaande situaties waarin Cloudflare in het account van de leverancier staat, hoeft overigens niet direct een verhuizing te worden georganiseerd. Je kunt ook afspreken welke informatie bij beëindiging beschikbaar moet zijn en hoe die overdracht plaatsvindt.
Begin eens met een overzicht van wat er eigenlijk bij Cloudflare is ingesteld. Dat is sowieso nuttig. Ook voor de huidige beheerder, die misschien zelf allang niet meer precies weet waarom die ene beveiligingsregel er nog staat. Wat mij betreft hoort de vraag wie het Cloudflare-account beheert thuis in het eerste gesprek over een nieuwe beheerovereenkomst. Niet in het laatste gesprek met de vertrekkende leverancier.