DLP a Terraform: pravidla Power Platform jako součást kódu

V předchozím článku jsme se podívali na příkazovou řádku v Power Platform. Ukázali jsme si, že vedle vizuálních návrhářů mají své místo také nástroje pro vývojáře a automatizaci.

U tohoto tématu ještě chvíli zůstaneme. Tentokrát se zaměříme na správu platformy a pravidla, která určují, jak mohou aplikace a automatizace využívat konektory.

Konkrétně na DLP politiky a možnost spravovat je pomocí Terraformu.

Proč se zabývat DLP?

Jednou z velkých výhod Power Platform je množství dostupných konektorů. Aplikaci nebo tok můžeme snadno propojit s Dataverse, SharePointem, podnikovým systémem nebo externí službou.

Z pohledu uživatele je to příjemné. Nemusí pro každé propojení čekat na vývoj vlastní integrace.

Z pohledu správy platformy ale potřebujeme řešit také to, jaká propojení chceme umožnit.

Představme si automatizaci, která načítá firemní údaje a předává je do externí služby. Technicky může jít o několik jednoduchých kroků. Z pohledu organizace už ale záleží na tom, o jaká data jde a kam se dostávají.

Právě tady pomáhají DLP politiky — Data Loss Prevention. Nastavují hranice pro používání konektorů a jejich kombinování v aplikacích a tocích. Pomáhají tak snižovat riziko nechtěného sdílení firemních dat.

Business, Non-Business a Blocked

V tomto článku pracujeme s klasickými DLP politikami, které rozdělují konektory do tří skupin:

Důležité je, že Non-Business neznamená zablokovaný. Konektory ve stejné skupině mohou spolupracovat; mezi Business a Non-Business je hranice.

Pokud například zařadíme SharePoint do Business a Gmail do Non-Business, politika zabrání jejich společnému použití v jedné aplikaci nebo toku. Dva konektory zařazené do Business spolu naopak mohou pracovat.

Zařazení určuje organizace podle svého scénáře. Označení Business tedy automaticky nezaručuje bezpečnost služby ani přístup pouze k firemním účtům.

Existují také konektory, které v klasických DLP politikách blokovat nelze. Ty musíme ponechat v Business nebo Non-Business. Podrobnosti ke klasifikaci konektorů.

Nejprve strategie, potom nástroj

Než začneme politiku vytvářet, potřebujeme si ujasnit její účel.

Jaký základ má platit pro běžná prostředí? Kde potřebujeme prostor pro experimentování? Jak budeme schvalovat nové konektory a řešit výjimky?

Microsoft ve své strategii datových politik popisuje mimo jiné přístup se společnou restriktivní politikou a cílenými výjimkami pro prostředí s jinými požadavky.

To je dobrý výchozí bod pro přemýšlení. Konkrétní pravidla ale potřebujeme přizpůsobit vlastní organizaci, aplikacím a datům.

Stejně tak je vhodné rozlišovat „výchozí politiku tenanta“ a politiku pouze pro Default environment. V našem příkladu myslíme společný tenantový základ, který může pokrývat více prostředí.

Kde pomůže Terraform?

DLP můžeme spravovat přímo v Power Platform admin centru. Terraform představuje další možnost, která nám umožňuje popsat požadované nastavení v souborech a spravovat ho jako kód.

Pro Power Platform využíváme provider od Microsoftu.

Praktický přínos se může projevit už při vytváření první politiky. Místo ručního přesouvání velkého množství konektorů můžeme pravidla pro jejich zařazení popsat jednou.

Například:

• schválené konektory zařadit do Business,
• ostatní blokovatelné konektory do Blocked,
• konektory, které blokovat nelze, ponechat v příslušné povolené skupině.

Takto si můžeme usnadnit vytvoření restriktivního základu i pozdější hromadnou změnu klasifikace. Nemusíme každý konektor přesouvat jednotlivě v portálu.

Terraform ale sám nerozhoduje, co je pro organizaci správné. Pravidla definujeme my a před nasazením kontrolujeme jejich dopad. Hromadné blokování může ovlivnit existující aplikace a toky stejně jako ruční změna.

Při převzetí již existující politiky ji navíc potřebujeme nejprve importovat do správy Terraformu. Pouhé napsání konfigurace neznamená, že automaticky převezme libovolnou politiku z tenanta.

Tenantový základ a výjimka pro DEV

V našem demu jsme začali jednou výchozí politikou na úrovni tenanta.

Nastavili jsme ji pro všechna prostředí kromě výslovně uvedených výjimek. Díky tomu pokrývá také nová prostředí, dokud je z jejího rozsahu nevyloučíme.

DEV jsme přidali do seznamu výjimek. UAT a PROD zůstávají zahrnuté.

