SOC 2 Type 1 против Type 2: фото для аренды против реалити-шоу

После трёх недель демонстраций и созвонов потенциальный корпоративный клиент присылает долгожданное письмо: «Пожалуйста, приложите актуальный отчёт SOC 2 Type 2, чтобы отдел безопасности согласовал закупку».

Лид команды продаж пересылает запрос инженерам в приподнятом настроении. В прошлую пятницу компания как раз завершила аудит: на руках свежий 45-страничный PDF от сертифицированной аудиторской фирмы. Спустя двадцать минут файл уже летит клиенту.

Через двое суток из отдела безопасности заказчика приходит короткий отказ: «Вы прислали отчёт Type 1. Наш регламент требует Type 2 минимум за шесть месяцев работы. Напишите нам, когда закроется период наблюдения».

Сделка встаёт на паузу на полгода.

Постановочное фото против скрытой камеры на кухне

Стандарт SOC 2 проверяет, как технологические компании защищают клиентские данные: от шифрования баз до процессов найма и изменений в кодовой базе.

Отчёт SOC 2 Type 1 похож на подготовку квартиры к съёмке для сайта аренды. Вы запихиваете разбросанные носки под диван, прячете грязные сковородки в духовку, пшикаете освежителем воздуха и замираете, пока фотограф делает кадр. Этот снимок юридически фиксирует: во вторник в 14:15 в квартире действительно царил идеальный порядок.

Отчёт SOC 2 Type 2 — это как если бы съёмочная группа документального реалити-шоу заселилась к вам в гостиную на полгода. Операторы смотрят, как вы варите кофе сонным утром в понедельник. Они фиксируют, вытираете ли вы стол в полночь четверга. Они проверяют, не копятся ли немытые кружки в раковине, когда у вас горит дедлайн.

Здесь аналогия расходится с реальностью: в реалити-шоу гора посуды на кухне делает выпуск только живее и интереснее для зрителей. В отчёте SOC 2 Type 2 разработчик, вливший срочный фикс прямо в ветку main без код-ревью коллеги, превращается в аудиторское замечание на странице 32. И этот отчёт ложится на стол директору по безопасности вашего заказчика.

Что на самом деле проверяет аудитор

Главное отличие между Type 1 и Type 2 — это разница между замыслом и реальной ежедневной практикой.

Type 1: проверка архитектуры на одну дату

Аудит Type 1 оценивает, насколько грамотно спроектированы ваши политики и настройки безопасности на конкретный день:

Написана ли у вас политика доступа, требующая двухфакторную аутентификацию?
Закрыт ли доступ к боевой базе данных фарволом прямо сейчас?
Включено ли шифрование дисков на ноутбуках, которые вы показали аудитору на созвоне?

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

Корпоративные заказчики отлично это понимают, поэтому отчёт Type 1 почти никогда не проходит скоринг безопасности для систем, обрабатывающих критичные данные.

Type 2: операционная дисциплина на длинной дистанции

Аудит Type 2 проверяет, работали ли заявленные правила на протяжении всего периода наблюдения — обычно от 3 до 12 месяцев.

Здесь аудитор уже не верит скриншотам одного дня:

Из всех пулреквестов, влитых в продакшн с января по июнь, аудиторская программа берёт случайную выборку из тридцати штук. Проверяется каждый: стоял ли аппрув от второго инженера до того, как код попал в сборку.
Даты увольнения сотрудников из HR-системы сверяются с логами Google Workspace и GitHub: был ли доступ отозван строго в течение прописанных в политике 24 часов.
Проверяются алерты облачного мониторинга: реагировала ли дежурная смена на инциденты безопасности в рамках утверждённых сроков.

Чтобы закрыть Type 2 без замечаний, требуется постоянная дисциплина процессов. Один хотфикс в три часа ночи без аппрува во время сбоя в апреле превратится в официальный дефект аудита в ноябре.

Три грабли, на которые наступают команды в Type 2

Большинство проблем в период наблюдения возникают не из-за коварных хакеров, а из-за бытовой спешки:

1. Ночной пуш в обход правил

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

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

2. Забытый аккаунт подрядчика

Внешний дизайнер завершил проект 15 марта. Менеджер поблагодарил его в чате, но забыл завести задачу на отзыв доступов в IT-отдел.

Почта и корпоративные доступы подрядчика оставались активными до плановой ревизии в мае. Аудитор сравнивает дату акта выполненных работ со временем блокировки учётной записи и выкатывает замечание: доступ к инфраструктуре сохранялся два месяца после завершения контракта.

3. Пулреквест без привязки к задаче

Во многих командах действует правило: у каждого изменения в коде должен быть номер тикета в таск-трекере. Посреди спринта разработчик замечает опечатку в шапке сайта и вливает быстрый коммит fix typo in header без ссылки на тикет.

Для разработчика это безобидная правка на две строчки. Для аудитора — несанкционированное изменение production-контура без согласованного обоснования.

Инженерные барьеры вместо надежды на память

Полагаться на человеческую память на протяжении 180 дней подряд — верный способ провалить Type 2. Зрелые команды заменяют устные договоренности жесткими техническими ограничениями:

# Пример: блокировка прямого пуша в main через GitHub API,
# чтобы обойти ревью было физически невозможно даже админам
gh api -X PUT repos/:owner/:repo/branches/main/protection \
  -F "required_status_checks[strict]=true" \
  -F "enforce_admins=true" \
  -F "required_pull_request_reviews[required_approving_review_count]=1" \
  -F "required_pull_request_reviews[dismiss_stale_reviews]=true"

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

Точно так же синхронизация корпоративного каталога с кадровой системой через протокол SCIM гарантирует, что при смене статуса сотрудника в HR-сервисе доступы отзываются автоматически за считанные секунды.

Type 1 доказывает, что вы умеете красиво описать безопасность на бумаге. Type 2 доказывает, что ваши инженерные привычки выдерживают столкновение с реальной рабочей суетой.

С каким самым нелепым или неожиданным замечанием аудитора сталкивалась ваша команда во время проверки?