Соответствие SOC 2 для Google Workspace: что нужно знать

Если Ваша организация проходит путь к SOC 2 — а рано или поздно это делает большинство B2B-компаний, разрабатывающих ПО, поскольку клиенты этого требуют, — Google Workspace обязательно попадёт в область проверки. В нём хранятся учётные записи, документы и элементы управления доступом, которые напрямую соотносятся с критериями, которые проверяет аудитор. Эта статья объясняет, как Workspace вписывается в программу SOC 2 и как подготовить его сторону без аврала в последний момент.

Сразу оговорка по терминологии: SOC 2 — это *аттестация*, проводимая независимой аудиторской фирмой (CPA), а не значок, который Вы присваиваете себе сами. Результатом является отчёт аудитора, а не самопровозглашённый лейбл. Внутри организации Вы можете выстроить и продемонстрировать элементы управления, а также собрать доказательства, чтобы аттестация прошла гладко. Именно об этом данная статья.

Краткая ориентация в SOC 2

SOC 2 оценивает элементы управления обслуживающей организации в соответствии с Trust Services Criteria (TSC): Security (включается всегда, часто называется Common Criteria) и, опционально, Availability, Processing Integrity, Confidentiality и Privacy. Критерии Security — серия CC — это то место, где Google Workspace проявляется чаще всего.

Отчёт Type I оценивает, были ли элементы управления *спроектированы* надлежащим образом на определённый момент времени. Отчёт Type II оценивает, *работали ли они эффективно* в течение периода (как правило, 3–12 месяцев). Клиенты обычно хотят именно Type II, и это имеет важное следствие: Вам нужны элементы управления, которые работают, и доказательства того, что они работали, на протяжении всего периода — а не только в день аудита.

Где Google Workspace соотносится с критериями

Несколько Common Criteria чётко соотносятся с элементами управления Workspace, с которыми Вы уже работаете:

• CC6.1 — Логические элементы управления доступом. Кто может получить доступ к защищённой информации и как доступ ограничен авторизованными пользователями. В терминах Workspace: выделение учётных записей, принудительное применение MFA, элементы управления совместным доступом, а также доступ, которым обладает каждая учётная запись, включая внешние и служебные аккаунты.
• CC6.2 — Регистрация и авторизация. Новые пользователи регистрируются и авторизуются до предоставления доступа; доступ отзывается, когда он более не нужен. Здесь находится гигиена процессов joiner/mover/leaver.
• CC6.3 — Минимально необходимые привилегии и разделение обязанностей. Доступ основан на ролях и ограничен минимально необходимым уровнем. Избыточные права доступа и разрастание административных привилегий — это находки, противоречащие данному критерию.
• CC6.6 — Защита от внешних угроз. Внешне доступная поверхность: публичные ссылки, внешний совместный доступ и доступ, предоставленный учётным записям за пределами организации.
• CC7.x — Мониторинг и реагирование на инциденты. Обнаружение аномалий и реагирование на события безопасности. Знание о том, когда изменяются настройки совместного доступа или прав, и возможность провести расследование, поддерживают эти критерии.

Запоминать нумерацию не нужно. Суть в том, что повседневная работа с Workspace — принудительное применение MFA, контроль совместного доступа, удаление устаревшего доступа, управление сторонними приложениями — *и есть* те доказательства элементов управления, которые хочет видеть аудитор.

Что аудиторы на самом деле запрашивают

Аудиторам нужны не заверения, а доказательства. По элементам управления, связанным с Workspace, ожидайте запросов вроде:

• Подтверждение того, что MFA применяется принудительно (сама политика и её применение на практике, а не просто «мы это включили»).
• Список администраторов и обоснование для каждой привилегированной роли.
• Доказательства проведения проверок доступа — что Вы периодически проверяете, кто может получить доступ к конфиденциальным данным, и предпринимаете действия по результатам проверки.
• Записи об отзыве доступа при увольнении сотрудников.
• Конфигурацию совместного доступа и то, как контролируется внешний общий доступ.
• Запись о том, как выявленные проблемы безопасности отслеживаются до устранения.

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

Как подготовить сторону Workspace

