„HREF műszaki előírások” változatai közötti eltérés

Innen: KIFÜ Wiki
(egyéb)
(újraszövegezés, kevéssé fontos pontok törlése)
8. sor: 8. sor:
 
A dokumentum célja, hogy 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.
 
A dokumentum célja, hogy 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.
  
== Felépítés ==
+
Az eduID föderációhoz csatlakozó intézmények a csatlakozással magukra nézve kötelező érvényűként elfogadják az alább leírtakat. Bármely '''kötelező'''ként megjelölt pont be nem tartásából fakadó következményekért a felelősség az intézményt terheli. Az '''ajánlott''' eljárásoktól való eltérés indokolt esetben lehetséges, de minden eltérést dokumentálni szükséges.
 
 
  
 
= Identitás-menedzsment =
 
= 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
+
Jelen fejezet összefoglalja az intézményen belüli felhasználókezelésre vonatkozó előírásokat. A felhasználókezelés magában foglalja a
  
 
* felhasználói accountok létrehozását,
 
* felhasználói accountok létrehozását,
19. sor: 18. sor:
 
* az adatok védelmét illetéktelen behatolással szemben.
 
* az adatok védelmét illetéktelen behatolással szemben.
  
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 ellenőrizni, szükség esetén a dokumentációt frissíteni.
+
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 ==
 
== Adatforrások ==
27. sor: 26. sor:
 
* egyéb autoritatív adatbázis (tanulmányi, munkaügyi rendszer).
 
* egyéb autoritatív adatbázis (tanulmányi, munkaügyi rendszer).
  
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:
+
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:
  
* az adatforrásként szolgáló rendszer naprakész adatokat tartalmaz
+
* az adatforrásként szolgáló rendszer naprakész adatokat tartalmaz,
* az IdP adatbázisban szereplő felhasználók rendszeresen szinkronizálásra kerülnek az autoritatív adatbázissal
+
* az IdP adatbázisban szereplő 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.
+
* 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 ==
 
== 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.
+
Az IdP adatbázisában szereplő bejegyzések természetes személyhez '''kell''' kapcsolódjanak, lehetőleg egy személyhez ne tartozzon több bejegyzés. A szerep felhasználók (adminisztrátor, rektor) használata '''tilos'''.
* Minden egyes adatbázisbeli bejegyzés különböző egyénhez kell tartozzon.
+
 
* 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.
+
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. '''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 a hivatalos okmányokon szereplő adatokkal egyeztetni.
* 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 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.
+
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. tanulmányi rendszer) terhelik.
 +
 
 +
=== Teszt felhasználók ===
 +
Bizonyos megkötésekkel lehetséges technikai bejegyzések (például teszt accountok) használata, de ezeket egyértelműen azonosítani és dokumentálni '''kell'''. Az intézményhez fűződő szerepet tároló attribútumnak  ([[HREFAttributeSpec#eduPersonScopedAffiliation|eduPersonScopedAffiliation]]) a teszt accountok esetén '''tilos''' valódi felhasználókhoz köthető értékeket tartalmaznia (hallgató, oktató, ...).
 +
 
 +
== Jelszavak kiosztása és karbantartása ==
 +
 
 +
Az IdP adatbázisbejegyzéseihez tartozó jelszavakat '''tilos''' nem hitelesített csatornán továbbítani bármely két rendszer között, például elektronikus levélben elküldeni, titkosítatlan kapcsolaton bekérni.
 +
 
 +
A felhasználói accountokhoz tartozó jelszavakat '''ajánlott''' személyesen, vagy egyéb, nem elektronikus módon kiosztani (pl. postai úton). 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).
 +
 
 +
Minimális elvárásként '''kötelező''' legalább 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álata, ugyancsak '''ajánlott''' a jelszó szűrése a szótárban szereplő szavak alapján.
 +
 
 +
'''Kötelező''' a jelszavak évenkénti cseréjének kikényszerítése.
 +
 
 +
Az elfelejtett jelszavak cseréjére 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ó), amit '''kötelező''' dokumentálni.
  
 +
'''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 kitiltás).
  
