HREF műszaki előírások
Tartalomjegyzék
Föderációs policy csatlakozó intézmények (IdP-k) számára
FIGYELEM!
A specifikáció kidolgozása folyamatban van, lényeges változások is belekerülhetnek figyelmeztetés nélkül. Amíg ez a figyelmeztetés itt szerepel, addig munkaverziónak tekintendő! |
A szócikk vagy fejezet még megírásra vár
Kérlek, kommentjeiddel segítsd a tervezetet! |
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.
Felépítés
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.
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.
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 (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.
- 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.
- 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.
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 (?).
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
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
- Tervezett leállások csak az előre meghirdetett karbantartási időszakokban történjenek.
- 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énjenek.
- 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.
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.
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.
- 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.
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 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, ...)
Üzemeltetési kérdések
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.
- 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
- 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
- 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
- A mentési és visszaállítási procedúrát az intézményeknek dokumentálniuk kell.
- 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.
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
- 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.
- Ajánlott az operációs rendszer illetve IdP frissítését legritkábban havonta alkalmazni.
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ó
- 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.
- 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
- 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
- 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
Hardver infrastruktúra
Hálózati infrastruktúra
Szoftver infrastruktúra
Források
SWITCH - Best current practices for operating a SWITCHaai Identity Provider