1. Установите базовую конфигурацию (baseline). Задокументируйте желаемое состояние настроек администратора — совместный доступ, двухэтапная аутентификация, ограничения Marketplace, аутентификация электронной почты — и регулярно сверяйте фактическое состояние с этим эталоном. Отклонение (drift) — враг чистого аудита.
2. Проводите проверки доступа, которые можно подтвердить доказательствами. Периодически проверяйте, кто может получить доступ к конфиденциальным данным, включая внешние и нечеловеческие учётные записи, и сохраняйте результаты. «Мы проверяли доступ ежеквартально, вот записи» — это именно то, чего требует CC6.3.
3. Ужесточите и задокументируйте совместный доступ. Соотнесите с CC6.1 и CC6.6, контролируя публичный и внешний совместный доступ и имея возможность показать текущее состояние.
4. Отслеживайте выявленные проблемы до их устранения. Когда Вы обнаруживаете уязвимость, фиксируйте её, устраняйте и сохраняйте историю. Это поддерживает критерии мониторинга и устранения.
5. Ведите журнал аудита. Запись с временными метками о действиях, значимых для безопасности, делает ответы на вопросы «кто, что и когда сделал» тривиальными.

Многое из этого пересекается с общей практикой обеспечения безопасности Google Workspace — в этом и суть. SOC 2 — это не отдельный проект, пристёгнутый сбоку; это Ваша практика безопасности, сделанная понятной и подтверждённой доказательствами.

Непрерывные доказательства лучше авральной подготовки к аудиту

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

Альтернатива — непрерывность: контролировать состояние безопасности круглый год, генерировать доказательства как побочный продукт и приходить на аудит с уже собранной историей. Инструмент контроля состояния, который сопоставляет находки с критериями SOC 2 и формирует доказательства, готовые для аудитора, превращает аврал в простой экспорт данных.

Типичные ошибки в части аудита, касающейся Workspace

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

• Путать «настроено» с «принудительно применяется». Включение политики двухэтапной аутентификации — не то же самое, что её применение ко всем учётным записям. Аудиторы проверяют именно последнее. Убедитесь, что принудительное применение действует в масштабах всей организации — см. наше руководство по принудительному применению MFA в Google Workspace.
• Относиться к проверкам доступа как к формальной галочке. «Мы проверяем доступ» без записей, области охвата или дальнейших действий — это не доказательство. Сохраняйте результаты и показывайте, что по выявленным проблемам были приняты меры.
• Забывать про нечеловеческие учётные записи. Служебные аккаунты и ИИ-агенты также обладают доступом, и аудитор, проверяющий принцип минимальных привилегий (CC6.3), не примет ответ «мы проверяли только людей». Управляйте ими — см. обнаружение рискованных ИИ-агентов.
• Допускать отклонение конфигурации между аудитами. Базовая конфигурация, которая была чистой в январе и «поплыла» к июню, приведёт к находке в отчёте Type II. Именно непрерывная проверка, а не ежегодный снимок состояния, удерживает ситуацию под контролем.

Соответствие требованиям — побочный продукт хорошей безопасности

Наиболее полезная переформулировка для стороны Workspace в SOC 2 заключается в том, что Вы выстраиваете элементы управления не *ради аудита* — Вы ведёте полноценную программу безопасности и позволяете аудиту наблюдать за ней. Всё, что аудитор хочет увидеть по критериям контроля доступа, — это то, что Вы и так хотели бы иметь: принудительно применяемая идентификация, контролируемый совместный доступ, управляемый доступ сторонних приложений и поддерживаемая базовая конфигурация. Аудит просто просит сделать всё это понятным и подтверждённым доказательствами.

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

8200.dev сопоставляет состояние безопасности Вашего Google Workspace с семействами элементов управления SOC 2, ISO 27001 и GDPR и формирует пакеты доказательств, которые можно передать аудитору — честные, ограниченные тем, что мы действительно наблюдаем, и никогда не являющиеся необоснованным заявлением о соответствии. Подробнее о том, как это работает, или о наших собственных практиках безопасности.

Готовитесь к аудиту? Начните бесплатный аудит безопасности и посмотрите, как состояние Вашего Google Workspace соотносится с критериями контроля доступа, которые проверяют аудиторы.