Witam,
Mam takie pytanie, czy jest jakiś sposób przed zabezpieczeniem bazy Progressa przed dostępem do niej z edytora procedur lub klienta shellowego? Wiem jak zabezpieczyć bazę z DBAUTHKEY przed uruchamianiem na niej nie-naszych r-kodów. Ale jeżeli klient podstawi do instalacji Progressa swoją licencję developerską, to może uruchomić edytor procedur i wykonać na bazie dowolny kod, czy może mylę się? Dodatkowym problemem jest przechowywanie hasła w pliku PF, czy to czystego czy zakodowanego, nadal ten plik umożliwia dostęp do bazy danych. Czy jest ktoś w stanie mi polecić jakieś rozwiązania uniemożliwiające klientowi dostęp bezpośredni do bazy?
Pozdrawiam.
Jeśli zmiana loginu/hasła do bazy wchodzi w grę to najprostszą metodą jest zaszycie nazwy użytkownika i jego hasła w aplikacji i łączenie się z bazą danych z jej poziomu. Namiary na bazę danych (host, port) można do aplikacji przekazać jako parametry.
Można to rozwinąć np do dwóch zdefiniowanych użytkowników bazy. Jeden służy tylko do inicjowania połączenia i ma dostęp w bazie do określonej porcji informacji służącej do wyznaczania hasła pełnego dostępu. Po połączeniu się (jawnym użytkownikiem) aplikacja wyznacza hasło dostępu i przełącza się na się na drugiego użytkownika. Do tego dochodzi jeszcze oczywiście sprawa zarządzania hasłem drugiego użytkownika (np jego zmiana). Metoda dobra w określonych przypadkach, ponieważ deweloper może wykazać, że nie posiada dostępu (nie zna hasła) do danych klienta.
Od wersji OE 10.1 czy 10.2 można po zdefiniowaniu użytkowników w bazie i nadaniu im uprawnień (które obowiązują tylko dla kompilacji) przenieść te uprawnienia na runtime. W Data Administration, opcja Admin -> Database Options. Trzeba zaznaczyć Use Runtime Permissions Checking i oczywiście Disallow Blank UserID Connections.
Ale to nadal nie zabezpiecza przed użyciem własnych licencji deweloperskich i odpalenie na bazie np. _desk.p czy chociażby mpro i ręczne napisanie kodu i go wykonanie. A przypomnę tylko, że hasło do bazy jest zapisane w pliku PF, który jest do odczytu - niestety - dla każdego. Mój problem polega właśnie na tym, że klient ma dostęp do całego środowiska, więc może zatrudnić kogokolwiek, kto będzie w stanie odpalić na licencji deweloperskiej edytor i wyciągnąć co będzie chciał z bazy. Chodzi mi o takie zabezpieczenie bazy, żeby nie mógł - nawet na własnych licencjach deweloperskich - dostać się do bazy inaczej niż poprzez napisane przeze mnie oprogramowanie. Co mogę w takiej sytuacji zrobić, gdy całe środowisko jest pod kontrolą klienta?
Rozumiem, że Państwa aplikacja nie korzysta z serwera aplikacji... Nie wiem jaką macie wersję, ale proszę przeczytać artykuł z bazy wiedzy nt szyfrowania hasła.
Korzystamy z Client-Networking, WebSpeeda i też AppServer do WebService-ów. Szyfrowanie również znamy, natomiast to nadal nie rozwiązuje nam problemu, ponieważ plik -pf z zaszyfrowanym hasłem można wykorzystać do uruchomienia jakiejkolwiek procedury jeśli ma się licencję deweloperską. Właśnie największym problemem jest ta licencja deweloperska trzeciej osoby, która pozwala na podłączenie się do bazy i wykonywanie procedur ad-hoc.
User i password nie musi byc wcale w .pf. Do bazy mozna sie podlaczyc bez podawania uzytkownika i hasla i nastepnie nastawic je przy pomocy SETUSERID. A haslo do SETUSERID mozna ukryc w .r.
Jeśli zmiana loginu/hasła do bazy wchodzi w grę to najprostszą metodą jest zaszycie nazwy użytkownika i jego hasła w aplikacji i łączenie się z bazą danych z jej poziomu. Namiary na bazę danych (host, port) można do aplikacji przekazać jako parametry.
Można to rozwinąć np do dwóch zdefiniowanych użytkowników bazy. Jeden służy tylko do inicjowania połączenia i ma dostęp w bazie do określonej porcji informacji służącej do wyznaczania hasła pełnego dostępu. Po połączeniu się (jawnym użytkownikiem) aplikacja wyznacza hasło dostępu i przełącza się na się na drugiego użytkownika. Do tego dochodzi jeszcze oczywiście sprawa zarządzania hasłem drugiego użytkownika (np jego zmiana). Metoda dobra w określonych przypadkach, ponieważ deweloper może wykazać, że nie posiada dostępu (nie zna hasła) do danych klienta.