Sdílet prostřednictvím

Doporučení pro správu identit a přístupu

  • Článek

Platí pro toto doporučení kontrolního seznamu zabezpečení pro Power Platform Well-Architected:

SE:05 Implementujte přísnou, podmíněnou a auditovatelnou správu identity a přístupu (IAM) pro všechny uživatele úlohy, členy týmu a systémové komponenty. Omezte přístup výhradně podle potřeby. Používejte moderní průmyslové standardy pro všechny implementace ověřování a autorizace. Omezte a důsledně auditujte přístup, který není založen na identitě.

Tento průvodce popisuje doporučení pro ověřování a autorizaci identit, které se mohou pokoušet o přístup ke zdrojům úlohy.

Z hlediska technické kontroly je identita vždy primárním perimetrem. Tento rozsah nezahrnuje pouze okraje vaší úlohy. Zahrnuje také jednotlivé komponenty, které jsou součástí vaší úlohy.

Typické identity zahrnují:

  • Lidé. Uživatelé aplikací, administrátoři, operátoři, auditoři a útočníci.
  • Systémy. Identity úlohy, spravované identity, klíče API, instanční objekty a prostředky Azure.
  • Anonymní. Subjekty, které neposkytly žádné důkazy o tom, kdo jsou.

Definice

Termíny definice
Ověřování (AuthN) Proces, který ověřuje, že identita je tím, kdo nebo co říká, že je.
Autorizace (AuthZ) Proces, který ověřuje, zda má identita oprávnění k provedení požadované akce.
Podmíněný přístup Sada pravidel, která umožňuje akce na základě zadaných kritérií.
IdP Zprostředkovatel identity jako Microsoft Entra ID.
Osoba Pracovní funkce nebo titul, který má soubor odpovědností a činností.
Předsdílené klíče Typ tajného klíče, které sdílí poskytovatel a spotřebitel a používá se prostřednictvím zabezpečeného a dohodnutého mechanismu.
Identita zdroje Identita definovaná pro cloudové prostředky, které spravuje platforma.
Role Sada oprávnění, která definují, co může uživatel nebo skupina dělat.
Obor Různé úrovně organizační hierarchie, kde může role fungovat. Také skupina funkcí v systému.
Objekt zabezpečení Identita, která poskytuje oprávnění. Může to být uživatel, skupina nebo instanční objekt. Všichni členové skupiny mají stejnou úroveň přístupu.
Identita uživatele Identita osoby, jako je zaměstnanec nebo externí uživatel.
Identita úlohy Systémová identita pro aplikaci, službu, skript, kontejner nebo jinou komponentu úlohy, která se používá k autentizaci vůči jiným službám a prostředkům.

Poznámka:

Identita může být seskupena s jinými podobnými identitami pod nadřazeným objektem, kterému se říká objekt zabezpečení. Skupina zabezpečení je příkladem zaregistrovaného objektu zabezpečení. Tento vztah hierarchický zjednodušuje údržbu a zlepšuje konzistenci. Vzhledem k tomu, že atributy identity nejsou zpracovávány na individuální úrovni, je také snížena pravděpodobnost chyb. V tomto článku termín identita zahrnuje objekty zabezpečení.

Microsoft Entra ID je poskytovatel identity pro Power Platform

Všechny produkty Power Platform používají Microsoft Entra ID (dříve Azure Active Directory nebo Azure AD) pro správu identity a přístupu. Entra ID umožňuje organizacím zabezpečit a spravovat identitu pro jejich hybridní a multicloudová prostředí. Entra ID je také nezbytné pro správu obchodních hostů, kteří vyžadují přístup ke zdrojům Power Platform. Power Platform také používá Entra ID ke správě dalších aplikací, které se potřebují integrovat s API Power Platform pomocí funkcí instančního objektu. Pomocí Entra ID Power Platform můžete využít pokročilejší bezpečnostní funkce Entra ID, jako je podmíněný přístup a průběžné vyhodnocování přístupu.

Ověřování

Autentizace je proces, který ověřuje identitu. Žádající totožnost musí poskytnout určitou formu ověřitelné identifikace. Příklad:

  • Uživatelské jméno a heslo.
  • Předsdílený tajný klíč, jako je klíč API, který uděluje přístup.
  • Token sdíleného přístupového podpisu (SAS).
  • Certifikát používaný při vzájemném ověřování TLS (Transport Layer Security).

