A w tej materii bywa różnie i chociaż nieraz pozory zdają się wskazywać, że ochrona istnieje, to są to tylko jej pozory.

Tak się składa, że pakiet MS Office w wersji standardowej (a więc zawierający Excela) jest częstym składnikiem stacji roboczych w firmach. Na tych samych kontach użytkowników stacji roboczych uruchamiane są także aplikacje dedykowane, jak na przykład FK czy CRM, służące przetwarzaniu produkcyjnemu. Niektóre aplikacje klienckie współdziałają z serwerem bazy danych wykorzystując model autoryzacji zintegrowanej, co oznacza, że do autoryzacji dostępu do danych wystarczy zalogowanie się na konto stacji roboczej. Jest to wygodny sposób (i notabene zalecany przez Microsoft) uwierzytelniania użytkownika na serwerze bazy danych. Skutkiem tego aplikacja kliencka uzyskuje dostęp do danych, zgodnie z uprawnieniami, jakie przysługują temu użytkownikowi na serwerze bazy danych.

Zrozumiałe, że skoro użytkownik ten ma poprzez aplikację przeglądać i modyfikować dane, to musi mieć takie właśnie uprawnienia do tabel tej bazy na serwerze. Jeśli tylko użytkownik systemu będzie "grzeczny" i będzie korzystał ze środowiska dedykowanej aplikacji, to nic złego się nie stanie. Jeśli jednak poniosą go wodze fantazji, to uruchamiając chociażby arkusz kalkulacyjny pobierze dane, i to nawet te, o których istnieniu do tej pory "wiedziała" tylko dedykowana aplikacja oraz jej projektanci. Jeśli użytkownik będzie złośliwy lub niezadowolony z pracy i poprosi o fachową pomoc kolegę programistę, to ten bez większego trudu przygotuje mu taki arkusz modyfikujący dane w bazie, że zrobi się niezły galimatias. Wystarczy tylko, że użytkownik przyniesie arkusz na stanowisko pracy, skopiuje na stację roboczą i uruchomi na swoim koncie. Oczywiście Excel jest w tym wypadku narzędziem z wyboru, ale nie tylko to środowisko pozwala na tego rodzaju ingerencję.

Wygodne uprawnienia

W kontekście tego przykładu może zastanawiać, dlaczego produkcyjna aplikacja, której pracownicy używają na co dzień, wymaga zazwyczaj dodatkowego, niezależnego od Windows, logowania, skoro dostęp do danych uzyskiwany jest na innym poziomie. Uzasadnienie jest dosyć trywialne: na przykład dlatego, aby rozsądzać o uprawnieniach użytkowników w ramach samej aplikacji, albo żeby po prostu identyfikować i wewnętrznie rejestrować ich poczynania. Wymóg autoryzacji użytkownika w aplikacji narzuca także ustawa o ochronie danych osobowych - oczywiście wtedy, gdy mamy do czynienia z tego rodzaju danymi.

Pytanie, jakie na końcu wypadałoby zadać brzmi: dlaczego tworzone są rozwiązania dające zalogowanemu użytkownikowi szeroko otwarte wrota dostępu do danych. Okazuje się, że sprawa nie jest do końca łatwa i prosta do wyjaśnienia. Nie zawsze buduje się rozwiązania niedoskonałe lub wręcz błędne z tytułu niewiedzy czy niestaranności. Często o takiej, a nie innej konstrukcji decydują konkretne ograniczenia zachodzące dla bardziej skomplikowanych przypadków, co powoduje, że autorzy kosztem bezpieczeństwa starają się zachować elastyczność i funkcjonalność produktu. Czasem jest to swego rodzaju wygoda lub powzięcie błędnych założeń, z których później trudno się wycofać, a czasami zaszłości koncepcyjne starej wersji oprogramowania instalowanej w coraz nowszych środowiskach. Najgorsze jest jednak to, że zdarza się, iż administratorzy zarządzający tego rodzaju otoczeniem produkcyjnym nie do końca zdają sobie sprawę z istniejących zagrożeń.