Решение для безопасного управления секретами Deckhouse Stronghold от компании «Флант»  получило сертификат соответствия ФСТЭК России № 5038 от 10 февраля 2026 года. Документ подтверждает, что новая редакция продукта — Deckhouse Stronghold Certified Security Edition — соответствует требованиям технических условий и приказа ФСТЭК России № 76 от 2 июня 2020 года по 4-му уровню доверия.

Сертифицированную редакцию Deckhouse Stronghold смогут внедрять организации, для которых обязательно использование продуктов, прошедших сертификацию ФСТЭК России. Речь идёт о государственных компаниях и госкорпорациях, банках, федеральных и региональных органах исполнительной власти, а также об организациях, работающих с объектами критической информационной инфраструктуры.

Deckhouse Stronghold — решение для централизованного хранения и безопасного управления жизненным циклом секретов. Продукт обеспечивает защищённую доставку секретов, централизованный аудит и управление доступами, а также контроль над созданием, ротацией и отзывом секретов. Решение может использоваться в любых инфраструктурах, включая публичные и частные облака, а также закрытые контуры с повышенными требованиями к информационной безопасности. Deckhouse Stronghold полностью совместим с API HashiCorp Vault, имеет интерфейс на русском языке и работает на российских операционных системах.

Deckhouse Stronghold Certified Security Edition реализует функциональные возможности уровня HashiCorp Vault Enterprise, включая межкластерную репликацию данных, пространства имён, автоматическое резервное копирование данных по заданному расписанию, встроенное безопасное автоматическое распечатывание хранилища без использования внешних сервисов или KMS, поддержку внешних аппаратных модулей безопасности и двойное шифрование данных. В том числе поддерживаются российские криптографические алгоритмы «Кузнечик» и «Магма» в соответствии с ГОСТ Р 34.12-2018.

«Мы ставили перед собой задачу создать не просто сертифицированное решение, а полноценное enterprise-хранилище секретов, которое можно использовать в реальных production-средах с повышенными требованиями к информационной безопасности. Deckhouse Stronghold Certified Security Edition изначально разрабатывался в соответствии с требованиями безопасной разработки программного обеспечения по ГОСТ Р 56939-2024. Сертификация ФСТЭК России подтверждает, что продукт полностью соответствует требованиям регулятора и предлагает заказчикам функциональные возможности уровня HashiCorp Vault Enterprise», — отметил Владимир Девятайкин, менеджер продукта Deckhouse Stronghold компании «Флант».

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

В дальнейшем планируется активное развитие редакции Certified Security Edition, включая расширение функциональности performance-репликации, а также прохождение оценки влияния среды функционирования на средство криптографической защиты информации в рамках встраивания СКЗИ в Deckhouse Stronghold.

— Формально — да, — сказал он наконец. — По документам я оперативник по сбору мифов.

Она чуть приподняла бровь, но улыбки на ее лице не появилось. Если бы женщина не умела хорошо контролировать эмоции, то в Агентстве она бы надолго не задержалась.

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

— Хорошо вы устроились — женщина хмыкнула. — Получается, что вы главный по сплетням?

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

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

— Алина Ветрова. Эксперт отдела. В наших отчетах мифы обычно заканчиваются простоями и деньгами. Иногда репутацией. Реже судами. Она посмотрела на него внимательнее.

— Теперь ваша очередь — как мне к вам обращаться?

— Илья Горин, — представился он. — Можно просто Илья.

— Хорошо, значит будем работать так. Вы приносите легенду, как обычно ее подают люди. Я разбираю, где в этом правда, где подмена терминов, а где просто страхи вперемешку с неуверенностью. И потом мы пишем отчёт так, чтобы его понял любой, кто отвечает за проект. Итак, что у нас сегодня на повестке дня?

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

— Дело №001. “Бэкап на том же сервере”.

Алина медленно выдохнула.

— Ну, это классика, куда без кривых бэкапов, — сказала она, уже перелистывая первые страницы. — Хотя простой эту тему язык не повернется назвать.

Сводка по инциденту

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

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

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

[ФРАГМЕНТ РАЗГОВОРА | 08:29]

— Знаешь, что самое частое? — Игорь с легкой усмешкой отвернулся от ноутбука, — Люди искренне гордятся папкой самим фактом существования папки backups. Показывают её почти с облегчением. Мол, вот, мы не из тех, кто забывает про резервные копии.

Алина не отрывалась от распечатки, но слушала внимательно.

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

Игорь повернулся к ней.

— Потому что считают, что вопрос закрыт?

— Потому что слово «бэкап» звучит как нечто завершеное, — ответила Алина. — Сделал копию и значит застраховался. А дальше начинаются нюансы. Ведь создать копию и обезопасить файлы — это не одно и то же.

Игорь задумчиво кивнул.

— Обеспечить безопасность — значит поселить копию отдельно на другом сервере?

Алина наконец подняла взгляд.

— Безопасность — это когда копия переживает потерю сервера. Когда она существует независимо от него. И когда ты уже хотя бы один раз восстановился из неё. Всё остальное — это удобство. Полезно, но ничего не гарантирует

