O bezpieczeństwie systemów bankowych

Od czasu do czasu pojawiają się informacje w mediach o sytuacjach, w których "komputer się pomylił". Samą informację można potraktować z przymrużeniem oka, ale skłania ona do postawienia pytania: czy stosowanie komputera jest bezpieczne?

Od czasu do czasu pojawiają się informacje w mediach o sytuacjach, w których "komputer się pomylił". Samą informację można potraktować z przymrużeniem oka, ale skłania ona do postawienia pytania: czy stosowanie komputera jest bezpieczne?

Można wymienić wiele cech, którymi musi charakteryzować się system bankowy, ale jedną z najważniejszych jest szeroko rozumiane bezpieczeństwo. Jest to cecha za którą często płaci się dużą cenę. Na poczuciu bezpieczeństwa opiera się zaufanie klienta do banku. Bezpieczeństwo informacji przechowywanych w banku, pewność zachowania tajemnicy potrzebna jest zarówno klientom banku, jak i bankowi.

System bankowy z punktu widzenia informatyka należy do szerszej klasy systemów, do klasy systemów informatycznych.

Etapy tworzenia systemu nazywa się cyklem życia systemu. Proces tworzenia systemu jest procesem iteracyjnym. Etapy powtarza się tak długo, aż uzyska się zamierzony efekt. Jeżeli na którymś z etapów pojawia się sytuacja, której nie przewidzieliśmy, to należy cofnąć się do etapu wcześniejszego i dokonać modyfikacji.

Cały proces tworzenia systemu dzieli się na następujące etapy:

1. analizę

2. projekt

3. realizację projektu - pisanie kodu programu

4. testowanie

5. eksploatację

6. konserwację.

Etapy od 1 do 4 to etapy tworzenia systemu a 5 i 6 to etapy jego użytkowania.

Na etapie analizy funkcyjnej należy wyspecyfikować błędne sytuacje, możliwe do określenia na tym poziomie abstrakcji problemu. Są to prawie wszystkie sytuacje, które prowadzą do błędu np. występowanie w zestawie dokumentów przeznaczonych do wczytania dokumentu nie należącego do danej grupy. Oprócz określenia błędnych sytuacji należy podać sposób reagowania na nie. Jest to bardzo istotne, gdyż wprowadzenie automatyzacji każdego procesu prowadzi do niebezpieczeństw. Wielu ludzi nie zdaje sobie sprawy z konsekwencji wprowadzenia automatu. Wbrew powszechnemu mniemaniu możliwe jest to tylko w sytuacjach typowych, w których wszystko jest dokładnie zdefiniowane. Jeśli w trakcie działania systemu zaistnieje sytuacja nietypowa, to zachowanie się systemu często jest trudne do przewidzenia. Nie jest możliwe określenie wszystkich błędnych sytuacji. Czasem świadomie rezygnuje się z kontroli jeśli prawdopodobieństwo wystąpienia błędnej sytuacji jest bardzo małe, a koszty kontroli są zbyt duże (koszty w sensie czasu pracy komputera). Świadomie obniża się poziom bezpieczeństwa systemu w zamian za zwiększenie wydajności. Są co najmniej dwie możliwe drogi znalezienia zbioru błędnych sytuacji. I jak to w życiu często bywa jedna łatwa, prosta ale "zła" i druga trudna, kręta i pod górkę ale za to "dobra". Ta zła to taka, kiedy nie przewiduje się błędów, awarii. W trakcie działania systemu okaże się co, może się zdarzyć. Jest to podejście narażające użytkownika na przykre konsekwencje. Trudniejszy sposób polega na określeniu wszystkich możliwych sytuacji i podzieleniu całego zbioru na sytuacje dopuszczalne i niedopuszczalne. Schemat postępowania jest prosty i oczywisty, ale warto mu się przez chwilę przyjrzeć, gdyż zawiera pewne pułapki. Nie zawsze jest oczywiste określenie zbioru wszystkich sytuacji. W zależności od osoby, odpowiedzi mogą być różne. Czasem "praktyk" ten zbiór utożsamia ze zbiorem sytuacji z jakimi się styka na co dzień. Dobry analityk nie może dać się zwieść.

