Rambler's Top100
Статьи ИКС № 09 2012
Александр САНИН  18 сентября 2012

Приглашение к ревизии

С точки зрения ИТ-процессов тенденция перехода в облака оправдана и понятна, однако в ракурсе информационной безопасности далеко не все так однозначно. Облачные вычисления ведут к пересмотру привычных для нее понятий и представлений о процессах.

Александр САНИН, коммерческий директор AvanpostЧто осталось на корабле современности

Очень важное обстоятельство, которое до сих пор мешает большинству специалистов по информационной безопасности принять облака как данность, как что-то потенциально хорошее и нужное, – изменение понятия «периметр защиты». Именно периметр защиты традиционно считался базовым понятием с четким определением, и именно отталкиваясь от него большинство компаний выстраивали свои системы защиты информации. В облаках же классическое определение неприменимо: периметр защиты размыт и, что еще более важно, он контролируем лишь частично. Это сразу вызывает настороженность у специалистов по инфобезопасности. Но, несомненно, со временем придется пересматривать сложившиеся взгляды, включая даже такие привычные термины. К слову, в новой парадигме физические границы периметра все же поддаются описанию, ведь у каждого облака есть свой «облачный периметр» – он начинается в той точке, где в ЦОД приходит кабель интернет-провайдера.

Понятие «информационная безопасность» подразумевает множество процессов. Если же говорить только о технической составляющей – средствах и системах, которые обеспечивают безопасность в ИТ-среде, – то для любой среднестатистической службы информационной безопасности основные процессы – это управление доступом, антивирусная и антиспам-защита, защита от внешних угроз и вторжений, межсетевое экранирование и резервирование. Можно перечислить еще ряд элементов, но эти шесть ключевых процессов применимы абсолютно во всех организациях, и переход в облако должен в первую очередь обеспечить специалисту по инфобезопасности их приемлемый уровень. Облако должно иметь технические компоненты защиты от вирусов, троянов и прочих подобных угроз; оно должно быть надежно защищено от внешних атак, таких как DDoS; должно иметь средства межсетевой защиты и средства резервирования и восстановления после аварий. И мы видим, что все эти процессы в современных облаках уже давно перестали быть чем-то новым, все перечисленные системы существуют и успешно функционируют, и заказчику при выборе того или иного облачного сервиса наверняка предложат подписать соответствующий SLA, где будут указаны подробности о каждом из компонентов. Но что современное облако может предложить нам с точки зрения управления доступом? Тут мы видим некоторый вакуум…

Доступ насущный

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

Между тем любой современный и эффективный процесс управления доступом неразрывно связан с решениями IDM (Identity Management). Именно IDM-решения в настоящее время способны автоматизировать большую часть ручной работы в рамках управления доступом. Любое такое решение за счет интеграции с кадровой базой данных организации делает процедуру согласования и предоставления доступа тому или иному лицу полностью автоматизированной и прозрачной. Более того, по результатам тестов, проведенных компанией Avanpost, процесс предоставления доступа ускоряется на порядок, т. е. время предоставления доступа, а также время отзыва прав доступа сокращается минимум в 10–15 раз. Как же процесс управления доступом должен видоизмениться с учетом текущих тенденций «облачности»?

Управление доступом ...aaS

В принципе даже классическое представление процесса управления доступом отчасти вписывается в облачную модель. Например, при использовании IaaS (Infrastructure as a Service) заказчик может, как и раньше, самостоятельно контролировать и предоставлять доступ даже в облачной среде, с одной лишь оговоркой: он не может достоверно сказать, что список лиц, которым предоставлен доступ, – это окончательный вариант, поскольку существует еще обслуживающий персонал самого облака (тут уже вопрос доверия к провайдеру и тоже, к слову, переосмысления основных понятий ИБ), могут появиться внутренние нарушители
и т.п. В целом же процессом управления доступом полностью распоряжается заказчик. Варианты появляются в других моделях. В модели PaaS (Platform as a Service) или SaaS (Software as a Service) говорить о классической схеме уже не приходится. Чтобы автоматизировать управление доступом в облачном сервисе, построенном по такому принципу, нужно искать новые подходы.

Один из новых вариантов – автоматизация процесса управления доступом таким образом, чтобы его можно было предоставлять пользователям тоже в виде сервиса, эдакого IDMaaS. При этом подходе пользователь фактически будет иметь доступ к IDM-решению, которое, в свою очередь, будет настроено на управление доступом ко всем нужным ему бизнес-приложениям, и платить за такой сервис нужно будет по принципу модели SaaS. Технологически такой сервис уже сегодня вполне можно запустить, вопрос лишь в согласовании с провайдерами облаков. Более того, технологически можно добиться интеграции сервиса с облаком до такой степени, чтобы пользователь мог управлять доступом даже к тем бизнес-приложениям, которые находятся вне этого облака (например, у него в офисе или даже в другом облаке).
Заметили неточность или опечатку в тексте? Выделите её мышкой и нажмите: Ctrl + Enter. Спасибо!