Защита сервера базы данных

«Безопасность баз данных» (англ. Database security ) относится к использованию широкого спектра средств защиты информации для защиты баз данных (потенциально включая данные, приложения баз данных или хранимые функции, системы баз данных, серверы баз данных и связанные с ними сетевые ссылки) против компрометации их конфиденциальности, целостности и доступности. Он включает в себя различные типы или категории контроля, такие как технические, процедурные / административные и физические. «Безопасность базы данных» является специализированной темой в более широких сферах компьютерной безопасности, информационной безопасности и управления рисками.

Росс Андерсон часто говорил, что по своей природе большие базы данных никогда не будут свободны от злоупотреблений в результате нарушений безопасности; Если большая система предназначена для облегчения доступа, она становится небезопасной; Если сделана водонепроницаемая, становится невозможно использовать. Это иногда называют «Правилом Андерсона». [1]

Многие уровни и типы управления информационной безопасностью подходят для баз данных, в том числе:

• Контроль доступа
• Базы данных аудита
• Аутентификация
• Шифрование
• Целостность данных
• Резервные копии
• Безопасность приложений
• Защита базы данных с использованием статистического метода

Содержание

Угрозы безопасности [ править | править код ]

К угрозам безопасности к системам баз данных относятся, например:

• Непреднамеренная деятельность или неправильное использование уполномоченными пользователями базы данных, администраторами баз данных или сетевыми / системными менеджерами или не авторизованными пользователями или хакерами (например, ненадлежащий доступ к конфиденциальным данным, метаданным или функциям в базах данных или неправильные изменения в программах, структурах или безопасности базы данных конфигурации);
• Инфекции вредоносных программ, вызывающие такие инциденты, как несанкционированный доступ, утечка или раскрытие личных или запатентованных данных, удаление или повреждение данных или программ, прерывание или отказ в разрешенном доступе к базе данных, атак на другие системы и непредвиденный сбой служб баз данных ;
• Перегрузки, ограничения производительности и проблемы с пропускной способностью, приводящие к невозможности использования авторизованных пользователей для использования баз данных по назначению;
• Физический ущерб серверам баз данных, вызванный пожарами или наводнениями в компьютерном зале, перегревом, молнией, случайными разливами жидкости, статическими разрядами, сбоями в электроснабжении / сбоями оборудования и устареванием;
• Ошибки разработки и ошибки программирования в базах данных и связанных с ними программах и системах, создание различных видов уязвимости безопасности (например, несанкционированное эскалация привилегий), потеря / повреждение данных, ухудшение производительности и другие;
• Повреждение данных и / или потеря, вызванные вводом неверных данных или команд, ошибками в процессах администрирования базы данных или системы, саботажем / уголовным ущербом и другие.

Привилегии [ править | править код ]

В среде базы данных важны два типа привилегий:

Привилегии системы [ править | править код ]

Системные привилегии позволяют пользователю выполнять административные действия в базе данных. К ним относятся привилегии (как указано в SQL Server), такие как: создание базы данных, создание процедуры, создание представления, резервная база данных, создание таблицы, создание триггера и выполнение. [2]

Привилегии объекта [ править | править код ]

Объектные привилегии позволяют использовать определенные операции над объектами базы данных, разрешенные другим пользователем. Примеры включают: использование, выбор, вставку, обновление и ссылки. [2]

Принцип наименьшей привилегии и разделения обязанностей:

Базы данных подпадают под внутренний контроль, то есть данные, используемые для публичной отчетности, годовые отчеты и другие, подлежат разделению обязанностей, то есть должно быть разделение задач между развитием и производством. Каждая задача должна быть проверена третьим лицом, которое не пишет фактический код. Разработчик базы данных не должен ничего выполнять в производстве без независимого анализа документации кода для выполняемой работы. Как правило, роль разработчика заключается в передаче кода в DBA; Однако, учитывая сокращения, возникшие в результате экономического спада, администратор баз данных может быть недоступен. Если администратор базы данных не задействован, важно, как минимум, для сверстников провести обзор кода.

Принцип предоставления наименьшего количества привилегий:

Другим пунктом внутреннего контроля является соблюдение принципа предоставления наименьшего количества привилегий, особенно в производстве. Чтобы предоставить разработчикам больше доступа для выполнения своей работы, гораздо безопаснее использовать олицетворение для исключений, требующих повышенных привилегий (например, «EXECUTE AS» или sudo, чтобы сделать это временно). Часто разработчики могут отклонить это как «накладные расходы», находясь на пути к славе кодирования. Однако имейте в виду, что администраторы баз данных должны делать все, что считается ответственным, потому что они являются «де-факто» стюардами данных организации и должны соблюдать правила и закон. [3]

