Hvordan bruke Cloudflare "Under Attack"-modus på en nettside som er under DDoS-angrep?

Når en nettside er under DDoS-angrep, er Cloudflare Under Attack-modus en nødinnstilling som viser besøkende en kort sikkerhetsbekreftelse for å filtrere bort bot-trafikk. Ved å velge nettstedet ditt i Cloudflare-panelet og aktivere Under Attack Mode fra sikkerhetsdelen, kan du redusere HTTP/HTTPS forespørslene i løpet av få minutter, beskytte reelle brukeres tilgang til nettstedet, og redusere belastningen på serveren din. Det er imidlertid viktig å merke seg at denne modusen ikke er en permanent løsning; den bør brukes sammen med riktig DNS-proxyinnstilling, WAF-regler, hastighetsbegrensning, cache-konfigurasjon og sikkerhet på origin-serveren.

I denne guiden vil vi trinnvis gå gjennom hvordan man aktiverer Cloudflare Under Attack-modus, når det bør brukes, hvilke innstillinger som bør støttes, og hvordan man trygt kan gå tilbake til normal drift etter at angrepet er over. Målet er å gi en praktisk sjekkliste for handling i panikksituasjoner og gjenopprette tilgjengeligheten til nettstedet ditt så raskt som mulig.

Hva er Cloudflare Under Attack-modus?

Cloudflare Under Attack-modus er et nød-sikkerhetsnivå som tilbys av Cloudflare. Når den er aktivert, vil Cloudflare sende besøkende til nettstedet gjennom en kort bekreftelse i nettleseren. Denne bekreftelsen varer vanligvis bare noen sekunder og gjør det vanskeligere for automatiserte botter, enkle HTTP-flomverktøy eller ondsinnede klienter å påføre nettstedet direkte belastning.

Hovedformålet med denne modusen er å dempe angrep på applikasjonslaget, det vil si på lag 7. For eksempel, hvis nettstedet mottar tusenvis av GET-forespørslene per sekund til forsiden, eller det er mange POST-forsøk på WordPress-påloggingssiden, eller hvis søkesiden får dyre forespørsel eller handlekurven mottar falsk trafikk, gir Under Attack-modus en rask første respons.

Den viktige distinksjonen her er: Under Attack-modus filtrerer webforespørslene; men hvis serverens IP-adresse er direkte målrettet, eller hvis tjenestene dine utenfor Cloudflare-proxyen er eksponert, eller hvis angrepet skjer på lag 3/4, vil det være behov for ekstra tiltak. Derfor er det kritisk at DNS-postene er proxied via Cloudflare, at origin IP-adressen er skjult, og at riktige sikkerhetstiltak er implementert på hosting-siden. For sikker infrastrukturvalg kan det henvises til Tjenester for sikker webhosting og installasjon av SSL-sertifikat.

Symptomer på DDoS-angrep: Hva bør sjekkes før man går over til Under Attack-modus?

Ikke all treghet er DDoS. Noen ganger kan det skyldes en feilaktig plugin, låsing av databasen, en cron-jobb som bruker høy CPU, eller feil cache-innstilling som gir lignende resultater. Derfor kan det være lurt å gjøre en rask diagnose før du aktiverer Under Attack-modus. Likevel, hvis serveren har problemer med å svare, brukerne får 502, 503, 504-feil, og loggene viser en unormal økning i forespørslene, bør nødmodus aktiveres uten forsinkelse.

Typiske indikatorer på DDoS

• En plutselig økning i trafikk som er 5, 10 eller 50 ganger mer enn normalt på kort tid.
• Hundrevis av forespørsel per sekund til en enkelt side eller endpoint.
• Trafikk fra forskjellige land, men med lignende user-agent-verdier.
• Målretting av dyre URL-er som admin, login, search, cart i WordPress, WooCommerce, OpenCart eller spesialprogrammer.
• Serverens CPU, RAM, PHP-FPM worker eller MySQL-tilkoblingsgrenser fylles raskt opp.
• En plutselig økning i 4xx og 5xx-feil på Cloudflare Analytics-skjermen.
• Reelle brukere kan få tilgang til nettstedet sporadisk, men bot-trafikken sender kontinuerlige forespørsel.

