Лучшие практики для хранения паролей в сценариях оболочки / Perl?

Question

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

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

Есть ли хорошее решение для этого, которое кто-то другой уже написал, возможно, как модуль CPAN? Или есть что-то еще, что лучше сделать - например, сохранить комбо пользователя / пароля в отдельном файле, который спрятан где-то еще в файловой системе? Или я должен хранить их в зашифрованном виде, чтобы избежать их извлечения из моих сценариев с помощью общесистемного grep?

Edit: База данных Oracle находится на сервере HP-UX.
Сервер приложений (запускающий сценарии оболочки) - Solaris.
Установка сценариев, которые будут принадлежать только мне, запрещена, они должны принадлежать учетной записи службы, к которой имеют доступ несколько сотрудников службы поддержки.
Сценарии предназначены для запуска в качестве заданий cron.
Я хотел бы пойти с аутентификацией с открытым ключом, но я не знаю методов, чтобы заставить это работать с Oracle - если есть такой метод - просветите меня!

Answer 1

Лучшей практикой, IMHO, было бы НЕ хранить пароли в скрипте shell / Perl Вот для чего нужна аутентификация с открытым ключом.

Answer 2

Если скрипт запущен удаленно с сервера.

1. Сделайте ваши отчеты просмотров
2. Предоставьте пользователю, который входит в систему, ТОЛЬКО доступ для выбора в представлениях отчета.
3. Просто сохраните пароль.

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

Answer 3

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

Однако в Perl существует множество подходов. Вы можете изучить Getopt :: Long для параметров командной строки (и дополнительно Getopt :: ArgvFile для хранения их в простом файле конфигурации) или посмотреть что-то вроде Config :: IniFiles для чего-то более мощного. Это два типа, которые я обычно использую, но есть и другие доступные модули конфигурационных файлов.

Answer 4

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

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

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

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

Некоторые практические примеры реализации здесь

Answer 5

Я не уверен, какую версию Oracle вы используете. В более старой версии Oracle (до 9i Advanced Security) некоторые администраторы баз данных CREATE USER OPS$SCOTT IDENTIFIED BY EXTERNALLY устанавливали бы REMOTE_OS_AUTHENT в значение true.

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

Это плохая идея.

Поскольку вы можете создать образ любой Windows XP с локальным пользователем SCOTT, вы можете войти в вашу БД без пароля.

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

Какое бы ни было ваше решение, стоит заглянуть в Project Lockdown от Oracle перед его фиксацией.

Answer 6

Поскольку вы пометили ksh & bash, я собираюсь предположить, что Linux.

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

Лучшим способом может быть следующее:

1. Сделайте ваш скрипт таким образом, чтобы его могли видеть / читать / открывать только вы. чмод 700 это. Жесткие пароли удалены.
2. Иметь скрипт запуска, который исполняется пользователем и выполняет sudo.

Таким образом, пользователь может увидеть ваш скрипт запуска, проверить его на наличие только одной командной строки. Они могут запустить его, и он работает, но у них нет прав на чтение исходного кода для сценария sudo'd.

Answer 7

Хорошего решения не существует. Вы можете немного запутать пароли, но не можете их защитить.

Если у вас есть контроль над настройкой БД, вы можете попробовать подключиться по именованному каналу (по крайней мере, MySQL поддерживает это) без пароля и позволить ОС обрабатывать разрешения.

Вы также можете хранить учетные данные в файле с ограниченными правами.

Answer 8

Существуют коммерческие или более продвинутые решения, такие как Cyberark AIM, которые могут сделать это лучше, но, делая это бесплатно и из коробки, я получил ответный запрос на использование открытого / закрытого ключа SSH, потому что, с одной стороны, пары ключей SSH, скорее всего, уже есть создано соответствие политики безопасности; во-вторых, пары ключей SSH уже имеют набор стандартных протоколов для защиты ключей с помощью разрешения файла, непрерывного усиления системы (например, tripwire) или вращения ключа.

Вот как я это сделал:

1. Генерация пар ключей ssh, если еще нет. Пары ключей и каталог будут защищены системным протоколом / разрешением по умолчанию. ssh-keygen –t rsa –b 2048

2. использует открытый ключ ssh для шифрования строки и хранится в том же каталоге .ssh $ echo "секретное слово" | openssl rsautl -encrypt -inkey ~ / .ssh / id_rsa.pub -pubin -out ~ / .ssh / secret.dat

3. использовать закрытый ключ ssh для расшифровки ключа и передачи параметров в сценарии / AP в реальном времени. Скрипт / программа для включения строки для расшифровки в реальном времени: строка = openssl rsautl -decrypt -inkey ~/.ssh/id_rsa -in ~/.ssh/secret.dat

PS - Я экспериментировал с решением без агента CYBERARK AIM. Такая боль требует значительных изменений / изменений API для API / скрипта. будет держать вас в курсе, как это происходит.

Answer 9

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

Этого должно хватить на несколько человек.

Ключевые слова: Hardcoding Password

Answer 10

Жаль, что я никогда не видел эту ветку раньше - она ​​выглядит очень интересно. Я добавлю свои два цента для любого, кто натолкнется на нить в будущем.

Я бы рекомендовал использовать аутентификацию ОС на самом сервере БД - REMOTE_OS_AUTHENT по-прежнему ЛОЖЬ.

Если вы вызываете скрипт с другого компьютера, настройте SSH-ключ без фразы и используйте SSH, чтобы туда попасть. Затем вы можете направить результаты SQL обратно на вызывающую машину, и она сможет обрабатывать эту информацию дальше.

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

Инго