Ověřování Power Platform zahrnuje sekvenci požadavků, odpovědí a přesměrování mezi prohlížečem uživatele a Power Platform nebo služeb Azure. Sekvence následuje tok udělení ověřovacího kódu Microsoft Entra ID.

Připojování a ověřování přístupu k externímu zdroji dat je samostatný krok vůči ověření přístupu ke službě Power Platform. Další informace viz Připojení a ověřování zdrojů dat.

Autorizace

Power Platform používá Microsoft Entra ID Microsoft Identity Platform pro autorizaci všech volání rozhraní API se standardním protokolem OAuth 2.0.

Klíčové strategie návrhu

Chcete-li porozumět potřebám identity pro úlohu, musíte vytvořit seznam uživatelských a systémových toků, prostředků úlohy a osoby a akce, které provedou.

Každý případ použití bude mít pravděpodobně svou vlastní sadu ovládacích prvků, které musíte navrhnout s předpokladem narušení. Na základě požadavků na identitu případu použití nebo osob identifikujte podmíněné volby. Nepoužívejte jedno řešení pro všechny případy použití. Naopak ovládací prvky by neměly být tak podrobné, abyste zaváděli zbytečnou režii správy.

Musíte zaprotokolovat přístupovou cestu identity. Pokud tak učiníte, pomůže to ověřit ovládací prvky a protokoly můžete použít pro audity souladu.

Určení všech identit pro ověření

Přístup zvenku dovnitř. Ověřování Power Platform zahrnuje sekvenci požadavků, odpovědí a přesměrování mezi prohlížečem uživatele a Power Platform nebo služeb Azure. Sekvence následuje tok udělení ověřovacího kódu Microsoft Entra ID. Power Platform automaticky ověřuje všechny uživatele, kteří přistupují k úloze pro různé účely.

Přístup zevnitř ven. Vaše úloha bude potřebovat přístup k dalším zdrojům. Například čtení nebo zápis na datovou platformu, získávání tajných klíčů z úložiště tajných klíčů a protokolování telemetrie do monitorovacích služeb. Může dokonce potřebovat přístup ke službám třetích stran. To vše jsou požadavky na identitu úlohy. Musíte však také zvážit požadavky na identitu prostředku, například jak poběží a ověřují kanály nasazení.

Určení akce pro autorizaci

Dále musíte vědět, o co se každá ověřená identita pokouší, aby bylo možné tyto akce autorizovat. Akce lze rozdělit podle typu přístupu, který vyžadují:

  • Přístup na datovou rovinu. Akce, které probíhají v datové rovině, způsobují přenos dat. Například aplikace čte nebo zapisuje data z Microsoft Dataverse nebo zapisuje protokoly do Application Insights.

  • Přístup na řídicí rovinu. Akce, které probíhají v řídicí rovině, způsobí vytvoření, úpravu nebo odstranění prostředku Power Platform. Například úprava vlastností prostředí nebo vytvoření zásad dat.

Aplikace se obvykle zaměřují na operace datové roviny, zatímco operace často přistupují k řídicí i datové rovině.

Poskytnutí autorizace na základě role

Na základě odpovědnosti každé identity autorizujte akce, které by měly být povoleny. Identitě nesmí být dovoleno dělat víc, než je potřeba. Než nastavíte pravidla autorizace, musíte jasně porozumět tomu, kdo nebo co podává požadavky, co tato role smí dělat a do jaké míry to může dělat. Tyto faktory vedou k volbám, které kombinují identitu, roli a rozsah.

Vezměte v úvahu následující skutečnosti:

  • Musí mít úloha přístup k datové rovině Dataverse pro přístup pro čtení i zápis?
  • Potřebuje úloha také přístup k vlastnostem prostředí?
  • Pokud je identita ohrožena útočníkem, jaký by to měl dopad na systém z hlediska důvěrnosti, integrity a dostupnosti?
  • Vyžaduje úloha trvalý přístup nebo lze zvážit podmíněný přístup?
  • Provádí úloha akce, které vyžadují oprávnění správce / zvýšená oprávnění?
  • Jak bude úloha interagovat se službami třetích stran?
  • Máte pro úlohy inteligentních aplikací, jako jsou agenti, požadavky na jednotné přihlašování (SSO)?
  • Pracuje agent v neověřeném režimu, ověřeném režimu nebo v obou?

Přiřazení role

