projekt bazy, użytkownicy

Witam,
tak się zacząłem zastanawiać, nad przebudowaniem bazy ponieważ niedługo przestanie spełniać wymogi bezpieczeństwa.
Mam tabelę pracownicy, i wiele tabel jest z nimi połączonych np wiadomości, chodzi o to żeby nie można się było podszyć pod taki wpis w bazie.
Mój pomysł jest taki żeby powiązać w jakiś sposób konto mysql.user z wpisami w bazie pracownicy. Z tym że pomiędzy bazami się chyba relacji nie da zrobić.
Może ktoś by mnie nakierował jak się coś takiego robi?
Baza jest MySQL z silnikiem INNODB

Co znaczy się podszyć się pod wpis w bazie?
Pomysł z userami systemu bazodanowego w takiej formie jest kompletnie nietrafiony, bo żeby miało to sens to musiałbyś zrobić aby user w aplikacji łączy się w kontekście danego usera mysql, który ma odpowiednie prawa przypisane etc. inaczej wydaj się to całkiem bez sensu.
Jakie są te twoje wymogi bezpieczeństwa?
Masz domenę? W sensie autentykację domenową czy jakiś kerberos, active directory, ...
Za pomocą takich mechanizmów zapewnia się sensowną autentykację, czyli zwiększa bezpieczeństwo.

Kurcze nie tak łatwo odpowiedzieć :P
Właśnie chodzi o to, że w tym momencie jest tak, że w zasadzie autentykacji nie ma. Jest autentykacja mysql do dostępu do zasobów, jednak jak już masz dostęp do bazy to działa to na tej zasadzie że na formularzu wybierasz siebie jako autora z listy pracowników i tyle. Nie bardzo wiem jak to powinno być zbudowane, żeby po zalogowaniu do bazy użytkownik był identyfikowany.

Nie jestem przekonany czy w poprawnym kontekście używasz pojęcia "logowanie do bazy".
Takie rzeczy rozwiązuje się na poziomie aplikacji. Tzn. autentykujesz usera, jak? Gama możliwości spora. Najprostsze: login+hasło, inne: domenowe, czytniki kart chipowych, biometryczna, czy nawet po jakiejś nazwie/ip kompa (głupie, ale można).
Kolejnym pojęciem jest autoryzacja, czyli odpowiedzenie na pytanie co może dany user.
Twoja aplikacja po autentykacji, powinna userowi X pozwalać wskazać tylko siebie jako autora, a np. Y powinien móc jako autora wskazać jakiś swoich podwładnych. Konfiguracja uprawnień zazwyczaj jest zapisana w bazie, ale należy to oprogramować. Samo zalogowanie jako inny user do systemu bazy danych niczego ci nie rozwiąże, co najwyżej ograniczysz uprawnienia do CRUD etc.

Mam użytkowników bazy MySQL którzy logując się podają login i hasło, następnie mają dostęp do zawartości bazy firmowej której dostępność jest regulowana przez uprawnienia MySQL.
Czyli trzeba by to zrobić tak, że włączając aplikację i logując się do bazy użytkownik(z bazy MySQL) jest powiązany z wpisem w tabeli pracownicy(w bazie Firma)? Tylko pytanie jak to zrobić skoro nie da się stworzyć relacji pomiędzy różnymi bazami. Chyba żeby podczas dodawania użytkownika do bazy podawać od razu ID pracownika w bazie Firma. Wtedy podczas logowania można by domyślnie ustawić autora na tego pracownika.

Musisz w tabeli z pracownikami mieć kolumnę w której wpiszesz identyfikator/nazwę mysql.user, tzn. to co zwraca user(), ale tylko część name. Oczywiście nie możesz założyć relacji, ale np. możesz założyć unique na tej kolumnie. Po user będziesz mógł wyciągnąć pracownika. Ale i tak w aplikacji musisz coś oprogramować, sam autor się nie wyczaruje.
Swoją drogą przyznam że osobliwe rozwiązanie, bo jeśli ktoś niewłaściwie zarządza uprawnieniami tych userów, to mogą dostać zbyt duże uprawnienia w systemie bazy danych i niezłego bigosu narobić. Jeśli mamy jednego usera po którym aplikacja łączy się do bazy to łatwiej zapanować jakie taki user może mieć uprawnienia, ewentualnie drugi user dla jakiś adminów, który ma więcej możliwości dotyczących np. usuwania jakiś rekordów etc.

No tak najłatwiej to by było jak by logowanie do bazy było na podstawie wpisów w tabeli firma.pracownicy żeby administrator nie musiał się bawić z powiązywaniem kont, żeby się to robiło automatycznie po wprowadzeniu użytkownika do bazy firmowej. Oczywistym jest fakt, że będzie to oprogramowane tylko właśnie muszę wiedzieć jak zrobić strukturę zanim zacznę to robić. Tak najchętniej to bym się dowiedział jak się to normalnie rozwiązuje. Jakiś przykład bazy byłby bardzo mile widziany.