For eksempel, hvis en e-handelsnettsted normalt får 2.000 forespørsel per minutt, og det øker til 80.000 forespørsel per minutt i løpet av 10 minutter, og 70 % av forespørslene går til handlekurven eller søkesiden, er dette et klart tegn på et angrep på lag 7. I dette scenariet bør Under Attack-modus aktiveres i løpet av de første 5 minuttene, og deretter bør spesifikke WAF- og hastighetsbegrensningsregler legges til for mål-URL-ene.

Når bør Cloudflare Under Attack-modus brukes?

Cloudflare Under Attack-modus er ikke en standard sikkerhetsinnstilling som bør være kontinuerlig aktivert. Dette skyldes at det også viser en kort venteskjerm til ekte besøkende. Dette kan påvirke brukeropplevelsen, spesielt på konverteringsfokuserte sider, betalingsprosesser eller API-brukende systemer. Den beste bruken er å aktivere det midlertidig under angrep og justere sikkerhetsnivået når trafikken er tilbake til normalen.

Situasjoner der det er passende å bruke det

• Når nettstedet mottar høy og unormal HTTP/HTTPS-trafikk.
• Når serverressursene raskt er i ferd med å gå tom og 502/503-feilene øker.
• Når Cloudflare WAF ikke er konfigurert med spesifikke regler ennå, og det er behov for en rask beskyttelse.
• Når bot-trafikken er betydelig høyere enn ekte brukertrafikk.
• Når de angrepne websider, skjemaer, påloggingsskjermer eller søke-endepunkter.

Situasjoner der det må brukes med forsiktighet

• Når mobilapplikasjoner, betalingsleverandører, webhooker eller API-trafikk er intensivt brukt.
• Når du er i en periode der søkemotor-boter skanner kritisk.
• Når bedriftsbrukerne dine kobler til via gamle nettlesere eller begrensede nettverksmiljøer.
• Når det finnes subdomener som ikke er bak Cloudflare-proxyen på nettstedet ditt.

Hvis Under Attack-modus brukes for nettsteder med API-trafikk, kan det føre til at visse integrasjoner feiler. Derfor bør det, dersom mulig, planlegges spesifikke WAF-regler, tillatelser eller forskjellige sikkerhetsnivåer for API-subdomener. For en detaljert guide om API-sikkerhet kan Veiledning for API-sikkerhet og hastighetsbegrensning anbefales.

Slik aktiveres Cloudflare Under Attack-modus? Trinn-for-trinn-applikasjon

Følgende trinn utgjør en praktisk sjekkliste for å handle raskt under et angrep. Cloudflare-grensesnittet kan vise små endringer over tid; men logikken er den samme: velg domenet ditt, heve sikkerhetsnivået og bekrefte innkommende trafikk gjennom Cloudflare.

1. Logg inn på Cloudflare-kontoen din

Først må du logge inn på Cloudflare-kontoen din og velge domenet som er under angrep. Hvis du administrerer flere domener, må du sørge for at du jobber med riktig zone. Å aktivere Under Attack-modus på feil domene vil føre til unødvendig tidsbruk og la det faktiske angrepet fortsette.

2. Kontroller at DNS-postene er proxied

For at Under Attack-modus skal være effektiv, må webtrafikken gå gjennom Cloudflare. Sørg for at A, AAAA og CNAME-postene i DNS-delen er i oransje sky, det vil si proxied. DNS-only-poster i grå sky går ikke gjennom Cloudflare sikkerhetslaget. Spesielt www, rot-domenet og de brukte subdomenene bør kontrolleres.

Hvis origin IP-adressen din er synlig på internett, kan angripere omgå Cloudflare og angripe serveren direkte. Derfor er det en sterk ekstra beskyttelse å tillate kun HTTP/HTTPS-trafikk fra Cloudflare IP-områder i serverens brannmur. Du kan få støtte fra hosting-leverandøren din i dette, eller henvises til Hvordan sette opp Cloudflare DNS-innstillinger guiden.

3. Aktiver Under Attack-modus fra sikkerhetsdelen

Etter å ha åpnet det relevante domenet i Cloudflare-panelet, finner du alternativet Under Attack Mode i Security eller Overview-skjermen. Når du aktiverer dette alternativet, begynner Cloudflare å vise en kort bekreftelsesside til besøkende som kommer til nettstedet. I noen paneler kan denne innstillingen også vises under Security Level som "I am Under Attack".

