Niedawno odkryłem, że duża część działu finansowego używa Excela do łączenia się z moją instancją SQL Server 2000 z kontem w roli sysadmin. Jakie jest moje obecne ryzyko, które powinienem natychmiast przekazać odpowiednim władzom?
Niedawno odkryłem, że duża część działu finansowego używa Excela do łączenia się z moją instancją SQL Server 2000 z kontem w roli sysadmin. Jakie jest moje obecne ryzyko, które powinienem natychmiast przekazać odpowiednim władzom?
Odpowiedzi:
Prawie wszystko.
Zacznę od ich potencjalnej możliwości użycia xp_cmdshell
(a sp_configure
jeśli nie mogą, to mogą… i cokolwiek, co zwróci konto, xp_cmdshell 'whoami.exe'
może zrobić…), a następnie przejdę do ich zdolności drop database
.
Dalsze zagrożenia obejmują nie tylko użytkowników finansów, którzy mogą wykonywać te czynności, ale każdy program na maszynie finansowej uzyskujący dostęp do poświadczeń połączenia sysadmin ...
(Inne potencjalne zagrożenia obejmują ryzyko odkrycia, że jeden z TPTB skonfigurował to w ten sposób)
select name, salary from employees
update salaries set salary = 0 where employee='swasheck''s boss'
Jedną rzeczą, którą ludzie finansowi powinni zrozumieć, jest to, że dając Excelowi użytkownika systemu, ominąłeś każdą wewnętrzną kontrolę wbudowaną w bazę danych lub aplikację. Właściwy biegły rewident wypatrzyłby ich za to. Na przykład, jeśli masz wbudowane mechanizmy kontrolne, aby upewnić się, że dwie różne osoby muszą zatwierdzić wydatek (aby uniknąć potencjalnego oszustwa), wówczas łącząc arkusz kalkulacyjny Excel w ten sposób, całkowicie usunąłeś tę kontrolę danych.
Jeśli złośliwy użytkownik zniszczy twoje dane, możesz przywrócić dane z kopii zapasowej - w tym scenariuszu powinieneś być w stanie obliczyć wpływ na biznes.
Co gorsza, system nie jest już integralny. Jeśli użytkownik manipuluje danymi w nie katastrofalny sposób, możesz nie odkryć szkód, dopóki kopie zapasowe nie będą już dostępne. Weź pod uwagę wpływ, że firma nie jest w stanie zaufać ważności danych przechowywanych na tym serwerze.