В корпоративном реестре может числиться полторы сотни приложений, хотя реальная инфраструктура давно вышла за его пределы: сотрудники заводят личные аккаунты в SaaS, оплачивают подписки со своих карт и поднимают временные облачные ресурсы, которые продолжают работать годами.

Та же история с железом: личный роутер разработчика, Raspberry Pi для мониторинга, домашний NAS с рабочими файлами или принесённый из дома коммутатор — всё это живёт в корпоративной сети, но не существует ни в одном реестре. Каждый такой инструмент появляется по понятной причине — его можно запустить за несколько минут, пока согласование занимает недели, но затем он обрастает данными, доступами и интеграциями, оставаясь вне общего контура управления.

Так формируется Shadow IT — не только софт и облака, но и физические устройства, которые обычный discovery видит лишь фрагментами. Разберём, откуда берётся этот скрытый слой инфраструктуры, во сколько он обходится компании и как вернуть его под контроль без тотальных запретов.

Человеку нужен инструмент, он открывает сайт, регистрируется и через несколько минут продолжает работу. Корпоративный процесс (если оформлять сервис через него) за это время успеет разве что принять заявку. 

Если сервис оказывается удобным, в него приглашают коллег, загружают документы и подключают интеграции, затем появляется платный тариф. Иногда расход попадает в закупки, иногда проходит через авансовый отчёт, а бесплатные аккаунты могут годами обходить финансовые отчеты и контроль учета.

Через несколько месяцев эксперимент уже неотъемлемо участвует в рабочих процессах. В сервисе хранится история проекта, клиентская база или исходный код, к нему привязаны десятки аккаунтов, а единственным администратором остаётся человек, который когда-то первым нажал Sign up. 

Проект тем временем мог завершиться, команда — смениться, а тот сотрудник вовсе уволиться. Данные и интеграции продолжают существовать, хотя восстановить исходный замысел и найти ответственного становится всё труднее.

Так формируется Shadow IT — слой приложений, устройств и облачных ресурсов, которые используются в работе, но выпадают из общего контура управления. Чаще всего он складывается из вполне рациональных решений, принятых в разное время разными людьми. 

Часть инструментов действительно нужна бизнесу, часть дублирует корпоративные системы, остальные переживают задачи, ради которых появились. Сам статус актива при этом может меняться: согласованная тестовая среда становится теневой после завершения пилота, если её не закрыли и не назначили нового владельца.

Обычная инвентаризация помогает увидеть лишь отдельные участки этой инфраструктуры. Агент на ноутбуке обнаруживает установленное ПО, пропуская SaaS в браузере. SSO показывает корпоративные учётные записи, однако личная почта остаётся за его пределами. Бухгалтерия находит платёж, если он проходил через компанию, а облачная консоль знает только о ресурсах внутри подключённых аккаунтов. Каждый источник описывает ту часть ИТ-ландшафта, которая уже попала в соответствующий процесс. Shadow IT сохраняется в промежутках между ними.

Откуда берётся Shadow IT

Теневая инфраструктура обычно появляется там, где скорость работы подразделения и скорость корпоративных процедур заметно расходятся. Новый сервис вправду можно развернуть за несколько минут, тогда как согласование закупки, проверка безопасности и подключение к SSO занимают дни или чаще недели. Для сотрудника выбор прагматичный: задача уже стоит, подходящий инструмент доступен, а последствия его использования проявятся (если проявятся) гораздо позже. Если сервис помогает закрыть текущую потребность, он быстро закрепляется в процессе и начинает расти вместе с ним.

Этому способствует сама модель SaaS.
Многие продукты позволяют начать с бесплатного тарифа, зарегистрироваться по рабочей или личной почте и пригласить коллег без участия ИТ-службы. На раннем этапе сервис почти не оставляет следов: нет ни договора, ни платежа, не требуется и устанавливать локальное ПО. Когда команда привыкает к инструменту, в нём уже лежат документы, макеты, переписка или данные клиентов. Отказаться от него становится сложнее, и параллельно с этим появляется платная подписка, которую проводят через корпоративную карту, авансовый отчёт или бюджет подразделения.

Похожим образом растёт и теневая облачная инфраструктура. Разработчику нужен стенд для теста, аналитикам — временная база, продуктовой команде вообще отдельное окружение для пилота. Ресурс создают быстро, иногда в личном аккаунте, иногда в корпоративном облаке, но в большинстве случаев вне принятой схемы учёта. Через несколько недель эксперимент может завершиться, а виртуальная машина, бакет или сервисный аккаунт продолжат существовать. Биллинг, как понимаете, будет списываться автоматически.

Отдельный пласт теневой инфраструктуры — физическое оборудование. Разработчик приносит из дома роутер, потому что корпоративный Wi-Fi не достаёт до его угла. Админ ставит Raspberry Pi для мониторинга, потому что заявку на нормальный сервер согласуют через месяц. Аналитик подключает личный NAS с рабочими файлами, потому что на сетевом диске кончилось место. Каждое из этих устройств подключено к корпоративной сети, но не существует ни в одном реестре — а для ИБ это не просто неучтённый актив, а незакрытый вход во внутреннюю сеть.