Endringene trer vanligvis i kraft raskt etter aktivering. I de første minuttene bør Cloudflare Analytics, Security Events og serverressursforbruk overvåkes sammen. Hvis CPU- og tilkoblingstallene begynner å falle, betyr det at modusen fungerer. Men hvis feilsatsen fortsatt er høy, må det skrives flere regler.

4. Test den faktiske brukeropplevelsen

Etter å ha aktivert modusen, bør du teste nettstedet fra forskjellige nettverk. Mobilnett, kontornettverk og, om mulig, fra en annen lokasjon, bør forsiden, produktsiden, påloggingssiden og betalingsstrømmen testes. Hvis nettstedet er tilgjengelig etter bekreftelsesskjermen, er dette forventet oppførsel. Hvis brukerne havner i en uendelig bekreftelsessløyfe, bør innstillinger som cookie-blokkerende, nettleserkompatibilitet eller konflikter med Cloudflare-sikkerhetsregler undersøkes.

5. Identifiser URL-er som angrepet er rettet mot

Under Attack-modus gir generell beskyttelse; men den virkelige effekten oppnås med målrettede regler. Bruk Cloudflare Security Events, Web Analytics, hosting-tilgangslogger og applikasjonslogger for å finne de mest forespurte banene. For eksempel kan URL-er som /wp-login.php, /xmlrpc.php, /search, /cart, /api/login eller /checkout være under angrep.

Når mål-URL-en er identifisert, kan det tas tiltak basert på kriterier som land, user-agent, forespørselmetode, URI-sti eller bot-score med WAF Custom Rules. For eksempel kan IP-er som sender mer enn et rimelig antall forespørsel per minutt til et spesifikt påloggings-endepunkt, pålegges managed challenge. For WordPress-nettsider er WordPress Sikkerhetstiltak en naturlig intern lenkemulighet.

Forskjeller mellom Under Attack-modus og andre Cloudflare sikkerhetsalternativer

Cloudflare sikkerhetsverktøyene tjener ulike formål. Under Attack-modus er et raskt og generelt nødfilter; WAF og hastighetsbegrensning tilbyr mer målrettede, bærekraftige og mer balanserte løsninger med hensyn til brukeropplevelsen.

I praksis fremmer en god forsvarsstrategi følgende rekkefølge: Først reduseres det akutte presset med Under Attack-modus, deretter analyseres angrepsmønsteret, WAF og hastighetsbegrensningsregler legges til, og til slutt styrkes den permanente infrastrukturen med cache- og origin-brannmurinnstillinger.

Anbefalte ekstra Cloudflare-innstillinger under angrep

Selv om Under Attack-modus kan aktiveres med et enkelt klikk, avhenger suksessen til DDoS-forsvaret av støttende innstillinger. Følgende anbefalinger er blant de mest effektive tiltakene i virkelige operasjoner.

Lag målrettet beskyttelse med WAF-regler

Cloudflare WAF lar deg ta tiltak basert på spesifikke betingelser. For eksempel kan du pålegge en challenge til POST-forespørsel som kommer til /wp-login.php fra bestemte land. På denne måten kan du isolere angrepets mål uten å overbelaste hele nettstedet.

• Åpne admin- og påloggingssider kun for bestemte land eller IP-områder.
• Blokker ubrukte endepunkter som XML-RPC.
• Bruk managed challenge for mistenkelige user-agent-verdier.
• Begrens klienter som sender for mange forespørsel på spesifikke URI-stier med hastighetsbegrensning.

Sett cache-nivået riktig

Under DDoS-angrep må origin-serveren svare på hver forespørsel, noe som raskt kan føre til at ressursene går tomme. Statiske filer, bilder, CSS, JavaScript og cachebare sider bør serveres via Cloudflare edge. I dynamiske systemer som WordPress kan en side-cache-plugin, Cloudflare-cache-regler og passende cache-control-header brukes sammen.

For eksempel kan sider som vises til anonyme besøkende på en nyhets- eller bloggorientert nettside caches i 5 til 30 minutter. Denne enkle innstillingen reduserer TTFB-verdiene selv i angrepsfrie perioder, og avlaster hosting-ressursene. For ytelse kan webside akselereringsguide vurderes.

Sett hastighetsbegrensningstersklene realistisk

Hastighetsbegrensning er spesielt effektivt på kostbare endepunkter. Men hvis tersklene settes tilfeldig, kan ekte brukere bli blokkert. For eksempel kan en normal bruker i en produkt søkeside gjøre 5-15 søk per minutt; 100 søk per minutt er unormalt. På påloggingssiden er 10 mislykkede forsøk innen 5 minutter mistenkelig i de fleste scenarier.

Et eksempel på tilnærming: for /wp-login.php kan IP-er som sender mer enn 10 forespørsel per minutt pålegges managed challenge, mens de som sender mer enn 50 forespørsel på 5 minutter kan pålegges midlertidig blokkering. For API-endepunkter bør mer presise grenser basert på brukerøkt, IP, token og metode foretrekkes.

Skjul origin IP-adressen og begrens med brannmur

En av de mest kritiske feilene når man bruker Cloudflare, er å la origin IP-adressen være synlig. Gamle DNS-poster, subdomener som fungerer direkte med IP, webtjenester som blandes med e-postposter, eller lekkede konfigurasjoner kan tillate angripere å nå serveren utenom Cloudflare.

På serveren bør portene 80 og 443 kun åpnes for Cloudflare IP-områder for sterk beskyttelse. I tillegg bør SSH, panel, database og administrasjonsporter ikke være åpne for internett; IP-begrensning, sterkt passord, 2FA og, om mulig, VPN bør brukes. For hosting-sikkerhet kan det henvises til cPanel sikkerhetsinnstillinger og VPS brannmurkonfigurasjon.

Spesielle hensyn for WordPress, WooCommerce og bedriftsnettsteder

Ikke alle nettsteder har samme trafikkstruktur. En blogg, en WooCommerce-butikk og et SaaS-panel kan gi ulike resultater med Cloudflare Under Attack-modus. Derfor bør kritiske baner bestemmes basert på nettstedstype.

WordPress-nettsteder

De mest målrettede filene i WordPress er vanligvis /wp-login.php og /xmlrpc.php. Hvis du ikke bruker XML-RPC, er det vanligvis trygt å blokkere den. Det kan også implementeres land- eller IP-begrensninger for admin-panelet. I tillegg bør sikkerhetsplugins ikke komme i konflikt med Cloudflare-reglene; for mange challenge-mekanismer samtidig kan sette brukeren i en bekreftelsessløyfe.

WooCommerce-butikker

Handlekurv, betalings- og kontosider i WooCommerce krever spesiell oppmerksomhet. Fordi disse sidene er dynamiske, bør det ikke brukes aggressiv caching. Når Under Attack-modus er aktivert, må du sørge for at betalingsleverandørens callback- eller webhook-URL-er fungerer. Hvis nødvendig, bør betalingsleverandørens IP-områder legges til i tillatelseslisten, eller en spesifikk regel bør skrives for det aktuelle endepunktet.

Bedrifts- og API-brukende nettsteder

Bedriftsportaler, CRM-integrasjoner og mobilapp-API-er kan ha problemer med å håndtere JavaScript challenge-skjermen. For slike systemer kan det være mer hensiktsmessig å administrere API-subdomenet separat i stedet for å bruke Under Attack-modus på hele domenet. For eksempel kan Under Attack aktiveres for www.example.com, mens token-baserte sikkerhet, hastighetsbegrensning og tillatelseslister kan brukes for api.example.com.

Metrikker å følge etter at Under Attack-modus er aktivert

For å forstå om et sikkerhetstiltak fungerer, er numerisk overvåking nødvendig. Det er ikke nok at nettstedet åpnes; feilrater, serverbelastning og reell brukeradferd må vurderes sammen.

• Cloudflare Security Events: Viser hvor mange forespørsel som har blitt utfordret eller blokkert av hvilke regler.
• HTTP-statuskoder: Endringer i 403, 429, 502, 503 og 504-feil bør overvåkes.
• Serverens CPU- og RAM-bruk: En nedgang forventes etter Under Attack.
• PHP-FPM og MySQL-tilkoblinger: Viser lettelsen på applikasjonslaget.
• Båndbredde og forespørselstall: Trafikkvolumet bør sammenlignes med andelen forespørsel som er filtrert.
• Reelle bruker-konverteringer: Testing av skjemaer, bestillinger, pålogging og betalingsprosesser bør utføres.