Role je sada oprávnění přiřazená k identitě. Přiřaďte role, které pouze umožní identitě provést úkol, nic víc. Když jsou uživatelská oprávnění omezena na požadavky jejich úlohy, je snazší identifikovat podezřelé nebo neoprávněné chování v systému.

Položte si otázky jako:

  • Je přístup pouze pro čtení dostatečný?
  • Potřebuje identita oprávnění k odstranění zdrojů?
  • Potřebuje role pouze přístup k záznamům, které vytvořila?
  • Je přístup hierarchický založen na obchodní jednotce, ve které uživatel je?
  • Potřebuje role správcovská nebo zvýšená oprávnění?
  • Potřebuje role trvalý přístup k těmto oprávněním?
  • Co se stane, když uživatel změní práci?

Omezení úrovně přístupu uživatelů, aplikací nebo služeb snižuje potenciální útok. Pokud udělíte pouze minimální oprávnění, která jsou potřebná k provádění konkrétních úkolů, výrazně se sníží riziko úspěšného útoku nebo neoprávněného přístupu. Vývojáři například potřebují přístup pouze k vývojovému prostředí, ale ne k produkčnímu prostředí, potřebují přístup pouze k vytváření zdrojů, ale ne změně vlastnosti prostředí a mohou potřebovat pouze přístup ke čtení/zápisu dat z Dataverse, ale ne změně datového modelu nebo atributů tabulky Dataverse.

Vyhněte se oprávněním, která cílí na jednotlivé uživatele. Granulární a vlastní oprávnění vytvářejí složitost a zmatek a může být obtížné je udržovat, protože uživatelé mění role a pohybují se napříč firmou nebo když se k týmu připojují noví uživatelé s podobnými požadavky na ověřování. Tato situace může vytvořit složitou starší konfiguraci, kterou je obtížné udržovat a negativně ovlivnit bezpečnost i spolehlivost.

Kompromis: Granulární přístup k řízení přístupu umožňuje lepší auditování a monitorování uživatelských aktivit.

Udělujte role, které začínají s nejmenšími oprávněními, a přidejte další na základě vašich provozních potřeb nebo potřeb v oblasti přístupu k datům. Vaše technické týmy musí mít jasné pokyny k implementaci oprávnění.

Zvolte podmíněný přístup

Neposkytujte všem identitám stejnou úroveň přístupu. Založte svá rozhodnutí na dvou hlavních faktorech:

  • Čas. Jak dlouho může identita přistupovat k vašemu prostředí.
  • Oprávnění. Úroveň oprávnění.

Tyto faktory se vzájemně nevylučují. Zkompromitovaná identita, která má více oprávnění a neomezenou dobu přístupu, může získat větší kontrolu nad systémem a daty nebo tento přístup využít k pokračování ve změně prostředí. Omezte tyto přístupové faktory jako preventivní opatření a pro kontrolu rozsahu škod.

podle potřeby (JIT) poskytují požadovaná oprávnění pouze tehdy, když jsou potřeba.

Jen dostatečný přístup (JEA) poskytuje pouze požadovaná oprávnění.

Přestože čas a výsady jsou primárními faktory, platí i jiné podmínky. K nastavení zásad můžete například také použít zařízení, síť a umístění, ze kterého přístup pochází.

Používejte silné ovládací prvky, které filtrují, detekují a blokují neoprávněný přístup, včetně parametrů, jako je identita a poloha uživatele, stav zařízení, kontext úlohy, klasifikace dat a anomálie.

K vaší úloze může například vyžadovat přístup identit třetích stran, jako jsou dodavatelé, partneři a zákazníci. Potřebují spíše odpovídající úroveň přístupu než výchozí oprávnění, která poskytujete zaměstnancům na plný úvazek. Jasné rozlišení externích účtů usnadňuje předcházení a odhalování útoků pocházejících z těchto vektorů.

Účty s kritickým dopadem

Administrativní identity představují některá z největších bezpečnostních rizik, protože úkoly, které provádějí, vyžadují privilegovaný přístup k široké sadě těchto systémů a aplikací. Narušení nebo zneužití může mít škodlivý vliv na vaši firmu a její informační systémy. Zabezpečení správy je jednou z nejkritičtějších oblastí bezpečnosti.

