Восстановление данных *

Я работаю директором по цифровой трансформации. И каждый раз, когда собираю бюджет, вижу одну и ту же картину: на ИТ денег мало, на ИБ — ещё меньше. При этом требования растут, угрозы множатся, а формулировка от бизнеса : «сделай так, чтобы работало удобно, из любого места и без пароля желательно, ну и не ломалось».

Как и многие я ищу идеальную формулу: минимум вложений → максимум защиты. Не «купить всё и сразу», не «внедрить SOC за 10 миллионов в год», а именно базовую базу по ИТ и ИБ, которая закрывает 80% рисков и не требует армии сотрудников для ее поддержания.

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

ИБ‑гигиена — это не SOC, не «киберщит» и не магический короб. Это несколько приземлённых вещей: MFA, антивирус, бэкапы, ролевая модель и обучение людей. Всё это стоит сильно дешевле одного серьёзного инцидента.

Как только очередной вендор обещает «убить нативные тулзы PostgreSQL», где-то устало вздыхает DBA. Попытка сделать бэкап PostgreSQL «лучше самого PostgreSQL» — это изначально неверная постановка задачи. 

Универсальный файловый агент не притворяется глубоко PostgreSQL-aware решением. Его задача в другом: взять нативные механизмы СУБД и превратить их в управляемый и наблюдаемый процесс на уровне всей инфраструктуры.

Вокруг такого подхода обычно сразу возникают неприятные, но правильные вопросы. Кто отвечает за консистентность? Где на самом деле живет PITR? Что будет, если потеряется WAL-сегмент? Можно ли восстановить одну таблицу, а не весь инстанс? И зачем вообще нужен внешний слой поверх pg_probackup, если у PostgreSQL уже есть свои зрелые инструменты?

Под катом — честный разговор о границах ответственности между PostgreSQL и внешней платформой.

Олды, возможно, помнят серию постов о «Самураях» — российской разработке защищённых флэшек 2011-2013 годов. Путь «Самурая» вскоре после этого прервался, но не закончился: 10 лет спустя, «Самураи» — это уже не одни флэшки, а целая линейка систем уничтожения данных, по нажатию кнопки стирающих от ноутбука до серверной стойки. И это только часть железных и софтверных решений для по шифрованию, анонимизации и уничтожению данных, которые с тех пор начали выпускаться в России: от защищённых флэшек до защищённых жёстких дисков, защищённых анонимные смартфоны «с секретом» и утилизаторов жёстких дисков и SSD. За прошедшие 15 лет выяснилось, что системы защиты и безвозвратного уничтожения данных — это целая отрасль с огромным спросом и массой востребованных решений.

А ещё — возможно, последняя незарегулированная отрасль российского IT: оказывается, разработка тревожных кнопок моментального уничтожения данных не требует никаких лицензий ФСБ, сертификаций ФСТЭК или реестров Роскомнадзора, потому что, согласно 152-ФЗ, оператор обязан уничтожать персональные данные необратимо. Т.е. с точки зрения закона о персональных данных, функция безвозвратного уничтожения данных — это тоже защита данных. Таким образом, на пересечении законодательной благосклонности и пользовательского спроса, образовалась одна из самых необычных ниш российского ИТ, с которой я сталкивался.

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

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

Проблема публичного идентификатора

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

Однако СНИЛС — это не просто номер. Это ключевой идентификатор гражданина в системе межведомственного взаимодействия. В связке с фамилией и инициалами он позволяет:

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

В этой статье на примере ПО «Береста» мы разберём, как устроен компонент «Монитор состояния» и какую роль он играет в обеспечении отказоустойчивости инфраструктуры резервного копирования.

Архитектура и место монитора в системе

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

На рис. 1 показано логическое взаимодействие компонентов системы.

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

В инфраструктурах среднего и крупного масштаба Data Domain давно используется как стандартное целевое хранилище для резервного копирования. Поэтому при развитии «Бересты» для нас было важно реализовать корректную и полноценную поддержку работы с этой платформой через DDBoost.

Разберёмся, как это устроено.

Что такое Data Domain и почему он используется для бэкапа

