Фича вайтлистинга обещает быть эффективной, но даже в отрыве от специфики реализации платформы Касперского в целом, видны следующие подводные камни:
- трудоемкость поддержки - ведь вот эти "Всего-то делов внести в базу данных новое приложение или поставить галочку в правильном месте в системе управления защитой – 10 секунд" Касперского применимы только к СМБ.. в крупном бизнесе необходима четкая авторизация действия, а это подпись руководителя сотрудника запросившего установку ПО, ее проверка, внесение записи о факте разрешения в базу полномочий пользователей (либо единоразовая интеграция с БД Касперского, но об этом в статье Касперского ни слова.. ) и хранения доказательств на случай расследования. Только таким образом мы можем понять, что сотруднику это ПО нужно в производственных целях.
- фрагментация пользовательского опыта ("Причём пользователи могут отправить заявку на разрешение определённого приложения прямо из клиента KES.") - нынешние ИТ-департаменты стараются свести все взамодействия с пользователем к т.н. "единому окну". Концепция понятна - это удобно и пользователям (понятно куда бежать), и ИТ - проще контролировать качество ИТ-услуг и их прозрачность (ценобразование, соответствие требованиям и т.п.). И в это время в статье нет упоминания интеграции данного коммуникационного канала хотя бы с двумя наиболее популярными системами управления ИТ-услугами промышленного класса - BMC Remedy\HP Service Manager.
- "ложное" ощущение снижения рисков связанных с обновлениями - преподнесенная как панацея технология контроля обновлений никак не работает с риском взлома вендора (если я не прав - пусть вендор поправит меня;), и заражения конечной точки через взломанный сервер обновлений. Взлом Sourceforge уже доказал реальность такого сценария, и тут нужен банальный "прокси" когда вендор будет у себя на серверах проверять обновления софта а потом спускать их клиентам. Но об этом в статье тоже не упомянуто..
Комментариев нет:
Отправить комментарий