A SZABÁLYZAT CÉLJA...

Átírás

1 x/2016. főigazgatói utasítás EESZT kezelési szabályzat v1.0 TARTALOMJEGYZÉK 1 A SZABÁLYZAT CÉLJA A SZABÁLYZAT HATÁLYA FELHASZNÁLHATÓSÁGI TERÜLET HATÁLY SZEMÉLYI HATÁLY TÁRGYI HATÁLY IDŐBELI HATÁLY FELELŐSSÉG MEGHATÁROZÁSA FOGALOM MEGHATÁROZÁSOK AZ EESZT-BEN ALKALMAZOTT TANÚSÍTVÁNYOK JELLEMZŐI EESZT-BEN ALKALMAZOTT TANÚSÍTVÁNYOK EESZT ÁLTAL KIADHATÓ TANÚSÍTVÁNYOK ÉS HIERARCHIÁJUK AZ EESZT TANÚSÍTVÁNYOK IGÉNYLÉSE ÉS ÁTADÁSA AZ EESZT ÁLTAL KIBOCSÁTOTT TANÚSÍTVÁNYOK JELLEMZŐ PAAS INFRASTRUKTÚRA ELEMEK SSL SZERVER TANÚSÍTVÁNY ÜZLETI MODULOK AZONOSÍTÁSI TANÚSÍTVÁNY CSATLAKOZÓ INTÉZMÉNYI AZONOSÍTÁSI TANÚSÍTVÁNY CSATLAKOZÓ INTÉZMÉNYEK VPN AZONOSÍTÁSI TANÚSÍTVÁNY A SZABÁLYZAT LEÍRÁSA TANÚSÍTVÁNY IGÉNYLÉSE TANÚSÍTVÁNY ELŐÁLLÍTÁSA TANÚSÍTVÁNY KIADÁSA TANÚSÍTVÁNY NYILVÁNTARTÁSA ÉS TÁROLÁSA TANÚSÍTVÁNY FELFÜGGESZTÉSE ÉS VISSZAVONÁSA MELLÉKLETEK, FÜGGELÉKEK MELLÉKLET MEGBÍZÁSI NYILATKOZAT MINTA MELLÉKLET TANÚSÍTVÁNY IGÉNYLŐLAP MINTA MELLÉKLET CRL ELŐÁLLÍTÁSI FOLYAMAT (AJÁNLÁS) BELSŐ TLS/SSL SZERVER TANÚSÍTVÁNY KÜLSŐ KAPCSOLATOKHOZ SZÜKSÉGES AUTENTIKÁCIÓS TANÚSÍTVÁNY SAML KÉRÉSHEZ HASZNÁLT MODUL AZONOSÍTÁSI TANÚSÍTVÁNY VPN KAPCSOLATOKHOZ SZÜKSÉGES AUTENTIKÁCIÓS TANÚSÍTVÁNY Törzsnyilvántartási szám: 49/2015. Oldal: 1/21

2 1 A SZABÁLYZAT CÉLJA Jelen szabályozás célja, hogy a vonatkozó jogszabályi előírások és az EESZT Informatikai Biztonsági Szabályzata (a továbbiakban EESZT IBSZ) alapján az Állami Egészségügyi Ellátó Központ (a továbbiakban ÁEEK) meghatározza az Egészségügyi Elektronikus Szolgáltatási Tér (a továbbiakban EESZT) rendszerben használatos ok kezelésére vonatkozó eljárásrendet (EESZT Tanúsítvány kezelési szabályzat vagy TAKESZ). Az eljárásrend a következő területeket szabályozza: a) Tanúsítványok igénylése b) Tanúsítványok előállítása c) Tanúsítványok kiadása d) Tanúsítványok nyilvántartása és tárolása e) Tanúsítványok felfüggesztése és visszavonása 2 A SZABÁLYZAT HATÁLYA 2.1 Felhasználhatósági terület hatály Az ÁEEK/ EESZT mint belső hitelesítő szolgáltató által kiadott ok csak EESZThez kapcsolódó elektronikus kommunikációs tevékenységhez: a) az EESZT-n belüli kommunikáció b) az EESZT-hez csatlakozott rendszerek és az EESZT közötti kommunikáció használhatók és csak az EESZT üzemeltető szervezettel szerződéses viszonyban álló cégnek, intézménynek adható ki. A felhasználók köre a következő szereplők közül kerül ki: a) Kötelezett és engedélyezett egészségügyi szolgáltatók b) Ágazatirányítási szervezetek c) EESZT fejlesztők d) HIS szállítók 2.2 Személyi hatály A Szabályzat személyi hatálya kiterjed az a) EESZT elektronikus információs rendszereinek felhasználóira, üzemeltetőire, fejlesztőire vagy egyéb módon alkalmazóira, továbbá b) az EESZT és pilot projekt megvalósítására az ÁEEK-val szerződéses kapcsolatban álló szoftver fejlesztő, tanácsadó, biztonsági auditot végző cégek és állami intézmények alkalmazottjaira, akik az EESZT informatikai rendszereit és a kapcsolódó informatikai rendszereket fejlesztik, tesztelik, üzemeltetik, vagy auditálják.

