Vítejte na blog.vyvojar.cz Přihlásit | Registrovat | Pomoc
Titulní Blogy Fotky Soubory

Mazinův blog o SharePointu

IRM/RMS

Problém zabezpečení přístupu k informacím řeší organizace typicky ukládáním těchto informací do nejrůznějších IS, které mají mechanizmy na řízení přístupu. I když platí obecné principy a existují i bezpečnostní normy, každý z nich k tomu přistupuje trochu jinak. Společným slabým místem těchto systémů ale bývá okamžik, kdy informace tento informační systém opouští. Pak jsou obvykle nechráněné.

Protože je můj blog věnovaný především SharePointu ukažme si na něm modelový příklad:

Máme v organizaci nainstalovaný SharePoint a v něm fungující DMS. Toto DMS má sofistikovaný systém řízení přístupu k jednotlivým dokumentům, protože zahrnuje i velmi citlivé dokumenty, např. akt. obchodní nabídku pro významné obchodní partnery ve Wordu. Nastavení práv na zmíněné nabídce zahrnuje právo úprav pro členy obchodního oddělení. V konečné fázi přípravy dokumentu dostane právo čtení i grafické oddělení, které má za úkol nabídku zkontrolovat z hlediska grafického standardu organizace. Samo měnit dokument nemůže, pouze má do připraveného formuláře vyplnit připomínky. Jenže kterýkoliv zaměstnanec grafického oddělení může ve chvíli, kdy dokument otevře ve Wordu, uložit dokument jinam (nebo obsah dokumentu označí a vykopíruje mimo). Tím nad ním získá úplnou kontrolu, takže je schopen daný dokument upravit a vytvořit tak podvrh. Stejně tak může dokument přeposlat emailem konkurenci.

Řešením problémů ochrany informací i za hranicí běžných IS může být technologie Information Right Management (IRM). Cílem IRM je chránit obsah dokumentů přímo na úrovni těchto dokumentů, tzn. práva přístupů k informacím v dokumentu jsou součástí dokumentu jako takového a není možné je oddělit. Abych byl technologicky přesný slovo dokument je zde míněno jako kontainer informací, ale může jím být i email (a jeho přílohy), jak uvidíme dále. Podobnou technologii používá Adobe k ochraně PDF dokumentů.

Tato technologie nemá nic společného s možností elektronicky podepisovat dokumenty. Mohou se vzájemně doplňovat, protože každá z nich řeší jiný aspekt ochrany informací. IRM řeší otázku toho, kdo co může dělat s informacemi v dokumentu. Elektronický podpis řeší otázku původu a celistvosti dat. Jinými slovy řečeno zajišťuje to, že příjemce informace si může ověřit, že autorem je opravdu ten, kdo se za něj označuje (např. podpisem v textu dokumentu, nebo jako autor emailu, který informaci odeslal) a to, že se informace od jejího vytvoření nezměnila (že dokument nikdo od jeho podpisu nezměnil).

Popis RMS

Microsoft implementoval technologii IRM hned 2x. Obě tyto implementace jsou užitečné a na sobě v zásadě nezávislé. Obě implementace se označují jako Right Management Service (RMS). Jedna implementace je spojena s technologií LiveID a druhou Microsoft implementoval do Windows 2008 (R2). Ta je označovaná jako AD RMS. AD znamená Active Directory. Jak už její název napovídá je integrovaná s Active Directory.

RMS je koncipováno jako klient server řešení. Klient publikuje informace a/nebo se je pokouší číst. Server se stará o to, aby se informace nedostaly do nepovolených rukou. Serverovou stranou je buď LiveID infrastruktura, nebo AD RMS. Klientská část se skládá ze dvou částí:

  1. RMS klient, který je standardní součástí Windows od verze Vista ale dá se stáhnout a doinstalovat do Windows od verze Windows 2000 SP4. RMS klient je společný pro obě serverové implementace (LiveID i AD RMS).
  2. RMS aplikace. To je software, který používá RMS klienta (nekomunikuje tedy se serverovou částí přímo), a s jeho pomocí umožnuje chránit informace nebo k chráněným informacím přistupovat. Tato aplikace vlastně zajišťuje projevy práv z RMS (např. to, že nelze dokument tisknout, že ho lze otevřít pouze pro čtení, ...). Z Microsoftích programů sem patří především programy z rodiny Office (Outlook, Word, Excel, PowerPoint,...). Vzhledem k tomu, že existuje i SDK pro komunikaci s RMS klientem, je možné vytvářet i vlastní aplikace.
