Nie jestem jeszcze przyzwyczajony do sposobu, w jaki działa Git (i zastanawiam się, czy ktoś oprócz Linusa jest;)).

Jeśli używasz Heroku do hostowania aplikacji, musisz sprawdzić kod w repozytorium Git. Jeśli pracujesz nad projektem typu open source, najprawdopodobniej udostępnisz to repozytorium na Github lub innych hostach Git.

Niektóre rzeczy nie powinny być sprawdzane w publicznym repozytorium; hasła do baz danych, klucze API, certyfikaty itp. Ale te rzeczy nadal muszą być częścią repozytorium Git, ponieważ używasz go do przesyłania kodu do Heroku.

Jak pracować z tym przypadkiem użycia?

Uwaga: Wiem, że Heroku lub PHPFog mogą używać zmiennych serwera, aby obejść ten problem. Moje pytanie dotyczy bardziej „ukrywania” części kodu.

Preferowaną metodą utrzymywania w tajemnicy haseł / kluczy interfejsu API w heroku jest ustawienie wartości konfiguracji za pomocą aplikacji wiersza polecenia heroku. Poniższy przykład zaczerpnięty z artykułu w centrum twórców heroku

(Poniższy przykład i cała moja odpowiedź dotyczą aplikacji Railsowych)

$ cd myapp
$ heroku config:add S3_KEY=8N029N81 S3_SECRET=9s83109d3+583493190
Adding config vars and restarting myapp... done, v14
S3_KEY:     8N029N81
S3_SECRET:  9s83109d3+583493190

Następnie odwołaj się do tych wartości konfiguracji w swoim kodzie, używając zmiennej ENV []

AWS::S3::Base.establish_connection!(
  :access_key_id     => ENV['S3_KEY'],
  :secret_access_key => ENV['S3_SECRET']
)

W ten sposób wrażliwe hasła nie są przechowywane w repozytorium git. (Uwaga: uruchamiając aplikację lokalnie, ustaw te wartości w swoim .bashrcpliku

Ponadto nie jestem pewien, jakiego typu aplikację używasz, ale w Railsach heroku nie używa pliku database.yml, po prostu ustawia nazwę użytkownika / hasło bazy danych zgodnie z ustawieniami aplikacji. Możesz więc uniknąć zapisywania tych danych w git

Ponadto, jeśli uruchamiasz własną aplikację i chcesz, aby pozostała prywatna, świetną alternatywą dla github jest bitbucket, który oferuje bezpłatne prywatne repozytoria.

Kilka pomysłów ... Kryptografia klucza publicznego jest najbardziej elastyczną odpowiedzią.

Zaciemnianie (tylko dla kodu)

W przypadku części kodu, które chcesz ukryć, czy możesz umieścić je w innym projekcie, skompilować je i wpisać tylko skompilowany kod, a nie źródło? To nie jest szyfrowanie i nie nadaje się do szyfrowania haseł lub kluczy. Ludzie nadal mogą poddawać inżynierii wstecznej skompilowany kod, ale nie otrzymują źródła.

Prywatne repozytorium GIT

Czy to musi być publiczne repozytorium git?

Pamięć serwera

Czy możesz zapisać te informacje w chronionym pliku w katalogu osobistym konta użytkownika, na którym działa aplikacja? Skopiowałbym sposób, w jaki ssh robi to za pomocą ~ / .ssh / id_rsa i chmod 600. W przeciwnym razie można użyć zmiennej środowiskowej. Potrzebujesz gdzieś na serwerze do przechowywania jakiegoś klucza lub nie ma sposobu, abyś mógł cokolwiek chronić.

Kryptografia symetryczna (tylko dla Ciebie)

Jeśli jesteś jedynym programistą, możesz umieścić klucz na serwerze i mieć ten sam klucz na swoim komputerze oraz użyć symetrycznego schematu szyfrowania w celu ochrony niektórych danych, takich jak hasło lub certyfikat. Dzielenie się symetrycznym kluczem z przyjaciółmi staje się nieuporządkowane.

Kryptografia asymetryczna (dla wielu programistów)

Jeśli inni programiści muszą sprawdzić tajne rzeczy w publicznym repozytorium git, dla tego rodzaju rzeczy stworzono kryptografię klucza publicznego / klucza prywatnego (asymetrycznego). Zainstaluj klucz prywatny na swoim serwerze (nie zaznaczaj go w celu kontroli źródła!) I wygeneruj z niego klucz publiczny. Zaszyfruj swoje tajne dane za pomocą klucza publicznego serwera. Tylko serwer może odszyfrować te dane za pomocą swojego klucza prywatnego. Możesz nawet sprawdzić klucz publiczny w celu kontroli źródła, aby inne osoby mogły szyfrować dane przy użyciu tego samego klucza publicznego i tylko serwer może go odszyfrować.

Narzędzie

Openssl jest prawdopodobnie jedynym narzędziem do kryptografii, jakiego kiedykolwiek potrzebujesz. Nie pisz własnego algorytmu kryptograficznego ani własnej implementacji opublikowanego algorytmu.

Zamykanie myśli

Jeśli „serwer” to serwer sieciowy korzystający z protokołu https, powinieneś już mieć na serwerze bezpieczny plik kluczy do przechowywania klucza prywatnego. To oszałamiające, że firma hostingowa nie uwzględniła to. Może mają jakieś wskazówki, w jaki sposób inni rozwiązują wyzwanie, przed którym stoisz?

Jeśli chcesz uruchomić swój kod na Heroku, musisz mu go dać - nie możesz ukryć go przed dostawcą hostingu.

Jeśli chodzi o publiczne repozytoria git, jeśli twój projekt jest open source, ale nie chcesz udostępniać szczegółów hostingu, będziesz musiał zachować prywatny rozwidlenie swojego projektu na potrzeby wdrożenia.

Nie powinieneś ukrywać części kodu. Bezpieczeństwo twojego systemu nie powinno polegać na tajności kodu; jest to znane jako „bezpieczeństwo przez zaciemnienie”, na co eksperci od bezpieczeństwa czują się źle, ponieważ działa bardzo słabo.

Zamiast tego hasła, klucze kryptograficzne itp. Należy przechowywać oddzielnie od kodu. Przechowuj je w osobnym pliku konfiguracyjnym lub wartości konfiguracyjnej odczytywanej przez kod. Nie musisz ich przechowywać w git.

Ważne: Nigdy nie koduj kluczy kryptograficznych, haseł ani innych tajemnic w kodzie źródłowym! To bardzo zła praktyka.

Zobacz też:

• Jak projekty open source radzą sobie z bezpiecznymi artefaktami?

• Hasło w pliku .php

• Standardy szyfrowania haseł w plikach konfiguracyjnych?

• Open Source i jak działa w przypadku bezpiecznych projektów?

• Jak chronić informacje o koncie ftp w kodzie źródłowym programu

• Czy to bezpieczny sposób deklarowania parametrów DB w htaccess, a nie w pliku PHP?

Wtyczka: IT Security.SE to świetne miejsce do zadawania pytań na temat bezpieczeństwa!