3 Biztosítani kell, hogy az érintett személyek a jelen Szabályzatot a szükséges mértékben megismerjék; 2.3 Tárgyi hatály A Szabályzat tárgyi hatálya kiterjed jelen szabályzat 2.1 es pontja által meghatározott felhasználók számára kiadott okra. 2.4 Időbeli hatály A szabályzat időbeli hatálya kiterjed a) az EESZT bevezetését előkészítő pilot projektekre és b) az éles rendszer üzemeltetési időszakra 3 FELELŐSSÉG MEGHATÁROZÁSA Jelen szabályzatban meghatározott tevékenységek előkészítésében és végrehajtásában az alábbi személyek illetékesek és felelősek: Szabályzat elkészítése és módosítása: a) EESZT informatikai biztonsági felelőse (EESZT IBF) b) Az EESZT elektronikus információs rendszer biztonságáért felelős személy (IBF) feladata, hogy jogszabályi, funkcionális, biztonsági, technológiai vagy egyéb változások bekövetkezése esetén elrendelje a szabályozás módosítását. Szabályzat jóváhagyása: a) ÁEEK főigazgató b) EESZT Üzemeltetési vezető c) ÁEEK Informatikai biztonsági felelős Szabályzatban foglaltak alkalmazása: a) EESZT IBF b) EESZT IBF megbízottja Szabályzat alkalmazásának ellenőrzése: a) az EESZT patnerkapcsolati vezető b) az EESZT üzemeltetési vezető c) az EESZT Informatikai biztonsági felelős (IBF) 4 FOGALOM MEGHATÁROZÁSOK Jelen szabályzatban használt fogalmak meghatározásai a következők: EESZT IBF megbízottja

4 Az EESZT IBF-nek az EESZT Fejlesztési és üzemeltetési főosztályvezető jóváhagyásával, írásban kijelölt megbízottja, aki a Tokenekkel kapcsolatos feladatok ellátásban teljes joggal helyettesíti az EESZT IBF-et. EESZT Tanúsítvány menedzsment szoftver A Tanúsítvány generálása, a ok és visszavonási listák nyilvántartásával kapcsolatos a adminisztrációs és on-line ellenőrzési funkciók elvégzésére rendszeresített szoftver. Intézményi megbízott A Tokenek és Tanúsítványok igénylésével kapcsolatos ügyekben eljáró kapcsolattartó, akit az igénylő vállalat vagy intézmény vezetője jelöli ki és látja el a 1. Mellékletben meghatározott meghatalmazással

5 5 Az EESZT-ben alkalmazott ok jellemzői 5.1 EESZT-ben alkalmazott ok Az 5-ös biztonsági besorolású EESZT az információs csatornák védelme érdekében valamint egyes felhasználók azonosítására különböző típusú elektronikus okat használ, amelyek a kibocsátó szerint 2 csoportba sorolhatók: Minősített hitelesítés szolgáltató által kibocsátott ok Az ÁEEK, mint az EESZT belső hitelesítés szolgáltatója által kibocsátott ok Az EESZT-ben használatos okat a következő táblázat foglalja össze: A megnevezése A típusa Hitelesítés szolgáltató Megjegyzés EESZT wildcard szerver azonosító Wildcard SSL szerver Minősített hitelesítő szolgáltató Az EESZT azonosítására szolgál a külvilág felé (portál és HIS webszolgáltatások) EESZT Root CA Belső CA ÁEEK EESZT Az EESZT mint belső EESZT hitelesítés szolgáltató saját a. A Subordinate CA ok és a PaaS infrastruktúra elemek szerver ainak kibocsátásához használjuk EESZT Subordinate vagy subca ok a DEV, UAT, TST és PROD környezetkhez Belső subca ÁEEK EESZT A DEV, UAT, TST és PROD környezetekhez szükséges EESZT ok kibocsátásához szükséges. PaaS infrastruktúra elemek SSL szerver SSL szerver ÁEEK EESZT Az EESZT PaaS infrastruktúra elemek közötti biztonságos SSL kommunikációhoz (HTTPS, LDAPS,..) szükségesek. A szerver oldalon használjuk EESZT SaaS alkalmazás modulok közti kommunikációhoz használt azonosítási Azonosítási ÁEEK EESZT Az EESZT SaaS alkalmazás modulok közötti biztonságos kommunikációhoz szükségesek. A kliens oldalon használjuk SAML jegyek kéréséhez.