== 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. postai úton).
 
* 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).
 
* 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.
 
* 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.
 
* 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 (?).
 
  
 +
=== Felhasználói adatok karbantartása ===
 +
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. '''Kötelező''' 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 account IdP-n keresztül történő belépését le '''kell''' tiltani.
 +
 +
'''Ajánlott''' az intézményhez való viszony gyakori karbantartása (például naponta történő szinkronizálás a tanulmányi rendszerrel).
  
== Jelszavak ==
 
* Az intézmények kötelesek dokumentálni a jelszavakkal kapcsolatban alkalmazott megkötéseiket.
 
* A jelszavak minimális hossza legalább 6 karakter.
 
* 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 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, ...)
 
  
 
= Szolgáltatás-menedzsment =
 
= Szolgáltatás-menedzsment =
64. sor: 70. sor:
  
 
== Rendelkezésre állás ==
 
== Rendelkezésre állás ==
* Tervezett leállások csak az előre meghirdetett karbantartási időszakokban történjenek.
+
Az intézmény számára '''ajánlott''' 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:
* Szükséges dokumentálni a szolgáltatási szintet, mely 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 előre tervezett karbantartási célú leállások maximális száma
 
** egy éven belüli maximális állási idő
 
** egy éven belüli maximális állási idő
 
** a leállási időszakok kommunikálásának módja
 
** a leállási időszakok kommunikálásának módja
 
** nem tervezett leállások 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énjenek.
+
* 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.
* Az IdP szolgáltatás lehető legnagyobb rendelkezésre állása klaszterezett architektúrában valósítható meg.
+
 
* Amennyiben a klaszterezett működés nem megvalósítható, ajánlott egy tartalék-rendszer kiépítése, amely probléma esetén minimális kézi beavatkozással képes átvenni a működést.
+
 