Dell EMC Data Domain — это специализированная платформа для резервного копирования и архивного хранения данных. По сути, это целевое хранилище для бэкапа: на него сохраняются данные из файловых систем, виртуальных сред и баз данных.

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

Это даёт два очевидных эффекта:

·      существенно сокращается объём хранения;

·      снижается нагрузка на сеть при регулярных инкрементальных копированиях.

Дополнительно используется компрессия и оптимизация структуры хранения под задачи резервного копирования и восстановления данных.

Почему NFS — не самый эффективный вариант

Data Domain может использоваться как обычная файловая система по NFS. Но при таком подходе вся логика дедупликации остаётся на стороне хранилища.

Это означает:

·      по сети передаются полные объёмы данных;

·      дедупликация выполняется уже после приёма;

·      растёт нагрузка на сеть и увеличивается окно резервного копирования.

Для крупных инфраструктур такой подход быстро становится узким местом.

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

Поэтому я предлагаю перевод статьи о том, как работает правило 3-2-1, почему оно перестало быть универсальным, какие уязвимости оставляет в современных средах и как эволюционировало, чтобы соответствовать современным требованиям к защите данных.

Правило резервного копирования 3-2-1 на протяжении многих лет считалось золотым стандартом защиты данных. Его привлекательность заключалась в простоте: хранить три копии данных, размещать их на двух разных типах носителей и держать одну копию вне основной площадки.
В течение многих лет такой подход обеспечивал практичную и надёжную защиту в эпоху, когда резервное копирование в основном было локальным, а угрозы — значительно менее сложными.

Но это было когда-то.

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

Представим ситуацию. У нас на руках есть устройство на базе SoC (чипсет) от Qualcomm в аварийном режиме – emergency download, edl, USB\VID_05C6&PID_9008. Для доступа к памяти устройства, чтобы провести его восстановление, требуется программер. В сети их много и большинство называется просто «prog_firehose_ddr.elf» без указания модели устройства, для которого их разрабатывали. Можно пробовать загружать по одному и проверять подходит или нет, но это очень долго. Куда быстрее и проще проанализировать список из нескольких программеров и проверить на соответствие только несколько, наиболее подходящих из них.

TL;DR: Вы покупаете дорогие security-решения, но при инциденте всё равно паника и хаос? Проблема не в инструментах, а в том, что делаете не на своём уровне зрелости. Разбираем 6 уровней развития ИБ — от «всё на общих паролях» до «безопасность как конкурентное преимущество».

Типичная история: компания тратит на ИБ миллионы, покупает модные SIEM/DLP/EDR, нанимает специалистов, проводит аудиты. А потом прилетает шифровальщик — и выясняется, что бэкапы лежат на том же сервере, доступы раздавали «как у Васи, чтобы не бегать», а план реагирования существует только на бумаге.

Проблема одна: делаете не на своём уровне зрелости.

Зрелость ИБ — это не про стандарты ISO и не про сертификаты SOC2. Это способность не развалиться от типовых проблем и при этом не убить бизнес параноидальным контролем. Это баланс между «нас точно взломают» и «давайте проверять каждый клик сотрудника».

Что внутри статьи:

5 уровней зрелости — от уровня 0 («пароли в общем чате», этот уровень вообще не считаем за уровень) до уровня 5 («ИБ как фактор выигрыша тендеров»)

Портреты компаний на каждом уровне — узнаете себя в первом абзаце

Типичные факапы и почему они происходят именно на вашей стадии

Инструменты и процессы — какие имеют смысл на каждом этапе

Никаких переводов западных фреймворков. Только то, что работает в наших реалиях.

Главный месседж: нормально быть на уровне 2-3, если вы там стабильны и честны с собой. Гораздо хуже притворяться зрелыми на бумаге и гореть на практике. Модель зрелости — это не экзамен на оценку.

Под катом — разбор уровней с примерами, рисками и конкретными действиями. Если хоть раз ловили себя на мысли «мы вроде что-то делаем, но непонятно, достаточно ли этого» — welcome.

Привет Хабр!

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

