OAZIS ESTATEНа главную
Главный тезис Архитектура Хостинг Доступы Совместная работа Безопасность План внедрения Бюджет Как это в OCC Устная защита Скачать материалы Назад к проекту
Тестовое задание 1 · безопасность

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

Полная документация: как защищены персональные данные клиентов Oasis — эшелонированная оборона, соответствие 152-ФЗ, доступы, бэкапы, аудит и реакция на инциденты.

Компания: Oasis · агентство недвижимости, Сочи Статус: проект архитектуры и план внедрения (без развёртывания на этом этапе) Соответствие: 152-ФЗ «О персональных данных»
0 · Главный тезис

Эшелонированная оборона

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

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

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

1

Сеть

Firewall, fail2ban, WAF на Nginx, доступ только через VPN, открыты только 443 и VPN.

2

Доступы

Least privilege: персональные ключи и учётки, роли, ничего лишнего по умолчанию.

3

Приложение

Изолированные окружения dev / stage / prod в отдельных Docker-контейнерах.

4

Шифрование

TLS в канале, LUKS на диске, шифрование чувствительных полей БД отдельным ключом.

5

Секреты

Ключи и пароли — в менеджере секретов (Vault / SOPS), никогда в коде и Git.

6

Резервные копии

Правило 3-2-1: 3 копии, 2 носителя, 1 офсайт, с регулярной проверкой восстановления.

7

Аудит

Журнал входов, доступа к ПДн и действий администраторов в защищённой зоне.

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

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-ФЗ

  1. ЦОД физически в РФ (локализация — ст. 18 ч. 5).
  2. Готовность подписать поручение на обработку ПДн (ст. 6 152-ФЗ) — без этого документа облако использовать нельзя.
  3. Желательно — аттестация ЦОД по требованиям ФСТЭК / 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. В прод (реальные ПДн) деплоит только админ после ревью"]
1

Разделение окружений dev / stage / prod

Разработчик живёт в dev на обезличенной БД.

2

Персональные доступы

Свой VPN-ключ и учётка в Git, не общий пароль. Уволили — отозвали именно его ключ.

3

Прод-деплой только через ревью

Прямого доступа к боевой БД у разработчика нет.

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

Self-hosted Git и code review

Инструмент — 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 не вставляем (см. раздел «Безопасность AI»).
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/901 577
Dev/StageHaedus 2/2/40677
Офсайт-бэкапYandex S3 (по объёму)~500
Домен + TLS (Let's Encrypt)~200 / 0
Итого~2 954 руб/мес

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

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

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

СтатьяТарифЦена
Сервер приложенийCastor 8/12/1502 877
Отдельная БД PostgreSQLDiadem 4/8/901 577
Dev/StageBrachium 2/4/60977
Офсайт-бэкап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 контактов потянет?»

Технически это очень мало, БД держит миллионы. Бюджет идёт на защиту, а не на мощности.

Материалы

Скачать документацию

Тот же документ в разных форматах — для печати, правок и вставки схем в Miro/Excalidraw.

Схемы записаны в формате Mermaid и уже отрисованы на этой странице. Чтобы получить картинки для Word/Miro/Excalidraw — скопируйте код каждой схемы на mermaid.live и экспортируйте PNG/SVG, либо откройте .html-версию и сохраните как PDF.

← Назад к проекту