Comiesięczne zestawienie powstaje w arkuszu, którego przycisk importuje dane i przygotowuje raport. Po pobraniu nowej wersji plik nadal pokazuje tabele, ale automatyzacja nie działa. Zbliża się termin rozliczenia, więc pojawia się pomysł wyłączenia zabezpieczeń na wszystkich komputerach działu.
W takim przypadku wsparcie IT powinno oddzielić potrzebę biznesową od sposobu jej realizacji. Przywrócenie raportowania nie musi oznaczać zgody na uruchamianie dowolnego kodu. Najpierw trzeba ustalić pochodzenie arkusza, działanie makr i przyczynę blokady, a następnie wybrać rozwiązanie o możliwie ograniczonym zakresie.
Otwarty arkusz nie oznacza uruchomionej automatyzacji
Makro to zapis czynności lub kod wykonywany przez aplikację biurową. Może porządkować dane, ale również odczytywać pliki, łączyć się z innymi systemami albo uruchamiać dodatkowe programy. Dlatego możliwość obejrzenia tabel nie jest równoznaczna z pozwoleniem na wykonanie automatyzacji.
Trzeba rozróżnić widok chroniony, blokadę makr oraz zwykły błąd programu. Komunikat o niedozwolonym uruchamianiu kodu wskazuje inną ścieżkę postępowania niż błąd brakującej biblioteki. Bez zapisania dokładnej treści ostrzeżenia łatwo zmienić niewłaściwe ustawienie i pozostawić pierwotną usterkę.
Zgłoszenie przekazywane do obsługi problemów użytkowników z aplikacjami biurowymi powinno zawierać opis niedziałającej czynności, źródło pliku oraz informację, kiedy proces działał ostatnio. Samo stwierdzenie „arkusz nie działa” nie pozwala ocenić ani pilności, ani ryzyka.
Co wsparcie IT powinno ustalić o pochodzeniu pliku
Plik zapisany z poczty lub pobrany przez przeglądarkę może otrzymać oznaczenie pochodzenia z internetu. Aplikacja może na tej podstawie blokować makra, mimo że podobny arkusz zapisany wcześniej lokalnie działał. Sposób zachowania zależy od programu, jego wersji oraz zasad obowiązujących na stanowisku.
Nie należy usuwać takiego oznaczenia tylko po to, aby sprawdzić, czy przycisk zacznie działać. Najpierw potrzebne jest potwierdzenie, kto przygotował arkusz i czy oczekiwano jego dostarczenia. Znany adres nadawcy nie dowodzi bezpieczeństwa załącznika: konto mogło zostać przejęte, a plik podmieniony.
- Wskazać właściciela procesu, który potwierdzi potrzebę używania arkusza.
- Ustalić zatwierdzone miejsce przechowywania i sposób dystrybucji aktualnych wersji.
- Porównać plik z wersją uzyskaną z potwierdzonego źródła.
- Sprawdzić, czy makra są podpisane i czy podpis pozostaje prawidłowy.
- Zweryfikować zależności: dodatki, foldery, połączenia z bazą oraz uprawnienia użytkownika.
Podpis kodu pomaga ustalić wydawcę i wykryć zmianę podpisanej zawartości, ale nie jest gwarancją nieszkodliwości. Z kolei brak podpisu w starszym narzędziu wewnętrznym nie przesądza o ataku. Oznacza potrzebę innego sposobu potwierdzenia pochodzenia i oceny kodu, zamiast automatycznego dopuszczenia.
Dopuszczenie makra, poprawa arkusza czy zastąpienie procesu
Pierwszy wariant to kontrolowane dopuszczenie sprawdzonej automatyzacji. Ma uzasadnienie, gdy znany jest autor, kod został oceniony, a firma potrafi utrzymywać zatwierdzoną wersję. Mechanizm zaufania powinien obejmować konkretny zakres. Uznanie całego folderu pobierania lub wspólnego katalogu z prawem zapisu dla wszystkich za zaufany tworzy drogę uruchamiania także obcych plików.
Drugi wariant to poprawa arkusza. Jeżeli kod odwołuje się do nieistniejącego dysku, wymaga praw administratora albo zapisuje hasło do bazy, samo odblokowanie niczego trwale nie rozwiąże. Potrzebne mogą być zmiana sposobu uwierzytelniania, ograniczenie uprawnień i usunięcie zależności od jednego stanowiska.
Trzeci wariant to zastąpienie makra funkcją programu, kontrolowanym importem lub inną automatyzacją. Warto go rozważyć, gdy nie ma autora, kodu nie da się utrzymać albo raport jest krytyczny dla rozliczeń. Wsparcie informatyczne powinno wskazać koszty i zależności każdego wariantu, natomiast właściciel procesu zatwierdza sposób dalszej pracy.
Próba na jednym stanowisku zamiast wyjątku dla całego działu
Praktyczna checklista decyzyjna dla technika M3 Group zaczyna się od dwóch niezależnych pytań: czy wolno uruchomić ten kod oraz czy po uruchomieniu wykona właściwe operacje. Poprawny raport nie dowodzi bezpieczeństwa makra, a brak ostrzeżenia nie potwierdza poprawności obliczeń.
- Zachować niezmieniony plik źródłowy i zapisać przyczynę blokady.
- Ocenić kod oraz zewnętrzne odwołania w kontrolowanym środowisku bez dostępu do danych produkcyjnych.
- Przygotować dane testowe z wcześniej znanym oczekiwanym wynikiem.
- Uruchomić zatwierdzoną wersję na ograniczonym stanowisku, bez zbędnych uprawnień.
- Sprawdzić wynik, miejsca zapisu i ewentualne połączenia z innymi usługami.
- Udokumentować zakres dopuszczenia oraz sposób jego wycofania.
Jeżeli rozwiązanie wymaga zmiany zasad bezpieczeństwa na komputerach, zastosowanie mają reguły kontrolowanego wdrażania zmian IT. Potrzebne są zatwierdzenie, ograniczona próba i plan powrotu, a nie jednoczesna modyfikacja wszystkich stanowisk tuż przed terminem rozliczeń.
Arkusz działający tylko u jednej osoby wymaga utrzymania
Jeżeli raport działa wyłącznie na komputerze autora, firma ma zależność organizacyjną, nie tylko techniczną. Przyczyną mogą być lokalne dodatki, zapisane poświadczenia lub ścieżki do prywatnych katalogów. Awaria tego stanowiska albo nieobecność pracownika zatrzyma proces, nawet gdy sam plik pozostaje dostępny.
Gotowość stanowiska zastępczego należy sprawdzić przez wykonanie raportu na danych testowych. Tę samą zasadę opisuje materiał o przygotowaniu ciągłości pracy na czas naprawy laptopa: dostęp do dokumentu nie oznacza jeszcze możliwości wykonania zadania.
Firma informatyczna we Wrocławiu powinna mieć udokumentowane wymagania techniczne, a przedsiębiorstwo — wskazanego właściciela arkusza i osobę zatwierdzającą zmiany. Opieka informatyczna we Wrocławiu powinna obejmować także te niewielkie narzędzia, jeżeli od nich zależą płatności, raportowanie lub obsługa zamówień.
Raport przywrócony, zabezpieczenia zachowane
Wsparcie IT może zakończyć zadanie, gdy zatwierdzony arkusz daje poprawny wynik, działa na przewidzianych stanowiskach i ma określone zasady aktualizacji. Odpowiedzialność za takie narzędzia powinna być częścią stałej obsługi środowiska informatycznego firmy, a nie pozostawać wyłącznie w pamięci autora.
Skuteczne wsparcie IT nie sprowadza się do usunięcia ostrzeżenia. Wynikiem powinien być działający proces, znane pochodzenie kodu i brak niepotrzebnego osłabienia ochrony całego działu.