Оценки уязвимости для управления рисками и соответствия требованиям [ править | править код ]

Один метод оценки безопасности базы данных включает в себя проведение оценок уязвимости или тестов на проникновение в базу данных. Тестеры пытаются найти уязвимости (уязвимости), которые могут быть использованы для поражения или обхода элементов управления безопасностью, взлома базы данных, компрометации системы и другие. Администраторы базы данных могут, например, использовать автоматическое сканирование уязвимости для поиска неправильной конфигурации элементов управления (часто называемых «дрифт») в пределах упомянутых выше уровней наряду с известными слабостями в программном обеспечении базы данных. Результаты таких сканирования используются для упрощения базы данных (повышения безопасности) и закрытия определенных выявленных уязвимости, но другие уязвимости часто остаются не распознанными и без внимания.

В средах баз данных, где важна безопасность, постоянный мониторинг соответствия стандартам повышает безопасность. Обеспечение безопасности требует, доступ на управление и обзор разрешениями (особенно публичными), предоставляемыми объектам в базе данных. Объекты базы данных могут включать таблицы или другие объекты, перечисленные в таблице. Разрешения, предоставленные для команд языка SQL на объектах, рассматриваются в этом процессе. Мониторинг соблюдения аналогичен оценке уязвимости, за исключением того, что результаты оценок уязвимости в целом приводят к стандартам безопасности, которые приводят к непрерывной программе мониторинга. По сути, оценка уязвимости является предварительной процедурой определения риска, когда программа соблюдения является процессом текущей оценки риска.

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

Абстракция [ править | править код ]

Механизмы уровня приложений authentication и authorization могут быть эффективными средствами обеспечения абстракции от уровня базы данных. Основным преимуществом абстракции является способность single sign-on к нескольким базам данных и платформам. Единая система регистрации сохраняет учетные данные пользователя базы данных и идентифицируется в базе данных от имени пользователя.

Мониторинг активности базы данных (DAM) [ править | править код ]

Другой уровень безопасности более сложного характера включает мониторинг активности базы данных в режиме реального времени либо путем анализа трафика протокола (SQL) по сети, либо путем наблюдения активности локальной базы данных на каждом сервере с использованием программных агентов или обоих. Использование агентов или собственное ведение журнала требуется для захвата действий, выполняемых на сервере, которые обычно включают в себя действия администратора базы данных. Агенты позволяют эту информацию захватывать таким образом, который не может быть отключен администратором базы данных, который имеет возможность отключать или изменять собственные журналы аудита.

Анализ может быть проведен для выявления известных нарушений правил, или исходные данные могут быть со временем захвачены для создания нормального шаблона, используемого для обнаружения аномальной активности, которая может свидетельствовать о вторжении. Эти системы могут обеспечить всеобъемлющий контрольный журнал базы данных в дополнение к механизмам обнаружения вторжений, а некоторые системы также могут обеспечивать защиту путем прекращения сеансов пользователей и карантина пользователей, демонстрирующих подозрительное поведение. Некоторые системы предназначены для поддержки разделения обязанностей (SOD), что является типичным требованием аудиторов. SOD требует, чтобы администраторы баз данных, которые обычно контролируются как часть DAM, не могут отключать или изменять функциональность DAM. Для этого необходимо, чтобы контрольный журнал DAM надежно хранился в отдельной системе, не администрируемой группой администрирования базы данных.

Родительский аудит [ править | править код ]

Помимо использования внешних инструментов для мониторинга или аудита, для многих платформ баз данных также доступны собственные возможности проверка базы данных. Собственные контрольные журналы извлекаются на регулярной основе и передаются в назначенную систему безопасности, где администраторы баз данных имеют / не должны иметь доступ. Это обеспечивает определенный уровень разделения обязанностей, который может свидетельствовать о том, что собственные контрольные маршруты не были изменены администраторами, прошедшими проверку подлинности, и должны проводиться ориентированной на безопасность старшей группой DBA с правами на чтение в производство. Включение собственного воздействия на производительность сервера. Как правило, собственные контрольные журналы баз данных не обеспечивают достаточного контроля для обеспечения разделения обязанностей; Поэтому возможности мониторинга на основе хоста на уровне сети и ядра модуля обеспечивают более высокую степень достоверности для судебной экспертизы и сохранения доказательств.

