Почему хороший дизайн схемы важен для защиты вашего SQL Server
SQL Server - важный компонент, который помогает управлять вашими критически важными данными о вашем приложении или системе. Это могут быть данные пользователя, данные приложения и другая конфиденциальная информация, и вам нужно будет убедиться, что ваш сервер защищен со всех сторон.
Структурирование схемы базы данных вашего приложения очень важно, поскольку оно определяет, насколько оптимизирована ваша структура данных при вставке и запросе данных. Это добавляет уровень безопасности тем, кто может получить доступ к вашим SQL-серверам, если все сделано правильно.
Хороший дизайн схемы снижает сложность базы данных, оптимизирует время запросов к базе данных и не оставляет места для нарушения безопасности на вашем сервере SQL. Плохая схема может подвергнуть ваш SQL-сервер уязвимостям. Вы можете найти дополнительную информацию в этой статье, чтобы увидеть некоторые уязвимости, обнаруженные незащищенными SQL-серверами.
Чтобы понять, почему схема важна для добавления уровня безопасности на SQL-серверы, нам нужно установить некоторые термины и знать различия между схемами, логинами, пользователями и ролями пользователей, понять, какая схема является плохой и хорошей, и какие методы ее исправить.
Что такое SQL Server?
SQL Server - это просто система управления реляционными базами данных или сокращенно РСУБД, которая разрабатывается, управляется и продается Microsoft. Подобно другому программному обеспечению СУБД, SQL Server разработан на основе SQL, который является стандартным языком программирования для работы с реляционными базами данных.
Схема определяется как набор объектов базы данных, состоящий из таблиц, триггеров, представлений, хранимых процедур, индексов базы данных и многого другого. Схема обычно связана с именем пользователя, которое называется владельцем схемы.
Схема дает обзор данных в базе данных (например, текущих таблиц и их взаимосвязей). Это упрощает отслеживание многих деталей, таких как данные, которые есть и недоступны в базе данных и что они представляют, не только для тех, кто создал базу данных, но и для тех, кто собирается использовать и поддерживать ее в будущем.
Очень важно отметить, что схема всегда принадлежит одной базе данных, тогда как база данных может быть подключена к нескольким схемам.
Важность разработки схемы в обеспечении безопасности SQL-серверов
Основная цель схемы SQL - помочь в управлении безопасностью, например определить, кто и что может «видеть и получать доступ». На самом деле это стало намного проще, начиная с SQL 2005, когда схема базы данных перестала напрямую связываться с владельцем.
Схема в основном похожа на любой другой объект базы данных, контейнер для других объектов, который упрощает управление группами объектов в сложных базах данных, и это может помочь в предоставлении ролей и разрешений для любой части.
Связь схем с ролями и разрешениями - важная концепция безопасности в SQL Server. Вы можете назначить разрешения для схемы, которые применяются ко всем объектам в схеме. Это поможет обеспечить доступ нужных людей к нужным данным.
Управление доступом на основе схемы - это концепция, используемая для баз данных SQL, поскольку она очень важна для безопасности данных и должна быть простой в реализации. Базы данных должны иметь собственный встроенный контроль доступа.
Схема SQL должна служить пространством имен, это помогает предотвратить дублирование имен в объектах из разных схем. Первоначально это использовалось для того, чтобы позволить нескольким пользователям данной базы данных создавать свои собственные таблицы данных или хранимые процедуры, не беспокоясь о существовании других объектов, которые могут быть введены другими пользователями с похожими именами.
Дизайн схемы дает вам общее представление о структуре и взаимосвязи таблиц в вашей базе данных. Это помогает понять, имеют ли таблицы отношения «один к одному» или «один ко многим». Он содержит ограничения целостности базы данных, которые должна поддерживать СУБД. Он связывает разработчика приложения с дизайном схемы и обеспечивает соблюдение правил, найденных в дизайне схемы. Без этих ограничений и дизайна разработчик может создавать правила на лету и вносить хаос в систему.
При разработке хорошей схемы очень важно следить за тем, чтобы выбрать первичный ключ, чтобы по ошибке не создать горячие точки в вашей базе данных. Одной из основных причин появления горячих точек является наличие столбца в вашей базе данных, значение которого монотонно увеличивается в качестве первой ключевой части, потому что это приведет к тому, что все вставки данных будут происходить в конце вашего пространства ключей.
Плохое удобство использования хорошего дизайна схемы может привести к множеству разрушений и стать причиной атак. При разработке хорошей схемы очень важно помнить о безопасности, поскольку это может заставить разработчиков, администраторов баз данных и других пользователей делать то, что они не должны делать, и в конечном итоге может открыть уязвимость. Подробнее читайте здесь: https://www.sisense.com/blog/better-sql-schema/
Рекомендации по созданию хорошей схемы
Не выбирайте столбец, значение которого монотонно увеличивается или уменьшается, например первую ключевую часть для таблицы, которая будет иметь высокую скорость записи.
Когда вы генерируете уникальные числовые первичные ключи, старшие биты последующих чисел должны распределяться примерно поровну по всему числовому пространству. Один из способов сделать это - сгенерировать последовательные числа обычными средствами, а затем перевернуть их, чтобы получить окончательные значения.
Реверсирование битов позволяет сохранить уникальные значения первичных ключей. Вам нужно сохранить только обратное значение, потому что вы можете пересчитать исходное значение в коде вашего приложения.
Размер строки в базе данных должен быть меньше 4 ГБ, чтобы обеспечить максимальную производительность. Размер строки включает строку верхнего уровня и все ее чередующиеся дочерние и плюс проиндексированные строки.
Если у вас есть таблица для вашей истории, которая помечена меткой времени, рассмотрите возможность использования убывающего порядка для ключевого столбца (столбцов).
Используйте чередующийся индекс для столбца, значение которого монотонно увеличивается или уменьшается.
Как и в предыдущем анти-шаблоне первичного ключа, также плохая идея создавать индексы без чередования для столбцов, значения которых монотонно увеличиваются или уменьшаются, даже если они не являются столбцами первичного ключа.
Лучшие практики настройки SQL-сервера
При работе с SQL-сервером, будь то установка нового SQL или уже установленный экземпляр SQL Server, всегда полезно убедиться, что сервер запущен и работает с правильной конфигурацией и настройками для повышения производительности.
Ниже приведены рекомендации по настройке:
- Использование максимального параметра SQL Server: всегда рекомендуется оставлять 20% или 20 ГБ (в зависимости от того, что меньше) памяти для операционной системы, а остальную часть отдавать SQL Server для дополнительных ресурсов памяти.
- Измените порт SQL Server по умолчанию: SQL Server использует порт по умолчанию 1433, который широко известен, и чаще всего администраторы баз данных не меняют его. Плохая практика, если вы планируете использовать один и тот же порт и рекомендуете не использовать его.
- Учетные записи служб: учетной записью службы по умолчанию является NTService, и ее следует изменить на выделенную учетную запись домена SQL Server, которая должна иметь доступ на уровне файлов и системы. Такие службы, как экземпляр SQL Server и агент SQL Server, должны обрабатываться отдельно.
- Желательно, чтобы у экземпляров базы данных было отдельное расположение для файлов данных, журнала и резервных копий. Эти местоположения по умолчанию в экземпляре будут использоваться для автоматического заполнения местоположения по умолчанию для создания новых баз данных.
- Поскольку вы установили расположение файлов базы данных по умолчанию на уровне экземпляра, теперь вам также необходимо установить настройки по умолчанию для любой новой базы данных, которую вы создаете.
