Usługa dokumentów dla przewodnika: jak zbudowaliśmy bezpieczne przechowywanie plików w ciągu 3 miesięcy

Bezpieczny system zarządzania dokumentami dla kadry zarządzającej

Kontekst: potrzeba bezpiecznego obiegu dokumentów

W projekcie, w którym odpowiadaliśmy już za scentralizowane uwierzytelnianie oraz usługę wysyłki powiadomień, pojawiło się nowe wymaganie biznesowe: stworzenie systemu do ewidencjonowania i udostępniania dokumentów najwyższej kadry zarządzającej.

Wymagania funkcjonalne

• Tworzenie zagnieżdżonych grup (katalogów) bez ustalonego limitu głębokości.
• Umieszczanie plików i archiwów w katalogach.
• Udostępnianie pojedynczych plików i całych katalogów.
• Szybkie wyszukiwanie po nazwie.
• Filtrowanie według udostępnionych plików, typów plików, rozmiaru i innych parametrów.
• Dodawanie plików i katalogów do ulubionych.
• Przenoszenie elementów do kosza z możliwością trwałego usunięcia wybranych pozycji lub opróżnienia całego kosza.
• Integracja z naszym istniejącym systemem uwierzytelniania. Dla kadry zarządzającej nowa usługa miała pojawiać się jako pierwsza na liście aplikacji.
• Ograniczenie czasu trwania sesji do jednej godziny i wyświetlanie czasu pozostałego do automatycznego wylogowania.
• Możliwość komentowania plików i katalogów przez wszystkich użytkowników mających do nich dostęp.
• Obsługa reakcji na komentarze.

Wymagania dotyczące bezpieczeństwa

Wszystkie pliki musiały być szyfrowane. Nawet gdyby osoba nieuprawniona uzyskała dostęp do przechowywanych plików, nie powinna móc odczytać ich zawartości.

Termin realizacji wynosił trzy miesiące.

Zakres: co oznaczało „rozwiązanie podobne do Dysku Google”

Aby pokazać skalę projektu, warto przedstawić funkcje Dysku Google, które mieliśmy odtworzyć:

• Przechowywanie i organizacja plików — przesyłanie plików, tworzenie folderów i obsługa zagnieżdżonej struktury katalogów bez ustalonego limitu głębokości.
• Udostępnianie — konfigurowalne uprawnienia do wyświetlania, komentowania i edytowania pojedynczych plików oraz folderów.
• Wyszukiwanie — szybkie wyszukiwanie według nazwy, typu pliku, daty modyfikacji i innych parametrów.
• Ulubione — oznaczanie plików i folderów w celu zapewnienia szybkiego dostępu.
• Kosz — przywracanie usuniętych elementów lub ich trwałe usuwanie.
• Współpraca — dostęp wielu użytkowników do wspólnych zasobów oraz współdzielone przestrzenie dla zespołów.

Naszym zadaniem było wdrożenie tych funkcji ze szczególnym naciskiem na bezpieczeństwo, w zamkniętym środowisku przeznaczonym dla kadry zarządzającej.

Architektura: Laravel, PostgreSQL i MongoDB

Wybraliśmy stos technologiczny, który umożliwiał szybkie tworzenie aplikacji i spełnienie wymagań bezpieczeństwa.

Laravel — framework aplikacji

Laravel był naturalnym wyborem w projekcie, w którym liczyły się szybkość realizacji i niezawodność. Zapewniał nam:

• Gotowe mechanizmy uwierzytelniania i autoryzacji.
• Wygodną obsługę kolejek do szyfrowania i przetwarzania plików w tle.
• Ekosystem pakietów do szyfrowania plików.

PostgreSQL — główna baza danych

W PostgreSQL przechowywaliśmy strukturę katalogów i metadane plików:

• Hierarchię katalogów.
• Metadane plików: nazwę, rozmiar, typ i datę przesłania.
• Uprawnienia dostępu.
• Informacje o ulubionych i elementach znajdujących się w koszu.

PostgreSQL odpowiadał za szybkie wyszukiwanie i filtrowanie wymagane przez system.

DocumentDB, a następnie MongoDB — skróty kryptograficzne i klucze powiązań

Początkowo korzystaliśmy z DocumentDB. Później, ze względu na ograniczenia wewnętrznego środowiska, przeprowadziliśmy migrację do MongoDB.

Każdy plik był szyfrowany za pomocą tajnego klucza. W DocumentDB, a następnie w MongoDB, przechowywaliśmy:

• Skróty kryptograficzne zaszyfrowanych plików.
• Unikalne klucze powiązań — nie klucze szyfrujące — służące do łączenia rekordów z danymi w PostgreSQL.

Dlaczego MongoDB, a nie S3?

W naszym konkretnym scenariuszu MongoDB działała szybciej niż S3 w testowanych operacjach związanych z plikami. Responsywność miała znaczenie: dokumenty kadry zarządzającej musiały otwierać się bez zauważalnych opóźnień.

