Как правило, сертификаты содержат следующие сведения.
· Открытый ключ субъекта.
· Идентификационные данные субъекта, например имя и адрес электронной почты.
· Срок действия, то есть интервал времени, на протяжении которого сертификат будет считаться действительным.
· Идентификационные данные поставщика сертификата.
· Цифровая подпись поставщика.
Эта подпись подтверждает действительность связи между открытым ключом и идентификационными данными субъекта. В процессе создания цифровой подписи данные, вместе с некоторыми секретными данными отправителя, преобразуются в тег, называемый подписью.
· прозрачное шифрование данных.
Прозрачное шифрование данных (TDE) является особым случаем шифрования с использованием симметричного ключа. TDE шифрует всю базу данных, используя симметричный ключ, который называется ключом шифрования базы данных. Ключ шифрования базы данных защищен другими ключами или сертификатами, которые, в свою очередь, защищаются главным ключом базы данных или асимметричным ключом, хранящимся в модуле расширенного управления ключами.
Подсистема аудита MS SQL Server
Подсистема аудита - это функция, которая появилась в версии MS SQL Server 2008, позволяющая проверять события ядра базы данных и настраивать параметры проверки. Для записи данных аудита используются расширенные события. В подсистеме имеются средства и процессы, которые необходимы для того, чтобы проводить, сохранять и просматривать конфигурации аудита для различных серверов и объектов баз данных.
Подсистема аудита SQL Server работает быстрее, чем функция трассировки, а среда SQL Server Management Studio упрощает создание и контроль журналов аудита.
Для настройки аудита необходимо его создать и указать место записи событий. Аудит может храниться в журнале безопасности Windows, в журнале приложений Windows или в любом файле. Вы присваиваете аудиту имя и настраиваете его характеристики, в частности, путь к файлу аудита и его максимальный размер. Также можно настроить аудит так, чтобы в случае сбоя проверки работа SQL Server завершалась. Если события аудита нужно записывать в несколько журналов, создается несколько аудитов.
Следующий этап - создание спецификаций аудита. В спецификации аудита сервера собирается информация об экземпляре SQL Server; в нее включаются объекты, относящиеся к серверу: данные учетных записей, членство в серверных ролях. Там же имеется информация о базе данных, контролируемая в основной базе данных, например, сведения о правах доступа к базе. При создании спецификации аудита вы указываете, в какой аудит будут поступать наблюдаемые события. Вы можете создать несколько аудитов сервера и несколько спецификаций аудита, но аудит может иметь только одну активную спецификацию в каждый конкретный момент времени.
Также можно создать спецификации аудита базы данных: они будут использоваться для отслеживания событий по отдельной базе данных. В аудит можно добавить несколько спецификаций аудита баз данных, но в каждом аудите сервера активной может быть только одна спецификация аудита баз данных.
События подсистемы аудита SQL Server, используемые в спецификациях аудита сервера, объединяются в коллекции связанных событий. Они предоставляются в виде групп действий аудита. Если такую группу добавить в спецификацию аудита, можно будет отслеживать события, включенные в группу. К примеру, существует группа действий аудита DBCC_GROUP, предоставляющая доступ к командам DBCC. Отдельно же команды DBCC включаться в аудит не могут.
Всего существует 35 групп действий аудита сервера, причем некоторые из них тесно связаны друг с другом.
В спецификациях аудита баз данных можно также указывать группы событий аудита, собранные в группы действий аудита на уровне баз данных. Кроме групп действий аудита, спецификации аудита баз данных могут включать в себя отдельные события аудита, позволяющие проверять инструкции, отвечающие за работу с данными. Эти события можно настроить таким образом, чтобы отслеживать всю базу данных или только определенные объекты. Действие SELECT, в частности, может использоваться для проверки запросов SELECT, обращенных как к отдельной таблице, так и ко всей схеме в целом. Кроме того, события такого рода можно настроить так, чтобы отслеживать действия по отдельным пользователям или ролям, например db_writers.
Скажем, действие SELECT можно использовать для проверки запросов SELECT, обращенных к отдельной таблице, источником которых является пользователь Mary, или роль FINANCE_DEPT, или роль базы данных Public. Нельзя не отметить, что все это предоставляет широчайшие возможности контроля и дает большой запас гибкости при настройке аудита.
Угрозы и уязвимости MS SQL Server
Хотя SQL Server включает разнообразные механизмы защиты, каждая система содержит функции, которыми можно воспользоваться для вредоносных целей. Каждый компонент, который открывает доступ к любым данным, может быть источником опасности при неверной реализации.
Каждый компонент может представлять риск, но не все угрозы равнозначны. Для некоторых требуется изменить методы применения, для других параметры, для третьих программный код. Ниже разъясняются опасности и упреждающие шаги, которые уменьшают риск.
Угрозы, которым подвержена сама платформа изображена на рисунке 2.
Рисунок 2 - Угрозы платформы
Перечень программных угроз и уязвимостей представлен на рисунке 3.
Рисунок 3 - Программные угрозы и уязвимости
Угрозы и уязвимости доступа к данным представлены на рисунке 4.
Рисунок 4 - Угрозы и уязвимости к данным
Резервное копирование и восстановление баз данных SQL Server
Компонент резервного копирования и восстановления SQL Server обеспечивает необходимую защиту важных данных, которые хранятся в базах данных SQL Server. Чтобы минимизировать риск необратимой потери данных, необходимо регулярно создавать резервные копии баз данных, в которых будут сохраняться производимые изменения данных. Хорошо продуманная стратегия резервного копирования и восстановления защищает базы от потери данных при повреждениях, происходящих из-за различных сбоев. Проверьте выбранную стратегию, выполнив восстановление баз данных из набора резервных копий; это поможет эффективно среагировать на реальные проблемы.
При правильном создании резервных копий баз данных можно будет восстановить данные после многих видов сбоев, включая следующие:
* сбой носителя;
* ошибки пользователей (например, удаление таблицы по ошибке); сбои оборудования (например, поврежденный дисковый накопитель или безвозвратная потеря данных на сервере);
* стихийные бедствия.
Стратегия резервирования и восстановления состоит из части, относящейся к резервированию, и части, относящейся к восстановлению. Часть, относящаяся к резервированию, определяет тип и частоту создания резервных копий, тип и скоростные характеристики оборудования, необходимого для их создания, способ проверки резервных копий, а также местонахождение и тип носителя резервных копий (включая и вопросы безопасности). Часть, относящаяся к восстановлению, определяет ответственного за проведение операций восстановления, а также методы их проведения, позволяющие удовлетворить требования пользователей по доступности данных и минимизации их потерь. Рекомендуется документировать процедуры резервирования и восстановления и хранить копию этой документации в документации по задаче.
Служба хранилищ больших двоичных объектов Windows Azure
В пакете обновления SQL Server 2012 1 (SP1) появилась функция, позволяющая выполнять резервное копирование и восстановление SQL Server с помощью службы хранилищ больших двоичных объектов Windows Azure. Эту функцию можно использовать для резервного копирования SQL Server локального экземпляра базы данных или экземпляра SQL Server, размещенного где-либо, например, на виртуальной машине Windows Azure. Резервное копирование в облако дает такие преимущества, как доступность, безлимитное удаленное хранение и простота миграции данных в облако и обратно. В этой версии можно выполнять инструкции BACKUP и RESTORE.
Гибкое, надежное и безлимитное удаленное хранилище: Хранение резервных копий с помощью службы хранилища больших двоичных объектов Windows Azure является удобным и гибким, а также позволяет реализовать доступ к данным из-за пределов вычислительной системы. Для создания удаленного хранилища для резервных копий SQL Server достаточно внести изменения в существующие скрипты и задания. Удаленное хранилище обычно должно быть расположено достаточно далеко от рабочей базы данных, чтобы одна авария не могла повлиять одновременно и на удаленную копию, и на рабочую базу данных. Кроме того, резервные копии доступны в любом месте и в любое время, а также к ним легко получить доступ для восстановления.
Архив резервных копий: Служба хранилища больших двоичных объектов Windows Azure - это лучшая альтернатива часто применяемому созданию архива резервных копий на носителе. Может потребоваться физически транспортировать накопители в удаленное помещение и принимать меры для их защиты. Хранение резервных копий в хранилище больших двоичных объектов Windows Azure обеспечивает быстрое, доступное и надежное архивирование.
Нет необходимости поддерживать аппаратуру: службы Windows Azure не требуют поддержки оборудования. Службы Windows Azure сами управляют аппаратным обеспечением и обеспечивают гео-репликацию для избыточности и защиты от сбоев оборудования.
В настоящее время для экземпляров SQL Server, запущенных в виртуальной машине Windows Azure, создание резервных копий с помощью службы хранилища больших двоичных объектов Windows Azure можно выполнить, создав подключенные диски. Однако количество дисков, которые можно подключить к виртуальной машине Windows Azure, ограниченно. Для сверхбольших экземпляров данное ограничение составляет 16 дисков, а для небольших экземпляров это количество меньше. С осуществлением резервного копирования непосредственно в хранилище больших двоичных объектов Windows Azure есть возможность обойти предел в 16 дисков.
Кроме того, файл резервной копии, который сохраняется в службе хранилища больших двоичных объектов Windows Azure, напрямую доступен в локальной службе SQL Server или удаленной службе SQL Server в виртуальной машине Windows Azure. Присоединение и отсоединение базы данных, а также скачивание и подключение виртуального жесткого диска не требуется.
Заключение
Обеспечение безопасности MS SQL Server можно представить как последовательность шагов в четырех областях: платформа, проверка подлинности, объекты (в том числе данные) и приложения, которые обращаются к системе. Система безопасности в MS SQL Server постоянно совершенствуется. Однако, такие общие угрозы безопасности, как кража данных или вандализм, существуют независимо от самой платформы MS SQL Server. Целостность данных также следует рассматривать как проблему безопасности. При отсутствии защиты данных они могут стать бесполезными, если разрешено нерегламентированное управление данными и в данные случайно или преднамеренно вносятся неверные значения или они полностью удаляются. В последних версиях MS SQL Server появились новые возможности шифрования и проверки подлинности. Новая подсистема аудита и управление на основании политик, реализованное в MS SQL Server 2008, дают средства, позволяющие контролировать соблюдение установленных норм безопасности. Кроме того, MS SQL Server обеспечивает управление доступом пользователей, что позволяет распределять права доступа между участниками или группами участников. В дополнение, в версии MS SQL Server 2012 года появилась функция резервного копирования с помощью службы хранилищ больших двоичных объектов Windows Azure, что обеспечивает доступное и безлимитное хранение сохраняемых данных в облаке.
3. И.С. Осетрова Администрирование SQL Server 2014 Учебное пособие С-Пб 2016