* Klaszterezett esetben fontos, hogy sem a terheléselosztó, 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.
+
== 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 szerepkört kialakítaniuk. '''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éges.
 +
 
 +
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.
 +
 
  
 +
=== Felhasználók támogatása ===
 +
Az intézményeknek '''ajánlott''' az IdP-vel kapcsolatosan végfelhasználói támogatást nyújtani. 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íthet.
  
== Support ==
 
* Az intézményeknek kötelességük az IdP-vel kapcsolatosan végfelhasználói támogatást nyújtani. 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íthet.
 
* 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.
 
* Az IdP 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.
 
* A gyakran előforduló hibákat és kérdéseket ajánlott a fent említett helpdesk URL-en publikálni.
 
  
 +
=== Föderációs operátorral való kapcsolattartás, incidens-kezelés  ===
 +
Az intézményeknek '''kötelességük''' dokumentálni az IdP szolgáltatással kapcsolatos katasztrófa-elhárítási teendőket, és ezen dokumentációkat rendszeresen (legalább évente) ellenőrizni, naprakészen tartani.
  
== Incidens-kezelés ==
+
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.  
* Az intézményeknek kötelességük dokumentálni az IdP szolgáltatással kapcsolatos katasztrófa-elhárítási teendőket, é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 csapatot.
+
Amennyiben a szolgáltatás által használt kriptográfiai kulcsok kompromittálódtak, az intézmény adminisztrátorának '''kötelessége''' a kulcsot visszavonni a föderációból (a [[Resource_Registry]]-n keresztül), illetve értesítenie a NIIF AAI csapatot.
  
  
 
== Jelentések készítése ==
 
== Jelentések készítése ==
* Az IdP szolgáltatás működésével kapcsolatban ajánlott meghatározni különböző metrikákat, melyek a szolgáltatás rendelkezésre állását és felhasználásának módját, hatékonyságát mérik.
+
Az IdP szolgáltatás működésével kapcsolatban '''ajánlott''' meghatározni különböző metrikákat, melyek a szolgáltatás rendelkezésre állását és felhasználásának módját, hatékonyságát mérik.
* A föderáció összesített statisztikájának elkészítéséhez ajánlott a következő adatok begyűjtése, napi felbontással:
+
 
 +
A föderáció összesített statisztikájának elkészítéséhez '''ajánlott''' a következő adatok begyűjtése, napi felbontással:
 
** egyedi felhasználók száma
 
** egyedi felhasználók száma
 
** egyes szolgáltatások felé adott SSO autentikációk száma
 
** egyes szolgáltatások felé adott SSO autentikációk száma
 
** összes SSO session 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, ...)
+
 
 +
A teljes föderáció statisztikáját a föderációs operátor tartja karban. Az IdP üzemeltetőjének '''ajánlott''', hogy az IdP előző pontban felsorolt statisztikáit az operátor számára rendelkezésre bocsátsa.
 +
 
  
 
= Üzemeltetési kérdések =
 
= Ü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. 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 feladata.
 +
 +
 
== Naplózás, monitorozás ==
 
== Naplózás, monitorozás ==
* Az operációs rendszer illetve a webszerver naplóállományait rendszeresen monitorozni kell, a gyanús üzeneteket kivizsgálni szükséges.
+
'''Ajánlott''' a szolgáltatás működését folyamatosan monitorozni. Ez a monitorozás magában foglalhatja a naplóállományok rendszeres vizsgálatát, az operációs rendszer, illetve 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ése.
* Folyamatosan monitorozni kell a hálózat elérhetőségét, lehetőleg ugyanazon a hálózati útvonalon, amelyen keresztül a felhasználók használják a szolgáltatást.
 
* Folyamatosan monitorozni kell a szükséges processzeket (NTP, webszerver, címtár-szerver, stb.)
 
  
=== IdP processz ===
+
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. 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''' őrizni. Biztosítani '''kell''', hogy a naplóállományokhoz csak az arra felhatalmazott személyek férhessenek hozzá.
* Az IdP alkalmazásszerver és az IdP processz logjait a hiba (ERROR) és figyelmeztetés (WARN) üzenetek szintjén folyamatosan monitorozni kell.
 
* A szolgáltatás kiesése esetén ajánlott a rendszergazdák automatikus értesítése (e-mail, sms)
 
* Ajánlott az IdP naplózási konfigurációját úgy módosítani, hogy a hibaüzenetek (ERROR) email-ben elküldésre kerüljenek.
 
* Az IdP processz alapvető működését folyamatosan monitorozni kell (/idp/Status).
 