Отдельный источник Shadow IT — организационная децентрализация.
Во многих компаниях маркетинг, HR, финансы и разработка самостоятельно выбирают часть инструментов и распоряжаются собственными бюджетами. Модель ускоряет работу, однако сведения о приложениях распределяются между закупками, бухгалтерией, ИТ-службой и владельцами процессов. Если между этими системами нет общего контура учёта, даже официально оплаченный сервис может остаться вне общей картины.

С развитием генеративного ИИ механизм ускорился.
Сотруднику уже не нужно внедрять отдельную систему: достаточно открыть чат-бот, установить расширение или включить AI-функцию внутри привычного приложения. За несколько минут в новый канал начинают попадать рабочие документы, исходный код или клиентские данные. Корпоративные политики обычно появляются позже, поэтому компания сначала сталкивается с массовым использованием инструмента и только затем пытается понять, где он уже встроился в процессы.

Почему discovery даёт увидеть только часть картины?

У каждого источника инвентаризации своя область видимости. Агент на рабочей станции находит установленное ПО и оборудование, но почти ничего не знает о сервисах, которые открываются в браузере. SSO показывает корпоративные учётные записи, хотя регистрация через личную почту остаётся за его пределами. Финансовые системы обнаруживают подписку после оплаты, пропуская бесплатные тарифы и расходы с личных карт.

С облачной инфраструктурой действует тот же принцип. Консоль провайдера показывает ресурсы внутри подключённых аккаунтов, однако тестовая среда может жить в отдельной подписке разработчика. Сетевой мониторинг зафиксирует обращение к внешнему сервису, но обычно не объяснит, кто его использует, для какой задачи и какие данные туда передаются.

Поэтому discovery редко даёт готовый реестр Shadow IT. Он создаёт набор сигналов: неизвестный домен в трафике, новый платёж, OAuth-приложение, облачный ресурс без владельца. Чтобы превратить их в управляемые активы, данные приходится сопоставлять между собой, нормализовать названия и связывать с конкретными командами, пользователями и процессами.

Даже после этого остаётся контекст, который невозможно получить одним сканированием. Система может определить, что сотрудники используют Notion, но не поймёт, хранится ли там черновик внутренней инструкции или клиентская база. Техническое обнаружение показывает факт использования; оценка ценности и риска начинается только после того, как у актива появляется владелец.

Во сколько обходится Shadow IT

Прямые расходы обычно выглядят скромно.
Одна подписка на нейросеть, отдельный тариф в той же Figma или несколько виртуальных машин редко сами по себе привлекают внимание и образуют ощутимую сумму. Проблема возникает после накопления: подразделения покупают похожие инструменты независимо друг от друга, подписки продлеваются автоматически, а скидки за централизованную закупку остаются недоступны.

По данным Zylo, приложения, которые сотрудники оплачивали сами, — это около 45% всех найденных SaaS, но лишь 3,7% расходов. Выборка отражает клиентскую базу самой Zylo и описывает не весь рынок, но суть проблемы показывает точно: Shadow IT растёт не суммами, а числом. Десятки мелких сервисов, и у каждого — свои аккаунты, интеграции и места, где лежат данные.

С облачными ресурсами затраты устроены иначе. Забытый стенд или тестовая база могут месяцами списывать небольшие суммы, пока никто не сопоставит платёж с завершённым проектом. Даже когда ресурс обнаружен, быстро отключить его получится не всегда: сначала придется выяснить, зависит ли от него какой-либо рабочий процесс и остались ли внутри нужные данные.

Самые дорогие последствия часто проявляются уже после потери доступа или инцидента. Компании приходится восстанавливать права на рабочее пространство, переносить данные, искать неизвестные интеграции и вручную разбирать историю использования. Поэтому существенная часть расходов появляется из-за того, что актив обнаруживают слишком поздно.

Что компания теряет вместе с видимостью

Главный риск Shadow IT возникает из-за нехватки контекста. Служба безопасности может видеть обращение к внешнему сервису, но не знать, какие данные туда передают и кто отвечает за аккаунт. При инциденте это увеличивает время расследования: сначала приходится восстанавливать саму схему использования, а уже затем оценивать последствия.

Частая уязвимость связана с доступами: рабочее пространство создаёт один сотрудник, коллег приглашают по мере необходимости, а отзыв прав после увольнения зависит от памяти администратора. Если аккаунт зарегистрирован на личную почту, компания может потерять контроль над данными вместе с его владельцем. Похожая проблема возникает с API-ключами, OAuth-разрешениями и интеграциями, которые продолжают работать после завершения проекта.

Отдельный слой риска связан с хранением данных. В неизвестном сервисе могут оказаться договоры, клиентские базы, макеты или исходный код, хотя компания не проверяла условия обработки, регион размещения и резервное копирование. Сам сервис при этом может быть достаточно защищённым, но уязвимость создаёт способ его использования: личный аккаунт, слабые настройки доступа или отсутствие владельца.