6 Személyes találkozás során kibocsátott azonosítási (autentikációs) az EESZT-hez csatlakozó intézmények számára Személyes találkozás során kibocsátott azonosítási szükséges Minősített hitelesítő szolgáltató Csatlakozó intézmények és az EESZT közötti kommunikációban, a rendszerek, mint intézményi felhasználók, azonosításához szükséges. A pilot időszakban 3 hónapos teszt t is elfogad az EESZT SSL kiens azonosítási az EESZT-hez csatlakozó intézmények számára Azonosításitanúsítv ány ÁEEK EESZT Csatlakozó intézmények és az EESZT közötti SSL kommunikációban használjuk a kliens oldal azonosítására VPN azonosítási intézmények számára DK-TK modul és a PACS modulok közötti kommunikációhoz Azonosítási ÁEEK EESZT Az IPSec alapú VPN kommunikációban a kliens oldal azonosítására használjuk Az EESZT-ben négy környezetet különböztetünk meg és minden környezet eléréséhez külön készlet szükséges: Környezet Hozzáférés Megjegyzés Fejlesztő környezet (DEV) UAT teszt környezet (UAT) Általános teszt környezet (TST) Éles (produktív) környezet (PROD) HIS szállítók Iparági irányító intézmények HIS szállítók Iparági irányító intézmények Eü szolgáltató intézmények Iparági irányító intézmények Eü szolgáltató intézmények Iparági irányító intézmények 5.2 EESZT által kiadható ok és hierarchiájuk Az ÁEEK mint az EESZT belső hitelesítés szolgáltatója, két szintű láncot használ: a) RootCA, amely az egyes EESZT környezetek (jelenleg négy) önálló, egymástól független ait kibocsátó Subordinate vagy subca-k ait tanúsítja az EESZT-n belül, a PaaS infrastruktúra elemek közötti kommunikációban használt SSL szerver okat tanúsítja

7 b) Subordinate vagy subca-k, amelyek a négy EESZT környezetben szükséges okat tanúsítják: az EESZT modulok közötti kommunikációhoz szükséges azonosítási ok az EESZT-hez csatlakozó intézmények számára szükséges személyes találkozó során kibocsátott azonosítási ok az EESZT-hez csatlakozó intézmények számára szükséges VPN azonosítási ok 5.3 Az EESZT ok igénylése és átadása A ok két módon igényelhetők: 1. Az igénylő intézmény elektronikus űrlapon küldi el a kért hoz szükséges adatokat. 2. Az igénylő az intézmény igénylőt (CSR) küld. Ebben az esetben az EESZT belső hitelesítés szolgáltató az igénylő által erre a célra készített t (Certificate Signing Request, CSR) írja alá. Amennyiben az igénylő intézmény a CSR-t maga állítja elő, abban a 3.4 pontban ismertetett paraméter adatoknak kell szerepelniük. A CSR előállítási folyamatát, az egyes ok esetén megadandó paramétereket és a CSR elkészítésére vonatkozó ajánlásokat a 3. Melléklet tartalmazza. Az elkészített ok az EESZT jelszóval ellátott PFX típusú (PKCS#12) KeyStore file-ban adja át az igénylőnek. A PFX file amennyiben a felhasználó eszközök igénylik - más tároló típussá transzformálható. A okat az AEEK/EESZT -ben, a kapcsolódó jelszót pedig SMS-ben küldi el az igénylőnek. A vírusvédelmi eszközök (pl. MS Outlook használatakor) általában nem engedik meg a ok csomagolás nélküli továbbítását -ben, ezért az EESZT ZIP-be csomagolva, a ZIP kibontó jelszót az ben mellékelve küldi meg a PFX file-t az igénylőnek. 5.4 Az EESZT által kibocsátott ok jellemző PaaS infrastruktúra elemek SSL szerver Az EESZT PaaS infrastruktúra elemek közötti biztonságos SSL kommunikációban (HTTPS, LDAPS,...) használatos szerver oldali. a) Adatlapos igénylés Az EESZT kezelő program által generáláskor használt default paraméterek:

8 Mező Mező hivatalos Mező tartalma megnevezése A kulcs típusa Key type RSA A kulcs hossza Key length 2048 Visszavonási lista URL CRL Distribution Point Nem kell megadni Aláírás algoritmusa Signature Algorithm SHA-256 RSA Kulcs használat Key Usage Digital Signature, Key Encipherment Kiterjesztett kulcs Extended Key Usage TLS server authentication (OID: ) használat Verzió Version 3 Érvényesség Validitíy 10 év A kéréséhez az elektronikus igénylő lapon (2. Melléklet) a következő paramétereket kell megadni: Mező Mező hivatalos megnevezése Mező tartalma Hivatalos mezők Rendszer név Common name (CN) Rendszer név fully qualified domain name formában Szervezeti egység Organizational unit (OU) EESZT_[környezet]_SSL Szervezet Organization (O) AEEK Város Town (city) (L) Budapest Alternatív rendszer név Subject alternative name DNS név vagy IP cím (SAN) Megye State (province) (ST) Budapest Ország Country (C) HU Nem hivatalos mezők EESZT környezet Nem hivatalos mező DEV, UAT, TST, PROD közül az igényelt Tanúsítvány típusa Nem hivatalos mező SSL b) CSR alapú kibocsátás CSR (Certificate Signing Request) alapú ügyfél igénylésnél a generálását a fenti 2 táblázat paramérei szerint kell elvégezni (lásd részletesen a 3. Mellékletben) Üzleti modulok azonosítási Az EESZT SaaS alkalmazás modulok közötti biztonságos kommunikációban használjuk a kliens oldalon SAML jegyek igényléshez. a) Adatlapos igénylés Az EESZT kezelő program által generáláskor használt default paraméterek: Mező Mező hivatalos Mező tartalma megnevezése A kulcs típusa Key type RSA A kulcs hossza Key length 2048 Visszavonási lista URL CRL Distribution Point A megfelelő környezet visszavonási listájára kell mutat, pl.: Aláírás algoritmusa Signature Algorithm SHA-256 RSA Kulcs használat Key Usage Digital Signature, Key Encipherment Kiterjesztett kulcs Extended Key Usage TLS client authentication (OID: ) használat