Ochrana privilegovaného přístupu proti odhodlaným protivníkům vyžaduje, abyste přijali úplný a promyšlený přístup k izolaci těchto systémů od rizik. Zde je uvedeno několik strategií:

  • Minimalizujte počet účtů s kritickým dopadem.

  • Používejte samostatné role namísto zvyšování oprávnění pro stávající identity.

  • Vyhněte se trvalému nebo nepřetržitému přístupu pomocí funkcí JIT vašeho poskytovatele identity. V případě situací rozbitého skla postupujte podle nouzového přístupu.

  • Používejte moderní přístupové protokoly, jako je bezheslové ověřování nebo vícefaktorové ověřování. Externalizujte tyto mechanismy na svého poskytovatele identity.

  • Vynucujte klíčové atributy zabezpečení pomocí zásad podmíněného přístupu.

  • Vyřaďte administrativní účty, které se nepoužívají.

Vytvořte procesy pro řízení životního cyklu identity

Přístup k identitám nesmí trvat déle než prostředky, ke kterým identity přistupují. Ujistěte se, že máte proces pro deaktivaci nebo odstranění identit, když dojde ke změnám ve struktuře týmu nebo softwarových komponentách.

Tyto pokyny se vztahují na řízení zdrojů, data, řídicí roviny, uživatele úlohy, infrastrukturu, nástroje, monitorování dat, protokoly, metriky a další entity.

Vytvořte proces správy identit pro správu životního cyklu digitálních identit, vysoce privilegovaných uživatelů, externích/hostujících uživatelů a uživatelů úlohy. Implementujte kontroly přístupu, abyste zajistili, že když identity opustí organizaci nebo tým, budou jim odebrána oprávnění k úloze.

Chraňte tajné klíče nezaložené na identitě

Tajné klíče aplikací, jako jsou předsdílené klíče, je třeba považovat za zranitelná místa v systému. V obousměrné komunikaci, pokud dojde ke kompromitaci poskytovatele nebo spotřebitele, mohou být zavedena významná bezpečnostní rizika. Tyto klíče mohou být také zatěžující, protože zavádějí provozní procesy.

Zacházejte s těmito tajnými klíči jako s entitami, které lze dynamicky stahovat z tajného úložiště. Neměly by být pevně zakódovány ve vašich aplikacích, tocích, kanálech nasazení ani v žádném jiném artefaktu.

Ujistěte se, že máte schopnost odvolat tajný klíč.

Aplikujte provozní postupy, které zvládají úkoly, jako je střídání klíčů a vypršení platnosti.

Informace o zásadách rotace naleznete v části Automatizace rotace tajného klíče pro zdroje, které mají dvě sady přihlašovacích údajů pro ověření a Výukový program: Aktualizace frekvence automatické rotace certifikátů v Key Vault.

Udržujte vývojová prostředí bezpečná

Přístup pro zápis do vývojářských prostředí by měl být chráněn a přístup pro čtení ke zdrojovému kódu by měl být omezen na role na základě potřeby vědět. Měli byste mít zaveden proces, který pravidelně kontroluje zdroje a identifikuje nejnovější zranitelnosti.

Udržujte auditní stopu

Jedním z aspektů správy identit je zajištění auditovatelnosti systému. Audity ověřují, zda jsou strategie předpokládaného porušení účinné. Udržování auditní stopy vám pomůže:

  • Ověřit, zda je identita ověřena silným ověřováním. Každá akce musí být sledovatelná, aby se zabránilo útokům na odmítnutí.

  • Zjistěte slabé nebo chybějící ověřovací protokoly a získejte přehled o přihlášeních uživatelů a aplikací a informace o nich.

  • Vyhodnoťte přístup od identit k úloze na základě požadavků na zabezpečení a dodržování předpisů a zvažte riziko uživatelského účtu, stav zařízení a další kritéria a zásady, které nastavíte.

  • Sledujte pokrok nebo odchylku od požadavků na shodu.

Většina zdrojů má přístup k datové rovině. Musíte znát identity, které přistupují ke zdrojům, a akce, které provádějí. Tyto informace můžete použít pro diagnostiku zabezpečení.

Usnadnění díky Power Platform

Řízení přístupu Power Platform je důležitou součástí celkové bezpečnostní architektury. Body řízení přístupu mohou zajistit, že ke zdrojům Power Platform získají přístup ti správní uživatelé. V této části prozkoumáme různé přístupové body, které můžete nakonfigurovat, a jejich roli ve vaší celkové strategii zabezpečení.

Microsoft Entra ID

