Czy pliki konfiguracyjne serwera/bazy danych, w tym hasła, powinny być przechowywane w kontroli źródła?

Pomijając kwestię, że hasła nigdy nie powinny być przechowywane w zwykłym tekście w dowolnym miejscu (poza czyjąś czaszką lub zamkniętym skarbcem dostępnym tylko dla CEO, CFO i CIO (i potrzebującym wszystkich trzech kluczy jednocześnie)), powinieneś przechowywać wszystko w kontroli źródła, które jest wymagane do zbudowania Twojego produktu.

Oznacza to nie tylko twoje źródło, ale nawet specyfikacje maszyn budowlanych, opcje kompilatorów, same kompilatory i tak dalej.

If we could znajdź sposób, aby sprawdzić w fizycznym sprzęcie, my też to zrobimy: -)

Wszystko, co może być odtworzone przez sam proces budowania, lub cokolwiek dla Uruchamianie zamiast budowania oprogramowania (takiego jak twoje hasła), zazwyczaj nie podlega kontroli źródłowej, ale niektóre sklepy zrobią to dla swoich plików wykonywalnych, wygenerowanych dokumentów itp., tylko po to, aby mogli szybko uzyskać konkretne wydanie do instalacji.

Hasła nie powinny być przechowywane w kontroli źródła. W ogóle. Nigdy. Zobacz Jak zachować tajemnice w tajemnicy

Hasła, Nazwy serwerów itp. są częścią konfiguracji wdrożenia wykonywanej przez administratora serwera. Konieczne jest udokumentowanie tej procedury i poddanie udokumentowanej procedury kontroli.

Alternatywnie konfiguracja wdrożenia może być wykonana przez skrypt, który sysadmin uruchomi, aby wykonać konfigurację, a podczas skryptu wykonanie poprosi sysadmin o podanie wymaganych informacji. Ponownie ten skrypt musi być utrzymywany w kontroli wersji.

Wszystko inne, poza konfiguracją serwera musi być pod kontrolą źródła.

Przechowywanie konfiguracji serwera w source control jest generalnie złym pomysłem, ponieważ przeszkadza to we wdrożeniach i może powodować małe katastrofy (np. gdy ktoś nie zdaje sobie sprawy, że jego wersja testowa wdrożona z source control komunikuje się z live serwis).

Zawsze przechowuj te pliki konfiguracyjne poza webrootem.

Zaufane połączenia mogą być opcją, pozwalającą znanym adresom IP łączyć się z usługami poprzez konfigurację tej usługi..

• podczas pracy w systemie Windows Użyj uwierzytelniania zintegrowanego. Zobacz zabezpieczenie dostępu do danych
• MySQL skonfiguruj tak, aby zezwalał na połączenia z localhost i nie wymagał hasła. Zobacz Krok 7: zabezpieczenie serwera MySQL w systemie Windows
• PostgreSQL możesz użyć ~/.pgpass .

Ogólnie, zgadzam się z paxdiablo: umieścić wszystko, co możliwe pod kontrolą źródła. Obejmuje to pliki konfiguracyjne produkcji z poświadczeniami bazy danych.

Pomyśl o sytuacji, w której twój serwer ulega awarii, kopie zapasowe okazują się złe i musisz przywrócić ten serwer. Myślę, że ty i twój Klient (lub szef) zdecydowanie zgodzilibyście się, że posiadanie wszystkiego, co potrzebne do wdrożenia witryny w kontroli źródeł, jest dużym plusem.

Jeśli chcesz łatwo budować instalowalne pakiety z Twoich źródeł przy użyciu ciągłej integracji (Inna najlepsza praktyka) będziesz musiał umieścić pliki konfiguracyjne pod kontrolą źródeł.

Należy również wziąć pod uwagę, że w większości przypadków programiści, którzy mają dostęp do kontroli źródła, nie mogą uzyskać dostępu bezpośrednio do produkcyjnego serwera bazy danych. Hasła produkcyjne są dla nich bezużyteczne.

Jeśli niewłaściwi ludzie uzyskali dostęp do Twoich źródeł, nadal muszą uzyskać dostęp do serwera produkcyjnego, aby zaszkodzić hasła. Tak więc, jeśli twoje środowisko produkcyjne jest odpowiednio chronione, zagrożenia bezpieczeństwa związane z hasłami w kontroli źródeł są bardzo ograniczone.

Myślę, że to pytanie dotyczy bardziej własności informacji, zaufania i organizacji. Powinieneś zadać sobie pytanie, jakiej części twojej organizacji ufałbyś, aby Twoje hasła systemowe były bezpieczne przed ujawnieniem i nadużyciem?

Byłem w organizacjach, gdzie były trzymane przez ludzi odpowiedzialnych za biznes. W innych przypadkach zostały one przekazane zespołowi operacyjnemu, który posiadał również procesy związane z tworzeniem i użytkowaniem itp.