Při popisu RMS se používají následující klíčové pojmy:
  • Autentizační server - tento server autentizuje uživatele, vydává jim RAC
  • RAC - certifikát vydaný autentizačním serverem, který potvrzuje identitu uživatele.
  • Licenční server - tento server na základě dodané RAC a licence k publikování vydává licenci pro použití uživateli s odpovídajícím RAC
  • Licence k publikování - seznam omezení, která se vztahují k publikovaným informacím (dokumentu)
  • Licence k použití - seznam omezení pro konkrétního uživatele
Role autentizačního a licenčního serveru typicky zastává jeden server. Ale jak si ukážeme dále při použití AD RMS, mohou být tyto role odděleny.

Jak to celé funguje v praxi si nejlépe vysvětlíme, když si popíšeme proces publikace informace a pokusu o přístup k informaci. Než se pustíme do dalšího popisu, ještě bych se chvíli zdržel u technické stránky věci. Obsah dokumentů (emailů) je zašifrován pomocí AES s využitím 256 bitů náhodně generovaného klíče. Dále se v jednotlivých fázích intenzivně využívá kryptografie veřejného klíče (RSA s klíčem 2048b). Tzn. je to postaveno na kvalitních kryptografických základech. Proto bychom se neměli (alespoň v dohledné době) dočkat utilit typu "RMS key recovery", jako je tomu při ochraně dokumentů pomocí hesla. Samozřejmě za předpokladu, že tam kluci z Redmontu neudělali někde chybu při implementaci.

Publikace informace - stručný popis

  1. Autor (resp. RMS aplikace) informace kontaktuje (pomocí RMS klienta) RMS server a získá jeho veřejný klíč.
  2. Autor vygeneruje výčet toho, kdo a co smí s chráněnou informací dělat a vygeneruje náhodný symetrický klíč, kterým bude informace chráněna.
  3. Obě tyto informace zašifruje veřejným klíčem RMS serveru, odešle mu je.
  4. RMS server ze zaslaného seznamu oprávnění a šifrovacího klíče vygeneruje licenci k publikování, kterou podepíše a zašifruje svým veřejným klíčem. Součástí licence je i nezašifrovaná (ale el. podepsaná) část, která obsahuje např. adresu RMS serveru.
  5. Licenci pošle zpět autorovi.
  6. Autor provede zašifrování informace (dokumentu) symetrickým klíčem a připojí k němu licenci k publikování.

Přístup k informaci

  1. Ten, kdo chce přistoupit k chráněné informaci, vezme k informaci připojenou licenci k publikování.
  2. Z této licence zjistí adresu RMS serveru.
  3. Pokud nemá RAC, pokusí se jej získat z RMS serveru (odpovídá to postupu získání certifikátu. Tzn. klient si vygeneruje privátní klíč a odpovídající veřejný klíč odešle v žádosti na server. Ten na základě žádosti vystavý certifikát).
  4. Na RMS server odešle RAC a získanou licenci k publikování (je součástí dokumentu).
  5. RMS server licenci rozšifruje svým privátním klíčem.
  6. Zjistí, co s příslušnou informací může dělat uživatel s odpovídajícím RAC.
  7. Pokud uživatel může dělat alespoň něco, vytvoří RMS server licenci k použití (jejíž součástí je i klíč pro rozšifrování chráněné informace) pro daného uživatele a zašifruje ji jeho veřejným klíčem (je obsažen v RAC).
  8. RMS klient použije privátní klíč uživatele (protikus k RAC) a licenci k použití rozšifruje. Tím je zajištěno, že licenci získá skutečný vlastník RAC.
  9. Získanou licenci předá RMS aplikaci, aby zajistila aplikaci práv.
  10. Získanou licenci si RMS klient drží po dobu její platnosti. Pokud během té doby chce RMS aplikace pracovat s informací, RMS klient ji to umožní bez nutnosti komunikace s RMS serverem.

