Практически в любой современной операционной системе существует возможность разграничить доступ к определенным ресурсам на уровне пользователей. Таким образом, каждый пользователь в сети ПЦ (в том числе и рабочую станцию, и сервер можно отнести к пользователям) имеет определенные права, которые должны быть формализованы и закреплены в письменном виде. Права и полномочия предоставляются каждому сотруднику ПЦ согласно его должностным обязанностям. В случае если сотрудник совмещает несколько обязанностей (например, администратор ЛВС и администратор БД), удобнее оперировать ролями. Каждой роли отводятся определенные полномочия, в рамках которых предоставляется доступ к ресурсам ПЦ.
Служебные роли ПЦ могут быть отождествлены с группой пользователей. В роли администратора ЛВС может выступать группа пользователей «администраторы», в роли сотрудников отдела архивных копий — «операторы архивов» и т. д. В каждой из групп может быть несколько пользователей сети, в то же время один пользователь сети может быть наделен несколькими полномочиями.
Все сотрудники обязаны иметь учетную запись, с помощью которой осуществляется регистрация в сети ПЦ. Далее эта учетная запись используется для доступа к любым сетевым ресурсам, будь то принтер или база данных.
При разработке политики безопасности для сотрудников должно быть установлено правило секретности собственных имени пользователя и пароля при регистрации в сети. Также должен быть установлен запрет на передачу персональных имени пользователя и пароля третьим лицам. В ходе формирования политики должны быть приняты меры по снижению вероятности компрометации паролей: установлены ограничения на минимальную длину пароля, его сложность и частоту смены.
Согласно последним данным[108] рекомендуемая длина пароля может быть принята свыше 8 символов. Существуют и рекомендации по сложности пароля, в которых определяют, что пароль может состоять из строчных и заглавных букв и цифр. Частота смены пароля позволяет уменьшить вероятность его подбора за определенный срок его жизни. Хорошей практикой может служить блокировка учетной записи в случае набора неправильного пароля N раз (как правило, N принимают равным от 3 до 5 раз).
В политике учетных записей помимо сотрудников ведется контроль доступа к ресурсам рабочих станций и серверов. Такая политика позволит, например, ограничить доступ к ресурсам в случае подмены сетевого адреса.
Отдельно могут быть введены дополнительные средства аутентификации пользователей. Использование сертификатов (цифровых удостоверений) с единым центом сертификации позволит многократно повысить стойкость системы безопасности. Использование двухфакторной аутентификации, в которой пользователь помимо данных учетной записи (имя пользователя, пароль) должен предоставить физический ключ доступа. Он позволит избежать компрометации учетной записи в случае успешной атаки подбора пароля. Физический ключ может быть заменен считывателем биометрических данных пользователя.
Еще одним способом, повышающим уровень безопасности ПЦ, является блокировка встроенных учетных записей администратора (root). В этом случае происходит делегирование прав администратора сети другому пользователю, так называемое переименование администратора. В этом случае, если пароль учетной записи «администратор» или «root» будут взломаны, администраторские права предоставлены не будут.
Одним из важных моментов при формировании политики безопасности является правило, обязывающее администратора ЛВС производить блокировку учетной записи пользователя в случае его болезни или увольнения. Также должны быть заблокированы гостевые учетные записи, присутствующие по умолчанию в операционных системах и СУБД.
Таким образом, пользовательский уровень безопасности вводит дополнительный барьер на пути несанкционированного доступа к ресурсам ПЦ и позволяет проводить разделение ресурсов на основе ролей, описанных в политике безопасности ПЦ.
Безопасность уровня приложенийОписанные меры безопасности позволяют усилить безопасность в сетевой инфраструктуре ПЦ. Но, как и на любом предприятии, в ПЦ существует прикладное программное обеспечение, на которое возлагается основная функциональная обязанность. Даже если будут приняты все меры по обеспечению безопасности сетевого и пользовательского уровня, брешь в системе безопасности уровня приложений позволит получить доступ к самой важной составляющей ПЦ — данным о платежных картах, к которым в итоге стремится потенциальный злоумышленник. Приведенный выше печальный пример бреши в системе безопасности уровня приложений с терминалами самообслуживания помог злоумышленнику получить данные по платежным картам, причем он не нарушил ни один из периметров защиты самого ПЦ.
Таким образом, безопасность уровня приложений можно оценить как один из самых важных пунктов в обеспечении сетевой безопасности ПЦ в целом.
Какие меры необходимо принять для снижения такого рода угрозы? На этот вопрос в первую очередь поможет ответить относительно недавно принятый стандарт в области защиты данных PA DSS[109]. Данный стандарт описывает предъявляемые требования к программному обеспечению, работающему с данными о платежных картах. После принятия данного стандарта каждый из поставщиков решения для работы с пластиковыми картами обязан будет иметь сертификат соответствия данному стандарту. Данный сертификат должен быть предъявлен в ходе проверки ПЦ на соответствие требованиям PCI DSS.
Одним из требований в стандарте является отсутствие данных о платежных картах в открытом виде. К таким данным относятся данные о номерах карт, о сроке их действия и CVC2/CVV2. Также запрещено хранение данных с магнитной полосы и ПИН-блока.
Помимо запрета на хранение данных безопасность уровня приложений обеспечивается регулярными критическими обновлениями операционных систем и СУБД. Такие обновления позволяют исправить найденные уязвимости в операционных системах и СУБД.
Также необходимо устанавливать обновления программного обеспечения на межсетевых экранах и маршрутизаторах. В случае наличия систем IPS/IDS необходимо проводить обновление сигнатур сетевых угроз.
К сожалению, не всегда то или иное обновление может быть безболезненно установлено. В практике любого ПЦ бывали случаи, когда обновление ПО на ключевых узлах приводило к частичной или полной его остановке. Для снижения вероятности такого рода чрезвычайных ситуаций используются тестовые среды, где каждое планируемое обновление должно проходить тщательную проверку и тестирование на совместимость с другими узлами процессинговой системы. Поскольку процессинговые комплексы представляют собой взаимосвязанную систему, тестирование очередного критического обновления на одном из комплексов может происходить длительное время, порой до нескольких недель или месяцев. В данный период, пока обновление находится в стадии тестирования, сотрудниками ПЦ должны быть приняты дополнительные меры по обеспечению безопасности. Например, если найдена уязвимость в интернет-браузере, используемом сотрудниками ПЦ, до момента установки вышедшего обновления сотрудникам отдела сетевой безопасности и администратору ЛВС необходимо принять меры для исключения использования данного рода уязвимости. Одним из вариантов решения может быть выделение специальной рабочей станции, с помощью которой будет осуществлен доступ в публичную сеть. Рабочая станция не должна быть подключена к общей локальной сети. На остальных рабочих местах использование браузера без установленного обновления необходимо запретить.
