1 260
szerkesztés
Módosítások
a
= Föderációs policy A dokumentum célja, hogy a HREF Föderációhoz csatlakozó intézmények (IdPTagok és Partnerek számára elvárásokat és ajánlásokat fogalmazzon meg, melyek a csatlakozáshoz szükséges identitás-k) számára =menedzsment, valamint üzemeltetési területeket fednek le.
{{ATTENTION|A specifikáció kidolgozása folyamatban vandokumentumban a '''KÖTELEZŐ''', lényeges változások is belekerülhetnek figyelmeztetés nélkül. Amíg ez a figyelmeztetés itt szerepel'''TILOS''', '''AJÁNLOTT''', addig munkaverziónak tekintendő!}}'''NEM AJÁNLOTT''' kifejezések értelmezése az alábbiak szerinti:
{{TODO|Kérlek* '''KÖTELEZŐ''' (ill. '''"KÖTELES"''', kommentjeiddel segítsd '''"kell"''') jelentése: a tervezetet!}}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 föderációhoz csatlakozó intézmények 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;
== Felépítés ==* az '''AJÁNLOTT''' pontoktól való eltéréseket az intézmények dokumentálni kötelesek.
= Identitás-menedzsment =
Jelen fejezet összefoglalja az intézményen belüli felhasználókezelésre vonatkozó előírásokat és tanácsokat. 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,* a felhasználó távozása után a felhasználói adatok törlését,* az adatok védelmét illetéktelen behatolással szemben== 1.Identitás-menedzsment ==
== Adatforrások ==A felhasználói :1.2. Az intézmény köteles a felhasználóiról általa ismert adatok több helyről származhatnak:forrását, karbantartásának módját, illetve ezen adatok becsült adatminőségét dokumentálni, és igény esetén ezt a dokumentációt a föderáció tagjainak rendelkezésére bocsátani.
* személyes felvétel,* egyéb autoritatív adatbázis (tanulmányi, munkaügyi rendszer):1.3. Kötelező a felhasználónevek egyediségét biztosítani.
Amennyiben egy intézmény külső, független adatbázist használ az IdP adatbázisának feltöltésére, köteles a következő kritériumokat betartani:1.4. Egy természetes személyhez nem ajánlott több felhasználói azonosítót rendelni.
* az adatforrásként szolgáló rendszer naprakész adatokat tartalmaz* az IdP adatbázisban szereplő :1.5. Nem ajánlott szerep felhasználók rendszeresen szinkronizálásra kerülnek az autoritatív adatbázissal* a hiteles adatforrásból kikerülő felhasználókat törölni kell az IdP adatbázisából is(dékán, igazgató) használata.
== Hitelesítési policy ==* Az IdP adatbázisában (LDAP, relációs adatbázis) szereplő minden egyes bejegyzésnek egy valós, intézmény által azonosított felhasználóhoz kell tartoznia::1.6.* Minden egyes adatbázisbeli bejegyzés különböző egyénhez kell tartozzon1.* A felhasználói account hitelesítésekor ajánlott megvalósított attribútumokat az account tulajdonosát személyesen azonosítani, személyi igazolvány, vagy egyéb hivatalos okmány segítségével.* Ajánlott a természetes azonosítókat (név, anyja neve, születési hely és idő), illetve a postai elérhetőséget a hivatalos okmányokon szereplő adatokkal egyeztetni.* Amennyiben a felhasználók nem közvetlenül kerülnek rögzítésre IdP-nek 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. tanulmányi rendszer) terhelik.Attribútum Specifikációban leírt módon kell megvalósítani;
== Accountok kiosztása és karbantarása ==* Ajánlott a felhasználói accountokhoz tartozó jelszavakat személyes, vagy egyéb, nem elektronikus módon kiosztani (pl::1. postai úton)6.3. Az IdP-nek ajánlott megvalósítania az alábbi attribútumokat:::* 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. külső rendszerben).displayName::* Az intézmény köteles a felhasználói adatbázisát rendszeresen karbantartani, abban a lejárt és nem használt accountokat letiltani.mail::* Az intézmény köteles a felhasználói adatokban bekövetkezett változásokat 4 héten belül(?) átvezetni az IdP adatbázisába. Amennyiben egy felhasználó viszonya megszűnt az intézménnyel, 3 hónapon belül(?) a felhasználói accountot le kell tiltani.sn::* Az intézmény köteles a felhasználókról annyi adatot és annyi ideig megtartani, ameddig a felhasználó által esetleg okozott visszaélések bizonyíthatósága jogilag fennáll (?).givenName
== Jelszavak ==* Az intézmények kötelesek dokumentálni a jelszavakkal kapcsolatban alkalmazott megkötéseiket:1.* A jelszavak minimális hossza legalább 6 karakter7.* Ajánlott a legalább 8 karakteres, több karakterosztályt tartalmazó jelszavak kikényszerítése.* Ajánlott a szótárban szereplő szavak jelszavakban történő felhasználásának tiltása.* Ajánlott a jelszavak cseréjének kikényszerítése legalább évente (illetve az utolsó 3 évben felhasznált jelszavak újrabeállításának tiltása).* Ajánlott a jelszavak brute-force támadásának kiszűrése, egyéb preventív módszerek alkalmazása (például 3 elrontott jelszó után automatikus 5 perces tiltás).* Ha Teszt felhasználók az IdP adatbázisa külső rendszerrel szinkronizált, lehetséges a jelszómódosítást a külső rendszerben használt jelszóhoz kötni, amennyiben a külső rendszerben kikényszerített jelszó-policy a fent leírtaknak megfelel.* A jelszavak csak titkosított csatornán kerülhetnek átadásra bármely két, hálózatilag szeparált rendszerelem között (pl. böngésző - IdP, IdP - LDAP, ...)alábbi megkötések mentén használhatóak:
= 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::1.7. A szakasz többnyire csak ajánlásokat fogalmaz meg1.minden teszt felhasználót egyértelműen azonosítani és dokumentálni kötelező (az érte felelős munkatárssal együtt),
== Rendelkezésre állás ==* Tervezett leállások csak az előre meghirdetett karbantartási időszakokban történjenek::1.* Szükséges dokumentálni a szolgáltatási szintet, mely a következő pontokat foglalja magában:** 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* A karbantartási időszakokat ajánlott rendszeres frissítések alkalmazására használni, ezen karbantartások lehetőleg előre kiszámíthatóan, kevés kiesést okozó időben történjenek7.* Az IdP szolgáltatás lehető legnagyobb rendelkezésre állása klaszterezett architektúrában valósítható meg2.* Amennyiben a klaszterezett működés nem megvalósíthatóteszt felhasználóval valós tranzakciót kezdeményezni tilos, ajánlott egy tartalék-rendszer kiépítésekivéve, amely probléma esetén minimális kézi beavatkozással képes átvenni ha a működést.* Klaszterezett esetben fontos, hogy sem tranzakcióban részt vevő SP a terheléselosztóteszt felhasználó használatához hozzájárult, sem az autentikációs és egyéb adatforrások nem képeznek egyszeres hibapontot a rendszerben. A hálózati eszközök és áramforrások redundáns kiépítése is ajánlott.
== Support ==* Az intézményeknek kötelességük az IdP-vel kapcsolatosan végfelhasználói támogatást nyújtani:1. Ezen támogatás elérhetőségéről a felhasználókat tájékoztatni kell, amit a [[Resource_Registry]]-n keresztül felvitt helpdesk URL segíthet8.* Az IdP-t üzemeltető szervezeti egység elérhetőségét fel kell tüntetni a [[Resource_Registry]]-benFelhasználói azonosító adatokat (pl. Ajánlott a csoporthoz közösen tartozó telefonszámot és e-mail címet használni.* Az IdP operátori problémákat ajánlott issue tracking rendszerben követnijelszó) publikus hálózaton titkosítatlanul továbbítani (felhasználótól bekérni, amihez optimális esetben hibaelhárítást segítő tudásbázis is tartozhat.* A gyakran előforduló hibákat és kérdéseket ajánlott a fent említett helpdesk URL-en publikálniadatbázisszerver felé kommunikálni) tilos.
== Incidens-kezelés ==* Az intézményeknek kötelességük dokumentálni :1.10. A felhasználók intézményhez fűződő viszonyában bekövetkezett változásokat 7 napon belül kötelező megjeleníteni az IdP szolgáltatással kapcsolatos katasztrófa-elhárítási teendőket, adatbázisában és ezen dokumentációkat rendszeresen (legalább évente) ellenőrizni, naprakészen tartani.* Amennyiben az IdP szolgáltatás által használt kriptográfiai kulcsok kompromittálódtak, az adminisztrátornak kötelessége a kulcsot visszavonni a föderációból (a [[Resource_Registry]]-n keresztül), illetve értesítenie a NIIF AAI csapatoteduPersonScopedAffiliation attribútum értékében.
= Üzemeltetési kérdések === Naplózás:2.2. IdP-t üzemeltető intézmény köteles az IdP-vel kapcsolatban végfelhasználói támogatást nyújtani, monitorozás ==== Mentés ==== Biztonság ==== Dokumentálási rend ==== IdP Konfiguráció ==és ezen támogatás elérhetőségéről a felhasználóit tájékoztatni.
= Források =:3.1.1. Az intézmény ezeket a naplókat köteles a hatályos adatvédelmi szabályokkal összhangban kezelni. :3.2. Az AAI infrastruktúra komponensei esetén kötelező legalább 2048 bites kulcsok használata. ::3.2.1. Biztosítani kell a privát kulcsok védelmét. ::3.2.2. Amennyiben egy kulcs kompromittálódik, az intézmény köteles a föderációs operátort 24 órán belül értesíteni. ::3.2.3. Ajánlott hosszú lejáratú, self-signed tanúsítványok használata. :3.3. Vonatkozó SAML szabványok ::3.3.1. Kötelező az ''Interoperable SAML 2.0 Web Browser SSO Deployment Profile'' ([http://wwwsaml2int.switchorg]) dokumentumban kötelezőnek megjelölt elemek támogatása ::3.ch3.2. Ajánlott a SAML2 Single Logout profil támogatása HTTP-Redirect illetve SOAP binding felett. :3.4. Az IdP köteles minden végpontját HTTPS (SSL/aai/support/bcp/idpTLS) protokollok segítségével védeni. :3.5. Az IdP minden SAML végpontjának az IdP-1t üzemeltető intézmény tulajdonában álló DNS domainnek, vagy az alatt levő névnek kell lennie. :3.06.html SWITCH Az IdP által használt scope- Best current practices for operating a SWITCHaai Identity Provider]oknak az IdP-t üzemeltető intézmény tulajdonában álló DNS domainnek, vagy az alatt levő névnek kell lennie.
→3. Üzemeltetési kérdések: typo
* '''NEM AJÁNLOTT''' jelentése: amennyiben az intézmény a pontban leírtak szerint jár el, ezt dokumentálni köteles.
:1.1. Az intézmények kötelesek az alkalmazott felhasználókezelési elveiket intézmény köteles adatkezelési elveit dokumentálni, és azt a működést ezen dokumentáció alapján rendszeresen ellenőrizni, szükség esetén a dokumentációt frissítenifelhasználókkal megismertetni.
:1.6. Attribútumok használata:
::1.6.2. Az IdP-nek kötelező megvalósítania az alábbi attribútumokat:
::* eduPersonTargetedID
::* eduPersonPrincipalName
::* eduPersonScopedAffialiation
::1.6.4. Az IdP-nek kötelező biztosítania, hogy az eduPersonTargetedID és az eduPersonPrincipalName attribútumok ne legyenek újra kioszthatók.
::1.7.3. ajánlott ezen felhasználókat a megfelelő homeOrganizationType értékkel megkülönböztetni.
:1.9. A felhasználói jelszavakat ajánlott nem elektronikus formában kiosztani (pl. személyesen, vagy postai úton).
::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 adatok 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ó.
== Jelentések készítése 2. Szolgáltatás-menedzsment ==* :2.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 köteles a szolgáltatás rendelkezésre állását és felhasználásának módját, hatékonyságát mérikföderációs operátorral való kapcsolattartásra megfelelő szerepkört kialakítani.* A föderáció összesített statisztikájának elkészítéséhez ajánlott Ajánlott a következő adatok begyűjtése, napi felbontással:** egyedi felhasználók száma** egyes szolgáltatások felé adott SSO autentikációk száma** összes SSO session száma* A működés belső finomításához ennél több, és részletesebb adatra is szükség lehet (csúcsterhelés meghatározása, terhelési időszakok számítása, kiadott attribútumok gyakorisága, ..kapcsolattartáshoz szerep e-mail címet megadni.)
:2.3. Az intézmény köteles az általa üzemeltett IdP forgalmi adataiból anonimizált, legalább napi 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.
= Egyéb === Hardver infrastruktúra ==== Hálózati infrastruktúra ==== Szoftver infrastruktúra 3. Üzemeltetési kérdések ==
:3.1. A személyes adatokkal kapcsolatos tranzakciókról kötelező naplóállományt készíteni, és azt legalább 30 napig megőrizni.