Detaily najdete zde v tomto PDF dokumentu.

Jak to funguje v Office aplikacích

Jak jsem uvedl dříve je technologie IRM použita v Office programech. Na pár sceenshotech si ukážeme, jak vypadá nastavování práv v Office aplikacích:

Nastavení RMS na dokumentu

 Základní nastavení práv

Další možnosti 

Office program Možnosti
Word Standardní možnosti:
  • Pouze čtení
  • Měnit dokument
  • Omezení platnosti dokumentu
  • Omezeni možnosti tisknout dokument
  • Omezení možnosti vykopírovat obsah dokumentu
  • Omezení možnosti přistupovat k obsahu dokumentu programově

Navíc lze omezit, že uživatel může používat pouze omezené styly nebo může pouze vkládat poznámky, vyplňovat formulářová pole, upravovat dokument v režimu sledování změn. Tyto možnosti ale nevyužívají RMS a jsou chráněny zadaným heslem.

Excel Standardní možnosti. Má i další možnosti jako je ochrana jednotlivých listů (omezení možnosti měnit formáty buněk,...) a omezení možnosti přidávat a ubírat listy. Tyto možnosti ale nevyužívají RMS a jsou chráněny zadaným heslem.
PowerPoint Standardní možnosti
Outlook Nepředávat dále" (do not forward) - toto právo znemožní uživateli přeposlat email, ale ani vytisknout ho, uložit, nebo kopírování jeho obsahu. Totéž platí u příloh tohoto emailu.
OneNote, Visio, Access, InfoPath nepodporují RMS

Ještě si ukážeme, jak vypadá chráněný email, když ho pošleme někomu, kdo nemá emailového klienta podporujícího RMS:

V tomto případě se jedná o email odeslaný na adresu gmailu zobrazený pomocí webového rozhraní v Internet Exploreru bez nainstalovaného RMS addonu. Z obrázku je patrné, že pokud nemá příjemce správnou aplikaci, ke chráněnému obsahu se nedostane. Pokud totiž email přijme pomocí Outlooku (pomocí protokolu POP3 nebo IMAP), zobrazí se správně.

LiveID vs. AD RMS

Jak jsme si už řekli, Microsoft implementoval IRM do služeb okolo LiveID a jako službu v Active Directory. Podíváme se na jejich srovnání. Obě varianty mají společné to, že jako identifikátor uživatelů, na které se práva vztahují, se používá email.

LiveID

Využití LiveID je výhodné:

  1. v situaci kdy nemáte k dispozici AD RMS. Jeho činnost je totiž vázána na doménu.
  2. když máte k dispozici AD RMS, ale ten, pro koho chcete dokument zabezpečit, k němu přístup nemá. Jak už jsem zmiňoval, otevření chráněného dokumentu vyžaduje získání licence k použití. To může být problém, zejména pokud adresát dokumentu je mimo vaši organizaci a nemá přístup do sítě organizace. Typicky obchodní partner.
  3. protože není potřeba nic dalšího, stačí jen, aby autor a adresát měli LiveID účty. Pokud používají nějaké služby Microsoftu, které vyžadují přihlášení, tak už LiveID účet určitě mají.
  4. je to zdarma.

Nevýhody:

  1. Nedá se to spravovat. LiveID má v ruce Microsoft.
  2. Pokud chci poslat někomu dokument, musím znát jeho email, resp. musím znát email, který má zaregistrovaný v LiveID. To může být problém, zvlášť pokud adresát používá několik emailů (ale i aliasů). Pak musí mít pro každý z nich vytvořený i LiveID účet.

V případě, že chcete používat IRM (pokusíte se nastavit na nějakém dokumentu IRM oprávnění) a nemáte v doméně nainstalovaný AD RMS a ještě jste si nenakonfigurovali používání LiveID, spustí se průvodce. V tomto průvodci určíte, který LiveID účet budete při práci s IRM používat. Je možné mít nakonfigurováno několik LiveID účtů.

AD RMS

AD RMS je vlastně následovník produktu RMS, který nabízel Microsoft samostatně. Nyní je to serverová role

