565
szerkesztés
Módosítások
Üzemeltetési kérdések
= Ü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 =