Je důležité rozumět tomu, že mírnější politika pro konkrétní prostředí nepřebije omezení tenantové politiky, která na něj stále platí. Odlišný režim proto vyžaduje správné nastavení rozsahu politik. Rozsah DLP politik.

Samotným vyloučením DEV nevzniká náhradní politika. Tu je potřeba připravit samostatně. V našem případě máme zatím nasazený společný základ a výjimku; pravidla pro DEV budou dalším krokem.

Jak vypadá konfigurace?

Pro demo jsme zvolili jednoduchou strukturu:

terraform/
├── tenant/
│   ├── versions.tf
│   ├── providers.tf
│   ├── variables.tf
│   ├── dlp.tf
│   ├── outputs.tf
│   └── policy.auto.tfvars
│
├── environments/
│   ├── dev/
│   ├── uat/
│   └── prod/
│
└── modules/
    └── environment/

Toto členění slouží k vysvětlení přístupu. Není univerzálním doporučením pro každý produkční projekt. V reálném řešení bychom strukturu přizpůsobili odpovědnostem týmů, způsobu nasazování a rozsahu správy.

V části tenant máme společnou DLP politiku. Složky DEV, UAT a PROD jsou zatím připravené pro další rozvoj.

Soubor versions.tf určuje požadované verze Terraformu a provideru. V providers.tf nastavujeme připojení a v dlp.tf definujeme vlastní politiku.

variables.tf popisuje vstupní parametry. Společné hodnoty, například název politiky, výjimky a schválené konektory, uchováváme ve verzovaném policy.auto.tfvars. Přihlašovací údaje do něj nepatří. Výstupy, například ID politiky, definujeme v outputs.tf.

Terraform načítá .tf soubory ve stejné složce jako jednu konfiguraci. Rozdělení podle oblastí nám pomáhá udržet ji přehlednou. Struktura konfigurace.

První vyzkoušení: init, plan a apply

Pro první pokus nemusíme rovnou připravovat pipeline. Můžeme začít lokálně.

Na Windows lze Terraform nainstalovat například pomocí winget:

winget install --id Hashicorp.Terraform --exact

Po instalaci otevřeme nové okno terminálu a ověříme dostupnost:

terraform version

V našem lokálním scénáři používáme pro přihlášení Azure CLI. Po přihlášení ke správnému tenantovi přejdeme do složky s tenantovou konfigurací.

Nejprve připravíme potřebné komponenty:

terraform init

Potom si necháme zobrazit navrhované změny:

terraform plan

Tento příkaz ještě nic nenasazuje. Ukáže, které prostředky mají vzniknout, změnit se nebo být odstraněny.

Při přidávání výjimky DEV jsme například viděli pouze úpravu rozsahu existující politiky. Nic se nevytvářelo ani nemazalo.

Pokud výsledek odpovídá našemu záměru, můžeme pokračovat:

terraform apply

Terraform znovu připraví plán a požádá o potvrzení. Kontrolujeme tedy i tento výsledný návrh, protože skutečný stav se mohl od předchozího spuštění změnit. Pracovní postup Terraformu.

Co nám tento přístup přinesl?

Začali jsme jednou politikou a konkrétní výjimkou. Už v tomto rozsahu máme požadované nastavení zachycené v repozitáři a můžeme sledovat jeho historii.

Před nasazením vidíme plán změn. Zařazení konektorů můžeme upravovat hromadně podle srozumitelných pravidel. Později můžeme stejnou konfiguraci zapojit do pipeline a doplnit schvalování.

Terraform přitom pracuje také se stavem, který propojuje konfiguraci se skutečnými prostředky. Pro týmovou práci potřebujeme tento stav bezpečně sdílet, například přes Azure Storage. Stavové soubory ani přihlašovací údaje neukládáme do Gitu.

Pro mě je na tomto přístupu zajímavé hlavně to, že můžeme začít postupně. Nemusíme hned automatizovat celou správu Power Platform.

Jedna DLP politika nám stačí k tomu, abychom si vyzkoušeli celý postup: popsat pravidla, zkontrolovat změnu, nasadit ji a zachovat její historii. Další prostředí a automatizace pak mohou navazovat na základ, kterému už rozumíme.

Zdroje a další čtení

Pro návrh vlastní DLP strategie a podrobnosti k jednotlivým možnostem doporučuji oficiální dokumentaci Microsoftu a HashiCorp. Dostupné funkce a chování provideru vždy ověřujte pro používanou verzi.

• Microsoft Learn — přehled datových politik
• Microsoft Learn — klasifikace konektorů
• Microsoft Learn — strategie DLP politik
• Microsoft Learn — rozsah tenantových a environmentových politik
• Microsoft Power Platform provider — dokumentace
• Terraform — struktura konfigurace
• Terraform — plánování změn
• Terraform — ukládání stavu v Azure Storage