For eksempel, hvis antall forespørsel forblir det samme etter at Under Attack-modus er aktivert, men forespørslene som når origin reduseres med 60 %, indikerer det at Cloudflare-laget absorberer en betydelig belastning. Hvis samtidig MySQL CPU-bruken fortsatt er høy, kan angrepet utløse en spesifikk dynamisk forespørsel; i så fall bør applikasjonsloggene undersøkes.

Hvordan avslutte Under Attack-modus etter at angrepet er over?

Det anbefales ikke å la Under Attack-modus stå åpen permanent når angrepstrafikken har normalisert seg, da dette kan påvirke konverteringsratene, effektiviteten til søkemotorinnhenting og brukeropplevelsen. Avslutningsprosessen bør også være kontrollert.

Trygge trinn for å gå tilbake til normal drift

• Vent i minst 30-60 minutter før du bekrefter at trafikknivåene har normalisert seg.
• Bekreft at antallet challenges og blokkeringer er redusert på Cloudflare Security Events-skjermen.
• Før du avslutter Under Attack-modus, må du forsikre deg om at målrettede WAF- og hastighetsbegrensningsregler er aktive.
• Justere sikkerhetsnivået til et mer balansert nivå, som Høy eller Medium.
• Test nettstedet fra ulike enheter og overvåk 5xx-feilratene.
• Følg loggene i 24 timer for å se om angrepet gjenopptas.

Som en god praksis bør det opprettes en hendelsesrapport etter angrepet. Rapporten bør inneholde tidspunktet for angrepets start, mål-URL-er, det høyeste antallet forespørsel, tiltakene som ble iverksatt, effektive regler og permanente forbedringer. Dette dokumentet vil betydelig redusere responstiden ved neste hendelse.

Vanlige feil og hva du bør unngå

Det er viktig å ta raske beslutninger under DDoS-angrep; men feil innstillinger kan blokkere ekte brukere. Følgende feil oppstår ofte under høy stress.

• Å tro at Under Attack-modus vil gi beskyttelse uten å proxie DNS-postene.
• Å la origin IP-adressen være synlig og ikke stenge tilgangen utenom Cloudflare i brannmuren.
• Å anvende en challenge på hele domenet uten å teste API, webhook og betalingscallback-adresser.
• Å skrive for brede WAF-blokkeringsregler som kan blokkere ekte kunder.
• Å bruke aggressiv caching på sider som ikke bør caches, som handlekurv, betalings eller brukerpanel-sider.
• Å la modusen stå åpen i flere uker etter at angrepet er over.
• Å ta avgjørelser basert kun på Cloudflare-skjermen uten å sjekke serverloggene.

Spesielt for e-handelsnettsteder kan blokkering av betalingscallback føre til betydelige inntektstap. Derfor, når du skriver sikkerhetsregler, er det sikrere å teste med logging eller managed challenge før blokkering. Når effekten av regelen er bekreftet, kan det gås til mer strenge tiltak.

Hvordan planlegge en mer robust forsvar i Hostragons-infrastrukturen?

Cloudflare gir et sterkt første lag; men vellykket DDoS-forsvar stopper ikke bare ved CDN. Hostinginfrastrukturen, programvareoptimaliseringen, SSL-konfigurasjonen, DNS-administrasjonen og sikkerhetskopieringsstrategien bør vurderes sammen. For et nettsted hostet på Hostragons bør den grunnleggende tilnærmingen være: Cloudflare filtrerer trafikken, hostinglaget håndterer kun ren trafikk, og applikasjonen bør optimeres slik at den ikke genererer unødvendig belastning på databasen.

Før et nytt prosjekt lanseres, er det viktig å administrere domenet med riktige DNS-poster, sikre at SSL-sertifikatet installeres uten problemer, og at ressursene på webserveren er tilpasset trafikprofilen din. På dette punktet kan Domenesjekk og domeneregistrering, Web hosting pakker, løsninger for bedrift hosting, og Gratis SSL-sertifikat være nyttige for brukeren.

For prosjekter med høy trafikk eller høy risiko for angrep, bør kontrollerte VPS- eller administrerbare serveralternativer vurderes i stedet for standard delt hosting. På denne måten kan brannmur, webserver, PHP-FPM, Redis, objektcache og databaseinnstillinger konfigureres mer fleksibelt. Uansett hvilken infrastruktur som velges, bør Cloudflare Under Attack-modus kun plasseres som et nødverktøy; den permanente sikkerhetsarkitekturen bør støttes med WAF, logganalyse og regelmessige oppdateringer.

