Krótka odpowiedź
Nie możesz.
Jeśli hasło jest przechowywane w artefakcie wysyłanym do użytkownika końcowego, musisz uważaj to za zagrożone! Nawet jeśli artefakt jest skompilowanym plikiem binarnym, zawsze istnieją (mniej lub bardziej skomplikowane) sposoby uzyskania hasła.
Jedynym sposobem ochrony zasobów jest udostępnienie użytkownikowi końcowemu tylko ograniczonego interfejsu API. Zbuduj programistyczny interfejs API (REST, WS+SOAP, RMI, JavaEE+Servlets, ...) lub udostępnij tylko niektóre funkcje w swojej bazie danych za pośrednictwem SPROC (patrz poniżej).
Najpierw kilka rzeczy...
Pytanie nie powinno dotyczyć tego, jak ukryć hasło, ale jak zabezpieczyć bazę danych. Pamiętaj, że same hasła są często bardzo słabą ochroną i nie powinny być uważane za jedyny mechanizm ochrony bazy danych. Czy korzystasz z SSL? Nie? Cóż, to nawet jeśli uda Ci się ukryć hasło w kodzie aplikacji, nadal łatwo jest je powąchać w sieci!
Masz wiele opcji. Wszystkie o różnym stopniu bezpieczeństwa:
„Rola aplikacji”
Utwórz jednego użytkownika bazy danych dla aplikacji. Zastosuj autoryzację dla tej roli. Bardzo powszechną konfiguracją jest zezwalanie tylko na operacje CRUD.
Zalety
- bardzo łatwy w konfiguracji
- Zapobiega
DROPzapytania (np. w iniekcjach SQL?)
Wady
- Każdy, kto widzi hasło, ma dostęp do wszystkich danych w bazie danych. Nawet jeśli te dane są zwykle ukryte w aplikacji.
- Jeśli hasło zostanie naruszone, użytkownik może uruchomić
UPDATEiDELETEzapytania bez kryteriów (np. usuń/zaktualizuj całą tabelę naraz).
Uwierzytelnianie atomowe
Utwórz jednego użytkownika bazy danych na każdego użytkownika aplikacji/użytkownika końcowego. Pozwala to zdefiniować atomowe prawa dostępu nawet na podstawie kolumny. Na przykład:Użytkownik X może wybrać tylko kolumny daleko i baz z tabeli foo. I nic więcej. Ale użytkownik Y może SELECT wszystko, ale bez aktualizacji, podczas gdy użytkownik Z ma pełny dostęp do CRUD (wybierz, wstaw, zaktualizuj, usuń).
Niektóre bazy danych umożliwiają ponowne użycie poświadczeń na poziomie systemu operacyjnego. Dzięki temu uwierzytelnianie dla użytkownika jest przejrzyste (wystarczy zalogować się do stacji roboczej, a tożsamość ta jest następnie przekazywana do bazy danych). Działa to najłatwiej w pełnym stosie MS (OS=Windows, Auth=ActiveDirectory, DB=MSSQL), ale - o ile mi wiadomo - jest również możliwe do osiągnięcia w innych bazach danych.
Zalety
- Dość łatwe do skonfigurowania.
- Bardzo atomowy schemat autoryzacji
Wady
- Ustawianie wszystkich praw dostępu w DB może być żmudne.
- Użytkownicy z
UPDATEiDELETEprawa mogą nadal przypadkowo (lub celowo?) usunąć/zaktualizować bez kryteria. Ryzykujesz utratę wszystkich danych w tabeli.
Procedury przechowywane z atomic auth&auth
Napisz nie Zapytania SQL w Twojej aplikacji. Uruchom wszystko poprzez SPROC. Następnie utwórz konta bazy danych dla każdego użytkownika i przypisz uprawnienia do tylko SPROC .
Zalety
- Najbardziej skuteczny mechanizm ochrony.
- SPROC mogą zmusić użytkowników do przekazywania kryteriów do każdego zapytania (w tym
DELETEiUPDATE)
Wady
- nie jestem pewien, czy to działa z MySQL (moja wiedza w tym obszarze jest niepewna).
- złożony cykl rozwoju:wszystko, co chcesz zrobić, musi najpierw zostać zdefiniowane w SPROC.
Ostateczne przemyślenia
Nigdy nie należy zezwalać aplikacji na zadania administracyjne bazy danych. W większości przypadków jedyne operacje, których potrzebuje aplikacja, to SELECT , INSERT , DELETE i UPDATE . Jeśli zastosujesz się do tej wskazówki, nie ma ryzyka, że użytkownicy odkryją hasło. Z wyjątkiem punktów wymienionych powyżej.
W każdym razie zachowaj kopie zapasowe. Zakładam, że chcesz zaprojektować swoją bazę danych przed przypadkowym usunięciem lub aktualizacją. Ale wypadki się zdarzają... miej to na uwadze;)