Процесс и процедуры [ править | править код ]

Хорошая программа обеспечения безопасности баз данных включает в себя регулярный обзор привилегий, предоставляемых учетным записям пользователей и учетным записям, используемым автоматическими процессами. Для отдельных учетных записей система двух факторная аутентификация повышает безопасность, но добавляет сложности и стоимости. Учетные записи, используемые автоматическими процессами, требуют соответствующего контроля над хранением паролей, таких как достаточное шифрование и контроль доступа, чтобы снизить риск компрометации.

В сочетании со звуковой программой обеспечения безопасности базы данных соответствующая программа аварийного восстановления может гарантировать, что служба не будет прервана во время инцидента с безопасностью, или любой инцидент, который приведет к отключению первичной среды базы данных. Примером может служить Репликация (информатика) | репликация для первичных баз данных на сайты, расположенные в разных географических регионах. [4]

После возникновения инцидента судебная экспертиза может использоваться для определения объема нарушения и для определения соответствующих изменений в системах и процессах.

Управление доступом в базах данных [ править | править код ]

Большинство систем баз данных представляют собой средство единого централизованного хранения данных. Это значительно сокращает избыточность данных, упрощает доступ к данным и позволяет более эффективно защищать данные . Однако, в технологии БД возникает ряд проблем, связанных, например, с тем, что различные пользователи должны иметь доступ к одним данным и не иметь доступа к другим . Поэтому, не используя специальные средства и методы, обеспечить надежное разделение доступа в баз данных практически невозможно.

Большинство современных СУБД имеют встроенные средства, позволяющие администратору системы определять права пользователей по доступу к различным частям баз данных, вплоть до конкретного элемента . При этом имеется возможность не только предоставить доступ тому или иному пользователю, но и указать разрешенный тип доступа: что именно может делать конкретный пользователь с конкретными данными (читать, модифицировать, удалять), вплоть до реорганизации всей базы данных. Управления доступом широко используются в компьютерных системах, например, в ОС для управления доступом к файлам .Особенность использования этого средства для защиты баз данных состоит в том, что в качестве объектов защиты выступают не только отдельные файлы (области в сетевых баз данных, отношения в реляционных баз данных), но и другие структурные элементы баз данных: элемент, поле, запись, набор данных.

Повышение безопасности базы данных [ править | править код ]

Для повышения общей безопасности этих баз данных можно использовать следующие дополнительные шаги, которые выполняются в рамках сети и среды сервера:

1. Запустите сервер баз данных на компьютере, на котором установлена система Windows Server 2003. По умолчанию эта операционная система более безопасна, чем система Windows 2000 Server. Несмотря на то, что компьютер сервера Windows 2000 Server можно заблокировать, этот процесс может быть связан с затратами времени, кроме того, существует вероятность возникновения ошибок, которыми могут воспользоваться злоумышленники для получения доступа к базе данных.
2. Ограничьте физический доступ к серверу базы данных.
3. Обеспечьте, чтобы разрешения базы данных и списки разграничительного контроля доступа, имеющиеся в файлах базы данных, разрешали доступ только уполномоченному персоналу. Надежными являются разрешения по умолчанию и списки DACL, настроенные службой управления правами. Следует соблюдать осторожность при изменении любых параметров по умолчанию.
4. Не запускайте лишние службы на сервере базы данных, например службы IIS, службу очередей сообщений или службы терминалов.
5. Кроме баз данных службы управления правами, не следует запускать на сервере баз данных никакие другие базы данных.

Невозможно защитить сервер от внешнего доступа раз и навсегда, ведь каждый день обнаруживаются новые уязвимости и появляются новые способы взлома сервера. О защите серверов от несанкционированного доступа мы и расскажем в этой статье.

Сервера любой компании рано или поздно могут стать мишенью для взлома или вирусной атаки. Обычно результатом такой атаки становится потеря данных, репутационный или финансовый ущерб, поэтому вопросам обеспечения безопасности серверов стоит уделить внимание в первую очередь.

Следует понимать, что защита от взлома серверов – это комплекс мер, в том числе подразумевающий постоянный мониторинг работы сервера и работу по совершенствованию защиты. Невозможно защитить сервер от внешнего доступа раз и навсегда, ведь каждый день обнаруживаются новые уязвимости и появляются новые способы взлома сервера.

