Безопасность данных в облачных сервисах

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

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

Управление данными

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

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

± Фирма, предоставляющая вам облачные сервисы, объявляется банкротом, ее имущество (в том числе серверы) конфискуется, и провайдер перестает предоставлять услуги.

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

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

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

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

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

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

Рассмотрим применение перечисленных мер для всех возможных сценариев развития событий.

Что происходит в случае остановки деятельности облачного провайдера

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

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

Что происходит, когда судебная повестка вынуждает вашего облачного провайдера раскрыть ваши данные

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

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

те быть уверены даже в том, что вы вообще узнаете о том, что повестка была выпущена.

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

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

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

ПРИМЕЧАНИЕ

Компания Amazon не раскрывает информации о том, где физически располагаются их центры обработки данных; они просто декларируют, что каждый из центров размещается в ничем не примечательном здании с охраной периметра по типу армейской. Даже если вы узнаете, что мой сервер базы данных находится в зоне доступности us-east-1a, вы все равно не узнаете, ни где располагаются центры обработки данных, формирующие эту зону, ни даже какую из трех зон доступности на восточном побережье США представляет зона доступности us-east-1a.

Amazon публикует свои стандарты безопасности и процедуры по ее обеспечению по следующему адресу: http://aws.amazon.com. Услугами какого бы облачного провайдера вы ни пользовались, вы должны понимать, каким стандартам безопасности они следуют, и ожидать, что они даже превышают все ваши требования.

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

Источник: Риз Дж., Облачные вычисления: Пер. с англ. — СПб.: БХВ-Петербург, 2011. — 288 с.: ил.

Вы можете следить за любыми ответами на эту запись через RSS 2.0 ленту. Вы можете промотать до конца и оставить ответ. Pinging в настоящее время не допускается.

Оставьте отзыв

XHTML: Вы можете использовать следующие теги: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>

 
Rambler's Top100