MS SQL Server дело тонкое...: Security

Показаны сообщения с ярлыком Security. Показать все сообщения

5.11.25

sys.dm_db_index_physical_stats со всеми "потрохами"

Автор: Paul Randal, Inside sys.dm_db_index_physical_stats

Давным‑давно, на излёте прошлого века, я написал для SQL Server 2000 команду DBCC SHOWCONTIG, в пару к своему новому изобретению — DBCC INDEXDEFRAG.

А ещё я постоянно носил шорты и люминесцентные оранжевые, жёлтые или зелёные носки.

Многое меняется — скажем, у меня теперь (иногда) есть чувство вкуса. Среди прочего, с появлением в SQL Server 2005 динамических представлений (DMV) DBCC SHOWCONTIG уступил место sys.dm_db_index_physical_stats. Однако под капотом у них один и тот же код — и характеристика ввода‑вывода (I/O) не изменилась.

Эту заметку я собирался написать уже давно, а окончательно подтолкнул меня T‑SQL Tuesday на тему I/O, который сегодня проводит Mike Walsh (blog). Идея отличная, решил присоединиться. Перечитывая перед публикацией, понимаю, что слегка увлёкся (угрохал пару часов) — но это один из моих «детей», так что я имею право! :-)

Дальше »

20.10.25

Новое в SQL Server 2022: Database Ledger

Автор: Deepam Ghosh, Database Ledger in SQL Server 2022

Защита данных от несанкционированного доступа сегодня — одна из главных задач. SQL Server 2022 предлагает новую функцию Database Ledger, усиливающую безопасность данных. Она защищает данные как от злоумышленников, так и от пользователей с повышенными привилегиями — администраторов баз данных, системных и облачных администраторов.

Database Ledger работает как традиционный реестр, фиксируя историю данных. Когда строка обновляется, SQL Server сохраняет её прежнее значение в таблице истории. Эта возможность использует технологию блокчейна, обеспечивая криптографическую целостность данных. SQL Server хеширует каждую транзакцию по SHA-256, формирует корневой хеш и связывает его с хешем предыдущего блока — создавая надёжную цепочку записей. В этой статье мы познакомимся с новой функцией SQL Server на практическом примере.

Дальше »

15.10.25

Исследуем fn_dblog(): недокументированная функция SQL Server для чтения журнала транзакций

Автор: SQLYARD, Exploring fn_dblog(): The Undocumented SQL Server Function That Reads the Transaction Log

SQL Server ведёт детальную запись каждого изменения в журнале транзакций. Обычно вы взаимодействуете с ним косвенно — через резервные копии, репликацию или восстановление. Но существует скрытая, недокументированная функция fn_dblog(), которая позволяет напрямую запрашивать активный журнал транзакций.

Эта функция может помочь вам:

Расследовать удаления и изменения данных.
Отслеживать активность DDL и DML.
Устранять проблемы вроде случайной потери данных.
Анализировать поведение репликации и восстановления.

Поскольку функция недокументирована, Microsoft её официально не поддерживает и она может измениться без предупреждения. Тем не менее, для администраторов БД и специалистов по расследованию инцидентов это мощный инструмент.

Дальше »

17.9.25

Всё, что нужно знать про управление ключами TDE при восстановлении базы данных

Автор: PieterVanhove, Everything you need to know about TDE key management for database restore

Прозрачное шифрование данных (TDE) в Azure SQL с ключом, управляемым клиентом (Customer-Managed Key, CMK), поддерживает сценарий «принеси свой ключ» (Bring Your Own Key — BYOK) для защиты данных в состоянии покоя и даёт возможность разделения обязанностей по управлению ключами и данными. При клиентском управлении TDE пользователь отвечает за жизненный цикл ключей (создание, загрузка, ротация, удаление), права на их использование и аудит операций с ключами. Ключ, используемый для шифрования ключа шифрования базы данных (Database Encryption Key, DEK), называемый TDE-протектором, — это асимметричный ключ, которым управляет клиент и который хранится в Azure Key Vault.

После включения TDE с использованием ключа из Key Vault новые резервные копии продолжают шифроваться с использованием того же TDE-протектора. Смена TDE-протектора не изменяет уже созданные резервные копии — чтобы восстановить резервную копию, зашифрованную ключом Key Vault, необходимо, чтобы материал соответствующего ключа был доступен серверу, на который выполняется восстановление. Особенность реализации TDE требует, чтобы для успешного восстановления были доступны как текущий, так и предыдущие TDE-протекторы. Рекомендуется сохранять все предыдущие версии протектора в хранилище ключей, чтобы иметь возможность восстановить резервные копии базы данных.

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

Дальше »