Veeam v13.1: Azure Security, відновлення AD та Archive Tier

Кожен, хто відновлював контролер домену о третій ночі, знає: резервні копії — це ще не найскладніше. Найскладніше — через шість годин довести, що ваш ліс Active Directory справді повернеться у чистому стані. Реліз Veeam 13.1 влучає прямо в цей біль, а його структура чітко показує, постмортеми яких інцидентів читала продуктова команда.

Що сталося

Veeam випустила версію 13.1 своєї платформи захисту даних, як повідомляє Virtualization Review, з трьома ключовими доповненнями: функції Azure Security, відновлення Active Directory та Archive Tier. На папері це схоже на звичайний точковий реліз. На практиці — три різні моделі загроз, яким приділено увагу в одному оновленні.

Робота над безпекою Azure вписується у зростаючу стопку функцій захисту хмарних навантажень, які поспішає впровадити кожен постачальник резервного копіювання. Відновлення Active Directory — це те, що привертатиме найбільше уваги з боку фахівців з реагування на інциденти, адже AD є найпоширенішою ціллю, яку знищують або отруюють під час серйозної атаки ransomware. Archive Tier — важіль контролю витрат, орієнтований на команди, що потопають у даних із тривалим терміном зберігання, які юридично не можна видалити.

Veeam не переосмислила свою архітектуру. Це реліз зрілості — той, що виходить, коли корпоративні клієнти раз по раз надсилають одні й ті самі три запити на нові функції через своїх менеджерів. І чесно кажучи, саме цього й повинні хотіти корпоративні покупці платформи. Нудно — це добре. Нудно — це те, що витримує аудити.

Час випуску теж не випадковий. Кожен квартал без нативної функції відновлення AD — це квартал, який корпоративні покупці витрачають на оцінку конкурентів. Те, що це з'явилося у v13.1, а не в рамках масштабного релізу v14, свідчить: продуктовий підрозділ перебуває під тиском закрити угоди зараз, а не в наступному фінансовому році.

Технічна анатомія

Подивіться на три функції разом — і ви зможете відтворити клієнтські розмови, що їх обумовили.

Почнемо з відновлення Active Directory. Під час реальної ransomware-атаки зловмисники перебувають у середовищі, підвищують привілеї через AD і часто пошкоджують або шифрують каталог до активації корисного навантаження. Відновлення віртуальних машин не має сенсу, якщо рівень ідентифікації повертається отруєним. Спеціалізоване відновлення AD означає гранульоване відновлення об'єктів, атрибутів і групових політик — в ідеалі без повного перебудування лісу. Команди, з якими я працював, витрачали цілі вихідні на посібники з відновлення лісу, які передбачали, що все піде правильно з першої спроби. Цього ніколи не буває. Нативний інструментарій тут — не розкіш, а базова необхідність.

Доповнення безпеки Azure, найімовірніше, спрямовані на ті самі проблеми, з якими бореться кожен хмарний продукт резервного копіювання: незмінність резервних blob-об'єктів, доступ до точок відновлення з обмеженням за ідентифікатором і захист від сценарію «зловмисник отримав облікові дані адміністратора резервного копіювання». Виробничі інциденти, які я спостерігав, незмінно показують: самі системи резервного копіювання є другою ціллю, щойно зловмисники закріпляються. Якщо ваш бекап-контур розділяє межу ідентифікації з виробничим контуром, у вас немає резервної копії — у вас є ще одна копія місця злочину.

Archive Tier — найменш ефектна з трьох функцій і, мабуть, найвагоміша з економічної точки зору. Дані тривалого зберігання — семирічні фінансові записи, журнали GDPR, аудиторські сліди ігрових регуляторів — зберігаються на «гарячих» сховищах і спалюють бюджет. Належний рівень архіву переміщує ці дані до дешевших класів об'єктного сховища, зберігаючи каталог придатним для пошуку. Для аналітичних команд, що будують lakehouse-патерни поверх Delta Lake чи подібних рішень, аналогія очевидна: гарячі, теплі та холодні рівні зі спільною поверхнею запитів. Резервне копіювання нарешті наздоганяє те, як платформи даних вже давно думають про життєвий цикл.

Мій погляд: цікаве інженерне питання полягає в тому, наскільки добре три функції поєднуються між собою. Об'єкти відновлення AD в Archive Tier, відновлені у захищеному Azure середовищі — ось той ланцюжок, який має значення. Якщо в цьому ланцюжку є шви, покупці знайдуть їх у найгірший можливий момент.

