Gdzie przechowywać referencje bazy danych w aplikacji internetowej?

Question

Zastanawiam się, jakich technik używasz do przechowywania poświadczeń bazy danych dla swojej aplikacji. Szczególnie interesują mnie aplikacje webowe Java, ale nie sądzę, że istnieje potrzeba ograniczenia tych pytań.

rzeczy do rozważenia:
Czy używasz plików właściwości, konfiguracji xml, innych?
Czy jest dołączany do aplikacji (np. W pliku jar) lub przechowywany osobno w systemie plików?
Czy hasło jest szyfrowane? Jeśli tak, jakiego schematu szyfrowania używasz?

Answer 1

W środowisku Java pule połączeń z bazą danych powinny zostać przekazane do kontenera przez aplikacje webapp. Jest to standard deklarowany w WEB-INF/web.xml jako zasoby. To samo dotyczy sesji pocztowych i innych zasobów zewnętrznych, które mogą się różnić w zależności od instalacji. Zajrzyj do JNDI po więcej informacji na ten temat)

Przyjemną częścią jest to, że aplikacja nie dba o to, jak połączyć się z czymkolwiek na zewnątrz. Nie zobaczy żadnych haseł, ponieważ sam je użyje.

W tomcat jest to skonfigurowane z plików kontekstowych (np.) W conf/Catalina/localhost /, conf/server.xml lub - najlepiej tylko w środowiskach deweloperów, z webappów META-INF/context.xml. Inne środowiska mają swoją własną lokalizację konfiguracji lub aplikację.

Szyfrowanie haseł zależy od kontenera. Tomcat przechowuje je w zwykłym tekście, ale sama aplikacja tego nie zobaczy. Nie wiem o mechanice w innych środowiskach.

Answer 2

Zależy od serwera aplikacji.

Zazwyczaj korzystam z wyszukiwań JNDI dla źródła danych, więc poświadczenia są przechowywane na serwerze aplikacji, który obsługuje pulę połączeń. Nie ma potrzeby wstawiania w ten sposób nic poza nazwą JNDI.

Tak, hasło jest szyfrowane w WebLogic.

Rzeczy na Tomcat mogą być ryzykowne. Informacje o połączeniu znajdują się w pliku META-INF/context.xml, co oznacza zwykły tekst dla hasła. Robię to tylko dla rozwoju, nigdy w produkcji.

Answer 3

Ponieważ pozostawiasz pytanie otwarte dla platformy, dodam, że poświadczenia bazy danych dla aplikacji .NET są przechowywane w pliku web.config. Od wersji 2.0 i powyżej istnieje specjalna sekcja ConnectionStrings, która umożliwia łatwiejszy dostęp programowy do ciągu połączenia.

Oprócz tego, że usługi IIS automatycznie blokują bezpośrednie żądania do pliku web.config, można również użyć polecenia IIS do zaszyfrowania sekcji ConnectionString pliku web.config. Szyfrowanie jest specyficzne dla urządzenia, co zwiększa jego moc, a środowisko wykonawcze .NET odszyfrowuje ciąg połączenia w locie, gdy uzyskujesz do niego dostęp, więc nie ma potrzeby dodatkowego kodowania w aplikacji, aby z nim pracować.

Answer 4

W stosie Microsoft rzeczy mogą być bardzo ładne.

Użytkownik tworzy konto użytkownika sieci w usłudze Active Directory bez prawie żadnych uprawnień. Możesz skonfigurować usługi IIS tak, aby uruchamiały aplikację internetową jako ten użytkownik. Udzielasz użytkownikowi prawa do odczytu folderów sieciowych i plików na dysku. Użytkownik konfiguruje program SQL Server, aby nadać mu uprawnienia do odczytu i zapisu dla żądanych tabel. W łańcuchu połączenia poinstruowano klienta db, aby łączył się jako konto użytkownika, na którym aplikacja internetowa jest obecnie uruchamiana.

Jest tylko jedno rzeczywiste konto użytkownika, mimo że jest widoczne w wielu miejscach. To konto użytkownika ma bardzo ograniczone uprawnienia. Nigdzie nie ma żadnych haseł, nawet jeśli są zaszyfrowane. Nie ma żadnej konfiguracji, która musi być wykonana w kodzie, aby to zadziałało (wszystko to w konfigurowaniu uprawnień).

Answer 5

W Django dane uwierzytelniające znajdują się w pliku konfiguracyjnym settings.py. Ponieważ nie jest to zazwyczaj przechowywane w drzewie katalogów /var/www/, jest bardzo bezpieczne.

Również jedna aplikacja Django może być używana (i ponownie używana) w wielu witrynach internetowych lub serwerach internetowych na tym samym hoście, z których każdy ma własne odrębne ustawienia. Tak więc konfiguracja settings.py nie jest dołączona do aplikacji, ale jest częścią pojedynczego wdrożenia aplikacji.

Answer 6

dla ASP.NET:

przechowywać parametry globalne, takie jak ciąg połączenia i repozytorium ścieżki w rejestrze, a następnie odniesienie do wpisu rejestru w pliku web.config.

Głównym powodem jest to, że często uważam, że muszę napisać samodzielny plik wykonywalny do uruchamiania zadań w tle i innych funkcji automatycznych, które wymagają dostępu do tych samych parametrów. Dlatego utrzymanie wszystkiego, co jest prawdziwie globalne w jednym łatwo dostępnym miejscu, ułatwia życie.

Answer 7

Które z tych witryn są dobrym miejscem do przechowywania referencji do bazy danych aplikacji internetowej? W osobnym pliku w kodzie źródłowym W osobnym pliku na serwerze hosta WWW W bazie danych Brak. Poświadczenia bazy danych nigdy nie powinny być przechowywane