9 Verzió Version 3 Érvényesség Validitíy 10 év A kéréséhez az elektronikus igénylő lapon (2. Melléklet) a következő paramétereket kell megadni: Mező Mező hivatalos megnevezése Mező tartalma Hivatalos mezők Rendszer név Common name (CN) Rendszer név Szervezeti egység Organizational unit (OU) EESZT_[környezet]_AUTH Szervezet Organization (O) ÁEEK Város Town (city) (L) Budapest Alternatív rendszer név Subject alternative name Nem kell megadni (SAN) Megye State (province) (ST) Budapest Ország Country (C) HU Nem hivatalos mezők EESZT környezet Nem hivatalos mező DEV, UAT, TST, PROD közül az igényelt Tanúsítvány típusa Nem hivatalos mező AUTH b) CSR alapú kibocsátás CSR (Certificate Signing Request) alapú ügyfél igénylésnél a generálását a fenti 2 táblázat paramérei szerint kell elvégezni (lásd részletesen a 3. Mellékletben) Csatlakozó intézményi azonosítási A csatlakozó intézmény és az EESZT interfésze végpontja közötti SSL csatorna felépítése során a csatlakozó kliens azonosítására szolgál. a) Adatlapos igénylés Az EESZT kezelő program által generáláskor használt default paraméterek: Mező Mező hivatalos Mező tartalma megnevezése A kulcs típusa Key type RSA A kulcs hossza Key length 2048 Visszavonási lista URL CRL Distribution Point A megfelelő környezet visszavonási listájára kell mutat, pl.: Aláírás algoritmusa Signature Algorithm SHA-256 RSA Kulcs használat Key Usage Digital Signature, Key Encipherment Kiterjesztett kulcs Extended Key Usage TLS client authentication (OID: ) használat Verzió Version 3 Érvényesség Validitíy 1 év A kéréséhez az igénylő által az elektronikus űrlapon megadandó paraméterek: Mező Mező hivatalos megnevezése Hivatalos mezők Mező tartalma

