Tudástár / Biztonság
Weboldal biztonság és védelem
Egy feltört weboldal nemcsak adatvesztést jelent — reputációs és üzleti kár is jár vele. A legfontosabb biztonsági alapokat gyűjtöttük össze, közérthetően, konkrét példákkal.
Tudástár / Biztonság
Egy feltört weboldal nemcsak adatvesztést jelent — reputációs és üzleti kár is jár vele. A legfontosabb biztonsági alapokat gyűjtöttük össze, közérthetően, konkrét példákkal.
Az SSL (pontosabban TLS) tanúsítvány titkosítja a weboldal és a látogató böngészője közötti teljes adatforgalmat. Nélküle a hálózaton közlekedő adatok — jelszavak, űrlapadatok, fizetési információk — elvileg lehallgathatók. SSL jelenlétét a https:// előtag és a lakat ikon jelzi a böngészőcímsorban.
Az SSL ma már kötelező standardnak számít: a Chrome és Firefox „Nem biztonságos" felirattal jelöli az SSL nélküli oldalakat, ami a látogatók bizalmát erősen csökkenti. Ezen felül a Google keresési algoritmusában is rangsorolási szempont — az SSL hiánya közvetlen hátrányt jelent az organikus keresési helyezésben.
Ingyenes SSL tanúsítvány az industry-standard Let's Encrypt révén elérhető, de a beállítás és az automatikus megújítás (90 naponta jár le) helyes konfigurálása technikai tudást igényel. Vállalati vagy e-kereskedelmi oldalakhoz érdemes fizetős, magasabb validációs szintű (OV, EV) tanúsítványt választani.
A biztonsági mentés a weboldal fájljainak és adatbázisának teljes másolata, amelyből feltörés, szerverhiba, véletlen törlés vagy hibás frissítés esetén helyre lehet állítani az eredeti állapotot. Mentés nélkül a visszaállítás nem garantált — esetenként lehetetlen.
Az ideális stratégia a 3-2-1 szabályt követi: legalább 3 mentési példány, legalább 2 különböző adathordozón vagy helyen, amelyből legalább 1 teljesen elkülönített (off-site) tárhelyen van — például S3-kompatibilis object storage-on. A tárhelyszolgáltató saját mentése nem helyettesíti a független mentést, mert ha a szerver meghibásodik, mindkét példány veszhet.
Aktív webshopnál napi mentés az elvárható minimum; statikusabb oldalaknál elegendő lehet a heti ciklus. Fontos, hogy a mentés visszaállíthatóságát időnként tesztelni is kell — a tesztelt mentés sokat ér, a teszteletlen keveset.
A WAF egy alkalmazásszintű tűzfal, amely a kéréseket már azelőtt szűri, hogy elérnék a weboldalt. Ismert támadási mintákat (payloadokat) azonosít és blokkol valós időben. Az általa kezelt fenyegetések közé tartoznak: SQL injection (ahol az adatbázis-lekérdezésekbe rosszindulatú SQL kód kerül), XSS (Cross-Site Scripting) (ahol JavaScript-kód fut le más felhasználók böngészőjében), és CSRF támadások.
A Cloudflare WAF és az AWS WAF a legelterjedtebb felhőalapú megoldások, amelyek naprakész szabályokat használnak az ismert sebezhetőségek ellen. Szerver szinten az ModSecurity (Nginx vagy Apache modulként) a legnépszerűbb open-source WAF megoldás.
Fontos: a WAF nem helyettesíti a biztonságos kódot — kiegészíti azt. Rosszul megírt, SQL injection-sérülékeny kódot a WAF sem véd meg tökéletesen.
A DDoS (Distributed Denial of Service) támadás célja a weboldal elérhetetlenné tétele úgy, hogy rengeteg — sok ezer különböző botnet-gépről érkező — kérés özönli el a szervert egyszerre. A szerver nem tudja kiszolgálni a valódi látogatókat sem, és elérhetetlenné válik.
A védekezés rétegei: CDN-alapú DDoS szűrés (a Cloudflare például hálózati szinten kiszűri a forgalmat, mielőtt az a szervert elérné), rate limiting (kérésszám-korlátozás), IP reputáció-alapú szűrés és szükség esetén a forgalom analizálása után az érintett IP-tartományok ideiglenes blokkolása. Kis és közepes weboldalak számára a Cloudflare ingyenes szintje már alapvető DDoS védelmet biztosít.
A rate limiting azt szabályozza, hogy egy adott IP-cím adott időszakon belül hány kérést küldhet. Például a bejelentkezési oldalon 5 sikertelen kísérlet után a rendszer 15 percre blokkolja az IP-t — ezzel a brute-force jelszótörési kísérletek automatikusan meghiúsulnak.
Laravel-ben ez a
throttle
middleware-rel, Nginx-en a
limit_req_zone
direktívával valósítható meg.
Az API végpontoknál különösen fontos a rate limiting — egy korlátlan API
könnyen kipumpálható, vagy szerver-erőforrásokat emészthet fel.
A legtöbb feltörés nem „célzott" támadás — automatizált szkriptek pásztázzák az internetet, és ismert sérülékenységgel rendelkező rendszereket keresnek. A leggyakoribb belépési pontok:
.env)A megelőzés alapjai: rendszeres frissítések, erős jelszavak és kétfaktoros hitelesítés, code review, minimális jogosultságok elve, és rendszeres biztonsági audit.
Amikor egy biztonsági rést felfedeznek egy szoftverben, a fejlesztők kiadnak egy javítást — de a patch megjelenésével egyidőben a sérülékenység is nyilvánossá válik. Akik nem frissítenek, a javítatlan réssel maradnak, miközben a kiaknázáshoz szükséges tudás már publikusan elérhető.
WordPress esetén például egy ismert plugin sérülékenység esetén órákon belül indul automatizált szkript-támadás az érintett oldalak ellen — nem kell hozzá célzott, emberi attacker.
Frissítés előtt mindig érdemes mentést készíteni, és staging környezetben tesztelni a kompatibilitást. A frissítések halogatása rövid távon kényelmes, hosszú távon azonban a biztonsági kockázat exponenciálisan nő.
A monitoring folyamatosan figyeli a weboldal állapotát — elérhetőségét, válaszidejét, szerver-erőforrás-kihasználtságát és esetleges hibáit. Ha az oldal leáll, a monitoring rendszer perceken belül értesítést küld, ahelyett hogy az ügyfél szólna be első látogatóként.
A legismertebb uptime monitoring eszközök (Better Uptime, UptimeRobot, Freshping) 30 másodpercenként ellenőrzik az oldalt, és azonnali SMS, email vagy Slack értesítést küldenek leállás esetén. Szerver szinten a Prometheus + Grafana kombináció részletes metrikákat nyújt a CPU, memória, hálózati terhelés és alkalmazáshibák vizualizálásához.
Monitoring nélkül a leállások átlagosan 3-4× hosszabb ideig észrevétlenek maradnak — ez közvetlen bevételkiesést jelent webshopok esetén.
Teljes körű védelem, mentések és folyamatos felügyelet.
Ajánlatkérés