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

Итак, миф о том, что облака существуют, успешно развиваются и все шире применяются для решения бизнес задач — оказался реальностью.

Есть целый ряд аргументов, на которых строится сегодня критика применения облачных технологий в тех или иных случаях, и по сути единственный аргумент «за» - экономический. Реальность такова, что этот довод — самый весомый, и доказывать надо обоснованность не перехода на облако. Применение технологий, альтернативных облачным, считается обоснованным случаях если:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Потребитель — тот, кто имеет юридические и экономические отношения с облаком.

Пользователь — тот, кто непосредственно получает сервисы и использует их.

Устройство — конкретный набор технических средств доступа и возможно защиты информации применяемый для получения сервисов.

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

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

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

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

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

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

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

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

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

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

Автор: Бабанин А. В.

Дата публикации: 01.01.2013

Библиографическая ссылка: Бабанин А. В. Безопасность в облаке: мифы и реальность; обеспечение безопасности и безопасность как сервис // Information Security/Информационная безопасность. М., 2013. № 1. С. 34–35.

---