10 Rendszer név Common name (CN) Rendszer név Szervezeti egység Organizational unit (OU) EESZT_[környezet]_AUTH Szervezet Organization (O) Az intézmény neve Város Town (city) (L) Az intézmény székhelye (város) Alternatív rendszer név Subject alternative name Nem kell megadni (SAN) Megye State (province) (ST) Megye (nem kötelező) Ország Country (C) HU Nem hivatalos mezők EESZT környezet Nem hivatalos mező DEV, UAT, TST, PROD közül az igényelt Tanúsítvány típusa Nem hivatalos mező AUTH b) CSR alapú kibocsátás CSR (Certificate Signing Request) alapú ügyfél igénylésnél a generálását a fenti 2 táblázat paramérei szerint kell elvégezni (lásd részletesen a 3. Mellékletben) Csatlakozó intézmények VPN azonosítási Az IPSec alapú VPN kommunikáció felépítése során a kliens oldal azonosítására használjuk. a) Adatlapos igénylés Az EESZT kezelő program által generáláskor használt default paraméterek: Mező Mező hivatalos Mező tartalma megnevezése A kulcs típusa Key type RSA A kulcs hossza Key length 2048 Visszavonási lista URL CRL Distribution Point A megfelelő környezet visszavonási listájára kell mutat, pl.: Aláírás algoritmusa Signature Algorithm SHA-256 RSA Kulcs használat Key Usage Digital Signature, Key Encipherment Kiterjesztett kulcs Extended Key Usage TLS client authentication (OID: ) használat Verzió Version 3 Érvényesség Validitíy 1év A kéréséhez az igénylő által az elektronikus űrlapon megadandó paraméterek: Mező Mező hivatalos Mező tartalma megnevezése Hivatalos mezők Rendszer név Common name (CN) Intézményi router publikus IP címe illetve az intézmény környezet szerinti CGNAT IP címe abban az esetben, ha a CSR-t nem tudja az intézmény úgy

11 generálni, hogy a SAN mezőben a CGNAT cím legyen. Szervezeti egység Organizational unit (OU) EESZT_[környezet]_VPN Szervezet Organization (O) Az intézmény neve Város Town (city) (L) Az intézmény székhelye Alternatív rendszer név Subject alternative name (SAN) Megye State (province) (ST) Megye megnevezése Ország Country (C) HU A kulcs típusa Key type RSA Az Intézmény ÁEEK által kiadott CGNAT-IP címe. A kormányzati felhő tűzfala ez alapján azonosítja a VPN kapcsolatot. Nem hivatalos mezők EESZT környezet Nem hivatalos mező DEV, UAT, TST, PROD közül az igényelt Tanúsítvány típusa Nem hivatalos mező VPN b) CSR alapú kibocsátás CSR (Certificate Signing Request) alapú ügyfél igénylésnél a generálását a fenti 2 táblázat paramérei szerint kell elvégezni (lásd részletesen a 3. Mellékletben)

12 6 A SZABÁLYZAT LEÍRÁSA A fejezet ismerteti a szabályzat keretében kiadható ok teljes életciklusára vonatkozó szabályozást. A szabályzat hatályát jelentő EESZT pilot időszakban a okkal kapcsolatos műveletek az EESZT IBF és/vagy megbízottja végzi. 6.1 Tanúsítvány igénylése Tanúsítványokat igényelhetnek a) Az EESZT-n belül használható ok az ÁEEK pilotban résztvevő, erre feljogosított munkatársai az EESZT fejlesztésében részvevő, az ÁEEK-val szerződéses kapcsolatban álló cégek erre feljogosított munkatársai b) Külső EESZT csatlakozáshoz szükséges ok az EESZT pilot projekt megvalósítására az ÁEEK-val szerződéses kapcsolatban álló szoftverfejlesztő, egészségügyi szolgáltató és egészségügyi irányító intézmények kérhetnek kapcsolattartójukon Intézményi megbízott- keresztül. Az intézményi megbízottaknak hivatalos meghatalmazásukat a 1. Mellékletben található megbízási nyilatkozat, cégszerűen aláírt változatának személyes átadásával kell igazolniuk. A megbízási nyilatkozat átadójának a törvényes igazoló okmányok valamelyikével igazolni kell személyazonoságát A megbízási nyilatkozatot az AEEK-nak 5 évig meg kell őriznie A igénylésére jogosultakat regisztrálni kell az EESZ Tanúsítványkezelő rendszerében. A t a regisztrált, igénylésre jogosultak kérhetnek a következő két eljárás valamelyikével: 1. Az igénylő elektronikus űrlapokon küldi el a kért hoz szükséges adatokat. Az űrlap tartalmát a 2. Melléklet mutatja be. Az egyes igényelhető típusok paramétereit a 3. Fejezet mutatja be. 2. Elektronikus igénylő (CSR) küldésével. Ebben az esetben az ÁEEK mint EESZT belső hitelesítési szolgáltató, az igénylő által az erre a célra készített t (Certificate Signing Request, CSR) írja alá a tanúsításhoz szükséges környezet subca kulcsával. Amennyiben az igénylő intézmény a CSR-t maga állítja elő, azt a 3. Fejezetben ismertetett paraméterekkel kell létrehozni. A CSR igénylő oldali előállítására vonatkozó ajánlást az egyes ok esetén megadandó paraméterekkel a 3. Melléklet tartalmazza. A igénylő elektronikus űrlapot vagy a CSR-t az -ben kell eljuttatni az EESZT IBF nek vagy EESZT IBF megbízottjának a következő címre:

13 Tanúsítvány kezelési kontakt pont: Telefon: Tanúsítvány előállítása A ok generálását és/vagy aláírását (tanúsítását) az EESZT kezelő rendszerével kell elvégezni. 6.3 Tanúsítvány kiadása Az EESZT az elkészített/aláírt t jelszóval ellátott PFX típusú (PKCS#12) KeyStore file-ban adja át az igénylőnek. A PFX file amennyiben a felhasználó eszközök igénylik - más tároló típussá transzformálható. A okat az EESZT -ben, a kapcsolódó jelszót pedig SMS-ben küldi el a) az Az EESZT-n belül használható ok esetén közvetlenül az igénylő munkatársnak b) Külső EESZT csatlakozáshoz szükséges ok esetén az igénylő intézmény megbízottjának. A vírusvédelmi eszközök (pl. MS Outlook használatakor) általában nem engedik meg a ok csomagolás nélküli továbbítását -ben, ezért az EESZT a PFX-filet ZIP-be csomagolva, a ZIP kibontó jelszót az ben mellékelve küldi meg az igénylőnek. 6.4 Tanúsítvány nyilvántartása és tárolása A ok nyilvántartása az EESZT Tanúsítványkezelő szoftver segítségével történik. A nyilvántartás magába foglalja az érvényes kiadott ok és a visszavonási listák nyilvántartásának naprakész vezetését. A EESZT Tanúsítványkezelő alkalmazás a NISZ-ben van telepítve. A szoftver adatbázisát rendszeresen menteni kell az EESZT mentési és visszaállítási szabályzata szerint a NISZ-ben elhelyezett tárolóra. A RootCA és az egyes környezetek tanúsítását végző subca-k ait külön lemezen páncélszekrényben kell tárolni. 6.5 Tanúsítvány felfüggesztése és visszavonása Kompromittálódott t az EESZT-vel szerződéses kapcsolatban álló intézményeknek hivatalos kapcsolattartójukon, az intézményi megbízotton, keresztül azonnal be kell jelenteni: EESZT Helpdesk Telefon: xxxx helpdesk@eeszt.aeek.hu Tanúsítvány kezelési kontakt pont Telefon: tanusitvany@eeszt.aeek.hu

14 A kompromittálódott t az EESZT üzemeltetés visszavonja. A visszavont helyett az új az 5.1 pontban leírtak szerint lehet igényelni. Amennyiben az EESZT üzemeltetés egy esetében kompromittálódásra utaló biztonsági eseményeket tapasztal, saját hatáskörében dönthet a felfüggesztéséről és/vagy visszavonásáról. Felfüggesztés vagy visszavonás esetén az EESZT üzemeltetés ben értesíti a felhasználóját.

15 7 MELLÉKLETEK, FÜGGELÉKEK Jelen Szabályzat 3. Mellékletet tartalmaz. 1. Melléklet Megbízási nyilatkozat minta MEGBÍZÁSI NYILATKOZAT Alulírott. (név),.(beosztás), mint a......intézmény/vállalat feljogosított vezetője megbízom...(név),...(születési hely, idő)...(anyja neve),...(üzleti mobil telefonszám)..., (üzleti cím) munkavállalónkat / szerződéses partnerünket (a megfelelőt kérjük aláhúzni) hogy intézményünk nevében az EESZT pilot projekthez szükséges Tanúsítványok igénylésével és átvételével kapcsolatos feladatokat a kibocsátó Állami Egészségügyi Ellátó Központ Tanúsítvány kezelési szabályzatának megfelelően, intézményünk nevében felelősen ellássa. dátum, Név, Cégszerű aláírás

16 2. Melléklet Tanúsítvány igénylőlap minta TANÚSÍTVÁNY IGÉNYLŐLAP Mező Mező hivatalos Mező tartalma megnevezése Hivatalos mezők Rendszer név Common name (CN) SSL: Rendszer név fully qualified domain name formában AUTH: Rendszer vagy személy név VPN: Intézményi router publikus IP címe (lásd részletesen a VPN kapcsolatok beállítása dokumentumot) Szervezeti egység Organizational unit (OU) EESZT_[környezet] _[típus] Szervezet Organization (O) Az intézmény neve Város Town (city) (L) Az intézmény székhelye (város) Alternatív rendszer név Subject alternative name (SAN) Megye State (province) (ST) Megye (nem kötelező) Ország Country (C) HU SSL: DNS név vagy IP cím AUTH: Nem kell megadni VPN: Az Intézmény ÁEEK által kiadott CGNAT-IP címe (Lásd részletesen a VPN kapcsolatok beállítása dokumentumot) Nem hivatalos mezők EESZT környezet Nem hivatalos mező DEV, UAT, TST, PROD közül az igényelt Tanúsítvány típusa Nem hivatalos mező AUTH, SSL, VPN közül az igényelt Kapcsolattartó neve Nem hivatalos mező Kapcsolattartó mobil Nem hivatalos mező telefon szám Kapcsolattartó Nem hivatalos mező Dátum,

17 3. Melléklet CRL előállítási folyamat (ajánlás) 3.1. Belső TLS/SSL szerver Felhasználása: o Az infrastruktúra belső komponensei közti biztonságos kommunikációhoz (HTTPS, LDAPS stb.) használjuk szerver oldalon. Típusa: o 2048 bites RSA kulcsos TLS szerver autentikációhoz Tanúsító CA: o EESZT Infrastructure CA Generálás: o Egy új Java JKS vagy PKCS#12 (.p12 vagy.pfx) típusú KeyStore-ba beimportálom a CA át Trusted Certificate-ként. A KeyStore típusa az azt felhasználó konkrét komponens igényétől függ (pl. az ADC-be.pfx kiterjesztésű PKCS#12 kulcsot lehet beimportálni), illetve a JKS-nél külön-külön jelszóval lehet védeni a kulcstárat és benne lévő privát kulcsot is. A.pfx kulcstár formátum más formátumú tárakra konvertálható át. o Generáljunk egy 2048-bites RSA kulcspáros t a következő paraméterekkel: Típusa: Version 3 Aláírás algoritmusa: SHA-256 RSA Érvényesség: 10 év DN kitöltése: CN: a szolgáltatás eléréséhez használt esetleg virtuális fully qualified domain name(fqdn), pl. aek-t-lrayap1-a.eeszt.local, t-wosb.eeszt.local, t-a-osb1.eeszt.local, liferay01a-gyp.eeszt.local stb.) OU: EESZT_[környezet] _SSL O: AEEK L: Budapest ST: Budapest C: HU Beállítandó kiterjesztések: Extended Key Usage ( ) o TLS server authentication ( ) Key Usage ( ) o Digital Signature o Key Encipherment Subject Alternative Name ( ) o DNS Name: a CN-beli FQDN o o o DNS Name: a rövid név (pl. t-w-osb) DNS Name: az UAT környezet komponenseinél a régebbi elnevezések is (pl. liferay01a-gyp ill. liferay01agyp.eeszt.local) Készítsünk egy CSR-t az előző lépésben generált ról: Formátum: PKCS#10 Aláírás algoritmusa: SHA-256 RSA Fontos a beállított Extension-ök CSR-be történő beemelése! A CSR-t az EESZT Infrastructure CA által kell tanúsíttatni CRL nem kell a ba. A CA által aláírt t be kell importálni a generált hoz, majd a megfelelő komponensre fel kell tölteni és be kell konfigurálni a használatát.

18

19 3.2. Külső kapcsolatokhoz szükséges autentikációs Felhasználása: o Az EESZT egyes környezeteiből kiajánlott interfészek külső eléréséhez használjuk kliens oldalon. Típusa: o 2048 bites RSA kulcsos TLS kliens autentikációhoz Tanúsító CA: o A megfelelő környezet EESZT subca-ja (pl. EESZT DEV CA), valamint az azt tanúsító EESZT Infrastructure CA Generálás: o Egy új JKS vagy PKCS#12 (.p12 vagy.pfx) típusú KeyStore-ba beimportálom az EESZT Infrastructure CA és a megfelelő környezet EESZT subca (pl. EESZT DEV CA) át Trusted Certificate-ként. o Generáljunk egy 2048-betes RSA kulcspáros t a következő paraméterekkel: típusa: Version 3 Aláírás algoritmusa: SHA-256 RSA Érvényesség: 1 év DN kitöltése: A kliens azonosításához szükséges adatok CN: rendszer név SUN: nem kell megadni OU: EESZT_[környezet] _AUTH O: AEEK L: Budapest ST: Budapest C: HU Beállítandó kiterjesztések: Extended Key Usage ( ) o TLS client authentication ( ) Key Usage ( ) o Digital Signature o Key Encipherment o Készítsünk egy CSR-t az előző lépésben generált ról: Formátum: PKCS#10 Aláírás algoritmusa: SHA-256 RSA Fontos a beállított Extension-ök CSR-be történő beemelése! A CSR-t a megfelelő környezet EESZT subca-ja által kell tanúsíttatni. CRL-t is kell beletenni, melynek a megfelelő környezet visszavonási listájára kell mutatnia! o pl.: A CA által aláírt t be kell importálni a generált hoz, majd a megfelelő komponensre fel kell tölteni és be kell konfigurálni a használatát.

20 3.3. SAML kéréshez használt modul azonosítási Felhasználása: o Az EESZT egyes környezeteiben a modulok által történő SAML kéréshez használjuk kliens oldalon. Típusa: o 2048 bites RSA kulcsos TLS kliens autentikációhoz Tanúsító CA: o A megfelelő környezet EESZT subca-ja (pl. EESZT DEV CA), valamint az azt tanúsító EESZT Infrastructure CA Generálás: o Egy új Java (JKS) vagy PKCS#12 (.p12 vagy.pfx) típusú KeyStore-ba beimportálom az EESZT Infrastructure CA és a megfelelő környezet EESZT subca (pl. EESZT DEV CA) át Trusted Certificate-ként. o Generáljunk egy 2048-bites RSA kulcspáros t a következő paraméterekkel: Típusa: Version 3 Aláírás algoritmusa: SHA-256 RSA Érvényesség: 1 év DN kitöltése: A kliens azonosításához szükséges adatok CN: rendszer név SUN? Nem kell megadni OU: EESZT_[környezet] _AUTH O: Az intézmény neve L: Az intézmény szekhelye (város) ST: Megye (nem kötelező) C: HU Beállítandó kiterjesztések: Extended Key Usage ( ) o TLS client authentication ( ) Key Usage ( ) o Digital Signature o Key Encipherment o Készítsünk egy CSR-t az előző lépésben generált ról: Formátum: PKCS#10 Aláírás algoritmusa: SHA-256 RSA Fontos a beállított Extension-ök CSR-be történő beemelése! A CSR-t a megfelelő környezet EESZT subca-ja által kell tanúsíttatni. CRL-t is kell beletenni, melynek a megfelelő környezet visszavonási listájára kell mutatnia! o pl.: -A CA által aláírt t be kell importálni a generált hoz, majd a megfelelő komponensre fel kell tölteni és be kell konfigurálni a használatát.

21 3.4. VPN kapcsolatokhoz szükséges autentikációs Felhasználása: o Az EESZT DK-TK és a PACS rendszerek közötti VPN kommunikációban használjuk a a kliens oldal azonosításához. Típusa: o 2048 bites RSA kulcsos TLS kliens autentikációhoz Tanúsító CA: o A megfelelő környezet EESZT subca-ja (pl. EESZT DEV CA), valamint az azt tanúsító EESZT Infrastructure CA Generálás: o Egy új Java JKS vagy PKCS#12 (.p12 vagy.pfx) típusú KeyStore-ba beimportálom az EESZT Infrastructure CA és a megfelelő környezet EESZT subca (pl. EESZT DEV CA) át Trusted Certificate-ként. o Generáljunk egy 2048-betes RSA kulcspáros t a következő paraméterekkel: típusa: Version 3 Aláírás algoritmusa: SHA-256 RSA Érvényesség: 1 év DN kitöltése: A kliens azonosításához szükséges adatok CN: Intézményi router publikus IP címe illetve az intézmény környezet szerinti CGNAT IP címe abban az esetben, ha a CSR-t nem tudja az intézmény úgy generálni, hogy a SAN mezőben a CGNAT cím legyen a OU: Az EESZT megfelelő környezete: EESZT [környezet]_vpn O: Az Intézmény neve L: Az Intézmény székhelye SAN (subject alternative name): Az Intézmény ÁEEK által kiadott CGNAT-IP címe. A kormányzati felhő tűzfala ez alapján azonosítja a VPN kapcsolatot. ST: Megye, ahol az intézmény hivatalos központja található. Budapest esetén a megye Budapest. C: ország: HU Beállítandó kiterjesztések: Extended Key Usage ( ) o TLS client authentication ( ) Key Usage ( ) o Digital Signature o Key Encipherment o Készítsünk egy CSR-t az előző lépésben generált ról: Formátum: PKCS#10 Aláírás algoritmusa: SHA-256 RSA Fontos a beállított Extension-ök CSR-be történő beemelése! A CSR-t a megfelelő környezet EESZT subca-ja által kell tanúsíttatni. CRL-t is kell beletenni, melynek a megfelelő környezet visszavonási listájára kell mutatnia! o pl.: A CA által aláírt t be kell importálni a generált hoz, majd a megfelelő komponensre fel kell tölteni és be kell konfigurálni a használatát.