Опубликовано: 21.09.2026 | Источник: Xakep.ru

Облако с защитой персональных данных в ВКР: архитектура, нагрузочные тесты и метрики по ФЗ-152

В марте 2026 года «Хакер» опубликовал обзор тарифа «ФЗ-152» у провайдера «Рег.облако»: автор не просто перечисляет характеристики инстансов, а проверяет их в тестах — как ведёт себя площадка, которую формально разрешено использовать для хранения персональных данных. Это важный сигнал для выпускников ИТ-специальностей. Ещё два-три года назад в дипломах писали «развернём на VPS», и этого хватало. Сегодня комиссия всё чаще спрашивает: где физически лежат ПДн, кто оператор, какой уровень защиты ЦОД, что с изоляцией арендаторов и как вы это проверяли. Разберём, как превратить этот кейс в защищаемую ВКР — без пересказа статьи и без «аналитики ради аналитики».

Три темы ВКР, которые вырастают из этого материала

Тема 1. Проектирование защищённого контура обработки ПДн на базе облачного провайдера

• Актуальность: статья показывает, что провайдеры начали выделять «юридически чистые» тарифы, но выбор площадки всё равно требует инженерного обоснования, а не маркетингового сравнения.
• Цель: разработать архитектуру сервиса, обрабатывающего ПДн, с разграничением ответственности между оператором и облачным провайдером.
• Задачи: классифицировать обрабатываемые данные; построить модель угроз по приказу ФСТЭК №21; выбрать уровень защищённости (УЗ-2/УЗ-3); спроектировать сегментацию сети и схему размещения.
• Структура: Глава 1 — нормативная база (152-ФЗ, приказ №21, ГОСТ Р 57580); Глава 2 — архитектурная схема, диаграммы развёртывания и последовательностей; Глава 3 — проверка соответствия и расчёт стоимости владения.

Тема 2. Сравнительная оценка облачных площадок для размещения ПДн

• Актуальность: обзор в статье — пример того, как выглядит корректная методика сравнения: одинаковые тесты, одинаковая конфигурация, зафиксированные условия.
• Цель: построить многокритериальную модель выбора провайдера (технические, юридические, экономические критерии).
• Задачи: сформировать набор критериев; определить веса методом анализа иерархий; провести замеры; оценить чувствительность результата.
• Структура: Глава 1 — обзор рынка и нормативных ограничений; Глава 2 — методика и матрица сравнения; Глава 3 — расчёты, диаграммы, вывод по выбору.

Тема 3. Методика нагрузочного тестирования инстансов с повышенными требованиями к защите

• Актуальность: включённые механизмы защиты (шифрование дисков, аудит, фильтрация трафика) почти всегда стоят производительности — и это надо измерять, а не предполагать.
• Цель: получить количественную оценку влияния средств защиты на производительность приложения.
• Задачи: спроектировать тестовый стенд; снять baseline без защиты; повторить замеры с шифрованием и аудитом; рассчитать деградацию по ISO/IEC 25010.
• Структура: Глава 1 — теория нагрузочного тестирования и метрики; Глава 2 — стенд, сценарии, инструменты (k6, Locust); Глава 3 — результаты, графики, выводы.

Аналитическая глава: как сравнивать, чтобы не получить «воду»

Самая частая ошибка — сравнивать облака по странице с тарифами. Комиссия это видит мгновенно. Опирайтесь на фиксированный набор критериев и обязательно разделяйте типы критериев: то, что можно измерить, и то, что можно только подтвердить документом.

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

Проектная часть: что должно быть на схемах

Проектная глава в таких ВКР — это не «текст про серверы», а набор артефактов. Минимально защищаемый комплект выглядит так:

• Диаграмма развёртывания (UML deployment): выделите зону ответственности провайдера и зону ответственности оператора ПДн. Именно здесь чаще всего ловится подмена модели: студент рисует одну коробку «облако» и считает, что ответственность размыта.
• Схема сегментации: публичная подсеть, приватная подсеть приложений, подсеть данных, точки выхода в интернет, средства фильтрации.
• Поток данных ПДн: где данные появляются, где обрабатываются, где хранятся, где уничтожаются. Отдельно — где шифруются (at rest / in transit).
• Инфраструктура как код: Terraform или Ansible-роли с описанием создаваемых ресурсов. Это сильно повышает вес работы: конфигурация воспроизводима, а не «я настроил руками».

# Фрагмент: описание ресурсов стенда (псевдокод, адаптируйте под свой стек)
resource "cloud_instance" "app" {
  zone           = "ru-central-1"
  disk_encrypted = true
  subnet_id      = private_subnet.id
  tags           = ["pdn", "protected-contour"]
}

resource "cloud_bucket" "pdn_store" {
  encryption = "kms"
  versioning = true
  public_access = false
}

Тестирование и метрики: где брать цифры для расчётов

Цифры берутся только из ваших замеров либо из открытых источников со ссылкой. Смешивать нельзя: если задержка измерена вами, а стоимость — из прайса, так и напишите, укажите дату и версию тарифа.

Нагрузочное тестирование

Сценарии стройте по трём профилям: базовый (средняя нагрузка), пиковый (2–3× от базового), деградационный (плавный рост до отказа). Для каждого фиксируйте: RPS, p50/p95/p99 задержки, долю ошибок, потребление CPU и памяти. Отдельный прогон — с выключенными и включёнными средствами защиты, чтобы получить честную цену безопасности.

Наблюдаемость

Минимум, который стоит показать в дипломе, — метрики, собираемые OpenTelemetry, и дашборд в Grafana. Это сразу отвечает на вопрос комиссии «а как вы это измеряли?» — есть инструмент, есть скриншот, есть сохранённый отчёт.

Отказоустойчивость

Проверка RTO/RPO — самый выигрышный раздел. Сценарий простой: вносите данные, делаете снимок, имитируете отказ, восстанавливаете, считаете фактическое время и объём потерянных данных. Разница между заявленным SLA и вашим фактическим RTO — отличный материал для выводов.

Чему вы научитесь на таком дипломе

• Обосновывать выбор стека и площадки ссылками на нормативку, а не на вкус.
• Работать с моделью угроз и уровнями защищённости — это востребовано на рынке ИБ и DevOps.
• Проводить воспроизводимые нагрузочные замеры и оформлять их в виде отчёта с графиками.
• Описывать инфраструктуру кодом и документировать архитектуру диаграммами по UML.
• Считать экономику внедрения: стоимость инстансов, лицензий, трудозатрат на сопровождение.

Часто задаваемые вопросы

Насколько сложно реализовать такую тему, если я не безопасник?

Проще, чем кажется. Ядро работы — архитектура и метрики, а не построение собственного СЗИ. Вы используете сервисы провайдера и проверяете, что они работают так, как заявлено. Достаточно понимать разницу между шифрованием канала и шифрованием диска.

Обязательно ли писать код?

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

Где взять тестовые данные, если речь о персональных данных?

Только синтетика. Сгенерируйте набор по структуре, близкой к реальной, но без настоящих ФИО и контактов. Это отдельно проговаривается в разделе о защите информации — и засчитывается как понимание рисков.

Нужно ли аттестовать стенд для диплома?

Нет. Аттестация — процедура для промышленной эксплуатации. В ВКР достаточно показать соответствие выбранного уровня защищённости требованиям и перечислить меры из приказа ФСТЕК №21.

Источник: «Рег.облако ФЗ-152». Тестируем облачные инстансы с повышенной защитой личных данных (опубликовано 2026-03-25)