реферат. 1. История и ключевые факторы развития Определение облачных вычислений
 Скачать 69.47 Kb.
|
|
§ SaaS - приложение, используемое Потребителем посредством обращения к облаку из специальных программ. § PaaS - контейнеры для приложений Потребителя, средства разработки и администрирования. § IaaS - вычислительные мощности, базы данных, фундаментальные ресурсы, поверх которых Потребитель развёртывает свою инфраструктуру. o Уровень абстракции и контроля ресурсов § Управление гипервизором и виртуальными компонентами, необходимыми для реализации инфраструктуры. o Уровень физических ресурсов § Компьютерное оборудование § Инженерная инфраструктура • Безопасность o Аутентификация и авторизация o Доступность o Конфиденциальность o Идентефикация o Мониторинг безопасности и обработка инцидентов o Политики безопасности • Приватность o Защита обработки, хранения и передачи персональных данных. Облачный Аудитор - участник, который может выполняет независимую оценку облачных услуг, обслуживания информационных систем, производительности и безопасности реализации облака. • Может давать собственную оценку безопасности, приватности, производительности и прочего в соответствии с утвержденными документами. Облачный Брокер - сущность, управляющая использованием, производительностью и предоставлением облачных услуг, а также устанавливающая отношения между Провайдерами и Потребителями. • С развитием облачных вычислений, интеграция облачных сервисов может оказаться слишком сложной для Потребителя. o Сервисное посредничество - расширение заданного сервиса и предоставление новых возможностей o Агрегирование - объединение различных сервисов для предоставление Потребителю Облачный Оператор Связи - посредник, предоставляющий услуги подключения и транспорт (услуги связи) доставки облачных услуг от Провайдеров к Потребителям. • Предоставляет доступ через устройства связи • Обеспечивает уровень соединения, согласно SLA. Среди представленных пяти акторов, облачный брокер - опционален, т.к. облачные потребители могут получать услуги напрямую от облачного провайдера. Ввод акторов обусловлен необходимостью проработки взаимоотношений между субъектами. 4. Соглашение об уровне сервиса Соглашение об уровне сервиса - документ, описывающий уровень оказания услуг, ожидаемый клиентом от поставщика, основанный на показателях, применимых к данному сервису, и устанавливающий ответственность поставщика, если согласованные показатели не достигаются. Вот некоторые показатели, в том или ином составе встречающиеся в операторских документах: ASR (Answer Seizure Ratio) -параметр, определяющий качество телефонного соединения в заданном направлении. ASR рассчитывается как процентное отношение числа установленных в результате вызовов телефонных соединений к общему количеству совершенных вызовов в заданном направлении. PDD (Post Dial Delay) -параметр, определяющий период времени (в секундах), прошедший с момента вызова до момента установления телефонного соединения. Коэффициент доступности Услуги - отношение времени перерыва в предоставлении услуг к общему времени, когда услуга должна предоставляться. Коэффициент потери пакетов информации - отношение правильно принятых пакетов данных к общему количеству пакетов, которые были переданы по сети за определенный промежуток времени. Временные задержки при передаче пакетов информации - промежуток времени, необходимого для передачи пакета информации между двумя сетевыми устройствами. Достоверность передачи информации - отношение количества ошибочно переданных пакетов данных к общему числу переданных пакетов данных. Периоды проведения работ, время оповещения абонентов и времявосстановления сервисов. Иными словами, доступность услуги 99,99% говорит о том, что оператор гарантирует не более 4,3 минут простоя связи в месяц, 99,9% - что услуга может не оказываться 43,2 минуты, а 99% - что перерыв может длиться более 7 часов. В некоторых практиках встречается разграничение доступности сети и предполагается меньшее значение параметра - в нерабочее время. На разные типы услуг (классы трафика) также предусмотрены разные значения показателей. Например, для голоса важнее всего показатель задержки - он должен быть минимальным. А скорость для него нужна невысокая, плюс часть пакетов можно терять без потери качества (примерно до 1% в зависимости от кодека). Для передачи данных на первое место выходит скорость, и потери пакетов должны стремиться к нулю. 5. Методы и средства защиты в облачных вычислениях Конфиденциальность должна обеспечиваться по всей цепочке, включая поставщика "облачного" решения, потребителя и связывающих их коммуникаций. Задача Провайдера - обеспечить как физическую, так и программную неприкосновенность данных от посягательств третьих лиц. Потребитель должен ввести в действие "на своей территории" соответствующие политики и процедуры, исключающие передачу прав доступа к информации третьим лицам. Задачи обеспечения целостности информации в случае применения отдельных "облачных" приложений, можно решить - благодаря современным архитектурам баз данных, системам резервного копирования, алгоритмам проверки целостности и другим индустриальным решениям. Но и это еще не все. Новые проблемы могут возникнуть в случае, когда речь идет об интеграции нескольких "облачных" приложений от разных поставщиков. В ближайшем будущем для компаний, нуждающихся в безопасной виртуальной среде, единственным выходом останется создание частной облачной системы. Дело в том, что частные облака, в отличие от публичных или гибридных систем, больше всего похожи на виртуализованные инфраструктуры, которые ИТ-отделы крупных корпораций уже научились реализовывать и над которыми они могут сохранять полный контроль. Недостатки защиты информации в публичных облачных системах представляют серьезную проблему. Большинство инцидентов со взломом происходит именно в публичных облаках. 6. Безопасность облачных моделей вопросов безопасности также отличаются в зависимости от уровня взаимодействия. Требования к безопасности остаются одинаковыми, но в различных моделях, SaaS, PaaS или IaaS, уровень контроля над безопасностью изменяется. С логической точки зрения ничего не изменяется, но возможности физической реализации кардинально различаются. В модели SaaS приложение запускается на облачной инфраструктуре и доступно через веб-браузер. Клиент не управляет сетью, серверами, операционными системами, хранением данных и даже некоторыми возможностями приложений. По этой причине в модели SaaS основная обязанность по обеспечению безопасности практически полностью ложится на поставщиков. Проблема номер 1 - управление паролями. В модели SaaS приложения находятся в облаке, поэтому главным риском является использование нескольких учетных записей для доступа к приложениям. Организации могут решить эту проблему благодаря унификации учетных записей для облачных и локальных систем. При использовании системы единого входа, пользователи получают доступ к рабочим станциям и облачным сервисам с помощью одной учетной записи. Этот подход уменьшает вероятность появления "подвисших" учетных записей, подверженных несанкционированному использованию после увольнения сотрудников. По объяснению CSA, PaaS предполагает, что клиенты создают приложения с помощью языков программирования и инструментов, поддерживаемых вендором, а затем развертывают их на облачной инфраструктуре. Как и в модели SaaS, клиент не может управлять или контролировать инфраструктуру - сети, сервера, операционные системы или системы хранения данных - но имеет контроль над развертыванием приложений. В модели PaaS пользователи должны обращать внимание на безопасность приложений, а также на вопросы, связанные с управлением API, такие как подтверждение прав доступа, авторизация и проверка. Проблема номер 1 - шифрование данных. Модель PaaS изначально безопасна, но риск заключается в недостаточной производительности системы. Причина в том, что при обмене данными с провайдерами PaaS рекомендуется использовать шифрование, а это требует дополнительных процессорных мощностей. Тем не менее в любом решении передача конфиденциальных данных пользователей должна осуществляться по шифрованному каналу. IaaS Хотя здесь клиенты не контролируют лежащую в основе облачную инфраструктуру, они имеют контроль над операционными системами, хранением данных и развертыванием приложений и, возможно, ограниченный контроль над выбором сетевых компонентов. В данной модели есть несколько встроенных возможностей обеспечения безопасности без защиты инфраструктуры самой по себе. Это значит, что пользователи должны управлять и обеспечивать безопасность операционных систем, приложений и контента, как правило, через API. Если это перевести на язык методов защиты, то провайдер должен обеспечить: · надежный контроль доступа к самой инфраструктуре; · отказоустойчивость инфраструктуры. При этом потребитель облака берет на себя намного больше функций по защите: · межсетевое экранирование в рамках инфраструктуры; · защиту от вторжений в сеть; · защиту операционных систем и баз данных (контроль доступа, защита от уязвимостей, контроль настроек безопасности); · защиту конечных приложений (антивирусная защита, контроль доступа). Таким образом, большая часть мер по защите ложится на плечи потребителя. Провайдер может предоставить типовые рекомендации по защите или готовые решения, чем упростит задачу конечным потребителям.
7. Аудит безопасности Задачи Облачного Аудитора по сути не отличаются от задач аудитора обычных систем. Аудит безопасности в облаке подразделяется на аудит Поставщика и аудит Пользователя. Аудит Пользователя производится по желанию Пользователя, тогда как аудит Поставщика - одно из важнейших условий ведения бизнеса. Он состоит из: инициирование процедуры аудита; сбор информации аудита; анализ данных аудита; выработку рекомендаций; подготовку аудиторского отчета. На этапе инициирования процедуры аудита должны быть решены вопросы полномочий аудитора, сроков проведения аудита. Так же должно быть оговорено обязательное содействие сотрудников аудитору. В целом аудитор проводит аудит для определения надежности системы виртуализации, гипервизора; серверов; хранилищ данных; сетевого оборудования. Если Поставщик на проверяемом сервере использует модель IaaS, то данной проверки будет достаточно для выявления уязвимостей. операционная система, связующее ПО, среда выполнения. При использовании модели SaaS на уязвимости проверяются также системы хранения и обработки данных, приложения. Аудит системы безопасности выполняется с применением тех же методов и средств, что и аудит обычных серверов. Но в отличие от обычного сервера в облачных технологиях дополнительно проводится проверка гипервизора на устойчивость. В облачных технологиях гипервизор является одной из основных технологий и поэтому его аудиту должно придаваться особое значение. 8. Расследование инцидентов и криминалистика в облачных вычислениях Меры по Информационной безопасности могут быть разделены на превентивные (например, шифрование и другие механизмы управления доступом), и реактивные (расследования). Превентивный аспект безопасности облака - область активных научных исследований, в то время как реактивному аспект безопасности облака уделяется намного меньше внимания. Расследование инцидентов (включая расследование преступлений в информационной сфере) - хорошо известный раздел информационной безопасности. Целями таких расследований обычно являются: Доказательство, что преступление / инцидент произошли Восстановление события, окружающие инцидент Идентификация правонарушителей Доказательство причастности и ответственности правонарушителей Доказательство нечестных намерений со стороны правонарушителей. Новая дисциплина - компьютерно-техническая экспертиза (или форензика) появилась, в виду необходимости криминалистического анализа цифровых систем. Цели компьютерно-техническая экспертиза как правило таковы: Восстановление данных, которые, возможно, были удалены Восстановление событий произошедших внутри и вовне цифровых систем, связанных с инцидентом Идентификация пользователей цифровых системы Обнаружение присутствия вирусов и другого вредоносного программного обеспечения Обнаружение присутствия незаконных материалов и программ Взлом паролей, ключеи шифрования и кодов доступа В идеале копьютерно-техническая экспертиза - это своего рода машина времени для следователя, которая может переместиться в любой момент в прошлое цифрового устройства и предоставить исследователю информацию о: людях использовавших устройство в определенный момент действиях пользователей (например, открытие документов, получение доступа к веб-сайту, печать данных в текстовом процессоре, и т.д.) данных, хранившихся, созданных и обработанных устройством в определенное время. Облачные сервисы заменяющие автономные цифровые устройства должны обеспечить сходный уровень криминалистической готовности. Однако это требует преодоления проблем связанных с объединением ресурсов, мультиарендой и эластичностью инфраструктуры облачных вычислений. Основным средством в расследовании инцидентов является журнал аудита. Журналы аудита - предназначенные для контроля над историей регистрации пользователей в системе, выполнением административных задач и изменением данных - являются существенной частью системы безопасности. В облачных технологиях журнал аудита сам по себе является не только инструментом для проведения расследований, но и инструментом расчёта стоимости использования серверов. Хотя контрольный журнал и не устраняет бреши в системе защиты, он позволяет посмотреть на происходящее критическим взглядом и сформулировать предложения по коррекции ситуации. Создание архивов и резервных копий имеет большое значение, но не может заменить формального журнала аудита, в котором регистрируется, кто, когда и что делал. Журнал аудита - один из основных инструментов аудитора безопасности. В договоре об оказании услуг обычно упоминается, какие именно журналы аудита будут вестись и предоставляться Пользователю. 9. Модель угроз В 2010 году CSA провела анализ основных угроз безопасности в облачных технологиях. Результатом их труда стал документ "Top threats of Cloud Computing v 1.0" в котором наиболее полно на данный момент описываются модель угроз и модель нарушителя. На данный момент разрабатывается более полная, вторая версия этого документа. Текущий документ описывает нарушителей для трёх сервисных моделей SaaS, PaaS и IaaS. Выявлены 7 основных направлений атак. По большей части все рассматриваемые виды атак - это атаки, присущие обычным, "необлачным" серверам. Облачная инфраструктура накладывает на них определенные особенности. Так, например, к атакам на уязвимости в программной части серверов добавляются атаки на гипервизор, тоже являющийся их программной частью. Угроза безопасности №1 Неправомерное и нечестное использование облачных технологий. Описание: Для получения ресурсов у облачного провайдера IaaS пользователю достаточно иметь кредитную карту. Простота регистрации и выделения ресурсов позволяет спамерам, авторам вирусов и т.п. использовать облачный сервис в своих преступных целях. Раньше подобного рода атаки наблюдались лишь в PaaS, однако последние исследования показали возможность использования IaaS для DDOS-атак, размещения вредоносного кода, создания ботнет сетей и прочего. Примеры IaaS сервисы были использованы для создания ботнет сети на основе троянской программы "Zeus”, хранения кода троянского коня "InfoStealer" и размещения информации о различных уязвимостях MS Office и AdobePDF. Угроза безопасности №2 Небезопасные программные интерфейсы (API) Описание: Провайдеры облачной инфраструктуры предоставляют пользователям набор программных интерфейсов для управления ресурсами, виртуальными машинами или сервисами. Безопасность всей системы зависит от безопасности этих интерфейсов. Начиная от процедуры аутентификации и авторизации и заканчивая шифрованием, программные интерфейсы должны обеспечивать максимальный уровень защиты от различного сорта атак злоумышленников. Примеры: Анонимный доступ к интерфейсу и передача учетных данных открытым текстом являются основными признаками небезопасных программных интерфейсов. Ограниченные возможности мониторинга использования API, отсутствие систем журналирования, а так же неизвестные взаимосвязи между различными сервисами только повышает риски взлома. Угроза безопасности №3 Внутренние нарушители Описание: Проблема неправомерного доступа к информации изнутри чрезвычайно опасна. Зачастую, на стороне провайдера не внедрена система мониторинга за активностью сотрудников, а это означает, что злоумышленник может получить доступ к информации клиента, используя своё служебное положение. Так как провайдер не раскрывает своей политики набора сотрудников, то угроза может исходить как от хакера-любителя, так и от организованной преступной структуры, проникшей в ряды сотрудников провайдера. Примеры: На данный момент нет примеров подобного рода злоупотреблений. Рекомендации по устранению: • Внедрение строгих правил закупок оборудования и использование соответствующих систем обнаружение несанкционированного доступа • Регламентирование правил найма сотрудников в публичных контрактах с пользователями • Создание прозрачной системы безопасности, наряду с публикациями отчетов об аудите безопасности внутренних систем провайдера Угроза безопасности №4 Уязвимости в облачных технологиях Описание: Провайдеры IaaS сервиса используют абстракцию аппаратных ресурсов с помощью систем виртуализации. Однако аппаратные средства могут быть спроектированы без учета работы с разделяемыми ресурсами. Для того, что бы минимизировать влияние данного фактора, гипервизор управляет доступом виртуальной машины к аппаратным ресурсам, однако даже в гипервизорах могут существовать серьезные уязвимости, использование которых может привести к повышению привилегий или получению неправомерного доступа к физическому оборудованию. Для того, что бы защитить системы от такого рода проблем необходимо внедрение механизмов изоляции виртуальных сред и систем обнаружения сбоев. Пользователи виртуальной машины не должны получить доступ к разделяемым ресурсам. Угроза безопасности №5 Потеря или утечка данных Описание: Потеря данных может произойти из-за тысячи причин. Например, преднамеренное уничтожение ключа шифрования приведет к тому, что зашифрованная информация не будет подлежать восстановлению. Удаление данных или части данных, неправомерный доступ к важной информации, изменение записей или выход из строя носителя так же являются примером подобных ситуаций. В сложной облачной инфраструктуре вероятность каждого из событий возрастает ввиду тесного взаимодействия компонентов. Примеры: Неправильное применение правил аутентификации, авторизации и аудита, неверное использование правил и методов шифрования и поломки оборудования могут привести к потере или утечке данных. Статья 1 (частично): Клиенты владеют своими данными · Ни один производитель (или поставщик) не должен в процессе взаимодействия с клиентами любого плана обсуждать права на любые данные, загруженные, созданные, сгенерированные, модифицированные или любые другие, права на которые имеет клиент. · Производители должны изначально обеспечивать минимальную возможность доступа к данным клиентов еще на стадии разработки решений и сервисов. · Клиенты владеют своими данными, что означает, что они отвечают за то, что данные эти соответствуют законодательным нормам и законам. · Поскольку вопросы соответствия регуляторным нормам по использованию данных, обеспечению безопасности и соблюдению безопасности являются очень важными, необходимо, чтобы клиент определял географическое месторасположение своих собственных данных. В противном случае, производители должны предоставить пользователям все гарантии, что их данные будут храниться в соответствии со всеми нормами и правилами. Статья 2: Производители и Клиенты совместно владеют и управляют уровнями сервиса в системе · Производители владеют, а также должны делать все для того, чтобы соответствовать уровню сервиса для каждого клиента в отдельности. Все необходимые ресурсы и усилия, приложенные для достижения должного уровня сервиса в работе с клиентами, должны быть бесплатны для клиента, то есть не входить в стоимость сервиса. · Клиенты, в свою очередь отвечают за и владеют уровнем сервиса, предоставляемого их собственным внутренним и внешним клиентам. При использовании решений производителя для предоставления собственных сервисов - ответственность клиента и уровень такого сервиса не должен целиком зависеть от производителя. · В случае необходимости интеграции систем производителя и клиента, производители должны предлагать клиентам возможности мониторинга процесса интеграции. В случае, если у клиента существуют корпоративные стандарты по интеграции информационных систем, производитель должен соответствовать этим стандартам. · Ни при каких условиях производители не должны закрывать учетные записи клиентов за политические высказывания, некорректную речь, религиозные комментарии, если это не противоречит специфическим законодательным нормам, не является выражением ненависти и т.п. Статья 3: Производители владеют своими интерфейсами · Производители не обязаны предоставлять стандартные интерфейсы или интерфейсы с открытым кодом, если обратное не прописано в соглашениях с клиентом. Правами на интерфейсы обладают производители. В случае, если производитель не считает возможным предоставить клиенту возможности по доработке интерфейса на привычном языке программирования, клиент может приобрести у производителя либо сторонних разработчиков услуги по доработке интерфейсов в соответствии с собственными требованиями. · Клиент, однако, обладает правом использовать приобретенный сервис в собственных целях, а также расширять его возможности, реплицировать и улучшать. Данный пункт не освобождает клиентов от ответственности патентного права и права на интеллектуальную собственность. Приведенные выше три статьи - основа основ для клиентов и производителей "в облаке". С их полным текстом вы можете ознакомиться в открытом доступе в сети Интернет. Конечно, данный билль не является законченным юридическим документом, а уж тем более официальным. Статьи его могут меняться и расширяться в любое время, равно как и билль может дополняться новыми статьями. Это попытка формализовать "право собственности" в облаке, чтобы хоть как-то стандартизировать эту свободолюбивую область знаний и технологий. Взаимоотношения между сторонами На сегодняшний день лучшим экспертом в сфере облачной безопасности является Cloud Security Alliance (CSA). Эта организация выпустила и недавно обновила руководство, включающее описание сотни нюансов и рекомендаций, которые необходимо принимать во внимание при оценке рисков в облачных вычислениях. Еще одной организацией, деятельность которой затрагивает аспекты безопасности в облаке, выступает Trusted Computing Group (TCG). Она является автором нескольких стандартов в этой и других сферах, в том числе широко используемых сегодня Trusted Storage, Trusted Network Connect (TNC) и Trusted Platform Module (TPM). 1. Сохранность хранимых данных. Как сервис-провайдер обеспечиваетсохранность хранимых данных? Лучшая мера по защите расположенных в хранилище данных - использование технологий шифрования. Провайдер всегда должен шифровать хранящуюся на своих серверах информацию клиента для предотвращения случаев неправомерного доступа. Провайдер также должен безвозвратно удалять данные тогда, когда они больше не нужны и не потребуются в будущем. 2. Защита данных при передаче.Как провадйер обеспечивает сохранностьданных при их передаче (внутри облака и на пути от/к облаку)? Передаваемые данные всегда должны быть зашифрованы и доступны пользователю только после аутентификации. Такой подход гарантирует, что эти данные не сможет изменить или прочитать ни одно лицо, даже если оно получит к ним доступ посредством ненадежных узлов в сети. Упомянутые технологии разрабатывались в течение "тысяч человеко-лет" и привели к созданию надежных протоколов и алгоритмов (например TLS, IPsec и AES). Провайдеры, должны использовать эти протоколы, а не изобретать свои собственные. 3. Аутентификация.Как провайдер узнает подлинность клиента? Наиболее распространенным способом аутентификации является защита паролем. Однако провайдеры, стремящиеся предложить своим клиентам более высокую надежность, прибегают к помощи более мощных средств, таких как сертификаты и токены. Наряду с использованием более надежных к взлому средств аутентификации провайдеры должны иметь возможность работы с такими стандартами как LDAP и SAML. Это необходимо для обеспечения взаимодействия провайдера с системой идентификации пользователей клиента при авторизации и определении выдаваемых пользователю полномочий. Благодаря этому провайдер всегда будет располагать актуальной информацией об авторизованных пользователях. Худший вариант - когда клиент предоставляет провайдеру конкретный список авторизованных пользователей. Как правило, в этом случае при увольнении сотрудника или его перемещении на другую должность могут возникнуть сложности. 4. Изоляция пользователей. Каким образом данные и приложения одногоклиента отделены от данных и приложений других клиентов? Лучший вариант: когда каждый из клиентов использует индивидуальную виртуальную машину (Virtual Machine - VM) и виртуальную сеть. Разделение между VM и, следовательно, между пользователями, обеспечивает гипервизор. Виртуальные сети, в свою очередь, развертываются с применением стандартных технологий, таких как VLAN (Virtual Local Area Network), VPLS (Virtual Private LAN Service) и VPN (Virtual Private Network). Некоторые провайдеры помещают данные всех клиентов в единую программную среду и за счет изменений в ее коде пытаются изолировать данные заказчиков друг от друга. Такой подход опрометчив и ненадежен. Во-первых, злоумышленник может найти брешь в нестандартном коде, который позволит ему получить доступ к данным, которые он не должен видеть. Во-вторых, ошибка в коде может привести к тому, что один клиент случайно "увидит" данные другого. За последнее время встречались и те, и другие случаи. Поэтому для разграничения пользовательских данных применение разных виртуальных машин и виртуальных сетей является более разумным шагом. 5. Нормативно-правовые вопросы. Насколько провайдер следует законам иправилам, применимым к сфере облачных вычислений? В зависимости от юрисдикции, законы, правила и какие-то особые положения могут различаться. Например, они могут запрещать экспорт данных, требовать использования строго определенных мер защиты, наличия совместимости с определенными стандартами и наличия возможности аудита. В конечном счете, они могут требовать, чтобы в случае необходимости доступ к информации смогли иметь государственные ведомства и судебные инстанции. Небрежное отношение провайдера к этим моментам может привести его клиентов к существенным расходам, обусловленными правовыми последствиями. Провайдер обязан следовать жестким правилам и придерживаться единой стратегии в правовой и регулятивной сферах. Это касается безопасности пользовательских данных, их экспорта, соответствия стандартам, аудита, сохранности и удаления данных, а также раскрытия информации (последнее особенно актуально, когда на одном физическом сервере может храниться информация нескольких клиентов). 6. Реакция на происшествия. Как провайдер реагирует на происшествия, инасколько могут быть вовлечены его клиенты в инцидент? Иногда не все идет по плану. Поэтому провайдер услуг обязан придерживаться конкретных правил поведения в случае возникновения непредвиденных обстоятельств. Эти правила должны быть задокументированы. Провайдеры обязательно должны заниматься выявлением инцидентов и минимизировать их последствия, информируя пользователей о текущей ситуации. В идеале им следует регулярно снабжать клиентов информацией с максимальной детализацией по проблеме. Кроме того, клиенты сами должны оценивать вероятность возникновения проблем, связанных с безопасностью, и предпринимать необходимые меры. 10. Международные и отечественные стандарты Эволюция облачных технологий опережает деятельность по созданию и модификации необходимых отраслевых стандартов, многие из которых не обновлялись уже много лет. Поэтому законотворчество в сфере облачных технологий - один из важнейших шагов к обеспечению безопасности. |