Как вы решаете, что разрешено пользователям контролировать? Для данной функции или функциональности (например, установка общих ресурсов в папке, прикрепление файлов определенных типов к электронной почте, установка USB-устройств) существует ли правило передовой практики, на которое следует обратить внимание, чтобы взвесить риски и выгоды?
Во-вторых, вы по умолчанию блокируете что-то до тех пор, пока его не попросят / не потребуют, или оставляете что-то разрешенным, пока не возникнет проблема? Если не все одно или другое, чем вы руководствуетесь при выборе значения по умолчанию?
Как вы решаете, что разрешено пользователям контролировать?
По моему опыту, для этого нужен комитет. Даже если в организации есть отдельный офис по информационной безопасности, такие вещи требуют поддержки многих людей, прежде чем переходить к деталям реализации. Какая бы система блокировки ни использовалась, она должна быть достаточно гибкой, чтобы легко справляться со специальными снежинками, которые всегда появляются. Используйте слишком грубую систему блокировки (на мой взгляд, AD GPO квалифицируются как «слишком грубые»), и вы в конечном итоге предоставите исключения для широких участков, чтобы удовлетворить немногие истинные потребности.
Тем не менее, как составить список вещей, которые вы хотели бы ограничить, прежде чем приступить к этой серии встреч? В первую очередь нужно поставить цели. Выясните, чего вы пытаетесь достичь, блокируя вещи. Список вещей, которые нужно заблокировать, «предотвращение заражения вредоносным ПО» отличается от «предотвращения утечки информации о коммерческих секретах», который отличается от «предотвращения несанкционированной установки программного обеспечения».
После того, как у вас будет список целей, начните изучать настройки вашего продукта блокировки и выяснить, на что он способен. Некоторые из самых драконовских пакетов используются в университетских компьютерных лабораториях, чтобы поддерживать их в чистоте и, как правило, эффективны в этой среде. Такие пакеты редко используются в корпоративной среде, поскольку они слишком грубые для общего использования. Другие продукты подключаются к механизмам GPO, чтобы разрешить те же виды ограничений, но на групповой основе, что позволяет более детально подходить к ним, чем это делает собственная AD. Третьи используют свои собственные способы блокировки. Итак, узнайте, на что способен ваш продукт.
Теперь, когда у вас есть список того, чего вы хотели бы достичь и что вы действительно можете сделать, пора приступить к тяжелой работе - выяснить, что именно будет отключено. Если возможно, начните с политики, которая эффективно гласит: «Каждый пользователь будет получать свежее изображение рабочей станции каждое утро и не сможет вносить в нее какие-либо изменения», а затем расширяйте ее. Некоторым пользователям потребуется постоянная установка программного обеспечения. Или многофункциональные устройства с USB-подключением. Или несколько веб-браузеров для рабочих целей. Выяснение того, какие вещи необходимо разрешить для того, чтобы ваше предприятие функционировало, займет некоторое время, поэтому тестирование также включает в себя этот процесс.
Вы спросили о руководствах по передовой практике. К сожалению, это, как правило, зависит от конкретного приложения. Руководства по передовой практике, которые я видел, представляют собой более общие, абстрактные вещи, такие как «Предотвращение несанкционированной установки программного обеспечения для минимизации потерь времени службы поддержки», а не «отключение запроса запуска». По этой причине существует множество руководств по передовой практике для таких вещей, как AD GPO, и не так много для таких вещей, как Novell ZenWorks.
Лично я считаю, что лучшая стратегия - сначала посмотреть на все сверху вниз, а затем медленно начать открывать вещи, пока пользователи не смогут выполнять свою работу. Если есть особый случай (который обычно бывает), то их можно рассмотреть и принять меры в том, что можно считать безопасной средой.
В большинстве случаев описанные вами проблемы (настройка общих ресурсов, отправка типов файлов, установка устройств) обычно указывают на то, что это, вероятно, лучший способ сделать это.
Например:
Установка общих ресурсов - Почему нет централизованного репозитория для файлов, к которым необходимо получить доступ? Отправка типов файлов - действительно ли мы максимально эффективно используем имеющееся у нас программное обеспечение? Установка устройств. Всем ли пользователям нужна эта функция? Зачем?
Я бы не стал думать об этом как о риске против. система вознаграждений. Подумайте, как работает система в целом, какие части вас просят улучшить и, что наиболее важно, почему эти изменения могут быть необходимы.
Я второй sysadmin1138 с точки зрения поддержки, но есть еще одна причина для получения информации - в зависимости от вашей организации вы можете не знать достаточно о том, что все ваши пользователи делают каждый день на своей работе.
Некоторые проблемы, которые я видел как разработчик,
В приведенных выше случаях было бы хорошо хотя бы слышать от разработчиков, даже если вы на самом деле Слушать им.
В целом я считаю, что разработчики (и администраторы баз данных) вообще не должны подвергаться блокировке. Но у них обязательно должен быть доступ к заблокированной учетной записи пользователя для тестирования (а также к стандартной настольной сборке), иначе вы рискуете, что они приготовят что-то, что работает только на их машинах.
Что касается обычных пользователей, Раймонд Чен сказал, что «политика - это не то же самое, что безопасность», и это необходимо учитывать при разработке любой блокировки. Цель блокировки - держать пальцы подальше от частей системы, которые могут привести к увеличению накладных расходов на поддержку в случае вмешательства, а не для назначения разрешений или ограничений. Так что задокументируйте эти части и отталкивайтесь от них.
Вы также должны подкрепить это решение здравым смыслом. Если у вас нет бездонной кучи денег, вы, вероятно, не создаете резервные копии рабочих столов обычных пользователей, поэтому сделайте все возможное, чтобы они не сохраняли файлы на свой диск C (вам может потребоваться некоторое время, чтобы убедить некоторых руководителей высшего звена в том, что это на самом деле Меньше безопаснее, чем сохранение их в сети). Если сотрудник службы поддержки пытается устранить неполадки, мешает ли этому ваша блокировка? Должны ли общественные машины иметь стандартный набор обоев? Имеет ли значение, разрешено ли пользователю менять обои на компьютере, не предназначенном для публичного доступа?
Еще одна вещь, в которую нужно углубиться - если вы имеете в виду групповую политику - это узел «Назначение прав пользователя». У меня есть общая практика запрета интерактивного входа в систему для определенных учетных записей пользователей, например учетных записей служб. Использование общих учетных записей для интерактивного входа в систему - это плохо, поскольку вы фактически получаете бесполезный контрольный журнал, так что вот ваш шанс предотвратить его, прежде чем это станет проблемой для вас.
Наконец, постарайтесь сохранить как можно меньше уровней изоляции. Это упрощает управление, снижает риск конфликта объектов групповой политики и других подобных развлечений.
Здесь уже много замечательных комментариев. Я просто добавлю свои два цента.
Я думаю, что основная проблема, с которой вы столкнулись, заключается в том, что у вас нет реальной политики безопасности или она явно неадекватна.
вы по умолчанию блокируете что-то, пока оно не запрашивается / не требуется, или оставляете что-то разрешенное, пока не возникнет проблема
Оба этих подхода - ужасный способ реализации безопасности. Если вы заблокируете все, и людям придется жаловаться, чтобы выполнять свою работу, они не только будут разочарованы и возмущены, но и однажды вы потеряете работу, если кто-то из руководства не сможет выполнять свою работу из-за вашего запрета. Если вы разрешите все и реализуете безопасность только после того, как что-то пойдет не так, компания берет на себя ненужный риск со своими активами, и снова ... вы будете нести всю вину.
Вся идея реализации политики безопасности заключается в следующем:
1) Это документированная политика компании, которую ВСЕ должны знать и соблюдать.
2) Это политика сотрудничества, в которую внесли свой вклад все заинтересованные стороны, сформированная при поддержке руководства. В отличие от политики, вы обязаны произвольно формировать свою собственную и обвиняться в возникновении проблем.
Прежде всего, вы должны понимать бизнес-потребности ваших пользователей. Не существует «лучших практик», или, возможно, я должен сказать, что «лучшие практики» в некоторой степени неверно употребляются. Как уже было сказано, единого мнения о политике безопасности не существует. Ваш передовой опыт определенно не будет близок к моему. Вам нужно выяснить, что вашим пользователям нужно делать на своих машинах и в ваших сетях, чтобы выполнять свою работу (их бизнес-потребности), чтобы вы могли делать свою. Так что иди и узнай. Сформируйте комитет, разошлите опрос, опросите заинтересованных лиц, принесите в жертву барашка на столе вашего генерального директора - все, что подходит для вашего рабочего места.
Когда у вас появятся бизнес-потребности, вам нужно задать себе несколько вопросов.
Что вы пытаетесь защитить? Вы защищаете рабочие столы продаж или машины разработчиков? У них будут совершенно разные бизнес-потребности и подходы к безопасности.
От кого вы пытаетесь их защитить? Вредоносные сотрудники ... посторонние ... пользователи от самих себя?
Каковы риски? Какова ценность этих активов для компании? Если риск или ценность незначительны или отсутствуют, стоит ли тратить человеческие часы или деньги на защиту? Сколько будет стоить защита? На такие вопросы, вероятно, придется частично ответить вашему начальству. ИТ-отдел обычно не может решить, на какой риск компания готова пойти, вы можете только умолять их не брать на себя слишком много риска и CYA (письменно!), Если они отклонят ваши рекомендации.
Как только это будет сделано, задокументируйте политику и внедрите ее с помощью технических средств контроля и / или письменной политики компании, если это необходимо.
Это краткое изложение процесса. Целые книги документировали процесс формирования, написания и реализации политики безопасности, и я настоятельно рекомендую вам прочитать!
Вспомните уроки TRON. Системы должны быть разработаны для обслуживания пользователей. Ваша общая цель должна заключаться в создании удобных систем, которые не снижают производительность труда сотрудника. Помните, что в ИТ мы облегчаем бизнес, а не контролируем его. Ваш лучший помощник - обеспечить бесперебойную работу бизнеса, а продуктивным и счастливым конечным пользователям предоставить инструменты, необходимые для выполнения работы.
Для этого вам необходимо хорошо понимать, что будут делать пользователи. Возможно, вам даже придется разбить пользователей на группы, если их повседневная работа требует большей или меньшей функциональности, чем другие. Создавайте политики на основе этих групп и должностных функций. Поговорите с людьми, которые выполняют эту работу, и изучите их процессы, чтобы убедиться, что ваши системы помогают им в их обычных повседневных операциях.
Затем внимательно подумайте о своей безопасности. Незащищенная система в мгновение ока превращается в глючную вредоносную программу, на которой трепещет зверь. Полностью защищенная система никогда не включается и полностью непригодна для использования. Вам нужно найти не золотую середину, а баланс, который нужен вашим пользователям в вашей организации, и дать им простоту использования и душевное спокойствие.
Безопасность должна быть максимально прозрачной и обеспечивать четкую обратную связь с пользователями при активации. Хорошим примером может служить устройство шлюза / брандмауэра, на котором работает прозрачный прокси. Настройте этот прокси-сервер для поиска вирусов, блокировки вредоносных программ и спама. Когда прокси-сервер блокирует контент, вы должны четко указать конечному пользователю, что произошло и почему. Не предоставляйте все технические детали, а дайте ясное объяснение. С таким типом безопасности настройка пользовательских приложений не требует особой работы, пользователю не нужно слишком много думать о безопасности, и, тем не менее, вы повысили ценность и безопасность своего шлюза.
Когда вы, наконец, поймете, какая работа выполняется и что вам нужно сделать, чтобы надежно ее облегчить, вы можете приступить к созданию политики на основе того, что вы узнали. Убедитесь, что все знают, что такое политика, и получите как можно больше отзывов, чтобы постоянно совершенствовать ваши политики безопасности и ИТ-методы. Будьте осторожны и не относитесь к своим политикам безопасности так, как будто они высечены на камне. Они должны быть достаточно гибкими, чтобы позволить вашему бизнесу менять направление по мере необходимости и оставаться конкурентоспособным, сохраняя при этом ваши основные принципы безопасности.
Последняя мысль. Для начала - ни один процесс, сервер, устройство или объект не должны оставаться незащищенными, пока безопасность не будет нарушена. Если вы работаете в этом режиме, значит, вы уже проиграли битву. - Удачи
Анализ риска и вознаграждения. Для любой конкретной функции, которую вы можете отключить для пользователя, подумайте, сколько времени вы потеряете на решение проблемы, насколько вероятна проблема и сколько времени * будет стоить пользователю отсутствие этой функции. Отрегулируйте относительную ценность вашего времени и времени пользователя (блокируйте компьютер уборщика больше, чем компьютер генерального директора).
* Возможно, вам придется присвоить произвольное значение желаниям, не связанным с производительностью работы.
Как вы решаете, что разрешено пользователям контролировать? Имеется ли для данной функции или функциональности (например, установка общих ресурсов папки, прикрепление файлов определенных типов к электронным письмам, установка USB-устройств) какое-либо правило Best Practices, которое поможет взвесить риски и выгоды?
У каждой организации разная устойчивость к риску. Вам необходимо выяснить, каковы соответствующие уровни толерантности к риску в вашей организации, и решить, каковы риски и выгоды. Обычно общее сравнение безопасности - это удобство. Почти всегда существует прямая корреляция между [не] удобством и [не] безопасностью. Таким образом, вопрос, который следует задать тем, кто принимает эти решения, если вы не в состоянии сделать это, заключается в следующем: «Ограничение этого сделает людей менее продуктивными до такой степени, что затраты на бизнес будут больше, чем риск допустить это». ? "
Во-вторых, вы по умолчанию блокируете что-то до тех пор, пока его не попросят / не потребуют, или оставляете что-то разрешенным, пока не возникнет проблема? Если не все одно или другое, чем вы руководствуетесь при выборе значения по умолчанию?
Опять же, это субъективно, а не объективно. [Драконовская] политика некоторых организаций будет требовать, чтобы все было ограничено, если для этого нет конкретной деловой причины. Другие организации позволят все, что не оказывает негативного влияния на бизнес и производительность. Самая безопасная политика часто - ограничить все, но упростить запрос на разрешение. Таким образом, вы можете поддерживать более высокий уровень безопасности (и, возможно, проводить аудит), но при этом упростить задачу для тех, кому может потребоваться доступ к чему-либо, способному получить этот доступ без проблем.
Простые в использовании системы заявок значительно упрощают отслеживание (и поддержание позиции готовности к аудиту), и ваши пользователи с меньшей вероятностью будут восстать против вашего руководства по поводу нелепых политик, которые мешают им выполнять работу.
В настоящее время мы не заблокировали ни одну из наших служебных машин, но близки к тому, чтобы переместить Мои документы и некоторые другие общие папки в отдельный раздел, а затем заблокировать остальную часть машины с помощью Windows SteadyState ... по крайней мере, для некоторых пользователей.
Определяющим фактором стало недавнее заражение вредоносным ПО.
SteadyState является бесплатным и позволит вам ограничить то, что пользователи могут делать, и позволит вам заблокировать диск, чтобы каждый перезапуск возвращал машину в предварительно сконфигурированное состояние.
Один размер не подходит для всех. Разделите пользователей по двум направлениям: что им нужно для выполнения своей работы (легко понять) и с чем они способны справиться, не подвергая сеть риску (трудно понять), а затем соответственно заблокировать.
Один размер подходит всем. Жесткая блокировка будет раздражать пользователей, которые знают, что нельзя нажимать на случайные URL-адреса в электронных письмах, и побудит их найти обходные пути для вас (мошеннический Wi-Fi, подключающийся к мошенническим серверам), которые они будут подключаться обратно к вашей сети, вызывая больше проблем .
Применить принцип наименьших привилегий. Дайте им право выполнять работу, не больше и не меньше.
Определите типы ваших пользователей и любые категории, которые вы можете сделать. Например, если у вас есть разработчики с Visual Studio 2005, они должны работать с локальной административной учетной записью, а это означает, что ваши действия с этой системой довольно ограничены. Но конечный пользователь, которому нужен только Microsoft Office, вы можете многое. Уловка здесь не в том, чтобы быть слишком детализированным. Вы можете определить пользователя за пользователем, но тогда вы окажетесь в точке, где административно вы убьете себя.
После того, как вы сделали разделение, выясните, есть ли какие-то общие вещи (например, отсутствие USB / портативных накопителей), которые могут широко применяться в среде, за некоторыми исключениями. Создайте те глобальные политики, в которых нет исключений (или используйте такие механизмы, как упорядочивание объектов групповой политики, которые могут отменить настройки в случае возникновения исключений). Не только в технологии, но и в политике безопасности с зубами.
Затем начните спускаться по отдельным категориям. Выясните, что необходимо, и убедитесь, что у них есть доступ для этого. Заблокируйте все остальное, что разумно, что не предусмотрено глобальной политикой.
Как вы решаете, что разрешено пользователям контролировать?
1) Что нужно контролировать пользователям, чтобы выполнять свою работу?
2) Что не имеет значения, так или иначе? (например, действительно ли имеет значение, если кто-то в роли, где клиенты никогда не увидят рабочий стол своего компьютера, захочет выбрать свои собственные обои для рабочего стола?)
3) Что можно заблокировать, чтобы упростить управление системой, не затрагивая пользователей?
4) Что должно быть заблокировано до некоторой степени, чтобы пользователи не зашли в «тупик» (например, скрыть параметры для включения поддержки факсов с ПК, если это никогда не сработает в вашей локальной сети, чтобы пользователи не тратили свое время, пытаясь использовать это и ваше время, связанное с просьбами помочь заставить его работать)