Hoppa till innehåll 
Hostingkunder måste konsekvent implementera tekniska säkerhetsåtgärder för lösenord för att skydda hostingåtkomst från attacker som brute force-attacker och credential stuffing. Den här artikeln visar hur man implementerar, verkställer och övervakar cravity-proof-policyer på serversidan - inklusive bästa praxis för praktisk tillämpning. Särskilt i samband med värdservrar kan svaga lösenord vara en inkörsport för angripare att kompromissa med hela webbplatser eller stjäla känsliga data. Jag har ofta sett hur enkla lösenord har knäckts på kort tid eftersom viktiga riktlinjer inte har följts eller implementerats. Den ansträngning som krävs för att få till stånd bra riktlinjer för lösenord och bästa praxis i vardagen är hanterbar när de väl har definierats tydligt och integrerats tekniskt.
Centrala punkter
- Lösenordspolicy Definiera och genomdriv direkt i administratörsgränssnittet
- Multi-faktor autentisering Aktivt skydd för kritiska åtkomstpunkter
- Hashing av lösenord skyddar lagrad data med bcrypt eller Argon2
- Automatiserade kontroller mot komprometterad åtkomstdata
- Efterlevnad av GDPR genom dokumenterade riktlinjer för lösenord
Konsekvent implementering av rimliga riktlinjer för lösenord
Att säkra känsliga hostingområden börjar med att definiera och implementera effektiva lösenordsregler. En väl genomtänkt teknisk implementering säkerställer att svaga kombinationer utesluts så snart kontot skapas. Minimilängd, komplexitet och blockeringsfunktioner i händelse av misslyckade försök måste vara aktiva på systemsidan. Jag rekommenderar riktlinjer med minst 14 tecken längd och tvingande användning av specialtecken och versaler. Dessutom bör systemet automatiskt avvisa gamla och vanliga lösenord. För att göra riktlinjerna användarvänliga kan lösenordshintar visas direkt vid inmatningen. På så sätt kan hostingkunderna direkt se om deras val uppfyller kraven, t.ex. med hjälp av färgindikatorer (rött, gult, grönt). Jag har märkt att många värdar nämner lösenordsregler men inte alltid implementerar dem på ett tydligt sätt. En konsekvent integrering i kund- eller administratörsgränssnittet leder å andra sidan till betydligt färre fel vid tilldelning av lösenord. Regelbunden översyn av policyer spelar också en roll. Hotbilderna förändras ofta eller nya attackvektorer tillkommer. Det är värt att uppdatera kraven på lösenordsstyrka och minimilängd då och då. Detta håller säkerhetsnivån uppdaterad utan att nödvändigtvis äventyra befintliga hostingkonton.Hur den tekniska implementeringen av säkra lösenordspolicyer fungerar
I hostingmiljöer kan lösenordssäkerhet realiseras mest effektivt via policys på serversidan. Dessa inkluderar modulära moduler för lösenordsvalidering vid inmatning eller ändring av lösenord. De system som används bör vara utformade så att de kontrollerar lösenordens längd i klartext, teckentyper och matchningar med kända lösenordsläckor när de anges. Här är det värt att använda säkra hashmetoder som t.ex. Argon2 eller bcrypt helst även med en säkerhetsmodul för hårdvara för ytterligare säkerhet. Jag rekommenderar också att man strikt loggar misslyckade försök och aktiverar tillfälliga kontoblockeringar vid avvikelser. På så sätt kan potentiella brute force-attacker upptäckas i god tid innan en angripare lyckas få åtkomst. En blick på loggarna kan ge information om huruvida vissa IP-adresser eller användarkonton orsakar påfallande många åtkomstförsök. En annan viktig komponent är integrationen i befintliga hanteringssystem som cPanel, Plesk eller egna hosting-gränssnitt. Om lösenordspolicyer och valideringsmekanismer endast aktiveras på applikationsnivå är det ofta för sent och användarna har redan tilldelat sitt lösenord. Riktlinjerna bör därför implementeras och verkställas på serversidan - t.ex. med särskilda plug-ins eller integrerade moduler som kan integreras sömlöst i kontrollpanelen för webbhotellet.Enbart skärmlås är inte tillräckligt - MFA är obligatoriskt
Att enbart använda klassiska lösenord är inte längre tillräckligt för att få tillgång till hosting. Jag ser till att hostingkunderna dessutom skyddar sina konton med Multi-faktor autentisering kan säkras. Den bästa tvåfaktorslösningen kombinerar en statisk inloggning med en dynamiskt genererad kod - till exempel via en app eller en fysisk säkerhetstoken. När MFA är korrekt inställt förhindrar det åtkomst även om ett lösenord har äventyrats. Enligt min erfarenhet är kombinationen med appbaserade lösningar som Google Authenticator eller Authy särskilt populär. För särskilt känsliga miljöer rekommenderar jag dock hårdvarutokens (t.ex. YubiKey), eftersom dessa kan ge ytterligare skydd mot manipulation på den mobila enheten, till skillnad från en smartphone-app. Det är viktigt att planera återställningsprocessen. Om token förloras eller skadas måste det finnas ett säkert förfarande för att återställa åtkomsten utan att angripare kan missbruka detta förfarande. Förutom att logga in på hostingpanelen bör du också försöka tillämpa MFA för andra tjänster, t.ex. databaser eller e-postadministration. Tvåfaktorsautentisering används fortfarande alldeles för sällan inom just e-postsektorn, trots att e-post ofta innehåller lednings- eller kundkommunikation som inte får hamna i orätta händer.
Rekommenderade minimikrav för lösenord
Följande översikt gör det enkelt att få en överblick över grundläggande standarder och integrera dem i hostingplattformar:| Kategori | Krav |
|---|---|
| Minsta längd | Minst 12 tecken, företrädesvis 14 eller fler |
| Komplexitet | Kombination av stora/små bokstäver, siffror och specialtecken |
| Användningens varaktighet | Förnya var 90:e dag (kan automatiseras) |
| Undvikande | Inga standardlösenord eller lösenordselement (123, admin) |
| Förvaring | Krypterad med bcrypt eller Argon2 |
Verktyg för lösenordsrotation och åtkomstkontroll
Specialiserad programvara gör det möjligt för hostingadministratörer att automatiskt ändra åtkomst till privilegierade konton. Verktyg som Password Manager Pro eller liknande plattformar är särskilt användbara. Dessa program roterar regelbundet lösenord för servicekonton, dokumenterar ändringar, förhindrar duplicering och rapporterar omedelbart säkerhetsöverträdelser. Jag rekommenderar också att man har granskningsbara loggar och protokoll - det underlättar både operativt och vid granskning av tredje part. I större hostingmiljöer eller för större kunder kan man använda ett centraliserat system för identitets- och åtkomsthantering (IAM). Detta används för att definiera rollkoncept och genomdriva olika lösenords- och MFA-krav baserat på dessa roller. Till exempel gäller en högre säkerhetsnivå för administratörer än för vanliga användare. Under implementeringen är det viktigt att se till att alla gränssnitt är korrekt anslutna. Offboarding är också något som ofta underskattas: när anställda lämnar företaget måste deras åtkomst avaktiveras eller omfördelas omedelbart. Förutom lösenordsbaserad åtkomst är hanteringen av SSH-nycklar i hosting-miljöer också viktig. Även om många rekommenderar lösenordsfri autentisering för SSH-åtkomst måste nycklarna också förvaras säkert och roteras om det finns någon misstanke om att de kan ha äventyrats. I värsta fall kan en stulen SSH-nyckel leda till oupptäckt åtkomst, vilket är mycket svårare att upptäcka än användningen av ett knäckt lösenord.Identifiera och eliminera fallgroparna med felaktig lösenordshantering
Trots tydliga riktlinjer ser jag gång på gång samma svagheter i praktiken. Bland annat lagras lösenord i e-postmeddelanden, okrypterade anteckningar eller fritextfiler. Vissa användare använder identiska lösenord för flera tjänster eller skickar vidare sina åtkomstuppgifter via osäkra kanaler. För att motverka detta beteende förespråkar jag starkt centraliserade Administrativa och säkerhetsmässiga åtgärder från. Det blir särskilt knepigt när administratörer missbrukar sina egna privata lösenord för företagsåtkomst eller vice versa. Ett komprometterat privat konto kan snabbt bli en inkörsport till företagets resurser. Jag tycker att det är viktigt att hostingleverantörerna regelbundet informerar sina kunder om dessa faror. Utbildningsmaterial, webbseminarier eller korta förklarande videor i kundområdet kan göra underverk här. Jag följer också standarder som NIST SP 800-63B, som ger tydliga riktlinjer för lösenordsfrekvens, komplexitet och ändringsintervall. Särskilt företag som hanterar de mest känsliga uppgifterna bör åtminstone följa dessa riktlinjer för att stänga uppenbara angreppspunkter.
Praktiskt exempel: Lösenordskrav för hostingleverantörer
Jag har märkt att fler och fler hostar som webhoster.de förlitar sig på fördefinierade lösenordsregler. Kunderna kan inte välja sitt eget lösenord, utan får istället säkra kombinationer som genereras direkt av servern. Detta eliminerar helt upplägg som är känsliga för manipulation. Dessutom krävs autentisering med minst två faktorer för varje inloggning. Dessa leverantörer har redan stöd för automatiserade kontroller när ett konto skapas eller ett lösenord ändras. Nackdelen med vissa automatiserade genereringar är att användarna har svårt att memorera dessa lösenord. Av denna anledning erbjuds ofta en praktisk lösenordshanterare i kundcentret. Det innebär att kunderna inte behöver skriva in långa teckensträngar varje gång de loggar in, utan istället kan logga in bekvämt med hjälp av ett säkert system. Det är viktigt att sådana tjänster är både intuitiva och säkra och att inga lösenord skickas i klartext i e-postmeddelanden. Det finns dock fortfarande leverantörer som endast implementerar ett mycket rudimentärt skydd. Ibland finns det ingen skyldighet att använda MFA, ibland finns det ingen gräns för antalet misslyckade försök när man anger ett lösenord. Kunderna bör titta närmare på detta och vid behov välja en annan tjänst som uppfyller gällande säkerhetsstandarder.Efterlevnad av GDPR genom tekniska åtgärder
EU:s dataskyddsförordning föreskriver att system som är relevanta för dataskyddet måste skyddas genom lämpliga tekniska åtgärder. Alla som driver eller använder värdtjänster kan lämna in en dokumenterad lösenordspolicy som bevis. Automatiserade lösenordsrotationer och granskningsloggar ingår också i TOM. En väl implementerad lösenordskontroll stöder inte bara säkerheten, utan ger också lagstadgade bevis i händelse av en revision. Under en GDPR-revision kan ett saknat eller otillräckligt lösenordskoncept leda till kostsamma varningar eller böter. Jag rekommenderar därför att man bygger in detta i säkerhetsarkitekturen i ett tidigt skede och ser över det regelbundet. Vikten av noggrann dokumentation underskattas ofta. Du bör tydligt registrera hur komplicerade lösenorden måste vara, i vilka cykler en uppdatering sker och hur många misslyckade försök som tillåts innan kontot låses. Den här informationen kan vara en avgörande fördel vid en revision eller en säkerhetsincident. Frågan om lösenordsskydd är också relevant när det gäller databehandling på beställning (DPO). Leverantören bör i avtal garantera att den kommer att vidta lämpliga försiktighetsåtgärder. Annars kan kunderna snabbt hamna i en gråzon om lösenorden kommer på avvägar.
Organisatoriska rekommendationer för hostingkunder
Teknisk säkerhet omfattar även den organisatoriska delen. Jag råder hostingkunder att regelbundet utbilda alla användare - särskilt när det gäller nätfiske, social ingenjörskonst och återanvändning av lösenord. De bör också välja plattformar som har dokumenterade och tillämpade lösenordspolicyer. Detta inkluderar till exempel möjligheten till MFA-aktivering eller lösenordsspecifikation på serversidan. Om du vill vara på den säkra sidan bör du använda centraliserade lösenordshanterare och förlita dig på återkommande kontroller av enskilda regler. Särskilt i företag med många anställda bör lösenordsriktlinjerna kompletteras med tydliga interna processer. Det kan handla om riktlinjer för att tilldela nya konton, hantera gäståtkomst eller skydda inloggningar för ledningen. Jag rekommenderar också principen om dubbel kontroll vid tilldelning av särskilt kritisk åtkomst, t.ex. till databaser eller kunddata. Detta minskar risken för insiderhot och utesluter bättre mänskliga misstag. Det kan vara bra att skapa en intern FAQ eller en wiki om lösenordsanvändning. Där kan användarna få hjälp med hur de återställer sitt lösenord eller ställer in MFA. Detta självhjälpserbjudande avlastar inte bara supportteamet utan främjar också en självständig och ansvarsfull säkerhetskultur bland de anställda.Lösenordsskydd och WordPress: ett specialfall av CMS-åtkomst
I praktiken förlitar sig många webbprojekt på WordPress eller liknande CMS-plattformar. Det är framför allt här som jag ofta ser försök till attacker, t.ex. mot backend med hjälp av brute force. Det räcker alltså inte med att säkra hostinginfrastrukturen, utan även åtkomsten till applikationen måste skyddas. Ett bra alternativ är att skydda Säkra din WordPress-inloggning med enkla medel. Dessa inkluderar IP-blockeringar, hastighetsbegränsningar och inloggning med hjälp av tvåfaktorsförfarandet. Av egen erfarenhet vet jag att många WordPress -installationer är knappt säkrade eftersom fokus ofta ligger på teman och plugins. Här är det klokt att installera säkerhetsrelevanta plugins som blockerar misstänkta inloggningsförsök och skickar e-postmeddelanden till administratören vid attacker. Om du dessutom ändrar standardinloggningsadressen och använder en IP-vitlista minskar du attackytan avsevärt. Jag uppmuntrar alltid hostingkunder att vidta dessa ytterligare åtgärder för att göra sin WordPress-webbplats säkrare. Eftersom WordPress och andra CMS ofta har en mycket modulär struktur, är det också värt att ta en titt på respektive plugin-gränssnitt. Vissa säkerhetsplugins erbjuder redan integrerade funktioner för lösenordskontroll som känner igen svaga lösenord eller testar mot kända läckdatabaser. Ju fler säkerhetslager som kombineras, desto svårare blir det för potentiella angripare.
Lösenord som en del av en säkerhetsmodell med flera lager
Traditionella lösenord kommer inte att försvinna helt i framtiden - men de kommer att kompletteras. Jag ser fler och fler leverantörer som integrerar biometriska element eller lösenordslösa inloggningsprocedurer som FIDO2. Men även med dessa metoder är den säkra hanteringen av backup-åtkomst, adminkonton och API-åtkomst via starka lösenord oumbärlig. Det är därför inte ett alternativ, utan ett komplement. Jag ser till att dessa tekniker kombineras på ett medvetet sätt och att de är tekniskt säkrade. För ett säkerhetskoncept i flera lager bör lösenord, MFA, brandväggar, regelbundna revisioner och intrångstester gå hand i hand. Inget element ersätter det andra helt och hållet. Lösenord kan t.ex. skyddas av IP-filtreringsmekanismer, medan MFA avsevärt ökar den effektiva åtkomstbarriären. Samtidigt måste det finnas ett omfattande koncept för loggning och övervakning så att misstänkt åtkomst eller misslyckade försök kan identifieras och blockeras i realtid. I vissa fall kan biometriska procedurer (fingeravtryck, ansiktsigenkänning) också vara ett tillägg. Acceptansen i värdmiljön är dock ofta lägre eftersom administrationen och motsvarande enheter inte alltid är sömlöst tillgängliga. I slutändan är det lämpligt att steg för steg utvärdera vilka metoder som är bäst lämpade för den operativa miljön och där de praktiska fördelarna uppväger nackdelarna.Korrekt säkring av webbapplikationer också
Jag rekommenderar alla hostingkunder, Konsekvent säkra webbapplikationer - inte bara på hostingnivå, utan även på applikationsnivå. Många attacker sker inte direkt på hostingplattformen, utan via dåligt skyddade webbbackends. Säkerhet i flera lager är nyckeln här: lösenord, tvåfaktor, IP-filter och säkerhetsloggar hör ihop. Leverantörer som aktivt stöder detta gör det möjligt för användare att njuta av stabil och pålitlig hosting. I synnerhet anpassade webbapplikationer har ofta luckor i autentiseringen. En säker process för återställning av lösenord bör definitivt etableras här. Användare som återställer sitt lösenord bör verifieras tillräckligt innan en länk eller kod skickas automatiskt. En välkonfigurerad brandvägg för webbapplikationer (WAF) kan också blockera SQL-injektioner eller cross-site scripting-attacker, som annars lätt lurar i osäkra skript. Oavsett vilket CMS eller ramverk det handlar om är regelbundna uppdateringar av alla komponenter och plugins ett måste. Föråldrade programvaruversioner är en grogrund för säkerhetshål som inte ens starka lösenord kan kompensera för. Jag rekommenderar en fast uppdateringscykel som åtföljs av ett staging-system. På så sätt kan uppdateringar testas innan de går live. På så sätt förblir applikationen uppdaterad och stabil utan att riskera live-systemet med varje patch.