Хто постраждає

Цього кварталу три групи мають звернути на це особливу увагу.

По-перше, iGaming-оператори, що працюють на гібридних інфраструктурах. Регулятори на Мальті, у Великій Британії та в кількох федеральних землях Німеччини вимагають підтверджуваного зберігання даних і підтверджуваної можливості відновлення. Якщо ви не можете продемонструвати чисте відновлення AD під час настільних навчань, вашому комплаєнс-офіцеру залишається лише один аудит до дуже поганого понеділка. Функції v13.1 безпосередньо відповідають цим вимогам. Оператори, які досі використовують саморобні скрипти навколо старих версій резервного копіювання, тепер очевидно відстають.

По-друге, фінтех-платформи з переважно Azure-інфраструктурою. Робота над безпекою Azure має сенс лише тоді, коли ви її реально впроваджуєте, а впровадження означає перегляд меж IAM, управління ключами та мережевих шляхів резервного копіювання. Це реальний проєкт, а не прапорець у чеклисті. Команди, що відкладали це, бо «резервне копіювання й так працює», — саме ті, хто постраждає під час інциденту.

По-третє, будь-яка аналітична організація, яка сприймає резервне копіювання як окремий всесвіт від платформи даних. Якщо ваше сховище на Snowflake має чіткі політики зберігання, але вихідні системи резервно копіюються командою, що не оновлювала свій посібник із 2022 року, у вас є проблема узгодженості, яка чекає свого часу під час відновлення. Archive Tier — це можливість узгодити економіку зберігання в усьому життєвому циклі даних, а не лише на рівні сховища.

Неприємна правда: більшість організацій встановлять v13.1, переглянуть нотатки до релізу і ніколи не налаштують нові функції. Потім, за вісімнадцять місяців, під час інциденту, хтось виявить, що функція відновлення AD весь цей час була нелiцензованою або неправильно налаштованою. Саме так зазвичай і відбувається. Постачальники випускають — оператори кладуть на полицю.

Посібник для команд із даних

Конкретні кроки на найближчі два тижні.

Проведіть настільне навчання з відновлення AD до того, як торкнетеся чогось іншого. Задокументуйте, скільки часу це займає сьогодні з вашим поточним інструментарієм. Це ваш базовий показник. Без нього ви не зможете обґрунтувати розмову про ліцензування або виміряти, чи справді v13.1 допомагає.

Проведіть аудит межі ідентифікації вашого бекап-контуру. Якщо та сама адміністративна група, що торкається виробничого Kubernetes, також має доступ на запис до репозиторіїв резервного копіювання — виправте це цього кварталу. Функції безпеки Azure у v13.1 передбачають, що ви готові забезпечити розмежування. Якщо ні — ці функції суто декоративні.

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

Узгодьте політику зберігання з вашим аналітичним стеком. Якщо ваше сховище використовує знімки dbt для повільно змінюваних вимірів, а ваші операційні резервні копії мають зовсім іншу криву зберігання, ви втратите можливість звірки під час відновлення. Зберіть обидві команди в одній кімнаті.

Нарешті, не оновлюйте виробниче середовище в день виходу релізу. Спершу протестуйте. Кожен продукт резервного копіювання, з яким я мав справу, мав щонайменше один точковий реліз, що порушував відновлення в якійсь нетипової конфігурації. Висновок: тестуйте на некритичному середовищі щонайменше чотири тижні до розгортання далі.

Ключові висновки

• Veeam v13.1 включає Azure Security, відновлення Active Directory та Archive Tier — у одному релізі вирішує три окремі корпоративні проблеми.
• Відновлення Active Directory — це функція, яка матиме найбільше значення під час реальної ransomware-атаки, оскільки відновлення ідентифікації є найчастішим місцем відказу при відновленні лісу.
• Archive Tier — це гра на витратах; змоделюйте її відносно поточних витрат на зберігання тривалих даних до наступного бюджетного циклу.
• Функції безпеки Azure окупаються лише якщо ви реально забезпечуєте розмежування ідентифікації між виробничим і бекап-контурами.
• Проведіть настільне навчання з відновлення AD цього місяця. Якщо ви не можете виміряти поточний базовий показник, ви не можете обґрунтувати або підтвердити доцільність оновлення.