Projekt funkcjonalny

Na etapie projektu należy określić błędy mogące wystąpić w trakcie działania programu. Mogą one wynikać z błędów w programie lub z wystąpienia sytuacji, której nie określiło się na etapie analizy. Nie sposób wyeliminować wszystkich błędów w programie. Często ujawniają się one dla pewnego zestawu danych stąd bardzo ważny jest etap testowania o czym jeszcze później. Projekt musi uwzględniać diagnostykę błędów. Błędy są skorelowane z czynnościami wykonanymi w trakcie działania systemu oraz z jego stanem. Stąd ważne jest również pamiętanie historii systemu. Diagnostyka powinna umożliwić nie tylko zidentyfikowanie błędów, ale również sytuacji w jakich one wystąpiły. Sytuacje takie to np. błędne dane wejściowe lub wykonanie przez operatora systemu czynności nie przewidzianej przez analityka i projektanta. Diagnostyka może składać się z wielu etapów. Jeśli to tylko możliwe powinna być wykonywana na bieżąco w trakcie działania systemu. Może jednak być to zestaw procedur diagnostycznych, wykonywanych przy zamknięciu systemu np. na koniec dnia operacyjnego.

Projekt techniczny

Projekt techniczny (projekt realizacji funkcji opisanych w czasie analizy i w projekcie funkcjonalnym) musi uwzględniać wnioski z etapów wcześniejszych. W projekcie tym podaje się algorytmy zapewniające spełnianie funkcji przewidzianych wcześniej. Do realizacji systemów bankowych zatrudnia się technologię bazy danych. Jest kilka przyczyn, które to uzasadniają. Najbardziej oczywista to taka, że systemy baz danych (dla skrótu - SBD) tworzone są do gromadzenia i wyszukiwania informacji, a właśnie ta cecha charakteryzuje systemy bankowe. Nowoczesne SBD zapewniają również mechanizmy pozwalające zachować tzw. integralność danych. Baza danych składa się z wielu rodzajów danych powiązanych ze sobą różnymi relacjami. Na przykład informacje o stanach sald na rachunkach bankowych powiązane są z informacjami o klientach. Integralność bazy danych oznacza, że wszystkie relacje między danymi spełniają warunki charakteryzujące dany typ relacji. Nie ma np. w bazie rachunku, który należałby do więcej niż jednego klienta, wszystkie numery klientów należą do zbioru numerów poprawnych, itd. Innymi słowy dane przechowywane w bazie są dobre. Mechanizmy zapewniające integralność danych zapewniają ich bezpieczeństwo, a to wypisz, wymaluj temat tego artykułu dlatego nie będę już pisał o integralności, a o bezpieczeństwie. Realizacja projektu z zastosowaniem SBD pozwala programiście skupić się na określeniu typu wszystkich danych oraz relacji między nimi, bez potrzeby zagłębiania się w techniczne sposoby zapewniania bezpieczeństwa danych.

Teoria, standardy i praktyka

Kolejną cechą SBD uzasadniającą ich stosowanie jest to, że są one poparte wiedzą teoretyczną. Modele danych oraz metodologia tworzenia bazy danych mają swoje teoretyczne uzasadnienie. Istnieją formalne metody określenia, czy baza jest dobrze zaprojektowana. Istnienie takich modeli danych i metod pozwala na tworzenie baz danych, które z całą pewnością są dobrze zaprojektowane oraz na automatyzację procesu tworzenia projektu bazy. Narzędzia typu CASE (Computer-Aided Software Engineering) pozwalają na tworzenie graficznego opisu danych i relacji między nimi oraz na automatyczne generowanie opisu struktury bazy danych.

Obecnie najważniejszym modelem bazy danych jest model relacyjny. Dla tego modelu stworzono język zapytań SQL. Istnieje standard ANSI (American National Standard Insitute) tego języka (SQL-89 oraz jego rozszerzenie SQL-92). Ma to ogromne znaczenie, gdyż producenci SBD starają się zachowywać standard, dzięki czemu możliwe staje się uniezależnienie od SBD oraz od jednego systemu komputerowego, zarówno od tzw. platformy sprzętowej, jak też od systemu operacyjnego. Dlatego jeśli dokona się właściwego wyboru narzędzi można dostarczyć użytkownikowi SBD aktualny do żądanego przez niego system komputerowy. Proste, nie SQL- owe SBD co prawda nie zapewniają tak szerokiego wachlarza operacji i sposobów zapewnienia integralności bazy danych, ale mogą zapewnić przenośność między różnymi systemami operacyjnymi.

