Даже если вы сделали все правильно, чтобы обезопасить приложение SQL Server, ваша база данных все еще не является безопасной, когда хост-машина скомпрометирована. С помощью наших советов по обеспечению безопасности хоста вы можете быть более уверены в том, что уязвимости машины не подвергают опасности ваши данные.
Чтобы помочь вам поддерживать машину, на которой размещен SQL сервер Server безопасной, мы проделаем следующее:
• Предложим простые, но обычно упускаемые из виду советы, которые произведут существенные перемены в обеспечении безопасности любой машины.
• Обсудим способы поддержки базы данных в безопасном состоянии путем поддержки безопасности в Microsoft Windows.
• Снабдим вас некоторыми подсказками о том, как работать с системными администраторами для реализации этих советов.
Как администратор баз данных (АБД) вы, вероятно, хорошо осведомлены о своей ответственности за исправность и хорошее состояние базы данных. И если вы действуете подобно большинству опытных АБД, то уже затратили время и силы на установку политик безопасности и реализацию встроенных механизмов, которые SQL Server обеспечивает для безопасности базы данных. Но, как вам скажет каждый эксперт по безопасности, лучшие стратегии защиты включают слои (уровни — layers).
База данных является центром большинства IТ-инфраструктур и, разумеется, нуждается в независимой защите от вторжений и неправильного использования. Однако если вы хотите иметь действительно безопасную базу данных, вам понадобится создать несколько уровней (защиты), как показано на Рисунке А. Это означает защиту машины и операционной системы, на которой расположена база данных, так же как и сети, подключающей сервер базы данных к другим системам. Мы покажем вам 10 способов, с помощью которых вы можете уменьшить подверженность базы данных проблемам безопасности в этих областях.
Кстати, если вы хотите арендовать софт фирмы 1С, обратитесь в компанию Смарт Офис. Здесь вы сможете заказать множество конфигураций 1С, включая 1c sql в облаке.
Как распорядиться перекрывающимися зонами ответственности
Когда речь заходит о безопасности хоста и сети, область профессиональных интересов становится очень важной. Во многих организациях бывает трудно сказать, где заканчивается сфера деятельности АБД и начинается область ответственности системного администратора. Некоторые системные администраторы
обладают глубоким знанием своей сети и машин (как некоторые АБД осведомлены о своих базах данных). В других организациях АБД могут иметь полный контроль над хостом базы данных, но все еще будут, возможно, свободны от ответственности за сетевой интерфейс, передав ее системному администратору.
Вряд ли вы поспорите с тем, что разделение обязанностей относительно безопасности хоста базы данных между АБД и системным администратором благотворно сказывается на общей безопасности. В конце концов, потенциально опасно для одного человека иметь полный контроль над ценным IT-объектом. С другой стороны, если вы являетесь АБД, выгодно быть информированным, независимо от того, является ли безопасность хоста персональной ответственностью или основанием для обсуждения с системными администраторами.
Общие (независимые от ОС) советы
Наш список советов никоим образом не отсортирован по важности. Вам решать, какие советы реализовывать у себя и в каком порядке. Оцените свою ситуацию и решите, который из них заслуживает вашего внимания прямо сейчас, основываясь на своих конкретных условиях эксплуатации. Так что мы начнем с общих советов, а затем отточим их на конкретных вещах, которые нужно сделать с вашей конфигурацией Windows для поддержки хоста базы данных в безопасности.
Совет #1: Обезопасьте инфраструктуру
Убедитесь в том, что хост SQL Server расположен в запертой комнате с ограниченным доступом, с резервным источником питания и системами защиты от по
жара. Не ограничивайтесь только предположением, что все сделано правильно. Выполните проверку самостоятельно или подтвердите это с помощью администратора, ответственного за данную машину.
Совет #2: Отдайте хост под SQL Server
Попытайтесь сделать хост SQL Server посвященным базе данных. Это упрощает обеспечение безопасности, потому что только привилегированные учетные записи могут получить доступ и здесь меньше потребности в концентрации внимания на правах доступа к файлам. Однако внимательно следите за правами доступа к любым файлам, содержащим пароли и информацию об учетных записях пользователей, наряду с файлами данных, конфигурации, аудита, журналов и управляющими файлами.
Совет #3: Не пренебрегайте управлением заплатками
Поддерживайте операционную систему так, чтобы она была снабжена всеми необходимыми заплатками, независимо от того, какую ОС применяете. Необязательно вы должны быть тем, кто производит установку заплаток, но вы должны проверять это регулярно и решать эту проблему в случае необходимости.
Отслеживайте предупреждения системы безопасности, выпускаемые Microsoft, а также незамедлительно устанавливайте заплатки программного обеспечения. Регулярно посещайте веб-узел Microsoft по адресу http:// www.microsoft.com%2ftechnet%2fsecurity%2fcurrent.aspx для получения информации по предупреждениям, касающимся безопасности. Немного ниже на этой странице веб-узла Microsoft вы найдете раздел под названием Search By Product/Technology, предоставляющий ниспадающее окно Product/Technology, из которого вы можете выбрать SQL Server 2000 и другие продукты.
Совет #4: Избегайте контактов с Интернетом
Лучше всего не иметь хоста SQL Server, к которому можно получить доступ из Интернета. Это значит, что помещение веб-сервера или сервера приложений на ту же самую машину — плохая идея. Веб-серверы и серверы приложений должны иметь доступ к базе данных с другой машины внутри локальной сети.
Совет #5: Дайте оценку своей стратегии (развития) аппаратного обеспечения
Рассмотрите стратегию (развития) аппаратного обеспечения, относящуюся к базе данных. Безопасность не только связана с защитой от хакеров; безопасность также влияет на доступность этой базы. Если вы не используете RAID или некоторые другие решения по зеркалированию дисков, то должны сделать это. Рассмотрите план действий в аварийных ситуациях и определите, что могло бы случиться, если хост SQL Server отказал и был отключен от сети в течение нескольких дней.
Совет #6: Проверяйте план резервного копирования
Уделяйте пристальное внимание плану резервного копирования хоста SQL Server. Если вы выполняете резервное копирование на другой диск на данной хост-машине в режиме онлайн, то проконтролируйте, что эти файлы копируются на ленту в какой-то момент времени. Проверьте права доступа к файлам резервных копий и зашифруйте копии, если это необходимо. Держите полученную копию базы данных в безопасном месте.
Совет #7: Проводите в жизнь сильные пароли для учетных записей администратора
Важно проводить в жизнь сильные пароли для всех учетных записей, но особенно это важно для привилегированных учетных записей администратора. Установите автоматическое окончание срока действия пароля и заблокируйте учетные записи, подвергшиеся пяти следующим один за другим отказам входа в систему.
Совет #8: Обезопасьте «передвижную» базу данных
Остерегайтесь переезжающего с места на место АБД или разработчика, который возит с собой повсюду полную копию вашей базы данных SQL Server по разработке или производству. Если такой лэптоп потерян или украден, хорошо осведомленная сторона может почувствовать себя вооруженной найденным кладом секретной информации.
Существуют продукты, доступные с использованием USB-токенов размером с ключ от квартиры и улучшенного стандарта шифрования Advanced Encryption Standard (AES). Без такого токена лэптоп полностью неприступен. Когда вы готовы к использованию лэптопа, просто вставьте токен в USB-порт и введите пароль.
Совет #9: Уязвимости хоста (узла) доступа
Оценка уязвимостей (vulnerability assessment — VA), выполненная сторонними организациями, может быть крайне ценным инструментом для обеспечения аттестации системы безопасности и измерения эффективности мер ее обеспечения. Пригласите производителя, который специализируется на VA для выполнения тестов с вашим хостом SQL Server, чтобы получить оценки мест с наибольшими уязвимостями. Вы должны производить отчисления на регулярной основе, раз в квартал или ежегодно, поскольку ландшафт безопасности непрерывно изменяется.
Совет #10: Откажитесь от практики применения небезопасных приложений
Несмотря на то что охрана учетных записей является в большей степени проблемой базы данных, чем хоста, если приложение использует sa, например, для доступа к базе данных, то это явный признак того, что существует нечто вне этой базы данных, что может подвергнуть такую базу данных риску.
И несмотря на то что это может показаться очевидной ошибкой, реальность такова, что многие разработчики применяют учетную запись администратора sa для доступа к базе данных в своих программах, просто потому, что это уберегает их от необходимости применения управляемых полномочий. Кроме того, иногда коммерческие программные продукты по умолчанию настроены на применение учетной записи администратора sa, если администратор не конфигурирует программу на использование другой учетной записи.
Самые опасные преступники, разумеется, это приложения, которые сохраняют пароль sa. Приложения ASP и ASP.NET могут сохранять эту информацию в файле, таком как global.asa или web.config. Поэтому, чтобы расширить концепцию, упомянутую в Совете #2, разумно убедиться в том, что любое приложение на любой машине, использующее базу данных, не слишком выставляет напоказ пароль системного администратора sa — или любую другую учетную запись.
