Standardyzacja nowych technologii IT może przebiegać na dwa sposoby, zasadniczo przeciwstawne pod względem filozofii ich budowania. Pierwsza strategia to budowanie standardu “od góry”, przez komitet złożony z mianowanych ekspertów. Druga droga właściwie nie ma wiele wspólnego z przemyślaną stategią - z rynku wybiera się kilka stworzonych mniej lub bardziej na kolanie rozwiązań, nieco wygładza i ogłasza jako standard. W przypadku rynku tak innowacyjnego i szybko ewoluującego jak rynek IT tylko ta druga wydaje się być na razie skuteczna z perspektywy lat.

Nauczka z architektury IP Security

Prześledźmy to na konkretnych przypadkach. Przykładem strategii budowanej “od góry” był w latach 90-tych standard IP Security (IPSec). Był on projektowany przez szacowne grono tęgich mózgów, sieciowców, kryptologów i matematyków z amerykańskiej National Security Agency (NSA). W ciągu kilku lat zbudowano standard niemal idealny pod względem bezpieczeństwa, wydajny i skalowalny, a także mozliwy się do personalizacji (zainstalowania własnych algorytmów kryptograficznych).

Niestety, próba stworzenia rozwiązania pasującego do wszystkich możliwych scenariuszy użycia - które wtedy jeszcze znano tylko modelowo i hipotetycznie - skończyła się klapą. Pierwsza wersja wypuszczona w 1992 roku składała się z trzech kilkusetstronicowych dokumentów. Próbując zrozumieć o co chodzi w trzecim można było zapomnieć co przeczytaliśmy w pierwszym.

Rezultat był taki, że przez pierwsze pięć lat standardu IPSec nikt nie rozumiał. Upłynęły one na próbach stworzenia działającej implementacji przez autorów różnych systemów operacyjnych i stosów sieciowych. Przez kolejne pięć bezskutecznie próbowano doprowadzić do tego by różne implementacje IPSec dogadywały się ze sobą.

W końcu po niezliczonych imprezach “bakeoff”, gdy udało się doprowadzić do względnej kompatybilności, to nagle okazało się że wszystko na nic - bo w międzyczasie cały świat zaczął powszechnie stosować adresy prywatne (RFC 1918) i translację adresów (NAT).

To ostatnie spowodowało, że szlag trafił podstawowe założenie IPSec, jakim była ochrona nagłówków IP. Przyszło więc psuć elegancką (choć złożoną) architekturę IPSec mnóstwem rozszerzeń - NAT-Traversal, XAUTH czy Dead Peer Detection (DPD).

Protokół IPSec przestał rozumieć ktokolwiek, kto nie przerył się przez tysiące stron RFC i dodatkowo nie śledził regularnie list dyskusyjnych architektów rozszerzeń (miałem tę wątpliwą przyjemność projektując szyfrator dla Optimusa). Cyrk zaczął się od nowa - zrozumienie, implementacja, interoperacyjność. Rozwiązanie, które można określić jako teoretycznie doskonałe okazało się mocno ograniczone w praktyce.

Tymczasem lata płyną - w IT dekada to mnóstwo czasu. A ludzie potrzebują rozwiązania swoich problemów natychmiast. Pół-używalny standard powodował uciekanie w różne mniej lub bardziej kalekie domorosłe wynalazki, takie jak PPTPv1 (Microsoft). Wiele firm budowało własne standardy, wywodzące się z IPSec ale przycięte do kompatybilności tylko między dwoma własnymi implementacjami (np. popularne w latach 90-tych szyfratory Borderguard, czy wczesne wersje Checkpoint VPN). Tymczasem standard IPSec został niepostrzeżenie zepchnięty do roli protokołu używanego tylko do szyfrowania połączeń między szyfratorami w sieciach VPN.

Mało kto bowiem pamięta, że początkowa koncepcja była taka, że IPSec będzie tak naturalnym elementem każdego stosu TCP/IP jak np. DHCP i wszystkie komputery w Internecie będą między sobą szyfrować ruch. Była to mrzonka, do której realizacji miał służyć IPSec. W rezultacie w nieproporcjonalnie długim czasie stworzono standard, który swoją złożonością i trudnością użycia głównie odstraszał. A gdy go wreszcie stworzono, okazało się że trzeba go zmieniać bo zmieniły się warunki środowiskowe - pojawił się NAT!

Przykładów takich rozwiązań zaprojektowanych do robienia “wszystkiego” i “idealnych” w teorii jest więcej. Problem polega na tym, że budowa protokołu obsługującego nie w pełni określone scenariusze użycia i bez wyznaczonych priorytetów prowadzi do stworzenia czegoś, co jest niezwykle skomplikowane i nie spełnia swojej roli. W praktyce takie systemy są albo wypierane przez prostsze (tak jak IPSec jest wypierany przez SSL/TLS) albo wykorzystuje się ich ograniczony podzbiór do rozwiązania konkretnych zadań (PKIX, LDAP jako podzbiór DAP).

Partyzancki SSL

