Rendelettervezet a védelmi és biztonsági célú lakossági riasztási rendszer műszaki követelményeiről
Véleményezés időtartama: 2025. november 10–17.
E-mail cím: tarsadalmi_egyeztetes@nmhh.hu
A rendelettervezet a lap alján Word-változatban letölthető.
[1] A rendelet célja, hogy – az elektronikus hírközlésről szóló 2003. évi C. törvény 145/B-145/D. §-a, valamint a védelmi és biztonsági tevékenységek összehangolásáról szóló 2021. évi XCIII. törvény 71. §-a szerinti szabályozással összhangban – megállapítsa azokat a műszaki követelményeket, amelyek mobil rádiótelefon-technológia igénybevételével lehetővé teszik riasztási üzenet közel egyidejű továbbítását azon eszközökre, amelyek a riasztási célterületként meghatározott földrajzi területen találhatóak.
[2] A védelmi és biztonsági célú lakossági riasztási rendszer által küldött üzenet címzettje nem konkrét felhasználó, hanem a mobil rádiótelefon-hálózaton honos és barangoló, az üzenetek fogadására képes mobil eszközök automatikusan megkapják azokat. Ennek biztosítása érdekében szükséges a védelmi és biztonsági igazgatás központi szerve, az üzemeltető szervezet, valamint az érintett elektronikus hírközlési szolgáltatók közötti együttműködés és a megfelelő hálózati technológiák műszaki specifikációjának e rendelet szerinti összehangolása.
[3] Az elektronikus hírközlésről szóló 2003. évi C. törvény 182. § (3) bekezdés 17. pontjában kapott felhatalmazás alapján, a médiaszolgáltatásokról és a tömegkommunikációról szóló 2010. évi CLXXXV. törvény 109. § (5) bekezdésében meghatározott feladatkörömben eljárva a következőket rendelem el:
1. § E rendelet alkalmazásában
1. CAP üzenet: a CBE által előállított, az OASIS (Organization for the Advancement of Structured Information Standards) nemzetközi szabványügyi szervezet által kiadott CAP (Common Alert Protokol) szabvány v1.2 verziójának megfelelő üzenet.
2. CBC: a CBS azon központi komponense a szolgáltatók hálózataiban, amely kapcsolatot tart a CBE és a szolgáltató bázisállomásai között, ennek keretében fogadja a CBE által előkészített és továbbított CAP üzeneteket, a CB célterület alapján meghatározza, hogy mely cellákba kell továbbítani a CB üzenetet, valamint továbbítja a CB üzenetet a megfelelő bázisállomások számára.
3. CB célterület: a CAP üzenetben meghatározott földrajzi terület, amelyet poligon, földrajzi koordináta és egy hozzá tartozó sugár által meghatározott kör alapú terület, vagy egy előre definiált geokód határoz meg.
4. CBE: a CBS azon központi komponense, amelyen megvalósul a CAP üzenet létrehozása és az üzenet továbbításának kezdeményezése a CBC-k felé.
5. CBE üzemeltető: jogszabályban a CBE üzemeltetésére felhatalmazott jogi személy.
6. CBS: az ETSI TS 123 041:2025 szabvány műszaki tartalmán alapuló, mobilkommunikációs technológia, amely lehetővé teszi szöveges üzenetek központi helyről történő küldését egyidőben nagyszámú mobil eszközre, meghatározott földrajzi területen, felhasználótól függetlenül, a válaszadás lehetősége nélkül.
7. CB üzenet: a mobil bázisállomások által a CAP üzenet szerinti paramétereknek megfelelően kisugárzott olyan szöveges üzenet, amelyet a lefedettségi területen lévő, CB üzenet fogadására képes mobil eszközök automatikusan megkapnak, megjelenítenek.
8. Poligon: CB célterület leírására alkalmas IETF RFC 7946 szabvány szerinti GeoJSON térinformatikai adatcsere formátumú zárt geometriai alakzat, amely legfeljebb 100 koordinátát tartalmazhat.
9. Szolgáltató: mobil rádiótelefon szolgáltatást nyújtó elektronikus hírközlési szolgáltató.
2. § (1) Az elektronikus hírközlésről szóló 2003. évi C. törvény (a továbbiakban: Eht.) 145/B. § (1) bekezdése szerinti védelmi és biztonsági célú lakossági riasztási rendszer működtetése a CBS révén valósul meg.
(2) A CBE üzemeltető legalább kettő – egy aktív, valamint egy készenléti üzemmódban lévő – CBE-t üzemeltet, és az év minden napján biztosítja azok folyamatos felügyeletét. A CBE üzemeltető biztosítja, hogy a CBE-k rendelkezésre állása éves szinten legalább 99,9 % legyen.
(3) A CBE üzemeltető a CBE-ket egymástól földrajzilag oly módon elkülönítve helyezi el, hogy – különösen az egyik helyszínt érintő szolgáltatáskiesés esetén – képesek legyenek az egymást helyettesítő működésre. A CBE üzemeltető biztosítja a helyettesítés automatikus vagy manuális beállítását.
(4) A szolgáltató hálózatában legalább kettő – egymással nem szükségszerűen szinkronizált – CBC-t üzemeltet, és az év minden napján biztosítja azok folyamatos felügyeletét. A szolgáltató biztosítja, hogy a CBC-k rendelkezésre állása éves szinten legalább 99,9 % legyen.
(5) A szolgáltató a CBC-ket egymástól földrajzilag oly módon elkülönítve helyezi el, hogy – különösen az egyik helyszínt érintő szolgáltatáskiesés esetén – képesek legyenek az egymást helyettesítő működésre. A CBC bármely CBE-től érkező CAP üzenetet az abban foglaltaknak megfelelően kezel, a CBE üzemmódjának ellenőrzése nélkül.
(6) A szolgáltató hálózatában tesztcélú CBC-t üzemeltethet. A CBE üzemeltető biztosítja, hogy a CBE-k megkülönböztessék a CBC-t és a tesztcélú CBC-t. Tesztelés az 5. § (1) bekezdés f) pontja szerinti teszt üzenet küldése révén lehetséges.
3. § (1) A CBE-k egymástól független adatátviteli utakon kapcsolódnak a CBC-khez. A CBE-k és a CBC-k nem változó nyilvános IP címekkel rendelkeznek.
(2) A CBE és a CBC között közvetlen IP alapú adatátviteli kapcsolat kiépítéséhez felhasználhatók a kormányzati célú hálózat és a szolgáltató hálózata között már meglévő összeköttetések, szolgáltatásátadási pontok.
(3) A CBE és a CBC együttműködését a CBE-CBC interfész biztosítja, amelynek rendelkezésre állása éves szinten legalább 99,9 %. A CBC-nek alkalmasnak kell lennie – a CBE üzemeltető által meghatározott és a szolgáltató rendelkezésére bocsátott interfész specifikáció révén – a CBE-vel való együttműködésre.
(4) A fizikai adatkapcsolat a szolgáltató és a CBE üzemeltető közötti megállapodás szerint kerülhet kialakításra, különösen az alábbi paraméterek szerint:
- a) a CBE szerver nem változó nyilvános IP címeken éri el a CBC szervert az interneten, a Nemzeti Távközlési Gerinchálózaton keresztül, site-to-site VPN (Virtual Private Network) kapcsolattal (ipsec védelemmel) vagy
- b) a CBE és a CBC szerverei adatközpontokon keresztül kapcsolódnak egymáshoz site-to-site VPN (Virtual Private Network) kapcsolattal (ipsec védelemmel).
(5) A CBE üzemeltető által meghatározott szolgáltatásátadási pontoktól a szolgáltató a hálózatáig saját költségén alakítja ki az összeköttetést és üzemelteti a berendezéseket, illetve a szolgáltató viseli a 2. § (4) bekezdése szerinti rendelkezésre állással való kiépítési, létesítési és üzemeltetési költségeket. A CBE üzemeltető által meghatározott szolgáltatás átadási pontoktól a szolgáltató hálózatáig az összeköttetés tovább kábelezése a szolgáltató feladata és költsége.
(6) A CBE és a CBC közötti kommunikáció titkosított csatornán történik az 1. mellékletben foglaltak szerint. A tanúsítványkezelés a CBE üzemeltető feladata.
4. § (1) A CBE és a CBC közötti kommunikáció alkalmazási szinten elsődlegesen XML formátumban történik. A CBE üzemeltető és a szolgáltató biztosítja, hogy a CBE és a CBC közötti kommunikáció az ETSI TS 102 900 V1.4.1 (2023-06) szabvány tartalmával összhangban megfeleljen az OASIS nemzetközi szabványügyi szervezet által kiadott Common Alerting Protocol v1.2 verziójának magyar specifikációja alapján meghatározott – a védelmi és biztonsági igazgatás központi szerve által közzétett – követelményeknek. A CBE üzemeltető biztosítja továbbá, hogy a CBE kezelje mindazon eltéréseket, amelyek az egyes szolgáltatók CBC-inek kommunikációjában a CAP v1.2-es verziónak megfelelés mellett esetlegesen fennállnak.
(2) Az aktív CBE minden szolgáltató esetében az elsődleges CBC-ként megjelölt CBC-vel tart kapcsolatot. A CBE üzemeltető biztosítja, hogy valamennyi CBE rendszeres időközönként állapotjelző üzenet küldésével folyamatosan ellenőrizze minden szolgáltató esetében az összes CBC elérhetőségét és a fennálló kapcsolat működőképességét. Ha az elsődlegesen megjelölt CBC működésképtelen, a CBE a szolgáltató másik CBC-jének küldi meg az üzeneteket.
5. § (1) A CBE és a CBC közötti üzenet tartalma szerint
- a) riasztás,
- b) törlés,
- c) visszaigazolás,
- d) hibajelzés,
- e) állapotjelző vagy
- f) teszt
üzenet lehet.
(2) A riasztási tartalmú CAP üzenet tartalmazza legalább a CB üzenetet, a küldés időzítését, a CB üzenet szintjét, prioritását és érvényességi idejét, a CB célterületet, az üzenet és a küldő CBE egyedi azonosítóját.
(3) A törlést tartalmazó CAP üzenetben a CB célterületnek azonosnak kell lennie a törölni kívánt, egyedi azonosító alapján meghatározott eredeti – riasztást tartalmazó – CAP üzenetben meghatározott CB célterülettel. Törlést tartalmazó CAP üzenet esetén a CBC – a CBE-felé történő visszaigazolás üzenetküldést követően – a CB üzenet kiküldését haladéktalanul leállítja és naplózza.
(4) A CBE és a CBC közötti kommunikációt a CBE üzemeltető – a 3. § (6) bekezdésében meghatározott azonosítás után – riasztás vagy törlés tartalmú CAP üzenet küldésével kezdeményezi.
(5) A (4) bekezdés szerinti kezdeményezés esetén a CBC 3 percen belül
- a) visszaigazolást tartalmazó üzenetet küld a CBE-nek, ha az interfészen sikeresen és teljeskörűen fogadta a hitelesített CAP üzenetet, vagy
- b) hibajelzést tartalmazó üzenetet küld a CBE-nek, ha nem kapta meg teljeskörűen vagy hibátlanul, vagy ha nem tudta hitelesíteni, illetve értelmezni a CAP üzenetet.
(6) A szolgáltató saját döntése alapján nem módosíthatja, nem törölheti a CAP és a CB üzenetet. A CAP és a CB üzenet bármely elemének módosítása a CBE által küldött törlést tartalmazó CAP üzenet, majd új – riasztást tartalmazó – CAP üzenet küldése révén történik.
6. § (1) A szolgáltató a CB üzenetet a 4G LTE és 5G NSA (non standalone) technológián alapuló mobil rádiótelefon-hálózatán, valamint – ha a szolgáltató 5G SA (standalone) technológián alapuló mobil rádiótelefon-hálózatot használó előfizetőinek száma eléri az összes mobil rádiótelefon-szolgáltatást igénybe vevő előfizetőjének 5 %-át – 5G SA technológián alapuló mobil rádiótelefon-hálózatán is haladéktalanul kiküldi, ha az adott technológia a szolgáltató hálózatában a CB célterületen támogatott. Az 5G SA technológián alapuló mobil rádiótelefon-hálózatot használó előfizetők meghatározásakor figyelmen kívül kell hagyni azokat a mobil eszközöket, amelyekről nem lehet hívást kezdeményezni és fogadni.
(2) A szolgáltató biztosítja, hogy a CBC a CAP üzenetben foglalt adatok alapján automatikusan meghatározza, hogy a mobil rádiótelefon-hálózattal lefedett, a szolgáltató (1) bekezdés szerinti hálózatán belül mely bázisállomások mely celláin kell kisugározni a CB üzenetet a cellákhoz kapcsolódó mobil eszközökre.
(3) A CB célterületet lefedő bázisállomásokat és cellákat a szolgáltató úgy határozza meg, hogy a lehető legkisebb legyen a felesleges és az elmulasztott riasztás előfordulásának valószínűsége és a CB üzenettel ténylegesen elért terület ne legyen nagyobb, mint a CB célterület ellátását dominánsan biztosító cellák együttes ellátási területe.
(4) A szolgáltató által üzemeltetett CBC-nek alkalmasnak kell lennie arra, hogy a CBE általi igény esetén biztosítsa a CB üzenetek időzített vagy ismételt sugárzását, valamint arra, hogy egyidőben és akár ugyanazon CB célterületen több CB üzenet is érvényben legyen. Az egyszerre érvényben levő riasztások száma nem haladhatja meg a 12 darabot.
7. § (1) A szolgáltató az 5. § (5) bekezdés a) pontja szerinti esetben a CB üzenetet a CAP üzenetben meghatározott CB célterület valamennyi cellájába közel egyidejűleg küldi ki.
(2) Ha a CB üzenet – a CBC-be történő beérkezése után – nem küldhető ki részben vagy egészben, illetve azonnal a CAP üzenetben foglaltaknak megfelelően, akkor a szolgáltatónak az előzetesen megállapított eljárásrend szerinti technikai intézkedéseket kell meghoznia. A technikai intézkedésekkel összefüggő eljárásrendet a védelmi és biztonsági igazgatás központi szerve, a szolgáltatók és a CBE üzemeltető megállapodásban rögzítik. Az eljárásrendnek rendelkeznie kell az egyéb általános CBE és a CBC oldali üzemeltetési feladatok, folyamatok kezeléséről is.
(3) Ha a CB üzenet bármilyen ok miatt részben vagy egészben nem küldhető ki a CAP üzenetben foglaltaknak megfelelően, a szolgáltató biztosítja, hogy a CBC az esetleges törlés tartalmú CAP üzenetet is figyelembe véve – a lehető leghamarabb – kiküldje a ki nem küldött CB üzenetet a CAP üzenetben foglaltaknak megfelelően.
(4) A CBE és a CBC minden eseményt, hibát, tranzakciót automatikusan naplóz. A CBC-nek a CAP üzenet fogadásával, feldolgozásával, és a CB üzenet kiküldésével kapcsolatos minden releváns eseményt naplóznia kell. A szolgáltató biztosítja, hogy a CBC által készített naplóbejegyzések alkalmasak legyenek az eszközön végzett szolgáltatói tevékenységek utólagos nyomon követhetőségére is. A CBE üzemeltetőnek és a szolgáltatónak minden naplózott adatot – jogszabály eltérő rendelkezése hiányában – legalább 12 hónapig meg kell őriznie.
8. § A védelmi és biztonsági célú lakossági riasztási rendszer üzemeltetésével kapcsolatos, e rendeletben nem szabályozott műszaki követelményeket a védelmi és biztonsági igazgatás központi szerve, a szolgáltatók és a CBE üzemeltető együttműködési megállapodásban rögzítik.
9. § Ez a rendelet 2026. július 1. napján lép hatályba.
10. § Ez a rendelet az Európai Elektronikus Hírközlési Kódex létrehozásáról szóló, 2018. december 11-i (EU) 2018/1972 európai parlamenti és tanácsi irányelv 110. cikkének való megfelelést szolgálja.
Dr. Koltay András
a Nemzeti Média- és Hírközlési Hatóság elnöke
1. melléklet a …/2025. (… …) NMHH rendelethez
CBE, CBC adatátvitel műszaki alapkövetelményei
- Az OSI-modell 7. rétegén (alkalmazási réteg) a HTTPS protokollt kell alkalmazni az RFC 2818 szerint.
- A HTTPS titkosítását és hitelesítését a TLS1.2 (hosszú távon 1.3) protokoll biztosítja az RFC 8446 szabványnak megfelelően.
- A TCP-csomagokat az OSI 3. rétegén az IPv4 protokoll kezeli.
- A site-to-site VPN javasolt konfigurációs paraméterei az alábbiak:
- Peer IP Primary: a fizikai kapcsolat módjától függ
- Port: UDP/500; UDP/4500; IP 50 ESP
- VPN Product: a fizikai kapcsolat módjától függ
- IKE Policy: IKev2 Preferred
- Message Encryption algorithm: AES256
- Message integrity algorithm: SHA256
- Peer Authentication Method: PSK
- DH-Group: 14
- IKE Lifetime: 21600
- Mechanism for payload encryption: E S P
- ESP Transform: AES 256
- Data Integrity: S H A 256
- Security Association (SA) Lifetime :3600 (or less)
- Perfect Forwarding Secrecy (PFS): Group 14