Eksport danych z aplikacji: jak przygotować plik, który nie ujawnia za dużo

Pracownik pobiera raport dla jednego oddziału. W arkuszu widzi jednak również klientów innych jednostek oraz kolumny, których nie było na ekranie. Plik powstał poprawnie z punktu widzenia aplikacji, ale jego zakres nie odpowiada zadaniu ani uprawnieniom odbiorcy. Po pobraniu trudniej ustalić, gdzie trafią kolejne kopie.

Eksport danych z aplikacji powinien zaczynać się od decyzji o celu, odbiorcy i zakresie. Trzeba ustalić, które rekordy oraz pola są potrzebne, jak rozpoznać moment przygotowania pliku i co się dzieje po odebraniu dostępu. Sam przycisk pobierania jest dopiero końcem tej drogi.

Poniższe przykłady są fikcyjne. Nie istnieje jeden zestaw kolumn ani jeden okres przechowywania odpowiedni dla wszystkich organizacji. Zasady dotyczące danych, odbiorców i usuwania plików należy ustalić dla konkretnego procesu oraz właściwych wymagań.

Najpierw opisz zadanie odbiorcy

Zapytajcie, do czego potrzebny jest plik. Osoba przygotowująca zestawienie otwartych zleceń może potrzebować numeru sprawy, terminu i właściciela. Zespół rozliczeń może korzystać z innego zakresu. Jeśli odbiorca chce jedynie policzyć sprawy według statusu, szczegółowa korespondencja z klientami prawdopodobnie nie pomoże mu wykonać zadania.

W fikcyjnej firmie kierownik oddziału pobiera listę spraw wymagających decyzji. Widok w aplikacji jest ograniczony do jego jednostki. Eksport powinien zachować uzgodniony zakres rekordów i pól, chyba że istnieje osobne, wyraźnie określone uprawnienie do szerszego raportu. Nie powinien po cichu dodawać danych innych oddziałów.

Ustalcie również, czy plik ma zawierać pojedynczy widok użytkownika, czy określony raport przygotowany dla innej osoby. Filtry, role i źródło danych mogą wpływać na wynik. Przed pobraniem użytkownik powinien rozumieć, jaki zakres wybrał oraz czy obejmuje on wszystkie strony listy, czy tylko wyświetlony fragment.

O znaczeniu jednostek i definicji raportu piszemy w artykule o definicjach wskaźników dashboardu. Te same nazwy kolumn w dwóch plikach nie gwarantują, że obejmują identyczny okres albo ten sam zestaw spraw.

Uprawnienie do ekranu i prawo do eksportu

Możliwość obejrzenia pojedynczej sprawy nie zawsze oznacza potrzebę pobrania całej bazy. Organizacja powinna określić, które role mogą eksportować dane, jaki zakres jest im potrzebny i czy szerszy plik wymaga dodatkowej decyzji. Kontrola musi działać po stronie serwera, także gdy ktoś zna adres operacji lub próbuje zmienić parametry żądania.

W systemie obsługującym wiele firm granice organizacji powinny obowiązywać przy tworzeniu pliku i jego pobraniu. Zadanie wykonywane w tle potrzebuje właściwego kontekstu użytkownika oraz zakresu danych. O izolacji informacji między klientami piszemy w artykule o aplikacji dla wielu firm.

Jeżeli dostęp został odebrany po rozpoczęciu tworzenia raportu, trzeba ustalić, czy użytkownik nadal może pobrać wynik. Odpowiedź zależy od procesu i architektury, lecz powinna być świadomie zapisana oraz przetestowana. Sam fakt, że link był wcześniej widoczny, nie powinien automatycznie zastępować sprawdzenia aktualnych uprawnień.

W rolach i uprawnieniach aplikacji opisujemy przejście od obowiązków do reguł dostępu. Eksport jest osobnym działaniem, ponieważ tworzy kopię, która może później znaleźć się poza kontrolowanym widokiem systemu.

Jeżeli raport nie zawiera żadnych rekordów, odbiorca potrzebuje wiedzieć, czy to wynik filtrów, czy problem z pobraniem danych. Te sytuacje porządkujemy w artykule o pustych stanach aplikacji.

Nazwij zawartość, filtr i czas przygotowania

Przed pobraniem pokażcie, jakiego okresu i zakresu dotyczy raport oraz jakie pola zostaną uwzględnione. Jeśli niektóre rekordy są pomijane z powodu uprawnień lub błędu, użytkownik nie powinien uznać pliku za pełny bez odpowiedniej informacji. Znaczenie komunikatu zależy również od tego, czego wolno ujawnić danej osobie.

Przy dłuższym przygotowaniu pliku dane mogą zmienić się między rozpoczęciem zadania a pobraniem. Ustalcie, jaki moment lub zakres danych opisuje raport i jak przekazać tę informację odbiorcy. Jeśli źródła aktualizują się w różnym czasie, jeden znacznik „ostatnia aktualizacja” może wymagać doprecyzowania.

W przypadku raportu z kilku systemów wskażcie właściciela poszczególnych informacji oraz sposób postępowania przy braku danych. O tym, dlaczego trzeba ustalić źródło danych w integracji, piszemy szerzej osobno. Plik nie powinien wyglądać na kompletny, jeśli jedna część nie została pobrana i nikt o tym nie informuje.

Nazwa pliku może pomagać odbiorcy, ale nie powinna ujawniać poufnych danych w miejscu, w którym są niepotrzebne. Zamiast umieszczać szczegóły sprawy w nazwie, można wskazać typ raportu i uzgodniony zakres. Sposób oznaczenia powinien pozwolić odróżnić kolejne wersje bez kopiowania wrażliwej treści.

Format pliku ma znaczenie dla bezpieczeństwa

CSV jest wygodnym sposobem wymiany tabel, lecz program otwierający plik może interpretować niektóre wartości jako formuły. OWASP opisuje zagrożenie zwane CSV injection: niezaufana treść umieszczona w pliku może zostać potraktowana przez arkusz jako polecenie. Problem zależy od zawartości, programu i sposobu otwarcia pliku.

Zespół powinien sprawdzić aktualne zalecenia dla używanego formatu i programów odbiorców. Nie należy obiecywać, że pojedyncza zamiana znaku rozwiąże każdy przypadek. OWASP wskazuje, że niektóre sposoby zabezpieczenia mogą przestać działać po zapisaniu i ponownym otwarciu pliku w arkuszu. Potrzebne są testy obejmujące rzeczywistą ścieżkę pracy.

Jeśli eksport obejmuje dane wpisywane przez użytkowników, przygotujcie bezpieczne przykłady testowe zawierające znaki i wartości wymagające szczególnej obsługi. Sprawdźcie je w środowisku testowym, w programach używanych przez odbiorców. Celem jest rozpoznanie zachowania pliku, a nie uruchamianie nieznanych formuł na danych produkcyjnych.

Format wpływa także na znaczenie danych. Numery identyfikacyjne mogą zawierać zera na początku, a daty zostać inaczej zinterpretowane przez program odbiorcy. Ustalcie sposób przedstawienia wartości i sprawdźcie, czy po otwarciu pliku nadal odpowiadają źródłu. Warto zachować instrukcję dla osób, które regularnie korzystają z raportu.

Przekazanie pliku tworzy kolejny etap dostępu

Po pobraniu plik może trafić do skrzynki, folderu współdzielonego albo narzędzia partnera. Przed uruchomieniem eksportu ustalcie, gdzie ma być przekazywany, kto może go otworzyć i kiedy nie będzie już potrzebny. Sama kontrola dostępu do aplikacji nie usuwa kopii zapisanej wcześniej na urządzeniu.

Jeśli system przygotowuje plik do pobrania przez link, trzeba określić odbiorcę, czas dostępności oraz sposób odebrania dostępu. Przy wrażliwych danych warto sprawdzić, czy pobranie wymaga ponownej weryfikacji użytkownika. Konkretna metoda zależy od procesu oraz możliwości systemu.

Przy przekazaniu partnerowi określcie także sposób potwierdzenia odbioru i postępowanie po pomyłce. Wiadomość wysłana na niewłaściwy adres wymaga uzgodnionej reakcji; usunięcie pliku z własnego folderu nie dowodzi usunięcia każdej kopii. Zespół powinien wiedzieć, kto podejmuje decyzję i jak zgłasza problem.

O dostępie do dokumentów wykorzystywanych w firmowej wyszukiwarce piszemy w artykule o uprawnieniach w systemie RAG. Eksport ma inny cel, ale również wymaga sprawdzenia, kto otrzymuje materiał i jaki zakres informacji jest mu potrzebny.

Uzgodnij sposób korzystania z pliku

Plik może być potrzebny jednorazowo albo stanowić regularne źródło dla kolejnego zespołu. Przy cyklicznym eksporcie ustalcie częstotliwość, odbiorcę oraz to, jak rozpoznać najnowszą wersję. Jeżeli wcześniejszy raport pozostaje w folderze, osoba odbierająca powinna wiedzieć, czy został zastąpiony i czy nadal wolno z niego korzystać.

