Trwały nośnik. O co w tym wszystkim chodzi? Krótki rys historyczny.
Trwały nośnik jest to temat, który dotyczy nie tylko naszego polskiego „podwórka”. Pierwszym znanym mi przypadkiem w Unii Europejskiej, była sprawa austriackiego Banku BAWAG P.S.K., która poniekąd ukształtowała dalsze losy tego tematu. Problem trwałego nośnika szybko przekroczył również granicę Polski i stał się solą w oku naszych rodzimych instytucji finansowych. Na pierwszy ogień dostało się bankom, ale moim zdaniem aż się prosi, aby ta krucjata rozlała się również na pozostałe rynki (na przykład ubezpieczeniowy i telekomunikacyjny).
Oto jak wygląda ta historia.
Listopad 2015.
Urząd Ochrony Konkurencji i Konsumentów (UOKiK) kwestionuje praktyki banków, dotyczące sposobu kontaktowania się z klientami drogą elektroniczną w zakresie zmian warunków umownych (czyli między innym zmian regulaminów oraz tabel opłat i prowizji). W tym czasie w bankach zaczynają się (albo wkrótce się zaczną) prace nad regulacjami PSD 2 i MIFID II. Pojawiają się również pierwsze dyskusje na temat Rozporządzenia o Ochronie Danych Osobowych (RODO), które zacznie obowiązywać 25 maja 2018 roku. Do bogatej listy obowiązujących regulacji dodany zostaje jeszcze jeden punkt, który na rynku zaczyna być określany mianem trwałego nośnika. W rezultacie w bankach formują się grupy projektowe. A ich podstawowym zadaniem jest znalezienie odpowiedzi oraz przedstawienie rozwiązania, które usatysfakcjonuje regulatora.
Styczeń 2016.
UOKiK rozpoczyna postępowanie wobec 6 banków. Kolejnych 11 dołączy do tej listy jeszcze w sierpniu tego samego roku.
Luty 2016.
KNF wydaje opinie na temat wymogów, jakie powinien spełniać trwały nośnik.
Styczeń 2017.
Trybunał Sprawiedliwości Unii Europejskiej wydaje wyrok w sprawie C‑375/15 (Bank BAWAG P.S.K. przeciwko austriackiemu odpowiednikowi naszego UOKiKu). Trybunał orzeka, co następuje:
„Zmiany w informacjach i warunkach, o których mowa w art. 42 omawianej dyrektywy oraz zmiany w umowie ramowej, które dostawca usług płatniczych przekazuje użytkownikowi tych usług przez skrzynkę poczty elektronicznej na stronie internetowej bankowości elektronicznej, można uznać za dostarczone na trwałym nośniku w rozumieniu tych przepisów tylko wtedy, gdy zostaną spełnione poniższe dwie przesłanki:
- rzeczona strona internetowa daje temu użytkownikowi możliwość przechowywania informacji adresowanych osobiście do niego w sposób umożliwiający dostęp do nich i odtworzenie ich w niezmienionej postaci we właściwym okresie, bez możliwości jednostronnego wprowadzenia przez tego dostawcę lub przez innego przedsiębiorcę zmian do ich treści, oraz
- jeżeli użytkownik usług płatniczych jest zmuszony wejść na tę stronę internetową, aby zapoznać się z nowymi informacjami, przekazaniu tych informacji towarzyszy aktywne zachowanie dostawcy usług płatniczych zmierzające do podania do wiadomości użytkownika istnienia i dostępności tych informacji na wskazanej stronie internetowej.”
Kwiecień 2017.
UOKiK przestaje negować wykorzystanie systemu bankowości internetowej na potrzeby trwałego nośnika. Podkreśla jednak konieczność zapewnienia niezmienności i nieusuwalności zarówno na płaszczyźnie technologicznej, jak i prawnej oraz organizacyjnej. Urząd kwestionuje pomysł, który opiera się na oznaczeniu pliku certyfikatem i znacznikiem czasu. Wymienia jednak „macierz WORM” jako jedno z dopuszczalnych rozwiązań.
Maj 2017.
Prezes UOKiK wydaje pierwszą decyzję w sprawie trwałego nośnika, w której pojawia się zarzut naruszenia przepisów.
W tym samym czasie, już od kwietnia 2016 roku, po drugiej stronie barykady trwają konsultacje oraz przygotowania koncepcji prawnej i funkcjonalnej dla problemu trwałego nośnika. Jeszcze w grudniu 2016 roku przedstawiony zostaje w Urzędzie pomysł rozwiązania opartego między innymi o macierz obiektową z wbudowaną technologią WORM. Koncepcja spotyka się z aprobatą regulatora, a rozwiązanie to zaczyna być określane mianem „macierzy WORM”.
Podstawowe wymagania związane z trwałym nośnikiem…
są między innymi wypadkową wątpliwości UOKiKu, które skupiają się wokół takich trzech obszarów.
Bank ma pełną kontrolę nad systemem bankowości internetowej oraz może ingerować w informacje, które dostarcza swoim klientom na przykład na ich elektroniczne skrzynki pocztowe. Istnieje zatem ryzyko, że bank będzie wprowadzał zmiany w dokumentach klientów i na ich szkodę. Dlatego właśnie na początku tej historii system bankowości internetowej nie został zakwalifikowany jako system, który nosiłby znamiona trwałego nośnika. Co zresztą spotkało się z dużym sprzeciwem banków oraz instytucji związanych z tym środowiskiem.
Bank nie ma możliwości, aby potwierdzić, czy klient zapoznał się z przekazaną wiadomością. Ale czy w przypadku listu poleconego, który jest powszechnie stosowany i akceptowany mamy gwarancję, że odbiorca tego listu przeczytał jego zawartość? I co ważne, czy przeczytał ją ze zrozumieniem, bo tak naprawdę chyba tylko wtedy moglibyśmy mówić o prawdziwym dostarczeniu informacji? 
Bank nie zapewnia właściwego dostępu do określonych dokumentów. Giną one w skrzynce pocztowej w stercie reklam i ofert usług bankowych. Ale jak zapewnić taki dostęp po ustaniu relacji prawnej klienta z bankiem?
Wątpliwości te można w prosty sposób przekuć na wymagania związane z trwałym nośnikiem i dalej, w kolejnym kroku również na cechy jakie powinno posiadać rozwiązanie, które będzie adresować te wymagania. No to spróbujmy to zrobić.
Po pierwsze, niezmienność. Dostawca usług musi zagwarantować odtworzenie przechowywanych informacji w niezmienionej postaci oraz nie może pozwolić na ich usunięcie.
Po drugie aktywne informowanie. Bank musi dostarczyć informacje poprzez aktywne powiadamianie klienta o ich zamieszczeniu w systemie bankowości internetowej lub w zewnętrznym portalu wykorzystywanym w komunikacji z klientem.
I po trzecie dostęp do informacji przez odpowiedni okres. Klient banku musi mieć możliwość przechowywania informacji, adresowanych osobiście do niego w sposób, który umożliwi dostęp do nich w przyszłości. A przyszłość ta, to co najmniej okres przedawnienia roszczeń związanych z daną umową.
Warto pamiętać, że każdy z tych elementów powinien być zagwarantowany w płaszczyznach: technologicznej, organizacyjnej oraz prawnej. A im bardziej skomplikujemy temat na tym najniższym poziomie (technologicznym), tym trudniejsza będzie jego realizacja z punktu widzenia organizacyjnego, procesowego i prawnego.
Potencjalne rozwiązania.
To właśnie w takich sytuacjach jak w przypadku trwałego nośnika, widać jak ogromne pokłady wyobraźni drzemią w narodzie oraz jak bardzo potrafimy być kreatywni. Do UOKiKu trafiły różne pomysły. Najprostszym i najpewniejszym rozwiązaniem akceptowalnym przez regulatora jest papier. Na temat jego trwałości można co prawda prowadzić szereg dyskusji, natomiast w kontekście tematu trwałego nośnika zyskał on akceptacje Urzędu. Niestety wydruk i wysyłka tradycyjnych listów papierowych oraz dostarczenie ich wszystkim klientom banku okazuje się być bardzo kosztowną imprezą. Dodatkowo takie podejście stoi w sprzeczności z trendami transformacji cyfrowej oraz niewiele ma wspólnego z nowoczesnością.
Na ratunek niektórym bankom miały przyjść płyty CD/DVD. Bank może tutaj wyeliminować koszty wydruku i jest trochę bardziej nowoczesny, ale płyty również trzeba dostarczyć do klienta tradycyjną pocztą. No i poza tym, jakie musi być zdziwienie klienta, który otrzyma taką przesyłkę i nie będzie miał sposobu na odczytanie zawartości płyty. W końcu coraz mniejsza ilość komputerów posiada czytniki płyt CD/DVD. To może wysyłajmy pendrive'y? 
No ale chwileczkę, jest przecież jeszcze poczta elektroniczna. Niestety banki nie w każdym przypadku posiadają pełną bazę adresów email swoich klientów. A dodatkowo w takim scenariuszu istnieje zagrożenie ujawnienia tajemnicy bankowej.
Naturalnym w takim przypadku jest rozwiązanie zbudowane w oparciu o podpis elektroniczny. Technologicznie wydaje się spełniać warunki i wymagania, ale niestety nie dla regulatora. Podpis elektroniczny wraz ze znacznikiem czasu może być wprawdzie elementem systemu, ale nie jest wystarczający do zaakceptowania tego rozwiązania przez Urząd.
Ostatecznie na placu boju pozostały dwa rozwiązania (nie licząc tradycyjnej wysyłki papierowej, na którą stać tylko te najbogatsze banki). Blockchain oraz macierz WORM.
Blockchain jest to bardzo nowoczesne rozwiązanie, przed którym moim zdaniem rysuje się równie ciekawa przyszłość. Ale wykorzystanie tej technologii dla scenariusza trwałego nośnika, wiąże się z kilkoma wyzwaniami, które trzeba wziąć pod uwagę i zapisać po stronie ryzyka takiego projektu. Co to za wyzwania?
- Jak odpowiedzieć na coraz większą ilość wątpliwości prawnych i organizacyjnych, w tym między innymi tych, które dotyczą tajemnicy bankowej i rozproszonego działania łańcucha bloków oraz odpowiedzialności za potencjalne nieprawidłowe działanie systemu?
- Jak podzielić zasoby w łańcuchu pomiędzy bankami, które będą uczestniczyły w takim projekcie (zakładając, że komputery, zgodnie z ideą blockchaina, będą rozproszone pomiędzy wszystkimi zainteresowanymi stronami). Jeżeli podzielimy zasoby po równo, to może się okazać, że mały bank, będzie przetwarzał i przechowywał w blokach większą ilość cudzych transakcji (klientów większego banku), niż swoich własnych. I będzie musiał zainwestować swoje pieniądze w te zasoby.
- Jeżeli założymy, że to rozproszenie zasobów będzie proporcjonalne do ilości transakcji, to istnieje prawdopodobieństwo, że największy bank może posiadać więcej niż 50% zasobów w łańcuchu. A to oznacza, że teoretycznie będzie mógł wpływać na (zmieniać) zawartość bloków. Dlaczego teoretycznie? Ponieważ z finansowanego punktu widzenia raczej nikomu nie będzie się to opłacać (koszty wykonania takiej zmiany vs. korzyści jakie miałaby ona przynieść). Poza tym oczywiście wszyscy uczestnicy łańcucha zostaliby powiadomieni o takiej sytuacji. Nie zmienia to jednak faktu, że taki scenariusz jest możliwy. I mimo że z logicznego punktu widzenia jest raczej mało prawdopodobny, to warto rozważyć potencjalne ryzyko z tym związane. Pamiętam, co kiedyś, dawno temu, powiedział przewodniczący składu sędziowskiego na jednej z rozpraw, w której miałem okazję uczestniczyć. „Nie ważne, czy coś jest logiczne, czy nie. Ważne, aby było zgodne z literą prawa.”
- Jak zweryfikować wydajność działania łańcucha, który tak naprawdę budowany byłby od podstaw dla tego konkretnego scenariusza wykorzystania? Potrzebny jest prototyp i czasochłonne testy. A akurat w przypadku trwałego nośnika, czas nie jest sprzymierzeńcem banków.
- Nawet jeżeli prototyp spełni oczekiwania wydajnościowe i funkcjonalne, to należy go później wdrożyć na produkcji, co oznacza niełatwą integrację łańcucha z istniejącymi systemami oraz znowu wymaga czasu.
Prawdopodobnie dlatego banki, które chciały zamknąć temat trwałego nośnika jak najszybciej, zdecydowały się na zainwestowanie w to drugie rozwiązanie, czyli w macierz obiektową z technologią WORM.
„Macierz WORM”.
Choć, gdybyśmy chcieli być trochę bardziej precyzyjni, to należałoby napisać: obiektowy magazyn danych, który wykorzystuje technologię WORM. W tym scenariuszu to właśnie tutaj przechowywane są dokumenty.
WORM. Write Once Read Many. Zapisz jeden raz, czytaj wiele razy. Oznacza to ni mniej, ni więcej tyle, że raz zapisany dokument, nie może zostać zmieniony. I w macierzy obiektowej pilnuje tego nie tylko sama technologia WORM, ale również mechanizm sum kontrolnych (kluczy hash). Generowane są one dla każdego zapisywanego w magazynie dokumentu i są regularnie weryfikowane przez uruchomiony w tle proces. A przez to pozwalają one na utrzymanie tak zwanego łańcucha dozoru oraz udowodnienie przed regulatorem (lub klientem banku) autentyczności dokumentu. A gdy do tego dodamy jeszcze politykę retencji, która zabrania usuwania pliku przed upływem określonego czasu, to będziemy mieli komplet najważniejszych narzędzi i funkcjonalności macierzy obiektowej dla trwałego nośnika. WORM, sumy kontrolne, retencja. Te cechy pozwalają kontrolować niezmienność i nieusuwalność dokumentów. Ale czy to na pewno wystarczy, aby macierz obiektowa mogła być wykorzystana w projekcie trwałego nośnika? W kolejnym rozdziale dowiesz się na co jeszcze warto zwrócić uwagę, przy wyborze takiej macierzy. A tymczasem wróćmy jeszcze na chwilę do pozostałych wymagań. Jak już pewnie zauważyłeś(aś) sama „macierz WORM” pomoże odpowiedzieć na wymagania związane z niezmiennością i nieusuwalnością dokumentów. Natomiast dostęp do tych dokumentów oraz ich aktywne dostarczenie jest gwarantowane przez drugi komponent rozwiązania. I w zależności od decyzji i wyboru banku jest nim albo system bankowości internetowej, albo dedykowany portal dla klientów banku. Zdarzają się również przypadki wykorzystania w tej architekturze oprogramowania pośredniczącego (middleware) na przykład typu ECM (Enterprise Content Management), które integrowane jest z macierzą obiektową.
W przypadku wyboru opcji z niezależnym portalem, informacje dla klientów banku przekazywane są na dedykowanej stronie, niezależnej od portalu bankowości internetowej. Na stronie tej klient banku może wybrać sposób komunikacji (i co ważne, może ten wybór zmienić w dowolnym, wybranym przez siebie czasie). Strona ponadto musi umożliwiać zmianę hasła oraz musi posiadać możliwość monitorowania otwarcia dokumentu.
Zewnętrzny portal jest dobrą alternatywą w scenariuszu, w którym ustaje relacja prawna klienta z bankiem. Wtedy klient nadal ma dostęp do swoich dokumentów (regulaminów, umów, tabel opłat i prowizji), bez konieczności logowania się do systemu bankowości internetowej.
W przypadku zastosowania opcji, w której dostęp i dostarczenie dokumentów realizowane jest poprzez system bankowości internetowej, macierz obiektowa jest integrowana z tym systemem poprzez odpowiednie konektory lub dostępny w tej macierzy interfejs API. W systemie bankowości internetowej udostępniana jest dla klienta banku skrzynka lub folder z dokumentami. Do skrzynki tej nie mogą być wysyłane żadne reklamy i oferty usług bankowych. W przypadku ustania relacji klienta z bankiem wszystkie inne funkcje bankowości internetowej są wyłączane. Ponieważ jednak niesie to za sobą konieczność utrzymywania systemu bankowości internetowej dla już byłego klienta, dlatego banki myślą tutaj czasami również o zastosowaniu rozwiązania hybrydowego. Bankowość internetowa w czasie, gdy klient posiada konto lub inne produkty banku oraz przekierowanie do zewnętrznego portalu, gdy relacja zostanie zakończona.
Diabeł tkwi w szczegółach.
Pierwsze prototypy oraz wdrożenia tego rozwiązania pokazały na co warto zwrócić uwagę przy wyborze macierzy obiektowej z WORMem. Poniżej przygotowałem dla Ciebie krótką listę porad, dobrych praktyk i wniosków wyciągniętych z tych instalacji.
Sprawdź, czy macierz posiada stosowne audyty lub certyfikaty, które potwierdzą, że dane w niej zapisywane są rzeczywiście niezmienne i nieusuwalne. Pomoże Ci to bronić rozwiązania przed regulatorem.
Zastanów się, czy nie będziesz potrzebował funkcjonalności partycjonowania (multitenancy). Być może będziesz chciał wykorzystać tę macierz również dla innych scenariuszy.
Jeżeli tak, to niektóre z nich mogą wymagać możliwości niszczenia danych na żądanie lub po upływie określonego czasu. Jednym z przykładów jest tutaj Rozporządzenie o Ochronie Danych Osobowych i prawo do zapomnienia. I mimo, że prawo to dla wielu rodzajów danych przechowywanych w instytucjach finansowych i tak nie będzie działać (ponieważ będą nad nim stały inne kodeksy i regulacje branżowe), to jednak jestem pewny, że znajdziesz wśród swoich danych takie zbiory i takie regulacje, dla których zapewnienie bezpowrotnego usuwania dokumentów jest jednym z podstawowych wymagań.
Upewnij się, czy urządzenie posiada możliwość pracy w trybie, który pozwala na usuwanie plików przed upływem ich retencji (np. dokumenty z danymi osobowymi) oraz jednocześnie w trybie, który tego zabrania (np. dokumenty, które podlegają regulacji trwałego nośnika).
Równie ważne jest, aby niezmienność każdego dokumentu mogła być udowodniona w oparciu o sumę kontrolną, która jest przechowywana razem z dokumentem i tak samo zabezpieczona jak ten dokument.
Pomyśl o szyfrowaniu danych na dyskach oraz podczas replikacji pomiędzy ośrodkami.
W niektórych przypadkach użycia może Ci się przydać również wersjonowanie dokumentów.
Wybierz właściwy protokół komunikacyjny do integracji urządzenia z aplikacją. Rekomendowane (ale nie jedyne) są tutaj REST API, HTTP, S3, jako typowe protokoły obiektowe. To znaczy takie, które potrafią przekazywać nie tylko dane, ale również metadane i polityki. W metadanych możesz przechowywać na przykład informacje o tym, co się działo z danym dokumentem. I dodatkowo, ponieważ są one przechowywane wewnątrz macierzy WORM, to również mogą być objęte retencją. Wybór protokołu będzie oczywiście zależał do tego, jakim językiem mówi Twoja aplikacja.
Jeżeli protokołem tym jest NFS, to nie mam dobrych wiadomości. Oczywiście macierze obiektowe z reguły obsługują również tego typu protokoły. I technologicznie taka integracja będzie jak najbardziej możliwa. Pytanie tylko, czy uda Ci się obronić przed audytem lub regulatorem pewną „właściwość”, jaką posiada ten protokół (niezależnie od logo producenta urządzenia). Otóż w przypadku NFS-a niezmienność i trwałość otrzymujemy w wyniku takich oto zdarzeń. Najpierw zapisujemy dokument do systemu plików, a potem zabieramy atrybut zapisu. Inaczej mówiąc, w przypadku protokołów plikowych (NFS, CIFS) funkcjonalność WORM uzyskujemy poprzez ustawienie atrybutu plików na „tylko do odczytu”. I teraz najważniejsze. Za czas, od którego retencja rozpoczyna swój bieg uznaje się datę ostatniego dostępu do pliku, co oznacza, że istnieje przedział czasu, w którym można dokonać zmian w pliku zapisanym na nośniku NFS/CIFS WORM. Długość tego przedziału zależy od producenta urządzenia, ale w niektórych przypadkach liczona jest ona nawet w minutach. To z kolei przeczy założeniom regulatora i podnosi realne ryzyko dla banku (ryzyko związane z tym, że takie rozwiązanie nie zostanie zaakceptowane).
Inny przypadek dotyczy integracji macierzy obiektowej z aplikacją pośredniczącą typu middleware. Na przykład z już wcześniej wspomnianym ECMem. Zwróć wtedy uwagę na funkcjonalności i ograniczenia konektora, który jest zazwyczaj wykorzystywany do takiej integracji. Szczególnie jeżeli chciałbyś, aby część Twoich dokumentów była przechowywana na trwałym nośniku, a pozostałe - w innym urządzeniu (na przykład na serwerze plików, który już posiadasz).
I wrócę jeszcze na chwilę do metadanych. Czy nie byłoby idealnie, gdybyś mógł je indeksować i na tej podstawie wyszukiwać informacji przechowywanych w magazynie? A gdyby dodatkowo urządzenie posiadało interfejs API do wyszukiwania, to mógłbyś taki mechanizm uruchomić na przykład bezpośrednio w Twojej aplikacji.
Warto również pomyśleć o tym, co zrobisz z danymi po zamortyzowaniu się macierzy. W którymś momencie będziesz zapewne potrzebował przenieść dane do nowego urządzenia. W przypadku scenariuszy, w których należy zapewnić niezmienność danych, trzeba o tej niezmienności pamiętać nie tylko na etapie przechowywania, ale również podczas migracji. Musimy zapewnić tak zwany łańcuch dozoru dla wszystkich dokumentów. Dlatego przydadzą się w macierzy mechanizmy, które upraszczają taką migrację lub nawet pozwalają na jej przeprowadzenie w trypie bezprzerwowym (bez konieczności wyłączania / restartowania usługi).
I na koniec pamiętaj, że niezmienność i brak możliwości kasowania mogą być zapewnione również na poziomie programowym. Instalujemy oprogramowanie WORM np. w wirtualnych maszynach. Ale kontrola nad dokumentami jest wtedy możliwa tylko wewnątrz tego oprogramowania. Nie będzie ono w stanie zapobiec skasowaniu pliku z wirtualną maszyną, czy całego wolumenu dyskowego, na którym ta maszyna jest zainstalowana. Jeżeli nie jesteś pewny, czy uda Ci się obronić takie rozwiązanie przed regulatorem, to chyba lepiej wybrać gotowe, zamknięte rozwiązanie typu appliance, które nie pozwala na ingerencje w BIOS, firmware, czy nawet system operacyjny urządzenia.
Jak zoptymalizować inwestycje i zacząć korzystać z nowoczesnego obiektowego magazynu danych w szerszym zakresie?
"Ale ja nie chcę wdrażać kolejnego rozwiązania punktowego w mojej organizacji. I dlaczego miałbym budować następną wyspę pamięci masowej. Czy nie można byłoby wdrożyć rozwiązania pod trwały nośnik, ale z perspektywą wykorzystania go również w innych scenariuszach?"
Oczywiście, że można. Obiektowe pamięci masowe, posiadają możliwość tworzenia tzw. tenantów (wirtualnych partycji). W ramach tych tenantów tworzone są przestrzenie nazw – odpowiedniki systemu plików. Każdy tenant możesz dedykować np. oddzielnym klientom wewnętrznym (działom, departamentom, liniom biznesowym). Każdy z tych działów może mieć wiele aplikacji, które będą przechowywały swoje dane w dedykowanych dla nich przestrzeniach nazw. Dzisiaj możesz zacząć od jednej aplikacji i od jednego projektu lub scenariusza wykorzystania. Załóżmy, że jest to właśnie trwały nośnik. Ale nic nie stoi na przeszkodzie, aby tę samą macierz użyć na potrzeby innych regulacji prawnych (MIFID II, RODO) lub dla zupełnie innych scenariuszy użycia. W ten sposób tworzysz centralny magazyn danych obiektowych, który posiada nie tylko możliwość przechowywania danych, ale również rozumie metadane i potrafi je indeksować oraz wyszukiwać. A ponadto gwarantuje niezmienność i brak możliwości kasowania zarówno danych, jaki i metadanych.
Więcej na temat macierzy obiektowych oraz scenariuszy ich wykorzystania przeczytasz również w tym artykule. Zapraszam!
Dodaj komentarz