Oproti tomu AD RMS poskytuje následující výhody:

  1. Při definici práv se pracuje s uživateli domény, nemusím znát jejich email.
  2. Uživatel nemusí nic konfigurovat.
  3. Dají se použít i skupiny, ale jen ty co mají definovaný email (licence k použití je vydána všem členům příslušné skupiny)
  4. Dají se definovat vlastní práva
  5. Dají se definovat šablony - tzn. můžeme vytvořit např. šablonu "Supertajný dokument", která bude mít definováno, že takto označené dokumenty smí upravovat pouze nejvyšší vedení a číst pouze výkonná rada, nesmějí se tisknout a jejich platnost vyprší po 1 měsíci od vytvoření.
  6. Již publikovaný obsah lze odvolat. V případě zneužití informací lze licenci k publikování zařadit do seznamu odvolaných licencí a v takovém případě budou informace touto licencí chráněné již nedostupné (resp. další žádosti o licenci k použití budou zamítány, vydané žádosti zůstanou platné).
  7. Lze nastavit dobu platnosti licence pro použití. V krajním případě lze nastavit, že vyprší okamžitě při jejím získán, takže ji musí uživatel získat při každém otevření dokumentu.
  8. Získání licence k přístupu se loguje. Je tedy možné sledovat, kdo a kdy s chráněnými dokumenty pracoval.
  9. Integratovatelnost s SharePointem a Exchange.

Nevýhody:

  1. Aby to uživatelům fungovalo, musí mít přirazený email. Bez toho mu budou RMS aplikace Microsoftu (Office) nabízet možnost použití LiveID. V praxi to asi nebude problém, ale pozor při testování! Sám jsem si na toto naběhl.
  2. Je potřeba aby uživatelé měli AD RMS CAL. Ten není součástí standardního Windows CALu (podobně jako je to s CALem na terminálové služby)

Rozchodit se to dá poměrně snadno. Existuje k tomu Step-by-step dokument. RMS klienti komunikují s RMS serverem pomocí HTTP a HTTPS protokolů. Součástí instalace proto je i instalace IIS (pokud už tedy není nainstalován) a zprovoznění 2 webů. Dá se to nainstalovat ve dvou režimech, které se liší tím, kam a jak se ukládají informace spravované AD RMS serverem:

  • Vlastní interní databáze
  • Zadaný SQL server
Je na to další role s vlastní admin konzolí, kde se:
  1. Dají definovat šablony:
    1. Pojmenuje se v několika jazycích
    2. definuji se práva
    3. omezí se platnost obsahu [počet dnů, konkrétní datum, nikdy]
    4. dají se definovat i vlastní práva (a používat je ve vlastních aplikacích)
    5. to jestli lze obsah zpřístupnit v IE pomocí addonu
    6. omezení platnosti licence na určený počet dnů nebo na jednorázové
    7. dají do licence zabalit KeyPair hodnoty
    8. dá se nastavit to, zda může být obsah chráněný šablonou odvolatelný
  2. Dají se definovat důvěryhodnosti mezi doménami a jednotlivými RMS servery včetně toho, že můžeme nastavit, že AD RMS server bude důvěřovat Rights account certificate (RAC) vystaveným službou LiveID.
  3. Omezovat uživatele, nebo aplikace, verze AD RMS klientů a verze klientských OS, kterým nebudou licence vydávány, např. z důvodů kompromitace.

Spolupráce s SharePointem

SharePoint se dá integrovat s AD RMS a to jak ve verzi 2007 (nejde to s WSS, musí být MOSS), tak 2010 (i s Foundation). Na počítači s webem SharePointu musí být RMS klient. Pokud to je nastaveno, tak dokument uložený v SP je při downloadu opatřen takovými právy, jaká jsou na něm nastavena v knihovně dokumentů. Tím je docíleno toho, že i když takový dokument opouští SharePoint, je jeho obsah chráněn stejně jako uvnitř SharePointu. V SharePointu dokumenty šifrovány nejsou (při uložení dokumentu do SharePointu je dokument rozšifrován). To umožňuje indexaci při prohledávání (nebojte není to bezpečnostní díra, na výsledky hledání se samozřejmě také aplikují práva, navíc citlivé knihovny dokumentů nemusíte indexovat). Ještě důležitější je možná to, že díku dešifrování unitř SharePointu, mohou nad daným dokumentem běžet workflow jejichž činnost je typicky řízena vlastnostmi dokumentu. A protože vlastnosti dokumentu jsou také chráněny IRM (je jím chráněný celý dokument), tak by se k nim SharePoint nedostal.

Nastavení má 2 části. První se odehrává na webu centrální správy, kde se podpora IRM zapíná a zadává se adresa IRM(RMS) serveru:

Nastaveni RMS v centrální administraci

Dále se pak podpora zapíná na úrovni jednotlivých knihoven dokumentů:


Obrázek pochází z anglického SharePointu 2007, ale ve verzi 2010 vypadá stejně. Pro knihovnu dokument; se dá nastavit:

  • jak se má oprávnění, které se na stažené dokumenty aplikují, jmenovat a jaký má mít popis
  • jestli lze dokumenty tisknout
  • jak dlouho bude platit vydaná licence k přístupu
  • jestli mohou uživatelé do dotyčné knihovny dokumentů umístit dokumenty, které nepodporují IRM
  • Omezit do kdy budou dokumenty v knihovně dokumentů opatřovány IRM omezeními

Při stahování dokumentů jsou oprávnění na dokumentu (kromě práv z předchozího seznamu, ta se do RMS nastavení přenáší automaticky) převedena na IRM práva podle následující tabulky:

Oprávnění v SharePointu IRM oprávnění
Spravovat web, Nastavovat oprávnění Přístup bez omezení
Upravovat položku, Spravovat seznamy, přidávat stránky Editace, uložení, tisk
Zobrazit položku Pouze číst
všechna ostatní oprávnění žádná práva

Spolupráce s Exchange 2010

Spolupráce s Exchange 2010, kde se dají definovat pravidla, která emaily a jejich přílohy vybavují IRM obálkou na základě definovaných pravidel (podle odesílatele, příjemce, předmětu zprávy...). Pravidla mohou být volitelná (uživatel je nemusí použít, nebo je může změnit) a povinná. OWA Exchange 2010 už nevyžaduje IE addon pro otevírání zabezpečených zpráv.

Blíže se o IRM v Exchange 2010 můžete dočíst v tomto článku.

Podpora Windows Mobile

Windows Mobile (verze 6.5) podporují pouze "Nepředávat dále" právo.

Závěr

IRM je technologie, která umožňuje chránit informace v dokumentech i poté, co opustí informační systém. Informační systém se naopak typicky snaží chránit přístup k dokumentu jako takovému. Poté co ale chráněný dokument IS opustí, je zcela nechráněn. Myslím si, že díky integraci IRM do SharePointu je možné říci, že informace v dokumentech jsou chráněny od jejich vzniku a po celou dobu jejich existence. To dává pojmu ochrana informací další rozměr. Co mě trochu mrzí je, že v dnešní době, kdy MS masivně podporuje .NET framework, neexistuje RMS SDK právě pro tuto platformu (z .NETu se sice dá volat nativní kod, ale není to to pravé ořechové). I podporu Windows Mobile bych si uměl představit lepší. Taky jsem se nikde nedočetl, jak se IRM a potažmo i MS pere s následující situací: Jako člověk, který touží dostat se k chráněným informacím, si s pomocí RMS API napíšu RMS aplikaci, která se bude chovat podobně jako např. Word s tím ale, že nebude respektovat práva z licence k použití. Jak totiž bylo v článku několikrát zmíněno, za aplikaci (projevy, např. to, že dokument nelze tisknout) práv je zodpovědná právě RMS aplikace.

Zveřejněno Sunday, September 26, 2010 2:45 PM by mazin

Komentář

Žádné komentáře
Neregistrovaní uživatele nemužou přidávat komentáře.

Syndication

News

  • Web Developer
  • Enterprise Application Developer

  • Microsoft Office SharePoint Server 2007, Application Development
  • Microsoft Windows SharePoint Services 3.0, Application Development
  • Microsoft Office SharePoint Server 2007, Configuration
  • Microsoft Windows SharePoint Services 3.0, Configuration
  • .Net Framework 2.0, Distributed Applications
  • .Net Framework 2.0, Web Applications
  • .Net Framework 2.0, Windows Applications
Powered by Community Server (Personal Edition), by Telligent Systems