Przy ręcznym przekazywaniu warto wskazać osobę odpowiedzialną za sprawdzenie adresata i zawartości. Jeśli odbiorca nie otrzymał pliku, najpierw trzeba ustalić stan poprzedniej wysyłki. Ponowne przekazanie może utworzyć kolejną kopię albo trafić do osoby, której dostęp zmienił się od czasu pierwszej próby.

Jeżeli plik ma być importowany do innego systemu, uzgodnijcie format pól, identyfikatory oraz sposób obsługi błędów. Liczba wierszy nie dowodzi, że każdy rekord trafił do właściwej sprawy. Osoba prowadząca proces powinna móc porównać wynik z uzgodnionym zakresem i zgłosić rozbieżność.

Przy zmianie struktury raportu poinformujcie odbiorców, którzy używają go do dalszej pracy. Nowa nazwa kolumny, inny sposób zapisu daty lub dodatkowy filtr mogą zmienić wynik importu. Przed wdrożeniem warto wykonać próbę z przykładowym plikiem i ustalić, która wersja obowiązuje po zmianie.

Dopasuj czas przechowywania do celu

Dane eksportowane do pliku mogą pozostać w kilku miejscach, nawet gdy raport przestanie być potrzebny w codziennej pracy. Ustalcie, kto odpowiada za przegląd kopii oraz jakie reguły przechowywania obowiązują dla danego rodzaju informacji. Decyzja powinna wynikać z celu, warunków współpracy i właściwych wymagań, a nie z jednej liczby przyjętej dla wszystkich plików.

Jeśli użytkownik zgłosi błędny lub niepotrzebny eksport, zespół potrzebuje sposobu ustalenia zakresu problemu. Pomocne mogą być identyfikator zadania, odbiorca i czas przygotowania. Nie oznacza to, że w dzienniku trzeba przechowywać pełną kopię raportu. Zakres śladu należy uzgodnić z osobami odpowiedzialnymi za dane i utrzymanie.

Zapisz zdarzenie bez kopiowania całego pliku

Do wyjaśnienia problemu może być potrzebna informacja, kto utworzył eksport, kiedy, dla jakiego zakresu oraz czy pobranie zostało potwierdzone. Zespół powinien ustalić, które dane są potrzebne do tego celu i kto może je zobaczyć. Nie każdy dziennik musi zawierać pełną treść raportu.

OWASP w zaleceniach dotyczących logowania zdarzeń zwraca uwagę na ochronę informacji zapisywanych w dziennikach. Zakres technicznego śladu należy dopasować do konkretnego procesu oraz zasad przechowywania danych. Hasła, klucze i inne sekrety nie powinny trafiać do notatek diagnostycznych tylko dlatego, że ktoś bada błąd pobierania.

Jeśli przygotowanie raportu się nie powiodło, użytkownik potrzebuje czytelnego komunikatu i informacji o dalszym kroku. Nie należy przekazywać pliku częściowego jako kompletnego bez wyraźnego uzgodnienia. Osoba utrzymująca system powinna móc znaleźć problem bez proszenia odbiorcy o przesłanie całej zawartości raportu.

O przypisywaniu odpowiedzialności za błędy piszemy w artykule o monitorowaniu automatyzacji. Również eksport może wymagać kolejki do wyjaśnienia, jeżeli raport przygotowuje się długo albo korzysta z kilku źródeł.

Sprawdź plik i uprawnienia na przykładach

Przygotujcie fikcyjne dane dwóch oddziałów oraz konta o różnych rolach. Sprawdźcie zakres rekordów i kolumn, eksport wszystkich stron listy oraz próbę zmiany parametrów żądania. Osoba uprawniona do jednego oddziału nie powinna otrzymać danych drugiego tylko dlatego, że zna jego identyfikator.

Dodajcie zmianę filtru, nieaktualne źródło i odebranie uprawnienia przed pobraniem gotowego pliku. Otwórzcie plik w programie używanym przez odbiorcę i porównajcie kilka wartości ze źródłem. W teście formatu wykorzystajcie bezpieczne przykłady niezaufanej treści, zgodnie z przyjętą procedurą zespołu.

Przed odbiorem zapiszcie oczekiwane wyniki, osoby je potwierdzające oraz ograniczenia próby. W artykule o kryteriach odbioru aplikacji opisujemy, jak przygotować sprawdzalne scenariusze. Jeśli zewnętrzny odbiorca jest tylko symulowany, rzeczywista droga przekazania wymaga osobnej próby.

Jeśli chcesz uporządkować eksporty w swojej firmie, opisz w briefie odbiorców, potrzebne pola i miejsce, do którego trafiają pliki. Możemy omówić oprogramowanie na zamówienie oraz zakres kontroli dostępu. Napisz do Archifutura, korzystając z fikcyjnego przykładu zamiast danych klientów.