О защите серверов от несанкционированного доступа мы и расскажем в этой статье.

Способы и методы защиты серверов от несанкционированного доступа

Физическая защита сервера

Физическая защита. Желательно, чтобы сервер находился в защищенном ЦОДе, закрытом и охраняемом помещении, у посторонних не должно быть доступа к серверу.

Установите аутентификацию по SSH

При настройке доступа к серверу используйте аутентификацию по ключам SSH вместо пароля, поскольку такие ключи гораздо сложнее, а иногда и попросту невозможно взломать с помощью перебора вариантов.

Если же считаете, что вам все-таки требуется пароль, обязательно ограничьте число попыток его ввода.

Обратите внимание, если при входе вы видите подобное сообщение:

Last failed login: Tue Sep 28 12:42:35 MSK 2017 from 52.15.194.10 on ssh:notty
There were 8243 failed login attempts since the last successful login.

Оно может свидетельствовать, что ваш сервер пытались взломать. В таком случае для настройки безопасности сервера смените порт SSH, ограничьте список IP, с которых возможен доступ к серверу или установите ПО, автоматически блокирующее чрезмерно частую и подозрительную активность.

Регулярно устанавливайте последние обновления

Для обеспечения защиты сервера вовремя устанавливайте последние патчи и обновления серверного ПО, которое используете – операционной системы, гипервизора, сервера баз данных.

Желательно проверять наличие новых патчей, обновлений и сообщения об обнаруженных ошибках / уязвимостях каждый день, чтобы предотвратить атаки, использующие уязвимости нулевого дня. Для этого подпишитесь на новости от компании-разработчика ПО, следите за ее страницами в соцсетях.

Защищайте пароли

До сих пор одним их самых распространенных способов получить доступ к серверу является взлом пароля сервера. Поэтому придерживайтесь общеизвестных, но тем не менее актуальных рекомендаций, чтобы не оставить сервер без защиты:

• не используйте пароли, которые легко подобрать, такие как название компании;
• если вы до сих пор используете дефолтный пароль для консоли администратора – немедленно измените его;
• пароли на разные сервисы должны быть разными;
• если вам необходимо передать пароль кому-либо, никогда не отправляйте IP-адрес, логин и пароль в одном и том же письме или сообщении в мессенджере;
• для входа в учетную запись администратора можно установить двухэтапную аутентификацию.

Файрвол

• Убедитесь, что на сервере есть файрвол, он настроен и он работает все время.
• Защищайте и входящий, и исходящий трафик.
• Следите за тем, какие порты открыты и для каких целей, не открывайте ничего лишнего, чтобы снизить число вероятных уязвимых мест для взлома сервера.

В частности, файрвол очень помогает в защите сервера от ddos атак, т.к. можно быстро создавать запрещающие правила файрвола и вносить в них IP-адреса, с которых идет атака, или блокировать доступ к определенным приложениям, по определенным протоколам.

Мониторинг и обнаружение вторжений

• Ограничьте ПО и службы, работающие у вас на сервере. Периодически проверяйте все, что у вас запущено, и если обнаружатся какие-то незнакомые вам процессы, удаляйте их немедленно и начинайте проверку на вирусы.
• Периодически проверяйте наличие следов взлома. О взломе могут свидетельствовать новые учетные записи пользователей, которые вы не создавали, перемещение или удаление файла /etc/syslog.conf, удаленные файлы /etc/shadow и /etc/passwrd .
• Мониторьте работу вашего сервера, следите за его обычной скоростью и пропускной способностью, так вы сможете заметить отклонения, например, когда нагрузка на сервер стала значительно больше обычного.

Рекомендуем использовать специализированные системы обнаружения и предотвращения вторжений (IDS/IPS). Например, межсетевые экраны Cisco ASA Firepower оснащены соответствующим модулем, требуется только его правильно настроить.

Использование VPN и шифрования SSL/TLS

Если необходим удаленный доступ к серверу, он должен быть разрешен только с определенных IP-адресов и происходить по VPN.

Следующим этапом обеспечения безопасности может быть настройка SSL, которая позволит не только шифровать данные, но и проверять идентичность других участников сетевой инфраструктуры, выдавая им соответствующие сертификаты.

Проверка безопасности сервера