Všechny produkty Power Platform používají Microsoft Entra ID (dříve Azure Active Directory nebo Azure AD) pro správu identity a přístupu. Entra ID umožňuje organizacím zabezpečit a spravovat identitu pro jejich hybridní a multicloudová prostředí. Entra ID je také nezbytné pro správu obchodních hostů, kteří vyžadují přístup ke zdrojům Power Platform. Power Platform také používá Entra ID ke správě dalších aplikací, které se potřebují integrovat s API Power Platform pomocí funkcí instančního objektu. Pomocí Entra ID Power Platform můžete využít pokročilejší bezpečnostní funkce Entra ID, jako je podmíněný přístup a průběžné vyhodnocování přístupu.

Schéma cloudového výpočetního systému.

Přiřazení licence

Přístup k Power Apps a Power Automate začíná vlastnictvím licence. Zdroje a data, ke kterým má uživatel přístup, určuje typ licence, kterou máte. Následující tabulka uvádí rozdíly, na vysoké úrovni, ve zdrojích, které má uživatel k dispozici na základě svého typu plánu. Podrobné informace o licencích naleznete v části Přehled licencování.

Zásady podmíněného přístupu

Podmíněný přístup popisuje vaše zásady pro rozhodnutí o přístupu. Chcete-li používat podmíněný přístup, musíte porozumět omezením, která jsou vyžadována pro případ použití. Nakonfigurujte podmíněný přístup Microsoft Entra nastavením zásady přístupu, která je založena na vašich provozních potřebách.

Další informace naleznete v tématu:

Nepřetržitý přístup

Nepřetržitý přístup se zrychluje, když jsou vyhodnoceny určité události, aby se určilo, zda má být přístup odvolán. Tradičně s OAuth ověřováním 2.0 dochází k vypršení platnosti přístupového tokenu při kontrole během obnovení tokenu. Při nepřetržitém přístupu jsou kritické události uživatele a změny umístění v síti neustále vyhodnocovány, aby se určilo, zda by si uživatel měl nadále zachovat přístup. Tato hodnocení mohou vést k předčasnému ukončení aktivních relací nebo vyžadování opětovného ověření. Pokud je například uživatelský účet deaktivován, měl by ztratit přístup k aplikaci. Umístění je také důležité: token mohl být například autorizován z důvěryhodného umístění, ale uživatel změnil své připojení k nedůvěryhodné síti. Nepřetržitý přístup by vyvolal vyhodnocení zásad podmíněného přístupu a uživatel by ztratil přístup, protože se již nepřipojuje ze schváleného umístění.

V současné době s Power Platform pouze Dataverse podporuje průběžné vyhodnocování přístupu. Microsoft pracuje na přidání podpory k dalším službám a klientům Power Platform. Další informace naleznete v tématu Nepřetržité vyhodnocování přístupu.

Díky pokračujícímu přijímání hybridních pracovních modelů a používání cloudových aplikací se Entra ID stalo klíčovým primárním bezpečnostním perimetrem pro ochranu uživatelů a zdrojů. Podmíněný přístup rozšiřuje tento perimetr za hranici sítě a zahrnuje identitu uživatele a zařízení. Nepřetržitý přístup zajišťuje, že při změně událostí nebo umístění uživatelů je přístup přehodnocen. Použití Entra ID v Power Platform vám umožňuje implementovat správu zabezpečení na úrovni organizace, kterou můžete konzistentně aplikovat v celém portfoliu aplikací. Přečtěte si tyto osvědčené postupy správy identit, kde najdete další pokyny pro vytváření vlastního plánu pro používání Entra ID s Power Platform.

Správa skupinového přístupu

Místo udělování oprávnění konkrétním uživatelům přidělte přístup skupinám v Microsoft Entra ID. Pokud skupina neexistuje, ve spolupráci se svým týmem pro identitu ji vytvořte. Poté můžete přidávat a odebírat členy skupiny mimo Azure a ujistit se, že jsou oprávnění aktuální. Skupinu můžete také použít pro jiné účely, jako jsou seznamy adresátů.

Více informací viz Zabezpečené řízení přístupu pomocí skupin v Microsoft Entra ID.

Detekce hrozeb

Ochrana Microsoft Entra ID vám může pomoci odhalit, prozkoumat a napravit rizika založená na identitě. Další informace najdete v článku Co je ochrana identity?.

Detekce hrozeb může mít podobu reakce na upozornění na podezřelou aktivitu nebo proaktivního vyhledávání anomálních událostí v protokolech aktivit. Analýza chování uživatelů a entit (UEBA) v Microsoft Sentinel usnadňuje detekci podezřelých aktivit. Další informace naleznete v tématu Identifikace pokročilých hrozeb pomocí UEBA v aplikaci Microsoft Sentinel.

