Тестовое задание 1 — Архитектура безопасного сервера для командной разработки

Компания: Oasis (агентство недвижимости, Сочи)

Статус: проект архитектуры и план внедрения (без развёртывания на этом этапе)

Соответствие: 152-ФЗ «О персональных данных»

0. Главный тезис

У компании 80 000 контактов клиентов — это персональные данные (ФИО, телефоны, бюджеты сделок). По 152-ФЗ Oasis является оператором персональных данных, а значит обязан: хранить данные в РФ, ограничивать доступ, шифровать, вести журнал действий, уметь удалить данные по запросу субъекта и корректно реагировать на инциденты.

«Данные невозможно взломать» — так честный инженер не говорит: абсолютной невзламываемости не существует. Профессиональный ответ на тревогу заказчика — эшелонированная оборона (несколько независимых слоёв защиты, где пробой одного не открывает данные) плюс соответствие 152-ФЗ.

Семь слоёв защиты: сеть → доступы → приложение → шифрование → секреты → резервные копии → аудит. Отдельно — правила работы с AI (Claude и др.), потому что именно это самый частый незаметный канал утечки.

Эта модель — не теория: аналогичная архитектура уже работает в платформе OCC (мультиарендность, ролевой доступ, шифрование полей, зашифрованные офсайт-бэкапы, 2FA). См. раздел 8.

1. Схема архитектуры

1.1. Сетевые зоны

Принцип: наружу смотрит только тонкий периметр, данные — в самой глубокой закрытой зоне без выхода в интернет.

flowchart TB
    subgraph INET["Интернет"]
      U["Сотрудники Oasis (браузер, VPN)"]
      B24["Битрикс24"]
      GS["Google Sheets"]
      EXT["Другие источники (сайты, формы, телефония)"]
    end
    subgraph RU["РФ - дата-центр провайдера (152-ФЗ)"]
      subgraph EDGE["Зона периметра (DMZ)"]
        FW["Firewall + fail2ban"]
        VPN["VPN-шлюз (WireGuard)"]
        RP["Nginx reverse proxy: HTTPS/TLS, WAF, rate-limit"]
      end
      subgraph APP["Зона приложений (private)"]
        APPSRV["Сервер приложений: проекты команды, коннекторы интеграций"]
        GIT["Self-hosted Git (GitLab / Gitea)"]
        WORK["Изолированные окружения dev / stage / prod (Docker)"]
      end
      subgraph DATA["Зона данных (закрытая, без выхода в интернет)"]
        DB["PostgreSQL - единая БД ПДн (шифрованный диск)"]
        VAULT["Хранилище секретов (Vault / SOPS)"]
        LOGS["Журналы + аудит (SIEM)"]
      end
    end
    subgraph BACKUP["Офсайт-бэкапы (РФ, другой ЦОД)"]
      S3["S3-хранилище: шифрованные копии"]
    end
    U -->|только через| VPN
    VPN --> RP
    U -->|HTTPS| RP
    RP --> APPSRV
    RP --> GIT
    APPSRV --> WORK
    APPSRV --> DB
    APPSRV --> VAULT
    B24 -->|API, вебхуки| RP
    GS -->|API, чтение| APPSRV
    EXT -->|API| RP
    APPSRV --> LOGS
    DB -->|шифр. дамп по расписанию| S3
    WORK -.->|dev видит только обезличенные данные| DB

Наружу торчит только Nginx (шифрованный вход) и VPN. Приложения — за ними. Данные (БД, секреты, логи) — в самой глубокой зоне без выхода в интернет: до неё можно дотянуться только изнутри сервера. Бэкапы уезжают в другой ЦОД в зашифрованном виде.

1.2. Потоки данных из интеграций

flowchart LR
    B24["Битрикс24 (лиды, сделки, клиенты)"] -->|REST API + вебхук| ING["Слой интеграций (коннекторы)"]
    GS["Google Sheets (операционные таблицы)"] -->|Sheets API, чтение| ING
    TEL["Телефония / формы сайта"] -->|API| ING
    ING -->|нормализация + журналирование| DB[("PostgreSQL - единый источник правды")]
    DB --> PROJ["Проекты команды: инструменты, дашборды, отчёты"]
    DB --> BK["Бэкап (шифр.) в S3"]

Единым «источником правды» становится БД в РФ, а не Google Sheets. Битрикс и таблицы — источники, из которых данные забираются на ваш сервер. Так закрывается требование локализации ПДн россиян на территории РФ (ст. 18 ч. 5 152-ФЗ).

Примечание по Битрикс24. Коннектор работает одинаково с облачной и с коробочной версией Битрикс24 — через REST API и вебхуки, поэтому архитектура не меняется. Требование локализации ПДн выполняется в любом случае: первичная база — наш сервер в РФ. Уточнить, облако или коробка, нужно только для настройки прав сервисного аккаунта интеграции. Отдел продаж большой, но активных пользователей Битрикс немного — нагрузка на сервер небольшая, выбранной конфигурации хватает с запасом.

2. Где хостить: российский провайдер и почему

2.1. Обязательные критерии по 152-ФЗ

ЦОД физически в РФ (локализация — ст. 18 ч. 5).
Готовность подписать поручение на обработку ПДн (ст. 6 152-ФЗ) — без этого документа облако использовать нельзя.
Желательно — аттестация ЦОД по требованиям ФСТЭК / 152-ФЗ (соответствие уровню защищённости УЗ).

Для 80 000 обычных контактов (без спец. категорий — здоровье, судимости) уровень защищённости обычно УЗ-3 (иногда УЗ-4). Точный уровень определяется «моделью угроз» на этапе внедрения.

2.2. Матрица провайдеров (РФ, 152-ФЗ)

Провайдер	152-ФЗ / локализация	Плюсы	Минусы	Цена
ufo.hosting (текущий)	ЦОД в РФ (Country Russia) — локализация выполнена. Запросить поручение на обработку ПДн + аттестат/готовность под ФЗ-152	Уже освоен, честные цены, NVMe, ECC-память, сеть 10 Gbps, Linux/Windows	VPS с самостоятельным управлением: меры уровня защищённости (шифрование диска, доступы) реализуем сами	577-16 000 руб/мес
Yandex Cloud	Да, аттест. сегмент, KMS/IAM	Managed PostgreSQL, S3, ключи (KMS), рядом YandexGPT	Дороже, оплата по потреблению	Средняя-выше
Selectel	Да, аттест. облако под ФЗ-152	Гибко: VPS/выделенные/облако, S3, managed БД	Требует настройки	Средняя
Timeweb Cloud	Есть облако под 152-ФЗ	Дёшево, простой старт	Меньше enterprise-функций	Низкая
RuVDS	ЦОД аттестованы (в т.ч. ФСТЭК)	Готовые «152-ФЗ» тарифы	Базовый набор	Низкая

2.3. Рекомендация: остаёмся на ufo.hosting

ufo.hosting подходит: ЦОД в РФ (локализация ПДн выполнена), NVMe + ECC-память, сеть 10 Gbps, честные цены. От провайдера дополнительно запрашиваем: (1) поручение на обработку ПДн (ст. 6 152-ФЗ), (2) подтверждение расположения ЦОД в РФ, (3) аттестат/модель угроз при наличии. Меры уровня защищённости (шифрование диска LUKS, ограничение доступов, firewall) реализуем сами — на VPS это наша зона ответственности.

Панель управления (Vesta/Hestia/ISPmanager и т.п.) — дополнительная поверхность атаки; для безопасного контура управляем сервером через SSH + Docker без публичной панели. Если панель нужна — бесплатная HestiaCP, закрытая за VPN.

Git-сервер — Gitea (лёгкий, ~1 ГБ памяти), а не GitLab (требует 4+ ГБ только на себя): помещается в бюджет и живёт на том же сервере.

2.4. Конкретный выбор тарифа ufo.hosting

Данных мало (80k контактов), поэтому выбор определяется памятью под приложение + БД + Docker + Gitea, а не объёмом диска.

