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, 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:2.* 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ást2.* Folyamatosan monitorozni kell a szükséges processzeket (NTP, webszerver, címtárIdP-t üzemeltető intézmény köteles az IdP-szervervel kapcsolatban végfelhasználói támogatást nyújtani, stbés ezen támogatás elérhetőségéről a felhasználóit tájékoztatni.)
=== IdP processz ===* :2.3. Az IdP alkalmazásszerver és intézmény köteles az általa üzemeltett 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-mailforgalmi adataiból anonimizált, sms)* Ajánlott az IdP naplózási konfigurációját úgy módosítani, hogy legalább napi felbontású adatokat szolgáltatni 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áltoztatniföderációs operátor számára föderációs célú statisztika készítésének céljából.
== Mentés ==* A mentési és visszaállítási procedúrát az intézményeknek dokumentálniuk kell:3.* A kellő rendelkezésre állás biztosításáért ajánlott hetente teljes mentést készíteni az IdP-ről1.* Érdemes napi inkrementális mentést készíteni az IdP rendszerről1.* 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őrizniAz intézmény ezeket a naplókat köteles a hatályos adatvédelmi szabályokkal összhangban kezelni.
== 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::3.* Ajánlott behatolást észlelő rendszer (IDS) futtatása2.* A szerverekhez hozzáféréssel rendelkező felhasználók jogosultságait gyakran felül kell vizsgálni1.* 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 olvashassakulcsok védelmét.* 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 ::3.2.2 héttel azok megjelenése után alkalmazni kell.* Ajánlott Amennyiben egy kulcs kompromittálódik, az operációs rendszer illetve IdP frissítését legritkábban havonta alkalmazniintézmény köteles a föderációs operátort 24 órán belül értesíteni.
== 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:3.* 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ól3.Vonatkozó SAML szabványok
== 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://idp3.example3.org/idp/shibboleth1.* Ajánlott Kötelező az IdP konfiguráció verziókövetése''Interoperable SAML 2.* 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 benne0 Web Browser SSO Deployment Profile'' ([http://saml2int.org]) dokumentumban kötelezőnek megjelölt elemek támogatása
=== Metaadatok kezelése ===* A föderációs metaadatot a központi helyről kell letölteni (https://rr:3.aai3.niif2.hu/metadata/hrefAjánlott a SAML2 Single Logout profil támogatása HTTP-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ávalRedirect illetve SOAP binding felett.
=== 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:3.** a lokális attribútum-kiadási szabályokat ajánlott külön filter állományban tárolni4.* 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 köteles minden végpontját HTTPS (tehát adatbázisban tárolniSSL/TLS)protokollok segítségével védeni.
= Egyéb =* Hardver követelmények** Rack / szerverszoba / klíma:3.5. Az IdP minden SAML végpontjának az IdP-t üzemeltető intézmény tulajdonában álló DNS domainnek, etc** UPS* Szoftver követelmények** LTS OS** NTP* Hálózati követelmények* redundáns, legalább 100mbitvagy az alatt levő névnek kell lennie.
= Források =[http://www3.switch6.ch/aai/support/bcp/idpAz IdP által használt scope-1oknak az IdP-t üzemeltető intézmény tulajdonában álló DNS domainnek, vagy az alatt levő névnek kell lennie.0.html SWITCH - Best current practices for operating a SWITCHaai Identity Provider]
→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.)
=== Naplóállományok =3. Üzemeltetési kérdések ==* 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.
: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.
:3.2. Az AAI infrastruktúra komponensei esetén kötelező legalább 2048 bites kulcsok használata.
::3.2.3. Ajánlott hosszú lejáratú, self-signed tanúsítványok használata.
