Инвентаризация SaaS и управление доступом
Когда сотрудник уходит из небольшой компании, стандартный сценарий увольнения выглядит так: ноутбук сдан, аккаунт в корпоративном мессенджере заблокирован — на этом всё. Но что с репозиторием кода? Облачным провайдером? Системой аналитики, панелью платёжного сервиса, CRM?
Большинство небольших компаний не могут ответить на вопрос «к каким сервисам имеет доступ этот сотрудник?» — нет центрального списка. Люди подключают инструменты по мере необходимости, никто это не отслеживает. При увольнении очевидное отзывается, неочевидное остаётся активным — иногда месяцами.
Эта глава даёт систему: инвентаризировать всё, что используется, зафиксировать кто имеет доступ к чему и выстроить процессы найма и увольнения, которые не оставляют брешей.
Почему это важнее, чем кажется
Компании, которые проводят этот аудит впервые, обычно называют цифру «инструментов двадцать — тридцать». Реальный результат, как правило, — больше 60, нередко больше 100. У команды из 20–30 человек легко набирается по три-пять инструментов на сотрудника: платёжные системы, облачные хранилища, сервисы аналитики, маркетинга, рассылок, HR.
Каждый из них — потенциальная точка входа. Каждый хранит какие-то данные компании. И у каждого своё управление пользователями, которое никто не контролирует централизованно.
Теневые ИТ
Теневые ИТ — не злой умысел. Это разработчик, который подключил бесплатный инструмент мониторинга для конкретного проекта. Маркетолог, протестировавший новый сервис рассылок. Руководитель, зарегистрировавшийся в ИИ-ассистенте с рабочей почтой.
Проблема не в том, что люди используют эти инструменты. Проблема в том, что никто не знает об их существовании — до тех пор, пока:
- финансовая служба не спросит «что это за ежемесячное списание?»
- не выяснится, что уволившийся сотрудник был единственным администратором критичного сервиса
- у вендора не случится утечка, и вы не поймёте, пользуетесь ли вы его услугами вообще
Накопление прав доступа
Сотрудники накапливают доступы со временем. Разработчик получил права администратора на тестовую среду для отладки — они так и не были отозваны. Человек временно участвовал в проекте — и остался в репозитории навсегда. Стажёр двухлетней давности по-прежнему имеет доступ к аналитике.
Это не вопрос доверия. Это вопрос поверхности атаки. Каждый аккаунт с доступом к системам компании — потенциальная точка входа при компрометации учётных данных. Принцип минимальных привилегий — не бюрократия. Это признание простого факта: меньше точек доступа означает меньше способов войти.
Построение реестра SaaS
Это неэффектная работа, но она фундаментальна. Невозможно защитить то, о существовании чего не знаешь.
Шаг 1: начать с очевидного
Попросить каждого руководителя направления перечислить инструменты, которые его команда использует в работе. Это быстро даёт основу — всё, что знают все.
Для каждого сервиса зафиксировать:
- Название и адрес
- Категория (инфраструктура, разработка, коммуникации, продуктивность и т.д.)
- Кто владелец аккаунта (кто платит, кто администрирует)
- Как аутентифицируются (индивидуальные аккаунты, SSO, общие учётные данные)
- Чувствительность данных — к чему есть доступ
- Стоимость
- Примерное число пользователей
Шаг 2: проверить финансовые записи
Запросить выписки по корпоративным картам и счетам за последние 6 месяцев. Каждое регулярное списание в пользу какой-либо программной компании — это сервис в реестре. Так обнаруживаются платные инструменты, которые не попали в первичный список.
Шаг 3: проверить DNS и почтовый домен
Многие SaaS-сервисы при подключении требуют добавить запись в DNS-зону для подтверждения домена. DNS-зона — случайный реестр интеграций: записи CNAME или TXT, указывающие на внешние сервисы, выдают инструменты, которые компания когда-то подключила. Эти записи часто «переживают» сотрудников, которые их создавали.
Проверьте также почтовые алиасы: есть ли адреса вроде support@company.ru, которые пересылают письма в какой-то внешний helpdesk?
Шаг 4: разослать запрос по компании
Направить сотрудникам короткий запрос: «Мы составляем реестр всех инструментов, которые используем. Если вы регистрировались в каком-либо ПО с рабочей почтой — пожалуйста, сообщите».
Всплывут вещи, о которых забыли: персональный планировщик, сервис для видеоконференций, ИИ-инструмент, которым пользовался один человек.
Шаблон реестра
Простая таблица работает для компаний до 100 человек:
| Сервис | Категория | Владелец | Аутентификация | Чувствительность | Пользователи | Стоимость/мес | Последняя проверка |
|---|---|---|---|---|---|---|---|
| Яндекс 360 | Ядро | CTO | SSO | Высокая — почта, документы | Все | ₽15 000 | 2024-01 |
| Облачный провайдер | Инфраструктура | CTO | IAM + MFA | Критичная — продакшн | 8 | ₽50 000 | 2024-01 |
| GitFlic / GitVerse | Разработка | VP Eng | SSO + MFA | Высокая — и сходный код | 25 | ₽8 000 | 2024-01 |
| VK Teams | Коммуникации | CTO | SSO | Средняя — внутренний чат | Все | ₽6 000 | 2024-01 |
| Пассворк | Безопасность | CISO | MFA | Критичная — все учётные данные | Все | ₽12 000 | 2024-01 |
| CRM | Продажи | VP Sales | Email/пароль | Высокая — данные клиентов | 10 | ₽20 000 | 2024-01 |
Категоризация по риску
Не все сервисы равнозначны. Категоризировать по ущербу при компрометации:
Критичные — инцидент означает немедленный серьёзный ущерб:
- Облачная инфраструктура (Yandex Cloud, VK Cloud, Selectel, Cloud.ru)
- Обработка платежей, банк-клиент
- Хранилища персональных данных клиентов (подпадают под 152-ФЗ)
- Доступ к производственному развёртыванию
Высокая чувствительность — инцидент означает значительный ущерб:
- Репозитории исходного кода
- Корпоративная почта и аутентификация
- Внутренняя документация с конфиденциальными данными
- HR-системы с данными сотрудников
Средняя — инцидент означает умеренный ущерб:
- Аналитика и мониторинг
- Инструменты управления проектами
- Дизайн-инструменты
- Маркетинговые инструменты
Низкая — инцидент означает минимальный прямой ущерб:
- Публичные социальные сети компании
- Общие инструменты без конфиденциальных данных
Усилия по безопасности концентрируются на критичных и высокочувствительных сервисах. Именно они требуют MFA, строгого управления доступом и внимательного контроля при увольнениях.
Минимальные привилегии на практике
Ролевой доступ, а не индивидуальные разрешения. Создать роли под функции: разработчик, DevOps, дизайнер, маркетолог, администратор. При найме назначить роль. При смене команды — обновить роль, а не накаплива ть права по одному.
По умолчанию — меньше прав. Когда кто-то запрашивает доступ, первый вопрос: «Нужны права на запись, или хватит чтения?». Начинать с чтения, расширять при реальной необходимости. Занимает 30 секунд, предотвращает накопление прав.
Временный доступ для разовых задач. Разработчику нужен доступ к производственной базе для отладки? Выдать на 24 часа, не навсегда. Поставить напоминание в календарь на отзыв.
Отдельные аккаунты для привилегированных операций. CTO не должен использовать один и тот же аккаунт для ежедневной работы и управления корневым доступом к облаку. Для критичных систем — отдельные административные аккаунты, используемые только для административных задач.
Плановый аудит доступа
Поставить в корпоративный календарь квартальное напоминание: «Проверка доступов». Для каждого критичного сервиса:
- Выгрузить список пользователей
- Сравнит ь с актуальным списком сотрудников
- Проверить несоответствия ролям (у маркетолога есть доступ к репозиторию кода?)
- Отозвать всё лишнее
Занимает 2–3 часа в квартал. Стоит этого.
Чек-лист найма
Новый сотрудник выходит на работу. Что должно произойти:
До первого рабочего дня:
- Создать корпоративный почтовый аккаунт
- Добавить в корпоративный мессенджер
- Добавить в Пассворк с доступом к нужным хранилищам
- Подготовить список инструментов по роли
В первый день:
- Провести инструктаж по Пассворку и настройке MFA
- Предоставить доступ к инструментам по роли
- Зафиксировать, что было предоставлено (обновить реестр)
Шаблон для разработчика:
| Задача | Инструмент | Уровень доступа | Выполнено |
|---|---|---|---|
| Создать корпоративный аккаунт | Яндекс 360 / VK WorkSpace | Стандартный пользователь | ☐ |
| Добавить в корпоративный мессенджер | VK Teams / eXpress | Участник | ☐ |
| Добавить в Пассворк | Пассворк | Участник команды | ☐ |
| Предоставить доступ к репозиторию | GitFlic / GitVerse | Участник команды | ☐ |
| Добавить в назначенные репозитории | Репозиторий | Запись в назначенные | ☐ |
| Создать пользователя в облаке | Облачный провайдер | Политика разработчика | ☐ |
| Добавить в среду разработки | CI/CD | Развёртывание на стейджинге | ☐ |
| Проверить MFA на всех критичных инструментах | — | — | ☐ |
Настроить под свой стек. Главное — наличие чек-листа, которому кто-то следует, а не надежда на память.
Чек-лист увольнения
Увольнение должно быть быстрее найма. Если предоставление доступа заняло два часа — его отзыв должен занять тридцать минут, потому что есть чек-лист.
До последнего рабочего дня:
- Экспортировать данные, которые нужны компании
- Передать владен ие общими документами, проектами, аккаунтами
- Выяснить, есть ли сервисы, где сотрудник — единственный администратор (критично!)
В последний рабочий день:
- Отключить корпоративный почтовый аккаунт (не удалять — настроить переадресацию руководителю на 30 дней)
- Отключить в корпоративном мессенджере
- Отозвать доступ к Пассворку — общие пароли, к которым сотрудник имел доступ, подлежат ротации
- Пройти по реестру SaaS и отозвать доступ к каждому сервису
- Отозвать доступ к VPN
- Удалить SSH-ключи с серверов
- Отозвать доступ к облачной консоли
После увольнения:
- Сменить общие учётные данные, которые знал сотрудник (корневые пароли, API-ключи, общие аккаунты)
- Проверить, нет ли личных аккаунтов на корпоративных сервисах
- Обновить реестр
Шаблон:
| Задача | Инструмент | Ответственный | Выполнено |
|---|---|---|---|
| Отключить почту | Яндекс 360 / VK WorkSpace | ИТ | ☐ |
| Отключить в мессенджере | VK Teams / eXpress | ИТ | ☐ |
| Отозвать доступ к Пассворку | Пассворк | лидер безопасности | ☐ |
| Сменить общие учётные данные | Пассворк | лидер безопасности | ☐ |
| Удалить из репозитория | GitFlic / GitVerse | Руководитель разработки | ☐ |
| Удалить пользователя в облаке | Облачный провайдер | DevOps-инженер | ☐ |
| Удалить из CI/CD | CI/CD | DevOps-инженер | ☐ |
| Отозвать доступ к VPN | VPN | ИТ | ☐ |
| Удалить SSH-ключи | Серверы | DevOps-инженер | ☐ |
| Удалить из CRM | CRM | Руководитель продаж | ☐ |
| ... (продолжить для всех сервисов в реестре) |
Пассворк в управлении доступом
При правильной настройке Пассворк закрывает несколько смежных задач:
Ротация общих учётных данных при увольнении. Пассворк отслеживает, кто и когда обращался к каким учётным данным. При увольнении легко определить, к каким общим паролям у сотрудника был доступ, и сменить их систематически.
Гранулярное управление доступом. Создать хранилища по командам или уровням чувствительности:
- Инфраструктурное хранилище — только DevOps и CTO
- Производственные учётные данные — только старшие инженеры
- Учётные данные для разработки — все разработчики
- Маркетинговые инструменты — маркетинговая команда
При смене роли или увольнении — обновить доступ к хранилищам.
Журнал аудита. Пассворк фиксирует, кто обращался к каким учётным данным и когда. При проверке или расследовании инцидента можно ответить: «Кто имел доступ к этому API-ключу за последние шесть месяцев?»
Хранилище для сервисов без SSO. Для приложений без поддержки единого входа Пассворк — место хранения локальных учётных данных с именованием [Сервис] — Администратор или [Сервис] — ivan@company.ru. Это даёт хотя бы центральную запись там, где нет автоматического управления доступом.
Как измерять результат
Полнота реестра:
- Количество сервисов в реестре
- Дата последней проверки каждого сервиса
- Цель: критичные и высокочувствительные сервисы — проверка раз в квартал
Гигиена доступа:
- Количество неактивных аккаунтов, выявленных при проверках
- Время от увольнения сотрудника до полного отзыва всех доступов
- Цель: полное оформление увольнения в течение 24 часов
Минимальные привилегии:
- Количество пользователей с административным доступом на каждом сервисе
- Цель: администраторов — не более 10% от общего числа пользователей на большинстве сервисов
Практические приёмы, которые помогают
Охота на «мёртвые» аккаунты по дате последнего входа. Большинство административных панелей SaaS показывают дату последнего входа. Во время квартального аудита отсортировать пользователей по этой дате и найти аккаунты без активности за 90+ дней. Это либо бывшие сотрудники, которых не уволили из системы, либо сотрудники, которым доступ фактически не нужен.
Переадресация почты перед отключением. Когда сотрудник уходит, не отключайте почту сразу. Настройте переадресацию его ящика руководителю на 30 дней. Так перехватываются: ссылки для сброса пароля от сервисов, которые забыли отозвать; счета от подписок, привязанных к личному адресу; входящие от внешних контактов.
После 30 дней — просмотреть, что пришло, закрыть осиротевшие аккаунты, затем удалить ящик.
Поиск по корпоративной почте. Когда обнаруживается сервис, о котором никто не знает, можно найти, кто и когда в нём регистрировался: поиск по домену отправителя и ключевым словам «добро пожаловать» или «подтвердите» покажет письма о регистрации с рабочей почты.
Управленческое задание для лидера безопасности
Что поручить:
- Построить реестр SaaS, используя методологию из этой главы
- Категоризировать сервисы по чувствительности данных
- Создать чек-листы найма и увольнения для каждой ключевой роли
- Провести первый аудит доступа к пяти критичным сервисам
- Настроить квартальный процесс проверки и внести его в корпоративный календарь
Какой артефакт получить на выходе:
- Реестр SaaS с категориями чувствительности и владельцами
- Чек-листы найма и увольнения (по ролям и универсальный)
- Отчёт о первом аудите доступа: что найдено, что исправлено
- Настроенный регулярный процесс проверки
Контрольные вопросы перед переходом к следующей теме:
Реестр:
- Реестр SaaS составлен
- Добавлено не менее 30 сервисов (реальная цифра, как правило, выше)
- Проверены финансовые записи на регулярные списания за ПО
- Каждому сервису назначен владелец
- Сервисы категоризированы по чувствительности данных
- Выявлены сервисы со слабой аутентификацией
Управление доступом:
- Созданы чек-листы найма для ключевых ролей
- Создан универсальный чек-лист увольнения
- Определены ответственные за каждый шаг отзыва доступа
- Проведён аудит доступа для пяти критичных сервисов
- Обнаруженные «призрачные» аккаунты устранены
Интеграция с Пассворком:
- Структура хранилищ отражает командные и ролевые права доступа
- Общие учётные данные находятся в нужных хранилищах, а не в личных
- Процедура ротации при увольнении понятна ответственным
Процесс:
- Квартальный аудит доступа внесён в корпоративный календарь
- Чек-лист увольнения доступен HR и руководителям
- Минимум ещё один человек знает и понимает процесс
См. также
- Каталог пользователей и SSO — подключение сервисов к единому входу
- Безопасность подрядчиков — оценка поставщиков перед подключением
- Управление паролями — где хранятся доступы к сервисам
Что дальше
Теперь известн о, какие сервисы использует компания и кто к чему имеет доступ. Процессы предоставления и отзыва доступа выстроены.
Следующая глава: обновления программного обеспечения и управление уязвимостями. Устаревшее ПО с известными уязвимостями — один из самых лёгких способов для злоумышленника попасть в систему.