# Как выбрать стек для SaaS с жёсткими требованиями комплаенса

> Чего регулирование на самом деле требует от архитектуры и как выбрать хостинг, сервисы и инструменты, чтобы аудит стал рутинной задачей, а не поводом всё перестраивать.

Илья Исматов · CTO · 10 августа 2026 г. · Инженерия

Bitmason: https://bitmason.dev/ru/blog/tech-stack-for-compliance-heavy-saas/

Когда SaaS-продукт продаётся банкам, больницам или крупным корпорациям, комплаенс перестаёт быть документом и начинает определять устройство системы. Клиенты присылают опросники по безопасности, просят отчёт SOC 2 или сертификат ISO 27001 и вписывают условия обработки данных в договоры. В зависимости от рынка продукту может понадобиться соответствовать ещё и GDPR, PCI DSS или HIPAA.

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

## Что комплаенс на самом деле ограничивает

Если отбросить бумаги, большинство требований сводится к нескольким техническим областям.

- **Размещение данных (data residency).** Некоторые клиенты или регуляторы требуют, чтобы данные оставались в определённом регионе. GDPR ограничивает передачу персональных данных за пределы Европейской экономической зоны, если не приняты специальные меры защиты, и многие покупатели просто просят хостинг в ЕС, чтобы не поднимать этот вопрос. От этого зависят ваши облачные регионы, а также то, где хранятся ваши резервные копии и логи и где держат свои копии данных почтовый провайдер и инструменты поддержки.
- **Журналы аудита.** Нужно показать, кто что сделал, когда и откуда: в продукте, в инфраструктуре и в коде. Эти записи должно быть трудно изменить, и храниться они должны определённый срок.
- **Контроль доступа.** Сотрудники должны получать доступ только к тому, что нужно для их роли, со строгой аутентификацией и записью о каждой выдаче прав. Доступ к данным в продакшене должен быть редким, обоснованным и журналируемым.
- **Шифрование.** Шифрование данных при передаче и при хранении служит базовым уровнем. Сложнее вопросы о том, кто управляет ключами, как они ротируются и нужны ли некоторым клиентам собственные ключи.
- **Хранение и удаление.** Одни записи нужно хранить годами, другие удалять по запросу. Право на удаление по GDPR (right to erasure) распространяется на резервные копии, аналитические копии и логи, и именно здесь спотыкается большинство систем.

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

## Управляемые сервисы или своя эксплуатация

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

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

Есть и причины эксплуатировать что-то самим. Клиент может требовать развёртывания на своей площадке (on-premises) или в выделенной среде только для него. Нужного управляемого сервиса может не оказаться в требуемом регионе. Для HIPAA провайдер должен подписать соглашение о деловом партнёрстве (business associate agreement), и оно покрывает не каждый сервис из его каталога, поэтому проверьте список до выбора. Для данных платёжных карт обычный совет: вообще не пускать их в свои системы, используя размещённые поля (hosted fields) или токенизацию платёжного провайдера. Это сужает область действия PCI DSS до малой части стека.

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

## Выбирайте скучные, хорошо поддерживаемые инструменты

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

Полезные вопросы к каждому компоненту:

- Широко ли он используется, активно ли поддерживается и публикует ли уведомления о безопасности?
- Поддерживает ли он нужные вам меры контроля из коробки: шифрование, детальные права доступа, журнал аудита, единый вход (single sign-on)?
- Можно ли нанять людей, которые его знают?
- Публикует ли поставщик, если он есть, собственные отчёты о соответствии?

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

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

## Журналы и доказательства с первого дня

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

Закладывайте доказательства с самого начала:

- **Инфраструктура как код.** Каждое изменение окружения проходит через pull request с ревью, поэтому история и есть журнал изменений.
- **Защищённые ветки и обязательное ревью.** Репозиторий показывает, что никакой код не попал в продакшен без одобрения второго человека.
- **Центральные логи только на дозапись.** Логи приложения, инфраструктуры и доступа стекаются в одно место с ограниченными правами на запись и определённым сроком хранения.
- **События аудита в продукте.** Записывайте значимые для безопасности действия в самом продукте (входы, изменения прав, выгрузки, удаления) в структурированном виде, который можно показать клиентам.
- **Единый вход для сотрудников.** Одна учётная запись для всех внутренних инструментов превращает подключение и отключение сотрудников и пересмотр доступа в запрос, а не в поиски.

Где можно, не пускайте персональные данные в логи. Лог, полный email-адресов и токенов, становится второй копией вашей базы данных, с более слабой защитой и собственной проблемой сроков хранения.

## Оставьте стеку возможность меняться

Регулирование меняется, клиенты приносят новые требования, а крупная сделка может прийти вместе с регионом, где вы ещё не работаете. Стек должен уметь подстроиться без переписывания.

Помогает несколько привычек:

- Относитесь к региону и тенанту (tenant) как к конфигурации, а не к допущениям, зашитым в код, чтобы новое развёртывание было просто новым набором значений.
- Поставьте тонкий слой собственного кода между приложением и сервисами, которые вероятнее всего изменятся, например почтой, хранилищем и управлением учётными записями. Тогда замена поставщика затронет один модуль.
- Классифицируйте данные заранее. Зная, какие поля персональные, чувствительные или регулируемые, вы сможете применять правила шифрования, хранения и размещения к отдельным полям, а не ко всему подряд.
- Записывайте каждое существенное решение и требование, которое за ним стоит. Когда стандарт изменится, будет видно, каких решений это касается.

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

## С чего начать

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

Если сделать всё это правильно и рано, продукт сам по себе ещё не станет соответствовать требованиям: политики, обучение и процессы по-прежнему важны. Но когда придёт первый опросник от крупной компании, ответы на него уже будут в системе.

## Вопросы по статье

### Нужно ли соответствовать требованиям ещё до первого клиента?

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

### Если облачный провайдер соответствует требованиям, соответствует ли им наш продукт?

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

### На какой стандарт ориентироваться в первую очередь?

На тот, о котором спрашивают ваши клиенты. B2B-покупатели в США часто просят SOC 2, европейские чаще просят ISO 27001 и GDPR, а работа в здравоохранении или с платежами приносит с собой HIPAA или PCI DSS.

### Можно ли построить всё на open-source инструментах и всё равно пройти аудит?

Да. Аудиторы проверяют меры контроля и доказательства, а не названия брендов. Но если вы сами эксплуатируете инструменты, вам нужно ещё и показать, что они обновляются, находятся под мониторингом и резервируются.