Privátní nasazení v Azure

Tato příručka je technickým vstupním bodem pro nasazení Siesta AI do zákazníkem řízeného prostředí Azure. Vymezuje hranice mezi zákaznickou platformou, verzovaným balíčkem nasazení Siesta AI, privátním režimem aplikace a doklady potřebnými pro předání do produkce.

Podrobné provozní postupy zůstávají v sekci Nasazení a provoz. Pro přesnou topologii, regiony, úrovně služeb, cíle obnovy a způsob doručení jsou autoritativní implementační dohoda a balíček konkrétního zákaznického nasazení.

Kontrakt nasazení

Privátní nasazení běží v tenantovi a subscription Azure řízených zákazníkem. Zákazníkem řízené prostředí nemusí nutně znamenat, že je zákazníkem také provozované: rozdělení odpovědností musí určit, kdo jednotlivé vrstvy nasazuje, schvaluje, monitoruje, podporuje a obnovuje.

Zákazník vlastní nebo výslovně deleguje:

• správu subscription a tenantu, Azure Policy, registraci poskytovatelů prostředků, kvóty a kontrolu nákladů;
• virtuální sítě, privátní DNS, ingress, TLS certifikáty, odchozí přístup, firewally a konektivitu k firemním službám;
• administraci Microsoft Entra, bezpečnostní skupiny, privilegovaný přístup a schvalování oprávnění aplikace;
• cíle monitoringu, integraci se SIEM, retenci, směrování incidentů, politiku záloh a cíle obnovy;
• change window a identity oprávněné kontrolovat, importovat, nasazovat a vracet releasy.

Siesta AI dodává dohodnuté verzované infrastrukturní a aplikační artefakty, dokumentuje jejich požadované vstupy a společně se zákazníkem ověřuje nasazenou aplikaci. S balíčkem zacházejte jako s jedním release celkem: nekombinujte nezkontrolovanou infrastrukturu jedné verze s aplikačními artefakty jiné verze.

Struktura IaC balíčku

Referenční balíček používá Bicep entrypoint na úrovni subscription a orchestrátor na úrovni resource group. Před změnou parametrů si přečtěte dodanou verzi, protože právě ta je spustitelným kontraktem daného releasu.