Najważniejsze jest to, że jest jasno określone w organizacji, kto powinien mieć dostęp do haseł systemowych. Następnie możesz zdecydować się na odpowiednie rozwiązania techniczne do ochrony haseł.

Nie. Hasło produkcyjne należy skonfigurować bezpośrednio na serwerze. Należy utworzyć instrukcje wdrażania dla zespołu wdrożeniowego/osoby, aby zmienić odpowiedni plik właściwości podczas wdrażania.

Stwierdziłem, że użycie skryptu build (w moim przypadku Phing) było najlepszym sposobem wprowadzania haseł.

W moim Subversion repos dla PHP, pliki konfiguracyjne zawierające hasła są sprawdzane jako config.php.sample ze wskazówkami do tego, co należy podać, a Skrypty opierające się na PHP wymagają obecności config.php w tym samym miejscu.

Repozytorium jest skonfigurowane tak, aby ignorować config.php dla tego katalogu, aby uniknąć "przypadkowych" dodawania lub sprawdzania.

Przykładowy plik konfiguracji, oczywiście, poddałbym je kontroli wersji. Ale zazwyczaj nie z danymi dostępowymi realworld, takimi jak adresy serwerów lub hasła. More somethinglike

# program.conf
#
# mysql option for $myprog.
#
#SERVER_ADDR=127.0.0.1
#SERVER_USER=mysql
#SERVER_PASSWD=abcdef

Problemy z hasłami w kodzie źródłowym:

• trudno się różnić od jednego wdrożenia do drugiego (nie chcę modyfikować kodu źródłowego w produkcji)
• zwiększone prawdopodobieństwo przypadkowego uszkodzenia bazy danych produkcji podczas tworzenia
• problem z bezpieczeństwem (w większości sklepów nie ma powodu, aby Kod/Programiści znali hasła prod)
• zmiana hasła wymaga przesunięcia

To co znalazłem działa najlepiej to sprawdzanie config w tym wykorzystuje domyślne wartości mixture sane i symbole zastępcze dla danych specyficznych dla wdrożenia. Nasze aplikacje zawsze szukają konfiguracji systemowej, która pozwala na nadpisanie dowolnej zmiennej. Dzięki temu maszyna produkcyjna może mieć konfigurację odpowiednią do jej wdrożenia.

Uwaga: kiedy funkcjonuję jako administrator, zawsze zarządzam configami oddzielnie od kodu (nie bez powodu).

Zawsze wykluczałbym istotne pliki konfiguracyjne, które zawierają hasła lub inne szczegóły dostępu (jak w przypadku baz danych), to czysta najlepsza praktyka. Do tego Kontrola źródeł i wersji służy zwykle więcej niż jednemu użytkownikowi i nie wszyscy pracują z tymi samymi danymi bazy danych lub nawet z tym samym konfiguracją serwera (domeny itp.) i w tym celu pliki konfiguracyjne powinny pozostać wyłączone z tej całej partii.

Bez odpowiedniego procesu budowania, używam tej strategii (dla aplikacji PHP):

1. Stwórz folder /etc/companyname

2. W nim umieść dwa pliki:

   <?php // env.php
   return 'prod'; 
   

   <?php // appname-prod.php
   return array(
     'db' => array( /* credentials */ ),
     /* other host-specific conf data */
   ); 
   

3. Aby oba pliki były czytelne tylko przez proces PHP

Teraz plik konfiguracyjny Twojej aplikacji będzie wyglądał następująco:

<?php // config.php
$env = (require "/etc/companyname/env.php");
$creds = (require "/etc/companyname/appname-{$env}.php");

W tym miejscu środowisko definiuje używane poświadczenia i można przenosić Kod między wstępnie skonfigurowanymi środowiskami(i kontrolować niektóre opcje za pomocą $env). Oczywiście można to zrobić za pomocą zmiennych środowiskowych serwera, ale to a) jest prostsze w konfiguracji i b) nie ujawnia poświadczeń każdemu skryptowi na serwerze (nie pojawi się w bezpańskich śmieciach debugujących, takich jak phpinfo()).

Dla łatwiejszego czytania poza PHP możesz zrobić pliki uwierzytelniające JSON lub coś takiego i po prostu znosić mały hit wydajności (APC nie będzie ich buforować).

Wolę mieć plik local_settings obok głównego pliku settings . To local_settings nie powinno być dodawane do repozytorium, ale dodam próbkę .local_setting do repozytorium, aby pokazać strukturę tego pliku.

W czasie wykonywania, jeśli istnieje local_settings, jego wartości nadpisują wartości głównego pliku ustawień.

Na przykład w python:

Settings.py:

log='error.log'
db=lambda:None
db.host='localhost'
db.user=''
db.password=''

try:
    import local_settings
except ImportError:
    pass

Local_settings.py:

from settings import *

db.user='abcd'
db.password='1234'