* Ajánlott egy dedikált teszt-account segítségével a belépést figyelni. Ajánlott a teszt-account jelszavát gyakran (legalább havonta) megváltoztatni.
 
  
=== Naplóállományok ===
+
'''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.
* Azon naplóállományokat, melyek egy incidens esetén bizonyítékul szolgálhatnak (audit logok), szükséges legalább annyi ideig megőrizni, míg a bizonyítás kapcsán jogilag szükséges.
 
* A naplóállományokat ajánlott legalább 6 hónapig megőrizni.
 
* A személyes adatokhoz való hozzáférésről (pl. LDAP-access) naplóállományokat kell készíteni, ezeket az IdP naplókkal összhangban meg kell őrizni.
 
* Biztosítani kell, hogy a naplóállományokhoz csak az arra felhatalmazott személyek férhessenek hozzá.
 
* Amennyiben a naplóállományok elhagyják az IdP-t, kötelező a benne szereplő személyes adatokat (minden felhasználói attribútum, IP cím, stb...) törölni, "anonimizálni".
 
* Ajánlott a webszerver és az IdP logokat napi szinten cserélni (rotálni), a régi logfájlokat pedig tömörített formátumban tárolni.
 
* Ajánlott a régi, "rotált" naplóállományok integritásvédelmének biztosítása.
 
  
  
== Mentés ==
+
== Biztonság ==
* A mentési és visszaállítási procedúrát az intézményeknek dokumentálniuk kell.
+
Az AAI infrastruktúra szervereire, illetve a személyes adatokat kezelő egyéb szerverekre való belépést erősen korlátozni '''kell'''. '''Ajánlott''' a többfaktoros, emelt szintű autentikáció, 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 be.
* A kellő rendelkezésre állás biztosításáért ajánlott hetente teljes mentést készíteni az IdP-ről.
 
* Érdemes napi inkrementális mentést készíteni az IdP rendszerről.
 
* A mentéseket biztonságos, "off-site" rendszeren kell tárolni.
 
* A visszaállítási procedúrát legalább évente ajánlott ellenőrizni.
 
  
 +
'''Ajánlott''' a szerverek tűzfallal történő védelme, illetve behatolást észlelő rendszer (IDS) futtatása.
 +
 +
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 tanúsítványok használata (IdP webszerver, SP webszerver).
 +
 +
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!
  
== Biztonság ==
 
* A felhasználókezelést végző szerverekre való belépést erősen korlátozni kell. Ajánlott a többfaktoros, emelt szintű autentikáció, illetve a belépés bizonyos hálózati szegmensekre való korlátozása.
 
* Ajánlott behatolást észlelő rendszer (IDS) futtatása.
 
* A szerverekhez hozzáféréssel rendelkező felhasználók jogosultságait gyakran felül kell vizsgálni.
 
* Szükséges a szerverek tűzfallal történő védelme (az IdP processz számára csak a 443 illetve 8443-as portokat kell nyitva tartani).
 
* Ajánlott a felhasználók felé megbízható tanúsítványkiadó által aláírt tanúsítvány használata.
 
* Biztosítani kell, hogy a működéshez szükséges privát kulcsokat csak az IdP processz olvashassa.
 
* Legalább 3 évente érdemes új kulcspárt generálni.
 
* Amennyiben egy kulcs kompromittálódik, azt azonnal vissza kell vonni az AAI rendszerből!
 
  
=== Frissítések ===
+
== AAI komponensek konfigurációja, üzemeltetése ==
* Az operációs rendszer illetve IdP szoftver kritikus biztonsági frissítéseit legkésőbb 2 héttel azok megjelenése után alkalmazni kell.
+
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/metadata.xml), és legfeljebb napi gyakorisággal 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. A metaadat aláíró tanúsítványát '''ajánlott''' összevetni a NIIF AAI visszavonási listával.
* Ajánlott az operációs rendszer illetve IdP frissítését legritkábban havonta alkalmazni.
 
  
 +
Az intézmények számára '''ajánlott''' az AAI rendszerek konfigurációjának dokumentálása, illetve verziókövetése.
  
== Dokumentálási rend ==
 
* Ajánlott az IdP által felhasznált attribútumokat egyesével megvizsgálni, azokhoz hiteles adatforrásokat illetve adatfelelősöket kötni.
 
* Az IdP szoftver- és hardverkörnyezetét (beleértve a hálózati beállításokat is) intézményen belül dokumentálni kell.
 
* Az IdP szoftver menedzselését - indítás, leállítás, monitorozást - intézményen belül dokumentálni kell.
 
* Érdemes naplót vezetni az IdP-t érintő konfiguráció-módosításokról.
 
  
== IdP Konfiguráció ==
+
=== Attribútumok kezelése ===
* Az IdP entityID-jának URL formátumúnak kell lennie, és ezen URL-nek az IdP metadatáját kell visszaadnia. Shibboleth esetén ez az URL így néz ki: https://idp.example.org/idp/shibboleth.
+
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.
* Ajánlott az IdP konfiguráció verziókövetése.
 
* Ajánlott egy tesztrendszer üzemeltetése, amely mindenben megegyezik az éles szolgáltatással, ezért az éles szolgáltatás konfiguráció-változtatásai tesztelhetőek benne.
 
  
=== Metaadatok kezelése ===
+
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).
* A föderációs metaadatot a központi helyről kell letölteni (https://rr.aai.niif.hu/metadata/href-metadata.xml).
 
** A metaadatot legalább óránként ajánlott újra letölteni.
 
** A metaadatot kötelező legfeljebb napi gyakorisággal frissíteni.
 
* A metaadat aláírását minden letöltés után ellenőrizni kell.
 
* Az aláíró tanúsítványt ajánlott összevetni a NIIF AAI visszavonási listával.
 
  
=== Attribútumok ===
+
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 adatforrásokhoz való kapcsolatot titkosított hálózati protokoll felett kell végezni (kivétel ezalól a lokális hoszt).
 
* Az IdP nem hozhat létre, változtathat, törölhet olyan attribútumokat, amelyekért nem ő a felelős. Ezt a védelmet az adatforrás szintjén kell megvalósítani.
 
* A kiadott attribútumoknál az adatvédelmi elveket kell szem előtt tartani
 
** csak olyan attribútum adható ki, ami minimálisan szükséges az adott szolgáltatás működéséhez
 
** csak olyan attribútum adható ki, amelynek kiadásába a felhasználó beleegyezett (uApprove)
 
* Az attribútum-kiadást ajánlott a [[Resource_Registry]]-n keresztül generált filterrel szabályozni.
 
** a lokális attribútum-kiadási szabályokat ajánlott külön filter állományban tárolni.
 
* Az IdP-nek kötelező támogatnia célzott, átlátszatlan azonosítót
 
** ez az azonosító lehet az ún. eduPersonTargetedId, vagy SAML2 persistent NameID
 
** a NameID használata esetén kötelező ezt az értéket perzisztensen kezelni (tehát adatbázisban tárolni).
 
  
= Egyéb =
+
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]].
* Hardver követelmények
 
** Rack / szerverszoba / klíma, etc
 
** UPS
 
* Szoftver követelmények
 
** LTS OS
 
** NTP
 
* Hálózati követelmények
 
* redundáns, legalább 100mbit
 
  
 
= Források =
 
= Források =
 
[http://www.switch.ch/aai/support/bcp/idp-1.0.html SWITCH - Best current practices for operating a SWITCHaai Identity Provider]
 
[http://www.switch.ch/aai/support/bcp/idp-1.0.html SWITCH - Best current practices for operating a SWITCHaai Identity Provider]

A lap 2010. május 14., 12:30-kori változata

Föderációs policy csatlakozó intézmények (IdP-k) számára



Jelen dokumentum célja

A dokumentum célja, hogy 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.

Az eduID föderációhoz csatlakozó intézmények a csatlakozással magukra nézve kötelező érvényűként elfogadják az alább leírtakat. Bármely kötelezőként megjelölt pont be nem tartásából fakadó következményekért a felelősség az intézményt terheli. Az ajánlott eljárásoktól való eltérés indokolt esetben lehetséges, de minden eltérést dokumentálni szükséges.

Identitás-menedzsment

Jelen fejezet összefoglalja az intézményen belüli felhasználókezelésre vonatkozó előírásokat. 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.

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).

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:

  • az adatforrásként szolgáló rendszer naprakész adatokat tartalmaz,
  • az IdP adatbázisban szereplő 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.


Hitelesítési policy

Az IdP adatbázisában szereplő bejegyzések természetes személyhez kell kapcsolódjanak, lehetőleg egy személyhez ne tartozzon több bejegyzés. A szerep felhasználók (adminisztrátor, rektor) használata tilos.

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. 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 a hivatalos okmányokon szereplő adatokkal egyeztetni.

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. tanulmányi rendszer) terhelik.

Teszt felhasználók

Bizonyos megkötésekkel lehetséges technikai bejegyzések (például teszt accountok) használata, de ezeket egyértelműen azonosítani és dokumentálni kell. Az intézményhez fűződő szerepet tároló attribútumnak (eduPersonScopedAffiliation) a teszt accountok esetén tilos valódi felhasználókhoz köthető értékeket tartalmaznia (hallgató, oktató, ...).

Jelszavak kiosztása és karbantartása

Az IdP adatbázisbejegyzéseihez tartozó jelszavakat tilos nem hitelesített csatornán továbbítani bármely két rendszer között, például elektronikus levélben elküldeni, titkosítatlan kapcsolaton bekérni.

A felhasználói accountokhoz tartozó jelszavakat ajánlott személyesen, vagy egyéb, nem elektronikus módon kiosztani (pl. postai úton). 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).

Minimális elvárásként kötelező legalább 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álata, ugyancsak ajánlott a jelszó szűrése a szótárban szereplő szavak alapján.

Kötelező a jelszavak évenkénti cseréjének kikényszerítése.

Az elfelejtett jelszavak cseréjére 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ó), amit kötelező dokumentálni.

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 kitiltás).


Felhasználói adatok karbantartása

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. Kötelező 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 account IdP-n keresztül történő belépését le kell tiltani.

Ajánlott az intézményhez való viszony gyakori karbantartása (például naponta történő szinkronizálás a tanulmányi rendszerrel).


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. A szakasz többnyire csak ajánlásokat fogalmaz meg.

Rendelkezésre állás

Az intézmény számára ajánlott 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 szerepkört kialakítaniuk. 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éges.

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.


Felhasználók támogatása

Az intézményeknek ajánlott az IdP-vel kapcsolatosan végfelhasználói támogatást nyújtani. 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íthet.


Föderációs operátorral való kapcsolattartás, incidens-kezelés

Az intézményeknek kötelességük dokumentálni az IdP szolgáltatással kapcsolatos katasztrófa-elhárítási teendőket, és ezen dokumentációkat rendszeresen (legalább évente) ellenőrizni, naprakészen tartani.

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.

Amennyiben a szolgáltatás által használt kriptográfiai kulcsok kompromittálódtak, az intézmény adminisztrátorának kötelessége a kulcsot visszavonni a föderációból (a Resource_Registry-n keresztül), illetve értesítenie a NIIF AAI csapatot.


Jelentések készítése

Az IdP szolgáltatás működésével kapcsolatban ajánlott meghatározni különböző metrikákat, melyek a szolgáltatás rendelkezésre állását és felhasználásának módját, hatékonyságát mérik.

A föderáció összesített statisztikájának elkészítéséhez 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 teljes föderáció statisztikáját a föderációs operátor tartja karban. Az IdP üzemeltetőjének ajánlott, hogy az IdP előző pontban felsorolt statisztikáit az operátor számára rendelkezésre bocsátsa.


Ü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. 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 feladata.


Naplózás, monitorozás

Ajánlott a szolgáltatás működését folyamatosan monitorozni. Ez a monitorozás magában foglalhatja a naplóállományok rendszeres vizsgálatát, az operációs rendszer, illetve 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ése.

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. 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 őrizni. Biztosítani kell, hogy a naplóállományokhoz csak az arra felhatalmazott személyek férhessenek hozzá.

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.


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. Ajánlott a többfaktoros, emelt szintű autentikáció, 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 be.

Ajánlott a szerverek tűzfallal történő védelme, illetve behatolást észlelő rendszer (IDS) futtatása.

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 tanúsítványok használata (IdP webszerver, SP webszerver).

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/metadata.xml), és legfeljebb napi gyakorisággal 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. A metaadat aláíró tanúsítványát ajánlott összevetni a NIIF AAI visszavonási listával.

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. eduPersonTargetedID, vagy SAML2 persistent NameID, utóbbit kötelező perzisztensen kezelni (tehát adatbázisban tárolni). További információ: a NameID formátumokról.

Források

SWITCH - Best current practices for operating a SWITCHaai Identity Provider