Контакты
Подписка
МЕНЮ
Контакты
Подписка

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

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

В рубрику "JOB" | К списку рубрик  |  К списку авторов  |  К списку публикаций

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

Андрей Тархов
руководитель отдела внедрения и
техподдержки Rainbow Security

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

Как предотвратить неприятную сиуацию?

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

Эта концепция реализуется в виде распределения обязанностей между IТ-подразделением и отделом ИБ. Кроме того, можно ввести третье лицо – владельца информации – сотрудника, который определяет правила использования и права доступа к ней. Скорее всего он не является системным администратором, а занимает менеджерскую позицию и принимает участие в принятии решений.

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

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

Шифрование

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

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

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

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

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

Опубликовано: Журнал "Information Security/ Информационная безопасность" #5, 2010

Приобрести этот номер или подписаться

Статьи про теме