Módosítások

HREF műszaki előírások

11 371 bájt törölve, 2017. május 29., 13:56
a
3. Üzemeltetési kérdések: typo
{{TRASH|A dokumentum aktuális verziója célja, hogy a [[HREFContract]] oldalról érhető elHREF Föderációhoz csatlakozó Tagok és Partnerek számára elvárásokat és ajánlásokat fogalmazzon meg, melyek a csatlakozáshoz szükséges identitás-menedzsment, valamint üzemeltetési területeket fednek le.}}
A dokumentumban a '''KÖTELEZŐ''', '''TILOS''', '''AJÁNLOTT''', '''NEM AJÁNLOTT''' kifejezések értelmezése az alábbiak szerinti:
* '''KÖTELEZŐ''' (ill. '''"KÖTELES"''', '''"kell"''') jelentése: a pontban leírtak betartása a föderációba vetett bizalom kiépítéséhez és megtartásához elengedhetetlenül szükségesek, ettől a résztvevők nem térhetnek el;
= Jelen dokumentum célja =A dokumentum célja* '''TILOS''' jelentése KÖTELEZŐ NEM, hogy azaz a [[HREFGlossary#HREF Föderáció|HREF Föderációhoz]] csatlakozó [[HREFGlossary#Tag|Tagok]] és [[HREFGlossary#Partner|Partnerek]] számára elvárásokat és ajánlásokat fogalmazzon meg, melyek a csatlakozáshoz szükséges általános üzemeltetési és identitás-menedzsment területeket fednek le. Ezen elvárások és ajánlások a föderációba vetett bizalom kiépítéséhez és megtartásához elengedhetetlenül szükségesek.pontban leírtak szerint az intézmény nem járhat el;
A HREF Föderációhoz csatlakozó Tagok és Partnerek a csatlakozással magukra nézve kötelező érvényűként elfogadják * az alább leírtakat. Az '''ajánlottAJÁNLOTT''' eljárásoktól pontoktól való eltérés indokolt esetben lehetséges, de minden eltérést eltéréseket az intézmények dokumentálni szükséges.= Identitás-menedzsment =Jelen fejezet összefoglalja az intézményen belüli felhasználókezelésre vonatkozó előírásokatkötelesek. A felhasználókezelés magában foglalja a
* felhasználói accountok létrehozását,* ezen accountok folyamatos ellenőrzését és naprakészen tartását,* '''NEM AJÁNLOTT''' jelentése: amennyiben az intézmény a felhasználó távozása után a felhasználói adatok törlésétpontban leírtak szerint jár el,* az adatok védelmét illetéktelen behatolással szembenezt dokumentálni köteles.
Az intézmények '''kötelesek''' az alkalmazott felhasználókezelési elveiket dokumentálni, és a működést ezen dokumentáció alapján rendszeresen (legalább évente egyszer) ellenőrizni, szükség esetén a dokumentációt frissíteni.
== Adatforrások ==
A felhasználói adatok több helyről származhatnak:
* személyes felvétel,* egyéb autoritatív adatbázis (tanulmányi, munkaügyi rendszer)== 1.Identitás-menedzsment ==
Amennyiben egy :1.1. Az intézmény külsőköteles adatkezelési elveit dokumentálni, független adatbázist használ az IdP adatbázisának feltöltésére, '''köteles''' azt a következő kritériumokat betartani:felhasználókkal megismertetni.
* az adatforrásként szolgáló rendszer naprakész adatokat tartalmaz:1.2. Az intézmény köteles a felhasználóiról általa ismert adatok forrását,* az IdP adatbázisban szereplő felhasználók rendszeresen szinkronizálásra kerülnek az autoritatív adatbázissalkarbantartásának módját,* illetve ezen adatok becsült adatminőségét dokumentálni, és igény esetén ezt a hiteles adatforrásból kikerülő felhasználókat törölni '''kell''' az IdP adatbázisából is.== Hitelesítési policy =='''Tilos''' egy természetes személyhez több felhasználói bejegyzést rendelni. Gondoskodni '''kell''' dokumentációt a felhasználónevek egyediségéről, újrakiosztásuknak megakadályozásáról isföderáció tagjainak rendelkezésére bocsátani.
A felhasználói account hitelesítésekor '''ajánlott''' az account tulajdonosát személyesen azonosítani, személyi igazolvány, vagy egyéb hivatalos okmány segítségével:1. '''Ajánlott''' továbbá a természetes azonosítókat (név, anyja neve, születési hely és idő), illetve a postai elérhetőséget 3. Kötelező a hivatalos okmányokon szereplő adatokkal egyeztetnifelhasználónevek egyediségét biztosítani.
Amennyiben a felhasználók nem közvetlenül kerülnek rögzítésre az IdP adatbázisába, hanem külső adatforrásból, ezen azonosítási feladatok a külső adatforrás karbantartóját (pl:1. tanulmányi rendszer) terhelik4.=== Teszt felhasználók és szerep felhasználók ===Az ún. szerep felhasználók (dékán, gazdaságis, adminisztrátor, ...) használata '''tilos'''Egy természetes személyhez nem ajánlott több felhasználói azonosítót rendelni.
''':1.5. Nem ajánlott''', de bizonyos megkötésekkel lehetséges teszt szerep felhasználók létrehozása, de ezeket egyértelműen azonosítani és dokumentálni '''kell''', különös tekintettel arra, hogy mely munkatárs felelős az adott teszt bejegyzésért. A teszt felhasználókat csak tesztelésre szabad felhasználni(dékán, azokkal valós tranzakciókat kezdeményezni '''tilos'''igazgató) használata.
A [[HREFAttributeSpec#schacHomeOrganizationType|schacHomeOrganizationType]] attribútumban a teszt felhasználóknál '''kötelező''' a <code>urn:schac1.6. Attribútumok használata:homeOrganizationType:hu:test</code> értéket szerepeltetni, és ezt minden SP felé kiadni (függetlenül attól, hogy az adott SP kérte-e ezt az attribútumot, avagy sem).
::1.6.1. A teszt felhasználók jelszavát '''ajánlott''' gyakran cserélni.megvalósított attribútumokat az IdP-nek az Attribútum Specifikációban leírt módon kell megvalósítani;
== Jelszavak kiosztása és karbantartása ==::1.6.2. Az IdP adatbázisbejegyzéseihez tartozó jelszavakat '''tilos''' hitelesítetlen vagy titkosítatlan csatornán továbbítani bármely két rendszer között, például elektronikus levélben elküldeni, titkosítatlan kapcsolaton a felhasználótól bekérni. Ugyancsak biztosítani '''kell''' a jelszót tároló adatbázis és -nek kötelező megvalósítania az IdP között a kölcsönösen hitelesített és titkosított csatornát.alábbi attribútumokat:::* eduPersonTargetedID::* eduPersonPrincipalName::* eduPersonScopedAffialiation
A felhasználói accountokhoz tartozó jelszavakat '''ajánlott''' személyesen, vagy egyéb, nem elektronikus módon kiosztani (pl::1. postai úton)6. Lehetőség van arra, hogy a felhasználó saját maga állítsa be jelszavát, ha technikailag a felhasználó biztonságos azonosítása lehetséges (pl. a tanulmányi rendszerben tárolt jelszó segítségével)3.Az IdP-nek ajánlott megvalósítania az alábbi attribútumokat:::* displayName::* mail::* sn::* givenName
Minimális elvárásként '''kötelező''' legalább ::1.6 karakter hosszú, legalább két karakterosztályt (betűk, számok, egyéb jelek) tartalmazó jelszavak használata. '''Ajánlott''' a legalább 8 karakter hosszú, legalább két karakterosztályt tartalmazó jelszavak használata4. Az IdP-nek kötelező biztosítania, ugyancsak '''ajánlott''' a jelszó szűrése a szótárban szereplő szavak alapjánhogy az eduPersonTargetedID és az eduPersonPrincipalName attribútumok ne legyenek újra kioszthatók.
'''Ajánlott''' a jelszavak évenkénti cseréjének kikényszerítése:1.7. Teszt felhasználók az alábbi megkötések mentén használhatóak:
Az elfelejtett jelszavak cseréjére ::1.7.1. minden teszt felhasználót egyértelműen azonosítani és dokumentálni kötelező (az intézmény bármilyen, megfelelően biztonságos eljárást alkalmazhat (személyes megjelenés, tanulmányi rendszerben tárolt jelszó, SMS-ben elküldött ideiglenes jelszóérte felelős munkatárssal együtt), amit '''kötelező''' dokumentálni.
'''Ajánlott''' ::1.7.2. teszt felhasználóval valós tranzakciót kezdeményezni tilos, kivéve, ha a jelszavak brute-force támadásának kiszűrésetranzakcióban részt vevő SP a teszt felhasználó használatához hozzájárult, egyéb preventív módszerek alkalmazása (például 3 elrontott jelszó után automatikus kitiltás).
== Felhasználói adatok karbantartása, felhasználók kiléptetése ==Az intézmény '''köteles''' ::1.7.3. ajánlott ezen felhasználókat a felhasználói adatbázisát rendszeresen karbantartani, abban a lejárt és nem használt accountokat letiltanimegfelelő homeOrganizationType értékkel megkülönböztetni.
'''Kötelező''' az intézményhez való viszonyban :1.8. Felhasználói azonosító adatokat ([[HREFAttributeSpec#eduPersonScopedAffiliation|eduPersonScopedAffiliation]]pl. jelszó) bekövetkezett változásokat 7 napon belül átvezetni az IdP adatbázisábapublikus hálózaton titkosítatlanul továbbítani (felhasználótól bekérni, adatbázisszerver felé kommunikálni) tilos. Amennyiben a felhasználó elhagyta az intézményt, úgy ezt az információt szintén jelezni kell ebben az attribútumban:
* hallgató kilépése esetén lehetőség van arra, hogy a jogviszony megszűnte után ún:1. 'alum' státuszban továbbra is használható maradjon a szolgáltatás9. A 'student' illetve 'member' jelző ilyenkor már '''felhasználói jelszavakat ajánlott nem használható'''elektronikus formában kiosztani (pl.* oktató illetve alkalmazott kilépése esetén a 'staff', 'employee', 'faculty'személyesen, 'member' értékeket törölni kellvagy postai úton).
Az intézmény '''köteles''' a :1.10. A felhasználók kiléptetési procedúráját dokumentálni, különös tekintettel intézményhez fűződő viszonyában bekövetkezett változásokat 7 napon belül kötelező megjeleníteni az IdP oldali szolgáltatás használatára. '''Ajánlott''' a jogviszony megszűnte után legfeljebb néhány héttel teljesen letiltani a felhasználó belépésének lehetőségétadatbázisában és az eduPersonScopedAffiliation attribútum értékében.
Az egyéb ::1.10.1. Amennyiben az intézmény külső adatforrást (tanulmányi- ill. bérügyi rendszert) használ a felhasználói adatokban bekövetkezett változásokat 30 napon belül '''kötelező''' átvezetni az IdP adatbázisábaadatok tárolására, úgy ez a 7 napos korlát a hiteles adat elsődleges rendszerben történő megváltozásától számítandó.
= = 2. Szolgáltatás-menedzsment ==Ez a szakasz az előzőekben leírt identitás-menedzsment elvekhez kapcsolódóan az egyes szoftver-komponensek üzemeltetését foglalja össze:2. A szakasz többnyire csak ajánlásokat fogalmaz meg1.== Rendelkezésre állás ==Az intézmény számára '''ajánlott''' köteles a szolgáltatási szint (SLA) dokumentálása, és az eljárások rendszeres ellenőrzése az elkészült dokumentációnak megfelelően. Az SLA a következő pontokat foglalja magában:* Tervezett és nem tervezett leállásokkal kapcsolatos megkötések** egy éven belüli előre tervezett karbantartási célú leállások maximális száma** egy éven belüli maximális állási idő** a leállási időszakok kommunikálásának módja** nem tervezett leállások kommunikálásának módja* Szolgáltató rendszerek architektúrája, különös tekintettel az egyszeres hibapontokra, redundáns (tartalék-) rendszerekre, esetleges klaszterek működésére.== Támogatás ==A föderációban részt vevő intézmények '''kötelesek''' az IdP-vel (és az SP-vel) kapcsolatos problémákra reagálni tudó operátori föderációs operátorral való kapcsolattartásra megfelelő szerepkört kialakítaniukkialakítani. '''Ajánlott''', hogy ezt a szerepet ne egy ember töltse be, hiszen a felmerülő problémák esetén sok esetben gyors beavatkozás szükségeskapcsolattartáshoz szerep e-mail címet megadni.
Az operátori problémákat '''ajánlott''' issue tracking rendszerben követni, amihez optimális esetben hibaelhárítást segítő tudásbázis is tartozhat:2.2.=== Felhasználók támogatása ===Az intézményeknek '''kötelező''' IdP-t üzemeltető intézmény köteles az IdP-vel kapcsolatosan kapcsolatban végfelhasználói támogatást nyújtani. Ezen , és ezen támogatás elérhetőségéről a felhasználókat felhasználóit tájékoztatni kell, amit a [[Resource_Registry]]-n keresztül felvitt helpdesk URL segíthet.
A föderációs operátor a végfelhasználók részére nem nyújt támogatást:2.3.=== Föderációs operátorral való kapcsolattartás, incidens-kezelés ===Az intézményeknek '''kötelességük''' dokumentálni intézmény köteles az általa üzemeltett IdP szolgáltatással kapcsolatos katasztrófa-elhárítási teendőketforgalmi adataiból anonimizált, és ezen dokumentációkat rendszeresen (legalább évente) ellenőrizni, naprakészen tartaninapi felbontású adatokat szolgáltatni a föderációs operátor számára föderációs célú statisztika készítésének céljából.
Az IdP-t üzemeltető szervezeti egység elérhetőségét fel '''kell''' tüntetni a [[Resource_Registry]]-ben. '''Ajánlott''' a csoporthoz közösen tartozó telefonszámot és e-mail címet használni== 3. Üzemeltetési kérdések ==
Amennyiben a szolgáltatás által használt kriptográfiai kulcsok kompromittálódtak:3.1. A személyes adatokkal kapcsolatos tranzakciókról kötelező naplóállományt készíteni, az intézmény adminisztrátorának '''kötelessége''' a kulcsot '''azonnal''' visszavonni a föderációból (a [[Resource_Registry]]-n keresztül), illetve 1 munkanapon belül értesítenie a NIIF AAI csapatotés azt legalább 30 napig megőrizni.
== Jelentések készítése ==:3.1.1. Az IdP szolgáltatás működésével kapcsolatban '''ajánlott''' meghatározni különböző metrikákat, melyek intézmény ezeket a szolgáltatás rendelkezésre állását és felhasználásának módját, hatékonyságát mériknaplókat köteles a hatályos adatvédelmi szabályokkal összhangban kezelni.
A föderáció összesített statisztikájának elkészítéséhez ''':3.2. Az AAI infrastruktúra komponensei esetén kötelező''' a következő adatok begyűjtése, napi felbontással:** az IdP-t adott napon használó (egyedi) felhasználók száma** egyes föderációs szolgáltatások felé adott SSO autentikációk száma** összes SSO autentikáció számalegalább 2048 bites kulcsok használata.
A teljes föderáció statisztikáját ::3.2.1. Biztosítani kell a föderációs operátor tartja karban. Az IdP üzemeltetője '''köteles''' az IdP előző pontban felsorolt statisztikáit az operátor számára rendelkezésre bocsátaniprivát kulcsok védelmét.
= Üzemeltetési kérdések === Üzemeltetéssel kapcsolatos kötelezettségek ==Az intézmények '''kötelesek''' AAI rendszereiket elvárható gondossággal üzemeltetni, az üzemeltetési eljárásaikat dokumentálni, azokat rendszeresen felülvizsgálni::3. Az AAI rendszerek megfelelő működéséhez szükséges infrastruktúra biztosítása (megfelelő hálózati elérés, szoftverfrissítések, időszinkronizálás) az intézmények feladata2.== Naplózás, monitorozás =='''Ajánlott''' a szolgáltatás működését folyamatosan monitorozni2. Ez a monitorozás magában foglalhatja a naplóállományok rendszeres vizsgálatátAmennyiben egy kulcs kompromittálódik, az operációs rendszer, illetve intézmény köteles a hálózat elérhetőségének, átbocsátó képességének ellenőrzését illetve mérését. Hiba esetén '''ajánlott''' az operátorok automatikus (e-mail, SMS) értesítéseföderációs operátort 24 órán belül értesíteni.
A rendszerben keletkező naplóállományok személyes adatokat tartalmaznak, ezért ezen naplóállományok kezelésével kapcsolatosan '''kötelező''' az adatkezelési elvek betartása::3.2. A személyes adatokhoz való hozzáférésről '''kötelező''' naplóállományokat készíteni, ezeket az IdP naplókkal összhangban meg '''kell''' őrizni3. Biztosítani '''kell'''Ajánlott hosszú lejáratú, hogy a naplóállományokhoz csak az arra felhatalmazott személyek férhessenek hozzáself-signed tanúsítványok használata.
'''Ajánlott''' a webszerver és az IdP logokat napi szinten cserélni (rotálni), a régi logfájlokat pedig tömörített, integritásvédett formátumban tárolni:3.3. Vonatkozó SAML szabványok
Az incidensek felderítése érdekében ::3.3.1. Kötelező az IdP '''köteles''' minden belépésről a felhasználó visszakövethetőségét biztosító adatokat 30 napig megőrizni, majd azután törölni, vagy off-line módon archiválniInteroperable SAML 2. Az IdP ezeket az adatokat '''nem adhatja ki0 Web Browser SSO Deployment Profile''' az SP-k számára([http://saml2int.org]) dokumentumban kötelezőnek megjelölt elemek támogatása
== Biztonság ==Az AAI infrastruktúra szervereire, illetve a személyes adatokat kezelő egyéb szerverekre való belépést erősen korlátozni '''kell'''::3.3.2. '''Ajánlott''' a többfaktoros, emelt szintű autentikáció, SAML2 Single Logout profil támogatása HTTP-Redirect illetve a belépés bizonyos hálózati szegmensekre való korlátozása. Az intézmény felelőssége, hogy ezen szerverekre csak a megfelelő jogosultsággal bíró operátorok léphessenek beSOAP binding felett.
'''Ajánlott''' a szerverek tűzfallal történő védelme, illetve behatolást észlelő rendszer :3.4. Az IdP köteles minden végpontját HTTPS (IDSSSL/TLS) futtatásaprotokollok segítségével védeni.
Az AAI infrastruktúra felhasználók számára szolgáltatásokat nyújtó elemeire '''ajánlott''' megbízható tanúsítványkiadó által kiadott, modern böngészők által elfogadott tanúsítványok használata (IdP webszerver, SP webszerver):3.5. Az IdP és minden SAML végpontjának az SP által használtIdP-t üzemeltető intézmény tulajdonában álló DNS domainnek, metaadatba is kerülő kulcshoz '''ajánlott''' vagy az ún. self-signed tanúsítvány használataalatt levő névnek kell lennie.
Az AAI infrastruktúra elemei esetén '''megkövetelt''' a minimum 2048 bites kulcsok használata. Biztosítani '''kell''', hogy a működéshez szükséges privát kulcsokhoz csak az arra jogosultak férhessenek hozzá. Amennyiben egy kulcs kompromittálódik, azt azonnal vissza '''kell''' vonni az AAI rendszerből, és erről 1 munkanapon belül értesíteni '''kell''' a föderációs operátort! == AAI komponensek konfigurációja, üzemeltetése ==Az AAI komponensek számára '''kötelező''' a föderációs metaadatot a központi helyről letölteni (http://metadata.eduid.hu/2010/href-metadata.xml), és 24 óránként vagy gyakrabban frissíteni. A metaadat aláírását illetve a benne szereplő érvényességre vonatkozó adatokat (validUntil) '''kötelező''' minden frissítés során ellenőrizni.  Az intézmények számára '''ajánlott''' az AAI rendszerek konfigurációjának dokumentálása, illetve verziókövetése.=== Attribútumok kezelése ===Az intézmény '''köteles''' a felhasználók személyes adatait a törvényi előírásokkal összhangban kezelni. Az IdP csak olyan attribútumokat adhat ki, amelyek minimálisan szükségesek egy szolgáltatás működéséhez. Minden kiadott személyes adat csak a felhasználó beleegyezésével adható ki. Az intémény '''köteles''' a tárolt adatok integritását biztosítani, azokhoz a hozzáférést megfelelően szabályozni. Az adatforrásokhoz való kapcsolatot titkosított hálózati protokoll felett '''kell''' végezni (kivétel ezalól a lokális hoszt). IdP üzemeltetése esetén '''ajánlott''' az adatkiadást a [[Resource_Registry]]-n keresztül generált szűrőkkel szabályozni. '''Ajánlott''' ezen szűrők rendszeres frissítése. Az IdP-nek '''kötelező''' támogatnia célzott, átlátszatlan azonosítót, és ezt az SP-k számára kiadni (amennyiben az adott SP kér ilyet). Ez az azonosító lehet az ún. [[HREFAttributeSpec#eduPersonTargetedID|eduPersonTargetedID]], vagy SAML2 persistent NameID, utóbbit '''kötelező''' perzisztensen kezelni (tehát adatbázisban tárolni). További információ: [[HREFAttributeSpec#NameID_formátumok_-_melyiket_válasszam.3F|a NameID formátumokról]]3.=== Felhasznált SAML profilok ===Az IdP '''köteles''' a SAML2 Web Browser SSO profilt <code>HTTP-Redirect</code> binding felett támogatni6. Az SP '''köteles''' a SAML2 Web Browser SSO profilt <code>HTTP-POST</code> felett támogatni. Mind az IdP, mind az SP számára ajánlott a SAML2 Single Logout profil támogatása <code>HTTP-Redirect</code> illetve <code>SOAP</code> binding felett. A <code>HTTPáltal használt scope-Artifact</code> binding használata a Web Browser SSO profil esetén megengedett. A felhasználó személyes adatainak védelme érdekében oknak az IdP '''köteles''' minden végpontját SSL/TLS-sel védeni (HTTPS). Az SP számára '''ajánlott''' az SSL/TLS használata. Felhasználói adatot titkosítatlan csatornán átvinni '''tilos''' (tehát ha az SP nem használ SSL/TLS-tüzemeltető intézmény tulajdonában álló DNS domainnek, vagy az assertion titkosítása '''kötelező''', egyébként '''ajánlott''').=== Adatvédelem, attribútum-kiadás ===Az IdP-nek '''kötelező''' megjelölni egy ''adatvédelmi felelőst'', aki jogosult az adatkiadási szabályokról dönteni. '''Ajánlott''' szerep e-mail címet megadni erre a célra. Az IdP adatvédelmi felelőse folyamatosan figyelemmel kíséri a Resource Registry-ben attribútum filterek változását (ill. az erről küldött e-maileket), amelyeket a változástól számított 7 napon belül jóvá '''alatt levő névnek kell''' hagynia vagy el '''kell''' utasítanialennie= Források =[http://www.switch.ch/aai/support/bcp/idp-1.0.html SWITCH - Best current practices for operating a SWITCHaai Identity Provider]

Navigációs menü