Комментарии 8
Для каждого работника необходимо составить и утвердить заявку на пользование сетевыми папками. Если сотрудник попробует открыть тот или иной ресурс, доступ к которому не разрешен, администратор получит оповещение о произошедшем инциденте безопасности. АС «Кобальт» предложит создать соответствующий документ – акт о несанкционированном доступе.
Глупый наверно вопрос но все же — а зачем пользователю видеть сетевые ресурсы к которым у него нет доступа? Не проще ли скрыть эти ресурсы + доступ только по белым спискам, а не кому попало?
и вопрос уже более прикладной, как вы определяете местоположение пк? в статье пару раз указано что знаем о пк все вплоть до того где он стоит
и в догонку о закреплении пользователей, есть ли способы борьбы с переселенцами? в моей практике был случай, когда на удаленном от меня филиале 2 бухгалтера поменялись не только машинами, но и учетками, спалились они конечно по глупости — прислали заявку в систему о переименовании одной учетки в другую
Про сетевые ресурсы: тут скорее мы осуществляем контроль за правильностью раздачи прав администраторами. Про «переселенцев» проблема актуальна. Местоположение ПК на данном этапе вносится вручную. Но сейчас работаем над тем, чтобы привязывать местоположение по IP подсети. В нашем варианте кабинеты большие, и админами, как правило, поделены на подсети. Адреса на рабочие станции раздает DHCP, статики немного, и учет ее местоположения вполне вести вручную.
По физическим переселенцам можно реализовать привязку МАС адреса к порту свича и, соответственно, к розетке. У циски это кажется называется port security.
Это сработает только в случае если перетащили пк, а не человек пересел
Кстати вопрос к автору — привязка к пк есть, а контроль за чужими учетками на пк ведете? и как организовали если не секрет?
Кстати вопрос к автору — привязка к пк есть, а контроль за чужими учетками на пк ведете? и как организовали если не секрет?
Да, сработает, только если ПК переехал. Отлавливать, какой человек куда пересел, пока не было необходимости. Контроля за чужими учетками не ведем, поскольку, согласно доменной политике, люди могут работать на «чужих» ПК под своими учетками. Если с «чужого» компа пользователь получает доступ к сетевому ресурсу, здесь неважно, т.к. в журнал попадает событие с какого ПК и под какой учеткой был доступ. Учетка сопоставлена с пользователем, проверяем актуальность заявки на доступ к ресурсу и т.д.
Спасибо за информацию! Осталось только подружить нашу систему и циску. Зато определение места вплоть до рабочего стола в open space.
Такое чувство что все или почти все описаные выше кейсы уже давно и по нескольку раз реализованы в различных продуктах по ИТ управлению, например Solarwinds и иже с ним.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Как мы обобщили информационную безопасность