# Biztonságtudatosság adminoknak és szerkesztőknek: security awareness a webes csapatban

> Biztonságtudatosság adminoknak és szerkesztőknek: mely kockázatok számítanak szerepkörönként, és hogyan tehet éberré egy webes csapatot 90 nap alatt.

Forrás: https://phpsos.de/hu/blog/sicherheitsbewusstsein-redaktion/  
Állapot: 2026. 10. 25.  
Szolgáltató: PHP SOS, PHP-vészhelyzeti segítség és szerverbiztonság. Azonnali segítség WhatsAppon: https://wa.me/491736494914?text=%C3%9Cdv%C3%B6zl%C3%B6m%2C%20PHP%20SOS%21%20Seg%C3%ADts%C3%A9gre%20van%20sz%C3%BCks%C3%A9g%C3%BCnk%20a%20PHP-szerver%C3%BCnkkel.%20C%C3%A9g%3A%20%E2%80%A6%20Weboldal%3A%20%E2%80%A6

**Röviden:** A biztonságtudatosság a webes csapat munkatársainál azt jelenti: mindenki, aki weboldalt gondoz, ismeri a szerepkörének három-négy kockázatát, felismeri a szokatlan jelenségeket, és gyorsan, szemrehányástól való félelem nélkül jelenti őket. A szerkesztőknek más tartalmakra van szükségük, mint az adminoknak. A rövid, ismétlődő egységek a saját CMS példáival jobban hatnak, mint egy éves kötelező képzés.

## Miért éppen most van a középpontban a webes csapat

A PHP2Shell körüli helyzet megmutatta, mennyi minden zúdul néhány nap alatt a weboldalak üzemeltetőire: a BSI (a német Szövetségi Információbiztonsági Hivatal) figyelmeztetései, tárhelyszolgáltatók közleményei, tanácsok fórumokon és közösségi hálózatokon, köztük hamisak is. Ilyen hetekben nemcsak az adminok, hanem a szerkesztők, a marketing és az asszisztensek is döntenek arról, melyik levelet nyitják meg, és melyik linkre kattintanak.

A nagy hírhelyzetek tapasztalat szerint alkalmat jelentenek a csalóknak. Számítson olyan levelekre, amelyek tárhelyszolgáltatónak, CMS-gyártónak vagy „IT-osztálynak” adják ki magukat, és sürgős bejelentkezésre vagy állítólagos biztonsági frissítésre szólítanak fel. Aki ismeri a valós helyzetet, ritkábban ddől be ennek. Magát a műszaki rést egyetlen szerkesztő sem zárja le, de egy ellopott admin-hozzáférés rés nélkül is kinyitja az ajtót.

## Biztonságtudatosság a munkatársaknál: ki mire szorul?

Mindenki számára ugyanazokkal a diákkal tartott képzés többnyire célt téveszt. Értelmesebb a szerepkörök szerinti szabás. A következő áttekintés segít a tervezésben:

| Szerepkör | Tipikus kockázatok | Mit kell tudnia a személynek |
|---|---|---|
| Szerkesztő, marketing | adathalász levelek, nem biztonságos fájlfeltöltések, megosztott hozzáférések | ellenőrizni a feladót, csak várt fájltípusokat feltölteni, a saját hozzáférési adatokat soha nem továbbadni |
| CMS-adminisztrátor | ismeretlen forrású bővítmények, túl sok admin-fiók, egykori munkatársak régi fiókjai | takarékosan osztani a jogokat, rendszeresen ellenőrizni a fiókokat, bővítményeket csak jóváhagyással telepíteni |
| Szerver-admin | ellenőrizetlen netes tippek, napló nélküli módosítások, elfelejtett tesztfájlok | értékelni a forrásokat, dokumentálni a módosításokat, ismerni a vészhelyzeti utat |
| Vezetés | nyomás a gyors döntésekre, tisztázatlan illetékességek | rögzíteni a döntési utakat, komolyan venni a jelentéseket, jóváhagyni a megelőzés költségvetését |
| Külső ügynökség | közös hozzáférések, hiányzó megállapodások | saját, személyes fiókokat használni, bejelenteni a módosításokat |

