Оглавление
Хороший продукт – это всегда плод совместных усилий производителя и пользователей. Чтобы продукт был успешным и востребованным, им должны пользоваться, давать обратную связь, и производитель должен реагировать на нее. Только тогда он станет по-настоящему полезным, конкурентоспособным, будет расти и развиваться.
Авторы:
Василий Окулесский, вице-президент по информационной безопасности ЦМРБанка
Андрей Акинин, генеральный директор Web Control
В случае с системами привилегированного доступа возникает два вопроса: кто является основным бенефициаром решения и для чего оно используется в первую очередь.
Часто инструмент безопасности применяется не так, как его видит разработчик. В ходе эксплуатации складывается компромисс между тем, как он задумывался, и тем, как его используют на практике.
Например, DLP-система редко применяется для предотвращения утечек, а самым необычным, пожалуй, сценарием ее использования можно считать построение социальных схем и групп делового общения.
Компания Web Control при создании и развитии PAM-системы sPACE следовала запросам клиентов и отзывам потребителей. Это концептуально перевело продукт из ИБ-инструментов в ИТ-инструмент и позволило формализовать повседневные действия ИТ-персонала, что, по отзывам клиентов, стало дополнительным бонусом от внедрения sPACE PAM.
Что хочет ИБ, когда говорит о контроле пользователей?
PAM-системы лежат на стыке ИБ и ИТ: они обеспечивают централизованный безопасный доступ к ресурсам для ИТ и контроль пользователей для ИБ, но что именно нужно ИБ от такого контроля? С точки зрения информационной безопасности, системы управления привилегированным доступом – это прежде всего контроль администраторов. Что значит контроль администраторов? Это решение трех задач.
Во-первых, безопасники хотят быть уверены, что не произошло подмены пользователей. Пока ИТ-ресурсы функционируют в штатном режиме, потребности в контролирующей системе нет. Но если возникает проблема, то нужен инструмент, который позволит провести расследование и понять, что произошло. Часто этого сделать нельзя, поскольку администратор использует общую учетную запись или авторизовался под именем другого пользователя.
Для минимизации угрозы подмены пользователей PAM разделяет персональную учетную запись пользователя и привилегированную. Для персональной нужна система строгой аутентификации, в то время как привилегированная учетная запись администраторам неизвестна, PAM ее использует при запуске сеанса доступа. В таком случае доступ к системам в обход PAM невозможен, что исключает несанкционированный привилегированный доступ. Разделение учетных записей должно решить еще одну вспомогательную задачу контроля – сделать невозможным или крайне затруднительным непосредственный доступ к базам данных или информационным системам.
Во-вторых, безопасники хотят знать, что администраторы делают, и быть уверенными, что последние не выполняют запрещенных действий. Привилегированные пользователи обладают большими правами, соответственно, их действия могут оказать существенное негативное влияние на работу баз данных, серверов, всей ИТ-инфраструктуры в целом.
В компании работают привилегированные пользователи с разным уровнем доверия. Некоторые администраторы добавляют и редактируют пользователей в системе, другие действуют по строго определенным сценариям работы, есть администраторы с более широкими привилегиями и высоким уровнем квалификации. PAM-система должна учитывать уровень доверия к привилегированному пользователю и наделять его правами в соответствии с этим уровнем. У обычного администратора не должно быть прав на исполнение потенциально деструктивной команды, например «format c:», и все действия должны фиксироваться для последующего расследования инцидентов.
В идеале у пользователя должна быть возможность действовать только правильным образом, и полагаться только на интуицию здесь опасно. Если использовать аналогию, то дорожное движение осуществляется по проложенным дорогам, четко регламентируется правилами и контролируется камерами на каждом перекрестке. На любом участке дороги водитель знает, куда он может свернуть, разрешено ли ему двигаться и с какой скоростью. А в особо опасных местах, например, на автомагистралях, у него нет самой физической возможности выехать на встречную полосу благодаря ограничителям. Даже знание о том, что действия фиксируются, сильно дисциплинирует.
Принцип «запрещено все, что не разрешено» решает, как минимум, две дополнительные задачи.
Конечное число разрешенных процессов повышает уровень понимания ИТ-задач офицерами ИБ.
Действия ИТ-администраторов в чрезвычайных случаях становятся более предсказуемыми.
Правда, полноценное их решение возможно только при полном понимании со стороны ИТ и ИБ того, что их цель – защита интересов компании, а не решение своих собственных местечковых задач.
В-третьих, подразделение ИБ должно контролировать назначение и изменение прав привилегированных пользователей. Для того чтобы это сделать, необходима достаточно детализированная карта технологических процессов обслуживания ИТ. Она позволяет четко определять ролевые модели доступа: системы, к которым человек должен иметь доступ, уровень доступа, способ получения доступа и, возможно, перечень запрещенных команд при реализации конкретной задачи. Наличие необходимого и достаточного набора ролевых моделей – залог успеха внедрения PAM. Создание такого набора требует глубокого понимания ИТ-процессов и вовлечения и ИБ-, и ИТ-специалистов.
Процессы могут меняться, и здесь на помощь приходит вендор или интегратор, если PAM-система позволяет адаптировать сценарии самостоятельно. При этом мы всегда должны помнить, что представители вендора или интегратора – не только наши друзья и помощники, но в первую очередь – это группа пользователей наибольшего риска, и их действия должны находиться под очень жестким контролем. Внедрение РАМ должно решить и эту дополнительную задачу. Вендоры и интеграторы являются первыми в очереди на контроль, возможно, даже более приоритетными, чем ИТ-администраторы. Многие аспекты контроля пользователей вызывают стандартную конфликтную ситуацию ИТ и ИБ: все, что безопасно, по мнению ИТ, неудобно. Ключ в общем доступе и отсутствие камер наблюдения – это удобно и недорого. Однако, если произошел инцидент, то как администратору доказать свою непричастность? И запись действий, а тем более персональные ключи, здесь могут помочь. Всегда полезно вспомнить, что ИТ и ИБ решают свои задачи не для себя, а для защиты интересов компании в целом. Такое понимание общности целей – необходимое условие успешного внедрения как РАМ, так и любых средств защиты, но РАМ это демонстрирует наиболее выпукло.
Таким образом, PAM – это не система для ИБ, а система для повышения безопасности администраторов, которые на самом деле и являются основными пользователями и бенефициарами внедрения PAM. Поэтому при внедрении PAM нужно думать прежде всего о них.
Формализация повседневных действий ИТ-персонала и создание сценариев их работы
При внедрении РАМ как инструмента ИТ можно использовать опыт построения систем инцидент-менеджмента, в которых родство ИТ и ИБ наиболее проявляются. Так, при создании системы реагирования, каждому инциденту назначается свой playbook с прописанными действиями, что позволяет стандартизировать процесс.
Подобную практику можно использовать и при внедрении PAM, тогда значительно упрощается его внедрение. А побочным результатом внедрения PAM станет разработка стандартных регламентов, создание сценариев работы ИТ-персонала, подготовка протестированных скриптов и программ, которые можно использовать в нужный момент. ИТ-службы попутно получают следующие преимущества:
работа администратора становится прозрачной и понятной, в то же время хорошо документированной, что позволяет проводить расследования, поиск ошибок и исправление как сценариев, так и систем;
снижается трудоемкость рутинных операций, причем чем больше систем находится под управлением, тем заметнее и ощутимее эффект снижения трудоемкости;
при грамотно описанных сценариях снижаются требования к персоналу, и уже начинающие администраторы могут выполнять работу под контролем – это позволяет снизить затраты на персонал и облегчает поиск специалистов.
Как результат, мы получаем оптимизацию деятельности ИТ—служб и, определенно, экономический эффект, а также повышаем уровень ИТ—зрелости компании.
Как выбрать PAM-систему?
Хороший PAM-инструмент получится только тогда, когда вендор и пользователи объединяют свои знания, опыт, готовы ими делиться, нацелены на один результат, налажен канал взаимодействия и механизм учета обратной связи, а система является условно открытой. Чтобы система стала рабочей, она должна работать, набивать шишки, смотреть под ноги, искать либо более безопасные маршруты, либо повышать «проходимость».
Совершенно очевидно, что как бы ни был хорош вендор, пока пользователь не набьет определенную массу шишек, не «наедет» из-за них на производителя, пока они вместе не найдут середину у «безопасно-удобно», решение не будет развиваться и совершенствоваться. Поэтому система должна быть условно открыта, чтобы ее можно было модифицировать при получении обратной связи от заказчика. Если добавилось новое оборудование или появилось новое ПО, к которому нет стандартного коннектора, то должна быть возможность организовать доступ через PAM хотя бы в режиме прохода.
Функциональность должна быть такой, чтобы не возникало потребности обходить систему или внедрять PAM частично для доступа только к критическим ресурсам. Учитывая степень связности ИТ-систем в компании, предоставление доступа к новой системе, интегрированной с защищенными старым системами, – это нарушение ИБ. Классический пример – атака через цепочку поставщиков.
Еще раз необходимо подчеркнуть, что современный PAM – это не столько инструмент безопасности, сколько ИТ-инструмент, который должен непрерывно развиваться не только эволюционно, но и, если это необходимо, революционно, следуя актуальным потребностям отрасли.
sPACE PAM следует именно этим принципам. Для этого должна выстраиваться система постоянного взаимодействия, эффективная обратная связь между разработчиками и потребителями. Разработка от интересов заказчика есть выражение клиентоориентированного подхода.
Хороший PAM – это PAM, которым пользуются.
ITSec_articles