Приховування пароля в сценаріях оболонки

Як я можу приховати пароль у скриптах оболонки? Існує ряд сценаріїв, які мають доступ до бази даних. Якщо ми відкриємо сценарій, інші також знають ім’я користувача та пароль. Тож якщо хтось знає, як приховати, будь ласка, дайте мені знати.

У мене є один спосіб: помістіть пароль у файл і зробіть файл прихованим, і ніхто не збирається отримати доступ до файлу (змінити дозволи та використовувати файл у скрипті під час переходу до бази даних).

По-перше , як уже сказали декілька людей, важливим є збереження облікових даних окремо від сценарію. (Окрім підвищеної безпеки, це також означає, що ви можете повторно використовувати один і той же сценарій для декількох систем з різними обліковими даними.)

По-друге , вам слід врахувати не тільки безпеку облікових даних, але й вплив, якщо / коли ці облікові дані будуть порушені. У вас не повинно бути лише одного пароля для доступу до бази даних, у вас повинні бути різні облікові дані з різним рівнем доступу. Наприклад, ви можете мати одного користувача БД, який має можливість здійснювати пошук у базі даних - цей користувач повинен мати доступ лише для читання. Інший користувач може мати дозвіл на вставлення нових записів, але не видаляти їх. Третя може мати дозвіл на видалення записів.

Окрім обмеження дозволів для кожного облікового запису, ви також повинні мати обмеження щодо того, звідки можна використовувати кожен обліковий запис. Наприклад, обліковий запис, який використовується вашим веб-сервером, не повинен дозволяти з'єднатися з будь-якою іншою IP-адресою, ніж веб-сервер. Обліковий запис з повними правами доступу до бази даних дійсно повинен бути дуже обмежений з точки зору того, звідки він може з'єднуватися, і ніколи не повинен використовуватися, крім інтерактивного. Також розгляньте можливість використання збережених процедур у базі даних, щоб обмежити, що саме може зробити кожен обліковий запис.

Ці обмеження потрібно реалізувати на стороні DB-сервера системи, так що навіть якщо клієнтська частина порушена, обмеження не можуть бути змінені з неї. (І, очевидно, що сервер БД повинен бути захищений брандмауерами тощо, крім конфігурації БД ...)

У випадку з обліковим записом БД, дозволений лише обмежений доступ лише для читання, і лише з певної IP-адреси, вам, можливо, не знадобляться додаткові облікові дані, ніж це, залежно від чутливості даних та безпеки хосту сценарію запускається з. Одним із прикладів може бути форма пошуку на вашому веб-сайті, яку можна запустити з користувачем, якому дозволено використовувати лише збережену процедуру, яка витягує лише ту інформацію, яка буде представлена ​​на веб-сторінці. У цьому випадку додавання пароля насправді не надає додаткової безпеки, оскільки ця інформація вже призначена для загального доступу, і користувач не може отримати доступ до будь-яких інших даних, які були б більш чутливими.

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

По-третє , подумайте, який тип облікових даних використовувати. Паролі - це лише одна форма, і не найбезпечніша. Натомість ви можете використовувати якусь форму пари відкритих / приватних ключів, або AD / PAM тощо.

По-четверте , розглянемо умови, за яких буде виконуватися сценарій:

Якщо він запускається в інтерактивному режимі, тоді вам слід ввести пароль, або пароль до приватного ключа, або приватного ключа, або увійти в систему за допомогою дійсного квитка Kerberos, коли ви запускаєте його - іншими словами, сценарій повинен отримати його дані безпосередньо від вас під час запуску, замість того, щоб читати їх з якогось файлу.

Якщо він запускається з веб-сервера, подумайте про налаштування облікових даних у момент запуску веб-сервера. Хорошим прикладом тут є сертифікати SSL - вони мають публічний сертифікат та приватний ключ, а в приватному ключі є пароль. Ви можете зберігати приватний ключ на веб-сервері, але вам все одно потрібно ввести пароль, коли ви запускаєте Apache. Ви також можете мати облікові дані для певного обладнання, наприклад фізичної картки або HSM, яке можна видалити або заблокувати після запуску сервера. (Звичайно, недоліком цього методу є те, що сервер не може перезапуститись самостійно, якщо щось трапиться. Я вважаю за краще це перед ризиком пошкодити свою систему, але ваш пробіг може відрізнятися ...)

Якщо сценарій запускається з cron, це складна частина. Ви не хочете, щоб облікові дані лежали в будь-якій точці вашої системи, де хтось може отримати до них доступ, - але ви хочете, щоб вони лежали, щоб ваш скрипт мав доступ до них, правда? Ну, не зовсім правильно. Поміркуйте, що саме робить сценарій. Які дозволи потрібні для бази даних? Чи можна його обмежити, щоб не було значення, чи не так пов’язана неправильна людина з цими дозволами? Чи можете ви замість цього запустити скрипт безпосередньо на сервері БД, до якого ніхто інший не має доступу, а не на сервері, на якому є інші користувачі? Якщо з якихось причин, про які я не можу придумати, у вас абсолютно повинен бути запущений сценарій на незахищеному сервері, і він повинен бути в змозі зробити щось небезпечне / руйнівне ... зараз настав час переосмислити свою архітектуру.