Rask sjekkliste: De første 15 minuttene under DDoS-angrep

Tid er kritisk under angrep. Følgende liste oppsummerer hva det tekniske teamet eller nettstedseieren kan gjøre i løpet av de første 15 minuttene.

• Logg inn på Cloudflare-panelet og velg det riktige domenet.
• Sjekk at DNS-postene er i oransje sky, det vil si proxied.
• Aktiver Under Attack-modus.
• Test forsiden, pålogging, handlekurv, betaling og API-endepunkter.
• Identifiser mål-URL-er fra Cloudflare Security Events-skjermen.
• Legg til spesifikke WAF- eller hastighetsbegrensningsregler for de mest angrepne banene.
• Kontroller serverens CPU, RAM, PHP-FPM, og MySQL-status.
• Sjekk om det er direkte tilgang til origin IP.
• Undersøk om det er behov for tillatelser for betalingsleverandører, webhooker og kritiske integrasjoner.
• Noter alle tiltak med tidsstempel.

Dersom denne listen blir gjennomgått regelmessig, vil panikken reduseres under en ekte angrep, og kvaliteten på responsen forbedres. For større nettsteder anbefales det å dokumentere denne prosessen som en hendelseshåndteringsplan.

Ofte stilte spørsmål

Beskytter Cloudflare Under Attack-modus nettstedet helt?

Nei. Cloudflare Under Attack-modus er spesielt effektiv for å redusere bot- og flomtrafikk på HTTP/HTTPS-nivå; men det gir ikke fullstendig beskyttelse alene. DNS-postene må være proxied, origin IP må være skjult, og WAF-regler, hastighetsbegrensning, cache og serverbrannmurinnstillinger må brukes sammen.

Vil Under Attack-modus skade SEO?

Kortvarig bruk forårsaker vanligvis ikke alvorlig skade på SEO. Men hvis modusen er åpen for lenge, kan det påvirke effektiviteten av søkemotorinnhenting og brukeropplevelsen. Derfor er det mer sunt å deaktivere modusen etter angrepet og fortsette med målrettede sikkerhetsregler.

Hvor lenge bør Cloudflare Under Attack-modus være aktivert?

Den kan være aktivert så lenge angrepsintensiteten er høy; i praksis anbefales det å overvåke i minst 30-60 minutter etter at trafikken har normalisert seg, og deretter stenge den gradvis. Før modusen stenges, bør WAF og hastighetsbegrensningsregler være på plass.

Påvirker Under Attack-modus API eller betaling systemene?

Ja, det kan påvirke. Fordi noen API-klienter, webhook-tjenester og betalingscallback-systemer kan ha problemer med å fullføre nettleserbasert sikkerhetsbekreftelse. Derfor bør kritiske endepunkter testes, og om nødvendig, spesifikke Cloudflare-regler eller tillatelser bør defineres.

Er det nødvendig med ekstra tiltak på hosting-siden når man bruker Cloudflare?

Ja. Cloudflare gir sterk beskyttelse på første lag; men origin-serverens IP må skjules, brannmuren bør bare tillate nødvendig trafikk, programvaren må holdes oppdatert, og cache-konfigurasjonen må gjøres riktig. Sikker hosting-infrastruktur er en viktig del av DDoS-motstand.

Konklusjon

Cloudflare Under Attack-modus er et effektivt nødverktøy for å gi rask lindring til en nettside under DDoS-angrep. Når den aktiveres med riktig DNS-proxyinnstilling, reduserer den bot-trafikken, reduserer serverbelastningen, og øker sjansen for at reelle brukere får tilgang til nettstedet. For best resultat bør denne modusen støttes av WAF-regler, hastighetsbegrensning, cacheoptimalisering og sikkerhet på origin-brannmuren.

Hvis du ønsker at nettstedet ditt skal fungere mer motstandsdyktig mot angrep, bør du regelmessig gjennomgå infrastrukturen, DNS-administrasjonen og SSL-konfigurasjonen. Ved å undersøke Hostragons’ hosting-, domene- og SSL-løsninger kan du skape et tryggere og mer bærekraftig grunnlag for nettstedet ditt.