ноябрь    2024

Пн	Вт	Ср	Чт	Пт	Сб	Вс
				1	2	3
4	5	6	7	8	9	10
11	12	13	14	15	16	17
18	19	20	21	22	23	24
25	26	27	28	29	30

показать все 

14.11.2024

Обновление BI.ZONE Secure DNS: гибкая настройка фильтрации и максимальная скорость

Читать далее 

14.11.2024

RED Security: в октябре количество DDoS-атак на ТЭК выросло в 3 раза

Читать далее 

14.11.2024

Falcongaze представила новую версию DLP-системы — SecureTower 7 Helium

Читать далее 

14.11.2024

ИСП РАН покажет результаты 30-ти лет работы на Открытой конференции в Москве

Читать далее 

08.11.2024

Юбилейная конференция ЭОС: ЭОС: 30 лет лидерства на рынке автоматизации документооборота и обсуждение актуальных трендов

Читать далее 

показать все 

22.11.2024

Тандем технологий – драйвер инноваций.

Читать далее 

21.11.2024

ИИ: маршрут не построен, но уже проектируется

Читать далее 

18.11.2024

Глеб Шкрябин: «Надежные и масштабируемые системы — основа стабильной работы бизнеса в условиях больших нагрузок»

Читать далее 

14.10.2024

Елена Ситдикова: «На разработчиках программного обеспечения для транспорта лежит большая ответственность перед пассажирами»

Читать далее 

11.10.2024

Технологический ИИ-арсенал

Читать далее 

13.06.2024

Взгляд в перспективу: что будет двигать отрасль информационной безопасности

Читать далее 

18.04.2024

5 способов повысить безопасность электронной подписи

Читать далее 

18.04.2024

Как искусственный интеллект изменит экономику

Читать далее 

18.04.2024

Неочевидный САПР: выход ПО за рамки конструкторской деятельности

Читать далее 

18.04.2024

Скоро некому будет делать сайты и заниматься версткой

Читать далее 

показать все 

Главная / Архив номеров / 2013 / Выпуск №1 (24) / Как защититься от сисадмина?

Рубрика: ИТ-управление

Павел Одинцов, технический директор компании FastVPS

Как защититься от сисадмина?

Ваш системный администратор решил съездить в гости к аллигаторам? Уйти к конкурентам? Боитесь? Напрасно! Выполнив ряд простых рекомендаций, вы забудете об администраторе как о незаменимом сотруднике!

Актуальность данной темы очень сложно переоценить, так как количество случаев потери данных по причине заведомо деструктивных действий системных администраторов огромно. Об этом пестрят форумы, пишут в блогах и даже наглавном сайте журнала «Системный администратор» опрос «Мстили ли вы своему начальнику?» выведен на главную страницу.

Нет, здесь мы не будем говорить о случаях потери данных по вине ошибок или некорректной конфигурации оборудования – все эти темы находятся за гранями обсуждаемого вопроса. Речь пойдет исключительно о заведомо деструктивных действиях, которые может совершить уволенный или просто не чистый на руку системный администратор.

Все меры противодействия можно разделить на организационные, ориентированные в первую очередь на высших руководителей компаний, и технические, ориентированные на технических руководителей.

Организационные меры

Среди организационных моментов, на которые стоит обратить внимание в первую очередь, – оформление любых учетных записей (хостинга, доменов и проч.) в сторонних компаниях. Оформление должно осуществляться исключительно нареального владельца услуги (генерального директора компании) или юридическое лицо (предпочтительно), а не на сотрудника, исполняющего обязанности системного администратора. В случае конфликтной ситуации почти невозможноили крайне сложно и долго по времени доказывать, что это был лишь сотрудник, а не реальный владелец услуги.

Также стоит обратить внимание на то, что для всех действий, связанных с рабочими вопросами (регистрация учетных записей, деловая переписка), следует использовать исключительно рабочий e-mail (в домене компании), а не личный адрес сотрудника. Если же это невозможно (например, когда сам домен только регистрируется), допустимо использование личного e-mail руководителя как административного контакта и личного e-mail администратора как технического.

Вторым немаловажным моментом является обязательное законодательное оформление всех отношений с системным администратором, чтобы в случае конфликта иметь юридические основания для жалоб в ответственные органы. Разумеется, это не гарантирует отсутствия проблем, но минимизирует их и позволяет компенсировать убытки при конфликте.

Особо внимательными стоит быть при поиске системных администраторов-фрилансеров, которые зачастую ничем не могут гарантировать своей добропорядочности. Тут необходимо обращать внимание на наличие большого числа доверенных рекомендаций и хорошего портфолио у специалиста, а также на поведение и манеру общения человека.

Крупной компании также можно порекомендовать выделение подразделения информационной безопасности, в круг обязанностей которого будет входить и контроль за системными администраторами.

Технические меры

Из технических аспектов наиболее важным является резервирование данных и наличие актуальных доступов ко всему оборудованию/программному обеспечению у руководителя ИТ-службы или компании в целом.

О резервировании данных написано огромное количество документации, но вот редко кто уделяет внимание не менее важному вопросу – как же защитить данные от самого системного администратора.

Из собственного опыта я могу порекомендовать руководителю ИТ-службы следить за тем, чтобы администратором в обязательном порядке было настроено резервное копирование критичных данных (баз данных, файлов сайтов, рабочей документации). Причем не стоит удовлетворяться отчетом «задача выполнена», не помешает лично потребовать восстановить работу сайта, допустим, недельной давности на тестовом оборудовании, чтобы убедиться, что резервирование работает и работает корректно (это наиболее важно). Если же позволяет квалификация, то руководителю стоит изучить способы резервного копирования и лично контролировать его выполнение (когда данных много, это, безусловно, почти невозможно, но всегда есть возможность резервировать самые критичные данные, например, сведения о клиентах и финансовую документацию) на доступный только руководителю ресурс хранения. Это сэкономит нервные затраты иповысит устойчивость бизнеса в ИТ-сфере.

Наличие административных доступов у руководства – это очень важный с точки зрения методологии DRP (disaster recovery plan, план восстановления после сбоя) пункт. Сбоем в данном случае называем конфликт с системным администратором, необходимость его быстрой замены и минимизации рисков потери данных. При наличии актуальных доступов к оборудованию/аккаунтам имеется время, чтобы владелец мог сменить пароли лично. Кроме этого, приналичии актуальных доступов возможно привлечение сторонних специалистов (или же нового системного администратора) для передачи инфраструктуры им на обслуживание в максимально короткие сроки.

Если в компании используется большое количество лицензируемого ПО, стоит обратить внимание на то, чтобы все лицензии на ПО хранились в строго определенном месте (для бумажных лицензий лучшее место – сейф), дабы исключить их потерю, так как восстановление подобной информации крайне и крайне затруднительно.

Имеется еще один интересный момент, связанный не с безопасностью данных напрямую, но с экономией времени и средств. Речь идет о том, что все результаты работы системного администратора должны быть четко задокументированы, иначе при увольнении сотрудника по тем или иным причинам будут полностью потеряны его наработки (конфигурация оборудования, ПО, различные регламенты и проч.), что неминуемо ведет к необходимости повторной реализации данных задач.

***

Резюмируя все вышесказанное, хочется обратить внимание на то, что безотказная работа ИТ-инфраструктуры обеспечивается не только грамотными техническими решениями, но и внимательной и качественной работой системных администраторов.

В начало⇑

Комментарии отсутствуют

Комментарии могут отставлять только зарегистрированные пользователи