Perun
Aktuální systém Perun
Popis aktuálního systému Perun najdete na perun.metacentrum.cz
Historie vývoje systému Perun
Motivace
S přibývajícím počtem serverů a pracovních stanic i programového vybavení a komplikujícími se vztahy oprávněného přístupu uživatelů k těmto prostředkům vznikla původně v Brněnském superpočítačovém centru nutnost jejich striktně centralizované správy.
Výchozí požadavky na systém realizující centralizovanou správu lze shrnout do následujících bodů:
- centrální databáze vynucující komplikovaná pravidla integrity dat
- okamžité promítnutí změn v datech do konfigurace ovlivněných služeb
- rozdělení privilegovaného přístupu mezi více správců
- kvalitativní (další služby) i kvantitativní (řádový nárůst objemu dat) rozšiřitelnost systému
- úroveň bezpečnosti srovnatelná s dalšími používanými prostředky (Kerberos, AFS)
V první etapě jsme uvažovali o použití a případných modifikacích systému Moira vyvinutého na MIT v rámci projektu Athena. Nakonec jsme však jeho nasazení z několika důvodů odmítli. Návrh tohoto systému nepředpokládá využití technologií, které nabízejí současné komerční relační databáze (deklarativní integritní omezení, databázové triggery, signalizace událostí), což se odráží v implementaci integritních omezení poměrně těžkopádným procedurálním rozhraním. Systém také neumožňuje okamžitou propagaci změn. Tyto a další důvody vedly k rozhodnutí implementovat pro správu výpočetních prostředků zcela nový systém.
Architektura systému
Systém Perun je vyvíjen na Ústavu výpočetní techniky MU od roku 1996. Systém je postaven nad relační databází Oracle, současná produkční implementace nad verzí databáze 9.1. Protože systém využívá řady vyšších rysů této databáze, je jeho přenositelnost na jiný databázový systém problematická, i když pravděpodobně ne zcela vyloučena. Aktuální informace o současném stavu architektury Peruna lze najít v technické zprávě (PDF formát, PS formát).
Datové schéma
Současné datové schéma obsahuje cca 50 tabulek. Jedním z hlavních cílů jeho návrhu bylo zajištění konzistence dat přímo na úrovni databáze, zejména použitím deklarativních integritních omezení. V případech, kde to kvůli omezeným možnostem relačního modelu není možné, je integrita dat vynucena databázovými triggery (procedura, která je spouštěna asynchronně na základě určité databázové události, např. vložení nebo smazání záznamu v tabulce, a jejíž úspěšné dokončení podmiňuje úspěch celé operace, která její vyvolání způsobila). Uživateli - správci je tak umožněn přístup k datům veškerými prostředky jazyka SQL, přitom je ale prakticky vyloučeno databázi modifikovat tak, aby obsahovala nekonzistentní data.
Služby
Ze systému Moira byla převzata koncepce tzv. služeb. Službou rozumíme jistou přesně definovanou, pokud možno minimální a nezávislou, konzistentní jednotku správy počítačových zdrojů. Např. služba PASSWD pokrývá soubory /etc/passwd (seznam uživatelů na konkrétním počítači) a /etc/shadow (jejich hesla a doba platnosti účtů). Je zřejmé, že nemá smysl tuto službu dále dělit a měnit každý z těchto souborů zvlášť. Obecně je samozřejmě specifikace každé služby výsledkem kompromisu, vzhledem ke značné provázanosti nelze téměř nikdy vyčlenit zcela nezávislou službu, na druhou stranu při zachování přijatelného rozsahu není třeba z důvodů efektivity dělit služby na příliš malé úseky.
Propagace změn
Provedení libovolné změny v databázi je okamžitě sadou triggerů vyhodnoceno na požadavek změny konkrétní služby na konkrétním počítači a tento požadavek je uložen do fronty. Po definitivním potvrzení (commit) transakce, která změnu vyvolala, je o vzniklých požadavcích vyrozuměn hlavní proces aplikace. Ten na základě logiky implementované už na klientské straně (tj. mimo vlastní databázi) požadavky vyhodnocuje, generuje příslušné konfigurační soubory a bezpečnou a autentizovanou cestou je předává servisním démonům na řízených počítačích. Spolu s konfiguračními soubory je předáván i skript pro aktualizaci příslušné služby, který je po ověření integrity na řízeném počítači proveden, zpravidla s identitou privilegovaného uživatele.
Uživatelské rozhraní
Přístup do databáze je možný, s ohledem na implementaci integritních omezení přímo v databázi, libovolným klientským programem podporujícím připojení k databázi Oracle na požadované bezpečnostní úrovni. Uživatelský přístup je realizován přes webové rozhraní, vesměs realizované v jazyce Java. Členové MetaCentra mají svůj přístup zabezpečen systémem Kerberos.
Pro administraci systému Perun je k dispozici webové rozhraní realizované v jazyce PHP a pro některé specifické úlohy také skripty, spouštěné z příkazové řádky.
Díky popsanému systému generování konfiguračních souborů a jejich propagace na řízené počítače není kromě přístupu do databáze nutná a ani žádoucí žádná jiná interakce uživatelů - správců se systémem (např. spouštění dalších programů, signalizace událostí démonům apod.).
Bezpečnost
Zabezpečení systému se obecně opírá o autentizační systém Kerberos verze 5. Tímto systémem je jednak ověřována identita uživatelů při přihlášení do databáze (adekvátní bezpečnostní úrovně lze ale dosáhnout i jinými prostředky poskytovanými Oraclem), ale zejména je jím zabezpečena propagace změn na řízené počítače.
Požadujeme, aby databázový server a hlavní proces aplikace běžely na počítači, který považujeme za zabezpečený. Na lokálním disku tohoto počítače jsou uloženy důvěryhodné verze skriptů pro aktualizaci služeb a klíče pro autentizaci.
Hlavní proces se v okamžiku aktualizace konkrétní služby krátkodobě autentizuje systému Kerberos na základě bezpečně uloženého klíče, získá lístek, kterým se prokáže servisnímu démonovi na řízeném počítači, a zabezpečeným komunikačním kanálem mu předá vygenerované konfigurační soubory a důvěryhodný aktualizační skript.
Servisní démon převezme konfigurační soubory a skript, uloží je na lokální disk, podle lokálního konfiguračního souboru ověří, zda je oprávněn aktualizovat danou službu, a po ověření integrity získaných souborů skript spustí s identitou privilegovaného uživatele.
Z bezpečnostního hlediska je kritický především kód servisního démona, ten je ale udržován v minimálním možném rozsahu (dohromady méně než 1000 řádků zdrojového kódu v jazyce C), a je tedy poměrně snadno ověřitelná jeho bezpečnost.
Další potenciální riziko představují skripty, ale zde už je (modulo bezpečnost samotného servisního démona) vyloučena možnost úmyslného útoku. Skripty samy jsou také, mimo jiné i vhodným návrhem služeb, udržovány co nejjednodušší (zpravidla méně než 100 řádků skriptu pro sh nebo awk) a jsou navrženy tak, aby možnost zanechání služby v nekonzistentním stavu byla minimalizována i v případě výpadku během provádění skriptu.
Použití v praxi
Systém Perun je v současné době používán v Brněnském superpočítačovém centru pro řízení uživatelských účtů na serverech i pracovních stanicích. Kromě toho slouží také jako autoritativní databáze oprávněných uživatelů METACentra používaná správci všech zapojených uzlů. Záměrně není koncipován jako obecný nástroj pro personalistické účely, s ohledem na použité databázové technologie ale může být s takovými systémy poměrně hladce propojen.
V tomto kontextu začíná vystupovat nutnost synchronizace systému s jinými datovými zdroji. Rozsáhlé a relativně frekventované změny probíhají zejména mezi uživateli - studenty. Správcům je třeba maximálně usnadnit zřízení přístupu nových uživatelů k výpočetním zdrojům a naopak efektivně blokovat neoprávněný přístup bývalých studentů a zaměstnanců.
V letošním roce byla realizována notifikační služba , která informuje uživatele a administrátory o akcích, které byly v systému Perun ukončeny nebo které naopak vyžadují reakci od nich (PDF formát, PS formát).
V budoucnu je plánováno další rozšíření systému Perun o služby zajišťující správu programového vybavení a přístupu uživatelů k němu.