W pierwotnym zamiarze arkusze kalkulacyjne zostały pomyślane jako narzędzie do niezbyt złożonych obliczeń z wykorzystaniem niewielkiej dawki danych. Wraz z rozwojem technologii awansowały do roli uznanego środowiska symulacyjnego oraz prezentacyjnego. Wzbogacenie możliwości arkuszy o ich programowanie spowodowało, że programiści byli w stanie zwielokrotniać ich funkcjonalność oraz budować wygodniejsze interfejsy, podwyższające walory jakościowe tego narzędzia.

Nigdy jednak arkusze kalkulacyjne nie były pomyślane jako narzędzie klienckie dla przetwarzania transakcyjnego ani też jako system składowania danych dla przetwarzania w wielodostępie. Co najwyżej mogą one spełniać pomocniczą rolę przy wsadowym transporcie danych pomiędzy logicznie odrębnymi systemami, i to raczej tylko w sporadycznych przypadkach, wynikających najczęściej z potrzeb podczas konwersji systemów.

Pomimo dosyć dobrze określonych rodzajów zastosowań i znanej ogólnie funkcjonalności, znaleźli się liczni propagatorzy rozwoju idei arkusza jako magazynu danych dla przetwarzania w trybie online czy jako aplikacji klienckiej, co starano wcielić w obszar zastosowań z wiadomym skutkiem. Niektórzy twórcy wręcz zapędzili się zdecydowanie za daleko, stawiając całe przetwarzanie w firmie na takim właśnie środowisku, o czym już jednoznacznie wypowiadał się Marcin Marciniak ("Kiedy pozbyć się arkuszy Excela?", CW nr 22/2010) i pod czym podpisuję się obiema rękami.

Abym nie był źle zrozumiany - nie opowiadam się za zrezygnowaniem z arkuszy całkowicie, a jedynie za używaniem ich zgodnie z przeznaczeniem. Już od dawna wiadomo, że do tworzenia oprogramowania służą odpowiednie środowiska, a do przechowywania danych specjalizowane serwery, które doskonale radzą sobie z zachowaniem spójności transakcyjnej. Najwyraźniej dobrze skonstruowana strona narzędziowa środowiska Excela stała się zachętą do niezgodnych z pierwotnym jego przeznaczeniem zastosowań. To jest między innymi rachunek, jaki trzeba płacić za popularność.

Arkusz jako narzędzie analityczne potrafi nie tylko przechowywać w swoich plikach pewien ograniczony zasób danych, ale potrafi dane te pozyskiwać z różnych źródeł zewnętrznych, jakimi natywnie są bazy SQL Server lub Access, a w nieco szerszym zakresie każdy obiekt zapewniający podłączenie do niego. W związku z tym nie jest już problemem, dla mało nawet doświadczonego użytkownika, pobranie świeżej zawartości tabeli z połączonej bazy danych, jeśli tylko wie, gdzie jej szukać i ma odpowiednie uprawnienia dostępu. Jeśli zadanie to okazałoby się dla niego zbyt trudne, z pomocą przyjdzie programista dorabiając odpowiedni przycisk, rzucający się w oczy i czyniący swą powinność bez konieczności błądzenia po pasku menu.

Jeżeli już mówimy o zatrudnieniu do tego zadania programisty, to zdawać sobie należy sprawę z faktu, że przecież może on wykonać nieco więcej, gdyż środowisko programowe VBA zezwala na przesłanie dowolnego zapytania do serwera, jak również pobrania wyników, jeśli takowe są. Przy bardzo nikłym wysiłku programistycznym można wykonać wyszukiwanie danych, ich aktualizację w bazie (a nie tylko na planszy arkusza), a nawet usunąć całą zawartość tabeli z odległej bazy. Jeśli nałożymy na środowisko pracy w arkuszu odpowiedni formularz frontowy, Excel staje się do siebie niepodobny, a użytkownik ma to, co zazwyczaj daje aplikacja stworzona w zgoła innym środowisku. Nadmienić wypada, że podobne sztuczki można wyczyniać w środowisku Access, nawet nie sięgając po język programowania.

Ryzykowny dostęp

Przechodząc do sedna sprawy, należy zauważyć, że skoro zwykły użytkownik Excela lub Accessa może bez jakiejkolwiek umiejętności programowania przyłączyć i wyświetlić zawartość tabel bazy danych, to znaczy też, że może te dane następnie zapisać w innym miejscu, na innym nośniku. Może je wreszcie wynieść poza firmę lub wysłać na inny serwer jako załącznik poczty lub poprzez klienta FTP.

W związku z tym należy uwypuklić dwa rodzaje ryzyka, jakie potencjalnie współistnieją z możliwościami funkcjonalnymi oferowanymi przez popularne pakiety oprogramowania biurowego:

- wyciek danych;

- niekontrolowana modyfikacja danych.

Środowisko użytkownika wyposażone w oprogramowanie biurowe, jakim jest na przykład MS Office, daje dużą swobodę działania. Pozostaje tylko kwestią chęci, umiejętności, świadomości oraz istniejących systemowo obwarowań bezpieczeństwa, co dalej będzie się działo w kwestii danych dostępnych na serwerach. Zastanawiając się, jakie pobudki mogą kierować pracownikiem, aby dokonał procederu niezgodnego z prawem, nie trzeba poszukiwać zbyt wyrafinowanych przyczyn. Najczęściej jest to chęć zysku lub zaszkodzenia pracodawcy. W każdej firmie jest pewien odsetek niezadowolonych pracowników i jest tylko kwestią zaistnienia sprzyjającego impulsu lub warunków, aby złorzeczenie przeistoczyć w czyny. A warunki znajdą się, jeżeli uprawnienia dostępu do danych nie będą skutecznie stały na ich straży.