Bo zwalniać też trzeba umieć
Jak jest za oknem, każdy widzi. W związku z tym, jak zwykle o tej porze roku, rośnie moja aktywność czytelnicza. Ostatnio przeczytałem kilka książek, których autorem jest Ken Follet: Niebezpieczna fortuna (swoją drogą fajna lektura w kontekście kryzysu), Lwy Pansziru, Klucz do Rebeki, Zamieć. Co ma to wspólnego z IdM, bezpieczeństwem i zwalnianiem?
Mały spoiler : Zamieć opowiada historię włamania do laboratorium, w którym prowadzone są badania nad groźnymi wirusami. Laboratorium takie jest oczywiście dobrze strzeżone, ale włamanie kończy się sukcesem. Na szczęście (dla książki oczywiście) obejścia systemu zabezpieczeń dokonuje nie jakiś genialny haker z dziwnymi (przy okazji – z nieistniejącymi) zabawkami, lecz były pracownik, który go (współ)tworzył. Zna on system (pewien problem) ale przede wszystkim jego dostęp (i hasła, kody), które mógł znać, nie zostały zmienione.
Uważam, że dobry system zabezpieczeń powinien bronić się sam, czyli znajomość zasady jego funkcjonowania, nie powinna wpływać negatywnie na jego skuteczność. Jest jednak wiele przykładów, w których znajomość procedur i mechanizmów bezpieczeństwa pozwala znaleźć w nich lukę (by daleko nie szukać, również w tej książce jest dobry przykład z “uwolnieniem” królika z laboratorium – to oczywiście fikcja literacka, ale nie tak bardzo “fikcyjna”, jak może się wydawać, przykład z “prawdziwego życia”: Société Générale: 31-latek samodzielnie zarządzał transakcjami za 50 mld euro!). Co do zasady jednak bezpieczeństwo systemu nie może opierać się tylko na tym, że (prawie) nikt nie wie, jak on działa, bo znajdzie się ktoś, kto się domyśli i co wtedy? Budować system od nowa? Tu z kolei mam nieodparte skojarzenie z szyfrem Cezara. W tym (fikcyjnym) przypadku to, że intruz był w stanie obejść systemy zabezpieczeń w nikłym stopniu wynikało z faktu, że był ich autorem. Problemem był fakt, że nadal miał do nich dostęp.
Jak być może wiecie, miałem przyjemność uczestniczyć (kierować) we wdrożeniu systemu typu Identity Management. Przedstawiając cele tego systemu dla biznesu kładło się nacisk na sprawną realizację procesu zatrudniania pracownika, oraz późniejszej jego obsługi (aktualizacja danych, zmiana uprawnień). Dla (mojej) działki bezpieczeństwa tak naprawdę najbardziej interesującym elementem był właśnie proces zwalniania pracowników, a w szczególności możliwość zablokowania dostępu do wszystkich systemów, do których zwalniania osoba miała dostęp. Muszę powiedzieć, że odczułem pewną satysfakcję, gdy dowiedziałem się, że system zadziałał prawidłowo w moim przypadku (chyba najbardziej widoczny efekt – natychmiastowe zniknięcie z książki adresowej), gdy nie zdecydowałem się na przedłużenie umowy.
Skuteczność działania systemu tego typu jest oczywiście uzależniona od tego, czy będzie on miał informacje o wszystkich kontach należących do danego użytkownika. Dodatkowym problemem są zwykle różnego typu konta techniczne (konta administratorów, usług, konta “awaryjne”), które często są “bezpańskie”. Co więcej jeśli osobą zwalnianą jest administrator, może się nagle okazać, że zablokowanie jego kont spowoduje, że coś przestaje działać, bo to akurat działa(ło) na jego koncie. Dlatego poza rozwiązaniami technicznymi potrzebne są też przemyślane procedury, oraz czas na to, by to wszystko zaczęło działać.
W każdym razie sytuacja przedstawiona w Zamieci skojarzyła mi się z tym, co może się stać w każdej firmie, która nie ma procedury zwalniania pracowników (zwłaszcza “zwalniania ich” w systemach IT).
...w sumie ciekawe, czy jest jakaś dobra książka, w której pojawiałby się temat computer forensic w sposób bardziej strawny, niż tu: TW Komputer (serial fantasy).
Oryginał tego wpisu dostępny jest pod adresem Bo zwalniać też trzeba umieć
Autor: Paweł Goleń