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

САМОЕ СЛАБОЕ ЗВЕНО ЦЕПИ

Защита доступа — самое слабое звено этой цепочки, поскольку, в отличие от традиционной модели сети и аутентификации, облачные сервисы и консьюмеризация (использование ИТ-устройств как в личных целях, так и для рабочих задач) стирают границы между провайдерами удостоверений (Identity Provider) и провайдерами приложений (Application Provider). Например, всю аутентификационную информацию можно получить посредством облачных механизмов для аутентификации, а сведения о совокупности идентификационных данных (Identity Federation) — при помощи таких стандартных протоколов, как SAML или ADFS. Через облако открывается доступ к самым разнообразным приложениям, и в этом случае оно выполняет функции и провайдера удостоверений, и сервиспровайдера, который подтверждает информацию, поступившую от провайдера удостоверений, и предоставляет доступ к приложениям.

Таким образом, решение безопасности, где учтены эти аспекты, а основной акцент делается на обеспечении защищенного доступа к облаку, должно сочетать в себе функции управления идентификацией и доступом (Identity and Access Management, IAM) с традиционными системами аутентификации, но при этом оно должно учитывать контекст доступа и существование различных типов конечных устройств, быть гибким и адаптируемым. Кроме того, необходимо найти разумный компромисс при рассмотрении требований, исходящих от руководителя предприятия, специалистов по информационной безопасности, системных администраторов и конечных пользователей.

Для бизнес-подразделений ключевыми факторами являются размеры затрат и их быстрая окупаемость (Return on Investment, ROI). Все инвестиции в безопасность ИТ должны быть оправданны с точки зрения деловых процессов, а необходимость внедрения мощных и дорогостоящих средств аутентификации следует тщательно продумать и взвесить. Специалистам по информационной безопасности, в свою очередь, следует соотносить свои решения с поставленными задачами по обеспечению безопасности. Таким образом, выбранное решение должно предоставить возможность соблюдения высочайших стандартов безопасности и в то же время легко интегрироваться в существующую инфраструктуру.

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

Современные решения для управления идентификацией и доступом учитывают все эти требования. В них объединены уже проверенные продукты и технологии, обеспечивающие защищенный доступ к облаку с использованием сильной аутентификации. Ядро такого решения состоит из сервера аутентификации (см. Рисунок 1), VPN с шифрованием SSL и консоли управления. Главным координационным центром является сервер аутентификации, который обеспечивает защищенный удаленный доступ к критически важным данным и приложениям в сети. Использование нескольких серверов, к примеру RADIUS, позволяет внедрить различные методы аутентификации, в частности использование простого пароля, а также двух- и трехфакторную аутентификацию. Благодаря этому можно воплотить в жизнь гибкие концепции безопасности для различных групп пользователей и приложений.

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

 

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

Если сервер аутентификации интегрирован в систему управления, то тем самым обеспечивается простота его настройки и администрирования, а также прозрачная интеграция в существующие базы данных, такие как Active Directory компании Microsoft, eDirectory от Novell, OpenLDAP и другие системы. В случае увольнения сотрудника или при необходимости ограничения срока действия определенных профилей можно легко и быстро внести изменения через стандартную систему администрирования пользователей. Когда кто-либо хочет авторизоваться в облачном приложении, сервис-провайдер направляет внутрикорпоративному серверу аутентификации в соответствующем пользовательском домене запрос SAML или ADFS (см. Рисунок 2). Этот сервер, выступающий в качестве провайдера удостоверений, сверяет полученные данные с сохраненным профилем и запрашивает аутентификацию через мобильное устройство пользователя. Лишь после успешной аутентификации сервер аутентификации отсылает сервис-провайдеру через SAML или ADFS разрешение на доступ.

Рисунок 2. При аутентификации коммуникация между пользовательским доменом и доменом сервис-провайдера осуществляется через SAML.
Рисунок 2. При аутентификации коммуникация между пользовательским доменом и доменом сервис-провайдера осуществляется через SAML.

 

Облако облаку рознь