Поэтому оценивать Shadow IT только по списку запрещённых приложений мало полезно. Один и тот же продукт может использоваться в управляемом корпоративном контуре и параллельно существовать в десятках личных рабочих пространств. Для компании важен статус конкретного экземпляра: кто им владеет, какие данные внутри и можно ли быстро отозвать доступ или закрыть ресурс.

Shadow AI в принципе ускоряет старую проблему

С генеративным ИИ Shadow IT стало сложнее распознавать. Раньше компания искала неизвестные приложения и аккаунты, теперь часть риска скрывается внутри уже знакомых сервисов: AI-функции появляются в редакторах, CRM, IDE, браузерных расширениях и системах аналитики, которые могли быть согласованы задолго до их внедрения.

В 2025 году генеративные AI-приложения использовались в большинстве наблюдаемых организаций, а значительная доля сотрудников входила в них через личные аккаунты. Эти данные отражают клиентскую базу платформы, но хорошо показывают направление изменений: корпоративные документы, исходный код и клиентская информация всё чаще попадают в каналы, которые IT видит лишь частично.

Обычный реестр здесь быстро потеряет актуальность, в нём может числиться разрешённое приложение, однако очередное обновление добавляет функцию, которая отправляет содержимое документа во внешнюю модель. Формально продукт остаётся тем же, хотя схема обработки данных уже изменилась.

Поэтому для Shadow AI недостаточно знать название сервиса. Приходится учитывать конкретные функции, тип аккаунта, настройки хранения и характер передаваемых данных. Без этого известное приложение сохраняет теневой слой внутри управляемой инфраструктуры.

Что делать?

Первой реакцией на теневую инфраструктуру обычно становится запрет.
Компания блокирует доступ к отдельным сервисам, запрещает устанавливать приложения и требует проводить любые новые инструменты через согласование.

Подобный подход возможно снижает часть рисков, особенно если речь идёт о заведомо небезопасных продуктах, однако полностью проблему никак не решит. Сотрудники переходят на личные аккаунты, открывают сервисы с домашних устройств или используют мобильный интернет. Сам инструмент при этом остаётся в рабочем процессе, а его использование становится менее заметным.

Причина сохраняется: подразделению по-прежнему нужен способ решить задачу быстрее, чем это позволяет корпоративная процедура. Если согласование занимает несколько недель, а новый SaaS запускается за пять минут, часть сотрудников выберет второй вариант независимо от формального запрета. Поэтому контроль Shadow IT обычно начинается с пересмотра самого пути появления новых инструментов. Чем проще сотруднику заявить о сервисе, получить быструю оценку и запустить ограниченный пилот, тем меньше причин оставлять его за пределами официального контура.

После обнаружения неизвестного актива его ещё предстоит превратить в управляемый. Сигналом может стать новый платёж, обращение к неизвестному домену, OAuth-приложение или облачный ресурс без владельца. Эти данные нужно сопоставить, определить сам продукт и связать его с конкретным подразделением. Один сервис нередко фигурирует под разными названиями, доменами и юридическими лицами, поэтому без нормализации в реестре быстро появляются дубли.

Дальше компании приходится восстановить контекст использования: кто создал аккаунт, какие команды от него зависят, какие данные там хранятся, сколько стоит подписка и какие интеграции уже подключены. После этого возможны разные решения. Полезный сервис можно легализовать и перенести под корпоративное управление, дублирующий — заменить стандартным инструментом, рискованный — ограничить, а забытый ресурс  закрыть после проверки данных и зависимостей. Единая политика для всех найденных активов обычно уступает такой оценке по конкретному сценарию.

На этом этапе появляется роль ITAM.
Сетевой мониторинг, IAM, финансовая система и облачные консоли дают отдельные сигналы, но каждый из них описывает только свою часть инфраструктуры. ITAM связывает найденный актив с владельцем, подразделением, договором, лицензией, устройством или бизнес-сервисом и затем отслеживает его жизненный цикл. 

В таком контуре становится видно, когда заканчивается пилот, кто отвечает за продление подписки, какие доступы нужно отозвать после увольнения и можно ли перераспределить активы между командами.

В SimpleOne ITAM такой реестр может использоваться как точка сборки данных из разных источников. Сам по себе он не обнаружит личный аккаунт в Notion или виртуальную машину в неизвестной облачной подписке, если ни одна система не передала соответствующий сигнал. Его задача начинается после обнаружения: нормализовать актив, связать его с организационной структурой и сохранить историю решений по нему. Это особенно важно для сервисов, которые переходят из временного эксперимента в постоянный рабочий инструмент.

Полностью убрать Shadow IT вряд ли получится. Новые приложения появляются быстрее внутренних регламентов, а сотрудники продолжат искать инструменты под конкретные задачи. Практическая цель состоит в другом: сократить время, в течение которого актив остаётся неизвестным, и не позволять временным решениям годами существовать без владельца, правил доступа и понятного завершения жизненного цикла.