Co istotne, w MongoDB nie przechowywaliśmy samych plików. Znajdowały się tam wyłącznie skróty zaszyfrowanej zawartości oraz klucze powiązań. Metadane plików pozostawały w PostgreSQL.

Ochrona danych: szyfrowanie i krótkie sesje

Ochrona danych była jednym z kluczowych wymagań. Wdrożyliśmy dwie warstwy zabezpieczeń.

1. Szyfrowanie plików

Każdy plik był szyfrowany za pomocą tajnego klucza. Osoba nieuprawniona, która uzyskałaby dostęp do magazynu plików, zobaczyłaby wyłącznie zaszyfrowane dane.

Zastosowaliśmy szyfrowanie strumieniowe, podobne do mechanizmów dostępnych w pakietach do szyfrowania plików dla Laravela. Dzięki temu nie trzeba było wczytywać całych plików do pamięci, co miało szczególne znaczenie przy dużych plikach i archiwach.

Proces wyglądał następująco:

1. Użytkownik przesyła plik.
2. Plik jest szyfrowany za pomocą tajnego klucza.
3. Zaszyfrowany plik trafia do magazynu plików.
4. Jego skrót kryptograficzny i unikalny klucz powiązania są zapisywane w MongoDB.
5. Metadane — nazwa, rozmiar i uprawnienia — trafiają do PostgreSQL.
6. Gdy uprawniony użytkownik pobiera plik, system odszyfrowuje go i przekazuje użytkownikowi.

2. Sesje ograniczone do jednej godziny

Sesje użytkowników z kadry zarządzającej były ograniczone do jednej godziny. Interfejs wyświetlał licznik czasu pozostałego do automatycznego wylogowania.

Był to dodatkowy środek ochrony: nawet jeśli urządzenie pozostawiono bez nadzoru, sesja wygasała po godzinie.

Aktualizacje w czasie rzeczywistym dzięki WebSockets

Zintegrowaliśmy WebSockets, aby przekazywać informacje o zmianach w czasie rzeczywistym.

Dzięki temu:

• Gdy użytkownik udostępniał plik współpracownikowi, pojawiał się on u odbiorcy bez przeładowywania strony.
• Usunięcie lub przeniesienie pliku było widoczne dla wszystkich osób mających do niego dostęp.
• Współpraca stawała się płynniejsza, a interfejs szybciej reagował na zmiany.

Frontend: Vue.js

Frontend zbudowaliśmy w Vue.js. Pozwoliło to zapewnić:

• Szybko reagujący interfejs.
• Wygodną nawigację po zagnieżdżonych katalogach i plikach.
• Integrację z WebSockets na potrzeby aktualizacji w czasie rzeczywistym.

Rezultat: terminowa realizacja i wdrożenie biznesowe

Projekt ukończyliśmy w wyznaczonym terminie trzech miesięcy. System został uruchomiony i jest aktywnie wykorzystywany przez biznes.

Stos technologiczny

KomponentTechnologiaBackendLaravel (PHP)Główna baza danychPostgreSQLPrzechowywanie skrótów i kluczy powiązańDocumentDB, następnie MongoDBKomunikacja w czasie rzeczywistymWebSocketsFrontendVue.js

Wnioski z projektu

1. Ochrona danych jest elementem architektury, a nie dodatkiem

Szyfrowanie plików, krótkie sesje oraz rozdzielenie przechowywania metadanych i skrótów uwzględniliśmy już na etapie projektowania, zamiast dodawać je na końcu.

2. Krótkie terminy są osiągalne przy jasno określonych wymaganiach

Trzy miesiące to niewiele przy takim zakresie funkcjonalnym. Jasne wymagania i odpowiedni dobór narzędzi pozwoliły nam jednak dotrzymać terminu.

3. MongoDB do przechowywania skrótów było nietypowym, ale uzasadnionym wyborem

Skróty często przechowuje się w tej samej bazie co metadane plików. W naszym przypadku MongoDB zapewniła wydajność potrzebną do powiązania plików z odpowiadającymi im rekordami.

Świadomie pozostawiliśmy same pliki poza MongoDB. Obsługa wielu połączeń z bazami danych w Laravelu ułatwiła integrację.

4. Aktualizacje w czasie rzeczywistym usprawniają współpracę

Dzięki WebSockets użytkownicy widzieli zmiany natychmiast, bez konieczności odświeżania strony.

Podsumowanie

Projekt pokazuje, jak można wdrożyć funkcjonalność podobną do Dysku Google w zamkniętym środowisku o rygorystycznych wymaganiach dotyczących ochrony danych.

Wykorzystaliśmy znane technologie — Laravel, PostgreSQL i Vue.js — oraz dodaliśmy mechanizmy potrzebne do ochrony dokumentów kadry zarządzającej: szyfrowanie, krótkie sesje i rozdzielenie przechowywanych danych.

System działa, biznes z niego korzysta, a termin został dotrzymany.