Роль сервера	Тариф	Конфигурация	Цена (акция / обычная)
Прод (app + PostgreSQL + Docker + Gitea)	Okul	16 vCore / 16 ГБ ECC / 210 ГБ NVMe	5 000 / 5 500 руб/мес
Dev + Stage (изолированная разработка)	Brachium	2 vCore / 4 ГБ / 60 ГБ NVMe	977 / 1 080 руб/мес
Эконом-прод (старт, если режем бюджет)	Diadem	4 vCore / 8 ГБ / 90 ГБ NVMe	1 577 / 1 740 руб/мес
Эконом-dev	Haedus	2 vCore / 2 ГБ / 40 ГБ NVMe	677 / 750 руб/мес
Офсайт-бэкап (2-й узел, другой ЦОД)	Naos или Yandex S3	1 vCore / 1 ГБ / 25 ГБ	577 руб/мес (или S3 по объёму)

Офсайт-бэкап лучше в S3-хранилище (Yandex Object Storage, ru-central1) — платим по объёму (для 80k контактов дамп крошечный), либо второй маленький узел ufo (Naos) в другой локации как зеркало. Цены акционные (обычные выше) — на защите честно уточнить «акция/обычная».

3. Модель доступов

Принцип: least privilege (минимум необходимого). Новый разработчик по умолчанию не видит ПДн клиентов вообще.

3.1. Роли

Роль	Что может	Доступ к ПДн клиентов
Владелец / администратор ИБ	Всё, управление доступами и ключами	Полный (по регламенту)
Руководитель-разработчик	Свои проекты, деплой в stage	Только обезличенные / по явному праву
Разработчик (новый)	Код, dev-окружение	Нет. Только обезличенные тестовые данные
Аналитик / менеджер	Дашборды, отчёты	Агрегаты, без выгрузки «сырых» ПДн
Интеграции (сервисные аккаунты)	Только свой канал (Битрикс/Google)	По минимуму, отдельные ключи

3.2. Как выдать доступ новому разработчику без чувствительных данных

flowchart LR
    NEW["Новый разработчик"] --> VPN2["1. Доступ в VPN (персональный ключ)"]
    VPN2 --> DEVENV["2. Только dev-окружение (изолированный контейнер)"]
    DEVENV --> MASK["3. Обезличенная копия БД: телефоны/ФИО заменены на фейковые"]
    MASK --> PR["4. Изменения через ветку + code review"]
    PR --> PROD["5. В прод (реальные ПДн) деплоит только админ после ревью"]

Разделение окружений dev / stage / prod. Разработчик живёт в dev на обезличенной БД.
Персональные доступы (свой VPN-ключ и учётка в Git, не общий пароль). Уволили — отозвали именно его ключ.
Прод-деплой только через ревью: прямого доступа к боевой БД у разработчика нет.

4. Совместная работа над проектами

Инструмент — self-hosted Git (GitLab или Gitea) на вашем же сервере в РФ. Не GitHub (код и случайные секреты уезжают за рубеж).

flowchart TB
    F1["feature/иван-отчёты"] --> PR1["Merge Request + review"]
    F2["feature/пётр-битрикс"] --> PR2["Merge Request + review"]
    PR1 --> MAIN["main (защищённая ветка = прод)"]
    PR2 --> MAIN
    MAIN --> STAGE["Автодеплой в stage (проверка)"]
    STAGE --> PRODDEPLOY["Ручной деплой в prod (подтверждает админ)"]

Версионность: каждое изменение в отдельной ветке, история хранится, можно откатиться.
Изоляция: каждый проект/окружение в своём Docker-контейнере.
Кто что меняет: ветку main напрямую не трогает никто, всё через Merge Request с ревью, права по ролям.
Правила AI: реальные ПДн клиентов в Claude/внешние LLM не вставляем (см. 5.7).

5. Безопасность

5.1. Шифрование

В канале: HTTPS/TLS везде, HSTS, современные шифры, плюс VPN между сотрудником и сервером.
На диске: шифрование диска сервера (LUKS) + шифрование чувствительных полей БД (телефоны, паспортные данные) отдельным ключом. Украденный дамп без ключа — это мусор.
Бэкапы шифруются перед отправкой в S3.

5.2. Резервные копии (правило 3-2-1)