W tabeli Pracownicy masz jakiś identyfikator + hasło jakim pracownik autentykuje się, czyli loguje do aplikacji, aplikacja sprawdza czy login+hasło się zgadzają, a jeśli tak to dla jakiego pracownika=użytkownika. I mówi tak, Jan kowalski jest zalogowany. Teraz to już z górki, w sesji masz id tego pracownika (czy nawet więcej informacji jak imię, nazwisko, ...) i na tej podstawie albo pobierasz jakieś reguły uprawnień (czy bezpośrednio do usera podpięte, czy do stanowiska, lokalizacji, grupy, ...) i na postawie tych uprawnień mówisz co może a czego nie w aplikacji.
Przykład tabeli:
Emploiees
Id
Login
Password
Name
Surname
Position
Location
...

Ale to by trzeba zrobić tak jak jest w bazie MySQL, hash hasła w innej tabli do której ma dostęp tylko aplikacja. Z mojego punktu widzenia strasznie to skomplikowane ale do rozgryzienia. Jeszcze jak rozwiązać sposób sprawdzania tego hasła? Początkowo aplikacja musiała by się łączyć jako jakiś użytkownik który ma dostęp do tabeli z hasłami. Jednak jakoś nie wydaje mi się to bezpieczne, żeby tak w kodzie gdzieś zapamiętać hasło do tak ważnej rzeczy.

Aplikacja web leży na serwerze, więc z definicji jest to miejsce bezpieczniejsze. Np. w .net są mechanizmy wspierające szyfrowanie pliku konfiguracyjnego (częsci/całego) i w sposób przezroczysty dla aplikacji deszyfracji i dostarczenia jej danych z pliku konfiguracyjnego, m.in. connection string do bazy z hasłem.
Plik konfiguracyjny możesz zaszyfrować czy tylko jakiś element i na starcie aplikacji zdeszyfrować i załadować do application, czy jakiś zmiennych serwerowych connection string. Później łączysz się za pomocą tego conn str do bazy. Oczywiście kwestia ewentualnego szyfrowanego połączenia między aplikacją a bazą danych to osobna kwestia. Te dwie sprawy są rozłączne.
Hasła w bazie oczywiście nie powinny być trzymane w postaci jawnej, tylko albo zaszyfrowane, albo hash. Hasło jakie podaje użytkownik, albo po stronie aplikacji jest hashowane/szyfrowane i wysyłane do porównania do bazy, albo można też taką operację wykonać na bazie, ale raczej nie jest to praktykowane.
Problem bezpiecznego zebrania hasła od użytkonika to jeszcze inna kwestia. Chodzi o zapewnienie bezpiecznego połączenia między użytkownikiem (przeglądarką) a aplikacją (serwerem www), realizuje się to za pomocą ssl (https), do czego potrzebny jest certyfikat (klucz publiczny-prywatny). Może to być twój certyfikat (podpisany przez ciebie), nie musi być kupiony/podpisany przez tzw. urząd certyfikacji, jako to jest na stronach np. banków.

Z założenia miała to być zwykła aplikacja nie internetowa ze względu na łatwiejsze operowanie na plikach, dostęp do usług w systemie, takich jak autostart czy też wyskakujące powiadomienia z tray'a. Połączenia z poza firmy chciałem zorganizować przez VPN i ssh więc z tego względu chyba większych problemów nie powinno być, a w sumie po kompilacji programu faktycznie chyba nie ma możliwości odczytu hasła.
No dobra, to to już mniej więcej wiem jak ogarnąć, teraz pytanie jak się właściwie zabrać za poprawne zaprojektowanie aplikacji... ale to już chyba inny temat

"po kompilacji programu faktycznie chyba nie ma możliwości odczytu hasła" - cóż... mylisz się. Zależy jaki język, ale generalnie nie jest to niemożliwe. W C#/java wręcz banalne.
Możesz też zastosować taką sztuczkę:

1. albo komunikacja przez webservice, a wcześniej jakaś autentykacja na podstawie login/pass. Ale generalnie conn string jest na serwerze i aplikacja nie komunikuje się bezpośrednio z bazą.
2. za pomocą webservice tylko autentykacja login/pass i pobranie connection string, którego później będzie używała aplikacja. Aplikacja nie przechowuje conn stringa (ani innych bardziej wrażliwych informacji). Nie znaczy to że z pamięci procesu nie da się wyciągnąć danych.
3. aplikacja zawiera plik konfiguracyjny zaszyfrowany (częściowo/w całości), który na starcie odszyfrowywuje i pobiera z niego conn string.
   Idealne, 100% zabezpieczenie nie istnieje. Jeśli aplikacja wpadnie w ręce odpowiednio zdeterminowanego hakera poradzi sobie z każdym.