{"componentChunkName":"component---src-templates-blog-template-js","path":"/hu/blog/password-policy-dos-donts-best-practices","result":{"data":{"markdownRemark":{"html":"<p>A jelszópoltika célja, hogy azonosítókat nehezebb legyen feltörni, miközben nem teszi indokolatlanul bonyolulttá a biztonságos viselkedést. A legjobb szabályzatok egyértelműek, gyakorlatiasak, és igazodnak ahhoz, ahogyan az emberek valójában dolgoznak. Hosszú, egyedi jelszavakra ösztönöznek, támogatják a jelszókezelők használatát, előírják a többfaktoros hitelesítést ott, ahol indokolt, és eltávolítják azokat a régi szabályokat, amelyek kiszámítható viselkedéshez vezetnek.</p>\n<p>Ez a cikk bemutatja a modern jelszópolitika helyes és helytelen elemeit, a kerülendő hibákat, a legjobb gyakorlatokat, valamint egy másolható sablont, amelyet testre szabhat szervezete számára.</p>\n<h2>Mi az a jelszópolitika?</h2>\n<p>A jelszópolitika olyan szabálygyűjtemény, amely meghatározza, hogyan kell a jelszavakat létrehozni, tárolni, használni, megosztani, megváltoztatni és védeni. Alkalmazandó alkalmazottakra, alvállalkozókra, adminisztrátorokra, szolgáltatásfiókokra, és esetenként ügyfelekre – attól függően, hogy mely rendszerek tartoznak a hatókörbe.</p>\n<p>Egy jó jelszópolitika gyakorlati kérdésekre ad választ:</p>\n<ul>\n<li>Milyen hosszúnak kell lennie a jelszónak?</li>\n<li>Engedélyezettek-e jelszómondatok?</li>\n<li>Beilleszthető-e jelszó jelszókezelőből?</li>\n<li>Mikor kell megváltoztatni a jelszót?</li>\n<li>Kötelező-e többlépcsős hitelesítés?</li>\n<li>Hogyan kezeljük a közös hozzáférésű hitelesítő adatokat?</li>\n<li>Mi történik, ha feltörtnek gyanítjuk a jelszót?</li>\n</ul>\n<p>A cél nem a lehető legbonyolultabb szabályrendszer létrehozása, hanem a valós kockázat csökkentése.</p>\n<h2>Amit érdemes megkövetelni egy modern jelszópolitikában</h2>\n<h2>Követeljen megfelelő hosszúságot</h2>\n<p>A jelszó hossza az egyik legerősebb védelem a találgató és brute-force támadások ellen. Egyetlen, minden emberi felhasználóra érvényes minimális követelmény általában könnyebben érthető, és az IT-csapatok is könnyebben tudják érvényre juttatni, mint a külön szabályozást a szokványos felhasználókra, adminokra és különleges esetekre. Egy praktikus alap, ha minden emberi felhasználói fiókhoz legalább 16 karakteres jelszót írunk elő. Ha jelszókezelőt vagy véletlenszerűen generált jelszómondatokat használnak a felhasználók, a hosszabb még jobb.</p>\n<h2>Engedélyezze a hosszú jelszavakat és jelszómondatokat</h2>\n<p>A felhasználók tudjanak minden eddiginél hosszabb jelszavakat is létrehozni. Kerülje az alacsony maximális hosszhatárokat, mint a 16 vagy 20 karakter. Legalább 64 karakteres maximális hosszt javasolt megengedni, és sok rendszer ennél többet is biztonságosan tud kezelni.</p>\n<p>A jelszómondatok engedélyezettek legyenek, de csak ha elég hosszúak, és nem közismert idézeteken, dalszövegeken, cégneveken vagy kiszámítható fordulatokon alapulnak. Például több véletlenszerű szóból álló jelszómondat általában jobb, mint egy rövid, kényszerített karakterhelyettesítésekkel teli jelszó.</p>\n<h2>Követelje meg az egyediséget</h2>\n<p>Minden fióknak egyedi jelszóra van szüksége. A jelszóújrahasználat egyik fő oka annak, hogy egy kiszivárgásból több fiók átvétel lesz más szolgáltatásokon is. A jelszókezelő lehetővé teszi, hogy egyedi jelszavakat használjunk anélkül, hogy mindegyiket fejben kellene tartani.</p>\n<h2>Támogassa a jelszókezelők használatát</h2>\n<p>Szabályzatában külön emelje ki, hogy engedélyezett és támogatott a jóváhagyott jelszókezelők használata. A felhasználók beilleszthessék a jelszavakat a bejelentkezési űrlapokra, használhassák az automatikus kitöltést, és generálhassanak véletlenszerű jelszavakat. A beillesztés tiltása védőintézkedésnek tűnhet, de legtöbbször inkább gátolja a valóban erős jelszavak használatát.</p>\n<h2>Ellenőrizze a jelszavakat ismert kompromittált listák ellen</h2>\n<p>A jelszót el kell utasítani, ha ismert adatlopásból származó listákban, gyakran használt jelszavak között, vagy a szervezet tiltólistáján szerepel. Ez több védelmet ad, mint rákényszeríteni a felhasználóra, hogy szerepeljen egy nagybetű, egy szám és egy szimbólum a jelszavában.</p>\n<h2>Kötelezze a többfaktoros hitelesítést, ha technikailag megoldható</h2>\n<p>Ahol technikailag lehetséges, legyen bekapcsolva a többfaktoros hitelesítés (MFA), különösen az adminisztrátorok, távoli elérés, felhőszolgáltatások, email, jelszókezelők, pénzügyi rendszerek és más értékes rendszerek esetén. A többfaktoros hitelesítés nem pótolja az erős jelszavakat, de csökkenti a lopott hitelesítő adatok jelentette kockázatot.</p>\n<p>Előnyben részesítse az adathalászatnak ellenálló MFA-t, mint a passkey-ek, hardveres biztonsági kulcsok vagy platform hitelesítők. Az alkalmazásalapú hitelesítő appok általában jobbak, mint az SMS. Az SMS-alapú MFA-t kerülni kell, amint bármely más multifaktoros hitelesítési módszer technikailag elérhető, mert a telefonszámokat elfoghatják, klónozhatják (SIM-swapping), átírhatják vagy visszaélhetnek velük a regisztráció során.</p>\n<p>Ez nem elmélet: 2018-ban a Reddit bejelentette, hogy támadók elfogták az SMS-alapú kétlépcsős hitelesítést, és belső rendszerekhez fértek hozzá: <a href=\"https://www.reddit.com/r/announcements/comments/93qnm5/we_had_a_security_incident_heres_what_you_need_to/\" rel=\"nofollow\">https://www.reddit.com/r/announcements/comments/93qnm5/we<em>had</em>a<em>security</em>incident<em>heres</em>what<em>you</em>need_to/</a>. 2021-ben a Coinbase jelezte, hogy támadók legalább 6 000 ügyféltől loptak el kriptovalutát, miután kihasználták a hitelesítő adatokat és egy SMS-alapú fiókvisszaállítási rést: <a href=\"https://www.reuters.com/technology/coinbase-says-hackers-stole-cryptocurrency-least-6000-customers-2021-10-01/\" rel=\"nofollow\">https://www.reuters.com/technology/coinbase-says-hackers-stole-cryptocurrency-least-6000-customers-2021-10-01/</a>.</p>\n<h2>Cserélje a jelszavakat kompromittálódás után</h2>\n<p>A jelszót akkor kell megváltoztatni, ha bizonyíték vagy ésszerű gyanú merül fel annak kompromittálódására. Erre példák: adathalászat, malware a felhasználó eszközén, azonosító kiszivárgása, gyanús bejelentkezés vagy véletlen felfedés.</p>\n<h2>A közösen használt hitelesítő adatokat is védje megfelelően</h2>\n<p>Közös jelszavakat csak akkor alkalmazzon, ha egyéni fiók nem megoldható. Ha a közös hitelesítő elkerülhetetlen, akkor azt jóváhagyott jelszókezelőben kell tárolni, a hozzáférést korlátozni az arra jogosultakra, és ahol lehet, a megosztást naplózni.</p>\n<h2>Védje a jelszó-visszaállítás folyamatát</h2>\n<p>A jelszó-visszaállítás általában a fiókbiztonság leggyengébb pontja. Ellenőrizni kell a visszaállítás során a felhasználó személyazonosságát, a visszaállító hivatkozás gyorsan járjon le, csak egyszer használható legyen, és értesítse a felhasználót a jelszó módosításáról.</p>\n<h2>Amit tilos egy modern jelszópolitikában</h2>\n<h2>Ne kötelezzen indokolatlan gyakori jelszócserére</h2>\n<p>A kötelező, gyakori (30, 60 vagy 90 napos) jelszócsere általában gyengébb jelszavakhoz vezet. A felhasználók ilyenkor hajlamosak kis, kiszámítható módosításokat alkalmazni, például számot növelni vagy évszakot cserélni. Az NIST Digitális Azonosítási Irányelvei elvetették a rutinszerű, időszakos jelszócserét — csere csak bizonyított kompromittálódás esetén javasolt. Lásd 3.1.1.2 fejezet: <a href=\"https://pages.nist.gov/800-63-4/sp800-63b.html#passwordver\" rel=\"nofollow\">https://pages.nist.gov/800-63-4/sp800-63b.html#passwordver</a>. Jelszócsere legyen kötelező kompromittálódás, szerepkörváltás, fiókvisszaállítás vagy akkor, ha a jelszó már nem felel meg a szabályzatnak.</p>\n<h2>Ne hagyatkozzon kizárólag bonyolultsági szabályokra</h2>\n<p>Az olyan szabályok, mint \"kötelező kisbetűt, nagybetűt, számot, szimbólumot tartalmazzon\" önmagukban nem jelentenek védelmet. A <code>Password1!</code> megfelel sok bonyolultsági elvásárnak, mégis gyenge. Inkább a hosszra, egyediségre, véletlenszerűségre és breach-lista szűrésre helyezze a hangsúlyt.</p>\n<h2>Ne tiltsa a másolást vagy beillesztést</h2>\n<p>A beillesztés tiltása megnehezíti a jelszókezelők használatát, és rövidebb, könnyebben begépelhető jelszavakra tereli a felhasználókat. Engedje a beillesztést és automatikus kitöltést, kivéve ha konkrét, dokumentált biztonsági ok indokolja a tiltást.</p>\n<h2>Ne engedje a jelszótippeket</h2>\n<p>A jelszótippek sokszor túl sokat elárulnak. Ha egy tippből a felhasználó ki tudja találni a jelszavát, valószínű, hogy a támadó is. Alkalmazzon inkább biztonságos visszaállítási folyamatot.</p>\n<h2>Soha ne tároljon jelszót olvasható formában</h2>\n<p>Rendszerekben soha ne legyen a jelszó olvasható (plain text) vagy visszafejthető titkosítással tárolva. A jelszavakat modern, lassú, sózott jelszóhash-algoritmussal kell tárolni, például Argon2id, bcrypt, scrypt vagy PBKDF2 (a rendszer képességeitől és szabályozásaitól függően).</p>\n<p>A gyors, általános célú hash-algoritmusok, mint az MD5, SHA-1, SHA-256 vagy SHA-512 nem megfelelőek önmagukban jelszóhash-elésre. Ezeket gyorsaságuk miatt tervezték, így egy adatbázis-szivárgás után könnyen kivitelezhetővé válnak az offline brute-force támadások. További háttér az <a href=\"/blog/evolution-of-password-hashing\">a jelszóhashelés fejlődése</a> cikkünkben.</p>\n<h2>Ne osszon meg jelszavakat emailben vagy chaten</h2>\n<p>Jelszavakat nem szabad emailben, chatben, ticketekben, dokumentumokban vagy képernyőképeken megosztani. Használjon jelszókezelőt biztonságos megosztással és jogosultságkezeléssel.</p>\n<h2>Ne használjon személyes adatokat vagy kiszámítható mintákat</h2>\n<p>A jelszó nem tartalmazhat nevet, születési dátumot, cégnév-részletet, billentyűzetmintát, ismétlődő karaktereket vagy gyakori helyettesítéseket (pl. <code>@</code> helyett <code>a</code>, <code>0</code> helyett <code>o</code>). A támadók ezeket a mintákat hamar tesztelik.</p>\n<h2>Legjobb gyakorlatok szervezetek számára</h2>\n<h2>Állítson fel egyértelmű minimum követelményeket</h2>\n<p>Használjon könnyen érthető elveket:</p>\n<ul>\n<li>Egy minimum hossz elvárás, pl. 16 karakter minden emberi felhasználói fiókhoz</li>\n<li>Engedjen meg legalább 64 karakter hosszú jelszavakat</li>\n<li>Engedje a szóközöket és általános szimbólumokat</li>\n<li>Engedélyezze a jelszómondatokat és jelszókezelők használatát</li>\n<li>Utasítsa el a kompromittált vagy gyakran használt jelszavakat</li>\n</ul>\n<h2>Kezelje a privilegizált fiókokat másként</h2>\n<p>Adminisztrátori, szolgáltatásfiókok és éles hozzáférések esetén szigorúbb szabályokat alkalmazzon. Erősebb jelszavak, multifaktoros hitelesítés, korlátozott hozzáférés, rendszeres ellenőrzés és azonnali forgatás hozzáférésváltáskor.</p>\n<h2>Használjon szerepalapú hozzáféréskezelést és legkisebb jogosultság elvét</h2>\n<p>Az erős jelszavak sem pótolják a túlzott jogosultságokat. A felhasználók csak a munkájukhoz szükséges rendszerekhez és titkokhoz férjenek hozzá.</p>\n<h2>Figyelje a gyanús aktivitást</h2>\n<p>Észlelje a szokatlan bejelentkezési mintákat, lehetetlen utazásokat, ismételt hibás próbálkozásokat, új országokból induló hozzáférést, vagy munkaidőn kívüli használatot. A jelszópolitika betartását támogassa monitorozással és incidenskezeléssel.</p>\n<h2>Képezze a felhasználókat a valódi fenyegetésekre</h2>\n<p>Az oktatás fókuszáljon a jelszóújrahasználatra, adathalászatra, hamis bejelentkező oldalakra, MFA-kimerítésre, biztonságos megosztásra, és hogy hogyan kell jelenteni a kompromittált gyanút. Ne hibáztassa a felhasználót, hanem tegye a biztonságos viselkedést könnyűvé.</p>\n<h2>Legyen a szabályzat elég rövid, hogy legyen betartható</h2>\n<p>A jelszópolitika legyen érthető. Ha túl hosszú, túl homályos vagy túlságosan szigorú, az emberek ki fogják játszani. A legjobb szabályzat, amit tényleg lehet is követni és érvényesíteni.</p>\n<h2>Másolható jelszópolitika-sablon</h2>\n<p>Használja kiindulópontként az alábbi sablont! A szögletes zárójelek közötti részeket igazítsa saját szervezetéhez, rendszereihez, kockázataihoz és jogszabályi követelményeihez.</p>\n<pre><code class=\"language-text\">Jelszópolitika\n\nVerzió: [1.0]\nTulajdonos: [Biztonság / IT osztály]\nÉrvényesség kezdete: [ÉÉÉÉ-HH-NN]\nFelülvizsgálat időköze: [12 havonta]\n\n1. Célkitűzés\n\nEz a szabályzat meghatározza a [Szervezet Neve] jelszavainak létrehozására, használatára, tárolására, megosztására és módosítására vonatkozó követelményeket. Célja csökkenteni az illetéktelen hozzáférés, hitelesítő adatlopás, fiókátvétel és adatvesztés kockázatát.\n\n2. Hatály\n\nEz a szabályzat minden alkalmazottra, alvállalkozóra, ideiglenes munkatársra, szolgáltatóra és minden más felhasználóra érvényes, aki a [Szervezet Neve] rendszereihez, alkalmazásaihoz, hálózataihoz, felhőszolgáltatásaihoz vagy adataihoz hozzáfér.\n\nHatályos minden szokványos, privilegizált, szolgáltatási, közös fiókra vagy bármely rendszerre, ahol a jelszó hitelesítésre szolgál.\n\n3. Jelszóképzés követelményei\n\nMinden jelszónak az alábbi követelményeket kell teljesítenie:\n\n- Emberi felhasználók fiókjainál legalább 16 karakter hosszú jelszót kell használni.\n- A jelszavak legyenek egyediek, ne legyenek újrafelhasználva sem munkahelyi, sem magán fiókokon.\n- Jelszó nem tartalmazhat nevet, felhasználónevet, cégnév-részletet, születési dátumot, billentyűzetmintát, ismétlődő karaktereket vagy más könnyen kitalálható információt.\n- Jelszó nem alapulhat gyakori kifejezéseken, idézeteken, dalszövegeken vagy kiszámítható helyettesítéseken.\n- Jelszó nem szerepelhet ismert kompromittált jelszólistákban vagy gyakori jelszavak között.\n- Jelszó tartalmazhat szóközöket, szimbólumokat, számokat, nagy- és kisbetűket.\n- Jelszómondat megengedett, ha elég hosszú, egyedi és nem kiszámítható vagy nyilvános mondat.\n\n4. Jelszókezelők\n\nA [Szervezet Neve] előírja vagy erősen javasolja, hogy jóváhagyott jelszókezelőt használjanak jelszavak létrehozására, tárolására és megosztására.\n\nA felhasználók használhatják a jelszógenerátort, automatikus kitöltést, másolás/beillesztés funkciót a jóváhagyott jelszókezelőből. Jelszavakat nem szabad böngészőben, táblázatban, dokumentumban, jegyzetappban, emailben, chatben, képernyőképen vagy jóváhagyatlan eszközökben tárolni.\n\n5. Többlépcsős hitelesítés (MFA)\n\nA többfaktoros hitelesítés alkalmazása kötelező, ahol technikailag lehetséges, beleértve (de nem kizárólag):\n\n- Email fiókok\n- Távoli elérés rendszerei\n- Jelszókezelők fiókjai\n- Felhőszolgáltatások\n- Adminisztrátori fiókok\n- Pénzügyi, HR és más magas kockázatú rendszerek\n- Valamennyi rendszer, amely [bizalmas/kritikus] besorolású\n\nAhol rendelkezésre áll, a felhasználók adathalászatnak ellenálló MFA-t használjanak, például passkey-t, hardverkulcsot vagy platform authemtikátort. Előny az applikáció-alapú hitelesítés az SMS helyett. SMS-alapú MFA csak akkor alkalmazható, ha más – erősebb – MFA megoldás technikailag nem lehetséges.\n\n6. Jelszóváltás\n\nA jelszót azonnal meg kell változtatni, ha:\n\n- A jelszó kompromittálódott vagy annak gyanúja felmerül.\n- A felhasználó adathalász oldalra írta be a jelszót.\n- A jelszót jogosulatlan személlyel osztották meg.\n- Malware vagy jogosulatlan hozzáférés észlelhető a felhasználó eszközén.\n- A jelszó szerepel ismert adatszivárgásban.\n- Privilegizált felhasználó szerepköre vagy munkaviszonya változik.\n- Az IT/Biztonság felszólítja a felhasználót jelszóváltásra.\n\nAutomatikus jelszólejárat nem szükséges, kivéve ha törvény, szabályozás, szerződés vagy rendszer ezt megköveteli. A jelszót nem szabad csak minimális, kiszámítható módosítással megváltoztatni.\n\n7. Jelszómegosztás\n\nJelszót nem szabad emailben, chatben, ticketen, dokumentumban, képernyőképben, telefonon vagy szóban megosztani.\n\nMegosztott hitelesítő csak akkor engedélyezett, ha egyéni fiók technikailag nem megoldható, vagy ha azt az [IT/Biztonság] kifejezetten jóváhagyta. Jóváhagyott közös hitelesítőt kizárólag jóváhagyott jelszókezelővel, és csak jogosult hozzáférőkkel lehet megosztani.\n\n8. Privilegizált fiókok\n\nPrivilegizált fiókokhoz egyedi jelszót kell használni, amely más standard fiókhoz nem alkalmazható. Ezeknél a fiókoknál MFA kötelező, ahol technikailag lehetséges, rendszeres felülvizsgálat mellett.\n\nPrivilegizált jelszót akkor kell forgatni, ha az adminisztrátor elhagyja a szervezetet, szerepet vált, megszűnik hozzáférési szükségessége, vagy kompromittálódás gyanúja esetén.\n\n9. Szolgáltatási fiókok és alkalmazástitkok\n\nSzolgáltatási fiókok jelszavait, API kulcsokat, tokeneket, alkalmazástitkokat jóváhagyott titokkezelőben vagy jelszókezelőben kell tárolni.\n\nSzolgáltatási fiók adatok nem lehetnek kódban, konfigurációs fájlban, képekben, dokumentációban vagy scriptben, kivéve ha azt jóváhagyott titokkezelési eljárás védi.\n\n10. Jelszó-visszaállítás és fiók-visszaállítás\n\nA visszaállítási folyamatban mindig ellenőrizni kell a felhasználó személyazonosságát, mielőtt visszaállítják a hozzáférést. Visszaállító hivatkozások és ideiglenes jelszavak csak egyszer használhatók, gyorsan lejárnak, és csak jóváhagyott csatornán továbbíthatók.\n\nA felhasználót értesíteni kell jelszóváltozásról vagy visszaállításról. Ideiglenes jelszót első bejelentkezéskor meg kell változtatni.\n\n11. Technikai kontrollok\n\nA jelszavakat tároló vagy feldolgozó rendszereknek:\n\n- Soha nem szabad jelszót olvasható formában tárolni.\n- Jóváhagyott, modern, sózott jelszóhash-algoritmust kell alkalmazni: PBKDF2, scrypt, bcrypt vagy Argon2.\n- Nem alkalmazhatnak MD5, SHA-1, SHA-256, SHA-512 vagy más gyors algoritmust önmagában jelszó-hashelésre.\n- Hitelesítési végpontoknál rate limiting vagy hasonló védelem szükséges.\n- El kell utasítani a gyenge, gyakori vagy ismerten kompromittált jelszavakat.\n- Engedélyezni kell jelszó beillesztését jelszókezelőből.\n- Legyen támogatott legalább 64 karakter hosszú jelszó, ahol technikailag lehetséges.\n- A biztonságilag releváns hitelesítési eseményeket naplózni kell.\n\n12. Kompromittálódás jelentése\n\nA felhasználó köteles azonnal jelenteni, ha jelszavának kompromittálódására, adathalászatra, szokatlan bejelentkezési felületre, MFA-értesítésre (amit nem ő indított), vagy véletlen jelszó-felfedésre gyanakszik az [IT/Biztonság kapcsolattartónál].\n\n13. Kivételek\n\nE szabályzat alóli kivétek dokumentálandók, kockázatelemzendők, időben korlátozandók és az [IT/Biztonság vezetése] által jóváhagyandók. Amennyire csak lehet, helyettesítő védelmi intézkedést kell alkalmazni.\n\n14. Szankciók\n\nA szabályzat megsértése hozzáférés eltávolításához, kötelező biztonsági tréninghez, fegyelmi eljáráshoz vagy más intézkedéshez vezethet, összhangban [Szervezet Neve] szabályzataival és a vonatkozó jogszabályokkal.\n\n15. Felülvizsgálat\n\nA szabályzatot legalább évente, vagy jelentős rendszer-, fenyegetettség-, jogi vagy üzleti változás után felül kell vizsgálni.\n</code></pre>\n<h2>Záró gondolatok</h2>\n<p>Az erős jelszószabályzat nem a felhasználó életének megnehezítéséről szól. A cél a gyenge szokások felszámolása, a jelszókezelők támogatása, a többfaktoros hitelesítés alkalmazása, valamint a gyors reakció kompromittált hitelesítő adatok esetén. Legyen a szabályzat praktikus, betartható, és összpontosítson a valós támadásokra, mint a phishing, credential stuffing, jelszó-újrafelhasználás és feltört fiókok.</p>","frontmatter":{"date":"May 07, 2026","slug":"password-policy-dos-donts-best-practices","title":"Jelszópolitika: Amit szabad, amit tilos, legjobb gyakorlatok, és egy másolható sablon","description":"Ismerje meg, mit kell ma megkövetelni egy korszerű jelszópolitikában, mely elavult szabályokat érdemes elkerülni, és másolja ki a gyakorlatias sablont a szervezete számára.","author":"Sascha Pfeiffer","featuredImage":null}}},"pageContext":{"slug":"password-policy-dos-donts-best-practices","lang":"hu","langPathPrefix":"/hu"}},"staticQueryHashes":["2149092236","3128451518","3192060438"]}