Een van de belangrijkste zorgen die klanten hebben als ze horen dat cside als proxy werkt, is "wat gebeurt er als cside uitvalt?" of "voegt het latency toe?"
De realiteit is dat we onze producten hebben ontworpen voor verschillende niveaus van 'slechte dagen'. Bij een wereldwijde uitval is low-tech de juiste aanpak. Door uit de weg te stappen, zorgen we ervoor dat onze uitval niet jouw uitval wordt. In deze blogpost gaan we uitgebreid in op hoe je een runtime-service bouwt voor maximale uptime voor de klant.
TLDR:
- We maken websites doorgaans sneller. Dit hangt af van je scripts en hoeveel er cacheable zijn. Cside kan worden geïmplementeerd zonder toegevoegde latency, afhankelijk van de hybride implementatie. We draaien in veel verschillende regio's — dit aantal verandert voortdurend, maar minimaal 9 verschillende geo-locaties is de norm. Proxying dicht bij een gebruiker vermindert potentiële extra latency direct, terwijl meerdere locaties ons in staat stellen om verkeer van punt naar punt te routeren via snellere routes in plaats van standaard BGP-routes.
- Als cside een incident heeft, zijn er meerdere veiligheidsmaatregelen actief. Incidenten leiden zelden tot impact voor de klant, laat staan tot daadwerkelijke downtime van de runtime-service.
- Als cside uitvalt, stoppen we het script dat je verkeer via ons routeert. Door cside uit de verkeersflow te verwijderen, heeft dit geen impact op de site van de klant. Zie deze architectuur als een virtuele dead-man switch.
Welke oplossingen biedt cside?
Cside biedt 3 benaderingen voor client-side dependency security:
- Direct mode - Eenvoudigst & redelijk veilig
Gebruiksscenario: Ik geef om client-side security, ik heb iets nodig dat makkelijk uit te leggen is aan de rest van het team en ik ben bereid wat compromissen te sluiten om organisatorische verwarring te voorkomen.
Werkwijze: scripts van third-party bronnen die ik vertrouw worden direct geserveerd, scripts die ik niet vertrouw krijgen de volledige beveiligingsbehandeling. First-party scripts worden client-side gecontroleerd en door cside opgehaald.
Voordelen: Eenvoudigst te implementeren — voeg gewoon een script toe. (Vrijwel) Geen performance-impact — het wrappen van JS in de browser kan een verwaarloosbare hoeveelheid extra latency toevoegen (enkele milliseconden). Mogelijkheid om scriptacties te stoppen of te blokkeren op basis van script-URL, hash of domein.
Nadelen: Niet altijd gegarandeerd dat dezelfde script-payload wordt gecontroleerd als die de gebruiker ontving — maar het scheelt weinig. Geen performance-winst op statische of optimaliseerbare scripts. Acties in de browser zijn in principe zichtbaar, ook bij zware obfuscatie.
Implementatie: Voeg ons script toe aan je website.
Je kunt cside nog steeds plaatsen tussen niet-vertrouwde scripts en de eindgebruiker.
- Gatekeeper-modus - Veiligst
Gebruiksscenario: Ik ben een hoogwaardig doelwit en heb volledige beveiligingscontrole nodig.
Werkwijze: alle third-party scripts passeren cside, behalve de scripts die ik zelf heb geselecteerd; first-party scripts worden client-side gecontroleerd en door cside opgehaald.
Voordelen: Volledige zichtbaarheid. Volledige controle. Performance-verbetering op sommige scripts. We weten dat wat de gebruiker ontving ook daadwerkelijk is gecontroleerd. We hoeven niet om te gaan met browserbeperkingen — we hebben controle over de scriptlevering en volledige forensische zichtbaarheid.
Nadelen: Het woord "proxy" roept zorgen op bij mensen, maar we leggen hieronder uit waarom dat in dit geval niet nodig is. Bij sterk dynamische scripts kan latency worden toegevoegd. Statische scripts worden doorgaans sneller geleverd.
Implementatie: Voeg ons script toe aan je site. Markeer scripts die je vertrouwt en waarvoor cside niet hoeft te serveren. Standaard gaten we sommige scripts niet die incompatibel zijn met servering via een andere URL. Werkwijze: alle scripts passeren cside, behalve sommige.
- Scan-modus - Snelst
Gebruiksscenario: Ik heb niet de mogelijkheid om een script aan de website toe te voegen.
Werkwijze: Ik moet een vinger aan de pols houden, ik kan niets toevoegen aan de site, dus observability is een goed startpunt.
Voordelen: Goedkoop. Snel en eenvoudig in te stellen. Cside threat intel verzameld door duizenden andere websites met gezamenlijk miljarden bezoekers.
Nadelen: Client-side aanvallen zijn dynamisch; een statische scan zal een aanval per definitie minder snel opsporen. Een zeer gerichte aanval zou detectie kunnen ontwijken.
Waarom we deze aanpak hanteren
Het cside-team is al een tijdje actief in client-side security, bij verschillende leveranciers.
We begrijpen de beperkingen en dragen actief bij aan standaardenorganisaties zoals het W3C om client-side security technisch haalbaar te maken.
Client-side detecties zijn per specificatie eenvoudig te reverse-engineeren en te omzeilen. Browsers geven beveiligingsleveranciers, anders dan de meeste besturingssystemen, geen extra controle of prioriteit. Wat een script voor client-side security in essentie doet, is API's wrappen die door kwaadwillenden kunnen worden gebruikt en monitoren welke scripts deze gebruiken. Helaas kunnen te strikte client-side detecties sommige client-side libraries breken. Het probleem is dat niet elk script goed samenwerkt met gewrapte API's.
Door detecties in de browser te combineren met detecties in onze eigen engine creëren we een gebalanceerd best-of-all-worlds scenario. We balanceren detectievermogen met gebruiksgemak en veerkracht, en geven de klant uiteindelijk de mogelijkheid om zelf de aanpak te kiezen.
Waarom cside verschilt van traditionele 'proxy'-diensten
Als de meeste mensen aan een proxy denken, denken ze meteen aan Cloudflare, Akamai, Fastly, enzovoort. Hoewel die uitstekend zijn voor algemene CDN- en DDoS-bescherming, vertegenwoordigt cside.com een fundamenteel andere aanpak.
In plaats van HTTP-verkeer te proxyen zoals traditionele proxy's en firewalls, bewaken we de browsergebaseerde componenten en JavaScripts die de eindgebruiker in zijn browser laadt vanaf het publieke internet tijdens een bezoek aan je website of webapplicatie. Dit biedt volledige scriptzichtbaarheid: we zien wat de eindgebruiker ziet en blokkeren kwaadaardige pogingen om PII, creditcardgegevens of cryptowallet-ID's te skimmen of te oogsten. Traditionele proxy's werken doorgaans op een alles-of-niets-principe. Dit creëert een single point of failure en beperkte operationele flexibiliteit. De hybride aanpak van cside verandert het spel volledig door selectieve proxying mogelijk te maken en script-voor-script controle te bieden, in volledige proxy- of capture-only-modus. Bovendien werken we met een fail-open ontwerp, zodat we nooit invloed hebben op je website, betaalpagina's of checkouts bij een incident.
Het type incident is bepalend
Er zijn verschillende mogelijke oorzaken van verstoring:
- Codewijzigingen
- Onverwachte grote belasting
- Uitval bij upstream-providers
Voor elk geval hebben we een runbook.
Voor elk geval hebben we preventieve maatregelen.
Voor elk geval hebben we redundantie.
We nemen geen enkel risico.
Uitval door codewijzigingen voorkomen
Zoals de meeste enterprise-grade bedrijven hebben we een rigoureus testproces en testen we onze code grondig voordat deze naar productie gaat.
Bovendien hebben we "development"- en "staging"-omgevingen waar we onze wijzigingen uitgebreid testen voordat ze überhaupt productie bereiken. Onze stagingomgeving is een volledige spiegel van productie, inclusief de gatekeeping-engine, zodat elke update wordt getest in dezelfde opzet waarop onze gebruikers vertrouwen. Zo zorgen we ervoor dat de proxy na elke wijziging volledig functioneel is.
Onze engine draait in een volledig gedistribueerde opzet over meerdere regio's, zodat gebruikers de dichtstbijzijnde instantie bereiken. Wanneer we klaar zijn voor productie, voeren we gefaseerde uitrollingen uit over onze regio's. De nieuwe code wordt eerst in één regio uitgerold en vervolgens stapsgewijs uitgebreid naar de andere. In het onwaarschijnlijke geval dat een slechte codewijziging dit punt bereikt, wordt deze vroegtijdig gedetecteerd en ingeperkt in die eerste regio, voordat de uitrol wereldwijd doorgaat.
Er gaat iets mis — wat nu? Redundantie via protocol.
Cside is van nature een hybride proxy. Dat betekent dat we kunnen worden geïmplementeerd om sommige, alle of de meeste scripts te proxyen, met uitzondering van scripts die we expliciet niet proxyen. En dat is volledig configureerbaar door onze klanten.
Standaard proxyen we geen first-party scripts en specifieke scripts die proxying per ontwerp verhinderen. Dat betekent niet dat we ze negeren. We behandelen ze gewoon iets anders. Ze stromen nog steeds door onze pipeline zodat ze worden geanalyseerd, we halen hun inhoud nog steeds op ook al serveert de proxy ze niet, en we kunnen onze klanten nog steeds informeren als er iets verdachts is.
En voor gevallen waarbij een script echt gevoelig is en klanten het helemaal niet via de proxy willen laten lopen, kan het volledig worden uitgesloten.
Deze flexibiliteit is voor ons zeer waardevol, omdat het ons opties geeft om ons gedrag op de site van de klant snel aan te passen. Wanneer er een incident optreedt of we snel moeten debuggen, hebben we opties om de impact direct te beperken.
Bijvoorbeeld: als de proxy ooit downtime zou hebben, kunnen we onmiddellijk stoppen met het serveren van de scripts via een van de hierboven genoemde mechanismen, om te voorkomen dat pagina's stukgaan. Sommige van deze bedieningselementen zijn ook beschikbaar in het dashboard zodat klanten het zelf kunnen configureren.
Doorgaans, wanneer er iets begint mis te gaan, zullen een of meer van onze interne niet-publieke services indicatoren van een probleem tonen voordat het kritiek wordt. Op dat moment treedt onze incidentalarmering in werking. Het cside-team draait een 24/7 wereldwijde on-call rotatie, met escalaties naar vakinhoudelijke experts. We zijn van plan binnenkort een blogpost te publiceren over onze incidentbeheerprocessen — blijf op de hoogte!
Daarnaast hebben we back-up secundaire services klaarstaan in onze back-end voor elke service, zodat ze hoog beschikbaar blijven en zelfs rampscenario's worden gedekt. Zo staat er bij de proxy, als de primaire proxy de belasting niet aankan door een onverwachte verkeerspiek, een secundaire service klaar om het over te nemen.
In de nabije toekomst is cside van plan anycast IP's te gebruiken om automatisch via protocol load te balanceren naar een alternatieve locatie. Dit is meer dan een redundantiefactor — het is ook een ontwerpbeslissing die de performance verhoogt.
Cside is down — wat gebeurt er dan?
Goed nieuws: dit is nog nooit gebeurd. Als het ooit zou gebeuren, zou dat betekenen dat een hele reeks veiligheidsmaatregelen heeft gefaald. Toch zijn we voorbereid.
Zo werkt het. Als onze proxy uitvalt, routeert ons client-side script geen verkeer meer naar cside. Met andere woorden: je site gaat gewoon door zonder ons. Klinkt low-tech, toch? Dat is bewust zo. Bij een wereldwijde uitval is low-tech de juiste aanpak. Door uit de weg te stappen, zorgen we ervoor dat onze uitval niet jouw uitval wordt.
Het enige verkeer waar we ons op dat moment zorgen over hoeven te maken, zijn server-side geprefixte scripts. Die zijn ook gedekt. We verwerken deze met een fallback-proxy die de scripts omleidt naar hun oorspronkelijke bron. Dit is veel minder rekenintensief en deze infrastructuur draait op een oneindig schaalbare third-party service.
Het resultaat: geen impact op de uptime van de klant. De enige afweging is dat we tijdens dit incident geen zichtbaarheid hebben via onze proxyservice.
Dat gezegd hebbende, is een plotselinge wereldwijde uitval vrij zeldzaam en uiterst onwaarschijnlijk.
Doorgaans zien we ruim van tevoren waarschuwingssignalen, zodat we genoeg tijd hebben om te reageren.
Klanten zijn altijd bereikbaar!
We zijn cside begonnen omdat we wisten dat alle andere methoden op de markt een vals gevoel van veiligheid gaven en niet de zichtbaarheid hadden die nodig is om hun klanten te beschermen. Het bouwen en onderhouden van een snelle gedistribueerde proxy is geen kleine opgave. We kenden de risico's en hebben ons aangemeld om ze aan te pakken. Het is ook belangrijk te vermelden dat client-side third-party scripts vandaag de dag doorgaans onbewaakt zijn, ook wat betreft uptime SLA's. We vinden elk uur verouderde URL's op websites. Dit is heel gebruikelijk. We geven je zichtbaarheid en zekerheid die je daarvoor niet had. Uptime is belangrijk en je hebt vandaag geen uptime-zichtbaarheid op client-side third-party dependencies — maar als je cside gebruikt, verandert dat.
We zorgen er bewust voor dat er geen single point of failure is en maken gebruik van eenvoudige low-tech veiligheidsmaatregelen. De low-tech failsafe-methode is bij een incident vaak de meest betrouwbare.