Алексей Сабанов, заместитель генерального директора компании «Аладдин Р.Д.»Безопасность при переходе к облачным вычислениям — это не только модная тема обсуждений, в ряде случаев дискуссии перетекают в практическую плоскость. При этом одной из самых сложных задач является организация защищенного доступа к облачным сервисам.

В статье рассматривается частная (и пока мало актуальная для российской действительности) ситуация: трансляция доверия, причем в самом простом случае перехода к облачным вычислениям — при построении частного (корпоративного) облака. Как показано в статье А. П. Баранова «Можно ли защитить в «облаке» конфиденциальную информацию?» (Журнал «Системы высокой доступности» № 2, 2012 год), эти задачи могут быть решены с помощью традиционных средств защиты информации.

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

Identity Provider — центр регистрации пользователей, связанный с удостоверяющим центром трастовыми (доверенными) отношениями; в простейшем случае это администратор, у которого есть право заведения и аннулирования учетных записей пользователей. Основная задача центра регистрации — связать идентификационную и, главное, аутентификационную информацию с конкретным пользователем и сделать соответствующую запись в базе данных (Access List). Обычно для этого применяется электронное удостоверение (чаще всего сертификат Х.509 открытого ключа), в простейшем случае — логин/пароль пользователя. Прибегать к помощи сертификата Х.509 намного безопаснее и удобнее: в этом случае аутентификатором является закрытый ключ пользователя, который в отличие от пароля (в лучшем случае — хеша пароля) не записывается в базу данных и всегда находится на защищенном чипе смарт-карты; удобство управления доступом объясняется быстрым и безошибочным выполнением основных операций по приостановке или отзыву сертификата, что автоматически прекращает доступ к системе его владельца. На корпоративном уровне самую сложную часть по идентификации пользователя (проверка паспортных данных, трудовой книжки, ИНН, СНИЛС, дипломов об образовании и т. д.) выполняет кадровая служба, которая передает информацию о правах пользователя на доступ в службу ИТ.

Identity Federation (IF) — средство привязки к пользователю электронных идентификаторов и атрибутов, совместимых с разными системами аутентификации. Назначение IF — трансляция доверия в отношении прав доступа пользователя из одной прикладной системы в другую. Основными инструментами IF являются упомянутые протоколы SAML (Security Assertion Markup Language — защищенный протокол обмена XML сообщениями) и ADFS (Active Directory Federation Services — службы, встроенные, например, в службу каталога Microsoft Windows Server 2008), в которых наиболее полно реализованы интерфейсы поддержки передачи учетных записей пары логин/пароль.

Нетрудно доказать, что способ организации трансляции доверия для учетных записей класса логин/пароль применим только для частного и, с некоторыми ограничениями, для гибридного облаков. Для публичного облака защищенный доступ к облачным сервисам безопасно может быть построен только при использовании двухсторонней строгой аутентификации с использованием квалифицированных сертификатов формата Х.509. При этом система трансляции доверия для публичных облаков, как правило, основывается на мандатном доступе с введением уровней доверия к аутентификации. На низшем уровне доверия в качестве аутентификатора используется пароль, на высшем — закрытый ключ квалифицированного сертификата, сгенерированный внутри микропроцессорного чипа смарт-карты.

Алексей Сабанов — заместитель генерального директора компании «Аладдин Р.Д.».

 

КОМБИНИРОВАНИЕ МЕТОДОВ АУТЕНТИФИКАЦИИ

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

При доступе к внутренней сети предприятия или внутреннему облаку, размещенному у провайдера, сервер аутентификации тоже занимает центральное положение. Как и при доступе к приложениям во внешних облаках, он проверяет идентификационную информацию, устанавливает соответствующий метод аутентификации и предоставляет пользователю возможность работать с корпоративными приложениями через SSL-VPN, причем из любого места и с любого устройства, способного подключиться к Интернету. Благодаря однократной регистрации (Single Sign-on, SSO) процедуру аутентификации достаточно выполнить один раз. VPN доступна через стандартный браузер Web, так что нет необходимости устанавливать специализированное клиентское ПО на конечные устройства.

Торстен Юнглинг — менеджер по региону DACH (Германия, Австрия, Швейцария) в компании Stonesoft.