Cesta	Technický účel
bicep/deploy.bicep	Entrypoint na úrovni subscription. Vytvoří resource group nasazení, spustí deployment do resource group a vrátí endpointy aplikace a API.
bicep/main.bicep	Orchestrátor na úrovni resource group. Propojuje výstupy modulů s navazujícími vstupy a definuje graf závislostí nasazení.
bicep/modules/*.bicep	Moduly prostředků pro síť, monitoring, identity, registry, data, tajné hodnoty, AI služby, compute, privátní DNS a Private Endpoints.
bicep/parameters/<ENVIRONMENT>.json	Zákazníkem řízené hodnoty bez tajných údajů pro jedno prostředí. Zákaznické parameter files ukládejte do schváleného privátního místa doručení, ne do veřejných příkladů.
bicep/deploy.ps1	Volitelný pomocný skript, který balíček validuje a zobrazí náhled změn před výslovně vyžádaným deploymentem. Před spuštěním zkontrolujte skript z dodaného releasu.

Referenční balíček nenahrazuje zákaznický enterprise edge, firemní DNS, životní cyklus TLS, správu firewallu, schválení kapacity modelů ani schvalování releasů. Tyto vstupy se k balíčku připojují prostřednictvím implementační dohody konkrétního zákazníka.

Kontrakt top-level parametrů

Subscription entrypoint aktuálně přijímá následující skupiny parametrů. Produkční hodnoty neodvozujte z výchozích hodnot modulu ani z ukázkového souboru.

Skupina parametrů	Kontrakt a body ke kontrole
Umístění	Azure location musí splnit zákaznické politiky a požadavky na dostupnost všech zvolených služeb.
Pojmenování	clientCode je jedno- až tříznakový kód nasazení. environment přijímá tst, tes, dev, stg nebo pro. Před apply potvrďte, že výsledné názvy odpovídají zákaznickým pravidlům.
Úrovně služeb	Úrovně registry, primární databáze, retrieval databáze, AI Services, AI Search a Storage jsou explicitní vstupy. Místo kopírování ukázkových hodnot ověřte podporu Private Linku, kapacitu, odolnost a cenu.
Správa Microsoft Entra	Zadejte zobrazovaný název a object ID schválené skupiny administrátorů SQL. Použijte skupinu, ne osobní identitu.
Ochrana prostředků	enableLocks řídí zámky CanNotDelete na podporovaných kritických prostředcích. Slaďte jej s životním cyklem prostředí a zdokumentovaným break-glass postupem.

Vnořené moduly mohou obsahovat další síťové a runtime parametry. Kontrola doručení musí potvrdit, že subscription entrypoint každý zákazníkem řízený parametr buď zpřístupňuje, nebo jej záměrně fixuje. Před produkcí zejména odmítněte široký catch-all zdroj ingressu a omezte ingress na schválenou gateway nebo nadřazenou síť.

Validace, náhled a apply

Validaci spouštějte ve stejném scope jako entrypoint. Použijte přístupově omezený parameter file a jedinečný název deploymentu dohledatelný ke schválenému releasu.

az bicep build --file bicep/deploy.bicep

az deployment sub validate \
  --location "<DEPLOYMENT_LOCATION>" \
  --name "<DEPLOYMENT_NAME>" \
  --template-file bicep/deploy.bicep \
  --parameters @bicep/parameters/<ENVIRONMENT>.json

az deployment sub what-if \
  --location "<DEPLOYMENT_LOCATION>" \
  --name "<DEPLOYMENT_NAME>" \
  --template-file bicep/deploy.bicep \
  --parameters @bicep/parameters/<ENVIRONMENT>.json

Zkontrolujte celý výsledek what-if, včetně přiřazení rolí, síťových pravidel, propojení privátního DNS, nahrazení prostředků a mazání. Přesně zkontrolovanou šablonu a parameter file aplikujte až po schválení:

az deployment sub create \
  --location "<DEPLOYMENT_LOCATION>" \
  --name "<DEPLOYMENT_NAME>" \
  --template-file bicep/deploy.bicep \
  --parameters @bicep/parameters/<ENVIRONMENT>.json

az deployment sub show \
  --name "<DEPLOYMENT_NAME>" \
  --query properties.outputs

Hash kompilované šablony, hash parameter file, what-if, schválení, operace deploymentu a výstupy archivujte jako jednu sadu důkazů. Výstupy jsou metadata nasazení pro navazující bootstrap; nepovažujte je za oprávnění zveřejnit privátní endpoint nebo zkopírovat tajné hodnoty do logu pipeline.

Předpoklady na straně zákazníka

Tyto vstupy vyřešte před implementačním oknem. Hodnoty konkrétního zákazníka zaznamenávejte pouze do přístupově omezeného deployment workbooku nebo předávacího balíčku, nikdy do veřejné dokumentace ani příkladů zdrojového kódu.

Oblast	Požadované rozhodnutí nebo vstup
Rozsah Azure	Tenant, subscription, schválené regiony, poskytovatelé prostředků, přiřazení politik, pravidla pojmenování a tagování, rozpočet a kvóty služeb
Síť a DNS	Vlastnictví virtuální sítě a subnetů, integrace privátního DNS, ingress hostname, vlastnictví TLS, povolený egress, proxy nebo firewallová cesta a testy konektivity
Identity a přístup	Deployment identita, administrátoři Microsoft Entra, skupiny operátorů, skupina administrátorů databáze, workload identity, schvalovatelé RBAC a proces kontroly přístupů
Doručení artefaktů	Zákaznický Azure Container Registry, importní nebo přenosová identita, povolený zdroj, proces ověření digestu a vlastník auditu
AI kapacita	Schválená nasazení modelů, regionální dostupnost, kvóty tokenů a propustnosti, požadavky na content safety a rozhodnutí o fallbacku
Provoz	Cíle Log Analytics nebo ekvivalentu, vlastníci alertů, předávání do SIEM, kontakty podpory, maintenance window a eskalační cesta
Odolnost	Rozsah a retence záloh, vlastník obnovy, otestované cíle RTO/RPO, osoba rozhodující o rollbacku a schválené change window
Identita aplikace	Registrace aplikace Microsoft Entra vlastněná organizací, tenant a client ID, redirect URI pro povolené povrchy, oprávnění Graphu a admin consent

Pomocí Životního cyklu nasazení převeďte vstupy na zkontrolovanou implementační posloupnost.

Referenční architektura

Referenční balíček Infrastructure as Code zřizuje logické vrstvy, nikoli jeden pevný univerzální počet prostředků. Konkrétní povolené moduly, topologii, SKU a regionální umístění určuje balíček daného zákazníka.

Vrstva	Typická odpovědnost v referenčním balíčku
Identity a tajné hodnoty	Managed identities, přiřazení RBAC, integrace Microsoft Entra a odkazy na Key Vault
Síť a překlad názvů	Integrace virtuální sítě, Private Endpoints, privátní DNS zóny a jejich propojení, řízení ingressu a schválený egress
Registry a workloady	Azure Container Registry, Container Apps, Functions, workload identity, stahování images, health probes a konfigurace škálování
Data a messaging	Azure SQL, Storage, fronty nebo messaging závislosti, konfigurace záloh a privátní přístup ke službám
AI a retrieval	Azure AI Services, schválená nasazení modelů, AI Search a Document Intelligence tam, kde jsou potřeba
Provoz	Azure Monitor, Application Insights, Log Analytics, diagnostická nastavení, alerty a předávání do zákaznického SIEM

Kanonické hranice služeb a důvěry popisují Referenční architektura, Runtime služby a Síťová bezpečnost.

Graf závislostí modulů

main.bicep propojuje prostředky v pořadí závislostí. Bicep odvozuje většinu závislostí z výstupů modulů, proto tyto reference zachovejte a nenahrazujte je ručně sestavenými názvy prostředků.

Fáze	Moduly a účel závislostí
1. Základ	Síť, Log Analytics/Application Insights a oddělené user-assigned managed identities pro API, retrieval, tools a frontend workloady.
2. Data plane	Container Registry, Storage, dvě hranice Key Vaultu, SQL databáze, Azure AI Services a AI Search. Tyto moduly přebírají principal ID identit a výstupy monitoringu.
3. Compute	Interní managed environment Container Apps a jeho aplikační workloady, následované App Service planem a Function Apps. Compute přebírá výstupy registry, identity, subnetu, Key Vaultu, Storage a monitoringu.
4. Podpůrné služby	Communication Services a Document Intelligence, pokud je dodaný balíček obsahuje.
5. Privátní přístup	Privátní DNS zóny propojené s virtuální sítí, potom Private Endpoints a DNS zone groups pro podporované PaaS prostředky.
6. Bootstrap	Vypočítané endpointy a metadata připojení s identitou se zapisují až po vytvoření jejich zdrojů. Zákaznické tajné hodnoty a schválené aplikační artefakty se dodávají řízenou release cestou.

Jde o model závislostí, ne o doporučení spouštět šest nezávislých deploymentů. Běžnou jednotkou validace a apply zůstává subscription entrypoint.

Kontrakt sítě a privátního DNS

Referenční síť odděluje tři účely provozu:

Účel subnetu	Azure delegace nebo politika	Očekávaný provoz
Infrastruktura Container Apps	Delegováno na Microsoft.App/environments	Infrastruktura interního managed environment a aplikační ingress ze schváleného nadřazeného zdroje
Private Endpoints	Zapnuté síťové politiky Private Endpoint	Private Link připojení k datům, registry, tajným hodnotám, AI a Function prostředkům
Integrace služeb	Delegováno na Microsoft.Web/serverfarms	VNet integrace Function Apps a odchozí přístup ke schváleným platformním závislostem

Balíček vytváří privátní DNS zóny pro jednotlivé služby a jejich propojení s virtuální sítí pro povolené Azure služby. Aktuální referenční sada pokrývá endpointy Storage blob, file a queue; Key Vault; Azure SQL; Cognitive Services; AI Search; App Service/Functions; Container Apps a Container Registry. Každý Private Endpoint je spojen s odpovídající zónou prostřednictvím Private DNS zone group.

Privátní konektivitu neověřujte z veřejné pracovní stanice. Z hostu používajícího zákaznický resolver a připojenou síť potvrďte, že FQDN každé služby překládá zamýšlená privátní zóna a že připojení dorazí ke správnému prostředku. Úspěšný DNS lookup sám o sobě nedokazuje NSG, route, firewall, RBAC ani přístup na aplikační vrstvě.

Kontrakt managed identity a RBAC

Referenční balíček používá oddělené user-assigned identity, aby zůstala oddělena oprávnění frontendu, API, retrievalu a nástrojů.

Principal	Referenční hranice přístupu
Workload identita frontendu	Stahuje schválené frontend images ze zákaznické registry. Nedědí sadu data-plane rolí služeb.
Identita API	Stahuje images a přistupuje ke schváleným data-plane rozhraním Key Vaultu, Storage, Azure AI Services, AI Search a Document Intelligence potřebným pro API a API Functions.
Identita retrievalu	Stahuje images a přistupuje ke stejným schváleným data-plane rozhraním pro retrieval workloady, background processing a retrieval Functions.
Identita tools	Stahuje images a přistupuje ke schváleným data-plane rozhraním potřebným pro tools workload.
Skupina zákaznických administrátorů	Provozuje registry a podporované datové služby, spravuje Key Vault a podle dodaného balíčku plní roli administrátora Microsoft Entra pro Azure SQL.

Mezi reprezentativní vestavěná data-plane přiřazení patří AcrPull, Key Vault Secrets User, Key Vault Crypto User, Storage Blob Data Owner, Storage Queue Data Contributor, Storage Table Data Contributor, Cognitive Services User, Search Index Data Contributor a Search Service Contributor. Přiřazení zákaznických operátorů jsou širší a musí zůstat založena na skupinách, schválena, podle potřeby časově omezená a kontrolována odděleně od workload identit.

Propagace přiřazení rolí Azure může chvíli trvat. Než workload označíte za nefunkční, ověřte, že očekávané principal ID získalo očekávané přiřazení ve správném scope prostředku, a opakujte pokus až po propagaci. Nepřidávejte jako workaround sdílené přihlašovací údaje.

Kontrakt runtime a bootstrapu

Aktuální referenční compute topologie obsahuje:

• frontend a API Container Apps s aplikačním ingressem uvnitř interního prostředí Container Apps;
• interní retrieval a tools Container Apps;
• retrieval worker bez ingressu;
• privátní API a retrieval Function Apps integrované se service subnetem.

Container Apps stahují images ze zákaznické registry pomocí svých user-assigned identit a zveřejňují readiness nebo liveness probes vhodné pro jednotlivé workloady. Function Apps vypínají public network access, vyžadují ověření, vynucují HTTPS a TLS 1.2, integrují se service subnetem a pro Storage binding používají managed identity.

Infrastrukturní deployment může vytvořit kostry workloadů a vypočítanou konfiguraci, ale sám o sobě nevytváří prostředí připravené pro produkční release. Před akceptací:

1. nahraďte každou bootstrap image referenci schváleným aplikačním artefaktem a ověřte digest v zákaznické registry;
2. každou nevyřešenou značku tajné hodnoty nahraďte schválenou cestou doručení secrets, aniž by se hodnota dostala do Bicep parametrů, source control, výstupů deploymentu nebo logů;
3. zřiďte a schvalte požadovaná nasazení modelů a kvóty pro vybraný region;
4. použijte databázové migrace a kroky bootstrapu aplikace z odpovídajícího release balíčku;
5. potvrďte, že revisions Container Apps a Function deploymenty používají očekávané identity, konfiguraci a verze artefaktů.

Public network access je vypnutý pro referenční Registry, Storage, Key Vault, SQL, AI/Search, Document Intelligence a Function prostředky. Ověřování pomocí lokálních nebo sdílených klíčů je také vypnuté tam, kde služba podporuje cestu přes managed identity. Každou zákaznicky specifickou výjimku evidujte jako explicitní zkontrolovanou odchylku s vlastníkem a datem odstranění.

Privátní režim a identita

Privátní režim se aktivuje jako součást dodaného deployment balíčku a musí být použit konzistentně pro frontend i API. Nejde o nezávislý produktový přepínač, který se zapíná až po nasazení.

V privátním režimu:

• přihlášení používá aplikaci Microsoft Entra vlastněnou zákazníkem;
• nejsou dostupné cesty pro heslo, lokální účet, Google ani otevřenou samoobslužnou registraci;
• onboarding je omezen na nakonfigurovanou organizaci a tenant;
• onboarding přes pozvánky, automatické vytvoření účtu při prvním přihlášení přes Microsoft a synchronizace skupin Microsoft Entra zůstávají samostatnými rozhodnutími organizace;
• role a oprávnění organizace nadále řídí, co může ověřený uživatel dělat.

Kontrakt identity vytvořte před širokým onboardingem. Parametry pro web, mobilní aplikaci, Windows, macOS a browser extension nastavte podle článku Konfigurace registrace aplikace Microsoft Entra ID. Administrátorské, deployment, workload a support identity popisuje Identita a přístup.

Konfigurace enterprise klientů

Povolené klientské povrchy obdrží verzovaný dokument siestaEnterpriseConfig. Identifikuje deployment a veřejného klienta Microsoft; nesmí obsahovat client secret, privátní klíč certifikátu, token ani autorizační kód.

{
  "schemaVersion": 1,
  "type": "siestaEnterpriseConfig",
  "workspaceId": "<WORKSPACE_ID>",
  "displayName": "<ORGANIZATION_NAME>",
  "apiBaseUrl": "https://<API_HOST>",
  "frontendUrl": "https://<APP_HOST>",
  "organizationId": "<ORGANIZATION_ID>",
  "microsoft": {
    "tenantId": "<DIRECTORY_TENANT_ID>",
    "clientId": "<APPLICATION_CLIENT_ID>"
  },
  "loginMode": "microsoftOnly"
}

Konfigurace je dostupná pouze tehdy, když je aktivní privátní režim, organizace povolila alespoň jeden podporovaný aplikační povrch, poskytovatel identity Microsoft je povolený a obsahuje tenant i client ID a obě aplikační URL jsou absolutní HTTPS adresy.

Mobile App může konfiguraci importovat z QR kódu zobrazeného v Profile → Apps & Extensions. Povolené browser a desktop povrchy mohou ve stejné části stáhnout JSON konfiguraci. Používejte vygenerovaný soubor nebo QR kód; dokument ručně nesestavujte ani neupravujte. Přestože soubor obsahuje identifikátory, nikoli přihlašovací údaje, zacházejte s ním jako s deployment metadaty a distribuujte jej pouze schváleným zákaznickým kanálem.

Před distribucí konfigurace zaregistrujte každý povolený povrch: Mobile App, Windows App, macOS App a Browser Extension.

Artefakty a release flow

Infrastruktura a aplikační dodávka jsou dvě oddělené kontrolované cesty, které se spojí v jednom schváleném releasu.

Cesta infrastruktury

1. Připněte verzi balíčku Infrastructure as Code a shromážděte schválené zákaznické vstupy.
2. Spusťte syntaktické a validační kontroly a poté zkontrolujte výstup Azure what-if pro vytváření, aktualizace, nahrazení a odstranění.
3. Před schválením vyřešte chyby politik, kvót, přiřazení rolí, překladu názvů a nevyplněných placeholderů.
4. Použijte zkontrolovaný balíček se schválenou deployment identitou a uchovejte doklady o nasazení.

Opakovatelnost, práci s parametry a řízení driftu popisuje Infrastructure as Code.

Cesta aplikace

1. Vyberte schválené neměnné aplikační artefakty stejného releasu a zaznamenejte jejich verze a image digesty.
2. Přeneste schválené images do zákaznického registru a ověřte výsledné digesty.
3. Aktualizujte Container Apps a Functions na schválené verze bez nového sestavení releasu v zákaznickém prostředí, pokud je implementační dohoda výslovně nevyžaduje.
4. Před povýšením releasu spusťte kontroly zdraví, identity, dat, modelů, nástrojů, background processingu a observability.

Doručení artefaktů může použít cross-tenant import registru, schválený jumpbox nebo jinou zákazníkem schválenou cestu. Každá zvolená cesta musí zachovat zdrojovou verzi a digest, oddělení povinností, schválení, doklady o skenování a auditovatelný záznam přenosu.

Validace, rollback a předání

Prostředí neoznačujte za připravené pouze na základě úspěšného nasazení. Zaznamenejte doklady pro každou použitelnou bránu.

Brána	Minimální doklady před go-live
Vstupy, politika a kvóty	Žádné nevyřešené placeholdery; dostupní požadovaní poskytovatelé a kvóty; přijatá omezení politik a regionů
DNS, TLS a privátní přístup	Veřejné i privátní názvy se překládají z určených sítí; řetězec certifikátu a hostname jsou platné; Private Endpoints používají očekávané DNS zóny
Identity a tajné hodnoty	Managed identities a RBAC jsou funkční a s nejnižšími oprávněními; workloady překládají odkazy na Key Vault; žádná tajná hodnota není vložena v konfiguraci nebo image
Integrita artefaktů	Nasazené tagy odpovídají schváleným digestům; stažení ze zákaznického registru funguje; doklady původu a skenování jsou uchovány
Zdraví workloadů	Spuštění Container Apps a Functions, readiness a liveness probes, kontroly závislostí, škálování a chování při restartu projdou
Identita uživatele	Přihlášení pouze přes Microsoft, omezení tenantu, onboarding v rámci organizace, pozvánky a případná schválená synchronizace skupin fungují podle dohody
Produktové cesty	Chat, retrieval, schválená nasazení modelů, nástroje agentů, uploady a background processing projdou reprezentativními testy
Provoz	Logy, traces, metriky, alerty, dashboardy, retence, předávání do SIEM a směrování podpory jsou viditelné určeným vlastníkům
Obnova	Předchozí verze artefaktů a konfigurace jsou dostupné; jsou zaznamenány kroky rollbacku i rozhodovací pravomoc; obnova ze zálohy je otestována vůči dohodnutým cílům

Doklady monitoringu připravte podle Observability a akceptaci, runbooky, vlastnictví a přechod podpory podle Rolloutu a předání.

Řešení problémů

Příznak	Nejprve zkontrolujte
Přihlášení přes Microsoft nebo redirect selže	Tenant a client ID, povoleného poskytovatele, redirect zaregistrovaný pro přesný klientský povrch, HTTPS URL aplikace, admin consent a politiku onboardingu organizace
Enterprise konfigurace není dostupná	Aktivaci privátního režimu, přepínače aplikačních povrchů organizace, povoleného poskytovatele Microsoft, tenant/client identifikátory a absolutní HTTPS URL frontendu a API
Frontend se otevře, ale volání API selhávají	API hostname a TLS, směrování ingressu, CORS nebo origin policy, audience bearer tokenu, zdraví API a privátní DNS ze sítě volajícího
Privátní služba Azure není dostupná	Stav Private Endpointu, subnet policy, propojení a záznamy privátní DNS zóny, firewallová pravidla, route tables a schválenou egress cestu
Workload nemůže stáhnout image	Digest v zákaznickém registru, workload identitu nebo registry RBAC, síťovou dostupnost, shodu tagu s digestem a registry policy
Retrieval, ingestion nebo background úloha stojí	Zdraví Functions, přístup k frontě nebo Storage, konektivitu SQL a Search, kvótu AI služby, případně Document Intelligence a diagnostické traces
Validace nebo apply infrastruktury je blokovaný	Nevyřešené parametry, Azure Policy, registraci poskytovatelů, oprávnění, kvótu, regionální dostupnost a zkontrolované změny what-if
Rollback nebo obnova nesplňuje cíl	Retenci artefaktů, verzi konfigurace, kompatibilitu databáze, integritu záloh, oprávnění k obnově a poslední zaznamenaný test obnovy

Při eskalaci uveďte verzi releasu, čas, correlation ID, dotčenou komponentu, sanitizovanou chybu a již dokončené kontroly. Nikdy nepřikládejte tajné hodnoty, tokeny, privátní klíče, úplné exporty konfigurace, inventáře zákaznických prostředků ani neomezené diagnostické archivy.