Dokładnie odwrotnie niż IPSec wyglądała historia protokołu Secure Sockets Layer (SSL), opracowanego przez prywatną firmę Netscape i prowadzonego przez nią tak długo, aż stał się standardem de facto i ostatecznie został przejęty pod skrzydła IETF pod nową nazwą Transport Layer Security (TLS).

SSL był od początku protokołem odpowiadającym na precyzyjnie zdefiniowane potrzeby - zwiększenia zaufania do handlu elektronicznego. Nawet niekanoniczne jak się wydawało asymetryczne uwierzytelnienie (serwer uwierzytelnia się certyfikatem, ale klient już zwykle hasłem) okazało się zaletą, a nie słabością jak prorokowano początkowo. W tym momencie SSL wypiera IPSec nawet z rozwiązań VPN, tradycyjnie zarezerowanych przez IPSec. Po prostu - łatwiej się go używa, implementuje i zarządza.

Do czego zmierzam? Do tego, że w zetknięciu z niedookreślonymi scenariuszami użycia próba stworzenia “idealnego systemu do wszystkiego” może skończyć się tylko porażką. Przykładem takiej porażki jest europejski podpis elektroniczny, który od prawie dekady (Dyrektywa 1999/93/EC) jest na etapie dopracowywania i usprawniania, a wszystkiemu temu towarzyszą niezliczone analizy i raporty mające odpowiedzieć na pytanie: “dlaczego to nie działa?”.

Dreptając w miejscu i opisując w tych raportach niezwykle szczegółowo fragmenty niedziałającego podpisu nie przyznajemy, że w rzeczywistości nie potrafimy wymodelować układu tak złożonego, by obsłużył wszystkie potencjalne scenariusze użycia. Ale czy rzeczywiście potrzebujemy opisać każdy taki scenariusz? To “komitetowe” podejście niestety nie sprawdza się w praktyce.

Przykładem z lokalnego podwórka jest informatyzacja polskiej administracji publicznej. Miliony złotych wydano już na obszerne analizy, opracowania i strategie, które jednak od początku XXI wieku nie doprowadziły do pełnej realizacji najprostszej nawet funkcjonalności e-administracji. Istniejące rozwiązania są budowane chaotycznie i wzajemnie niespójnie.

Rozwiązaniem nie jest jednak kolejna monumentalna konstrukcja, której opracowanie będzie trwać pięć lat w założeniu, a dziesięć w praktyce. Cały pożytek z takiej architektury zostanie zniweczony przez jej archaiczność w momencie ukończenia, tak jak to się stało z IPSec.

Każdy kolejny rok zmarnowany na "studia wykonalności" to kolejny rok, w którym obywatel nie ma dostępu do narzędzi należących mu się w XXI wieku!</strong>

Budujmy od dołu

Rozwiązaniem tego impasu jest pilotaż, prowadzony przez kilka lub kilkanaście jednostek administracji publicznej, przed którymi należy postawić proste zadanie - oprogramować i ustandardyzować co najwyżej kilku procesów biznesowych, takich jak wydanie lub przyjęcie dokumentu urzędowego od osoby fizycznej lub firmy. Krytyczne jest jednak to, by proces ten przekraczał granice kilku urzędów, co wydaje się jak do tej pory przeszkodą nie do przebycia - tak mentalną jak i proceduralną. To znaczy, by dokument elektroniczny wystawiony przez jeden urząd został przyjęty przez kolejny. Brzmi to łatwo, ale w rzeczywistości takie nie jest. Wymaga bowiem stworzenia współdziałających ze sobą rozwiązań następujących zadań - autentyczności dokumentu elektronicznego, autentyczności wnioskodawcy oraz transportu dokumentu Ale właśnie o to chodzi, by rozwiązać te problemy w praktyce a nie na papierze, co czyniono z zapałem do tej pory. Rozwiązania, które niechętnie będą stosowane w pilotach na pewno polegną we wdrożeniu na skalę monumentalną i nie ma co marnować pieniędzy na ich wdrażanie (co z kolei czyni się z tym większą ochotą, im większe pieniądze). Przede wszystkim jednak należy zapomnieć o budowaniu systemów idealnych i przewidzianych na dekady. W drugiej kolejności porzucić należy ciągoty do pisania rozwlekłych elaboratów, odmieniajacych przez różne przypadki mętny termin "społeczeństwo informacyjne" i nazywanych "strategiami". Napiszmy strategię składającą się z kilku krótkich celów, które rzeczywiście chcemy osiągnąć. Czego ja na przykład osobiście oczekuję od e-administracji? Łatwych, tanich i stosunkowo bezpiecznych faktur elektronicznych. Możliwości otrzymania od jednego urzędu wypisu i złożenia go w drugim urzędzie. Możliwości pobrania ze stron urzędu interpretacji czy przepisu o gwarantowanej autentyczności. Tyle mi wystarczy, by mieć poczucie mitycznego "społeczeństwa informatycznego". Kolejny mętny elaborat wypełniony hasłami tylko nas go od niego oddala.