Zabezpieczanie hasła DB w php

Question

Jestem nowy w tworzeniu stron internetowych. Ciekawi mnie, jak ludzie to robią.

Piszę kod php, który używa mysql DB. Mam hasło zakodowane w kodzie od teraz. Ten kod może zostać wyewidencjonowany przez wszystkich programistów, dzięki czemu każdy ma dostęp do hasła. Wydaje mi się bardzo nie tak. Ponadto mogę wymyślić pewne komplikacje. Zamieszczam listę problemów w formie bullet point -

1. Hasło zapisane w kodzie jest błędne. Nie chcę, aby wszyscy deweloperzy mieli do niego dostęp, ponieważ wszyscy mogą sprawdzić kod.

2. Jak rozróżnić między serwerami produkcyjnymi i programistycznymi/poświadczeniami? Mam ten sam plik zawierający dane uwierzytelniające prod i dev DB. Jaki jest najlepszy sposób, aby sobie z tym poradzić?

3. Chcę zapobiec przed leniwymi/pijanymi czasami, aby twórcy nie usuwali/upuszczali tabel itp. Oczywiście mogę mieć różny dostęp do różnych programistów. Czy to rozwiązanie tego wszystkiego?

Możliwe rozwiązanie: Nie wpisuj hasła w kodzie. Poproś programistów o samodzielne dodanie hasła i upewnienie się, że nigdy się nie zalogował.

Problem z rozwiązaniem: żmudny proces wdrażania. Należy ręcznie wprowadzić hasło do wdrożenia produkcji/kontroli jakości i upewnić się, że jest ono w stanie połączyć się z bazą danych za każdym razem przed wdrożeniem. Brzmi zbyt bolesne i podatne na błędy. Co zwykle robią ludzie?

Również na tej samej notatce (rodzaj związany z powyższym pytaniu)

1. Jeśli masz 4 devs w zespole jaki sposób skonfigurować środowisko dev? Czy wszyscy korzystają z tego samego DB? Jeśli nie, w jaki sposób tworzysz tabele i zapełniasz tabele danymi testowymi? Czy musisz napisać kod, aby wypełnić dane testowe?

Wielkie dzięki za wszelkie dane wejściowe.

Answer 1

Hasło należy umieścić w osobnym pliku PHP zawierającym wszystkie ustawienia aplikacji i umieścić je na górze strony. Ten plik może być przechowywany poza kontrolą wersji i zastąpiony dla każdego wdrożenia.

Upewnij się, że przechowujesz plik config.php (lub jakkolwiek go nazwałeś) z katalogu głównego, tak aby nie mógł przypadkowo zostać wyświetlony żadnym użytkownikom Twojej aplikacji. Ponadto, jako dodatkowy środek ostrożności, upewnij się, że dasz mu rozszerzenie .php, tak, że jeśli w jakiś sposób nadal zostanie udostępnione, powinno zostać najpierw przetworzone przez PHP, a wszelkie przydatne informacje (z nadzieją) usunięte - powszechną praktyką byłoby aby nazwać go rozszerzeniem .conf.php lub .inc.php z tego powodu.

Jeśli chodzi o środowisko Dev, używamy jednej bazy danych współużytkowanej przez wszystkich programistów. Pierwotnie został stworzony z danych klienta na żywo, sklonowanych w naszej bazie danych, z pewnymi informacjami zredagowanymi/zastąpionymi ze względu na prywatność. Ta sama baza danych jest używana w naszej kompilacji programistycznej, a także w naszych kompilacjach lokalnych.

Answer 2

W tej sytuacji można napisać skrypt wdrażania, który automatycznie "zapełnia" hasło we właściwym miejscu kodu źródłowego. Następnie hasła produkcyjne będą znajdować się tylko w skryptach wdrażania środowiska produkcyjnego. Twórcy mogą ręcznie dodawać go do swoich lokalnych środowisk.

Ponadto, możesz mieć plik konfiguracyjny ze wszystkimi tymi ustawieniami i mieć aplikację do załadowania ich z niego lub nawet osobny plik php, jak sugeruje ktoś inny. Plik konfiguracyjny/php nie powinien być kontrolowany przez źródło, a każdy programista może sam zrobić, i możesz mieć poprawny w produkcji.

Answer 3

Często jest to rozwiązywane przez posiadanie zarówno wersji rozwojowej, jak i produkcyjnej pliku konfiguracyjnego. Wersja produkcyjna zawiera informacje o połączeniu dla programistycznej bazy danych (nazwa serwera, nazwa bazy danych, nazwa użytkownika, hasło). Ten plik może być przeglądany przez wszystkich programistów.

Wersja produkcyjna zawiera informacje o połączeniu dla serwera produkcyjnego i jest nieczytelna dla niezaufanych programistów. Po wdrożeniu kodu w lokacji produkcyjnej nie wdrażaj wersji rozwojowej pliku konfiguracyjnego. Wersja serwera produkcyjnego pozostanie nienaruszona.

Można rozważyć całkowite usunięcie pliku konfiguracyjnego z kontroli wersji. Korzystając z tego schematu, każdy programista zachowa własną wersję lub będzie mógł uzyskać dostęp do wersji rozwojowej ze standardowej lokalizacji.