Безопасность платформы и сети
Платформа для SQL Server включает в себя физическое оборудование и сетевые компьютеры, с помощью которых клиенты соединяются с серверами базы данных, а также двоичные файлы, применяемые для обработки запросов базы данных.
Физическая безопасность
Рекомендуется строго ограничивать доступ к физическим серверам и компонентам оборудования. Например, оборудование сервера базы данных и сетевые устройства должны находиться в закрытых охраняемых помещениях. Доступ к резервным носителям также следует ограничить. Для этого их рекомендуется хранить в отдельных охраняемых помещениях.
Реализация физической сетевой безопасности начинается с запрета доступа неавторизованных пользователей к сети. Следующая таблица содержит дополнительные сведения об источниках сведений по сетевой безопасности.
Сведения о | См. |
---|---|
SQL Server Compact и сетевой доступ к другим выпускам SQL Server | Раздел «Настройка и обеспечение безопасности среды сервера» в электронной документации по SQL Server Compact |
Безопасность операционной системы
В состав пакетов обновления и отдельных обновлений для операционной системы входят важные дополнения, позволяющие усилить безопасность. Все обновления для операционной системы необходимо устанавливать только после их тестирования с приложениями базы данных.
Кроме того, эффективную безопасность можно реализовать с помощью брандмауэров. Брандмауэр, распределяющий или ограничивающий сетевой трафик, можно настроить в соответствии с корпоративной политикой информационной безопасности. Использование брандмауэра повышает безопасность на уровне операционной системы, обеспечивая узкую область, на которой можно сосредоточить меры безопасности. Следующая таблица содержит дополнительные сведения по использованию брандмауэра с SQL Server.
Сведения о | См. |
---|---|
Настройка брандмауэра для работы со службами SQL Server | Настройка брандмауэра Windows для доступа к компоненту Database Engine |
Настройка брандмауэра для работы со службами Службы Integration Services | Службы Integration Services (службы SSIS) |
Настройка брандмауэра для работы со службами Службы Analysis Services | Настройка брандмауэра Windows на разрешение доступа к службам Analysis Services |
Открытие конкретных портов брандмауэра, чтобы предоставить доступ к SQL Server | Настройка брандмауэра Windows для разрешения доступа к SQL Server |
Настройка поддержки расширенной защиты для проверки подлинности с помощью привязки каналов и привязки служб | Соединение с компонентом Database Engine с использованием расширенной защиты |
Уменьшение контактной зоны является мерой безопасности, предполагающей остановку или отключение неиспользуемых компонентов. Уменьшение контактной зоны повышает уровень безопасности за счет уменьшения числа возможных способов атаковать систему. Важную роль в ограничении контактной зоны SQL Server играет запуск необходимых служб по принципу «минимума прав доступа», согласно которому службам и пользователям предоставляются только необходимые для работы права. Следующая таблица содержит дополнительные сведения по службам и доступу к системе.
Сведения о | См. |
---|---|
Службы, необходимые для SQL Server | Настройка учетных записей службы Windows и разрешений |
Если в системе SQL Server используются службы IIS, необходимы дополнительные действия для обеспечения безопасности контактной зоны платформы. Следующая таблица содержит сведения о SQL Server и службах IIS.
Сведения о | См. |
---|---|
Безопасность служб IIS в SQL Server Compact | «Безопасность служб IIS» в электронной документации по SQL Server Compact |
Службы Reporting Services Проверка подлинности | Проверка подлинности в службах Reporting Services |
SQL Server Compact и доступ к службам IIS | «Блок-схема безопасности служб IIS» в электронной документации по SQL Server Compact |
Безопасность файлов операционной системы SQL Server
SQL Server использует файлы операционной системы для работы и хранения данных. Оптимальным решением для обеспечения безопасности файлов будет ограничение доступа к ним. Следующая таблица содержит сведения об этих файлах.
Сведения о | См. |
---|---|
SQL Server программные файлы | Расположение файлов для экземпляра по умолчанию и именованных экземпляров SQL Server |
SQL Server позволяют повысить безопасность. Для определения новейшего доступного пакета обновления для SQL Serverперейдите на веб-сайт SQL Server .
С помощью приведенного ниже скрипта можно определить установленный в системе пакет обновления.
Безопасность
Устранение учетных записей служб
Традиционно учетные записи служб использовались для входа в SQL Server. Учетные записи служб добавляют дополнительный уровень сложности управления из-за необходимости использовать и периодически обновлять пароль учетной записи службы. Кроме того, учетные данные учетной записи службы могут использоваться при попытке маскировать действия пользователя в экземпляре.
Детализированные разрешения для системных учетных записей
Системные учетные записи традиционно получали разрешения путем создания имени входа для учетных записи LocalSystem () или NetworkService () и предоставления им разрешений. Этот метод предоставляет любому процессу или службе, которые выполняются как системная учетная запись, разрешения в SQL.
С помощью идентификатора безопасности службы разрешения могут быть предоставлены для конкретной службы. Только эта служба имеет доступ к ресурсам, для которых ей были предоставлены разрешения, действующие во время ее выполнения. Например, если выполняется как и получает право , учетная запись будет иметь право на только при выполнении в контексте . Если другой процесс попытается получить доступ к состоянию сервера SQL как , ему будет отказано в доступе.
Происхождение и целостность данных
Ведение исторических записей изменений данных может быть полезным для устранения проблем, связанных со случайными изменениями данных. Такой подход также может быть полезен для аудита изменений в приложениях, и может обеспечить возможность восстановления элементов данных, если злоумышленник внес в данные неавторизованные изменения.
- Используйте временные таблицы для хранения версий записей, а также просмотра данных в том виде, в котором они существовали на протяжении жизни записи, чтобы обеспечить историческое представление данных вашего приложения.
- Временные таблицы можно использовать, чтобы иметь возможность в любой момент времени предоставить версию текущей таблицы.
Шифрование неактивных данных
Шифрование неактивных данных кластеров больших данных SQL Server поддерживает основной сценарий шифрования на уровне приложения для компонентов SQL Server и HDFS. Ознакомьтесь со статьей Основные сведения о шифровании и руководство по конфигурации неактивных данных, в которой содержится исчерпывающее руководство по использованию этой функции.
Важно!
Мы рекомендуем использовать шифрование тома для всех развертываний Кластеров больших данных SQL Server. Предоставленные клиентом тома хранилища, настроенные в кластерах Kubernetes, также следует зашифровать, как при комплексном подходе к шифрованию неактивных данных. Функция шифрования неактивных данных Кластера больших данных SQL Server обеспечивает дополнительный уровень безопасности шифрования файлов данных и журналов SQL Server и поддержку зон шифрования HDFS.
Предоставление минимального разрешения
Первое указанное выше разрешение () — наиболее гранулярное, то есть эта инструкция предоставляет минимально возможное разрешение . Вместе с ним не предоставляются разрешения для каких-либо вложенных объектов. Рекомендуется всегда предоставлять минимально возможное разрешение (вы можете подробнее ознакомиться с принципом минимальных привилегий), но в то же время (противоречит этому) попытаться предоставить разрешения на более высоких уровнях, чтобы упростить систему предоставления. Поэтому, если Jae требуются разрешения для всей схемы, предоставьте один раз на уровне схемы, а не на уровне таблицы или представления много раз. Структура базы данных может существенно повлиять на то, насколько успешной может быть эта стратегия. Стратегия наиболее эффективна, когда объекты в базе данных, которым требуются одинаковые разрешения, включаются в одну схему.
Совет
При разработке базы данных и объектов для нее следует с самого начала определить, какие пользователи или приложения будут обращаться к каким объектам. На основе этих данных сами объекты (таблицы, представления, функции и хранимые процедуры) распределяются по схемам и контейнерам с доступом разного типа. Подробные сведения об этом подходе см. в записи блога Андреаса Вольтера (Andreas Wolter) Schema-design for SQL Server: recommendations for Schema design with security in mind (Разработка схемы для SQL Server: рекомендации по разработке схемы с учетом безопасности).
Настройка брандмауэра Windows в режиме повышенной безопасности
После того как стали известны IP-адреса, которые использует компьютер, и применяемые SQL Server порты, можно создать правила брандмауэра, а затем настроить их для конкретных IP-адресов.
Создание правила брандмауэра
-
На компьютере, на котором установлен SQL Server, войдите в систему в качестве администратора.
-
Нажмите кнопку Пуск, выберите команду Выполнить, введите wf.mscи нажмите кнопку ОК.
-
В диалоговом окне Контроль учетных записей пользователей нажмите кнопку Продолжить , чтобы с помощью учетных данных администратора открыть оснастку брандмауэра Windows в режиме повышенной безопасности.
-
На странице Обзор подтвердите, что брандмауэр Windows включен.
-
В левой панели щелкните Правила для входящих подключений.
-
Щелкните правой кнопкой мыши Правила для входящих подключенийи выберите команду Создать правило , чтобы открыть мастер создания правила для входящего подключения.
-
Можно создать правило для программы SQL Server. Так как в этом примере используется фиксированный порт, выберите Порти нажмите кнопку Далее.
-
На странице Протоколы и порты выберите TCP.
-
Выберите Указанные локальные порты. Введите номера портов через запятую и нажмите кнопку Далее. В этом примере настраивается порт по умолчанию, поэтому введите 1433.
-
На странице Действия просмотрите параметры. В этом примере брандмауэр не используется для принудительного включения безопасных соединений. Поэтому выберите Разрешить подключениеи нажмите кнопку Далее.
Примечание
Однако среда может потребовать безопасные соединения. Если выбрать один из параметров безопасных соединений, можно настроить сертификат, а затем — параметр Принудительное шифрование . Дополнительные сведения о безопасных соединениях см. в разделах Включение шифрования соединений в ядре СУБД (диспетчер конфигурации SQL Server) и Включение шифрования соединений в ядре СУБД (диспетчер конфигурации SQL Server).
-
На странице Профиль выберите один или несколько профилей для этого правила. Чтобы получить дополнительные сведения о профилях брандмауэра, щелкните ссылку Подробнее о профилях в программе брандмауэра.
-
Если компьютер является сервером и доступен только при соединении с доменом, выберите Домени нажмите кнопку Далее.
-
Если компьютер является мобильным (например, переносным компьютером), он, скорее всего, будет использовать несколько профилей при соединении с разными сетями. В этом случае можно настроить разные возможности доступа для разных профилей. Например, можно разрешить доступ, если компьютер использует профиль домена, и не разрешить — при использовании открытого профиля.
-
-
На странице Имя введите имя и описание правила и нажмите кнопку Готово.
-
Повторите эту процедуру для создания другого правила для каждого IP-адреса, используемого SQL Server.
После создания одного или нескольких правил выполните следующие шаги, чтобы настроить каждый IP-адрес компьютера для использования правил.
Настройка правила брандмауэра для конкретных IP-адресов
-
На странице Правила для входящих подключений окна Брандмауэр Windows в режиме повышенной безопасностищелкните правой кнопкой мыши только что созданное правило и выберите пункт Свойства.
-
В диалоговом окне Свойства правила перейдите на вкладку Область .
-
В области Локальный IP-адрес выберите Указанные IP-адресаи нажмите кнопку Добавить.
-
В диалоговом окне IP-адрес выберите IP-адрес или подсетьи введите один из IP-адресов, которые нужно настроить.
-
Щелкните ОК.
-
В области Удаленный IP-адрес выберите Указанные IP-адресаи нажмите кнопку Добавить.
-
В диалоговом окне IP-адрес настройте обмен данными для выбранного IP-адреса компьютера. Можно включать соединения через указанные IP-адреса, диапазоны IP-адресов, целые подсети или определенные компьютеры. Чтобы правильно настроить этот параметр, необходимо хорошо понимать работу сети. Сведения о сети можно узнать у администратора сети.
-
Нажмите кнопку ОК , чтобы закрыть диалоговое окно IP-адрес, затем нажмите кнопку ОК , чтобы закрыть диалоговое окно Свойства правила .
-
Чтобы настроить другие IP-адреса на многосетевом компьютере, повторите эту процедуру для каждого IP-адреса, используя другое правило.
Совместимость с разными компонентами
Как правило, безопасность на уровне строк будет работать должным образом в разных компонентах. Однако существует несколько исключений. В этом разделе описано несколько заметок и предостережения по использованию безопасности на уровне строк с некоторыми другими функциями SQL Server.
-
DBCC SHOW_STATISTICS предоставляет статистику по нефильтрованным данным и может вызвать утечку информации, которая должна быть защищена политикой безопасности. По этой причине доступ к просмотру объектов статистики для таблицы с политикой безопасности на уровне строк ограничен. Пользователь должен быть владельцем таблицы, членом предопределенной роли сервера sysadmin, предопределенной роли базы данных db_owner или предопределенной роли базы данных db_ddladmin.
-
Filestream. Безопасность на уровне строк не совместима с компонентом Filestream.
-
PolyBase: безопасность на уровне строк поддерживается для внешних таблиц в Azure Synapse и SQL Server 2019 CU7 или более поздней версии.
-
Таблицы, оптимизированные для памяти. Встроенная функция с табличным значением, которая используется в качестве предиката безопасности для таблицы, оптимизированной для памяти, должна быть определена с помощью параметра . Этот параметр позволяет блокировать функции языка, не поддерживаемые в оптимизированных для памяти таблицах, и выдавать соответствующую ошибку во время создания. Дополнительные сведения см. в разделе Безопасность на уровне строк в таблицах, оптимизированных для памяти статьи Вводные сведения о таблицах, оптимизированных для памяти.
-
Индексированные представления. Как правило, политики безопасности можно создавать на основе представлений, а представления — на основе таблиц, связанных политиками безопасности. Тем не менее индексированные представления нельзя создать на основе таблиц с политикой безопасности, так как операции поиска строк через индекс будут обходить политику.
-
Отслеживание измененных данных. Система отслеживания измененных данных может вызвать утечку целых строк, которые должны быть отфильтрованы для доступа членов db_owner или пользователей, являющихся членами «шлюзовой» роли, указанной при включении этой системы для таблицы. (Примечание. Для этой функции можно явно задать значение NULL, чтобы все пользователи имели доступ к измененным данным.) В результате параметр db_owner и члены такой шлюзовой роли могут просматривать все изменения данных в таблице даже при наличии политики безопасности для таблицы.
-
Отслеживание изменений. Отслеживание изменений может вызвать утечку первичного ключа строк, которые должны быть отфильтрованы для доступа пользователей с разрешениями SELECT и VIEW CHANGE TRACKING. Доступ к фактическим значениям данных не предоставляется, становится известно только то, что столбец A был обновлен (вставлен или удален) для строки с первичным ключом B. Это создает проблему, если первичный ключ содержит конфиденциальные элементы, например номер социального страхования. Тем не менее на практике для получения последних данных инструкция CHANGETABLE почти всегда объединена с исходной таблицей.
-
Полнотекстовый поиск. Запросы, использующие следующие функции полнотекстового и семантического поиска, будут выполняться со сниженной производительностью из-за введения дополнительного соединения для применения безопасности на уровне строк и блокирования утечки первичных ключей строк, которые должны быть отфильтрованы: CONTAINSTABLE, FREETEXTTABLE, semantickeyphrasetable, semanticsimilaritydetailstable, semanticsimilaritytable.
-
Индексы Columnstore. Безопасность на уровне строк совместима с кластеризованными и некластеризованными индексами columnstore. Тем не менее, поскольку безопасность на уровне строк применяет функцию, оптимизатор может изменить план запроса таким образом, чтобы пакетный режим не использовался.
-
Секционированные представления. Предикаты блокировки нельзя определить в секционированных представлениях, а секционированные представления нельзя создавать на основе таблиц, использующих предикаты блокировки. Предикаты фильтров совместимы с секционированными представлениями.
-
Темпоральные таблицы. Темпоральные таблицы совместимы с безопасностью на уровне строк. Тем не менее предикаты безопасности в текущей таблице не реплицируются автоматически в прежнюю таблицу. Чтобы применить политику безопасности для текущей и прежней таблиц, необходимо по отдельности добавить предикат безопасности в каждую таблицу.
Создание имени входа и пользователя базы данных
Предоставьте другим пользователям доступ к SQL Server, создав имя входа в базе данных master с помощью инструкции CREATE LOGIN. Пример:
Примечание
Всегда используйте надежный пароль вместо звездочек в предыдущей команде.
Имена входа могут подключаться к SQL Server и обращаться (с ограниченными разрешениями) к базе данных master. Для подключения к пользовательской базе данных имя входа должно иметь соответствующее удостоверение на уровне базы данных, называемое пользователем базы данных. Пользователи относятся к конкретной базе данных, и их нужно создавать отдельно в каждой базе данных для предоставления им доступа. Следующий пример переносит вас в базу данных AdventureWorks2014, а затем с помощью инструкции CREATE USER создает пользователя Larry, сопоставленного с именем входа Larry. Хотя имя входа и пользователь связаны (сопоставлены друг с другом), это разные объекты. Имя для входа является субъектом серверного уровня. Пользователь является субъектом уровня базы данных.
- Учетная запись администратора SQL Server может подключаться к любой базе данных и создавать дополнительные имена входа и пользователей в любой базе данных.
- Когда пользователь создает базу данных, он становится ее владельцем, который может подключаться к этой базе данных. Владельцы базы данных могут создавать дополнительных пользователей.
Позже вы сможете авторизовать другие имена входа, чтобы создать дополнительные имена входа, предоставив им разрешение . Внутри базы данных вы можете авторизовать других пользователей, чтобы создать дополнительных пользователей, предоставив им разрешение . Пример:
Теперь имя входа Larry может создать дополнительные имена входа, а пользователь Jerry может создать дополнительных пользователей.
Создание имени входа и пользователя базы данных
Предоставьте другим пользователям доступ к SQL Server, создав имя входа в базе данных master с помощью инструкции CREATE LOGIN. Пример:
Примечание
Всегда используйте надежный пароль вместо звездочек в предыдущей команде.
Имена входа могут подключаться к SQL Server и обращаться (с ограниченными разрешениями) к базе данных master. Для подключения к пользовательской базе данных имя входа должно иметь соответствующее удостоверение на уровне базы данных, называемое пользователем базы данных. Пользователи относятся к конкретной базе данных, и их нужно создавать отдельно в каждой базе данных для предоставления им доступа. Следующий пример переносит вас в базу данных AdventureWorks2014, а затем с помощью инструкции CREATE USER создает пользователя Larry, сопоставленного с именем входа Larry. Хотя имя входа и пользователь связаны (сопоставлены друг с другом), это разные объекты. Имя для входа является субъектом серверного уровня. Пользователь является субъектом уровня базы данных.
- Учетная запись администратора SQL Server может подключаться к любой базе данных и создавать дополнительные имена входа и пользователей в любой базе данных.
- Когда пользователь создает базу данных, он становится ее владельцем, который может подключаться к этой базе данных. Владельцы базы данных могут создавать дополнительных пользователей.
Позже вы сможете авторизовать другие имена входа, чтобы создать дополнительные имена входа, предоставив им разрешение . Внутри базы данных вы можете авторизовать других пользователей, чтобы создать дополнительных пользователей, предоставив им разрешение . Пример:
Теперь имя входа Larry может создать дополнительные имена входа, а пользователь Jerry может создать дополнительных пользователей.
Разрешения
Модель безопасности данных SQL Server для имен входа и ролей базы данных распространяется и на внешние скрипты. Для запуска внешних скриптов, использующих данные SQL Server или выполняемых в контексте вычисления SQL Server, требуется учетная запись SQL Server или учетная запись пользователя Windows. Пользователи базы данных с разрешениями на выполнение запросов могут обращаться к одним и тем же данным из внешнего скрипта.
Имя входа или учетная запись пользователя определяет субъект безопасности, которому в зависимости от требований внешнего скрипта может потребоваться несколько уровней доступа:
- разрешение на доступ к базе данных, в которой включены внешние скрипты;
- разрешения на чтение данных из защищенных объектов, таких как таблицы;
- возможность записи новых данных в таблицу, такую как модель, или результатов оценки;
- возможность создания новых объектов, например таблиц, хранимых процедур, использующих внешний скрипт, или пользовательских функций, использующих задания внешнего скрипта;
- право на установку новых пакетов на компьютере SQL Server или использование пакетов, предоставленных группе пользователей.
Каждый пользователь, запускающий внешний скрипт в контексте выполнения SQL Server, должен быть сопоставлен с пользователем в базе данных. Рекомендуется не задавать разрешения каждому пользователю базы данных отдельно, а создавать роли для управления наборами разрешений и назначать их пользователям.
Дополнительные сведения см. в статье Give users permission to SQL Server Machine Learning Services (Предоставление пользователям разрешения в службах машинного обучения SQL Server).
Шифрованию – быть!
Общий подход прост до гениального: раз злоумышленник гипотетически сможет
извлечь данные, надо сделать так, чтобы он их не смог прочитать. Информацию все
равно придется хранить в базе, но… ничего не мешает хранить ее в каком угодно
виде, в том числе зашифрованном! Главное, чтобы мы сами потом смогли
расшифровать :).
Компания Spelabs (www.spellabs.ru/spellabsCrypto1C.htm)
как-то анонсировала продукт, организующий дополнительную безопасность
бухгалтерских 1С на уровне шифрования данных, причем на полностью прозрачном
уровне. Пользовательские приложения, не подозревая о надстройке, работали в
обычном режиме. Увы, компания прекратила разработку этого направления. Но
реально обойтись и без подобных инструментов, ведь для шифрования сгодятся даже
штатные средства СУБД!
Любая современная СУБД, если это, конечно, не собранная на коленке курсовая,
может похвастаться достаточно надежными механизмами шифрования данных. В той же
самой MySQL я по памяти насчитал около 14 соответствующих функций, которые тебе
наверняка хорошо известны:
- AES_ENCRYPT() — шифрование AES
- AES_DECRYPT() — расшифровка AES
- COMPRESS() — возвращение результата в бинарном виде
- DES_ENCRYPT() — шифрование DES
- DES_DECRYPT() — дешифрование DES
-
ENCODE() — шифрование строки поверхностным паролем (на выходе
получается шифрованное слово первоначальной «plaintext» длины - DECODE() — расшифровка текста, обработанного функцией ENCODE()
- ENCRYPT() — шифрование с помощью Unix’ового системного вызова crypt
- MD5() — подсчет MD-5 суммы
- SHA1(), SHA() — подсчет SHA-1 (160-бит)
Для их применения надо лишь чуть изменить свои SQL-запросы, добавив в нужном
месте функции AES_ENCRYPT() или DES_ENCRYPT(), которые считаются наиболее
надежными в MySQL на текущий момент. Например, так:
Приятно признать, что хорошие программисты эти функции используют. Часто во
время проведения SQL-инжекции мне приходилось ломать голову и определять
функцию, которую использовал кодер для крипточки данных. В результате, требуется
производить те же AES_DECRYPT(AES_ENCRYPT()) наряду с unhex(hex()).
Удостоверения и проверка подлинности
SQL Server поддерживает два режима проверки подлинности: проверка подлинности Windows и режим проверки подлинности SQL Server и Windows (смешанный режим).
Имена для входа отличаются от пользователей базы данных. Сначала сопоставьте имена для входа или группы Windows пользователям базы данных или ролям в отдельной операции. Затем предоставьте разрешения на доступ к объектам базы данных пользователям, ролям сервера, а также (или) ролям базы данных.
В SQL Server существуют следующие типы имен входа.
- Локальная учетная запись пользователя Windows или учетная запись доменных служб Active Directory — SQL Server полагается на Windows для проверки подлинности учетных записей пользователей Windows.
- Группа Windows — предоставление доступа группе Windows обеспечивает доступ ко всем именам для входа пользователей Windows, которые являются членами группы. При удалении пользователя из группы для него будут удалены права, которые он получил во время членства в группе. Членство в группе является предпочтительной стратегией.
- Учетные данные SQL Server — SQL Server сохраняет имя пользователя и хэш пароля в базе данных master.
- Пользователи автономной базы данных проверяют подлинность подключений SQL Server на уровне базы данных. Автономная база данных — это база данных, изолированная от других баз данных и от экземпляра SQL Server (а также базы данных master), на котором размещена эта база данных. SQL Server поддерживает использование пользователей автономной базы данных для проверки подлинности Windows и SQL Server.
Следующие рекомендации и лучшие методики помогут вам защитить удостоверения и способы проверки подлинности:
-
Используйте стратегии для улучшения управления безопасностью.
Обычно пользователей Active Directory помещают в группы AD, причем группы AD должны существовать в ролях SQL Server, а ролям SQL Server необходимо предоставлять минимальные разрешения, требуемые приложением.
-
Использование защиты по принципу предоставления минимальных прав в Azure с помощью элементов управления доступом на основе ролей (RBAC)
-
Выбирайте AD DS вместо проверки подлинности SQL Server, когда это возможно, и в особенности отдавайте предпочтение AD DS, а не хранению средств безопасности на уровне приложения или базы данных.
- Так вы сможете легко отключить учетную запись пользователя, который покидает организацию.
- Или легко удалить пользователей из групп при смене их роли или ухода из организации. Гарантирование безопасности групп является рекомендуемым поведением.
-
Используйте многофакторную проверку подлинности для учетных записей с доступом на уровне компьютера, а также учетных записей, использующих RDP для входа в систему компьютера. Это помогает защититься от кражи или утечки учетных данных, так как однофакторная проверка подлинности на основе пароля является более слабой формой проверки подлинности с учетными данными, подверженными риску компрометации или ошибочной отправки.
-
Требуйте ввода сильных и сложных паролей, которые нельзя угадать, и которые не используются для других учетных записей или целей. Регулярно обновляйте пароли и применяйте политики AD DS.
-
Групповые управляемые учетные записи служб (gMSA) обеспечивают автоматическое управление паролями, упрощенное управление именами субъектов-служб и возможность делегировать управление другим администраторам.
- Если использовать gMSA, паролем учетной записи управляет не администратор, а сама операционная система Windows.
- gMSA автоматически обновляет пароли учетных записей, не перезапуская службы.
- gMSA сокращает уровень административной плоскости и улучшает разделение обязанностей.
-
Минимизируйте объем прав, предоставляемых учетной записи AD для DBA; рассмотрите возможность разделения обязанностей, ограничивающего доступ к виртуальной машине, возможность входа в операционную систему, возможность изменения журналов ошибок и аудита, а также возможность установки приложений и/или возможностей.
-
Рассмотрите возможность удаления для учетных записей DBA прав роли sysadmin и предоставления прав , вместо того, чтобы делать эти учетные записи участниками роли sysadmin. Роль системного администратора не учитывает операцию DENY, в отличие от .
Обзор
Многоуровневая технология безопасности предусматривает решение «защита в глубину», используя многочисленные возможности защиты, направленные на различные области безопасности. Возможности безопасности, доступные в SQL Server 2016, и улучшенные в последующих выпусках, помогают противостоять угрозам безопасности и обеспечивать надежную защиту приложений баз данных.
Azure соответствует ряду отраслевых норм и стандартов, которые позволяют создать совместимое с SQL Server решение, работающее на виртуальной машине. Сведения о соответствии нормам Azure см. в центре управления безопасностью Azure.
Обзор
Многоуровневая технология безопасности предусматривает решение «защита в глубину», используя многочисленные возможности защиты, направленные на различные области безопасности. Возможности безопасности, доступные в SQL Server 2016, и улучшенные в последующих выпусках, помогают противостоять угрозам безопасности и обеспечивать надежную защиту приложений баз данных.
Azure соответствует ряду отраслевых норм и стандартов, которые позволяют создать совместимое с SQL Server решение, работающее на виртуальной машине. Сведения о соответствии нормам Azure см. в центре управления безопасностью Azure.
Источники информации
https://studfiles.net/preview/2823609/
https://support.office.com/ru-ru/
https://studopedia.ru/11_126441_zashchita-baz-dannih-MS-Access-.html
- Экономические показатели ресторана (Анализ факторов, формирующих доход заведения)
- Анализ системы мотивации сотрудников на соответствие целям компании
- Анализ системы мотивации сотрудников на соответствие целям компании (на примере ПАО «МГТС»)
- Значение, цели и задачи оценочной деятельности в современной России
- Функциональные возможности ЕСМ «Directum»
- Корпорация, её сущность, достоинства и недостатки
- Понятие семьи и брака в семейном праве
- Основания и порядок раздела общего имущества супругов
- Историческая последовательность становления проектного управления
- Договор купли-продажи (Договорное право)
- Методы управления конфликтами в организации
- Особенности семейных правоотношений. Семейное право
Службы, используемые во внешней обработке (панель запуска)
Платформа расширяемости добавляет одну новую службу NT в в установке SQL Server: .
Ядро СУБД использует службу панели запуска SQL Server для создания экземпляра сеанса внешнего скрипта в виде отдельного процесса.
Процесс выполняется под удостоверением пользователя панели запуска, но с дополнительным ограничением, содержащимся внутри AppContainer. Такой подход лежит в основе модели безопасности и изоляции для внешних скриптов в SQL Server.
SQL Server также поддерживает сопоставление удостоверения вызывающего пользователя с учетной записью рабочей роли с низким уровнем прав, используемой для запуска вспомогательного процесса. В некоторых сценариях, когда скрипт или код осуществляет обратный вызов SQL Server для получения данных и операций, SQL Server обычно с легкостью управляет передачей удостоверений. Если вызывающий пользователь обладает достаточными разрешениями, скрипты, содержащие инструкции SELECT или вызывающие функции и другие программные объекты, выполняются успешно.
Шифрование файлов
позволяет защитить данные на уровне файлов, предоставляя шифрование неактивных данных файлов базы данных. TDE гарантирует, что файлы базы данных, файлы резервных копий и файлы tempdb не будут доступны для подключения и чтения без соответствующих сертификатов, расшифровывающих файлы базы данных. Если не использовать прозрачное шифрование данных (TDE), злоумышленник сможет завладеть физическими носителями (дисками или лентами резервных копий), восстановить или подключить базу данных и считать ее содержимое. Эта технология поддерживается в сочетании со всеми другими возможностями безопасности в SQL Server. Прозрачное шифрование данных (TDE) выполняет в реальном времени шифрование и дешифрование файлов данных и журналов в операциях ввода-вывода. При этом типе шифрования используется ключ шифрования базы данных (DEK), хранящийся в базе данных пользователя. Ключ шифрования базы данных можно также защитить с помощью сертификата, защищенного главным ключом базы данных master.
Используйте TDE для защиты неактивных данных, резервных копий и базы данных tempdb.
Используемая литература:
https://habr.com/hub/db_admins/
http://www.opennet.ru/docs/RUS/db_admin/#_Toc481223759
http://dit.isuct.ru/IVT/sitanov/Literatura/AdminInfSystem/Pages/Glava7.htm
http://5fan.ru/wievjob.php?id=36290
- Электронная цифровая подпись (по дисциплине Информационные технологии в менеджменте)
- Понятие, цели, задачи и значение оценки бизнеса (ИДЕНТИФИКАЦИЯ ОБЪЕКТА ОЦЕНКИ В СООТВЕТСТВИИ С ТРЕБОВАНИЯМИ НОРМАТИВНЫХ ДОКУМЕНТОВ)
- Инновационный проект как вид деятельности и сфера бизнеса
- Основные понятия и сущность корпоративного управления (Основные понятия и сущность корпоративного управления)
- Информационно-методический комплекс управления эффективностью бизнеса «Контур корпорация» компании Intersoft Lab
- Информационные системы управления эффективностью бизнеса как инструмент реализации стратегии компании и управления бизнес-процессами.
- Мотивация труда — от теории к практике (на примере отдела продаж компании ООО «Сота»)
- Особенности организации и методики проведения подвижных игр в младших классах (Характеристика подвижных игр.)
- Понятие и виды юридических фактов в гражданском праве.
- Понятие и виды юридических фактов в гражданском праве (Право и Организация Социального Обеспечения)
- Понятие и виды юридических фактов в гражданском праве. (Классификация юридических фактов)
- Обзор Pos-материалов и принципы их проектирования. ( Определение и функции Pos-материалов.)