Новая версия Easy Disk Checker - многофункциональной программы для работы с жёсткими дисками, SSD и флешками на «физическом» с точки зрения OS Windows уровне, независимо от файловой системы или её отсутствия. Проверка секторов, анализ SMART а том числе Seagate FARM, определение фейковых флешек, чтение и запись образов, клонирование, восстановление разметки и многое другое.

Привет, Хабр! На связи снова Иван Глинкин, руководитель группы аппаратных исследований из команды Бастиона. 

«Флешка с кодовым замком», «флешка с аппаратным шифрованием», «зашифрованный USB-накопитель», наконец, эталонное название — «криптографический модуль» (Cryptographic Module). У криптофлешки aka encrypted USB много имен, но суть от этого не меняется.

Задача такого устройства — защитить чувствительную информацию от несанкционированного доступа на программно-аппаратном уровне: при помощи шифрования, механизмов антивскрытия и прочих «семи печатей». Однако так ли надежны эти защищенные USB-накопители, как принято считать, или это всё от лукавого? 

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

Результаты получились интересными. Подробности — под катом.

Четыре года назад у меня Хабре была статья про цифровой недокументированный формат кардиограммы, структуру которого я попытался разгадать по максимуму. В результате мне удалось увидеть формы сигналов сторонними программными инструментами, в том числе и в аудиоредакторе. Более того, я разобрался, как вычислить недостающие 4 отведения, так как в файле было записано только 8 каналов. И в целом мне повезло с форматом представления цифровых данных: никаких там ADPCM 12 бит и близко не было.

В этом году пару месяцев назад мне пришлось столкнуться ещё с одним частным форматом кардиограммы. На этот раз речь пойдёт о мобильном кардиографе белорусской компании «Кардиан». Основная его аппаратная часть – коробка с электроникой, куда подключаются через разъём электроды для снятия кардиограммы. Дополнительная часть – устройство со смартфоном на андроиде, оснащённое термопринтером. Обе части соединяются через Bluetooth. В основной части стоит современный популярный микроконтроллер STM32, но данная статья не про обратную разработку электроники.

Обзор многофункциональной программы для работы с жёсткими дисками, SSD и флешками на «физическом» с точки зрения OS Windows уровне, независимо от файловой системы или её отсутствия. Проверка секторов, анализ SMART а том числе Seagate FARM, определение фейковых флешек, чтение и запись посекторных образов дисков (клонирование).

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

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

Хотите узнать, как легко купить чужие секреты и почему компании продолжают их выбрасывать в 2025 году? Рассказываем подробно.

Для электронной аппаратуры космических систем, и в первую очередь устройств памяти, актуальна задача защиты от воздействия ионизирующего космического излучения и других внешних факторов, искажающих хранимую и обрабатываемую информацию. Радиационные эффекты и космические частицы создают большое число накапливающихся в устройствах памяти ошибок. Использование известных методов помехоустойчивого кодирования информации дает эффект в течение ограниченного времени, пока число ошибок не становится слишком большим. В ответственных системах используется ECC-память – (error-correcting code memory, память с коррекцией ошибок) – тип компьютерной памяти, которая автоматически распознаёт и исправляет спонтанно возникшие изменения (ошибки) битов памяти – одну ошибку в одном машинном слове. При длине машинного слова 64 бита количество исправляемых ошибок < 1,5%.

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

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

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

Привет, Хабр! Сегодня познакомимся с Кибер Бэкапом 18 — новой версией нашей системы резервного копирования. Релиз у нас получился «увесистый» — мы обеспечили дальнейший рост производительности и масштабируемости системы, защиту новых и развитие возможностей защиты уже поддерживаемых источников данных, реализовали открытый API управления планами защиты, выполнили доработки в части интерфейса и управления системой, а также выпустили ознакомительную MVP‑версию Кибер Медиасервера.

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

Это было пять лет назад. С тех пор я прошел через четыре компании, построил on‑call процессы с нуля в двух из них, и научился главному: дежурства не должны убивать людей. Физически и морально. Давайте поговорим о том, как построить on‑call ротацию, которая не приведет к массовым увольнениям.