Хорошей идеей будет самостоятельная проверка безопасности сервера методом пентеста, т.е. моделирование атаки, чтобы найти потенциальные уязвимости и вовремя их ликвидировать. Желательно привлечь к этому специалистов по информационной безопасности, однако некоторые тесты можно проделать и самостоятельно, используя программы для взлома серверов.

Что еще грозит серверам кроме взлома

Сервер может выйти из строя по ряду других причин, кроме взлома. Например, это может быть заражение вредоносным ПО или просто физическая поломка какого-либо из компонентов.

Поэтому мероприятия по защите сервера должны включать:

• Установку и обновление программ для защиты сервера – антивирусов.
• Регулярные зашифрованные копии данных, по меньшей мере, раз в неделю, поскольку, согласно статистике, жесткие диски сервера на первом месте по частоте поломок. Убедитесь, что резервная копия хранится в физически безопасной среде.
• Обеспечение бесперебойного электропитания серверной.
• Своевременная физическая профилактика серверов, включающая их чистку от пыли и замену термопасты.

Опыт специалистов “Интегруса” говорит нам, что лучшая защита от такого рода угроз – это применение лучших практик в области систем защиты серверов.

Для обеспечения безопасности серверов наших заказчиков мы применяем сочетание инструментов: брандмауэры, антивирусы, технологии безопасности / управления событиями (SIM / SEM), технологии обнаружения вторжений / защиты (IDS / IPS), технологии сетевого поведенческого анализа (NBA), конечно же регулярное профилактическое обслуживание серверов и обустройство защищенных серверных под ключ. Это позволяет свести риски взлома или отказа сервера по другим причинам к минимуму.

Готовы провести аудит безопасности серверов вашей компании, провести консультирование специалистов, выполнить все виды работ по настройке защиты серверного оборудования.

Бд изолируют как правило и работают через слой АПИ. Никакие строки подключения у клиента нигде быть не должны.

Запрос из вашего приложения или браузера -> MVC контроллер -> обращение к базе из вашего кода.

Строка подключения при этом будет лежать в web.config или appsettings.json на сервере.

Всё зависит от того, где и как лежит эта строка.
Если это веб-приложение и база крутится на сервере, то юзер не увидит эту строку, она запрятана в исходном коде приложения.

Если это какая-то локальная программа, которая дёргает локальную же базу, то не совсем понятно, в чём проблема.

Если это какой-то сайт и пользователь подрубается к базе, вводя логин и пароль и передавая его plaintext’ом, то веб-макаке, которая так сделала, надо рвать руки.

В общем, уточните контекст.

Всё что запускается на машине атакующего может быть взломано.

Чушь. Взломайте-ка мне сервер Касперского, у меня антивирь к их серваку за обновлениями цепляется.

Если вы зашиваете мастер-пароль базы с программу, считайте что ваша базу уже не ваша.

Взломайте-ка мне сервер Касперского, у меня антивирь к их серваку за обновлениями цепляется.

Можно "зашить" хэш дли-и-и-инного пароля и передавать уже его.

то есть впихнуть саму строку в код программы из конфига.

И зашифровать только строку или файл с кодом в целом?

Ну "зашифровать" будет чересчур сложно, я думаю. Можно просто закодировать в какой-нибудь base64 и на сервере раскодировать обратно, если будет возможность. Можно обфусцировать, как советовали выше, разбить строку на кусочки, сунуть их в разные части кода и потом собрать.

Разумеется, это не защитит от того, кто действительно захочет взломать базу, но от обычного (и продвинутого) юзера защитит даже зашивание голой строки в программу.

И какая разница, я отправляю из своей программы этот хеш, сервер верит мне как родному приложению. В чём тут плюс хеша?

существует ли возможность поправить программу (нужен исходный код)?

я бы зашил и зашифровал строку подключения в саму программу

Ну "зашифровать" будет чересчур сложно, я думаю. Можно просто закодировать в какой-нибудь base64 и на сервере раскодировать обратно, если будет возможность. Можно обфусцировать, как советовали выше, разбить строку на кусочки, сунуть их в разные части кода и потом собрать.

Такова селяви, вы можете попробовать запрятать логин и пароль в обфусицированном коде но это защитит только от пользователей но не от хакера/знающего человека, правда сделает эту задачу дорогой.

На практике, обычно так и делают, если у вас десктопное приложение и пользователи подключаются с его помощь к базе данных, можно запрашивать у них логин и пароль (т.е. строка подключения это только ip и порт БД), т.е. за авторизацию и аутентификацию будет отвечать БД.