Как построить доверенное облако: вопросы, которые помогут найти ответ

Во-первых, полезно сомневаться, этому каждого из нас учат со студенческой скамьи, а общество в целом – с античности. Правда, для того чтобы позволить себе сомневаться, требуется известная смелость – человек нерешительный не соберется с духом усомниться, ведь это может привести к тому, что придется начинать все с начала. Чтобы не начинать все с начала тогда, когда уже потрачены силы и деньги, задавать себе вопросы "что я хочу сделать и почему именно это?" стоит как можно раньше.

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

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

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

Но они в первую очередь инструмент.

А само по себе использование инструмента не может быть достаточной причиной его использования¹. О каком бы инструменте ни шла речь.

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

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

Если же технология виртуализации уже внедрена в вашу информационную систему, вы используете множество серверов, но все они, работая разрозненно, все-таки не обеспечивают достаточной эффективности системы, то вашим решением может стать построение центра обработки данных (ЦОД). Это позволит наиболее эффективно и управлять полученной инфраструктурой, и обеспечивать серверы энергией. Как и прежде, для каждого пользователя выделяется виртуальная машина с необходимым объемом ресурсов, который, как и остальные параметры ВМ, определяется при ее создании.

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

Облака – наиболее мощный инструмент, а это значит, что из него не надо стрелять по воробьям. Экономически не оправданно, в первую очередь. А потому применяться облачные технологии должны лишь тогда, когда возможности ЦОДов и виртуализации уже исчерпаны [1].

И только теперь, если это действительно ваш случай, наступает время поиска ответа на вопрос: "Как построить доверенное облако?"

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

И для начала определим, что именно будем понимать под "доверенным облаком".

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

А потому облако – это совокупность ЦОДов, взаимодействующих между собой, клиентских рабочих мест и средств доступа, а также собственных инструментов облака (назовем их планировщиком).

Каким же должно быть облако, чтобы его можно было назвать "доверенным"? Можем ли мы доверять облаку в целом, если не доверяем тем серверам, виртуальным и клиентским машинам, каналу связи между ними, которые его составляют?

Вообще об обеспечении доверенной загрузки различных машин уже сказано так много, что выполнение данного требования стало хрестоматийной истиной [например, 2. С. 717– 723]. Совершенно не важно, какие именно действия мы выполняем и как пытаемся защититься от злоумышленников, если это происходит не в доверенной среде. В этом случае все наши усилия будут напрасны.

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

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

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

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

Во-вторых, должна обеспечиваться доверенная загрузка виртуальных машин [см., например, 4].

Причина все та же – обеспечение доверенной среды. Это особенно важно, ведь именно внутри ВМ происходит обработка информации. Той самой, ради защиты которой и предъявляется к облаку требование быть "доверенным".

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

В гостевых ОС, конечно, также должны быть установлены средства разграничения доступа, защиты от ВВК и так далее, однако вопрос оснащения ВМ (в отличие от вопроса обеспечения их корректного старта) выходит за рамки задачи построения доверенного облака, так как в общем случае облако должно предполагать возможность администрирования безопасности своих ВМ силами АИБов системы пользователя, а не управляющим персоналом облака, если предполагать, что доверенное облако может быть не только частным, но и, например, государственным.

В-третьих, должны быть защищены и клиентские машины.

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

В зависимости от ответов может быть выбрана опять же доверенная загрузка клиентских машин или создание доверенного сеанса связи, выбран подход с использованием "тонкого" или "толстого" клиента, выбраны дополнительные средства защиты. Так, если планируется на клиентском СВТ подписывать документ, обрабатываемый в облаке, ЭП – очевидно, что потребуется средство обеспечения доверенного сеанса связи с функциями "библиотеки ЭП" или "толстый клиент" с правильно реализованным СЭП [см., например, 5, 6].

Конечно, в случае несовпадения владельца облака и владельца системы требование контролировать клиентские СВТ звучит совершенно утопично: как можно контролировать то, что тебе не принадлежит?! Казалось бы. На самом деле, конечно, способы есть [например, 7]. Если нет возможности добиться использования только доверенных клиентских машин, то разграничить полномочия пользователей, подключающихся из доверенной и из недоверенной среды, вполне возможно. Нужно только своевременно задать себе правильный вопрос.

В-четвертых, должно создаваться безопасное соединение между клиентской машиной и ЦОДом. Без этого ни пользователь не может быть уверен, что работает с нужной ему доверенной виртуальной машиной и никто не "слушает" и не искажает трафик, ни владелец облака не может быть уверен в том, что подключился легальный клиент с легального СВТ и что даже если подключился именно он, в облако, пользуясь случаем, не передается что-то лишнее.

Доверенным облако можно считать только в том случае, если обеспечена доверенная загрузка каждого из серверов ЦОДов, доверенная загрузка виртуальных машин и клиентских машин пользователя, защищен доступ пользователей к их ВМ.

Достаточно ли выполнения этих требований?

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

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

А для этого – задавать самим себе дополнительные и наводящие вопросы. Ведь без вопроса нельзя найти ответ.

В заключение – вопрос от преподавателя: "Какой вопрос, ответ на который необходим для создания доверенного облака, мы специально пропустили?"

Литература

1. Конявский В.А. Облако ЦОДов, или Сон разума // Защита информации. INSIDE. – 2013. – № 5. – С. 36–37.
2. Конявский В.А., Лопаткин С.В. Компьютерная преступность. – Т. II. – 2008. – 840 с.
3. Чепанова Е.Г., Лыдин С.С. Облако ЦОДов, или Сон разума. Сравнительный анализ решений для обеспечения доверенной загрузки ОС, представленных на рынке // Защита информации. Инсайд.– 2014. – № 3. – С. 56–68.
4. Лыдин С.С., Конявская С.В. Облако ЦОДов, или сон разума: доверенная загрузка системы виртуализации // Защита информации. INSIDE. – 2014. – № 6. – С. 68–77.
5. Акаткин Ю.М. Как защитить электронную подпись // Национальный Банковский Журнал. – 2013. – № 8. – С. 111.
6. Конявская С.В. Применение защищенных микрокомпьютеров МКТ-card long в системах удаленного доступа смешанного типа // Вопросы защиты информации: Научно-практический журнал/ФГУП "ВИМИ". М., 2016г. – Вып. 3. – № 114. – C. 23–30.
7. Бабанин А.В. Безопасность в облаке: мифы и реальность; обеспечение безопасности и безопасность как сервис // Information Security/Информационная безопасность. – 2013. – № 1. – С. 34–35.