Osvědčené postupy zabezpečení pro Information Protection

  • Článek

Důležité

Verze sady SDK služby Microsoft Rights Management vydané před březnem 2020 jsou zastaralé; aplikace používající starší verze musí být aktualizovány, aby používaly verzi z března 2020. Úplné podrobnosti najdete v oznámení o vyřazení.

Pro sadu SDK služby Microsoft Rights Management Service se neplánují žádná další vylepšení. Důrazně doporučujeme přijmout sadu Microsoft Information Protection SDK pro klasifikaci, popisky a služby ochrany.

Information Protection sady SDK (Software Development Kit) poskytují robustní systém pro publikování a využívání chráněných informací všech typů. Aby systém mohl být co nejsilnější, musí být aplikace s podporou ochrany informací vytvořené pomocí osvědčených postupů. Aplikace sdílejí odpovědnost za udržování zabezpečení tohoto ekosystému. Pokud se identifikují rizika zabezpečení a zmírní se rizika, která vyvstanou během vývoje aplikace, pomůže to minimalizovat pravděpodobnost implementace méně zabezpečeného softwaru.

Tyto informace doplňují právní smlouvu, která musí být podepsána, k získání digitálních certifikátů pro aplikace pomocí sad SDK.

Předměty, na které se nevztahuje

I když jsou následující témata důležitými aspekty vytváření vývojového prostředí a zabezpečených aplikací, jsou pro tento článek mimo rozsah:

  • Správa procesů vývoje softwaru – správa konfigurace, zabezpečení zdrojového kódu, minimalizace přístupu k ladicím kódu a přiřazení priority chybám. Pro některé zákazníky je pro ně důležité mít bezpečnější proces vývoje softwaru. Někteří zákazníci dokonce nařizují, jak má proces vývoje vypadat.
  • Běžné chyby kódování – Informace pro zabránění přetečení vyrovnávací paměti Pokud chcete získat informace o těchto generických chybách a zmírnění jejich dopadu, doporučujeme přečíst si nejnovější vydání knihy Writing Secure Code od Michaela Howarda a Davida LeBlanca (Microsoft Press, 2002).
  • Sociální inženýrství – obsahuje informace o procedurálních a strukturálních zárukách, které pomáhají chránit kód před zneužitím vývojářů nebo jiných uživatelů v organizaci výrobce.
  • Fyzické zabezpečení – Obsahuje informace o uzamčení přístupu k základu vašeho kódu a podepisování certifikátů.
  • Nasazení nebo distribuce předběžné verze softwaru – Obsahuje informace o distribuci beta verze softwaru.
  • Správa sítě – Obsahuje informace o systémech zjišťování neoprávněného vniknutí ve fyzických sítích.

Modely hrozeb a zmírnění rizik

Vlastníci digitálních informací potřebují možnost vyhodnotit prostředí, ve kterých budou dešifrovány jejich prostředky. Prohlášení o minimálních standardech zabezpečení poskytuje vlastníkům informací architekturu pro pochopení a posouzení úrovně zabezpečení aplikací.

V některých odvětvích, jako je například státní správa nebo zdravotnictví, existují procesy certifikace a akreditace a standardy, které se můžou vztahovat na váš produkt. Splnění těchto minimálních doporučení zabezpečení není náhradou za jedinečné požadavky na akreditaci vašich zákazníků. Cílem standardů zabezpečení ale je pomoci vám při přípravě na současné a budoucí požadavky zákazníků. Veškeré investice, které učiníte v raném stadiu cyklu vývoje, tak budou pro vaši aplikaci přínosem. Tyto pokyny jsou doporučení, nikoli formální certifikační program Microsoftu.

V systému služeb pro správu práv existuje několik hlavních kategorií ohrožení zabezpečení, včetně následujících:

  • Únik – Zobrazení informací v neoprávněných umístěních
  • Poškození – Úprava softwaru nebo dat neoprávněným způsobem
  • Odepření – Výpočetní prostředek není k dispozici pro použití.

Tato témata se zaměřují především na situace úniku. Integrita systému rozhraní API závisí na jeho schopnosti v průběhu času chránit informace, což umožňuje přístup pouze k určeným entitě. Tato témata se dotýkají také situací poškození. Problémy s odepřením nejsou pokryty.

Microsoft netestuje ani nekontroluje výsledky testů související s minimálním standardem. Partner zodpovídá za zajištění splnění minimálních standardů. Microsoft poskytuje dvě další úrovně doporučení, které mají pomoct zmírnit běžné hrozby. Obecně platí, že tyto návrhy jsou doplňkové. Například při plnění upřednostňovaných doporučení se předpokládá, že splňujete minimální standardy, pokud není uvedeno jinak.