Dokładne przeanalizowanie zagadnienia bezpieczeństwa danych prowadzi również w konsekwencji do przyspieszenia realizacji projektu. Błędy pojawiające się w trakcie działania systemu można szybko zlokalizować korzystając z mechanizmów diagnostyki. Największą uwagę w tworzeniu systemu należy zwrócić na wczesne etapy - analizę i etapy projektowe. Jakość wykonania tych etapów ma podstawowe znaczenie w osiągnięciu sukcesu. Jak pokazują doświadczenia firm, które analizowały zagadnienia jakości i niezawodności, koszt usunięcia usterki rośnie z etapu na etap w potędze 2, tzn. jeżeli nie zauważy się błędu, to koszt jego usunięcia na następnym etapie wzrośnie dwukrotnie, a na kolejnym aż czterokrotnie!! Stąd relatywnie mniejsze znaczenie etapu realizacji projektu w aspekcie bezpieczeństwa i niezawodności. Niemniej jednak można zaprzepaścić efekty osiągnięte na etapach wcześniejszych, dlatego warto zastanowić się jak uniknąć tego niebezpieczeństwa. Jakość oprogramowania zależy od umiejętności programisty. Doświadczony programista wie jak uniknąć pułapek i zmniejszyć ryzyko wystąpienia błędów. Stąd konieczność poznawania nowoczesnych metod programowania oraz poszukiwanie własnych rozwiązań. Praca zespołowa stwarza możliwość powstawania przekłamań i niejednoznaczności z powodu komunikacji między uczestnikami procesu tworzenia systemu. Tworzenie i przestrzeganie norm na różnych etapach i poziomach sprzyja polepszeniu komunikacji. Na przykład zasady tworzenia opisów i dokumentacji, znane i przestrzegane, wpływają na ich czytelność.

Ostatnim etapem tworzenia systemu (choć nie ostatnim etapem cyklu życia systemu) jest etap testowania. Testowanie nie jest zadaniem prostym. Niezbędna jest do tego wiedza o metodach badania jakości oraz duże doświadczenie. Testowanie odbywa się na wielu poziomach. Na poziomie systemu testy wykonywać powinna wyznaczona osoba (lub zespół). Odpowiedzialna jest ona za przygotowanie planu testów oraz zestawu danych testowych. Plan testów przygotowuje się tak, aby sprawdzić możliwie wszystkie ścieżki przez jakie może "przechodzić" system. Jest to zadanie trudne, gdyż wymaga znajomości zarówno procesu, który się komputeryzuje, jak i tworzonego systemu. Zestaw danych testowych powinien być taki, aby obejmował zakres danych poprawnych oraz niepoprawnych. Pozwala to na obserwowanie reakcji dla różnych sytuacji. Potrzebne jest doświadczenie i intuicja, gdyż pewne defekty objawiają się w sytuacjach nietypowych np. dla pewnej szczególnej konfiguracji danych, stanu systemu oraz czynności operatora. Niektóre testy trudno wykonać przed wdrożeniem systemu do eksploatacji, np. zachowanie się dla bardzo dużej liczby danych.

Stworzenie dobrego, bezpiecznego systemu jest możliwe tylko wtedy, gdy wszystkie etapy będą wykonane dobrze. Z tego punktu widzenia nie ma ważniejszych i mniej ważnych etapów. Do każdego z nich potrzebne są: wiedza, umiejętności oraz doświadczenie. Konkluzja a zarazem odpowiedź na postawione na wstępie pytanie brzmi: tylko wysokie kwalifikacje całego zespołu tworzącego system bankowy dają gwarancję jego bezpiecznego stosowania.

W celu komercyjnej reprodukcji treści Computerworld należy zakupić licencję. Skontaktuj się z naszym partnerem, YGS Group, pod adresem [email protected]

TOP 200