# Корпоративный стек без тумана Экспресс-курс о системах, которые встречаешь внутри американской компании среднего размера, когда строишь там ИИ-агентов. Актуально на октябрь 2026. 42 понятия — иерархия ресурсов Azure, Managed Identity, Key Vault, Private Endpoint, Microsoft Foundry, IdP и SSO, OIDC и SAML, app registrations и service principals в Entra ID, delegated и application permissions, Conditional Access, Entra Agent ID, Okta, SCIM, Cross App Access, virtual warehouses и service users в Snowflake, Cortex, Delta Lake и Unity Catalog в Databricks, Agent Bricks, OneLake и capacities в Microsoft Fabric, data agents, least privilege, security review и другие — у каждого английское название, схема и карточка «что это → пример → подвох → связи». В конце — шпаргалка на одной странице. - **Author:** Фёдор Чищин - **Level:** intermediate - **Reading time:** ~55 минут чтения - **Published:** 2026-10-16 - **Source:** https://fedorthinks.com/ru/learn/enterprise-stack-express --- ## 1. Карта Шесть названий продуктов, три работы. Прежде чем лезть в детали, пойми, к какому слою относится каждая система и где между ними сидит твой ИИ-проект. ### Карта: 42 понятия в восьми главах > Карта метро: сначала видишь линии целиком, потом едешь по станциям. Курс идёт по трём слоям. Сначала **облако** — Microsoft Azure, где работает твой код и модели компании. Потом **идентичность** — Microsoft Entra ID и Okta: они решают, кто может войти и что ему можно трогать. Потом **данные** — Snowflake, Databricks и Microsoft Fabric, где компания держит цифры продаж, финансов и CRM. Последняя глава собирает всё вместе: как ИИ-агенту получить минимально возможный доступ, пройти security review у клиента и не ждать роль три недели. _Diagram: Три слоя, шесть систем — главы 2–7 идут по ним. Глава 8 — о том, как твой агент подключается ко всем сразу._ ### Как читать этот курс > Паспорт: у всех одни и те же поля, поэтому их легко сравнивать. У каждого понятия есть **английское название** (это слово ты услышишь на созвонах и прочитаешь в документации), образ из жизни, **схема** и **карточка**: _что это_, _пример_, _подвох_ и _связи_ с другими понятиями. Если знаешь Google Cloud, ты будешь снова и снова узнавать знакомое: большинство корпоративных систем — привычные идеи под другими именами. Названия продуктов здесь меняются часто — Azure AD стал Entra ID, Azure AI Foundry стал Microsoft Foundry, Vector Search стал AI Search, — поэтому курс даёт и старое имя. У клиента ты услышишь оба. ### Enterprise Stack — три слоя и проект посередине > Офисное здание: этажи принадлежат арендодателю (облако), охрана в лобби проверяет пропуска (идентичность), а архив в подвале хранит все записи (данные). Новому арендатору — ИИ-приложению — нужны все три. В каждой большой компании одни и те же три слоя. **Облако** — где работает код; в компании, которая живёт на Microsoft, обычно это Azure. **Идентичность** — справочник людей компании и стойка, через которую они входят: Entra ID или Okta. **Данные** — где лежат записи компании: Snowflake, Databricks или Fabric, обычно что-то одно из трёх. Твоё ИИ-приложение сидит посередине: сотрудники входят через identity provider компании, приложение работает в облаке компании и читает данные с минимальными нужными правами. Коротко: облако — _где работает код_, идентичность — _кого пускают_, данные — _что читают_. _Diagram: Сотрудники входят через Entra или Okta; твоё приложение получает токен, работает в облаке клиента и читает одну платформу данных._ #### Enterprise Stack (облако · идентичность · данные) - **Что это:** Три слоя, которые есть в каждой большой компании: облако, identity provider и платформа данных. - **Пример:** Логистическая фирма: Azure для кода, Entra ID для входа, Snowflake для данных о продажах — ИИ-агент касается всех трёх. - **Подвох:** У каждого слоя свой админ, свои тикеты и свои правила безопасности. Доступы — обычно самая медленная часть проекта. - **Связи:** Главы идут по слоям: **Azure**, **Entra ID / Okta**, **Snowflake / Databricks / Fabric**; всё сходится в **Least Privilege**. > **Вопрос рамки:** «Для каждой системы, которой я касаюсь: это облако (где работает мой код), слой идентичности (кого пускают) или слой данных (что я читаю) — и кто тот админ, который нужен мне в первый же день?» > Шесть названий продуктов — на самом деле три работы: облако запускает код, идентичность решает, кого пускать, а платформа данных хранит записи компании. Твой агент живёт между ними. ## 2. Облако: Microsoft Azure Azure — облако Microsoft. Если знаешь AWS или Google Cloud, идеи тебе уже знакомы. Меняются названия, строгая структура папок и то, насколько безопасность держится на identities, а не на ключах. ### Microsoft Azure — облако, которое выбирают, «потому что у нас всё Microsoft» > Переезд в новый город, где магазины те же, но называются иначе: супермаркет, аптека и булочная на месте — нужна только новая карта. **Microsoft Azure** — облако Microsoft, как AWS (Amazon) или Google Cloud: виртуальные серверы, контейнеры, базы данных, файловые хранилища, сети, очереди. Плюс доступ к моделям — OpenAI, Anthropic и другим — через **Microsoft Foundry**. Почему он везде в компаниях среднего размера? Они уже платят Microsoft за Office 365, Teams и Outlook, а сотрудники уже входят с рабочим аккаунтом Microsoft. Второе облако — это новый контракт, новая система входа, новые юристы и новый security review. А для ИИ есть причина важнее: многие компании не отправят данные в публичный `api.openai.com`, а модели в Azure работают внутри _их_ облака, по _их_ контракту и _их_ правилам доступа. _Diagram: Одни и те же кирпичики в трёх облаках. Проект в Google Cloud ≈ подписка + resource group в Azure; service account ≈ managed identity._ #### Microsoft Azure (облако Microsoft) - **Что это:** Публичное облако Microsoft: вычисления, хранилище, сети, базы данных и ИИ-модели. - **Пример:** Компания на Office 365 запускает нового ИИ-ассистента в Azure — счёт идёт по тому же контракту с Microsoft, вход через те же рабочие аккаунты. - **Подвох:** Два вида прав: **Azure RBAC** (на ресурсы) и роли Entra (на каталог) — разные вещи. Contributor на подписке не даёт права создать app registration. - **Связи:** Устроен по **Resource Hierarchy**; вход — через **Entra ID**; модели — из **Microsoft Foundry**. ### Resource Hierarchy — tenant → subscription → resource group > Матрёшка: компания держит папки контрактов, в каждом контракте — коробки проектов, в каждой коробке — сами вещи. Открой большую матрёшку — и всё внутри идёт вместе с ней. Azure строг к структуре, и она нужна тебе с первого дня, потому что по ней идут и доступы, и счета. **Tenant** — вся компания в мире Microsoft: один каталог людей и приложений, живёт в Entra ID. **Management group** — папка подписок с общими правилами (**Azure Policy**, например «ресурсы только в East US»). **Subscription** — контракт + счёт + граница доступа; обычно отдельные для prod и dev. **Resource group** — папка для вещей, которые живут и умирают вместе: приложение, его база, его vault. Удалишь группу — уйдёт всё внутри. Главное правило: роль **Azure RBAC** (кто что может), выданная на верхнем уровне, действует на всё ниже. Поэтому проси роль на _одну_ resource group, а не на подписку. _Diagram: Tenant → management group → subscription → resource group → resource. Роль, выданная выше, стекает на всё, что ниже._ #### Resource Hierarchy (tenant · subscription · resource group) - **Что это:** Вложенные папки Azure: tenant → management group → subscription → resource group → resource. - **Пример:** Твой доступ как подрядчика: гостевой аккаунт в их tenant и роль Contributor только на `rg-ai-agent-dev`. - **Подвох:** Новая роль может начать работать только минут через 5 (иногда дольше). 403 сразу после выдачи — это нормально, подожди. - **Связи:** Верхний уровень — tenant в **Entra ID**; роли выдают **Managed Identity**, человеку или группе. ### Where Code Runs — App Service, Container Apps, AKS, Functions > Способы добраться до работы: автобус по расписанию (Functions), такси, которое просто вызываешь (App Service), каршеринг — сам за рулём, но никакого обслуживания (Container Apps), и своя машина со всем её ремонтом (AKS). В Azure четыре обычных дома для твоего кода. **App Service** — «просто залей веб-приложение»; как Heroku, стиль постарше, запускает Python, Node, .NET или контейнер. **Container Apps** — контейнеры без мыслей о серверах, с автоскейлингом до нуля; ближе всего к Google Cloud Run и обычно лучший выбор для бэкенда агента. **AKS (Azure Kubernetes Service)** — полноценный Kubernetes, как GKE; бери, только если у клиента уже есть Kubernetes-платформа. **Functions** — код, который запускается по событию (HTTP, таймер, очередь); хорош для фоновых задач вроде «пришёл файл — обработай». _Diagram: От «меньше забот» к «больше контроля». Для бэкенда агента Container Apps — обычно правильный выбор по умолчанию._ #### Container Apps (App Service · AKS · Functions) - **Что это:** Serverless-контейнеры Azure — обычный дом для бэкенда ИИ-агента. - **Пример:** API агента работает как Container App со своей managed identity и ночью сжимается до нуля. - **Подвох:** Забытый кластер AKS или большая VM стоит сотни или тысячи долларов в месяц. Поставь бюджетные алерты на resource group и удаляй dev-ресурсы. - **Связи:** Права получает через **Managed Identity**; до сервисов ходит через **Private Endpoints**. ### Managed Identity — аккаунт для приложения совсем без пароля > Ключ-карта в отеле, которую ресепшен каждое утро программирует заново: мастер-ключа у тебя нет, карта открывает только твои комнаты и сама перестаёт работать. **Managed identity** — аккаунт для твоего приложения, который Azure создаёт и обслуживает сам. Ни пароля, ни файла с ключом: код просто просит у Azure токен. На практике ты вызываешь `DefaultAzureCredential()` — на ноутбуке он берёт твой `az login`, а внутри Container App получает короткоживущий токен от Entra ID (живёт около часа) через локальный endpoint. Дальше ты даёшь этой identity ровно те роли, что нужны, например **Cognitive Services OpenAI User** на ресурс Foundry. Это версия service account из Google Cloud для Azure — только без JSON-ключей. Видов два: **system-assigned** живёт и умирает вместе с одним ресурсом; **user-assigned** — отдельный объект, который можно прицепить к нескольким ресурсам. _Diagram: Container App просит у Entra токен, получает его примерно на час и с ним вызывает модель. Ключа, который мог бы утечь, просто нет._ #### Managed Identity (system- или user-assigned) - **Что это:** Аккаунт для приложения, которым управляет Azure: получает токены от Entra ID, пароля не хранит никогда. - **Пример:** Агент вызывает модель с токеном из `DefaultAzureCredential()` — ни одного API-ключа ни в коде, ни в конфиге. - **Подвох:** С октября 2025 Microsoft вводит обязательный MFA для изменений через CLI, SDK и Terraform от имени пользователя. Автоматизируй через managed или workload identity, а не через личный аккаунт. - **Связи:** Особый вид **Service Principal**; секреты читает из **Key Vault**; CI так же использует workload identity federation (OIDC). ### Key Vault — сейф для секретов > Банковская ячейка: ценности не лежат в ящике стола в офисе, открыть ячейку могут только люди из списка — и каждый визит записывается. Иногда секрет всё же нужен — скажем, API-ключ от CRM клиента или приватный ключ Snowflake. **Key Vault** — сейф Azure для секретов, ключей и сертификатов, как Secret Manager в Google Cloud. Приложение читает секрет своей managed identity, у которой есть роль **Key Vault Secrets User** на этот vault. Ничего не лежит в `config.yaml` или в `.env` в git. Именно этот ответ хочет услышать команда безопасности на вопрос «где ваши секреты?». _Diagram: До: пароли в конфигах. После: агент читает каждый секрет из Key Vault своей identity и с узкой ролью._ #### Key Vault (секреты · ключи · сертификаты) - **Что это:** Управляемое хранилище Azure для секретов, ключей и сертификатов. - **Пример:** При старте агент забирает из Key Vault ключ CRM и приватный ключ Snowflake. - **Подвох:** Vault, закрытый private endpoint, недоступен с твоего ноутбука — заранее продумай путь для dev. - **Связи:** Читается через **Managed Identity**; часто спрятан за **Private Endpoint**. ### Private Endpoint — сервисы без двери в интернет > Офисное здание, где у архива вообще нет входа с улицы: попасть туда можно только по внутреннему коридору, после того как тебя пропустили в лобби. **VNet (Virtual Network)** — частная сеть клиента в Azure, как VPC в Google Cloud. **Private endpoint** даёт сервису — Key Vault, Foundry, Postgres — частный IP-адрес внутри этой VNet. После этого сервис можно полностью закрыть от интернета (`publicNetworkAccess: Disabled`). Корпоративная безопасность это обожает, а в компаниях среднего размера это часто обязательно. Платишь за это ты: твой локальный код больше не достучится до закрытого сервиса. Понадобится VPN, jump box или dev-среда внутри VNet — и правильно настроенный **private DNS**, классический источник вопроса «почему это имя не резолвится?». _Diagram: Внутри VNet агент ходит к каждому сервису по частному IP. Интернет — и твой ноутбук — внутрь не попадут._ #### Private Endpoint (VNet · private link) - **Что это:** Частный IP облачного сервиса внутри сети клиента, чтобы сервис можно было закрыть от интернета. - **Пример:** Foundry, Key Vault и Postgres получают адреса вроде `10.0.1.4`; публичный доступ выключен. - **Подвох:** Ломает доступ с ноутбука и требует private DNS. Продумай путь для dev до первого деплоя. - **Связи:** Один из первых вопросов **Security Review**; родственник в Google Cloud — Private Service Connect. ### Microsoft Foundry — модели внутри tenant клиента > Столовая в офисе, которую ведёт внешний кейтеринг: еда та же, что в их ресторане, но готовят её в твоём здании, по твоим правилам и по твоему контракту. **Microsoft Foundry** — ИИ-платформа Azure. Имя менялось часто: Azure AI Studio (2023) → Azure AI Foundry (2024) → **Microsoft Foundry** (с конца 2025), а Azure OpenAI теперь часть «Foundry Models». В одном месте ты создаёшь **model deployment** — свою именованную копию модели (скажем, `gpt-4o-contracts`) со своей **quota**: **TPM** (токены в минуту) или **PTU** (ёмкость, купленная заранее). Агентов строишь в **Foundry Agent Service** с tools и MCP, плюс получаешь evaluations, content filters и трейсы. Старые endpoints и ключи Azure OpenAI в основном продолжают работать. Текущий scope токена — `https://ai.azure.com/.default`; в старых примерах — `https://cognitiveservices.azure.com/.default`. _Diagram: Код вызывает deployment по имени; ещё Foundry хостит агентов, evaluations и content safety. Три имени за три года._ #### Microsoft Foundry (бывший Azure AI Foundry · Azure OpenAI) - **Что это:** Платформа Azure для моделей (включая Azure OpenAI), агентов и evaluations. - **Пример:** `model="gpt-4o-contracts"` — в этом поле имя deployment, а не имя модели. - **Подвох:** Нужной модели может не быть в регионе клиента, или её TPM-квота слишком мала. Проверь до старта, а не в день демо. 404 часто значит неправильное имя deployment. - **Связи:** Вызывается с токеном **Managed Identity** через **Private Endpoint**; родственник в Google Cloud — Vertex AI, в AWS — Bedrock. > **Вопрос облака:** «Мой агент работает с managed identity, с ролями только на одну resource group, секреты в Key Vault, сервисы за private endpoints — и я проверил квоту модели в их регионе?» > Azure — знакомое облако со строгими папками. Проси одну resource group, дай приложению managed identity вместо ключей, держи секреты в Key Vault и проверь квоту модели в первый же день. ## 3. Идентичность: SSO и Entra ID Твоё приложение не должно проверять пароли. У компании уже есть стойка, которая знает каждого сотрудника. В этой главе — общие слова (IdP, SSO, OIDC), а потом стойка Microsoft, Entra ID, где живёт больше всего путаницы. ### Identity Provider и SSO — одна стойка для всех приложений > Охрана в бизнес-центре: охранник знает всех по пропуску. Офисы наверху сами паспорта не проверяют — они доверяют пропуску из лобби. **Identity provider (IdP)** — система, которая подтверждает: «это Анна, она из отдела продаж». Entra ID, Okta и Google — это IdP. **SSO (Single Sign-On)** — то, что чувствуют люди: входят один раз рабочим аккаунтом и дальше попадают во все приложения — Outlook, Salesforce, Jira, твоего агента — без новых паролей. До этого у каждого приложения был свой логин: пятнадцать паролей на человека, половина на стикерах, новички неделю ждут аккаунтов, а ушедшие ещё полгода открывают CRM. С IdP айтишники выключают один аккаунт — и доступ пропадает везде. И есть один журнал: кто куда входил. _Diagram: Сотрудник входит один раз у identity provider; каждое приложение — и твоё тоже — доверяет этому входу._ #### Identity Provider (IdP · SSO) - **Что это:** Сервис входа компании; с ним один рабочий аккаунт открывает все приложения (SSO). - **Пример:** У внутреннего агента нет формы логина — «Войти» отправляет людей в Entra ID или Okta клиента. - **Подвох:** Ты им не управляешь. Любое изменение того, как твоё приложение логинит людей, идёт через IT клиента. - **Связи:** Говорит на **OIDC или SAML**; два главных — **Entra ID** и **Okta**. ### OIDC и SAML — как приложение спрашивает стойку > Два способа доказать, что ты гость: QR-код в телефоне, который дверь сканирует за секунду (OIDC), или бумажное письмо с печатью от хозяина, которое охранник читает строчку за строчкой (SAML). Два стандарта позволяют приложению «спросить стойку». **OAuth 2.0** — как получить access token, чтобы вызвать API. **OIDC (OpenID Connect)** стоит поверх OAuth и нужен для входа: он добавляет **ID token** — JWT, где сказано, кто этот человек. Для нового веб-приложения OIDC — выбор по умолчанию. **SAML** — более старый XML-стандарт, всё ещё частый в корпоративном SaaS; бери его, если клиент настаивает. Обычный поток OIDC — **authorization code + PKCE**: редирект на IdP, человек входит (с MFA), IdP возвращает одноразовый код, твой бэкенд меняет его на токены. Потом ты проверяешь ID token: подпись (ключи из JWKS), `iss`, `aud`, срок, `nonce`. Для фоновой работы без человека есть поток **client credentials**; когда твой API вызывает другой API от имени пользователя — **on-behalf-of (OBO)**. _Diagram: Authorization code + PKCE: браузер идёт к IdP и возвращается с кодом, бэкенд меняет код на токены и проверяет их._ #### OIDC and SAML (OAuth 2.0 · auth code + PKCE) - **Что это:** Стандарты, через которые приложение логинит людей через IdP. OIDC — современный JSON/JWT; SAML — более старый XML. - **Пример:** Тот же поток «код + PKCE», что ты знаешь по «Войти через Google», только направленный на `login.microsoftonline.com/` или `acme.okta.com`. - **Подвох:** Никогда не используй email как ключ пользователя — он меняется. Бери стабильный ID: `oid` + `tid` в Entra, `sub` в Okta. - **Связи:** IdP за ним — **Entra ID** или **Okta**; приложение, с которым он говорит, — **App Registration**. ### Microsoft Entra ID — справочник компании в облаке > Справочник сотрудников, скрещённый со шкафом ключей: в нём каждый человек и каждая группа, и он же выдаёт ключи. **Microsoft Entra ID** — до 2023 года **Azure AD** — облачный каталог людей и приложений компании от Microsoft плюс её сервер входа. **Tenant** — каталог одной организации: у него есть ID (GUID) и домены вроде `contoso.com`. Внутри — **users** (сотрудники и **guests**: ты как подрядчик обычно заходишь B2B-гостем со своей почтой), **groups** (security groups для прав; группы бывают статические и динамические, например «все с department = Sales») и **apps**. Многие компании до сих пор держат старый локальный **Active Directory** и синхронизируют его в Entra через **Entra Connect**. Правило для твоего приложения: давай права группам, а не людям. IT добавляет человека в группу — он получает доступ, а ты не трогаешь код. _Diagram: Один tenant держит пользователей (включая гостей), группы и приложения. Старый локальный AD часто синхронизируется в него._ #### Microsoft Entra ID (бывший Azure AD) - **Что это:** Облачный каталог и identity provider Microsoft для сотрудников, групп и приложений. - **Пример:** Агент по контрактам пускает только участников группы `AI-Agent-Users` в tenant `contoso.com`. - **Подвох:** Для внутреннего приложения используй tenant ID клиента — не `/common`, который пускает любую организацию и личные аккаунты, — и проверяй `tid` в токене. - **Связи:** Приложения живут здесь как **App Registrations** и **Service Principals**; доступ задают **App Roles** и **Conditional Access**. ### App Registration vs Service Principal — паспорт и виза > Паспорт и виза: паспорт (registration) один раз говорит, кто ты. Визу (service principal) выдаёт каждая страна, куда ты въезжаешь, — и именно виза говорит, что тебе там можно. Эту пару путают все. **App registration** — паспорт твоего приложения: его **client ID** (публичный, это не секрет), **redirect URI** (куда вернуть человека после входа — совпадать должен точь-в-точь), его credentials, права, которые оно просит, и роли, которые оно объявляет. **Service principal** — экземпляр приложения внутри конкретного tenant; в портале он называется **Enterprise application**. Права выдают service principal, людей назначают на него, и Conditional Access действует на него. У одной регистрации могут быть service principals во многих tenants — так работают SaaS-продукты. **Managed identity** — тоже service principal, просто без паспорта, которым тебе нужно управлять. Про credentials: **client secret** протухает (максимум два года, по политике часто 6–12 месяцев); сертификат лучше; **federated credential** лучше всего — протухать нечему. _Diagram: Регистрация — чертёж, делается один раз. Каждый tenant, который пользуется приложением, получает свой service principal — и права держит именно он._ #### App Registration vs Service Principal (Enterprise application) - **Что это:** Registration = описание приложения (client ID, redirect URI, права, роли). Service principal = его копия в tenant, которая получает права. - **Пример:** «Contract Assistant»: single-tenant регистрация, redirect URI `https://agent.contoso.com/auth/callback`, federated credential вместо секрета. - **Подвох:** Скорее всего, ты не сможешь сам создать регистрацию или дать admin consent — это делает Application Administrator. Пришли точный список заранее — это экономит недели. - **Связи:** Просит **Delegated или Application Permissions**; объявляет **App Roles**; **Managed Identity** — тоже service principal. ### Delegated vs Application Permissions — от имени пользователя или от своего > Личный помощник с ключом от твоего кабинета открывает только твои двери. Ночной охранник с мастер-ключом открывает все двери в здании — удобно для обхода, опасно в чужих руках. Есть два вида прав на вызов API Microsoft. **Delegated permissions** (scopes) — приложение действует _от имени вошедшего пользователя_ и видит только то, что видит он: `User.Read`, `Files.Read`. В токене они лежат в claim `scp`. **Application permissions** — приложение действует _само по себе_, без пользователя, для фоновой работы: `Sites.Read.All` читает все сайты SharePoint. Это очень сильные права, и им всегда нужен **admin consent**. **Consent** — это согласие: «да, этому приложению можно читать мой профиль». Обычные права пользователь может одобрить сам, если компания разрешает; сильные — только админ. Многие компании вообще выключают согласие пользователей — отсюда самый частый экран при первом входе: **«Need admin approval»**. _Diagram: Delegated: агент видит только файлы Анны. Application: видит все сайты — и нужен админ, чтобы это одобрить._ #### Delegated vs Application Permissions (scopes · consent · admin consent) - **Что это:** Delegated = действовать как вошедший пользователь, в пределах его прав. Application = действовать как само приложение, на всём, что выдано. - **Пример:** Агент «вопрос-ответ по SharePoint» использует delegated `Sites.Read.All`, и SharePoint сам применяет права каждого пользователя. - **Подвох:** Application permissions обходят права людей. С application `Sites.Read.All` агент, который отвечает сотрудникам, легко покажет кому-то документ, который тому видеть нельзя. - **Связи:** Сердце **As the User vs As Itself**; первый вопрос **Security Review**. ### App Roles — твои роли, которые раздаёт их IT > Цветные браслеты на фестивале: организатор решает, что открывает синий браслет, касса раздаёт браслеты, а на входе смотрят только на цвет. **App roles** — роли, которые ты объявляешь в своей app registration, скажем `Agent.User` и `Agent.Admin`. IT клиента назначает их группам. Когда человек входит, его роли приходят в claim `roles` токена, и твой бэкенд их проверяет: нет `Agent.User` → 403. Включи **«Assignment required»** — и неназначенные люди даже войти не смогут. Почему бы просто не читать группы из токена? Из-за **groups overage**: если пользователь состоит в слишком многих группах (больше 200 для JWT), группы вообще не приходят в токене — вместо них ссылка на Graph. App roles обходят эту проблему и оставляют контроль у клиента: IT двигает людей между группами, а ты не трогаешь код. _Diagram: Ты объявляешь роли, IT назначает их группам, роли приходят в токене, твой бэкенд их проверяет._ #### App Roles (roles claim · assignment required) - **Что это:** Роли, объявленные твоим приложением, назначенные группам силами IT клиента и доставленные в токене. - **Пример:** `if "Agent.User" not in claims.get("roles", []): abort(403)` — финансы получают `Agent.Admin` через свою группу. - **Подвох:** Если вместо этого полагаться на groups claim, всё ломается для людей больше чем в 200 группах — групп просто нет в токене. - **Связи:** Объявляются в **App Registration**; аналог в Okta — отфильтрованный groups claim. ### Conditional Access — правила на входе > Вышибала в клубе со списком правил: члены клуба проходят, гости показывают документ, в кроссовках не пускают никого — и так на входе каждый раз. **Conditional Access** — набор правил «если — то», которые Entra проверяет при каждом входе: _если_ кто-то из группы Finance открывает приложение X с неуправляемого устройства, _то_ требуй MFA — или блокируй. В условиях могут быть пользователь или группа, приложение, устройство, место и риск входа. **MFA** — второй фактор: пуш в Microsoft Authenticator, ключ FIDO2, passkey. Conditional Access требует лицензии **Entra ID P1** или выше; у маленьких tenants без P1 могут быть только **security defaults** (MFA для всех). Доступ на основе риска и PIM требуют P2, а Conditional Access для service principals — отдельной лицензии Workload Identities. «У нас нет такой функции» часто значит «у нас нет такой лицензии». _Diagram: При каждом входе Entra проверяет: кто, какое приложение, какое устройство, откуда, насколько рискованно — и пускает, просит MFA или блокирует._ #### Conditional Access (MFA · security defaults) - **Что это:** Правила входа в Entra ID: условия (кто, приложение, устройство, место, риск) → действие (пустить, MFA, заблокировать). - **Пример:** Агент по контрактам автоматически попадает под политику компании «MFA плюс управляемое устройство». - **Подвох:** «Только управляемые устройства» может заблокировать твои тесты, твой CI и твой собственный ноутбук. Договорись об исключениях заранее и проверь, что dev-среду не заперли. - **Связи:** Действует на **Service Principal**; версия Okta — authentication policies. ### Microsoft Graph — один API ко всему Microsoft 365 > Центральный коммутатор здания: один номер соединяет с любым отделом — почтой, календарём, архивом файлов — вместо отдельной линии для каждого. **Microsoft Graph** — один большой API ко всему в Microsoft 365: пользователи, группы, почта, календари, Teams, файлы в OneDrive и SharePoint. Адрес — `https://graph.microsoft.com/v1.0/…`. Для ИИ-агента это главная дверь к документам клиента: «найди контракт 42 в SharePoint», «назначь встречу». С delegated-токеном Graph возвращает только то, что видит вошедший пользователь, — так инструмент поиска агента бесплатно наследует права SharePoint. Старый Azure AD Graph API выключен; остался только Microsoft Graph. Официальная библиотека для входа и токенов — **MSAL** (Python, JS, .NET и другие). _Diagram: Агент вызывает один endpoint, graph.microsoft.com, и достаёт пользователей, почту, календари, Teams и файлы — в пределах своих scopes._ #### Microsoft Graph (graph.microsoft.com · MSAL) - **Что это:** Единый REST API к данным Microsoft 365. - **Пример:** Инструмент поиска агента вызывает `POST /v1.0/search/query` с access token пользователя и получает только те документы, которые этот пользователь может открыть. - **Подвох:** Что вернёт Graph, ограничено scopes в токене. Попросишь мало — вызовы падают; попросишь много — security review встаёт. - **Связи:** Вызывается с **Delegated или Application Permissions**; токен приходит из входа по **OIDC**. ### Entra Agent ID — identity, сделанная для ИИ-агентов > Пропуск сотрудника для робота: своё фото, свой список доступов, он виден в журнале посетителей, и охрана может отключить его на стойке, как любой другой. В 2026 году в Entra появился отдельный вид identity для ИИ-агентов: **Agent ID** (общедоступен с апреля 2026). Агент получает свою identity, созданную по шаблону — **agent identity blueprint**, — и IT управляет ей как сотрудником: права, Conditional Access, логи входов, отключение. Это ответ на вопрос, который команды безопасности теперь задают часто: «как нам знать, какие агенты существуют и что им можно?». Штука новая, так что стоит знать слово и спросить клиента, пользуются ли они ей. _Diagram: Агенты создаются по blueprint, у каждого своя identity, и IT контролирует их как аккаунты сотрудников._ #### Entra Agent ID (agent identity blueprint) - **Что это:** Полноценный тип identity в Entra для ИИ-агентов: создаётся по blueprint и управляется как пользователь. - **Пример:** Агент по контрактам и агент продаж получают каждый свой Agent ID с отдельными правами и логами. - **Подвох:** Новинка 2026 года — многие tenants в среднем бизнесе её ещё не внедрили. Спрашивай, а не предполагай. - **Связи:** Аналог в Okta — **Cross App Access** с Agent SSO; оба служат **Least Privilege**. > **Вопрос идентичности:** «Моё приложение логинит людей через tenant клиента по OIDC, использует стабильный ID пользователя, проверяет app roles — и действует с delegated permissions всякий раз, когда отвечает человеку?» > Entra ID — справочник и стойка компании. Зарегистрируй приложение, дай IT назначать app roles группам, предпочитай delegated permissions и пришли IT один точный список — тогда admin consent будет быстрым. ## 4. Идентичность: Okta Okta делает ту же работу, что Entra ID, но это независимая компания. Она выигрывает там, где у клиента смесь инструментов и Microsoft не в центре. Стандарты те же; отличаются слова и админка. ### Okta Workforce Identity — нейтральная стойка > Стойка, которую держит независимая охранная фирма, а не арендодатель: она работает с каждым арендатором в здании, какой бы марки ни был замок в его офисе. **Okta Workforce Identity** — продукт Okta для сотрудников: он знает каждого человека в компании и решает, кто куда может войти. Люди входят один раз и попадают в Slack, Salesforce, Jira, AWS и твоё приложение. Компании выбирают его, когда у них «зоопарк» — Google Workspace, AWS, Slack, Salesforce, маки — и Microsoft не главный вендор; в его каталоге, **Okta Integration Network (OIN)**, больше 8 000 готовых интеграций. У каждой компании есть **org** с адресом вроде `acme.okta.com` — версия tenant в Okta. Обычно есть production org и **preview org** (на `oktapreview.com`): сначала проси доступ к preview. **Universal Directory** хранит людей (с полями вроде отдела и руководителя), группы, а теперь и ИИ-агентов; данные обычно приходят из HR-системы — «HR — источник правды». Не путай Okta с **Auth0**: компания та же, но Auth0 — для _клиентов_ компании, которые входят в её продукт, а Okta Workforce — для _сотрудников_. _Diagram: Люди приходят из HR и AD; org в Okta держит каталог, политики, серверы токенов и lifecycle; приложения — и твой агент — ему доверяют._ #### Okta (Workforce Identity · org · Universal Directory) - **Что это:** Независимый облачный identity provider для сотрудников: каталог, SSO, MFA, provisioning. - **Пример:** Агент — это OIDC app integration в `acme.okta.com`, назначенная группе `AI-Agent-Users`. - **Подвох:** По умолчанию группы в токен не кладутся. Нужен groups claim с фильтром (скажем, «начинается с AI-Agent-») — «все группы» раздувают JWT и ломают заголовки и cookies. - **Связи:** Те же стандарты, что у **Entra ID** (**OIDC и SAML**); provisioning через **SCIM**; токены от **Authorization Servers**. ### SCIM — пришёл, перешёл, ушёл — автоматически > Когда имя новичка появляется в списке HR, в первый же день у него есть пропуск, стол и шкафчик; когда он уходит, пропуск перестаёт работать в тот же вечер — и никому не надо об этом помнить. **SCIM** — стандартный REST API, чтобы создавать, обновлять и выключать пользователей в приложении. IdP — Okta или Entra — это SCIM-клиент; твоё приложение — SCIM-сервер с endpoints `/Users` и `/Groups`. **Lifecycle management** покрывает три момента: **joiner** (человеку назначили приложение → `POST /scim/v2/Users`), **mover** (он сменил команду → группы обновились), **leaver** (он ушёл → `PATCH` с `active=false`: аккаунт выключен, а не удалён). Без SCIM пользователи появляются в твоей базе только при первом входе (**just-in-time**), и ушедших никто не удаляет — «мёртвые души» с историей чатов и настройками. _Diagram: HR что-то меняет, IdP вызывает твой SCIM endpoint: создать при приходе, обновить при переходе, выключить при уходе._ #### SCIM (provisioning · joiner–mover–leaver) - **Что это:** Стандартный API, через который IdP создаёт, обновляет и выключает пользователей в твоём приложении. - **Пример:** Человек уходит в пятницу; Okta шлёт `PATCH active=false`, и его аккаунт в агенте выключен в тот же день. - **Подвох:** Важно, только если приложение хранит свои записи о пользователях. Если хранит, а SCIM ты пропустил, — будут аккаунты, которые переживут своих владельцев. - **Связи:** Работает от **Okta** или **Entra ID**; в паре с короткоживущими токенами даёт быстрый отзыв доступа. ### Authorization Servers — org или custom > В здании есть один стандартный пропуск, который открывает главные двери, но лаборатория с особыми правилами печатает свои пропуска со своими печатями. Стандартный пропуск на двери лаборатории не сработает. Часть Okta, которая выпускает токены, — **authorization server**, и их два вида. **Org authorization server** встроен, issuer — `https://acme.okta.com`; он годится для обычного входа и вызовов API самой Okta, но свои scopes туда не добавишь. **Custom authorization server** (issuer вроде `https://acme.okta.com/oauth2/default`) защищает _твои_ API: твои scopes вроде `agent.read` и `agent.tickets.write`, твои claims, твои политики, machine-to-machine. Для него нужна платная подписка **API Access Management** — у клиента её может не быть. Классическая ошибка: проверять в своём API токен от org-сервера так, будто это твой access token. Если строишь API, нужен custom-сервер. Сначала выясни issuer. _Diagram: Org-сервер отвечает за вход и API самой Okta; custom-сервер выпускает токены с твоими scopes для твоего API._ #### Authorization Server (org vs custom · issuer) - **Что это:** Эмитент токенов в Okta. Org = встроенный, для SSO; custom = твои scopes и claims, для твоих API. - **Пример:** Бэкенд проверяет токены по issuer `…/oauth2/default`, audience `api://ai-agent`, ключам из `/v1/keys`. - **Подвох:** Перепутаешь — и проверка `aud` падает или scope не добавить. Для вызовов API Okta используй OAuth service app, а не статический SSWS-токен, который ломается, когда его админ уходит. - **Связи:** Выпускает токены для **OIDC**; агенты могут ходить в другие приложения через **Cross App Access**. ### Cross App Access и Agent SSO — агенты, которые не копят токены > Вместо того чтобы каждый помощник носил связку скопированных ключей от всех офисов, стойка выдаёт короткий гостевой пропуск на каждый визит — и записывает каждый визит в журнал. Новая проблема: агенту в приложении A нужны данные из приложения B от имени пользователя. По-старому каждый пользователь в каждом приложении жмёт «подключи свою Jira», а агент хранит эти токены — и IT не видит ни одной такой связи. **Cross App Access (XAA)** — открытый протокол на основе черновика IETF **ID-JAG** (Identity Assertion JWT Authorization Grant): агент просит Okta, Okta проверяет политику и выпускает короткий токен для приложения B, и Okta видит и логирует каждую такую связь. XAA принят как расширение Enterprise-Managed Authorization для MCP; среди партнёров — Slack, Atlassian, Zoom, Asana, Datadog, Cloudflare и Claude. **Agent SSO** (общедоступен с 24 августа 2026, входит в стандартный Okta SSO без доплаты) регистрирует агента с поддержкой XAA как отдельную identity в Universal Directory, рядом с людьми, с короткоживущими токенами вместо статических API-ключей. Сверх этого **Okta for AI Agents** — отдельная платная подписка для обнаружения агентов и управления ими. Для клиентской стороны **Auth0 for AI Agents** (GA с ноября 2025) даёт Token Vault, асинхронное одобрение человеком и тонкий доступ для RAG. _Diagram: По-старому: пользователи подключают каждое приложение, агент хранит токены. XAA: агент просит Okta, получает короткий токен от имени пользователя, Okta это логирует._ #### Cross App Access (XAA · ID-JAG · Agent SSO) - **Что это:** Способ через Okta получить агенту в одном приложении короткий, залогированный токен для другого приложения — от имени пользователя. - **Пример:** Агент продаж создаёт тикеты в Jira через XAA — хранить нечего, и IT видит эту связь в Okta. - **Подвох:** Работает, только если и приложение агента, и целевое приложение это поддерживают. У многих клиентов среднего размера это не включено — держи план Б: обычный OAuth с минимальными scopes. - **Связи:** Аналог у Microsoft — **Entra Agent ID**; это **As the User**, только централизованно. > **Вопрос Okta:** «Я знаю issuer и что это за authorization server, groups claim отфильтрован, нужен ли мне SCIM — и может ли мой агент использовать Cross App Access вместо хранения токенов?» > Okta — нейтральная стойка: тот же OIDC, который ты уже знаешь, плюс SCIM для прихода и ухода людей, два вида серверов токенов, а теперь и Cross App Access, чтобы агенты перестали копить токены. ## 5. Данные: Snowflake Где компания держит свои цифры? Сначала три формы хранения данных. Потом Snowflake — SQL-хранилище, где storage и compute разделены, а платишь посекундно. ### Warehouse, Lake, Lakehouse — три способа хранить данные компании > Библиотека, гараж и современный архив. В библиотеке строгие полки и каталог, но принимают только готовые книги. Гараж берёт что угодно, но найти там что-то — кошмар. Архив хранит всё в дешёвых коробках — с каталогом сверху. **Data warehouse** — база данных для анализа, а не для работы приложения: большие строгие таблицы и тяжёлые запросы вроде «продажи по регионам за три года», на SQL. Быстро и надёжно, но дороже, и внутрь попадает только чистая часть данных. **Data lake** — просто папки файлов в облачном хранилище — S3, ADLS, GCS: логи, выгрузки CRM, CSV, JSON, картинки. Дёшево и огромно, но без порядка: нет транзакций, файлы ломаются при одновременной записи, никто не знает, какая версия правильная. Годами компании держали и то и другое и копировали данные туда-сюда — две копии, два набора прав, отчёты, которые не сходятся с моделями. **Lakehouse** (lake + warehouse) хранит данные один раз в дешёвом хранилище, в табличном формате, который добавляет транзакции, схему и историю, — и SQL, Spark и ML работают с одними и теми же таблицами. _Diagram: Warehouse: строго и чисто. Lake: дёшево и грязно. Lakehouse: файлы один раз, а сверху правила таблиц. Snowflake начинался как первое; Databricks и Fabric — третье._ #### Warehouse · Lake · Lakehouse (data warehouse · data lake) - **Что это:** Три формы хранения: строгие SQL-таблицы, сырые файлы любого вида или файлы с табличным форматом сверху. - **Пример:** Финансовые отчёты живут в warehouse; логи приложения падают в lake; lakehouse обслуживает и то и другое из одной копии. - **Подвох:** Сегодня Snowflake, Databricks и Fabric умеют почти всё и жёстко конкурируют — ярлыки говорят только о том, откуда каждый начинал. - **Связи:** **Snowflake** (корни в warehouse), **Databricks** и **Microsoft Fabric** (lakehouse на **Delta Lake**). ### Snowflake — хранилище в одном месте, вычисления по требованию > Огромный склад товаров и отдельные бригады грузчиков, которых нанимаешь поминутно. Нужно быстрее — зови бригаду побольше. Никто не работает — никому не платят. **Snowflake** — облачная база данных для аналитики. Компания вливает туда свои данные — продажи, CRM, склад, финансы, — и каждый отдел спрашивает их обычным SQL. Серверы, диски, индексы, бэкапы — забота Snowflake. Главная идея: **storage отделён от compute**. Одна копия данных, а у каждой команды свой вычислительный кластер, который не тормозит остальных. Слоёв три: **cloud services** (мозг — вход и роли, метаданные, оптимизатор запросов, кэш результатов), **compute** (virtual warehouses, оплата в кредитах) и **storage** (колоночные данные в micro-partitions, оплата за TB в месяц). Snowflake работает поверх AWS, Azure или GCP — облако и регион выбирает клиент. У твоего **account** идентификатор вроде `myorg-myaccount`; веб-консоль — **Snowsight**. Бонусы: **Time Travel** читает таблицу «как она была вчера» (по умолчанию 1 день, до 90 на Enterprise), а **zero-copy clone** за секунды делает dev-базу из prod. _Diagram: Три слоя: мозг сверху, отдельные кластеры на каждую команду посередине, одна общая копия данных внизу._ #### Snowflake (облачное хранилище данных) - **Что это:** SQL-платформа для аналитики, где storage и compute разделены, а за compute платишь по использованию. - **Пример:** Запросы агента идут на его собственном маленьком кластере, поэтому дашборды BI-команды не тормозят. - **Подвох:** Имена без кавычек становятся ЗАГЛАВНЫМИ: `"orders"` в кавычках и `orders` — разные таблицы. И бери новый идентификатор `org-account`, а не старый формат locator. - **Связи:** Compute — это **Virtual Warehouse**; доступ — **Roles and RBAC**; ИИ — **Cortex**. ### Virtual Warehouse — вычислительный кластер, а не склад > Такси со счётчиком: приезжает по вызову, счётчик крутится, только пока едешь, и уезжает, когда ты вышел. Машина побольше стоит дороже за минуту. Это слово путает всех: **virtual warehouse** ничего не хранит. Это вычислительный кластер, который выполняет твои запросы. У него есть размер — X-Small, Small, Medium, Large и так до 6X-Large, — и каждый шаг вверх даёт вдвое больше мощности за вдвое большую цену. Цена — в **credits**, внутренней валюте Snowflake: X-Small сжигает 1 кредит в час, Small — 2, Medium — 4, Large — 8, X-Large — 16 (Gen1). Цена кредита в долларах зависит от редакции, облака, региона и контракта — одной цифры нет. Оплата посекундная, с минимумом 60 секунд на каждый запуск. **Auto-suspend** усыпляет кластер в простое (ставь 60 секунд); **auto-resume** будит его на следующий запрос; **multi-cluster** (Enterprise) добавляет копии под нагрузкой. **Resource monitor** ограничивает кредиты: уведомить на 80%, остановить на 100%. Без активного warehouse SQL не запустится: «No active warehouse selected». _Diagram: Каждый размер удваивает кредиты в час. Просыпается на запрос, оплата посекундно, засыпает после 60 секунд тишины — и ограничивается resource monitor._ #### Virtual Warehouse (credits · auto-suspend · resource monitor) - **Что это:** Вычислительный кластер Snowflake с размером и посекундной ценой в кредитах; данных не хранит. - **Пример:** `AI_AGENT_WH`: X-Small, `AUTO_SUSPEND = 60`, resource monitor на 50 кредитов и `QUERY_TAG`, чтобы видеть расходы агента. - **Подвох:** Нет auto-suspend или слишком большой размер = тысячи долларов в месяц. Агент, который шлёт 20 запросов на каждый вопрос, держит warehouse бодрствующим весь день. - **Связи:** Слой compute в **Snowflake**; используется через **Role**. ### Roles and RBAC — права ролям, роли людям > Ключи на доске с крючками, подписанными по должности, а не по имени: «кассир», «ночной менеджер». Новичок получает крючок своей должности; россыпью ключи не раздают никому. В Snowflake права никогда не дают пользователю напрямую: их дают **ролям**, а роли — пользователям. Это **RBAC (role-based access control)**. Встроенные роли: **ACCOUNTADMIN** — бог аккаунта (тебе его никто не даст, и он тебе не нужен); **SECURITYADMIN** и **USERADMIN** управляют пользователями и правами; **SYSADMIN** создаёт базы и warehouses; **PUBLIC** есть у всех. Роли можно вкладывать друг в друга. Для агента ты создаёшь его собственную роль, скажем `AI_AGENT_RO`, с `USAGE` на его warehouse, базу и схему и `SELECT` на нужные views — плюс `SNOWFLAKE.CORTEX_USER`, если он вызывает Cortex. Сверху **row access policies** решают, какие строки кто видит, а **masking policies** прячут значения вроде email или SSN. Объекты называются `DATABASE.SCHEMA.OBJECT`, например `SALES.MART.ORDERS_V`. _Diagram: Service user получает одну роль только на чтение; права держит роль. Встроенные роли сверху — от ACCOUNTADMIN до PUBLIC._ #### Roles and RBAC (AI_AGENT_RO · row access · masking) - **Что это:** Модель доступа Snowflake: права выдают ролям, роли — пользователям и другим ролям. - **Пример:** `GRANT SELECT ON ALL VIEWS IN SCHEMA SALES.MART TO ROLE AI_AGENT_RO` — только views, никогда не сырые таблицы с PII. - **Подвох:** «Object does not exist» или «no warehouse» — почти никогда не опечатка, а пропущенный `USAGE`. Snowflake говорит «не существует», когда роль объект не видит. - **Связи:** Выдаётся **Service User**; хрестоматийный пример **Least Privilege**. ### Service User — аккаунт Snowflake для программы, пароли запрещены > Робот-курьер попадает в здание по запрограммированному чипу, а не набирая код на двери — и здание просто больше не пускает роботов по кодам. **Service user** (`TYPE = SERVICE`) — пользователь Snowflake для программы, а не для человека. Пароли ему запрещены: он входит через **key pair** (JWT), OAuth, programmatic access token (PAT) или workload identity federation. И теперь это строго: с августа по октябрь 2026 Snowflake полностью заблокировал вход по паролю для service users, а пользователей `LEGACY_SERVICE` переводят в `SERVICE`. Так что старые примеры из интернета с `password=` не работают — не копируй их. С **key-pair auth** ты генерируешь пару ключей RSA, отдаёшь админу публичный ключ (`RSA_PUBLIC_KEY`), а приватный держишь в Key Vault или Secret Manager. Коннектор подписывает им JWT (`authenticator="SNOWFLAKE_JWT"`). Второй слот, `RSA_PUBLIC_KEY_2`, позволяет менять ключи без простоя; **network policy** ограничивает, с каких IP можно подключаться. _Diagram: Никакого пароля. Приватный ключ из vault подписывает JWT; Snowflake сверяет его с публичным ключом, network policy и ролью._ #### Service User (TYPE = SERVICE · key-pair auth) - **Что это:** Пользователь Snowflake для софта: входит только по ключу, OAuth, PAT или workload identity. - **Пример:** `SVC_AI_AGENT` с `DEFAULT_ROLE = AI_AGENT_RO`, `DEFAULT_WAREHOUSE = AI_AGENT_WH` и только публичным RSA-ключом. - **Подвох:** Если все пользователи агента идут через один service user, все видят одни и те же данные. Реши заранее: row policies или вход от имени пользователя через OAuth из Okta или Entra. - **Связи:** Держит **Role**; ключи живут в **Key Vault**; выбор дизайна — **As the User vs As Itself**. ### Cortex — ИИ рядом с данными > Вместо того чтобы таскать коробки из архива к внешнему эксперту, ты зовёшь эксперта в архив — бумаги не покидают здание. **Cortex AI** — ИИ-слой Snowflake: модели Anthropic, OpenAI, Meta, Mistral и других работают внутри периметра безопасности Snowflake. **Cortex AI Functions** (бывший «AISQL») встраивают LLM прямо в SQL: `AI_COMPLETE`, `AI_CLASSIFY`, `AI_EXTRACT`, `AI_SENTIMENT` — классифицируй 100 000 отзывов одним запросом. **Cortex Analyst** превращает вопрос на английском в SQL с помощью **semantic view**, где описаны бизнес-термины («revenue = SUM(amount) where status = 'paid'»). **Cortex Search** — готовый RAG-поиск по тексту: векторы + ключевые слова + reranking. **Cortex Agents** (GA с ноября 2025) планируют шаги и вызывают Analyst, Search, твои процедуры и MCP-коннекторы; 28 августа 2026 Snowflake рекомендовал перейти с отдельного Analyst API на Cortex Agents. **Snowflake Intelligence** — готовый чат-интерфейс сверху. **Snowflake-managed MCP server** (`CREATE MCP SERVER`, до 50 tools) открывает всё это внешним агентам вроде Claude или Cursor — со Snowflake OAuth или внешним OAuth из Okta или Entra. _Diagram: Functions, Analyst, Search, Agents, Intelligence — всё внутри Snowflake. Managed MCP server открывает это внешним агентам._ #### Cortex (AI Functions · Analyst · Search · Agents) - **Что это:** Встроенный ИИ Snowflake: LLM-функции в SQL, text-to-SQL, RAG-поиск и агенты — рядом с данными. - **Пример:** Путь B для агента «почему упала маржа в Техасе?»: semantic view + Cortex Agent, который вызывается из твоего приложения, — данные не покидают Snowflake. - **Подвох:** Вызовы Cortex стоят кредитов за токены — отдельная строка в счёте; попробуй на 1 000 строк, прежде чем на миллионе. Не каждая модель есть в каждом регионе. И text-to-SQL без семантического слоя врёт: никто не знает, что значит `AMT_NET_2`. - **Связи:** Агенты достают его через **MCP**; родственник в Databricks — **Agent Bricks**, в Fabric — **Data Agent**. > **Вопрос Snowflake:** «У моего агента свой service user с ключом, роль только на чтение views, маленький warehouse, который засыпает через минуту, resource monitor — и семантический слой до любого text-to-SQL?» > Snowflake отделяет storage от compute и берёт за compute посекундно. Дай агенту свой service user с ключом, роль только на чтение, X-Small warehouse и лимит кредитов — и пришли админу готовый SQL-скрипт. ## 6. Данные: Databricks Databricks начинался с файлов и Spark, а не с SQL-таблиц. Это lakehouse: одна копия данных в собственном облачном хранилище клиента, один охранник на весь доступ и ИИ-платформа на тех же таблицах. ### Databricks — склад, цех и лаборатория на одной площадке > Заводская площадка: дешёвый склад для сырья, цех, где его чистят и обрабатывают, витрина с готовой продукцией, лаборатория для экспериментов — и один охранник на воротах, который проверяет пропуск у каждого. **Databricks** — платформа данных от создателей Apache Spark. Компания держит все данные в дешёвом облачном файловом хранилище, обрабатывает их в **Spark** (распределённый движок для данных, которые не влезают в одну машину), отвечает на вопросы на SQL и строит ML-модели и ИИ-агентов на тех же данных — всё под одной системой прав, **Unity Catalog**. Работает поверх облака клиента: AWS, Azure (как Azure Databricks) или GCP. Люди работают в **notebooks** (как Jupyter, в браузере, всегда подключены к compute) и **jobs**; аналитики — в SQL и **Genie**; ИИ-работа живёт в **Agent Bricks**. Compute — **clusters** для Spark, **SQL warehouses** для SQL, **serverless** — оплачивается в **DBU** (Databricks Units). Ещё есть **Lakebase** — управляемый Postgres для приложений, которым нужны быстрые чтения и записи. _Diagram: Люди и агенты сверху, compute посередине, Unity Catalog охраняет всё, а данные лежат в собственном хранилище клиента._ #### Databricks (lakehouse-платформа · Azure Databricks) - **Что это:** Lakehouse-платформа: файлы в облачном хранилище клиента, сверху Spark и SQL, ИИ на тех же таблицах. - **Пример:** Дистрибьютор держит продажи, склад и CRM в gold-таблицах `main.sales_gold.*` на Azure Databricks. - **Подвох:** Три облака — три немного разных продукта: на Azure identity идёт через Entra; доступность функций (Lakebase, serverless) зависит от облака и региона. - **Связи:** Таблицы — **Delta Lake**; права — **Unity Catalog**; агент ходит в **SQL Warehouse**. ### Delta Lake — папка файлов, которая ведёт себя как таблица > Журнал склада: коробки на полках — просто коробки, но журнал у двери говорит, какие из них составляют сегодняшний запас. Поменяй запись в журнале одним росчерком — и запас меняется целиком. **Delta Lake** — открытый табличный формат. Внизу — обычные файлы **Parquet** (колоночный формат файлов) плюс папка `_delta_log` — журнал, где записано, какие файлы составляют таблицу прямо сейчас. Благодаря журналу простая папка файлов получает силы настоящей базы данных: **ACID-транзакции** (запись ложится целиком или никак; читатели не видят половину), **схему** (строку в числовую колонку не запишешь), **time travel** (прочитать таблицу «как она была вчера») и `MERGE`, `UPDATE`, `DELETE`. Если знаешь Postgres: это как WAL, только журнал лежит рядом с файлами в S3, а не внутри сервера базы. Fabric использует тот же формат. _Diagram: Обычные файлы Parquet плюс журнал транзакций. Журнал говорит, какие файлы и есть таблица, — и это превращает папку в таблицу базы данных._ #### Delta Lake (Parquet + журнал транзакций) - **Что это:** Открытый табличный формат: файлы Parquet плюс журнал `_delta_log`, который добавляет транзакции и историю. - **Пример:** Ночной job делает MERGE новых заказов в `orders`; аналитики никогда не видят недописанную таблицу. - **Подвох:** Это формат, а не сервер: чтобы его прочитать, всё равно нужен compute — и платишь ты именно за него (DBU). - **Связи:** Основа **Lakehouse**; общий для **Databricks** и **Microsoft Fabric**. ### Unity Catalog — один охранник с одним журналом > Охранник на единственных воротах с журналом: неважно, пришёл ты пешком, приехал на машине или ты робот-доставщик, — он проверит пропуск и запишет, что ты взял. **Unity Catalog** — единый слой прав и каталога для всех данных и ИИ в Databricks; он включён по умолчанию в каждом workspace, созданном после 8 ноября 2023. Имена трёхуровневые — `catalog.schema.table`, например `main.sales_gold.orders`, — и та же схема покрывает views, **volumes** (папки файлов вроде PDF), функции и модели. Права выдаются через `GRANT` людям, группам и **service principals**. Можно прятать строки (**row filters**) и колонки (**column masks**). **Lineage** рисует, откуда данные пришли и куда ушли, а каждое действие пишется в аудит в **system tables**. Откуда бы ни пришёл запрос — из notebook, SQL или от твоего агента, — он проходит одну и ту же проверку. Чтобы прочитать одну таблицу, principal нужны три права сразу: `USE CATALOG` + `USE SCHEMA` + `SELECT`. _Diagram: Notebooks, SQL и агенты проходят одну и ту же проверку. Unity Catalog даёт доступ к таблицам, volumes и моделям — и логирует его._ #### Unity Catalog (catalog.schema.table · GRANT · lineage) - **Что это:** Центральные права, каталог, lineage и аудит Databricks для данных и ИИ-объектов. - **Пример:** Service principal агента получает `SELECT` на схему `main.sales_gold` и `READ VOLUME` на `main.docs.contracts` — и больше ничего. - **Подвох:** Если не хватает одного из трёх прав, это выглядит как «table not found». В старых workspaces таблицы могут ещё лежать в legacy `hive_metastore` со старыми правилами — проверь, что мигрировали. - **Связи:** Охраняет таблицы **Delta Lake**; проверяет каждый запрос к **SQL Warehouse**. ### Medallion — bronze, silver, gold > Руда из шахты, металл из печи, готовое кольцо на витрине. Ювелир продаёт только кольцо — но руду хранит на случай, если печь придётся запустить заново. **Medallion** — не продукт, а общепринятый способ раскладывать данные по слоям качества. **Bronze** — сырые данные ровно в том виде, как пришли из источника: дубли, мусор, смешанные форматы. Их хранят, чтобы можно было всё пересобрать. **Silver** — очищенные: правильные типы, без дублей, таблицы связаны ключами. **Gold** — агрегаты и бизнес-таблицы: выручка по дням, активные клиенты. Отчёты и агенты читают gold. Пайплайны, которые двигают данные между слоями, — **Lakeflow Jobs** (бывшие Workflows) и **Lakeflow Declarative Pipelines** (бывшие Delta Live Tables, DLT). Правило для ИИ-проекта: агент читает gold, иногда silver и никогда bronze. _Diagram: Источники → bronze (как пришло) → silver (очищено) → gold (готово для бизнеса). Агент читает gold._ #### Medallion (bronze · silver · gold) - **Что это:** Слои данных по качеству: сырые (bronze), очищенные (silver), готовые для бизнеса (gold). - **Пример:** Агент читает `main.sales_gold.orders`; сырые дампы CRM остаются в bronze, вне его досягаемости. - **Подвох:** Gold обновляется раз в ночь или раз в час. Агент должен говорить, на какую дату его цифры. - **Связи:** Строится на **Delta Lake**; давай агенту только gold через **Unity Catalog**. ### SQL Warehouse и OAuth M2M — как агент задаёт вопрос > Окошко самообслуживания с автоматом талонов: один раз показываешь документ, получаешь талон на час, и служащий сверяется со списком, прежде чем что-то выдать. **SQL warehouse** — compute Databricks только для SQL; BI-инструменты и твоё приложение подключаются к нему по **server hostname** и **HTTP path** (оба есть в Connection details у warehouse). Типов три: **serverless** (рекомендуется, обычно стартует за 2–6 секунд), **pro** и **classic** (около 4 минут). Агент входит как **service principal** через **OAuth M2M** (machine-to-machine): меняет `client_id` и `client_secret` на короткоживущий токен и шлёт SQL. Unity Catalog проверяет права и фильтры; движок читает только нужные файлы и колонки; строки возвращаются; и каждый запрос попадает в таблицы аудита (`system.access.audit`). Передавай значения как параметры запроса (`:since`), а не склеивай строки — даже когда SQL пишет LLM, — и всегда добавляй `LIMIT`. _Diagram: Агент меняет client ID и секрет на короткий токен, шлёт SQL в warehouse, Unity Catalog проверяет, строки возвращаются — и всё попадает в аудит._ #### SQL Warehouse (serverless · OAuth M2M · DBU) - **Что это:** Compute Databricks только для SQL; приложения и агент ходят в него с токеном service principal. - **Пример:** Маленький serverless warehouse только для агента (право `CAN USE`) — его расходы видны, и ему можно поставить свой лимит. - **Подвох:** Classic warehouse стартует ~4 минуты, и первый запрос агента падает по таймауту — а API по умолчанию создаёт именно classic. Personal access tokens (PAT) часто запрещены; используй OAuth M2M. - **Связи:** Проверяется **Unity Catalog**; identity — **Service Principal**; выбор дизайна — **As the User vs As Itself** (U2M / on-behalf-of). ### Agent Bricks — ИИ-зонтик Databricks > Торговый центр, где все ИИ-магазины переехали под одну крышу и одну вывеску: магазины те же, над входом новое имя. Больше всего имена менялись именно в этом углу. **Mosaic AI** — старое имя зонтика (после того как Databricks купил MosaicML); с марта 2026 зонтик для всего ИИ — **Agent Bricks**, платформа, чтобы строить и запускать агентов. Она поддерживает frontier- и открытые модели (OpenAI, Anthropic, Gemini и другие), фреймворки вроде LangGraph, CrewAI и Claude Agent SDK, трейсинг через **MLflow**, управляемую память агентов (на Lakebase), песочницу для запуска кода и разбор документов (`ai_parse_document`, `ai_extract`, `ai_classify`). Вокруг: **Model Serving** (модель как REST endpoint, для LLM — совместимый с OpenAI), **Unity AI Gateway** (одни ворота для вызовов моделей и MCP: права, бюджеты, лимиты, защита PII, трейсинг), **Databricks Apps** (хостинг агента внутри Databricks), **Genie** (спрашивай данные на английском, есть Genie MCP server). Vector search 1 июня 2026 переименовали в **AI Search**, и теперь он добавляет full-text, гибридный поиск и reranking; индекс может держаться в синхроне с Delta-таблицей. _Diagram: Модели, фреймворки, трейсинг, serving, AI gateway, поиск, Genie и хостинг приложений — всё под Agent Bricks. Плюс старые имена, которые ты ещё услышишь._ #### Agent Bricks (бывший Mosaic AI · AI Search · Genie) - **Что это:** Платформа Databricks, чтобы строить, запускать агентов и управлять ими рядом с данными. - **Пример:** Контракты разобраны через `ai_parse_document` → таблица чанков → индекс AI Search, который держится с ней в синхроне; вызовы модели агента идут через Unity AI Gateway. - **Подвох:** Переименования повсюду: DLT → Declarative Pipelines, Workflows → Lakeflow Jobs, Vector Search → AI Search, Delta Sharing → OpenSharing (июнь 2026). В документах клиента старые имена — знай оба. - **Связи:** Аналог в Snowflake — **Cortex**; в Fabric — **Data Agent**; в Azure — **Microsoft Foundry**. > **Вопрос Databricks:** «Мой агент читает только gold-таблицы, через маленький serverless SQL warehouse, как service principal с OAuth M2M и правами только на чтение в Unity Catalog — и каждый его запрос лежит в таблицах аудита?» > Databricks — это lakehouse: Delta-файлы в хранилище клиента, Unity Catalog как единственный охранник, gold-таблицы для агента и маленький serverless warehouse с OAuth — а не личные токены. ## 7. Данные: Microsoft Fabric Fabric — ответ Microsoft на Snowflake и Databricks: один продукт с хранилищем, загрузкой данных, обработкой, Power BI и ИИ. Его выбирают компании, которые уже живут в Microsoft. Новые идеи здесь — одно хранилище на всю компанию и одна общая capacity, которую тратят все. ### Microsoft Fabric и OneLake — «Office для данных» > Пять кладовых в пяти зданиях, у каждой свой ключ, — а вместо них одно большое здание с одним пропуском и одним счётом за электричество. **Microsoft Fabric** — SaaS-платформа данных «всё в одном»: одно общее хранилище (**OneLake**), загрузка данных (**Data Factory**), обработка (Spark, SQL), отчёты (**Power BI**) и ИИ (Copilot, data agents) — в одном портале в браузере, вход через Entra ID, оплата как одна **capacity**. До Fabric компания на Microsoft склеивала Azure Data Factory, ADLS, Azure Synapse и Power BI — у каждого свой счёт, свои права и своя сеть, а данные копировались по три-четыре раза. **OneLake** — одно логическое хранилище на весь tenant, создаётся автоматически; Microsoft называет его «OneDrive для данных». Внутри папки по **workspace** и **item**, таблицы в формате Delta (тот же открытый формат, что у Databricks); снаружи выглядит как ADLS Gen2. Роли в workspace — **Admin**, **Member**, **Contributor**, **Viewer**, — а ещё можно расшарить отдельный item. В Power BI **semantic model** (бывший «dataset») — бизнес-слой из таблиц, связей и мер DAX; часто именно там компания уже договорилась, что значит «выручка». _Diagram: Один Entra tenant, одна оплаченная capacity, workspaces, полные items, — а под всем этим OneLake. Внешние данные заходят через shortcut или mirroring._ #### Microsoft Fabric (OneLake · workspace · item) - **Что это:** Платформа данных Microsoft «всё в одном» с одним хранилищем (OneLake) и одним счётом (capacity). - **Пример:** Сеть клиник зеркалит свою медкарту (EHR) и биллинг из Azure SQL в Fabric, отчёты — в Power BI на F64. - **Подвох:** Проще, чем Databricks, но меньше контроля. И имена плывут: dataset → semantic model, «license mode» → «workspace type», P SKU → F SKU. - **Связи:** Оплачивается через **Capacity**; читается через **SQL Analytics Endpoint**; наполняется через **Shortcuts and Mirroring**. ### Capacity и F SKUs — один общий счёт за электричество > Договор на электричество для всего офиса: если твой новый обогреватель работает на полную, свет мигает и на этаже финдиректора. **Capacity** — пул вычислений, который покупает компания. Каждый workspace привязан к одной capacity, и всё, что он делает, — SQL, Spark, обновления отчётов, Copilot — тратит её **CU (capacity units)**. Размеры — **F SKUs**: F2, F4, F8 … F64 … F2048; число — это количество CU, а F64 соответствует старому Power BI Premium P1. Покупается в Azure, оплата посекундная (минимум минута) или резерв на год со скидкой; цены зависят от региона, так что смотри калькулятор Azure для региона клиента. Capacity можно поставить на паузу — тогда в ней ничего не работает. **F64 — это порог**: начиная с F64 люди с бесплатной лицензией могут смотреть отчёты Power BI; ниже каждому зрителю нужна Pro или PPU. Fabric разрешает тяжёлой задаче ненадолго взять больше купленного (**bursting**) и размазывает стоимость во времени (**smoothing**: интерактивную работу минимум на 5 минут, фоновую — на 24 часа). Переборщишь — начнётся **throttling**: после 10 минут «долга» интерактивные запросы ждут 20 секунд, после 60 минут их отклоняют, после 24 часов отклоняют всё. _Diagram: Все тратят из одной capacity. Короткие всплески выше лимита сглаживаются; слишком большой долг — это задержки, а потом отказы._ #### Capacity (F SKU · CU · throttling) - **Что это:** Общий, заранее купленный пул вычислений, который тратят все привязанные к нему workspaces Fabric. - **Пример:** Одна F64 обслуживает всю компанию; запросы агента держат маленькими и следят за ними в приложении Capacity Metrics. - **Подвох:** Throttling — это не «чуть медленнее», а ошибки `CapacityLimitExceeded` у всех. А если клиент ради экономии ставит capacity на паузу на ночь, твой агент ночью не работает. - **Связи:** Счёт **Microsoft Fabric**; поштучный **Virtual Warehouse** в Snowflake — противоположная модель. ### SQL Analytics Endpoint — снаружи Fabric выглядит как SQL Server > Музейная витрина: можно сколько угодно разглядывать каждый предмет со всех сторон, но впереди стекло — ничего не сдвинешь и не добавишь. В Fabric два дома для таблиц. **Lakehouse** — для дата-инженеров: Delta-таблицы (папка `Tables`) плюс любые файлы (папка `Files`), пишутся через Spark, notebooks и pipelines. **Warehouse** — для людей SQL: только таблицы, с полным **T-SQL** (диалект SQL от Microsoft) — `INSERT`, `UPDATE`, `MERGE`. Оба — Delta в OneLake, и их можно соединять в одном запросе. Каждый lakehouse (и mirrored database) автоматически получает **SQL analytics endpoint**: T-SQL только на чтение поверх его Delta-таблиц. Можно делать `SELECT`, создавать views и функции, настраивать row-level security — но не менять данные. Снаружи это выглядит как SQL Server: агент подключается через ODBC Driver 18 на порт 1433 (протокол TDS) к адресу вроде `xxxx.datawarehouse.fabric.microsoft.com` с токеном Entra для scope `https://database.windows.net/.default`. «Только чтение» — это хорошо для агента. _Diagram: Lakehouse против warehouse с одного взгляда. Агент читает lakehouse через его SQL endpoint только на чтение — как любой SQL Server._ #### SQL Analytics Endpoint (lakehouse vs warehouse · T-SQL) - **Что это:** Автоматический endpoint в стиле SQL Server, только на чтение, поверх lakehouse или mirrored database в Fabric. - **Пример:** `pyodbc` + токен Entra → `SELECT TOP (100) clinic, COUNT(*) … FROM dbo.appointments` с параметрами. - **Подвох:** Видны только таблицы в `/Tables`, а новые — после синхронизации метаданных (иногда с задержкой). Логи агента или кэш туда не запишешь — бери warehouse, SQL database в Fabric или свою базу. - **Связи:** Тратит **Capacity**; для доступа **Service Principal** нужна роль в workspace или право на item. ### Shortcuts и Mirroring — данные без своего ETL > Ярлык на рабочем столе открывает файл, который лежит где-то ещё. Mirroring — копия этого файла, которая сама обновляется каждый раз, когда меняется оригинал. Способ Fabric обойтись без пайплайнов копирования. **Shortcut** — как symlink: папка в lakehouse, которая на самом деле указывает на S3, ADLS, Google Cloud Storage, Dataverse, SharePoint/OneDrive или другой item в OneLake. Данные не копируются; удалишь shortcut — источник не пострадает. Для внутренних shortcuts доступ проверяется по identity того, кто читает. **Mirroring** — непрерывная копия: Fabric реплицирует базу в OneLake как Delta, почти в реальном времени. Источники — Azure SQL, SQL Server, Azure Database for PostgreSQL, Cosmos DB, Snowflake, Google BigQuery, Oracle и SAP. Для Azure Databricks есть metadata mirroring: копируется только каталог, а данные читаются через shortcuts. Вычисления для репликации бесплатны, а хранение реплик бесплатно до 1 TB на каждую CU capacity. _Diagram: Shortcut указывает на данные там, где они уже лежат. Mirroring держит в OneLake Delta-копию почти в реальном времени._ #### Shortcuts and Mirroring (symlink · живая копия) - **Что это:** Два способа завести внешние данные в OneLake: указать на них (shortcut) или держать живую копию (mirroring). - **Пример:** Таблицы биллинга из Azure SQL зеркалятся в Fabric; агент читает их через SQL endpoint mirrored database. - **Подвох:** Capacity на паузе останавливает и mirroring. В именах shortcuts нельзя пробелы и нелатинские символы. - **Связи:** Кладёт данные в OneLake **Microsoft Fabric**; mirrored databases получают **SQL Analytics Endpoint**. ### Fabric Data Agent — готовый «чат с данными» > Библиотекарь-справочник, который знает каталог наизусть и сам приносит ответы, — но только с тех полок, которые открывает твой читательский билет, и никогда не даёт писать в книгах. **Fabric data agent** — настраиваемый «чат с данными». Ты выбираешь до пяти источников — lakehouse, warehouse, semantic model, KQL database, mirrored database, ontology, — пишешь инструкции и примеры пар «вопрос → запрос», и агент превращает вопрос в SQL, DAX или KQL и выполняет его. Он общедоступен. Он работает **только на чтение** и **от имени пользователя**: видит только то, что можно этому человеку. Вызывать его можно из Microsoft 365 Copilot, Copilot Studio, Teams, Microsoft Foundry или как MCP-сервер. **Fabric IQ** — более новый слой «бизнес-смысла» (ontology, semantic models, data agents) для внешних агентов; в Foundry Agent Service старый инструмент «Fabric data agent» уберут 6 ноября 2026 в пользу Fabric IQ. **Copilot in Fabric**, встроенный помощник, теперь работает на любой платной capacity начиная с F2 (требование F64 отменили в апреле 2025), — но не на пробной. _Diagram: Вызывается из Teams, Copilot, Foundry или по MCP; превращает вопрос в SQL, DAX или KQL поверх до пяти источников — только чтение, от имени пользователя._ #### Fabric Data Agent (Fabric IQ · Copilot) - **Что это:** Встроенный в Fabric агент «вопрос → запрос» поверх выбранных источников, только на чтение и от имени пользователя. - **Пример:** Путь A для агента «почему в Остине растут неявки?»: data agent поверх semantic model, опубликованный в Teams, — права пользователей применяются сами. - **Подвох:** Только английский, LLM не выбрать, ответы ограничены 25 строками × 25 колонками, без PDF, а источник и агент должны быть в одном регионе capacity. Нужно больше контроля? Строй своего агента на SQL endpoint (путь B). - **Связи:** Родственник **Cortex** и **Agent Bricks** в Fabric; путь B использует **SQL Analytics Endpoint**. > **Вопрос Fabric:** «Админ Fabric разрешил service principals, у моего principal минимальная роль на одном item, запросы агента достаточно малы для общей capacity — и не справился бы с задачей data agent на их semantic model?» > Fabric — платформа данных Microsoft в одной коробке: OneLake для хранения, одна общая capacity для вычислений, SQL endpoint только на чтение для твоего агента — и встроенный data agent, когда хватает простого пути. ## 8. Собираем всё вместе Теперь настоящая работа: ИИ-агент внутри компании клиента. Каждая система выше задаёт одни и те же несколько вопросов: кто такой агент, что ему можно читать, от чьего имени он действует и подпишет ли это команда безопасности. Ответь рано — и проект движется; ответь поздно — и он ждёт. ### Чертёж: один агент, три слоя > Въезд в офисное здание новым арендатором: пропуска от стойки, помещение от арендодателя и ключ только от своей полки в архиве — всё оформлено до того, как приехал грузовик с вещами. Типичный проект простыми словами. Данные клиента живут в Snowflake (или в Databricks, или в Fabric). Сотрудники входят через Entra ID (или Okta). Приложение работает в облаке клиента — часто в Azure. Твой агент пускает только «своих» через их собственный вход, с app roles, которые их IT назначает группам. Он работает как Container App с managed identity, вызывает model deployment в Foundry, читает секреты из Key Vault и сидит за private endpoints, если безопасность просит. Данные читает с минимальными правами: service user в Snowflake с ключом и ролью только на чтение, service principal в Databricks с OAuth M2M и правами только на gold или service principal в Fabric с Viewer на одном item. Логи идут в Application Insights — без персональных данных в промптах. Деплой — из GitHub через OIDC, никаких секретов в репозитории. _Diagram: Вход через IdP клиента, агент в их Azure с managed identity и одно узкое подключение к платформе данных._ ### Least Privilege — только то, что нужно для работы > Ключ-карта горничной в отеле открывает номера на её этаже во время её смены — не сейф, не кабинет управляющего, не другие этажи. **Least privilege** — давать только минимум нужных прав, на самый узкий охват, по умолчанию только на чтение. У каждой системы своя версия: Contributor на одну resource group вместо всей подписки; роль вроде `AI_AGENT_RO` с `SELECT` на views вместо чего-то близкого к `ACCOUNTADMIN`; delegated `Files.Read.All` вместо application `Sites.Read.All`; Viewer на одном item в Fabric вместо Admin на workspace; только gold-схема в Unity Catalog. Для агентов это важно даже больше, чем для людей: LLM можно обмануть prompt injection, и тогда ущерб останавливается ровно там, где кончается то, что ему разрешено. _Diagram: Те же четыре системы: слева слишком много, справа ровно сколько нужно._ #### Least Privilege (минимальные права · узкий охват) - **Что это:** Давать только те права, что нужны для работы, на самый узкий охват и на как можно меньший срок. - **Пример:** Роль агента в Snowflake может читать три views в `SALES.MART` и больше ничего — даже сырые таблицы за ними. - **Подвох:** Слишком узко — и агент падает странно («table not found»). Начни с минимума, добавляй права по одному и записывай, зачем нужно каждое. - **Связи:** Определяет роли в **Resource Hierarchy**, **Roles and RBAC**, права в **Unity Catalog**; первое, что проверяет **Security Review**. ### As the User vs As Itself — чьими глазами смотрит агент > Отправить помощницу в архив с твоим читательским билетом или с мастер-картой здания. С твоим она принесёт только то, что мог бы взять ты. С мастер-картой принесёт что угодно — и тебе решать, что кому она покажет. Это главный выбор дизайна, и о нём спрашивает каждый security review. **As the user**: агент обращается к источнику данных с identity вошедшего человека — delegated permissions в Entra, on-behalf-of, OAuth U2M в Databricks, вход через Okta или Entra в Snowflake, data agent в Fabric. Источник применяет права каждого человека сам, так что Анна видит Техас, а Бен — Огайо, бесплатно. **As itself**: агент использует один **service account** — service principal, managed identity, service user в Snowflake, «аккаунт для программы, а не для человека». Все, кто говорит с агентом, видят одни и те же данные, поэтому фильтровать должен _ты_: row access policies в Snowflake, row filters в Unity Catalog, RLS в Fabric или твой собственный код. Правило: отвечаешь людям → действуй от имени пользователя; фоновые задачи вроде ночной индексации → маленькая service identity. _Diagram: От имени пользователя: действуют права каждого человека. От своего имени: одна identity видит всё, и фильтрация — на тебе._ #### As the User vs As Itself (delegated / OBO vs service account) - **Что это:** Выбор: агент действует с identity каждого пользователя или со своей собственной service identity. - **Пример:** Ассистент по контрактам ищет в SharePoint от имени пользователя; отдельный фоновый индексатор работает как service identity с небольшим набором application permissions. - **Подвох:** Для медицинских и других чувствительных данных это ключевой вопрос ревью. С одной общей identity будь готов точно показать, как фильтруются строки. - **Связи:** Собирается из **Delegated vs Application Permissions**, **Cross App Access**, **Service User**; главный вопрос **Security Review**. ### Security Review — экзамен перед запуском > Приёмка здания перед открытием: инспектор обходит его с чек-листом, и двери открываются только после последней галочки. **Security review** — проверка твоего решения командой безопасности клиента перед запуском. Вопросы предсказуемы, так что готовь ответы заранее — лучше всего коротким документом со списком всех подключений. Куда уходят данные, в каком регионе работает модель, какая LLM и по какому контракту (data residency)? Есть ли API-ключи? Правильный ответ: «нет — managed identity, секреты в Key Vault». Закрыты ли сервисы от интернета? Минимальны ли роли? Агент действует от имени пользователя или от своего, и кто что видит? Что он может _сделать_ сам — записать, удалить, отправить письмо, — и есть ли подтверждение человеком? Что попадает в логи, на какой срок и есть ли персональные данные в промптах? Как отозвать доступ — выключить пользователя, удалить enterprise app — и работает ли это сразу? Ещё всплывают защита от prompt injection и content filters. _Diagram: Восемь вопросов, которые задаёт каждая команда безопасности. Пусть ответы будут записаны до того, как спросят._ #### Security Review (одобрение клиента) - **Что это:** Проверка командой безопасности клиента потоков данных, identities, прав, логов и отзыва доступа перед запуском. - **Пример:** Ты приносишь карту на одну страницу: каждое подключение, его identity, его роль и зачем оно нужно — плюс таблицы аудита, где виден каждый запрос. - **Подвох:** Сильнее всего ревьюеров пугают права на чтение всего от имени приложения (`*.Read.All`). Будь готов обосновать каждое или заменить его delegated-доступом. - **Связи:** Проверяет **Least Privilege**, **As the User vs As Itself**, **Private Endpoint**, **Key Vault**. ### Day-One Access — начни с самого медленного > Заказать костюм на свадьбу у портного: примерки занимают недели, поэтому заказываешь в день, когда пришло приглашение, а не за неделю до свадьбы. В компании среднего размера доступы — обычно самая медленная часть всего проекта. Гостевой аккаунт, роль на resource group, app registration с admin consent, service user в Snowflake, права в Unity Catalog, настройка tenant в Fabric «Service principals can call Fabric public APIs» — каждое из этого тикет к другому админу, и вместе это может занять от одной до трёх недель. Ты не админ и не станешь им. Поэтому в первый же день отправь одно сообщение со всем сразу: redirect URIs, scopes, app roles, группы, права — и зачем нужно каждое. Для Snowflake пришли готовый SQL-скрипт, который админ просто запустит. Сначала проси preview/тестовую среду. И проверь квоту модели в нужном регионе до того, как начнёшь строить, а не в день демо. _Diagram: Пришли полный список в первый день — и доступы будут готовы, когда готов код. Попросишь на третьей неделе — и демо ждёт роль._ #### Day-One Access (список доступов) - **Что это:** Привычка запрашивать все аккаунты, роли и настройки в самом начале, одним точным списком. - **Пример:** День 1: гость + Contributor на `rg-ai-agent-dev`, детали app registration, скрипт для `SVC_AI_AGENT`, контакт админа Fabric, проверка квоты. - **Как избежать:** Найди каждого админа заранее — админ Fabric часто не тот же человек, что админ Azure. Веди запросы как задачи, с ответственными и сроками. - **Связи:** Практическая сторона **Least Privilege**; питает **Security Review**. ### Как всё связано > Пазл: отдельный кусочек мало что значит; вместе они складываются в картину. Понятия этого курса — одна система. Ветка **облака** — **resource hierarchy** Azure, **managed identity**, **Key Vault**, **private endpoints** и **Foundry** — отвечает на вопрос, _где работает агент и как он обходится без секретов_. Ветка **идентичности** — **IdP и SSO**, **OIDC**, **Entra ID** с **app registrations**, **permissions**, **app roles** и **Conditional Access**, **Okta** со **SCIM** и **Cross App Access**, и **Agent ID** — отвечает на вопрос, _кто такие агент и его пользователи_. Ветка **данных** — от **lake** до **lakehouse**, **Snowflake**, **Databricks**, **Fabric** — отвечает на вопрос, _что агенту можно читать_. Все три сходятся в твоём агенте, а держат их вместе **least privilege**, выбор между действием **от имени пользователя или от своего** и **security review**. _Diagram: Три ветки — облако, идентичность, данные — сходятся в твоём агенте, а держат их вместе least privilege и security review._ #### Прежде чем начинать ИИ-проект внутри клиента - **Кто админы** — Azure, Entra или Okta, платформа данных, Fabric — и отправил ли я каждому точный список? - **Где работает агент** — Container App с managed identity, роли на одну resource group? - **Как входят люди** — OIDC через IdP клиента, app roles или отфильтрованные группы, стабильные ID пользователей? - **От имени пользователя или от своего** — а если от своего, как фильтруются строки? - **Что он читает** — только gold-таблицы или views, только на чтение, через маленький compute, который засыпает? - **О чём спросит безопасность** — ключи, сеть, роли, логи, data residency, отзыв доступа — и записаны ли мои ответы? #### Слова, которые теперь твои - **Tenant, subscription, resource group** — и почему роль на одну RG лучше, чем на подписку. - **Managed identity, Key Vault, private endpoint** — приложение без ключей и без публичной двери. - **IdP, SSO, OIDC, SAML** — и почему пользователей ключуют по `oid` + `tid` или `sub`, а не по email. - **App registration vs service principal**, **delegated vs application permissions**, **admin consent**. - **App roles, Conditional Access, Microsoft Graph, Entra Agent ID**. - **Okta org, Universal Directory, SCIM, org vs custom authorization server, Cross App Access**. - **Data warehouse, data lake, lakehouse, Delta Lake, medallion**. - **Virtual warehouse, credits, service user, Cortex**; **Unity Catalog, SQL warehouse, OAuth M2M, Agent Bricks**. - **OneLake, capacity, F SKU, SQL analytics endpoint, shortcut, mirroring, data agent**. - **Least privilege, service account, security review**. ## Шпаргалка: все 42 понятия ### Карта - **Enterprise Stack** (облако · идентичность · данные): Три слоя в каждой большой компании; твой агент сидит между ними. ### Облако: Azure - **Microsoft Azure** (облако Microsoft): Знакомые облачные идеи под другими именами; выбирают, потому что «всё Microsoft». - **Resource Hierarchy** (tenant · subscription · RG): Вложенные папки; роль, выданная выше, действует на всё ниже. - **Container Apps** (App Service · AKS · Functions): Serverless-контейнеры — обычный дом для бэкенда агента. - **Managed Identity** (без пароля): Аккаунт приложения, который получает токены от Entra; утекать нечему. - **Key Vault** (сейф для секретов): Где живут немногие настоящие секреты; читаются с узкой ролью. - **Private Endpoint** (VNet): Частный IP для сервиса, чтобы закрыть его от интернета. - **Microsoft Foundry** (бывший Azure AI Foundry): Model deployments, агенты и evals внутри tenant клиента. ### Идентичность: Entra ID - **Identity Provider** (IdP · SSO): Стойка компании; один рабочий аккаунт открывает все приложения. - **OIDC and SAML** (auth code + PKCE): Как приложения логинят людей через IdP; для нового кода — OIDC. - **Microsoft Entra ID** (бывший Azure AD): Облачный каталог людей, групп и приложений от Microsoft. - **App Registration vs Service Principal** (Enterprise app): Паспорт приложения и его копия в tenant, которая держит права. - **Delegated vs Application Permissions** (consent): Действовать как пользователь или как само приложение с admin consent. - **App Roles** (roles claim): Твои роли, которые их IT назначает группам, а твой бэкенд проверяет. - **Conditional Access** (правила MFA): Правила «если — то» при каждом входе; нужна Entra ID P1. - **Microsoft Graph** (graph.microsoft.com): Один API к данным Microsoft 365, ограниченный scopes токена. - **Entra Agent ID** (agent blueprint): Тип identity для ИИ-агентов, которым управляют как сотрудником. ### Идентичность: Okta - **Okta** (Workforce Identity): Нейтральный IdP для компаний со смесью вендоров; по org на компанию. - **SCIM** (joiner–mover–leaver): IdP сам создаёт и выключает пользователей в твоём приложении. - **Authorization Server** (org vs custom): Org — для входа; custom — для scopes твоего собственного API. - **Cross App Access** (XAA · Agent SSO): Агенты получают через Okta короткие залогированные токены к другим приложениям. ### Данные: Snowflake - **Warehouse · Lake · Lakehouse** (три формы): Строгие таблицы, сырые файлы или файлы с правилами таблиц сверху. - **Snowflake** (облачное хранилище данных): SQL-аналитика с разделёнными storage и compute. - **Virtual Warehouse** (credits): Вычислительный кластер с посекундной оплатой; ставь auto-suspend на 60. - **Roles and RBAC** (AI_AGENT_RO): Права — ролям, роли — пользователям; агенту только views. - **Service User** (TYPE = SERVICE): Аккаунт программы; key pair или OAuth, пароли заблокированы. - **Cortex** (ИИ рядом с данными): LLM-функции, text-to-SQL, поиск и агенты внутри Snowflake. ### Данные: Databricks - **Databricks** (lakehouse-платформа): Файлы в хранилище клиента; Spark, SQL и ИИ на тех же таблицах. - **Delta Lake** (Parquet + журнал): Папка файлов, которая ведёт себя как транзакционная таблица. - **Unity Catalog** (один охранник): Права, маски, lineage и аудит для любого пути внутрь. - **Medallion** (bronze · silver · gold): Слои качества; агент читает gold. - **SQL Warehouse** (OAuth M2M): Compute для SQL; serverless стартует за секунды, classic — за минуты. - **Agent Bricks** (бывший Mosaic AI): ИИ-зонтик Databricks: модели, serving, gateway, AI Search, Genie. ### Данные: Fabric - **Microsoft Fabric** (OneLake): Одно хранилище и один счёт для всех инструментов данных Microsoft. - **Capacity** (F SKU · CU): Общий пул вычислений; перерасход ведёт к throttling. - **SQL Analytics Endpoint** (T-SQL только на чтение): Lakehouse, видимый как SQL Server; идеален для чтений агента. - **Shortcuts and Mirroring** (без ETL): Указать на внешние данные или держать их живую копию в OneLake. - **Fabric Data Agent** (Fabric IQ): Встроенный «чат с данными» только на чтение, от имени пользователя. ### Собираем всё вместе - **Least Privilege** (минимальные права): Только то, что нужно для работы, на самый узкий охват. - **As the User vs As Itself** (OBO vs service account): Права каждого пользователя или одна identity, чей вывод фильтруешь ты. - **Security Review** (одобрение клиента): Предсказуемые вопросы; держи ответы записанными. - **Day-One Access** (список доступов): Запроси всё в первый же день, одним точным сообщением. > ИИ-агент внутри компании — это прежде всего проект про доступы. Запускай его в их облаке без ключей, логинь людей через их IdP, читай самый маленький срез данных и проси всё в первый же день. Конец экспресс-курса · 8 глав · 42 понятия Дальше — практика: заведи бесплатный аккаунт Azure и задеплой крошечный Container App с user-assigned managed identity, который читает один секрет из Key Vault, — без единого ключа. Зарегистрируй приложение в тестовом tenant Entra (или в developer org Okta), войди через OIDC и проверь ID token руками. Потом открой пробный Snowflake, создай пользователя `TYPE = SERVICE` с key pair и ролью только на чтение и прочитай view из Python. Запиши каждое право, которое понадобилось, и зачем, — этот список и есть твой первый документ для security review. Но держи одну мысль выше остальных: корпоративный стек — это всего три вопроса: где это работает, кто это и что ему можно читать, — и лучшие ответы всегда самые маленькие.