Standardní úroveň Description
Minimální standard Aplikace, která zpracovává chráněné informace, musí splňovat minimální standard, aby ji bylo možné podepsat pomocí produkčního certifikátu přijatého od Microsoftu. Partneři obecně používají certifikát provozní hierarchie v době konečného vydání softwaru. K ověření, jestli aplikace splňuje tento minimální standard, se používají vlastní interní testy partnera. Splnění minimálního standardu není a nemělo by být považováno za záruku zabezpečení společností Microsoft. Microsoft netestuje ani nekontroluje výsledky testů související s minimálním standardem. Partner zodpovídá za zajištění splnění minimálních hodnot.
Doporučený standard Doporučené pokyny znázorňují cestu k lepšímu zabezpečení aplikací a poskytují informace o tom, jak se sada SDK může vyvíjet při implementaci dalších kritérií zabezpečení. Dodavatelé můžou své aplikace odlišit vytvořením této vyšší úrovně bezpečnostních pokynů.
Preferovaný standard Tento standard je aktuálně definovaná nejvyšší kategorie zabezpečení. Tento standard by měl být cílem dodavatelů, kteří vyvíjejí aplikace prodávané jako vysoce zabezpečené. Aplikace, které se řídí tímto standardem, budou pravděpodobně nejméně zranitelné vůči útokům.

Škodlivý software

Microsoft má definované minimální požadované standardy, které vaše aplikace musí splňovat pro účely ochrany obsahu před škodlivým softwarem.

Import škodlivého softwaru pomocí tabulek adres

Sada SDK ochrany informací nepodporuje úpravy kódu za běhu ani úpravy tabulky IAT (Import Address Table). Tabulka importních adres se vytvoří pro každou knihovnu DLL načtenou do procesního prostoru. Určuje adresy všech funkcí, které vaše aplikace importuje. Jedním z běžných způsobů útoku je úprava záznamů IAT v aplikaci tak, aby například odkazovaly na škodlivý software. Sada SDK zastaví aplikaci, když zjistí tento typ útoku.

Minimální standard

  • Během provádění nelze upravit tabulku adres importu v procesu aplikace. Aplikace určuje mnoho funkcí volaných za běhu pomocí tabulek adres. Tyto tabulky nelze během běhu ani po spuštění změnit. Mimo jiné toto omezení znamená, že nemůžete provádět profilaci kódu v aplikaci podepsané pomocí produkčního certifikátu.
  • Funkci DebugBreak nelze volat z žádné knihovny DLL zadané v manifestu.
  • LoadLibrary nejde volat s nastaveným příznakem DONT_RESOLVE_DLL_REFERENCES. Tento příznak říká zavaděči, že se má přeskočit vazba na importované moduly, což znamená úpravu tabulky importních adres.
  • Zpožděné načítání nemůžete změnit provedením změn za běhu nebo následnými změnami přepínače /DELAYLOAD linker.
  • Zpožděné načítání nelze změnit poskytnutím vlastní verze pomocné funkce Delayimp.lib.
  • Moduly, které jsou načteny ověřenými moduly, nelze uvolnit, zatímco prostředí sady SDK pro ochranu informací existuje.
  • Pomocí přepínače linkeru /DELAY:UNLOAD nemůžete povolit uvolnění zpožděných modulů.

Nesprávná interpretace licenčních práv

Pokud vaše aplikace správně interpretuje a vynucuje práva vyjádřená v licenci pro vystavování sady SDK, můžete zpřístupnit informace způsobem, který vlastník informací neměl v úmyslu. Pokud například aplikace umožňuje uživateli uložit nešifrované informace na nové médium, když licence k vystavování pouze uděluje právo zobrazit informace.

Azure Information Protection (AIP)

Systém ochrany informací organizuje práva několika seskupení. Další informace najdete v tématu Konfigurace práv k používání pro Azure Information Protection.

AIP umožňuje uživateli dešifrovat informace, nebo ne. Informace nemají žádnou základní ochranu. Pokud má uživatel právo dešifrovat, rozhraní API ho povolí. Aplikace je zodpovědná za správu nebo ochranu informací, jakmile jsou v jasném stavu. Aplikace zodpovídá za správu svého prostředí a rozhraní, aby se zabránilo neoprávněnému použití informací. Pokud například licence udělí oprávnění VIEW, zakažte například tlačítka Tisk a kopírování . Vaše testovací sada by měla ověřit, že aplikace funguje správně u všech licenčních práv, která rozpozná.

Minimální standard

  • Implementace práv XrML v.1.2 pro zákazníka by měla být konzistentní s definicemi těchto práv, jak je popsáno ve specifikacích XrML, které jsou k dispozici na webu XrML (http://www.xrml.org). Veškerá práva, která jsou specifická pro vaši aplikaci, je potřeba definovat pro všechny entity, které mají o vaši aplikaci zájem.
  • Testovací sada a testovací proces by měly ověřit, že se vaše aplikace správně spustí s právy, která aplikace podporuje. Měl by také ověřit, že nefunguje na nepodporovaných právech.
  • Pokud vytváříte aplikaci pro publikování, musíte zpřístupnit informace, které vysvětlují použitá vnitřní práva. To zahrnuje ty, které jsou a nejsou podporovány aplikací publikování a jak by se tato práva měla interpretovat. Kromě toho by měl koncový uživatel z uživatelského rozhraní jasně vědět, jaké jsou implikace přidělení nebo zamítnutí jednotlivých práv u jednotlivých informací.
  • Všechna práva abstrahovaná zahrnutím nových práv implementovaných aplikací musí být namapována na novou terminologii. Například nové právo s názvem SPRÁVCE může zahrnovat abstrahovaná práva TISK, KOPÍROVAT a UPRAVIT.

V tomto okamžiku není žádné.

Preferovaný standard

V tomto okamžiku není žádné.

Další kroky

Osvědčené postupy pro implementaci aplikací pomocí sady AIP SDK zahrnují následující články: