Seriál Lotus Notes: Bezpečnost
Systémy Lotus Notes/Domino si po celé dvě desítky let své existence zakládají na vysoké bezpečnosti. V tomto díle představíme všechny klíčové bezpečnostní principy, které Lotus Notes používají.
Hierarchické certifikáty
Každý subjekt v Lotus Domino má svoji jednoznačnou identitu - tou je hierarchické jméno uživatele nebo serveru. Jednotlivé stupně hierarchie se oddělují lomítkem, například: Jan Novak/Obchod/Firma, Frantisek Pokorny/Vyroba/Firma, Domino1/App/Brno/Firma. Nejjednodušším případem je Jan Novak/Firma a Server/Firma; jeden stupeň v hierarchii je vždy povinný.
Zápis je velmi podobný syntaxi zápisů v LDAPu (cn=Jan Novak, dc=Obchod, dc=Firma). I tady je nejvyšší stupeň v hierarchii umístěn co nejvíce vpravo.
Každý ze stupňů má svůj certifikační klíč, s nímž jsou jednak registrovány a certifikovány subjekty na dané úrovni, ale také vytvářeny stupně nižší. Nejvyšší stupeň hierarchie se v Lotus Notes nazývá organizace, nižší stupně potom organizační jednotka. Při zápisu se uvozují lomítkem na začátku. V našem případě je tedy "/Firma" jméno organizace, "/Obchod/Firma" a "/Vyroba/Firma" jsou organizační jednotky a "Jan Novak/Obchod/Firma" je plné hierarchické jméno uživatele.
Je výhodné volit jména organizačních jednotek tak, aby měla určitý význam - například jména divizí, sídla poboček a podobně.
Fyzicky je každý subjekt, ať se jedná o uživatele, server nebo certifikační jednotku, reprezentován Notes ID souborem. Tři základní ID soubory jsou proto vytvářeny již při instalaci prvního serveru Domino ve firmě (viz 1. díl seriálu). Jsou to ID soubory pro organizaci (cert.id), server (server.id) a prvního uživatele, který je současně administrátorem systému (admin.id).
Tyto soubory musejí být zálohovány a nesmíte zapomenout hesla, která jste jim přiřadili. Pokud ztratíte soubor cert.id (nebo k němu zapomenete heslo), přijdete o nejvyšší bod vaší bezpečnostní hierarchie a budete muset znovu vytvořit nové certifikáty a následně přecertifikovat všechny servery i uživatele.
Výhody hierarchických certifikátů:
- Distribuovaná správa uživatelů. Uživatele může registrovat pouze ten, kdo má přístup k certifikačnímu ID dané jednotky. Tím, že se vytvoří podřízené organizační jednotky (například pro každou pobočku), může uživatele registrovat a spravovat místní administrátor. Navíc je tak zajištěna i zodpovědnost jednotlivých administrátorů, protože není nutno předávat jeden centrální cert.id soubor všem, kdo chtějí zakládat nové uživatele.
- Přehlednost. Zejména ve větších společnostech jde z celého hierarchického jména uživatele poznat, do jaké divize patří, nebo ve které zemi či pobočce pracuje.
- Seskupování. Podle hierarchických certifikátů lze vytvářet automaticky plněné skupiny (např. UsersBrno = */Brno/Firma) nebo povolovat přístup k databázím (*/Firma = Readers, */Servers/Firma = Managers).
Přístup k serveru
Aby se mohl uživatel s klientem Lotus Notes připojit k serveru Lotus Domino, musí mu server povolit přístup. To je první bezpečnostní "kontrola" při přístupu k datům v databázích. Současně si klient Lotus Notes ověří, že přistupuje ke správnému serveru. Jedná se o obdobnou situaci jako například při používání elektronického bankovnictví.
Přestože navenek jsou vidět pouze hierarchická jména osob a serverů, při úvodní komunikaci klienta a serveru se používají soukromé a veřejné klíče uložené v každém ID souboru. Současně je v ID souboru uložen také certifikát od nadřízené organizační jednotky, která uživatele nebo server registrovala - to vše se při úvodní autentizaci ověřuje. Útočník, který si tedy sám doma vyrobí ID soubor Jan Novak/Firma a bude se snažit vydávat za opravdového Jana Nováka, neuspěje. Takový pokus o přístup neprojde hned prvním sítem kontroly, protože server pozná, že útočníkovo ID nebylo vytvořeno stejnou certifikační jednotkou jako serverové ID (přestože se obě jmenují /Firma).
Základním pravidlem, jenž platí pro instalaci serveru, je, že přístup k serveru mají povolen všichni uživatelé a všechny servery, které mají ve své hierarchii nějakého společného činitele, společnou "nadřízenou" organizační jednotku. Může jí být i ta na nejvyšší úrovni, tedy /Firma.
Příklady: K serveru Domino1/App/Brno/Firma může přistoupit uživatel Jan Novak/Obchod/Firma, Hana Prochazkova/Vyroba/Firma i server DominoBackup/Praha/Firma. Mají společnou certifikační jednotku /Firma. Naopak přístup nemá povolen Karel Novy/FirmaB.
Často se stává, že dvě společnosti používající Lotus Notes si chtějí prostřednictvím tohoto systému vyměňovat data. A nemusí jít jen o dvě různé firmy, často se takto propojují národní pobočky velkých firem, které si však zároveň udržují svoji oddělenou strukturu certifikátů. V takovém případě si musejí servery mezi sebou nejdříve vyjádřit oboustrannou důvěru - vytvořit tzv. křížový certifikát, pomocí kterého je povoleno k vybraným serverům společnosti "Firma" přistupovat i s certifikáty, které vydala jiná společnost, například "FirmaB".
Následně je třeba na serverech povolit přístup i pro jiné uživatele či servery, tedy pro ty, kteří nejsou uvedeni v names.nsf. To lze nastavit tak, že v Server dokumentu pro váš server přejdete na záložku Security, sekce Server Access (vlevo dole). Klíčová jsou políčka Access server a Not access server. V uvedeném případě byste nastavili pole takto:
Access server: zaškrtněte checkbox users listed in all trusted directories a přidejte ručně subjekty z druhé firmy, tedy Karel Novy/FirmaB.
Pole Not access server nechejte prázdné.
Pole Not access server se často používá ve spojení se skupinou typu Deny list only, kam přiřazujete uživatele, kteří už u vás nepracují. Je tak zaručeno, že i když si odnesou své původní Notes ID mimo firmu, servery je k sobě už nepustí.
Pozor! S polem Access server zacházejte opatrně. Když si nejste jisti, vždy mějte zaškrtnut check box users listed... Je-li totiž pole Access server prázdné, přístup se kontroluje jen vůči zakázaným uživatelům v Not access server. Je-li ovšem v poli Access server alespoň jedna hodnota, potom lidé a skupiny, kteří jsou tam uvedeni, jsou jediní, kteří mohou k serveru přistupovat. Jsou známy i případy, kdy si začínající administrátoři tímto způsobem sami odřízli přístup k serveru nebo naopak nechtěně povolili přístup jen sobě a nikomu jinému (dokonce ani serverům).
Přístup k databázi
To, zdali má uživatel přístup k určitému serveru, si může snadno ověřit. Stačí vyvolat příkaz File - Open - Application (nebo CTRL + O) a v horním řádku vybrat nebo ručně napsat jméno požadovaného serveru. Je-li přístup povolen, objeví se ve spodním okně seznam databází, které se na serveru nacházejí.
Potom přichází ke slovu další bezpečnostní kontrola - kontrola přístupu k databázi - autorizace. Každá databáze má svůj tzv. Seznam přístupových práv (ACL - Access Control List). V něm je uložen seznam oprávnění, která správce databáze přiděluje jednotlivým osobám, serverům či skupinám. Existuje sedm základních úrovní přístupu - Bez přístupu, Zapisovatel, Čtenář, Autor, Editor, Návrhář a Manažer (No Access, Depositor, Reader, Author, Editor, Designer, Manager).
Máte-li přístup k databázi alespoň jako Reader, můžete databází procházet, vidět dokumenty a otevírat je. K seznamu přístupových práv pro danou aplikaci se dostanete přes menu File - Application - Access Control.
Přístup k dokumentu
To, že má uživatel přístup k databázi, ovšem nemusí nutně znamenat, že má stejný přístup i ke všem dokumentům. Vývojáři aplikace mohou totiž nastavit její vnitřní logiku tak, že některé dokumenty budou moci vidět či editovat pouze vybraní uživatelé či skupiny uživatelů.
Příklad: Personální databáze - skupina personalistů vidí dokumenty o všech zaměstnancích, manažer vidí dokument svůj a svých podřízených a zbytek zaměstnanců vidí pouze svůj dokument. Pro řízení takového přístupu se nejčastěji používají tzv. Readers/Authors Fields, tedy Pole čtenáři/autoři. Není-li uživatel uveden v Readers Field, nebude mu dokument zobrazen, přestože má k databázi práva Reader. Vývojáři pomocí těchto dvou typů polí řídí přístup k různým částem databázového obsahu s mnohem větší granularitou, než by byli schopni jen za pomocí ACL, tedy řízení přístupu k celé databázi.
Součástí bezpečnostních nástrojů Lotus Notes/Domino není jen autentizace (ověření identity) a autorizace (ověření práva přístupu k prostředku), ale i sada nástrojů, které zajišťují, aby se citlivý obsah nedostal do nepovolaných rukou. A to ani v případě odposlechu komunikace či krádeže notebooku.
Šifrování přenosu
Přistupují-li zaměstnanci k serverům Lotus Domino z vnější, nezabezpečené sítě, nebo pokud se servery propojují se servery jiné partnerské společnosti (kvůli routování pošty a replikování databází), může se vyplatit funkce, která umožňuje na těchto přenosových kanálech zapnout šifrování přenášených dat.
Tato funkce se nazývá šifrování portu (Network port encryption) a dá se nastavit jak na straně serveru, tak na straně klienta. Po navázání spojení potom stačí, aby jeden z dvojice měl zapnuto šifrování portu, a dojde k šifrování přenášených dat prostřednictvím tohoto síťového portu.
V klientském programu Lotus Notes se tato funkce zapíná v hlavním nastavení File - Preferences - Notes Ports. V pravém panelu potom vyberte příslušný port (v současnosti to bývá téměř výlučně TCPIP) a dole zaškrtněte checkbox Encrypt network data.
Na straně serveru se porty ovládají nejlépe přes Administračního klienta. Připojte se z něj k požadovanému serveru a na záložce Configuration vyberte vpravo v liště příkaz Server - Setup ports. Další postup už je shodný s nastavením klienta.
Poznámka: V praxi se zapíná šifrování portu nejčastěji na vnějším serveru, který je umístěn v DMZ (demilitarizovaná zóna) a slouží jako průchozí server pro uživatele přistupující z nezabezpečeného prostředí internetu.
Šifrování databáze
Lotus Notes vám také umožní šifrovat data ukládaná na pracovních stanicích uživatelů - jako jsou lokální repliky poštovních schránek a dalších aplikací, se kterými chtějí uživatelé pracovat i offline. Zajišťuje to tzv. šifrování databáze (Database encryption).
Standardně se databáze nešifrují. Pokud by někdo odcizil notebook s lokálně uloženými databázemi (tedy NSF soubory), mohl by si je zkopírovat k sobě, do svého vlastního klienta Lotus Notes a otevřít je lokálně pod svým Notes ID.
Zapne-li se šifrování databáze, znamená to, že její obsah se zašifruje pomocí veřejného klíče uživatele či serveru a otevřít ji bude moci jen ten, kdo má odpovídající soukromý klíč - což je právě jedna konkrétní osoba či server s příslušným Notes ID.
Šifrování lokální databáze si může zapnout každý uživatel sám, přes menu File - Application - Properties. Na první záložce tlačítko Encryption Settings a dále vybrat Locally encrypt this database.
V tu chvíli se databáze zašifruje na aktuálně přihlášeného uživatele a otevřít ji bude moci pouze on. Stejným způsobem se šifrování databáze vypíná.
Obdobně lze šifrovat databáze i na serveru. V takovém případě se k zašifrování nepoužije klíč aktuálně přihlášeného uživatele, ale serveru, na kterém tato databáze leží. Znamená to, že uživatelé i ostatní servery mohou k této databázi na serveru DominoA přistupovat z klientů Lotus Notes a replikovat ji (při tom se provedou všechny již popsané kontroly přístupu k serveru, k databázi a k dokumentu), ale databázi nebude možné na "nízké úrovni", tedy na úrovni operačního systému, překopírovat někam jinam jako soubor NSF.
Popsaný postup nastaví šifrování vždy pro jednu konkrétní databázi. Chcete-li to udělat hromadně, máte jako administrátor dvě možnosti:
- Databáze uložené na serveru lze rychle procházet z Administračního klienta, záložka Files. Přes kontextovou nabídku (pravé tlačítko myši) vyberte Properties a postupujte stejně jako u lokální databáze.
- Šifrování databází na straně klienta lze řídit pomocí uživatelských politik (jsou to jakési profily uživatelů), kde můžete nastavit povinné šifrování všech databází, které si uživatel na svůj počítač zreplikuje. Jedná se o Desktop Settings, záložka Preferences - Replication, pole Encrypt replicas.
Shrnutí
V tomto článku jsou pokryty tři důležité oblasti bezpečnosti Lotus Notes:
Hierarchická jména uživatelů a způsob jejich vytváření pomocí certifikačních jednotek.
Autentizaci a autorizaci - administrátor může řídit přístup uživatelů k serveru, databázi i jednotlivým dokumentům.
Šifrování přenosových kanálů a databází jako způsob obrany proti útokům, které se snaží obejít výše popsaná pravidla řízení přístupu pomocí odposlouchávání nebo kopírováním souborů na úrovni souborového systému.
Předchozí: Portal NOW - seminář pro partnery
Následující: Certifikační den 30. 10. 2009