Jakie są bezpieczne podejścia do obsługi skryptu, który wymaga hasła bazy danych (MySQL)?

Question

Oczywiście, nie chcemy kodować hasłem jawnego tekstu w każdym skrypcie. To utrudniłoby cykliczne korzystanie z hasła, ponieważ wiele ton skryptów musiałoby zostać zmienionych, oprócz tego, że hasło jest przede wszystkim w postaci zwykłego tekstu.

Jeśli skrypty przyjmują hasło jako parametr, to musimy się martwić o modyfikację wyjścia "ps", aby nie wyświetlać wartości argumentu hasła. Musielibyśmy również martwić się o zapisanie polecenia w historii powłoki. To może być potencjalnie obsługiwane przez HISTIGNORE/HISTCONTROL na bash, ale istnieją inne powłoki używane z różną i mniej elastyczną kontrolą historii (np .: zsh). Możemy również użyć zmiennej środowiskowej specyficznej dla wiersza poleceń (FOO = bar ./script), a gdy 'FOO = pasek' nie pojawi się w 'ps', to domyślnie jest zapisywane w historii powłoki. Poza tym niektóre systemy ujawniają środowiska procesów innych użytkowników (przez "ps").

Można użyć pliku hasła (konfiguracji), który po prostu zapisuje hasło w postaci zwykłego tekstu. Ten plik może być właścicielem/uprawnieniami, aby zwiększyć jego dostęp. Ale na koniec dnia wciąż masz hasło w postaci zwykłego tekstu.

Monitowanie jest również opcją, ale zwykle jest mniej wygodne (nadal możliwe, na przykład, na przykład) i komplikuje brak interakcji, jeśli wymaga tego skrypt.

Można użyć szyfrowania o pewnym smaku, ale nadal mamy podobny problem, aby poradzić sobie z kluczem odszyfrowywania.

Czy powinienem wybrać jedną z powyższych? Czy inne opcje mogą być lepsze? Jak ludzie radzą sobie z tą sytuacją jest bezpieczny sposób?

Głównym celem jest to, że atakujący nie powinien mieć dostępu do serwera bazy danych, jeśli atakujący w jakiś sposób dostanie się do systemu korzystającego z serwera bazy danych. Na przykład, atak nie powinien być w stanie po prostu znaleźć hasła gdzieś leżącego, nie powinien być w stanie obserwować systemu ("ps"), aby go wykryć, i nie powinien móc "patrzeć wstecz". (historia powłoki), aby ją znaleźć.

Uświadamiam sobie, że istnieje miliony scenariuszy (km, zamienione strony, itd. Itd.) I że większość zakładów jest wyłączona, jeśli atakujący ma dostęp root i fizyczny i że nic nie będzie 100% bezpieczne. Po prostu szukam najlepszego podejścia w granicach powodu. :-)

Answer 1

Jeśli skrypty nie używają podpowiedzi i w jakiś sposób znają hasło db, to atakujący może wykonać dowolny skrypt i wykonać te same czynności.

Jeśli poprosisz o hasło, będziesz musiał podać je niektórym osobom, które umieści je w swoich skryptach, lub utworzą hasło dla każdego użytkownika, co zapewni wiele haseł do odgadnięcia (i nadal będą umieszczane w swoich skryptach).

Być może należy wziąć pod uwagę, że użytkownik bez hasła może wykonywać tylko SELECT na odpowiednich tabelach i może logować się tylko z określonych hostów oraz wymagać haseł i innych użytkowników w celu uzyskania bardziej czułych funkcji?

Jeśli chcesz ukryć hasło, zawsze możesz mieć system dwuczęściowy. Chociaż możesz robić bardzo skomplikowane rzeczy, XOR (bitowy wyłączny lub, który jest w perlu i większości innych języków) może być twoim przyjacielem. Jest to proste dla administratora i dla atakującego, żaden kawałek nie jest użyteczny. Zautomatyzowany napastnik może przejść na bardziej żyzny grunt. Możesz nawet zachować jedną z części na innym hoście i pobrać ją za pomocą wget, nfs lub cokolwiek innego. W ten sposób można go wyłączyć w ramach systemu tripwire.

W międzyczasie, być może potrzebujesz jakichś tripwiresów lub honeypotów, więc jeśli złoczyńcy przyjdą, możesz dać im dezinformację, a nawet wyłączyć szybciej. Lubię fail2ban dla aktywnego firewalla. Może skanować pliki dziennika i blokować adresy IP, które wysyłają ci, których nie chcesz, na podstawie tego, co pokazuje się w twoich dziennikach. Używa regexp i dowolnego pliku dziennika, aby zdefiniować incydent i ma pewną elastyczność w mechanizmie reguł.

Answer 2

Nie jestem administratorem systemu Unix, ale ... Co powiesz na to, aby skrypty działały pod kontem bez logowania, i ustaw uprawnienia do skryptu (i pliku haseł) na 500. To ograniczyłoby dostęp do root i użytkownika skryptu.

Answer 3

Może chcesz zbadać TPM (http://en.wikipedia.org/wiki/Trusted_Platform_Module)

Wiele produktów zabezpieczeń TPM używać do przechowywania kluczy związanych z bezpieczeństwem krytyczna. Innym pomysłem może być zaszyfrowanie hasła za pomocą certyfikatu przechowywanego na karcie inteligentnej.

Cheers, GK

Answer 4

Możesz umieścić plik .my.cnf w dir (-ów) macierzystego użytkowników, którzy mogą uzyskać dostęp do skryptu, z ich informacji i mysql może go odczytać stamtąd zamiast polecenia linia. Będziesz musiał ustawić zmienną środowiskową, aby wskazywała na ~/.my.cnf, ale ... Nie jestem pewien, czy to jest MYSQL_HOME, czy SYSCONFDIR, czy coś innego *. Wciąż będzie to zwykły plik tekstowy, ale jeśli ograniczysz ten plik do właściciela, to powinno być dobrze? To będzie przynajmniej zachować hasła z ps.

MySQL: Option Files i MySQL: Password Security strony doc zawierają w tym trochę wskazówki.

(* Disclaimer: Nie jestem administratorem przez jakiejkolwiek definicji, wystarczy mieć kłopoty)

Answer 5

zależności od wagi dane są, można wdrażać różne środki.

Hasło należy przechowywać w pliku do odczytu tylko przez root. Skrypt czytający klucze powinien zaczynać się jako root, odczytać hasło, ustanowić połączenie z bazą danych przy użyciu konta bazy danych z minimalnymi wymaganymi uprawnieniami, wyczyścić hasło z pamięci, a następnie rozwinąć (może pomóc How can I drop privileges in Perl?) na nieuprawnione konto systemowe.

mają proste skrypty/spust monitorować sesje bazodanowe (początek sesji i zakończenia, użytkownika, adres IP) poleceń wykonywanych na serwerze bazy danych, monitorowanie korzystania z sudo w systemie itd