Protokolování identity

Protokolování aktivity Power Apps, Power Automate, Copilot Studio, konektorů a prevence ztráty dat je sledováno a prohlíženo z portálu pro dodržování předpisů Microsoft Purview. Další informace viz Další informace o Microsoft Purview.

Zaznamenává změny provedené v záznamech zákazníků v prostředí s databází Dataverse. Auditování Dataverse také zaznamenává přístup uživatelů prostřednictvím aplikace nebo sady SDK v prostředí. Toto auditování je aktivováno na úrovni prostředí a pro jednotlivé tabulky a sloupce je vyžadována další konfigurace.

Role správce služby

Entra ID obsahuje sadu předem vytvořených rolí, které lze přiřadit správcům a udělit jim oprávnění k provádění administrativních úkolů. Podrobný rozpis oprávnění jednotlivých rolí si můžete prohlédnout v matici oprávnění.

Použijte Privileged Identity Management (PIM) Microsoft Entra ke správě vysoce privilegovaných administrátorských rolí v centru pro správu Power Platform.

Zabezpečení dat Dataverse

Jednou z klíčových funkcí Dataverse je jeho bohatý model zabezpečení, který se dokáže přizpůsobit mnoha scénářům podnikového využití. Tento model zabezpečení je k dispozici, pouze pokud v prostředí existuje databáze Dataverse. Jako profesionál v oblasti zabezpečení pravděpodobně nevybudujete celý model zabezpečení sami, ale můžete se podílet na zajištění toho, aby použití bezpečnostních funkcí bylo v souladu s požadavky organizace na zabezpečení dat. Dataverse používá zabezpečení založené na rolích k seskupení kolekce oprávnění. Tyto role zabezpečení mohou být přidruženy přímo k uživatelům nebo mohou být přidruženy k týmům a organizačním jednotkám Dataverse. Další informace najdete v tématu Koncepty zabezpečení v Microsoft Dataverse.

Konfigurace ověřování uživatelů v Copilot Studio

Microsoft Copilot Studio podporuje několik možností ověřování. Vyberte takovou, která splňuje vaše potřeby. Ověřování umožňuje uživatelům přihlásit se a tedy dát agentovi přístup k omezeným zdrojům nebo informacím. Uživatelé se mohou přihlásit pomocí Microsoft Entra ID nebo s jakýmkoliv poskytovatelem identity OAuth 2.0, jako je Google nebo Facebook. Další informace najdete v tématu Konfigurace ověřování uživatelů v Copilot Studio.

Pomocí zabezpečení založeného na Direct Line můžete omezit přístup pouze k umístěním, která ovládáte, povolením zabezpečeného přístupu pomocí tajných kódů nebo tokenů Direct Line.

Copilot Studio podporuje jednotné přihlašování (SSO), což znamená, že agenti můžou uživatele přihlásit. SSO musí být implementováno na vašich webových stránkách a mobilních aplikacích. Jednotné přihlašování Microsoft Teams je bezproblémové, pokud vyberete možnost ověřování Pouze v Teams. Dá se také nakonfigurovat ručně pomocí Azure AD verze 2, ale v tomto případě musí být aplikace Teams nasazená jako soubor ZIP, nikoli prostřednictvím nasazení Teams na 1 kliknutí z Copilot Studio.

Další informace:

Bezpečný přístup k datům pomocí Customer Lockbox

Většina operací, podpory a řešení problémů prováděných pracovníky společnosti Microsoft (včetně dílčích zpracovatelů) nevyžaduje přístup k údajům zákazníka. S Power Platform Customer Lockbox poskytujeme rozhraní pro zákazníky, kde mohou kontrolovat a schvalovat (nebo zamítat) žádosti o přístup k údajům ve vzácných případech, kdy je potřeba získat přístup k údajům zákazníka. Používá se například v případech, kdy technik společnosti Microsoft potřebuje získat přístup k zákaznickým datům, ať už v reakci na zákaznický lístek podpory nebo problém identifikovaný společností Microsoft. Další informace viz Bezpečný přístup k zákaznickým datům pomocí Customer Lockbox v Power Platform a Dynamics 365.

Kontrolní seznam zabezpečení

Podívejte se na úplný soubor doporučení.

Kontrolní seznam zabezpečení