Tak się jakoś dziwnie składa na tym świecie, że wszelkiego rodzaju zabezpieczenia stanowią najlepszą pułapkę na uprawnionych użytkowników. I tak, alarmy samochodowe lub domowe najczęściej uruchamiają sami ich właściciele, a zabezpieczenia systemów informatycznych stanowią często przeszkodę dla samych użytkowników, a nieraz i dla autorów tychże zabezpieczeń. Szczyt rozpaczy to administrator, który zapomniał swojego hasła do systemu. Nie pozostaje wtedy nic innego, jak skorzystać z pomocy włamywacza lub jego metod.

Niedawno zaangażowałem się emocjonalnie, obserwując walkę jednego z moich programistów z materią informatyczną, a konkretnie z przebijaniem się przez strefy ochronne w technologii wielowarstwowej. Niby wszystko stoi otworem, hasła i konta podane jak na tacy, a do celu dotrzeć nie sposób. I to jest dopiero heca! Autor oprogramowania nie jest w stanie dobrać się do swoich danych. Nie rozumiem zupełnie skąd tyle negatywnych opinii słyszy się na temat słabych zabezpieczeń systemów mikrokomputerowych. Skoro przez trzy progi autoryzacji nie potrafi przebrnąć osoba, która tworzy oprogramowanie i zna hasła dostępu, to co dopiero ma powiedzieć włamywacz, nieposiadający tej wiedzy. Jakże wielki musi być jego trud, aby dojść do zakazanego celu. Jakże potężne i sprytne muszą być narzędzia, które wspomagają go w tej samotnej tułaczce po świecie wielowarstwowej technologii, gdzie na chybił trafił, jak piłeczka pingpongowa, odbija się pomiędzy serwerami, usługami i kontami. Tyle tytułem wolnych żartów.

Temat ten zaistniał dlatego, że MS SQL Server oferuje dwa rodzaje autoryzacji użytkowników, przy czym w zasadzie tylko jeden, nazywany zaufanym, jest preferowany i zalecany na każdym kroku przez Microsoft. Polega on, z grubsza biorąc, na weryfikacji użytkownika przez system operacyjny, a nie wyłącznie przez serwer bazy danych. Niestety ten okrzyczany jako bezpieczniejszy sposób nie bardzo współgra z niektórymi usługami w samym środowisku serwera bazy danych. Przetwarzanie rozproszone z użyciem instancji serwerów połączonych jest dobitnym przykładem kolizji zalecanych i możliwych metod autoryzacji. Tutaj w zasadzie nie sposób sensownie użyć systemowego poziomu uwierzytelniania. Jedyna możliwość to zmiękczenie reguł i stosowanie słabszych i niepolecanych przez producenta metod weryfikacji. Zważywszy na to, że w praktyce coraz częściej występują działania integrujące rozproszone bazy danych, co widać po znaczącym wzroście liczby tematycznych wątków na stosownych listach dyskusyjnych, mogę do firmy Microsoft jedynie wnosić uzasadnione pretensje o macosze traktowanie tematyki przetwarzania rozproszonego. Po pierwsze nieczytelne eksponowanie sposobów autoryzacji - zarówno w helpie, jak i materiałach kursowych dotyczących administrowania serwerem - oraz kontekstu ich zastosowań, a po drugie kompletna ignorancja w temacie spójności przetwarzania rozproszonego, nawet w opasłym podręczniku hucznie zwanym "Resource Kit". A wystarczyłoby kilka zaledwie logicznych zdań mówiących jakie warunki obowiązują dla transakcji rozproszonych i jak kontrolować ich poprawność.

Mam jakieś takie dziwne odczucie, że Microsoft podchodzi do przetwarzania rozproszonego, jakby nie bardzo wierzył w zastosowanie tego nurtu. Ale nie jest to kwestia wiary. Straciłem wraz z zespołem trochę czasu na powtórne odkrywanie Ameryki, gdy realizowaliśmy projekt przetwarzania na kilku serwerach. Teraz to już jest nam obojętne, czy reguły te zostaną gdzieś opublikowane. Ale tym, których to zadanie dopiero czeka, z pewnością nie jest wszystko jedno.