Paweł Goleń, blog

A teraz wersja nieco dłuższa. W przypadku tworzenia systemu informatycznego określa się wymagania, które dzieli się zwyczajowo na dwie grupy: wymagania funkcjonalne oraz wymaganie niefunkcjonalne. Bezpieczeństwo należy do wymagań niefunkcjonalnych (choć na przykład w przypadku walidacji na upartego można by było dyskutować), podobnie jak na przykład szybkość czy stabilność działania. Jeśli w wymaganiach wyraźnie jest zaznaczone, że system ma obsłużyć 1000 równoczesnych użytkowników zapewniając czas reakcji poniżej 3 sekund na akcję użytkownika, to ma tak być. Widocznie z czegoś to wymaganie wynika, może ktoś przeprowadził badania, z których wynika, że 90% społeczeństwa będzie się irytować, jeśli na odpowiedź będzie czekać więcej niż te przykładowe 3 sekundy (pamiętacie wydajność Naszej Klasy na początku jej funkcjonowania?). Jeśli wykonawca zaakceptował tego typu wymagania, ustalił cenę i podpisał umowę, to ma obowiązek wywiązać się z niej. A nie dostarczyć system, który obsługuje ledwie 50 równoczesnych użytkowników z założonym czasem reakcji, a po przekroczeniu tej liczby - nagle przestaje działać. Podobnie w przypadku bezpieczeństwa - jeśli są przedstawione konkretne wymagania, to mają być one zrealizowane. Jeśli jest wymaganie walidacji wszystkich danych wejściowych, to brak walidacji skończonej liczby parametrów (nawet tych przekazywanych w polach ukrytych) powoduje, że system nie spełnia wymagań. Nie ma miejsca na dyskusję przy oddawaniu projektu, że "...w sumie to nie spełnia wszystkich wymagań, ale nasi Wysokiej Klasy Specjaliści stwierdzili, że w zasadzie tego nie potrzebujecie...". No dobra, tak naprawdę to są miejsca na takie dyskusje, bo przychodzi prezes do prezesa i zaczyna się rozmowa na zasadzie "....wiecie, rozumiecie...". Inne podejście wykonawcy, to udowadnianie, że "ten konkretny brak walidacji do niczego nie prowadzi". Fakt, nie prowadzi. Dlatego został zgłoszony jako błąd "trzeciej kategorii", a nie błąd krytyczny (podoba mi się też określenie, na które natknąłem się na blogu JW on Test, a konkretnie we wpisie the Zune issue: run-down-the-halls-screaming-about-it). Nie zmienia to faktu, że trzeba go poprawić.

Problem pojawia się wówczas, gdy w specyfikacji systemu pominięto wymagania niefunkcjonalne, a dzieje się tak niestety zbyt często. Sam, by mieć podstawy do dręczenia wykonawcy (tak, przyznaję się - uważałem i nadal uważam, że wykonawcę należy czasem postawić do pionu, bo będzie się bardziej starał pracując ze świadomością tego, że jego praca będzie zweryfikowana), na początku zacząłem umieszczać w specyfikacji bardzo wysokopoziomowe wymagania, typu "...system musi zapewniać integralność, poufność i dostępność informacji" albo "zgodność z wytycznymi Certified for Windows Server". Nie było to podejście do końca dobre, ale na początek wystarczyło. Niestety nie dla każdego projektu udało się znaleźć tyle czasu, by dokładne wymagania związane z bezpieczeństwem. Była to też po części moja świadoma strategia zmuszająca do współpracy "właściciela" projektu. Po prostu okazywało się, że z uwagi na dość rygorystyczne wymagania (gdy już udało się opracować bardziej konkretną listę, która była dodawana standardowo do specyfikacji), czas i cena realizacji projektu rosła. Wówczas nagle okazywało się na przykład, że jednak wiadomo jakie dane będą przetwarzane w systemie, nie są to dane osobowe ani dane istotne dla firmy, lecz powszechnie dostępne informacje, których ujawnienie, modyfikacja lub zniszczenie nie ma istotnego znaczenia.

Do czego zmierzam? W przypadku bezpieczeństwa zasada YAGNI również ma zastosowanie. Zaimplementowane mechanizmy bezpieczeństwa powinny mieć swoje uzasadnienie. Nie oznacza to bynajmniej, że "mniej ważne aplikacje" mogą być pisane niestarannie, bez przestrzegania najlepszych praktyk. Wynajmując dużą, uznaną firmę z doświadczeniem nie zamierzam uczyć jej takich oczywistości, że dynamiczny SQL jest zły i co to jest encoding na wyjściu (choć listę dokumentów zawierających te najlepsze praktyki dobrze jest jednak dołączyć i w jakiś sposób zawrzeć wymaganie ich stosowania w umowie, bo te "duże, uznane firmy" o dobrych praktykach nader często tylko gdzieś tam przelotnie słyszały), jest to wiedza analogiczna do tego, że alokując pamięć w C/C++, należy ją później zwolnić. Wracając do tematu - może się okazać, że implementacja jakiegoś mechanizmu bezpieczeństwa w konkretnej aplikacji nie ma sensu. Ale by takie decyzje mogły być podjęte, wymagana jest mniej lub bardziej formalna analiza ryzyka i/lub modelowanie zagrożeń dla danej aplikacji.