Det er ikke nogen nyhed, at vores krav til det klassiske CMS skal udvikle sig i takt med et kontinuerligt fragmenteret trusselsbillede. Sikkerhed, performance og særligt oppetid er under pres med stigende aktivitet fra ondsindede aktører på nettet.
Det så vi sidst den 12. september 2023, da en række ministerier og styrelsers hjemmesider var nede på grund af et DDOS-angreb. Fællesnævneren for disse hjemmesider? De var alle baseret på klassiske CMSer.
Dét kunne måske forlede dig til at tro, at det klassiske CMS er ved at have udspillet sin rolle, men det behøver ikke at være sådan. Hos Novicell har vi vist, at det kan være anderledes. Vi har leveret klassiske CMS-løsninger med et meget højt sikkerhedsniveau til flere store offentlige organisationer, hvor vi, trods flere forsøg på DDOS-angreb, er lykkedes med at have oppetider på 100% uden at skulle gribe manuelt ind i hosting-opsætningen.
De stærke setups er hverken resultatet af headless arkitektur eller ændringer i CMS'et, men derimod nøje strukturerede opsætninger af hostingmiljøet.
Kom med her, så tager vi dig trin for trin igennem detaljerne.
Tiltag 1: Cloudbaseret CDN og load-balancer
Vi starter med det vigtigste tiltag overhovedet. Ved at anvende en løsning som Cloudflare Edge eller Azure Frontdoor opnår du flere fordele gennem ét produkt:
- Indbygget beskyttelse mod DDOS-angreb, der er opbygget og vedligeholdt af eksperter på området.
- Indbygget web application firewall, der beskytter mod almindelige og specialiserede hackerangreb mod sitets software.
- Reduktion af trafikken ned til den bagvedliggende CMS-applikation ved at anvende de indbyggede CDN-muligheder til at servere statisk indhold som JavaScript-, css- og billedfiler direkte fra deres eget CDN-netværk.
- Reduktion af trafikken til dynamisk genererede sider fra CMS'et ved at anvende kortlivede kopier af det dynamiske indhold i CDN-netværket.
- Mulighed for at fordele den indkommende trafik videre til flere bagvedliggende applikationer, så du kan have flere applikationsinstanser eller fx lade en separat applikation håndtere alle redirects af gamle og forkerte adresser.
Tiltag 2: CMS-applikationen fordelt på flere instanser
Herefter kan du udnytte CMS'ets muligheder for at blive afviklet fra forskellige instanser til at forbedre performance, sikkerhed og robusthed:
- Sørg for, at den instans af applikationen der anvendes af sitets redaktører, er tilgængelig via en separat url på en separat instans. Det sikrer, at redaktørarbejdet og sitets belastning på internettet ikke påvirker hinanden, fordi det er forskellige applikationsinstanser, der håndterer redaktørerne og internettrafikken.
- Sørg for, at den instans der kører CMS'et ikke er tilgængelig udenfor virksomhedens interne netværk. Det løser du ved hjælp af den indbyggede firewall i CDN-løsningen.
- Sørg for, at der er mere end en instans af den del af applikationen, der håndterer internettrafikken - det kaldes også load-balancing. Hvis der er behov for meget høj sikkerhed, kan du endda fordele disse instanser ud over flere datacentre, så sitet kan køre videre, selvom et helt datacenter går ned. Vi har eksempelvis løst det ved at have en instans, der kører som en såkaldt hot-failover i et separat datacenter på en dynamisk replikeret database.
- Sørg for, at de instanser der håndterer internettrafikken, ikke indeholder CMSets funktionalitet, hvilket er muligt med fx nyere versioner af et CMS som Umbraco, som kan konfigureres til at slukke for CMS'ets funktionalitet på de instanser, der håndterer trafik fra websitets brugere.
Flere mulige tiltag
Når du har de to første ting på plads, som ovenfor beskrevet, er du godt på vej med et generelt robust og sikkert system, der “blot” mangler konfiguration af en række detaljer for at forbedre sikkerheden og graden af robusthed:
- Konfigurer de underliggende applikationer til kun at tillade trafik fra din CDN/load-balancer-løsning. Det sikrer, at eventuelle angribere ikke kan gå uden om load-balanceren og lægge websitet ned alligevel.
- Konfigurer CMS'et til at anvende din virksomheds single sign-on løsning. Det sikrer, at medarbejdere får afbrudt adgangen til CMS'et, når deres brugerkonto lukkes.
- Anvend CDN/load balancer-løsningens muligheder til at sørge for, at sitets respons indeholder alle nødvendige sikkerhedsheadere. Der er en række værktøjer online, der kan hjælpe med at checke, om dine sikkerhedsheads er på plads – eksempelvis securityheaders.com.
- Sørg for at implementere HSTS headers korrekt på hoveddomænet og alle underdomæner, så browsere ikke anvender ukrypterede forbindelser til dit site.
- Konfigurer domæner og SSL certifikater korrekt, så du opnår størst mulig sikkerhed.
- Konfigurer CDN/Load-balanceren til at anvende så sikker en forbindelse som muligt - dvs. TLS 1.3. Her er Cloudflares løsning lidt længere fremme end Azure Frontdoor, der endnu kun understøtter TLS 1.2.
- Anvend et security posture værktøj som Microsoft Defender for Cloud til at sikre, at din cloud konfiguration er på plads. Sådan nogle værktøjer kan endda dokumentere, at din opsætning er i overensstemmelse med sikkerhedsstandarder som ISO27001.
Nåede du igennem alle detaljerne?
Så er det forhåbentligt også tydeligt, at det er ikke CMS'et, der begrænser mulighederne for en robust og sikker løsning.
Når du skal have dit website ud at leve, er det altså langt vigtigere at finde en hosting med de nødvendige værktøjer end at vælge et bestemt CMS eller en bestemt løsningsarkitektur.
Har du allerede et site, der pludselig er blevet mere udsat? Også her er der relativt simple tiltag at gøre.