По-п’яте , якщо ви цінуєте безпеку вашої бази даних, ви не повинні запускати ці сценарії на серверах, до яких інші люди мають доступ. Якщо хтось увійшов у вашу систему, то він матиме можливість отримати доступ до ваших облікових даних. Наприклад, у випадку веб-сервера з сертифікатом SSL існує принаймні теоретична можливість того, що хтось зможе отримати корінь та отримати доступ до області пам'яті процесу httpd та витягнути облікові дані. Останнім часом був принаймні один подвиг, коли це можна було зробити через SSL, навіть не вимагаючи входу зловмисника.

Також розглядайте можливість використання SELinux або apparmor або будь-якого іншого, що доступне для вашої системи, щоб обмежити, які користувачі можуть робити. Вони дозволять вам заборонити користувачам навіть намагатися підключитися до бази даних, навіть якщо їм вдасться отримати доступ до облікових даних.

Якщо все це здасться вам надмірним , і ви не можете дозволити собі або не маєте часу на це - тоді, на мою думку (зарозумілою та елітарною), у вашій базі даних не слід зберігати нічого важливого чи чутливого. І якщо ви не зберігаєте нічого важливого чи чутливого, то там, де ви зберігаєте свої облікові дані, також не важливо - у такому разі навіщо взагалі використовувати пароль?

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

Перш за все, якщо взагалі є якийсь спосіб, ви можете змінити речі, щоб уникнути необхідності зберігати пароль всередині або поруч зі сценарієм, ви повинні докласти всіх зусиль для цього. Відповідь Джені Д містить багато гарних порад щодо цього.

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

. /usr/local/etc/secret-password-here

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

Інші відповіді стосуються того, як , але я буду розглядати, чи є . Залежно від того, до якої бази даних підключаються ваші користувачі, можливо, у вас вже є відповідний механізм, який вже використовуються цими клієнтськими програмами, і в цьому випадку обов'язково їх використовуйте (я думаю про це ~/.mysqlrcабо ~/.pgpass).

Якщо ви даєте декільком користувачам можливість отримувати доступ до бази даних, щоб робити конкретні запити за допомогою спільного облікового запису, ви, мабуть, не повинні. Натомість переконайтеся, що вони мають облікові записи в базі даних, і щоб ці облікові записи не мали більше дозволів, ніж потрібно (напевно, читайте на більшій частині, і дуже мало доступу для запису). Якщо їм потрібно зробити конкретні запити на певних таблицях, до яких вони не можуть отримати доступ, надайте збережені процедури, SECURTY DEFINERщоб вони могли це зробити.

Якщо жодне з перерахованого вище не уникає необхідності зберігання облікових даних, тоді прочитайте інші відповіді тут.

Ваша ідея про приховування пароля у важкодоступному місці може бути нормальною залежно від обставин.

Якщо інформація є окремою, це означає просте редагування файлу, наприклад, під час перегляду коду з колегою його не збираються показувати. Але зрозумійте, що кожен, хто має доступ до вашого облікового запису, може легко знайти такий файл. Я використовував підкаталог ~/.sshдля таких цілей з тієї простої причини, яка sshскаржиться, якщо права доступу до ~/.sshних недостатньо обмежені.

Однак можна вчинити і для запобігання такому огляду імені користувача та / або паролів.

Замутнення : Якщо ви не хочете, щоб хтось читав ім’я користувача або пароль під час редагування сценарію, ви можете помістити його в текст, але не як звичайний текст, а затуманений. Якщо затуманена версія досить довга, що перешкоджає її запам'ятовуванню тим, хто дивиться на неї, це не може бути відомо, навіть якщо метод і ключ розшифровки помітні. Звичайно, це все-таки тривіально обійде хтось, хто має доступ до вашого облікового запису.

Використання GPG :

Трохи краще, але все ж не повний доказ проти атак кореневого користувача на вашу систему - це зашифровувати пари імен користувачів / паролів у вашому gpgзагальнодоступному файлі та мати сценарій, щоб отримати вміст у файлі (можливо, підкажіть вам пароль, якщо ні кешоване / минуло) Я використовую ggp-карту, щоб, коли я покину ноутбук, але витягнув картку, доступ неможливий, навіть якщо шпилька все-таки буде кешована. Принаймні, якщо я запускаю річ 20 разів за кілька хвилин, я повинен надати шпильку лише один раз.

Безпека, здається, завжди обернено пов'язана зі зручністю (налаштування та використання).

Існує спосіб зберігати паролі в bash-скрипті, але вам потрібно зашифрувати і затуманити сценарій, щоб ніхто не зміг його прочитати чи запустити на ньому будь-який тип налагоджувача, щоб точно побачити, що він робить. Щоб зашифрувати та приховати скрипт bash / shell та зробити його справді виконуваним, спробуйте скопіювати його та вставити тут:

http://www.kinglazy.com/shell-script-encryption-kinglazy-shieldx.htm

На вищезгаданій сторінці все, що вам потрібно зробити, - це надіслати свій сценарій (ви можете спочатку надіслати зразок сценарію для душевного спокою). Для вас буде створено поштовий файл. Клацніть правою кнопкою миші на посилання для завантаження та скопіюйте вказану URL-адресу. Потім перейдіть до свого вікна UNIX і виконайте наступні дії.

Установка:

1. wget посилання на zip-файл

2. распакуйте нещодавно завантажений zip-файл

3. cd / tmp / KingLazySHIELD

4. ./install.sh / var / tmp / KINGLAZY / SHIELDX- (ваше-сценарій-ім'я) / home / (ваше-ім’я користувача) -force

Що вищезгадана команда встановлення зробить для вас:

1. Він встановить зашифровану версію вашого сценарію в каталог / var / tmp / KINGLAZY / SHIELDX- (ваше-скрипт-ім'я).

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

3. Забезпечує, що НІхто НЕ може змінити сценарій - Будь-які спроби змінити зашифрований скрипт приведуть його в непридатність ... до тих пір, поки ці спроби не будуть припинені або усунені. Він навіть може бути налаштований на сповіщення про те, коли хтось намагається зробити що-небудь із сценарієм, крім того, як запустити його, тобто злом або спроби модифікації.

4. Забезпечує абсолютно НІхто НЕ може робити копії. Ніхто не може скопіювати ваш скрипт у відокремлене місце і спробувати закрутити його, щоб побачити, як він працює. Усі копії сценарію повинні містити посилання на вихідне місце, яке ви вказали під час встановлення (крок 4).

ПРИМІТКА:

Я не вірю, що це працює для інтерактивних скриптів, які спонукають користувача до відповіді. Значення повинні бути жорстко закодовані в сценарій. Шифрування гарантує, що ніхто не може реально побачити ці значення, тому вам не потрібно турбуватися про це.

Ще одне рішення, не зважаючи на безпеку (я також думаю, що краще зберігати облікові дані в іншому файлі або в базі даних) - зашифрувати пароль gpg і вставити його в скрипт.

Я використовую gpg-пару, що не містить паролів, що я зберігаю в usb. (Примітка. Коли ви експортуєте цю пару ключів, не використовуйте --armor, експортуйте їх у двійковому форматі).

Спочатку зашифруйте свій пароль:

echo -n "pAssw0rd" | gpg --armor --no-default-keyring --keyring /media/usb/key.pub --recipient someone@mail.com --encrypt

Це буде роздрукувати зашифрований gpg пароль у стандартному виході. Скопіюйте все повідомлення та додайте це до сценарію:

password=$(gpg --batch --quiet --no-default-keyring --secret-keyring /media/usb/key.priv --decrypt <<EOF 
-----BEGIN PGP MESSAGE-----

hQEMA0CjbyauRLJ8AQgAkZT5gK8TrdH6cZEy+Ufl0PObGZJ1YEbshacZb88RlRB9
h2z+s/Bso5HQxNd5tzkwulvhmoGu6K6hpMXM3mbYl07jHF4qr+oWijDkdjHBVcn5
0mkpYO1riUf0HXIYnvCZq/4k/ajGZRm8EdDy2JIWuwiidQ18irp07UUNO+AB9mq8
5VXUjUN3tLTexg4sLZDKFYGRi4fyVrYKGsi0i5AEHKwn5SmTb3f1pa5yXbv68eYE
lCVfy51rBbG87UTycZ3gFQjf1UkNVbp0WV+RPEM9JR7dgR+9I8bKCuKLFLnGaqvc
beA3A6eMpzXQqsAg6GGo3PW6fMHqe1ZCvidi6e4a/dJDAbHq0XWp93qcwygnWeQW
Ozr1hr5mCa+QkUSymxiUrRncRhyqSP0ok5j4rjwSJu9vmHTEUapiyQMQaEIF2e2S
/NIWGg==
=uriR
-----END PGP MESSAGE-----
EOF)

Таким чином, лише якщо usb встановлено в системі, пароль можна розшифрувати. Звичайно, ви також можете імпортувати ключі до системи (менш захищені або взагалі відсутність безпеки) або захистити приватний ключ паролем (так що його неможливо автоматизувати).

#!/bin/bash
unset username
unset password
unset dbname
echo -n "username:"
read username
echo -n "dbname:"
read dbname
prompt="password:"

    while IFS= read -p "$prompt" -r -s -n 1 char
            do
                    if [[ $char == $'\0' ]]
                            then
                                    break
                    fi
                    prompt='*'
                    password+="$char"
            #       read -s -p "Enter Password: "  pswd
            #       echo -e "\nYour password is: " $pswd
            done

Я не вірю, що вам слід зберігати пароль. Я не можу придумати жодної вагомої причини для цього. Швидше, ви повинні зберігати солоний хеш цього пароля - деяку рядок, який надійно створюється деякою функцією, коли вихідний пароль передається як вхідний, але ніколи не пароль .