3 копии, 2 разных носителя, 1 офсайт. Автобэкап БД каждые N часов, хранение локально + в S3 другого ЦОД. Обязательна регулярная проверка восстановления (невосстановленный бэкап — не бэкап).

5.3. Журнал действий (аудит)

Логируем входы/выходы, доступ к ПДн, изменения данных, действия администраторов, деплои. Логи в закрытой зоне, защищены от изменения.

5.4. Где хранятся ключи и пароли к интеграциям

Никогда в коде и не в Git (перед коммитом — автосканер секретов). Секреты — в менеджере секретов (HashiCorp Vault или зашифрованный SOPS) или переменных окружения. У каждой интеграции свой ключ с минимальными правами.

5.5. Что делаем при утечке

flowchart LR
    A["Обнаружение (алерт/аудит)"] --> B["Изоляция: отключить канал, заблокировать доступ"]
    B --> C["Ротация всех затронутых ключей/паролей"]
    C --> D["Оценка: какие ПДн, сколько субъектов"]
    D --> E["Уведомление РКН в 24 часа"]
    E --> F["Восстановление из чистого бэкапа + разбор"]

С 1 сентября 2022 оператор обязан уведомить Роскомнадзор об инциденте с ПДн в течение 24 часов (о принятых мерах — в течение 72 часов).

5.6. Что делаем при увольнении сотрудника

Чек-лист offboarding в тот же день: отзыв VPN-ключа, блокировка учётки в Git и на сервере, ротация общих паролей/ключей, проверка логов на аномальную выгрузку перед уходом, изъятие/шифрование рабочего устройства.

5.7. Безопасность AI (Claude и др.)

Главный незаметный канал утечки. Правила:

Не отправляем реальные ПДн клиентов во внешние LLM (Claude, ChatGPT) — это трансграничная передача за рубеж, риск по 152-ФЗ.
Для AI поверх данных клиентов — обезличивание/псевдонимизация перед отправкой либо российские LLM (YandexGPT, GigaChat) внутри контура РФ.
AI для кода — свободно (нет ПДн). AI для клиентских данных — только по правилам выше.

5.8. Сетевая защита периметра

Firewall (открыты только 443 и VPN), fail2ban (блок брутфорса), WAF на Nginx, rate-limit, регулярные обновления ОС/пакетов. SSH — только по ключам, без пароля, доступ по VPN.

6. Пошаговый план внедрения

Фаза	Что делаем	Итог	Ориентир
0. Обследование	Инвентаризация: какие ПДн, где лежат (Битрикс, Sheets), кто имеет доступ	Понятна текущая картина	3-5 дн
1. Документы 152-ФЗ	Модель угроз, определение уровня защищённости, политика обработки ПДн, согласия клиентов	Юридическая база готова	1-2 нед
2. Инфраструктура	Аренда сервера в РФ, поручение на обработку, сетевые зоны, firewall/VPN, шифрование диска	Защищённый периметр	1 нед
3. Данные и интеграции	PostgreSQL, коннекторы Битрикс/Google, единый источник правды, локализация ПДн в РФ	Данные стекаются безопасно	1-2 нед
4. Доступы и Git	Self-hosted Git, роли, VPN-ключи, dev/stage/prod, обезличенная dev-БД	Команда может работать	1 нед
5. Бэкапы и аудит	Автобэкап 3-2-1, проверка восстановления, логирование, Vault для секретов	Устойчивость + прозрачность	1 нед
6. Регламенты	Onboarding/offboarding, план реакции на инцидент, правила AI	Процессы, а не только техника	3-5 дн
7. Приёмка	Проверка по чек-листу, пробное восстановление, обучение команды	Запуск	2-3 дн

7. Бюджет (конкретика по ufo.hosting, рубли в месяц, акционные цены)

Сценарий А — Эконом (старт):

