Znowu fora, na jednym z nich pojawił się problem bezpieczeństwa danych, wynoszenia przez pracowników tajemnic i innych ?wrażliwych? danych z firmy i łapanie ich na tym, no tak naprawdę raczej próby złapania. Jeżeli ktoś stwierdzi taki problem u siebie raczej znaczy to, że nie ma narzędzia do szukania sprawcy, więc lepiej nie psuć atmosfery w firmie ?śledztwem? a szybko zrobić dwie rzeczy: dokonać audytu systemu przez zewnętrzną firmę oraz sprawdzić architekturę systemu i jego funkcjonalności tak by zmienić ja na możliwie bezpieczna.
Osobiście jestem właśnie za taką metodą czy zmianą funkcjonalności. Tą metodą da się osiągnąć stan, w którym każdy podsystem ma szczegółowo określone kto nim zarządza i z czym się łączy (interfejsuje). Robiąc dokładny opis całej architektury da się (prawie zawsze) tak dobrać uprawnienia administratorów, żeby ŻADNEJ ?niebezpiecznej? operacji w systemie, jako całości nie mogła wykonać jedna osoba.
Może się tak zdarzyć, że wymaga to pewnych zmian w sposobie zarządzania całą siecią, ale to koszt utrzymania bezpieczeństwa informacji. W dużym uproszczeniu, jeżeli jeden ma prawa do oprogramowania biznesowego a inny do sprzętu to wymagane są co najmniej dwie osoby by wyprowadzić dane i zatrzeć ślady np. w logach.
Drugi bezsens, jaki obserwuję w wielu miejscach to możliwość raportowania ad-hoc bezpośrednio z baz danych… lepiej jednak stosować do tego celu widoki zmaterialozwane?
Jak trafiam na podobne problemy z bezpieczeństwem u swoich klientów to pierwsze, co sprawdzam to właśnie raporty i najczęściej widzę, że prawie każdy może sobie raportować po całych rejestrach!
Niestety jest to wynik tego, że na etapie analizy wymagań pozwalamy pracownikom by specyfikowali wymagania na systemy ERP, wtedy „każdy robi wszystko i na wszelki wypadek ma prawa do wszystkiego” i jak taka specyfikacja zostanie zrealizowana to system ma daleko do bezpieczeństwa, dlatego jestem wrogiem specyfikowania wymagań rękami pracowników, bo zawsze „coś ugrają dla siebie”…
Dostawca oprogramowania z reguły świadomie dopuszcza do takich rzeczy gdyż w tym modelu pracownicy odbierają oprogramowanie, więc pilnie strzegą „swoich uprawnień” wpisanych pierwotnie do specyfikacji a jak ich nie odnajdą to nie podpiszą protokołu odbioru, więc dostawca robi, czego sobie tylko zażyczą… bo wydobyć podpis po dokumentem odbioru systemu wystawić fakturę. W moich oczach, więc największym zagrożeniem bezpieczeństwa jest sytuacja, w której pracownicy średniego i niskiego szczebla są autorami wymagań na oprogramowanie.
Gdybym miał coś zasugerować w kwestii opisanego na początku problemu z wyciekiem danych to wykonanie analizy obecnej funkcjonalności posiadanego oprogramowania, wskazanie wszystkich ryzykownych punktów i dopiero od tego momentu szukał rozwiązania, przy czym nie szukałbym winnego, (bo to będzie teraz trudno udowodnić i jak już wspomniano najpewniej popsuje atmosferę w firmie) a po prostu pozatykałbym jak najszybciej wszystkie dziury.