A táblázat azt is mutatja, hol kell segítenie a technikának. A közös hozzáférések helyett személyes fiókok, valamint a kétfaktoros bejelentkezés mindenkinek, aki írási joggal rendelkezik, sok terhet levesz a képzésről. Hogyan megy ez, azt a [Kétfaktoros bejelentkezés admin-hozzáférésekhez](https://phpsos.de/hu/ratgeber/zwei-faktor-admin/) tartalmazza.

## Mit kell tudniuk a szerkesztőknek anélkül, hogy technikussá válnának

A szerkesztőknek nem kell tudniuk, mi az a PHP-worker. Három dolgot azonban biztosan uralniuk kell. Először: a „biztonsági incidens miatti” újbóli bejelentkezésre való felszólítást soha nem a levélben lévő linken keresztül intézik, hanem a megszokott úton a CMS-be, vagy az adminnál való rákérdezéssel.

Másodszor: a szokatlan jelenségek jelentése. Ide tartoznak az ismeretlen felhasználói fiókok a felhasználólistában, olyan oldalak vagy bejegyzések, amelyeket senki sem hozott létre, a hirtelen átirányítások és a figyelmeztetések a böngészőben. Egy szerkesztő gyakran többször látja a weboldalt, mint az admin, és korábban észreveszi a változásokat.

Harmadszor: a feltöltések tudatos kezelése. A képek és PDF-ek mindennaposak, de a szokatlan kiterjesztésű fájl, az „továbbításra” szánt archívum vagy a makrókat tartalmazó dokumentum nem való a CMS-be. Ha egy fájlt nem lehet feltölteni, az többnyire szándékos, és nem olyan hiba, amelyet meg kellene kerülni.

## Mire van még szükségük az adminoknak

Az adminoknál kevésbé az adathalászatról van szó, mint az időnyomás alatti ítélőképességről. A PHP2Shell hetében olyan tanácsok keringtek, amelyeket a szakmai szerzők kifejezetten elutasítanak, például az összes `PHPSESSID`-t tartalmazó kérés blokkolását. Az ilyen tévutak áttekintését nyújtja a [Veszélyes téves tippek a PHP2Shellről](https://phpsos.de/hu/blog/gefaehrliche-falschtipps/) cikk. A jó adminok először az elsődleges forrást ellenőrzik, vagyis a php.netet, a BSI-t vagy a gyártót, mielőtt egy konfigurációt módosítanak.

Ide tartozik a fegyelem a módosításoknál: mit változtattak mikor és miért, és hogyan lehet visszavonni? Egy rövid bejegyzés a ticketben vagy a wikiben elég. Éles helyzetben ez a lista aranyat ér, mert megmutatja, melyik módosítás származik Öntől, és melyik nem.

Végül az adminoknak tudniuk kell, miről ismerik fel egy lehetséges behatolást, és mit nem szabad ilyenkor tenni: nem szabad kapkodva törölni, nem szabad azonnal újratelepíteni, hanem rögzíteni és jelenteni kell. A tipikus jeleket a [Feltörték már a rendszeremet?](https://phpsos.de/hu/php2shell/bin-ich-gehackt-anzeichen/) foglalja össze.

## 90 nap alatt éber webes csapat

Egy programnak nem kell nagynak lennie ahhoz, hogy hasson. Ezek a lépések váltak be:

1. **Az állapot tisztázása (1-2. hét):** Kinek milyen hozzáférései vannak a CMS-hez, a tárhelyhez, a domainhez és a szerverhez? A közös fiókokat fel kell oldani, a régi fiókokat le kell zárni.
2. **A jelentési út rögzítése (2. hét):** Egy cím vagy csatorna a „valami furcsának tűnik” esetekre. Minden jelentésre válaszolnak, akkor is, ha ártalmatlan volt.
3. **Az első rövid egység szerepkörönként (3-4. hét):** 20 perc, példák a saját CMS-ből, valódi menük képernyőfotóival.
4. **Kétfaktoros bejelentkezés bevezetése (a 6. hétig):** Mindenkinek, aki írási joggal rendelkezik, a vészkódokat biztonságos helyen tárolva.
5. **Gyakorló levél és kiértékelés (8. hét):** Egy bejelentett tesztkampány az egyes személyek lejáratása nélkül. Azt értékelik ki, hogy jelentettek-e, nem azt, hogy ki kattintott.
6. **Második egység egy aktuális alkalomhoz (10-12. hét):** Például egy aktuális biztonsági helyzet, a saját rendszeren végigjátszva.

A sikert a jelentésekkel mérje, ne a kattintási arányokkal. Az a csapat, amely sokat jelent, éber. Az a csapat, amely soha nem jelent, vagy tökéletes, vagy bizonytalan, és az előbbi ritka.

## Hogyan segít konkrétan a PHP SOS?

- Önnel együtt felmérjük, kinek milyen hozzáférései vannak, és megmutatjuk a közös fiókokat, a felesleges adminokat és az elfelejtett hozzáféréseket.
- Szerepkörönként távolról tartunk rövid egységeket, az Ön CMS-ének és szerverkörnyezetének példáival.
- Közösen kialakítjuk a jelentési utat, és kívánságra értékeljük a beérkező gyanújelentéseket.
- Egy [biztonsági karbantartási szerződés](https://phpsos.de/hu/leistungen/security-wartungsvertrag/) keretében aktuális alkalmakkor megismételjük az egységeket, és rendszeresen ellenőrizzük a fiókokat.

## Összegzés

A biztonságtudatosság a webes csapatban nem félelemből, hanem világosságból születik: mindenki ismeri a szerepkörét, a tipikus kockázatait és a szokatlan jelenségek jelentésének útját. A személyes fiókokkal és a kétfaktoros bejelentkezéssel kombinálva ez olyan védelem, amely a következő válsághéten is megállja a helyét.


## Gyakori kérdések

**Szükségük van a szerkesztőknek egyáltalán biztonsági képzésre?**  
Igen. A szerkesztők hozzáférnek a CMS-hez, fájlokat töltenek fel, és olyan leveleket kapnak, amelyek rendszerüzenetnek látszanak. Nem kell érteniük a technikához, de fel kell ismerniük, ha valami szokatlan, és tudniuk kell, kinek jelentsék.

**Milyen gyakran kell képezni a webes csapatot?**  
Jobb röviden és rendszeresen, mint évente egyszer hosszan. Bevált a 15-20 perces egység néhány hetes időközökkel, kiegészítve egy alkalommal, például egy aktuális biztonsági helyzettel.

**Mit tegyek, ha egy munkatárs rákattintott egy adathalász linkre?**  
Azonnal jelentesse, szemrehányás nélkül. Ezután meg kell változtatni az érintett jelszót, le kell zárni az aktív munkameneteket, és ellenőrizni kell, hogy módosítottak-e valamit a fiókkal. Minél korábban érkezik a jelentés, annál kisebb többnyire a kár.

**Helyettesíti a képzés a technikai védelmi intézkedéseket?**  
Nem. A képzés és a technika kiegészítik egymást. A kétfaktoros bejelentkezés, a különálló szerepkörök és a naprakész szoftver felfogják azokat a hibákat is, amelyek jól képzett emberekkel is megtörténnek.

## Források

- [BSI: információk vállalkozásoknak](https://www.bsi.bund.de/)
- [OWASP Cheat Sheet Series](https://cheatsheetseries.owasp.org/)
- [php.net: biztonsági közlemények](https://www.php.net/)