Статья	Тариф	Цена
Прод (app+БД+Docker+Gitea)	Diadem 4/8/90	1 577
Dev/Stage	Haedus 2/2/40	677
Офсайт-бэкап	Yandex S3 (по объёму)	~500
Домен + TLS (Let's Encrypt)	—	~200 / 0
Итого		~2 954 руб/мес

Сценарий Б — Рекомендуемый:

Статья	Тариф	Цена
Прод (app+БД+Docker+Gitea)	Okul 16/16/210	5 000
Dev/Stage	Brachium 2/4/60	977
Офсайт-бэкап	Yandex S3	~1 000
Домен + TLS	—	~200 / 0
Итого		~7 177 руб/мес

Сценарий В — Масштаб (отдельная БД, рост нагрузки):

Статья	Тариф	Цена
Сервер приложений	Castor 8/12/150	2 877
Отдельная БД PostgreSQL	Diadem 4/8/90	1 577
Dev/Stage	Brachium 2/4/60	977
Офсайт-бэкап	Yandex S3	~1 500
Домен + TLS	—	~200 / 0
Итого		~7 131 руб/мес (запас роста: Alphard/Electra/Intercrus до 16 000)

VPN, Git (Gitea), менеджер секретов (Vault OSS) — 0 руб (self-hosted на этих же серверах).

Вывод: полноценная защищённая инфраструктура под 80 000 контактов — от ~3 000 руб/мес (эконом) до ~7 200 руб/мес (рекомендуемый). Это несопоставимо дешевле штрафов за утечку ПДн (для юрлиц в 2024-2025 — вплоть до оборотных за повторные нарушения) и репутационного ущерба в недвижимости.

8. Как это уже работает в OCC (доказательство, не теория)

Требование Oasis	Как реализовано в OCC
Изоляция данных между пользователями	Мультиарендность по company_id + ролевой доступ через PermissionService
Ролевая модель	12 ролей, доступ описан матрицей и проверяется на сервере, а не в интерфейсе
Шифрование чувствительных полей	Fernet-шифрование реквизитов выплат при хранении (отдельный ключ)
Защита входа	bcrypt-пароли, опциональная 2FA (TOTP), лимит попыток, блок IP, honeypot, device-tracking
Бэкапы	Шифрованные pg_dump каждые N часов, офсайт в S3 (ru-central1), ротация
Секреты вне кода	Только в переменных окружения (вне git) + автосканер секретов перед коммитом
Защита канала	HTTPS/HSTS, security-заголовки, HttpOnly+SameSite+Secure cookie
Защита от инъекций	ORM с параметризованными запросами
Локализация ПДн	Серверы и БД в РФ, минимизация PII, удаление по запросу

9. Тезисы для устной защиты

«Можно гарантировать, что не взломают?» — Абсолютной гарантии нет ни у кого. Даю эшелонированную оборону: 7 слоёв, где пробой одного не открывает данные, плюс быстрое обнаружение и восстановление.
«Почему сервер в РФ?» — 152-ФЗ ст. 18 ч. 5: первичная БД с ПДн россиян обязана быть в РФ. Плюс поручение на обработку с провайдером.
«Как новый разработчик не увидит клиентов?» — Изолированное dev-окружение на обезличенной БД, в прод не деплоит, ПДн физически недоступны.
«Если сотрудник уволится / данные утекут?» — Чек-листы: отзыв доступов в тот же день, ротация ключей; при утечке — изоляция, ротация, уведомление РКН в 24 часа, восстановление из чистого бэкапа.
«Ваши AI-инструменты (Claude) не сольют данные?» — Реальные ПДн во внешние LLM не отправляем; для клиентских данных — обезличивание или российские LLM внутри контура.
«80 000 контактов потянет?» — Технически это очень мало, БД держит миллионы. Бюджет идёт на защиту, а не на мощности.

Приложение. Как открыть схемы

Схемы записаны в формате Mermaid. В этом .html они уже отрисованы браузером. Чтобы получить картинки отдельно: открой .md в VS Code (расширение Markdown Preview Mermaid) или на GitHub; либо скопируй код каждой схемы (блок между тройными обратными кавычками с mermaid) на https://mermaid.live и экспортируй PNG/SVG для вставки в Word/Miro/Excalidraw. Этот файл .html открывается в браузере со всеми отрисованными схемами и через «Сохранить как PDF» даёт готовый документ.