Základy správy prostředků Azure
Je důležité pochopit strukturu a termíny, které jsou specifické pro prostředky Azure. Následující obrázek ukazuje příklad čtyř úrovní rozsahu, které poskytuje Azure:
Terminologie
Tady jsou některé termíny, se kterými byste měli být obeznámeni:
Prostředek – spravovatelná položka, která je k dispozici prostřednictvím Azure. Mezi příklady prostředků patří virtuální počítače, účty úložiště, webové aplikace, databáze a virtuální sítě.
Skupina prostředků – kontejner, který obsahuje související prostředky pro řešení Azure, například kolekci virtuálních počítačů, přidružených virtuálních sítí a nástrojů pro vyrovnávání zatížení, které vyžadují správu konkrétních týmů. Skupina prostředků obsahuje prostředky, které chcete spravovat jako skupinu. O tom, které prostředky do skupiny prostředků patří, rozhodujete vy na základě toho, co je pro vaši organizaci nejvhodnější. Skupiny prostředků se dají použít také k tomu, aby pomohly se správou životního cyklu odstraněním všech prostředků, které mají stejnou životnost najednou. Tento přístup také poskytuje výhody zabezpečení tím, že nezachová žádné fragmenty, které by mohly být zneužity.
Předplatné – Z hlediska hierarchie organizace je předplatné kontejner fakturace a správy prostředků a skupin prostředků. Odběr Azure má vztah důvěryhodnosti s Microsoft Entra ID. Odběr důvěřuje službě Microsoft Entra ID při ověřování uživatelů, služeb a zařízení.
Poznámka:
Předplatné může důvěřovat pouze jednomu tenantovi Microsoft Entra. Každý tenant ale může důvěřovat více předplatným a předplatným, které je možné mezi tenanty přesunout.
Skupiny - pro správu Azure poskytují hierarchickou metodu použití zásad a dodržování předpisů v různých oborech nad předplatnými. Může se nacházet v kořenové skupině pro správu tenanta (nejvyšší obor) nebo na nižších úrovních v hierarchii. Předplatná uspořádáte do kontejnerů označovaných jako skupiny pro správu a na tyto skupiny pro správu použijete své zásady správného řízení. Všechna předplatná v rámci skupiny pro správu automaticky dědí podmínky, které se na příslušnou skupinu pro správu vztahují. Všimněte si, že definice zásad se dají použít u skupiny pro správu nebo předplatného.
Poskytovatel prostředků – služba, která poskytuje prostředky Azure. Běžným poskytovatelem prostředků je například Microsoft. Compute, který poskytuje prostředek virtuálního počítače. Microsoft. Úložiště je dalším běžným poskytovatelem prostředků.
Šablona Resource Manageru – soubor JSON (JavaScript Object Notation), který definuje jeden nebo více prostředků pro nasazení do skupiny prostředků, předplatného, tenanta nebo skupiny pro správu. Šablony lze použít k nasazení prostředků konzistentně a opakovaně. Viz přehled nasazení šablony. Kromě toho je možné místo JSON použít jazyk Bicep.
Model správy prostředků Azure
Každé předplatné Azure je přidružené k ovládacím prvkům používaným Azure Resource Managerem. Resource Manager je služba pro nasazení a správu Azure, má vztah důvěryhodnosti s ID Microsoft Entra pro správu identit pro organizace a účtem Microsoft (MSA) pro jednotlivce. Resource Manager poskytuje vrstvu správy, která umožňuje vytvářet, aktualizovat a odstraňovat prostředky ve vašem předplatném Azure. Pomocí funkcí správy, jako je řízení přístupu, zámky a značky, můžete prostředky po nasazení zabezpečit a uspořádat.
Poznámka:
Před ARM došlo k jinému modelu nasazení s názvem Azure Service Manager (ASM) nebo "classic". Další informace najdete v tématu Azure Resource Manager vs. nasazení Classic. Správa prostředí pomocí modelu ASM je mimo rozsah tohoto obsahu.
Azure Resource Manager je front-endová služba, která hostuje rozhraní REST API používaná powershellem, webem Azure Portal nebo jinými klienty ke správě prostředků. Když klient odešle žádost o správu konkrétního prostředku, Resource Manager žádost odešle poskytovateli prostředků, aby žádost dokončil. Pokud například klient odešle žádost o správu prostředku virtuálního počítače, Resource Manager žádost odešle do Microsoftu. Poskytovatel výpočetních prostředků Resource Manager vyžaduje, aby klient zadal identifikátor pro předplatné i skupinu prostředků pro správu prostředku virtuálního počítače.
Před provedením jakékoli žádosti o správu prostředků Resource Managerem se zkontroluje sada ovládacích prvků.
Platná kontrola uživatele – Uživatel, který žádá o správu prostředku, musí mít účet v tenantovi Microsoft Entra přidruženém k předplatnému spravovaného prostředku.
Kontrola uživatelských oprávnění – Oprávnění se přiřazují uživatelům pomocí řízení přístupu na základě role (RBAC). Role RBAC určuje sadu oprávnění, která může uživatel převzít u konkrétního prostředku. RBAC pomáhá spravovat, kdo má přístup k prostředkům Azure, co může s těmito prostředky dělat a k jakým oblastem má přístup.
Zásady Azure kontrolují - zásady Azure, které určují povolené nebo explicitní operace pro konkrétní prostředek. Zásada může například určit, že uživatelé mají oprávnění (nebo nejsou povoleni) k nasazení určitého typu virtuálního počítače.
Následující diagram shrnuje model prostředků, který jsme právě popsali.
Azure Lighthouse - Azure Lighthouse umožňuje správu prostředků napříč tenanty. Organizace můžou delegovat role na úrovni předplatného nebo skupiny prostředků na identity v jiném tenantovi.
Předplatná, která umožňují delegovanou správu prostředků pomocí Služby Azure Lighthouse, mají atributy, které označují ID tenanta, která můžou spravovat předplatná nebo skupiny prostředků, a mapování mezi předdefinovanou rolí RBAC v tenantovi prostředku na identity v tenantovi poskytovatele služeb. Azure Resource Manager bude tyto atributy využívat za běhu k autorizaci tokenů pocházejících z tenanta poskytovatele služeb.
Stojí za zmínku, že azure Lighthouse je modelovaný jako poskytovatel prostředků Azure, což znamená, že aspekty delegování napříč tenantem je možné cílit prostřednictvím zásad Azure.
Microsoft 365 Lighthouse Microsoft 365 Lighthouse - je portál pro správu, který pomáhá poskytovatelům spravovaných služeb zabezpečit a spravovat zařízení, data a uživatele ve velkém měřítku pro malé a střední firmy (SMB), kteří používají Microsoft 365 Business Premium, Microsoft 365 E3 nebo Windows 365 Business.
Správa prostředků Azure s využitím Microsoft Entra ID
Teď, když máte lepší přehled o modelu správy prostředků v Azure, stručně se podíváme na některé možnosti Id Microsoft Entra, které můžou poskytovat správu identit a přístupu pro prostředky Azure.
Fakturace
Fakturace je důležitá pro správu prostředků, protože některé fakturační role pracují s prostředky nebo můžou spravovat prostředky. Fakturace funguje jinak v závislosti na typu smlouvy, kterou máte s Microsoftem.
Azure smlouva Enterprise s
Zákazníci azure smlouva Enterprise (Azure EA) se při spuštění komerční smlouvy s Microsoftem připojují k portálu Azure EA Portal. Při onboardingu je identita přidružená k fakturační roli kořenového podnikového správce. Portál poskytuje hierarchii funkcí správy:
Oddělení pomáhají segmentovat náklady do logických seskupení a umožňují nastavit rozpočet nebo kvótu na úrovni oddělení.
Účty se používají k dalším segmentům oddělení. Účty můžete použít ke správě předplatných a pro přístup k sestavám. Portál EA může autorizovat účty Microsoft (MSA) nebo účty Microsoft Entra (identifikované na portálu jako Pracovní nebo školní účty). Identity s rolí Vlastník účtu na portálu EA Portal můžou vytvářet předplatná Azure.
Podniková fakturace a tenanti Microsoft Entra
Když vlastník účtu vytvoří předplatné Azure ve smlouvě Enterprise, nakonfiguruje se správa identit a přístupu předplatného následujícím způsobem:
Předplatné Azure je přidružené ke stejnému tenantovi Microsoft Entra vlastníka účtu.
Vlastník účtu, který vytvořil předplatné, bude přiřazen role správce služeb a správce účtu. (Portál Azure EA přiřazuje ke správě předplatných role Azure Service Manageru (ASM) nebo klasické role. Další informace najdete v tématu Azure Resource Manager vs. nasazení Classic.)
Smlouvu Enterprise je možné nakonfigurovat tak, aby podporovala více tenantů nastavením typu ověřování "Pracovní nebo školní účet mezi tenanty" na portálu Azure EA Portal. Vzhledem k výše uvedeným informacím můžou organizace pro každého tenanta nastavit více účtů a více předplatných pro každý účet, jak je znázorněno na následujícím diagramu.
Je důležité si uvědomit, že výchozí konfigurace popsaná výše uděluje oprávnění vlastníka účtu Azure EA ke správě prostředků v jakýchkoli předplatných, která vytvořila. U předplatných s produkčními úlohami zvažte oddělení fakturace a správy prostředků změnou správce služeb předplatného hned po vytvoření.
Pokud chcete dále oddělit vlastníka účtu a zabránit tomu, aby znovu získal přístup správce služeb k předplatnému, můžete po vytvoření tenanta předplatného změnit . Pokud vlastník účtu nemá v tenantovi Microsoft Entra objekt uživatele, na který se předplatné přesune, nemůže znovu získat roli vlastníka služby.
Další informace najdete v rolích Azure, rolích Microsoft Entra a klasických rolích správce předplatného.
Smlouva se zákazníkem Microsoftu
Zákazníci zaregistrovaní v Smlouva se zákazníkem Microsoftu (MCA) mají jiný fakturační systém s vlastními rolemi.
Fakturační účet pro Smlouva se zákazníkem Microsoftu obsahuje jeden nebo více fakturačních profilů, které umožňují správu faktur a způsobů platby. Každý fakturační profil obsahuje jeden nebo více oddílů faktury pro uspořádání nákladů na faktuře fakturačního profilu.
V Smlouva se zákazníkem Microsoftu pocházejí fakturační role z jednoho tenanta Microsoft Entra. Pokud chcete zřídit předplatná pro více tenantů, musí se předplatná zpočátku vytvořit ve stejném tenantovi Microsoft Entra jako MCA a pak je změnit. V následujícím diagramu se předplatná podnikového it předprodukčního prostředí po vytvoření přesunula do tenanta ContosoSandbox.
RBAC a přiřazení rolí v Azure
V části Microsoft Entra Fundamentals jste se dozvěděli, že Azure RBAC je autorizační systém, který poskytuje jemně odstupňovanou správu přístupu k prostředkům Azure a zahrnuje mnoho předdefinovaných rolí. Můžete vytvářet vlastní role a přiřazovat role v různých oborech. Oprávnění se vynucují přiřazením rolí RBAC k objektům, které požadují přístup k prostředkům Azure.
Role Microsoft Entra pracují s koncepty, jako je řízení přístupu na základě role v Azure. Rozdíl mezi těmito dvěma systémy řízení přístupu na základě role spočívá v tom, že Azure RBAC používá Azure Resource Management k řízení přístupu k prostředkům Azure, jako jsou virtuální počítače nebo úložiště, a role Microsoft Entra řídí přístup k Microsoft Entra ID, aplikacím a služby Microsoft, jako je Office 365.
Role Microsoft Entra i role Azure RBAC se integrují se službou Microsoft Entra Privileged Identity Management a umožňují zásady aktivace za běhu, jako je pracovní postup schválení a vícefaktorové ověřování.
ABAC a přiřazení rolí v Azure
Řízení přístupu na základě atributů (ABAC) je autorizační systém, který definuje přístup na základě atributů přidružených k objektům zabezpečení, prostředkům a prostředí. Pomocí ABAC můžete objektu zabezpečení udělit přístup k prostředku na základě atributů. Azure ABAC odkazuje na implementaci ABAC pro Azure.
Azure ABAC staví na Azure RBAC přidáním podmínek přiřazení rolí na základě atributů v kontextu konkrétních akcí. Podmínka přiřazení role je další kontrola, kterou můžete volitelně přidat k přiřazení role, abyste zajistili podrobnější řízení přístupu. Podmínka filtruje oprávnění udělená jako součást definice role a přiřazení role. Můžete například přidat podmínku, která vyžaduje, aby objekt měl ke čtení objektu určitou značku. Pomocí podmínek nemůžete explicitně odepřít přístup ke konkrétním prostředkům.
Podmíněný přístup
Podmíněný přístup Microsoft Entra se dá použít ke správě přístupu ke koncovým bodům správy Azure. Zásady podmíněného přístupu je možné použít pro cloudovou aplikaci API pro správu služeb Windows Azure za účelem ochrany koncových bodů správy prostředků Azure, jako jsou:
Poskytovatel Azure Resource Manageru (služby)
Rozhraní API Azure Resource Manageru
Azure PowerShell
Azure CLI
portál Azure
Správce může například nakonfigurovat zásady podmíněného přístupu, které uživateli umožní přihlásit se k webu Azure Portal jenom ze schválených umístění a také vyžaduje vícefaktorové ověřování (MFA) nebo hybridní zařízení připojené k doméně Microsoft Entra.
Spravované identity Azure
Běžnou výzvou při vytváření cloudových aplikací je, jak v kódu spravovat přihlašovací údaje pro ověřování u cloudových služeb. Zajištění zabezpečení těchto přihlašovacích údajů je důležitý úkol. V ideálním případě by se přihlašovací údaje nikdy neměly nacházet na vývojářských pracovních stanicích ani se vracet se změnami do správy zdrojového kódu. Spravované identity pro prostředky Azure poskytují službám Azure automaticky spravovanou identitu v Microsoft Entra ID. Identitu můžete použít k ověření ve všech službách, které podporují ověřování Microsoft Entra bez jakýchkoli přihlašovacích údajů ve vašem kódu.
Existují dva typy spravovaných identit:
Spravovaná identita přiřazená systémem je povolená přímo u prostředku Azure. Když je prostředek povolený, Azure vytvoří identitu pro prostředek v důvěryhodném tenantovi Microsoft Entra přidruženého předplatného. Po vytvoření identity se přihlašovací údaje zřídí do prostředku. Životní cyklus identity přiřazené systémem je přímo svázaný s prostředkem Azure. Pokud se prostředek odstraní, Azure automaticky vyčistí přihlašovací údaje a identitu v Microsoft Entra ID.
Spravovaná identita přiřazená uživatelem se vytváří jako samostatný prostředek Azure. Azure vytvoří identitu v tenantovi Microsoft Entra, kterému důvěřuje předplatné, ke kterému je prostředek přidružený. Po vytvoření identity se identita dá přiřadit k jednomu nebo několika prostředkům Azure. Životní cyklus identity přiřazené uživatelem se spravuje odděleně od životního cyklu prostředků Azure, ke kterým je přiřazena.
Spravované identity jsou interně instanční objekty speciálního typu, které se použijí jenom pro konkrétní prostředky Azure. Po odstranění spravované identity se odpovídající instanční objekt automaticky odebere. Nee, že autorizaci oprávnění rozhraní Graph API může provádět jenom PowerShell, takže ne všechny funkce spravované identity jsou přístupné prostřednictvím uživatelského rozhraní portálu.
Microsoft Entra Domain Services
Služba Microsoft Entra Domain Services poskytuje spravovanou doménu, která usnadňuje ověřování úloh Azure pomocí starších protokolů. Podporované servery se přesouvají z místní doménové struktury SLUŽBY AD DS a připojí se ke spravované doméně služby Microsoft Entra Domain Services a nadále používají starší protokoly pro ověřování (například ověřování protokolem Kerberos).
Adresáře Azure AD B2C a Azure
Tenant Azure AD B2C je propojený s předplatným Azure pro účely fakturace a komunikace. Tenanti Azure AD B2C mají v adresáři samostatnou strukturu rolí, která je nezávislá na privilegovaných rolích Azure RBAC předplatného Azure.
Při počátečním zřízení tenanta Azure AD B2C musí mít uživatel, který vytváří tenanta B2C, oprávnění přispěvatele nebo vlastníka v předplatném. Později můžou vytvářet další účty a přiřazovat je k rolím adresáře. Další informace naleznete v tématu Přehled řízení přístupu na základě role v Microsoft Entra ID.
Je důležité si uvědomit, že vlastníci a přispěvatelé propojeného předplatného Microsoft Entra můžou odebrat propojení mezi předplatným a adresářem, což ovlivní průběžnou fakturaci využití Azure AD B2C.
Aspekty identit pro řešení IaaS v Azure
Tento scénář se zabývá požadavky na izolaci identit, které organizace mají pro úlohy IaaS (Infrastructure-as-a-Service).
Existují tři klíčové možnosti týkající se správy izolace úloh IaaS:
Virtuální počítače připojené k samostatné službě Doména služby Active Directory Services (AD DS)
Virtuální počítače připojené ke službě Microsoft Entra Domain Services
Přihlášení k virtuálním počítačům v Azure pomocí ověřování Microsoft Entra
Klíčovým konceptem, který se má řešit s prvními dvěma možnostmi, je, že v těchto scénářích existují dvě sféry identit.
Když se přihlásíte k virtuálnímu počítači Azure s Windows Serverem přes protokol RDP (Remote Desktop Protocol), obvykle se k serveru přihlašujete pomocí přihlašovacích údajů vaší domény, která provádí ověřování Kerberos vůči místnímu řadiči domény SLUŽBY AD DS nebo službě Microsoft Entra Domain Services. Pokud server není připojený k doméně, můžete k přihlášení k virtuálním počítačům použít místní účet.
Když se přihlásíte k webu Azure Portal, abyste vytvořili nebo spravovali virtuální počítač, ověřujete se pomocí ID Microsoft Entra (případně pomocí stejných přihlašovacích údajů, pokud jste synchronizovali správné účty) a to může vést k ověření vůči řadičům domény, pokud používáte Active Directory Federation Services (AD FS) (AD FS) nebo předávací ověřování.
Virtuální počítače připojené k samostatné službě Doména služby Active Directory Services
SLUŽBA AD DS je adresářová služba založená na Windows Serveru, kterou organizace do značné míry přijaly pro místní služby identit. Službu AD DS je možné nasadit, pokud existuje požadavek na nasazení úloh IaaS do Azure, které vyžadují izolaci identit od správců a uživatelů služby AD DS v jiné doménové struktuře.
V tomto scénáři je potřeba vzít v úvahu následující aspekty:
Řadiče domény služby AD DS: Musí být nasazeny minimálně dva řadiče domény služby AD DS, aby se zajistilo, že ověřovací služby jsou vysoce dostupné a výkonné. Další informace naleznete v tématu Návrh a plánování služby AD DS.
Návrh a plánování služby AD DS – Je nutné vytvořit novou doménovou strukturu SLUŽBY AD DS se správně nakonfigurovanými následujícími službami:
SLUŽBA AD DS Domain Name Services (DNS) – Služba AD DS DNS musí být nakonfigurovaná pro příslušné zóny v rámci služby AD DS, aby se zajistilo správné fungování překladu názvů pro servery a aplikace.
Weby a služby AD DS – Tyto služby musí být nakonfigurované, aby aplikace měly nízkou latenci a výkonnější přístup k řadičům domény. Příslušné virtuální sítě, podsítě a umístění datacentra, ve kterých se servery nacházejí, by měly být nakonfigurované v lokalitách a službách.
Ad DS FSMOs – role FSMO (Flexible Single Master Operation), které jsou potřeba, by se měly kontrolovat a přiřazovat příslušným řadičům domény služby AD DS.
Připojení k doméně služby AD DS – Všechny servery (s výjimkou jumpboxes), které vyžadují službu AD DS pro ověřování, konfiguraci a správu, musí být připojené k izolované doménové struktuře.
Zásady skupiny služby AD DS – Objekty zásad skupiny služby AD DS musí být nakonfigurované, aby se zajistilo, že konfigurace splňuje požadavky na zabezpečení a že konfigurace je standardizovaná napříč doménovou strukturou a počítači připojenými k doméně.
Organizační jednotky služby AD DS (OU) – Organizační jednotky SLUŽBY AD DS musí být definované, aby se zajistilo seskupení prostředků SLUŽBY AD DS do logické správy a konfiguračního sila pro účely správy a použití konfigurace.
Řízení přístupu na základě role – Řízení přístupu na základě role musí být definováno pro správu a přístup k prostředkům připojeným k této doménové struktuře. Sem patří:
Skupiny služby AD DS – Skupiny musí být vytvořeny, aby se použila příslušná oprávnění pro uživatele na prostředky služby AD DS.
Účty pro správu – jak je uvedeno na začátku této části, ke správě tohoto řešení jsou potřeba dva účty pro správu.
Účet pro správu služby AD DS s nejméně privilegovaným přístupem potřebným k provedení správy požadovaných na serverech AD DS a připojených k doméně.
Účet pro správu Microsoft Entra pro přístup k webu Azure Portal pro připojení, správu a konfiguraci virtuálních počítačů, virtuálních sítí, skupin zabezpečení sítě a dalších požadovaných prostředků Azure.
Uživatelské účty služby AD DS – Příslušné uživatelské účty je potřeba zřídit a přidat do správných skupin, aby bylo možné uživatelům povolit přístup k aplikacím hostovaným tímto řešením.
Virtuální sítě – Pokyny ke konfiguraci
IP adresa řadiče domény služby AD DS – Řadiče domény by neměly být nakonfigurované se statickými IP adresami v rámci operačního systému. IP adresy by měly být rezervované ve virtuální síti Azure, aby se zajistilo, že vždy zůstanou stejné a řadič domény by měl být nakonfigurovaný tak, aby používal protokol DHCP.
Server DNS virtuální sítě – Servery DNS musí být nakonfigurované na virtuální sítě, které jsou součástí tohoto izolovaného řešení, aby odkazovaly na řadiče domény. To je nutné k zajištění toho, aby aplikace a servery mohly přeložit požadované služby AD DS nebo jiné služby připojené k doménové struktuře služby AD DS.
Skupiny zabezpečení sítě (NSG) – Řadiče domény by se měly nacházet ve vlastní virtuální síti nebo podsíti s definovanými skupinami zabezpečení sítě, aby povolovaly přístup jenom k řadičům domény z požadovaných serverů (například počítačů připojených k doméně nebo jumpboxů). Jumpboxes by se měly přidat do skupiny zabezpečení aplikace (ASG), aby se zjednodušilo vytváření a správa NSG.
Výzvy: Následující seznam zdůrazňuje klíčové výzvy při použití této možnosti pro izolaci identit:
Další doménová struktura služby AD DS, která slouží ke správě, správě a monitorování, což vede k většímu výkonu it týmu.
Pro správu oprav a nasazení softwaru může být vyžadována další infrastruktura. Organizace by měly zvážit nasazení služby Azure Update Management, zásad skupiny (GPO) nebo System Center Configuration Manageru (SCCM) pro správu těchto serverů.
Další přihlašovací údaje pro uživatele, které si budou pamatovat a používat pro přístup k prostředkům.
Důležité
U tohoto izolovaného modelu se předpokládá, že neexistuje připojení k řadičům domény ani z podnikové sítě zákazníka a že neexistují žádné vztahy důvěryhodnosti nakonfigurované s jinými doménovými strukturami. Měl by být vytvořen jumpbox nebo server pro správu, aby bylo možné povolit bod, ze kterého lze spravovat a spravovat řadiče domény služby AD DS.
Virtuální počítače připojené ke službě Microsoft Entra Domain Services
Pokud existuje požadavek na nasazení úloh IaaS do Azure, které vyžadují izolaci identit od správců a uživatelů služby AD DS v jiné doménové struktuře, je možné nasadit spravovanou doménu služby Microsoft Entra Domain Services. Microsoft Entra Domain Services je služba, která poskytuje spravovanou doménu pro usnadnění ověřování úloh Azure pomocí starších protokolů. To poskytuje izolovanou doménu bez technických složitostí vytváření a správy vlastní služby AD DS. Je třeba vzít v úvahu následující aspekty.
Spravovaná doména služby Microsoft Entra Domain Services – Na tenanta Microsoft Entra je možné nasadit pouze jednu spravovanou doménu služby Microsoft Entra Domain Services a tato doména je svázaná s jednou virtuální sítí. Doporučuje se, aby tato virtuální síť tvoří centrum pro ověřování služby Microsoft Entra Domain Services. Z tohoto centra je možné vytvořit a propojit paprsky, které umožňují starší ověřování pro servery a aplikace. Paprsky jsou další virtuální sítě, na kterých jsou umístěné servery připojené ke službě Microsoft Entra Domain Services, a jsou propojeny s centrem pomocí síťových bran Azure nebo partnerského vztahu virtuálních sítí.
Umístění spravované domény – Při nasazování spravované domény služby Microsoft Entra Domain Services musí být nastaveno umístění. Umístění je fyzická oblast (datové centrum), ve které je spravovaná doména nasazená. Doporučuje se:
Zvažte umístění, které je geograficky uzavřeno pro servery a aplikace, které vyžadují služby Microsoft Entra Domain Services.
Zvažte oblasti, které poskytují možnosti Zóny dostupnosti pro požadavky na vysokou dostupnost. Další informace najdete v tématu Oblasti a Zóny dostupnosti v Azure.
Zřizování objektů – Služba Microsoft Entra Domain Services synchronizuje identity z ID Microsoft Entra přidružené k předplatnému, do kterého je nasazena služba Microsoft Entra Domain Services. Je také třeba poznamenat, že pokud přidružené ID Microsoft Entra má nastavenou synchronizaci s Microsoft Entra Connect (scénář doménové struktury uživatele), životní cyklus těchto identit se také může projevit ve službě Microsoft Entra Domain Services. Tato služba má dva režimy, které lze použít ke zřizování objektů uživatelů a skupin z ID Microsoft Entra.
Vše: Všichni uživatelé a skupiny se synchronizují z ID Microsoft Entra do služby Microsoft Entra Domain Services.
Vymezeno: Do služby Microsoft Entra Domain Services se synchronizují pouze uživatelé v oboru skupin.
Při prvním nasazení služby Microsoft Entra Domain Services se automatická jednosměrná synchronizace nakonfiguruje tak, aby replikovala objekty z ID Microsoft Entra. Tato jednosměrná synchronizace pokračuje v provozu na pozadí, aby spravovaná doména služby Microsoft Entra Domain Services byla aktuální s případnými změnami z ID Microsoft Entra. Nedochází k synchronizaci ze služby Microsoft Entra Domain Services zpět do Microsoft Entra ID. Další informace naleznete v tématu Způsob synchronizace objektů a přihlašovacích údajů ve spravované doméně služby Microsoft Entra Domain Services.
Je vhodné poznamenat, že pokud potřebujete změnit typ synchronizace ze všech na obor (nebo naopak), bude potřeba odstranit, znovu vytvořit a nakonfigurovat spravovanou doménu služby Microsoft Entra Domain Services. Organizace by navíc měly zvážit použití zřizování s vymezeným oborem, aby se omezily identity jenom na ty, které potřebují přístup k prostředkům služby Microsoft Entra Domain Services, jako dobrý postup.
Objekty zásad skupiny (GPO) – Ke konfiguraci objektu zásad skupiny ve spravované doméně služby Microsoft Entra Domain Services musíte použít nástroje pro správu zásad skupiny na serveru, který je připojený k spravované doméně služby Microsoft Entra Domain Services. Další informace naleznete v tématu Správa zásad skupiny ve spravované doméně služby Microsoft Entra Domain Services.
Secure LDAP – Služba Microsoft Entra Domain Services poskytuje zabezpečenou službu LDAP, kterou můžou používat aplikace, které ji vyžadují. Toto nastavení je ve výchozím nastavení zakázané a aby bylo možné povolit zabezpečený protokol LDAP, musí být navíc nahraný certifikát NSG, který zabezpečuje virtuální síť nasazenou službou Microsoft Entra Domain Services, aby umožňovala připojení portu 636 ke spravovaným doménám služby Microsoft Entra Domain Services. Další informace naleznete v tématu Konfigurace protokolu LDAP zabezpečení pro spravovanou doménu služby Microsoft Entra Domain Services.
Správa – Aby bylo možné provádět úlohy správy ve službě Microsoft Entra Domain Services (například počítače pro připojení k doméně nebo úpravy objektu zásad skupiny), musí být účet použitý pro tuto úlohu součástí skupiny Microsoft Entra DC Administrators. Účty, které jsou členy této skupiny, se nemůžou přímo přihlásit k řadičům domény, aby mohly provádět úlohy správy. Místo toho vytvoříte virtuální počítač pro správu, který je připojený ke spravované doméně služby Microsoft Entra Domain Services, a pak nainstalujete běžné nástroje pro správu služby AD DS. Další informace naleznete v tématu Koncepty správy uživatelských účtů, hesel a správy ve službě Microsoft Entra Domain Services.
Hodnoty hash hesel – Aby ověřování pomocí služby Microsoft Entra Domain Services fungovalo, musí být hodnoty hash hesel pro všechny uživatele ve formátu, který je vhodný pro ověřování NT LAN Manager (NTLM) a Kerberos. Aby ověřování pomocí služby Microsoft Entra Domain Services fungovalo podle očekávání, je potřeba provést následující požadavky.
Uživatelé synchronizovaní se službou Microsoft Entra Connect (ze služby AD DS) – Starší hodnoty hash hesel je potřeba synchronizovat z místní služby AD DS do Microsoft Entra ID.
Uživatelé vytvořené v Microsoft Entra ID – Potřebují resetovat heslo, aby se pro použití se službou Microsoft Entra Domain Services vygenerovaly správné hodnoty hash. Další informace naleznete v tématu Povolení synchronizace hodnot hash hesel.
Síť – Služba Microsoft Entra Domain Services je nasazená do virtuální sítě Azure, proto je potřeba vzít v úvahu důležité informace, aby byly servery a aplikace zabezpečené a mohly správně přistupovat ke spravované doméně. Další informace najdete v tématu Aspekty návrhu virtuální sítě a možnosti konfigurace pro službu Microsoft Entra Domain Services.
Služba Microsoft Entra Domain Services musí být nasazená ve vlastní podsíti: Nepoužívejte existující podsíť ani podsíť brány.
Skupina zabezpečení sítě (NSG) – se vytvoří během nasazení spravované domény služby Microsoft Entra Domain Services. Tato skupina zabezpečení sítě obsahuje požadovaná pravidla pro správnou komunikaci služby. Nevytvádejte ani nepoužívejte existující skupinu zabezpečení sítě s vlastními pravidly.
Microsoft Entra Domain Services vyžaduje 3 až 5 IP adres – Ujistěte se, že rozsah IP adres vaší podsítě může poskytnout tento počet adres. Omezení dostupných IP adres může zabránit službě Microsoft Entra Domain Services v údržbě dvou řadičů domény.
Server DNS virtuální sítě – Jak jsme už dříve probírali o modelu hvězdicové sítě, je důležité správně nakonfigurovat DNS ve virtuálních sítích, aby se zajistilo, že servery připojené ke spravované doméně Microsoft Entra Domain Services mají správná nastavení DNS pro překlad spravované domény Služby Microsoft Entra Domain Services. Každá virtuální síť má položku serveru DNS, která se předává serverům při získávání IP adresy a tyto položky DNS musí být IP adresa spravované domény služby Microsoft Entra Domain Services. Další informace najdete v tématu Aktualizace nastavení DNS pro virtuální síť Azure.
Výzvy – následující seznam zdůrazňuje klíčové výzvy při použití této možnosti pro izolaci identit.
Některé konfigurace služby Microsoft Entra Domain Services je možné spravovat pouze ze serveru připojeného k Microsoft Entra Domain Services.
Na tenanta Microsoft Entra je možné nasadit pouze jednu spravovanou doménu služby Microsoft Entra Domain Services. Jak popisujeme v této části, doporučuje se poskytovat ověřování služby Microsoft Entra Domain Services pro služby v jiných virtuálních sítích.
Možná je potřeba další infrastruktura pro správu oprav a nasazení softwaru. Organizace by měly zvážit nasazení služby Azure Update Management, zásad skupiny (GPO) nebo System Center Configuration Manageru (SCCM) pro správu těchto serverů.
U tohoto izolovaného modelu se předpokládá, že neexistuje žádné připojení k virtuální síti, která je hostitelem spravované domény Microsoft Entra Domain Services z podnikové sítě zákazníka a že neexistují žádné vztahy důvěryhodnosti nakonfigurované s jinými doménovými strukturami. Měl by být vytvořen jumpbox nebo server pro správu, aby bylo možné povolit bod, ze kterého lze spravovat a spravovat službu Microsoft Entra Domain Services.
Přihlášení k virtuálním počítačům v Azure pomocí ověřování Microsoft Entra
Pokud existuje požadavek na nasazení úloh IaaS do Azure, které vyžadují izolaci identity, pak poslední možností je použít Microsoft Entra ID pro přihlášení k serverům v tomto scénáři. To poskytuje možnost, aby Microsoft Entra ID identity sféru pro účely ověřování a izolaci identity bylo možné dosáhnout zřízením serverů do příslušného předplatného, které je propojené s požadovaným tenantem Microsoft Entra. Je třeba vzít v úvahu následující aspekty.
Podporované operační systémy: Přihlášení k virtuálním počítačům v Azure pomocí ověřování Microsoft Entra se v současné době podporuje ve Windows a Linuxu. Podrobnější informace o podporovaných operačních systémech najdete v dokumentaci pro Windows a Linux.
Přihlašovací údaje: Jednou z klíčových výhod přihlašování k virtuálním počítačům v Azure pomocí ověřování Microsoft Entra je možnost používat stejné federované nebo spravované přihlašovací údaje Microsoft Entra, které běžně používáte pro přístup ke službám Microsoft Entra pro přihlášení k virtuálnímu počítači.
Poznámka:
Tenant Microsoft Entra, který se používá pro přihlášení v tomto scénáři, je tenant Microsoft Entra přidružený k předplatnému, do kterého byl virtuální počítač zřízený. Tento tenant Microsoft Entra může být tenant, který má identity synchronizované z místní služby AD DS. Organizace by měly učinit informovanou volbu, která je v souladu se svými objekty zabezpečení izolace při výběru předplatného a tenanta Microsoft Entra, kterého chtějí použít pro přihlášení k těmto serverům.
Požadavky na síť: Tyto virtuální počítače budou potřebovat přístup k MICROSOFT Entra ID pro ověřování, takže musíte zajistit, aby konfigurace sítě virtuálních počítačů umožňovala odchozí přístup ke koncovým bodům Microsoft Entra na 443. Další informace najdete v dokumentaci pro Windows a Linux .
Řízení přístupu na základě role (RBAC): K dispozici jsou dvě role RBAC, které poskytují odpovídající úroveň přístupu k těmto virtuálním počítačům. Tyto role RBAC je možné nakonfigurovat prostřednictvím webu Azure Portal nebo prostřednictvím prostředí Azure Cloud Shell. Další informace najdete v tématu Konfigurace přiřazení rolí pro virtuální počítač.
Přihlášení správce virtuálního počítače: Uživatelé s touto rolí, kteří mají přiřazenou roli, se můžou přihlásit k virtuálnímu počítači Azure s oprávněními správce.
Přihlášení uživatele virtuálního počítače: Uživatelé s touto rolí, kteří mají přiřazenou roli, se můžou přihlásit k virtuálnímu počítači Azure s běžnými uživatelskými oprávněními.
Podmíněný přístup: Klíčovou výhodou použití ID Microsoft Entra pro přihlašování k virtuálním počítačům Azure je možnost vynutit podmíněný přístup v rámci procesu přihlašování. To umožňuje organizacím vyžadovat splnění podmínek před povolením přístupu k virtuálnímu počítači a použití vícefaktorového ověřování k zajištění silného ověřování. Další informace najdete v tématu Použití podmíněného přístupu.
Poznámka:
Vzdálené připojení k virtuálním počítačům připojeným k ID Microsoft Entra je povolené jenom z počítačů s Windows 10, Windows 11 a Cloud pc, které jsou připojené k Microsoft Entra nebo hybridnímu připojení Microsoft Entra ke stejnému adresáři jako virtuální počítač.
Výzvy: Následující seznam zdůrazňuje klíčové výzvy při použití této možnosti pro izolaci identit.
Žádná centrální správa ani konfigurace serverů. Například pro skupinu serverů není možné použít žádné zásady skupiny. Organizace by měly zvážit nasazení řešení Update Management v Azure za účelem správy oprav a aktualizací těchto serverů.
Není vhodné pro vícevrstvé aplikace, které mají požadavky na ověřování pomocí místních mechanismů, jako je integrované ověřování Systému Windows na těchto serverech nebo službách. Pokud se jedná o požadavek pro organizaci, doporučujeme prozkoumat samostatné služby Doména služby Active Directory Services nebo scénáře služby Microsoft Entra Domain Services popsané v této části.
U tohoto izolovaného modelu se předpokládá, že neexistuje žádné připojení k virtuální síti, která hostuje virtuální počítače z podnikové sítě zákazníka. Měl by být vytvořen jumpbox nebo server pro správu, aby bylo možné povolit bod, ze kterého lze tyto servery spravovat a spravovat.