Игорь тихо выдохнул.

— То главная ошибка в том, что папку backups почти на каком-то религиозном уровне считают последней линией обороны.

— Именно, — сказала Алина. — И это мы и должны объяснить. Чтобы человек после прочтения задал себе один неприятный вопрос.

— Какой?

— Если сервер исчезнет сегодня, что у тебя останется завтра?

Улики

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

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

Третий фактор риска — неполнота или некорректность резервной копии. Формальное наличие архивов не означает их пригодность к восстановлению. Возможна утрата отдельных компонентов (дампов баз данных, конфигурационных файлов, ключей доступа), повреждение архивов или отсутствие регулярной проверки процедуры восстановления. В таких условиях процесс восстановления требует ручной доработки и не гарантирует результат.

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

Показания свидетеля

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

— Я сразу скажу: бэкапы у нас были, честное слово. Я сам их настраивал.

Игорь молча кивнул, давая понять, что услышал. Алина сделала пометку в блокноте, не поднимая головы.

— Где вы их хранили? — спросила она ровно.

— На сервере в отдельной папке, под рутом. Мне казалось, так безопаснее: веб-сервер туда не полезет, права другие.

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

— Что произошло дальше? — Алина всё ещё не смотрела на него.

Потерпевший на секунду замолчал, будто прокручивал события заново.

— Сначала всё стало вести себя странно. Медленно, с ошибками. Потом я потерял доступ к админке. Через некоторое время сервер просто перестал отвечать. Провайдер сказал, что идет проверка, попросили подождать.

Игорь заметил, как в этот момент у человека дернулся уголок рта.

— И вы решили восстановиться из копии, — констатировал оперативник.

— Да. Это было первое, что пришло в голову, — кивнул потерпевший. — Я подумал: ладно, неприятно, но у нас же есть бэкапы. Сейчас зайду и…

Он запнулся и коротко выдохнул.

— И понял, что мне некуда заходить. Копия есть, но она внутри сервера. А сервер для меня  закрытая дверь. Это было… — он запнулся, пытаясь подобрать подходящее, — неприятно. Очень.

Алина наконец подняла взгляд.

— Что в итоге помогло?

Потерпевший горько усмехнулся,.

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

В кабинете повисла пауза.

Игорь закрыл папку и посмотрел на Алину.

— Этого будет достаточно. Я думаю, что можем закругляться и переходить к выводам.

Служебная памятка

[ПАМЯТКА | ГРИФ: «ДЛЯ ВНУТРЕННЕГО ПОЛЬЗОВАНИЯ»]
Резервная копия рассматривается не как сам по себе файл, а как подтвержденная возможность восстановления системы. При отсутствии хотя бы одной успешной процедуры тестового восстановления резервное копирование следует считать непроверенным. В этом случае оно существует формально, но не подтверждено как рабочий инструмент.

[ПАМЯТКА | ПОМЕТКА ЭКСПЕРТА]
Размещение копий в различных директориях одной и той же машины не снижает совокупный риск. Использование разных физических дисков в пределах одного сервера также не исключает критические сценарии отказа. Отдельная точка хранения требуется не из соображений удобства, а для обеспечения независимости от инцидентов, затрагивающих доступность и целостность основной среды.

[ПАМЯТКА | СЛУЖЕБНАЯ ФОРМУЛИРОВКА]
Термин отдельное хранение означает способность резервной копии сохраниться при полной утрате сервера. Если копия утрачивается или становится недоступной одновременно с основным узлом, она классифицируется как локальная и не может рассматриваться в качестве полноценного механизма страхования рисков.

[ПАМЯТКА | К ПРОТОКОЛУ РАССЛЕДОВАНИЯ]
Контрольный вопрос при оценке стратегии резервного копирования формулируется следующим образом: возможно ли восстановление проекта в течение следующего рабочего дня при полной утрате текущего сервера и отсутствии доступа к нему? При отрицательном ответе обсуждение деталей размещения архивов теряет приоритетное значение.

[ПАМЯТКА | ПРО ВРЕМЯ]
Резервное копирование должно обеспечивать достаточную глубину хранения для отката к корректному состоянию. Ошибки и искажения данных часто выявляются с задержкой. При ограниченной истории копий существует риск сохранения исключительно актуальных, но уже повреждённых версий данных.

Заключение экспертов

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

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

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

Закрытие дела №001

Бэкап на том же сервере удобен, но не является полноценной страховкой от инцидента, потому что находится в той же зоне риска. Полноценная страховка начинается там, где копия живёт вне сервера.

[ДОПОЛНЕНИЕ К ДЕЛУ | ПОМЕТКА РЕДАКТОРА]

Я очень прошу помощи у сообщества, какая софтина больше всего подходить для таких задач.

А именно - установить виндовс на NVME M2, потом с помощью программы создать резервную копию со всеми настройками, паролями, и сбросить этот образ на файлопомойку. А в случае форсмажора быстренько из образа восстановить систему. Как раньше на жестком диске я делал с помощью старого доброго Акронис. Так вот подытожу - чем заменить мне для этой задачи проверенный временем Акронис?