Безопасность в облаке: мифы и реальностьОбеспечение безопасности и безопасность как сервис

Алексей Бабанин
Заместитель директора ФГУП ВНИИПВТИ

Применение технологий, альтернативных облачным, считается обоснованным в случаях, если:

1. отсутствует реальная потребность в снижении сложности управления IT-инфраструктурой;
2. отсутствует необходимость повышения эффективности загрузки оборудования;
3. нет задачи предоставления типовых IT-услуг в массовом объеме на постоянной основе.

Для обоснованности необлачных вариантов развития достаточно одного из перечисленных факторов.

Резонно было бы удивиться тому, что среди перечисленных выше нет основания, связанного с информационной безопасностью. Проведем аналогии с другими отраслями деятельности.

Что означает"доверие"?

Никого не удивляет развитие международного туризма, когда с использованием инструмента платежной системы (например, виртуальной банковской карты), покупая набор бумажек на одном конце планеты, человек получает набор услуг в заданное время в конкретном месте, о котором за несколько дней до этого знал в лучшем случае "от Сенкевича".

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

Разберемся, что означает доверие в данном контексте. Чему именно может доверять потребитель. Очевидно, что в реальности он доверяет исключительно своему бытовому опыту - покупка массово и долговременно предоставляемых пакетов услуг статистически безопасна.

Отель из всемирно известной сети вполне может не соответствовать в точности количеству звезд или ожидаемому уровню сервиса, однако крайне маловероятно, что условия будут разочаровывающе неприемлемыми. Авиакатастрофы случаются, но пассажиропоток растет.

В контексте облачных технологий этот вывод можно интерпретировать следующим образом: представление клиента о безопасности применения облачных технологий целиком и полностью базируется на экономическом эффекте от их применения. Клиент не ожидает, что он будет надежно аутентифицирован, а его волеизъявление, на основании которого будет произведена та или иная операция, будет подлинным и целостным. Это миф. Он ожидает, что использовать облако - выгодно. А если может быть и невыгодно, то это и значит "небезопасно". Это реальность.

Эффект будет состоять в основном в резком уменьшении затрат на приобретение услуги, применяемой клиентом в дальнейшем для решения своих частных задач.

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

Безопасность с точки зрения облака

Перейдем теперь "на другую сторону прилавка" и проанализируем, как следует понимать рассмотренную выше безопасность с точки зрения облака.

Трансформируя ожидания клиента в задачи IT-инфраструктуры облака, мы получим безусловную необходимость решения следующих задач:

1. предоставление сервисов по требованию потребителя;
2. обеспечение "неисчерпаемости" сервисной мощности для типового потребителя;
3. соответствие качества предоставляемых сервисов задаче потребителя;
4. наличие развитой схемы тарификации и финансовых отношений в расчетах за предоставление сервисов;
5. предоставление сервисов через существующие и развивающиеся сети;
6. предоставление сервисов через стандартные, широко распространенные интерфейсные решения, имеющиеся у потребителя.

Теперь, когда задачи безопасности сформулированы как задачи облака, можно по отдельности рассмотреть каждую из них уже сточки зрения информационной безопасности в привычном специалистам ракурсе.

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

Решение задач 1-6 для облачной инфраструктуры осуществляется путем выполнения следующих условий:

1. Безопасный для потребителя сервис предоставляется безопасному для облака потребителю по безопасному каналу.
2. Процесс создания и предоставления сервиса позволяет за заданное время создать и утилизировать (освободить занятые ресурсы и уничтожить данные, не подлежащие дальнейшему использованию) сервис с гарантированным уровнем безопасности.
3. Расчетно-платежный механизм, используемый облаком, должен соответствовать требованиям платежных систем, в том числе и в части авторизации клиента, и позволять осуществлять учет предоставления сервисов в режиме реального времени.
4. Процесс предоставления сервиса инициируется через незащищенный недоверенный канал и включает в себя механизм проверки доверенности получателя. Получатель, в свою очередь, не обязан предпринимать каких-либо специальных действий для проверки безопасности предоставляемого сервиса.

Таким образом, мы фактически сформулировали набор требований к комплексу услуг, который облако должно предоставить потребителю для того, чтобы обеспечить выполнение его ожиданий в части безопасности.

Этот комплекс услуг и называется облачным сервисом безопасности.

Еще немного о мифах

Недопустимо верить в то, что безопасность информации можно обеспечить, защищая ее только на стороне облака. Следует отчетливо понимать, что облачный сервис безопасности должен обеспечивать безопасность информации и на стороне потребителя, причем вне зависимости от состояния абонентского оборудования. Работает оно или нет, надежна ли сеть, через которую осуществляется подключение. Очевидно, что при этом необходимо учитывать особенности абонентских устройств и естественным образом мы приходим к необходимости получения сведений о действующей совокупности "потребитель + пользователь + устройство".

Устройства, прежде чем они начнут использоваться для получения сервисов, регистрируются облаком как ассоциированные с конкретным пользователем.

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

Сервис безопасности выбирает схему взаимодействия, исходя из возможностей устройства и предопределенных заранее возможности и способах организации доверенного соединения. Определяются уровень надежности защиты, доверия к устройству, его управляемость, возможности по защите данных на нем.

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

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

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

Естественно ожидать, что в предоставлении части сервисов для некоторых устройств может быть отказано.

Отказ может последовать и в случае совокупности нетехнических факторов. Например, нахождение абонентского устройства за пределами корпоративной беспроводной или проводной сети. А может и не последовать, если устройство при этом поддерживает работу в доверенном сеансе связи с необходимыми характеристиками.

Это - реальность.