Каковы безопасные подходы к обработке скрипта, который требует пароль базы данных (MySQL)? - PullRequest
8 голосов
/ 11 февраля 2010

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

Если сценарии принимают пароль в качестве параметра, нам нужно беспокоиться об изменении вывода 'ps', чтобы он не отображал значение аргумента пароля. Нам также придется беспокоиться о том, что команда будет записана в истории оболочки. Это потенциально может быть обработано с помощью HISTIGNORE / HISTCONTROL на bash, но есть другие используемые оболочки с отличающимся и менее гибким управлением историей (например, zsh). Мы также могли бы использовать переменную среды, специфичную для командной строки (FOO = bar ./script), и хотя «FOO = bar» не будет отображаться в «ps», по-прежнему она по умолчанию записывается в историю оболочки. Кроме того, некоторые системы в любом случае предоставляют доступ к процессам других пользователей (через «ps»).

Можно использовать файл пароля (конфигурации), который просто хранит пароль в виде открытого текста. Этот файл может принадлежать / разрешаться таким образом, чтобы ограничить его доступ. Но, в конце концов, у вас все еще есть пароль в текстовом виде.

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

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

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

Общая цель здесь состоит в том, чтобы злоумышленник не смог составить сервер базы данных, если злоумышленник каким-либо образом попадет в систему, которая использует сервер базы данных. Например, атака не должна быть в состоянии просто найти пароль, лежащий где-то поблизости, не должна быть в состоянии наблюдать систему ('ps'), чтобы обнаружить его, и не должна быть в состоянии "оглянуться назад во времени" (история оболочки), чтобы найти его.

Я прекрасно осознаю, что существуют миллионы сценариев (kmem, меняющиеся страницы и т. Д. И т. Д.), И что большинство ставок не принимаются, если злоумышленник получает root или физический доступ, и что ничего не будет 100 % безопасно. Я просто действительно ищу лучший подход в пределах разумного . : -)

Ответы [ 5 ]

4 голосов
/ 12 февраля 2010

Вы можете поместить файл .my.cnf в домашний каталог пользователей, которые могут получить доступ к сценарию, с их информацией, и mysql может читать его оттуда вместо командной строки. Вам также придется установить переменную окружения так, чтобы она указывала на ~ / .my.cnf, но ... я не уверен, является ли она MYSQL_HOME или SYSCONFDIR или чем-то еще *. Это все еще будет простой текстовый файл, но если вы ограничите этот файл только для владельца, все будет хорошо? Это будет по крайней мере сохранить пароли от ps.

MySQL: файлы опций и MySQL: защита паролем страницы документа обе намекают на это немного.

(* Отказ от ответственности: я не администратор по любому определению, просто достаточно, чтобы попасть в беду)

3 голосов
/ 11 февраля 2010

Если сценарии не используют запрос и каким-то образом знают пароль БД, тогда злоумышленник может выполнить любой из ваших сценариев и выполнить те же действия.

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

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

Если вы хотите скрыть пароль, у вас всегда может быть система из 2 частей. Хотя вы можете делать очень сложные вещи, XOR (побитовый эксклюзив или, который на Perl и большинстве других языков) также может быть вашим другом. Для администратора это просто, а для злоумышленника ни одна часть не полезна. Автоматизированный злоумышленник может перейти на более плодородную почву. Вы даже можете оставить одну из частей на другом хосте и получить ее с помощью wget или nfs или чего-либо еще. Таким образом, он может быть отключен как часть системы tripwire.

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

2 голосов
/ 12 февраля 2010

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

Сохраните пароль в файле, доступном только для пользователя root. Сценарий чтения ключей должен начинаться с правами суперпользователя, считывать пароль, устанавливать соединение с базой данных с использованием учетной записи базы данных с минимальными необходимыми привилегиями, стирать пароль из памяти, а затем выпадать ( Как я могу сбросить привилегии в Perl? может помочь) на непривилегированную системную учетную запись.

Наличие простых сценариев / триггера для мониторинга сеансов базы данных (время начала и окончания сеанса, пользователь, IP-адрес, выполненные команды) на сервере базы данных, отслеживание использования sudo в системе и т. Д.

2 голосов
/ 11 февраля 2010

Я не администратор Unix, но ... Как насчет того, чтобы скрипты запускались под учетной записью без входа в систему, и установите разрешения для скрипта (и файла паролей) равными 500. Это ограничило бы доступ к root и пользователь сценария.

1 голос
/ 12 февраля 2010

Возможно, вы захотите изучить TPM (http://en.wikipedia.org/wiki/Trusted_Platform_Module)

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

Cheers, GK

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...