Курсовая работа по дисциплине

Программно-аппаратные средства обеспечения информационной безопасности

"Информационная безопасность в облачных вычислениях: уязвимости, методы и средства защиты, инструменты для проведения аудита и расследования инцидентов. "

Введение

1. История и ключевые факторы развития

2. Определение облачных вычислений

3. Референтная архитектура

4. Соглашение об уровне сервиса

5. Методы и средства защиты в облачных вычислениях

6. Безопасность облачных моделей

7. Аудит безопасности

8. Расследование инцидентов и криминалистика в облачных вычислениях

9. Модель угроз

10. Международные и отечественные стандарты

11. Территориальная принадлежность данных

12. Государственные стандарты

13. Средства обеспечения защиты в облачных технологиях

14. Практическая часть

Вывод

Литература

Введение

Нарастающая скорость распространения облачных вычислений объясняется тем, что за небольшие, в общем-то, деньги заказчик получает доступ к надежнейшей инфраструктуре с необходимой производительностью без необходимости закупки, монтажа и обслуживания дорогостоящих вычислителей.системы достигает 99,9% что также позволяет сэкономить на вычислительных ресурсах. И что еще важно - практически неограниченные возможности по масштабируемости. Приобретая обычный хостинг и попытавшись прыгнуть выше головы (при резком всплеске нагрузки) есть риск получить упавший на несколько часов сервис. В облаке дополнительные ресурсы предоставляются по первому запросу.

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

Целью исследования будет являться обзор имеющегося рынка облачных вычислений и средств для обеспечения безопасности в них.

облачное вычисление безопасность информация

1. История и ключевые факторы развития

Впервые идея того, что мы сегодня называем облачными вычислениями была озвучена J. C. R. Licklider, в 1970 году. В эти годы он был ответственным за создание ARPANET (Advanced Research Projects Agency Network). Его идея заключалась в том, что каждый человек на земле будет подключен к сети, из которой он будет получать не только данные но и программы. Другой ученый John McCarthy высказал идею о том, что вычислительные мощности будут предоставляться пользователям как услуга (сервис). На этом развитие облачных технологий было приостановлено до 90-х годов, после чего ее развитию поспособствовал ряд факторов.

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

2. Одним из наиболее значимых событий в данной области было появление Salesforce.com в 1999 году. Данная компания стала первой компанией предоставившей доступ к своему приложению через сайт. По сути данная компания стала первой компанией предоставившей свое программное обеспечение по принципу - программное обеспечение как сервис (SaaS).

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

В 2006, Amazon запустила сервис под названием Elastic Compute cloud (EC2), как веб-сервис который позволял его пользователям запускать свои собственные приложения. Сервисы Amazon EC2 и Amazon S3 стали первыми доступными сервисами облачных вычислений.

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

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

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

2. Определение облачных вычислений

Согласно определению Национального института стандартов и технологий CША:

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

Облачная модель поддерживает высокую доступность сервисов и описывается пятью основными характеристиками (essential characteristics), тремя сервисными моделями/моделями предоставления услуг (service models) и четырьмя моделями развертывания (deployment models).

Программы запускаются и выдают результаты работы в окно стандартного веб-браузера на локальном ПК, при этом все приложения и их данные, необходимые для работы, находятся на удаленном сервере в интернете. Компьютеры, осуществляющие cloud computing, называются "вычислительным облаком". При этом нагрузка между компьютерами, входящими в "вычислительное облако", распределяется автоматически. Простейшим примером cloud computing являются p2p-сети.

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

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

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

Для особо крупных и ресурсоёмких вычислений используются грид-вычисления.

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

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

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

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

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

Гипервизор (или Монитор виртуальных машин ) - в компьютерах программа или аппаратная схема, обеспечивающая или позволяющая одновременное, параллельное выполнение нескольких или даже многих операционных систем на одном и том же хост-компьютере. Гипервизор также обеспечивает изоляцию операционных систем друг от друга, защиту и безопасность, разделение ресурсов между различными запущенными ОС и управление ресурсами.

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

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

Модели облачных служб

Варианты предоставления вычислительных мощностей сильно отличаются. Все, что касается Cloud Computing, обычно принято называть словом aaS, - расшифровывается просто - "as a Service", то есть "как сервис", или "в виде сервиса".

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

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

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

Рис. 1 Типовая схема SaaS

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

Рис. 2 Типовая схема PaaS

Инфраструктура как услуга (IaaS). - провайдер предлагает клиенту вычислительные ресурсы в аренду: серверы, системы хранения, сетевое оборудование, операционные системы и системное ПО, системы виртуализации, системы управления ресурсами. Потребитель при этом не управляет базовой инфраструктурой облака, но имеет контроль над операционными системами, системами хранения, развернутыми приложениями и, возможно, ограниченный контроль выбора сетевых компонентов (например, хост с сетевыми экранами).

Рис. 3 Типовая схема IaaS

Дополнительно выделяют такие сервисы, как:

Коммуникации как услуга (Com-aaS) - подразумевается, что в качестве сервисов предоставляются услуги связи; обычно это IP-телефония, почта и мгновенные коммуникации (чаты, IM).

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

Рабочее место как услуга (WaaS) - пользователь, имея в своём распоряжении недостаточно мощный компьютер, может купить у поставщика вычислительные ресурсы и использовать свой ПК как терминал, для доступа к услуге.

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

Модели развёртывания

Среди моделей развёртывания выделяют 4 основных вида инфраструктуры

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

Рис. 4 Частное облако.

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

Рис. 5 Публичное облако.

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

Рис. 6 Гибридное облако.

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

Рис. 7 Описание свойств облаков

Основные свойства

NIST в своем документе `The NIST Definition of Cloud Computing` определяет следующие характеристики облаков:

Самообслуживание по требованию (On-demand self-service). У потребителя есть возможность получить доступ к предоставляемым вычислительным ресурсам в одностороннем порядке по мере потребности, автоматически, без необходимости взаимодействия с сотрудниками каждого поставщика услуг.

Широкий сетевой доступ (Broad network access). Предоставляемые вычислительные ресурсы доступны по сети через стандартные механизмы для различных платформ, тонких и толстых клиентов (мобильных телефонов, планшетов, ноутбуков, рабочих станций и т.п.).

Объединение ресурсов в пулы (Resorce pooling). Вычислительные ресурсы провайдера объединяются в пулы для обслуживания многих потребителей по многоарендной (multi-tenant) модели. Пулы включают в себя различные физические и виртуальные ресурсы, которые могут быть динамически назначены и переназначены в соответствии с потребительскими запросами. Нет необходимости в том, чтобы потребитель знал точное местоположение ресурсов, однако можно указать их местонахождение на более высоком уровне абстракции (например, страна, регион или центр обработки данных). Примерами такого рода ресурсов могут быть системы хранения, вычислительные мощности, память, пропускная способность сети.

Мгновенная эластичность (Rapid elasticity). Ресурсы могут быть эластично выделены и освобождены, в некоторых случаях автоматически, для быстрого масштабирования соразмерно со спросом. Для потребителя возможности предоставления ресурсов видятся как неограниченные, то есть они могут быть присвоены в любом количестве и в любое время.

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

Рис. 8 Структурная схема облачного сервера

Достоинства и недостатки облачных вычислений

Достоинства

· снижаются требования к вычислительной мощности ПК (непременным условием является только наличие доступа в интернет);

· отказоустойчивость;

· безопасность;

· высокая скорость обработки данных;

· снижение затрат на аппаратное и программное обеспечение, на обслуживание и электроэнергию;

· экономия дискового пространства (и данные, и программы хранятся в интернете).

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

· В конце 2010 года в связи с DDoS атаками против компаний, отказавшихся предоставлять ресурсы WikiLeaks, выяснилось еще одно преимущество технологии cloud computing. Атакованы были все компании, выступившие против WikiLeaks, но только Amazon оказалась нечувствительна к этим воздействиям, так как использовала средства cloud computing. ("Anonymous: serious threat or mere annoyance", Network Security, N1, 2011).

Недостатки

· зависимость сохранности пользовательских данных от компаний, предоставляющих услугу cloud computing;

· постоянное соединение с сетью - для получения доступа к услугам "облака" необходимо постоянное соединение с сетью Интернет. Однако в наше время это не такой и большой недостаток особенно с приходом технологий сотовой связи 3G и 4G.

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

· конфиденциальность - конфиденциальность данных хранимых на публичных "облаках" в настоящее вызывает много споров, но в большинстве случаев эксперты сходятся в том, что не рекомендуется хранить наиболее ценные для компании документы на публичном "облаке”, так как в настоящее время нет технологии которая бы гарантировала 100% конфиденциальность хранимых данных. Именно поэтому применение шифрования в облаке - обязательно.

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

· безопасность - "облако” само по себе является достаточно надежной системой, однако при проникновении на него злоумышленник получает доступ к огромному хранилищу данных. Еще один минус это использование систем виртуализации, в которых в качестве гипервизора используются ядра стандартные ОС такие, как Linux, Windows и др., что позволяет использовать вирусы.

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

3. Референтная архитектура

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

Рис. 9 Концептуальная схема референтной архитектуры

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

Облачные Потребители разбиваются на 3 группы:

· SaaS - использует приложения для автоматизации бизнес-процессов.

· PaaS - разрабатывает, тестирует, развертывает и управляет приложениями, развернутыми в облачном окружении.

· IaaS - создаёт, управляет сервисами ИТ-инфраструктуры.

Облачный Провайдер - лицо, организация или сущность, отвечающая за доступность облачной услуги для Облачных Потребителей.

· SaaS - устанавливает, управляет, сопровождает и обеспечивает ПО, развернутое на облачной инфраструктуре.

· PaaS - предоставляет и управляет облачной инфраструктурой и связующим ПО. Предоставляет инструменты разработки и администрирования.

· IaaS - предоставляет и обслуживает сервера, базы данных, вычислительные ресурсы. Предоставляет облачную структуру потребителю.

Деятельность Облачных Провайдеров делится на основные 5 типовых действий:

Развёртывание сервисов:

o Частное облако - обслуживается одна организация. Инфраструктура управляется как самой организацией, так и третьей стороной и может быть развёрнута как у Провайдера (off premise), так и у организации (on premise).

o Общее облако - инфраструктура используется совместно несколькими организациями со схожими требованиями (безопасность, соответствие РД).

o Публичное облако - инфраструктура используется большим количеством организаций с разными требованиями. Только off premise.

o Гибридное облако - инфраструктура объединяет различные инфраструктуры по принципу схожих технологий.

Управление сервисами

o Уровень сервиса - определяет базовые сервисы, предоставляемые Провайдером.

§ SaaS - приложение, используемое Потребителем посредством обращения к облаку из специальных программ.

§ PaaS - контейнеры для приложений Потребителя, средства разработки и администрирования.

§ IaaS - вычислительные мощности, базы данных, фундаментальные ресурсы, поверх которых Потребитель развёртывает свою инфраструктуру.

o Уровень абстракции и контроля ресурсов

§ Управление гипервизором и виртуальными компонентами, необходимыми для реализации инфраструктуры.

o Уровень физических ресурсов

§ Компьютерное оборудование

§ Инженерная инфраструктура

o Доступность

o Конфиденциальность

o Идентефикация

o Мониторинг безопасности и обработка инцидентов

o Политики безопасности

Приватность

o Защита обработки, хранения и передачи персональных данных.

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

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

Рис. 10 Деятельность Провайдера

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

С развитием облачных вычислений, интеграция облачных сервисов может оказаться слишком сложной для Потребителя.

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, уровень контроля над безопасностью изменяется. С логической точки зрения ничего не изменяется, но возможности физической реализации кардинально различаются.

Рис. 11. Наиболее актуальные угрозы ИБ

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

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

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

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

Проблема номер 1 - шифрование данных. Модель PaaS изначально безопасна, но риск заключается в недостаточной производительности системы. Причина в том, что при обмене данными с провайдерами PaaS рекомендуется использовать шифрование, а это требует дополнительных процессорных мощностей. Тем не менее в любом решении передача конфиденциальных данных пользователей должна осуществляться по шифрованному каналу.

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

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

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

· надежный контроль доступа к самой инфраструктуре;

· отказоустойчивость инфраструктуры.

При этом потребитель облака берет на себя намного больше функций по защите:

· межсетевое экранирование в рамках инфраструктуры;

· защиту от вторжений в сеть;

· защиту операционных систем и баз данных (контроль доступа, защита от уязвимостей, контроль настроек безопасности);

· защиту конечных приложений (антивирусная защита, контроль доступа).

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

Таблица 1. Разграничение ответственности за обеспечение безопасности между клиентом и поставщиком услуги. (П - поставщик, К - клиент)

	Сервер предприятия
Приложение
Данные
Среда выполнения
Связующее программное обеспечение
Операционная система
Виртуализация
Сервера
Хранилища данных
Сетевое оборудование

7. Аудит безопасности

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

Он состоит из:

· инициирование процедуры аудита;

· сбор информации аудита;

· анализ данных аудита;

· подготовку аудиторского отчета.

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

В целом аудитор проводит аудит для определения надежности

· системы виртуализации, гипервизора;

· серверов;

· хранилищ данных;

· сетевого оборудования.

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

При использовании модели PaaS дополнительно должны быть проверены

· операционная система,

· связующее ПО,

· среда выполнения.

При использовании модели SaaS на уязвимости проверяются также

· системы хранения и обработки данных,

· приложения.

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

8. Расследование инцидентов и криминалистика в облачных вычислениях

Меры по Информационной безопасности могут быть разделены на превентивные (например, шифрование и другие механизмы управления доступом), и реактивные (расследования). Превентивный аспект безопасности облака - область активных научных исследований, в то время как реактивному аспект безопасности облака уделяется намного меньше внимания.

Расследование инцидентов (включая расследование преступлений в информационной сфере) - хорошо известный раздел информационной безопасности. Целями таких расследований обычно являются:

Доказательство, что преступление / инцидент произошли

Восстановление события, окружающие инцидент

Идентификация правонарушителей

Доказательство причастности и ответственности правонарушителей

Доказательство нечестных намерений со стороны правонарушителей.

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

Восстановление данных, которые, возможно, были удалены

Восстановление событий произошедших внутри и вовне цифровых систем, связанных с инцидентом

Идентификация пользователей цифровых системы

Обнаружение присутствия вирусов и другого вредоносного программного обеспечения

Обнаружение присутствия незаконных материалов и программ

Взлом паролей, ключеи шифрования и кодов доступа

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

людях использовавших устройство в определенный момент

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

данных, хранившихся, созданных и обработанных устройством в определенное время.

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

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

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

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

9. Модель угроз

В 2010 году CSA провела анализ основных угроз безопасности в облачных технологиях. Результатом их труда стал документ "Top threats of Cloud Computing v 1.0" в котором наиболее полно на данный момент описываются модель угроз и модель нарушителя. На данный момент разрабатывается более полная, вторая версия этого документа.

Текущий документ описывает нарушителей для трёх сервисных моделей SaaS, PaaS и IaaS. Выявлены 7 основных направлений атак. По большей части все рассматриваемые виды атак - это атаки, присущие обычным, "необлачным" серверам. Облачная инфраструктура накладывает на них определенные особенности. Так, например, к атакам на уязвимости в программной части серверов добавляются атаки на гипервизор, тоже являющийся их программной частью.

Угроза безопасности №1

Неправомерное и нечестное использование облачных технологий.

Описание:

Для получения ресурсов у облачного провайдера IaaS пользователю достаточно иметь кредитную карту. Простота регистрации и выделения ресурсов позволяет спамерам, авторам вирусов и т.п. использовать облачный сервис в своих преступных целях. Раньше подобного рода атаки наблюдались лишь в PaaS, однако последние исследования показали возможность использования IaaS для DDOS-атак, размещения вредоносного кода, создания ботнет сетей и прочего.

Примерысервисы были использованы для создания ботнет сети на основе троянской программы "Zeus”, хранения кода троянского коня "InfoStealer" и размещения информации о различных уязвимостях MS Office и AdobePDF.

К тому же ботнет сети используют IaaS для управления своими пирами и для рассылки спама. Из-за этого некоторые IaaS сервисы попали в чёрные списки, а их пользователи полностью игнорировались почтовыми серверами.

· Усовершенствование процедур регистрации пользователя

· Усовершенствование процедур верификации кредитных карт и мониторинг использования платежных средств

· Всестороннее исследование сетевой активности пользователей сервиса

· Отслеживание основных черных листов на предмет появления там сети облачного провайдера.

Затронутые сервис-модели:

Угроза безопасности №2

Небезопасные программные интерфейсы (API)

Описание:

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

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

· Выполнить анализ модели безопасности облачного провайдера

· Убедиться, что используются устойчивые алгоритмы шифрования

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

· Понять всю цепочку зависимости между различными сервисами.

Затронутые сервис модели:

Угроза безопасности №3

Внутренние нарушители

Описание:

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

На данный момент нет примеров подобного рода злоупотреблений.

Внедрение строгих правил закупок оборудования и использование соответствующих систем обнаружение несанкционированного доступа

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

Создание прозрачной системы безопасности, наряду с публикациями отчетов об аудите безопасности внутренних систем провайдера

Затронутые сервис модели:

Рис. 12 Пример внутреннего нарушителя

Угроза безопасности №4

Уязвимости в облачных технологиях

Описание:

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

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

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

· Внедрение самых передовых методов установки, настройки и защиты виртуальных сред

· Использование систем обнаружение несанкционированного доступа

· Применение надежных правил аутентификации и авторизации на проведение административных работ

· Ужесточение требований к времени применения патчей и обновлений

· Проведение своевременных процедур сканирования и обнаружения уязвимостей.

Угроза безопасности №5

Потеря или утечка данных

Описание:

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

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

· Использование надежного и безопасного API

· Шифрование и защита передаваемых данных

· Анализ модели защиты данных на всех этапах функционирования системы

· Внедрение надежной системы управления ключами шифрования

· Отбор и приобретение только самых надежных носителей

· Обеспечение своевременного резервного копирования данных

Затронутые сервис модели:

Угроза безопасности №6

Кража персональных данных и неправомерный доступ к сервису

Описание:

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

· Запрет на передачу учетных записей

· Использование двух факторных методов аутентификации

· Внедрение проактивного мониторинга несанкционированного доступа

· Описание модели безопасности облачного провайдера.

Затронутые сервис модели:

Угроза безопасности №7

Прочие уязвимости

Описание:

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

· Отказ компании Amazon от проведения аудита безопасности EC2 cloud

· Уязвимость в процессинговом ПО, приведшая к взлому системы безопасности дата центра Hearthland

· Раскрытие журнальных данных

· Полное или частичное раскрытие данных об архитектуре системы и деталей об установленном ПО

· Использование систем мониторинга уязвимостей.

Затронутые сервис модели:

1. Юридическая база

По заявлениям экспертов 70% проблем с безопасностью в облаке можно избежать, если грамотно составить договор о предоставлении услуг.

Базой для такого договора может послужить "Билль о правах облака"

"Билль о правах облака" был разработан еще в 2008 г. Джеймсом Уркухартом (James Urquhart). Этот материал он опубликовал в своем блоге, который вызвал столько интереса и споров, что автор периодически обновляет свой "манускрипт" в соответствие с реалиями.

Статья 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. Международные и отечественные стандарты

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

IEEE, одна из крупнейших организаций по разработке стандартов, объявила о запуске специального проекта в области облачных технологий Cloud Computing Initiative. Это первая инициатива по стандартизации облачных технологий, выдвинутая на международном уровне - до сегодняшнего дня стандартами в сфере облачных вычислений занимались преимущественно отраслевые консорциумы. В настоящее время инициатива включает в себя 2 проекта: IEEE P2301 (tm), "Черновое руководство по обеспечению портативности и интероперабельности профилей облачных технологий”, и IEEE P2302 (tm) - "Черновой стандарт по обеспечению интероперабельности и распределенного взаимодействия (Federation) облачных систем”.

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

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

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

Ценность документа в том, что в его подготовку вовлечены не только правительственные организации (NIST, ENISA), но и представители экспертных сообществ и ассоциаций, таких как ISACA и CSA. Причем, в одном документе собраны рекомендации как для провайдеров облачных услуг, так и для их потребителей - организаций-клиентов.

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

Новый документ во многом вобрал в себя материалы, разработанные в ИТ-индустрии ранее.

Правительство Австралии

После нескольких месяцев "мозгового штурма", правительство Австралии выпустило ряд руководств по переходу на использование облачных вычислений.15 февраля 2012 года эти руководства были выложены на блоге департамента управления информацией правительства Австралии (Australian Government Information Management Office, AGIMO).

Чтобы облегчить компаниям миграцию в облака, подготовлены рекомендации по наилучшей практике использования облачных услуг в свете исполнения требований закона 1997 года об управлении финансами и подотчетности (Better Practice Guides for Financial Management and Accountability Act 1997). В руководствах в общем плане рассматриваются финансовые и правовые проблемы, а также вопросы защиты персональных данных.

Руководства говорят о необходимости постоянного мониторинга и контроля использования облачных услуг посредством ежедневного анализа счетов и отчетов. Это поможет избежать скрытых "накруток" и попадания в зависимость от поставщиков облачных услуг.

Первое руководство называется "Облачные вычисления и защита персональных данных для учреждений правительства Австралии" (Privacy and Cloud Computing for Australian Government Agencies, 9 стр.). В этом документе особое внимание уделяется вопросам обеспечения неприкосновенности частной жизни и безопасности при хранении данных.

В дополнение к этому руководству, был также подготовлен документ "Переговоры о предоставлении облачных услуг - Правовые вопросы в соглашениях о предоставлении облачных услуг" (Negotiating the Cloud - Legal Issues in Cloud Computing Agreements,19 стр.), помогающий разобраться в положениях, включаемых в договора.

Последнее, третье руководство "Финансовые соображения при использовании государственными органами облачных вычислений" (Financial Considerations for Government use of Cloud Computing, 6 стр.) рассматривает финансовые вопросы, на которые компании следует обратить внимание, если она решит использовать облачные вычислений в своей деловой деятельности.

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

Публичное обсуждение данного аналитического документа дает возможность заинтересованным сторонам рассмотреть и прокомментировать следующие проблемные вопросы:

· Несанкционированный доступ к секретной информации;

· Утрата доступа к данным;

· Неспособность обеспечить целостность и аутентичность данных, и

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

11. Территориальная принадлежность данных

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

Некоторые крупные игроки на рынке SaaS (такие, как Google, Symantec) могут дать гарантию хранения данных в соответствующей стране. Но это, скорее, исключения, в целом выполнение этих требований встречается пока довольно редко. Даже если данные остаются в стране, у клиентов нет возможности проверить это. Кроме того, не надо забывать и о мобильности сотрудников компаний. Если специалист, работающий в Москве, командируется в Нью-Йорк, то лучше (или, как минимум, быстрее), чтобы он получал данные из ЦОД в США. Обеспечить это - задача уже на порядок сложнее.

12. Государственные стандарты

На данный момент в нашей стране отсутствует какая-либо серьёзная нормативная база по облачным технологиям, хотя наработки в этой области уже ведутся. Так приказом президента РФ №146 от 8.02.2012г. определено, что федеральными органами исполнительной власти, уполномоченными в области обеспечения безопасности данных в информационных системах, созданных с использованием суперкомпьютерных и грид-технологий, являются ФСБ России и ФСТЭК России.

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

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

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

ФСТЭК заказала исследование, в результате которой появилася бета-версия "терминосистема в области "облачных технологи"”

Как можно понять, вся эта Терминосистема - это адаптированный перевод двух документов: "Focus Group on Cloud Computing Technical Report" и "The NIST Definition of Cloud Computing". Ну, то, что эти два документа не очень согласуются между собой - это отдельный вопрос. А визуально пока видно: в русской "Терминосистеме" авторы для начала просто не привели ссылки на эти английские документы.

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

Не говоря о том, что нормальное исследование должно включать раздел "обзор существующего положения дел".

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

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

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

13. Средства обеспечения защиты в облачных технологиях

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

Для этого нам понадобится сервер, поддерживающий виртуализацию. Решения подобного рода предлагаются компаниями Cisco, Microsoft, VMWare, Xen, KVM.

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

Для виртуализации операционных систем для платформ x86-64 подходят любые сервера с совместимыми процессорами.

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

Схема работы:

Рис. 11. Пример работы "облачного" сервера

Рис. 12. Реакция сервера на отказ блока оборудования

На данный момент рынок средств защиты облачных вычислений еще достаточно пуст. И это не удивительно. При отсутствии нормативной базы и неизвестности будущих стандартов компании-разработчики не знают, на чём акцентировать свои силы.

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

· Нарушение целостности

· Взлом гипервизора

· Инсайдеры

· Идентификация

· Аутентификация

· Шифрование

Аккорд-В

Программно-аппаратный комплекс Аккорд-В. предназначен для защиты инфраструктуры виртуализации VMware vSphere 4.1, VMware vSphere 4.0 и VMware Infrastructure 3.5.

Аккорд-В. обеспечивает защиту всех компонентов среды виртуализации: ESX-серверов и самих виртуальных машин, серверов управления vCenter и дополнительных серверов со службами VMware (например, VMware Consolidated Backup).

В программно-аппаратном комплексе Аккорд-В реализованы следующие механизмы защиты:

· Пошаговый контроль целостности гипервизора, виртуальных машин, файлов внутри виртуальных машин и серверов управления инфраструктурой;

· Разграничение доступа администраторов виртуальной инфраструктуры и администраторов безопасности;

· Разграничение доступа пользователей внутри виртуальных машин;

· Аппаратная идентификация всех пользователей и администраторов инфраструктуры виртуализации.

· СВЕДЕНИЯ О НАЛИЧИИ СЕРТИФИКАТОВ:

Сертификат соответствия ФСТЭК России №2598 от 20.03.2012 удостоверяет, что программно-аппаратный комплекс средств защиты информации от несанкционированного доступа "Аккорд-В.", является программно-техническим средством защиты информации, не содержащей сведения, составляющие государственную тайну, от несанкционированного доступа, соответствует требованиям руководящий документов "Средства вычислительной техники. Защита от несанкционированного доступа к информации. Показатели защищённости от несанкционированного доступа к информации" (Гостехкомиссия России, 1992) - по 5 классу защищенности, "Защита от несанкционированного доступа к информации. Часть 1. Программное обеспечение средств защиты информации. Классификация по уровню контроля отсутствия недекларированных возможностей" (Гостехкомиссия России, 1999) - по 4 уровню контроля и технических условий ТУ 4012-028-11443195-2010, а также может использоваться при создании автоматизированных систем до класса защищенности 1Г включительно и для защиты информации в информационных системах персональных данных до 1 класса включительно.

vGate R2

vGate R2 - сертифицированное средство защиты информации от несанкционированного доступа и контроля выполнения ИБ-политик для виртуальной инфраструктуры на базе систем VMware vSphere 4 и VMware vSphere 5.S R2 - версия продукта, применимая для защиты информации в виртуальных инфраструктурах государственных компаний, к ИС которых предъявляются требования по использованию СЗИ с высоким уровнем сертификации.

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

Способствует противодействию ошибкам и злоупотреблениям при управлении виртуальной инфраструктурой.

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

<#"783809.files/image017.gif"> <#"783809.files/image018.gif"> <#"783809.files/image019.gif"> <#"783809.files/image020.gif"> Рис. 13 Заявленные возможности vGate R2 Таким образом, подводя итог, приведем основные средства, которыми обладает vGate R2 для защиты датацентра сервис-провайдера от внутренних угроз, исходящих со стороны собственных администраторов: · Организационное и техническое разделение полномочий администраторов vSphere · Выделение отдельной роли администратора ИБ, который будет управлять безопасностью ресурсов датацентра на базе vSphere · Разделение облака на зоны безопасности, в рамках которых действуют администраторы с соответствующим уровнем полномочий · Контроль целостности виртуальных машин · Возможность в любой момент получить отчет о защищенности инфраструктуры vSphere, а также провести аудит событий ИБ В принципе, это практически все что нужно, чтобы защитить инфраструктуру виртуального датацентра от внутренних угроз с точки зрения именно виртуальной инфраструктуры. Безусловно, вам также потребуется защита на уровне оборудования, приложений и гостевых ОС, но это уже другая проблема, которая также решаема средствами продуктов компании Код Безопасности <#"783809.files/image021.gif"> Рис. 14. Структура сервера. Для обеспечения безопасности на подобном объекте необходимо обеспечить безопасность, согласно Таблице 2. Для этого я предлагаю использовать программный продукт vGate R2. Он позволит решить такие задачи, как: · Усиленная аутентификация администраторов виртуальной инфраструктуры и администраторов информационной безопасности. · Защита средств управления виртуальной инфраструктурой от НСД. · Защита ESX-серверов от НСД. · Мандатное управление доступом. · Контроль целостности конфигурации виртуальных машин и доверенная загрузка. · Контроль доступа администраторов ВИ к данным виртуальных машин. · Регистрация событий, связанных с информационной безопасностью. · Контроль целостности и защита от НСД компонентов СЗИ. · Централизованное управление и мониторинг. Таблица 2. Соответствие необходимости обеспечения безопасности для модели PaaS Сертификат ФСТЭК России (СВТ 5, НДВ 4) позволяет применять продукт в автоматизированных системах уровня защищенности до класса 1Г включительно и в информационных системах персональных данных (ИСПДн) до класса К1 включительно. Стоимость данного решения составит 24 500 рублей за 1 физический процессор на защищаемом хосте. Помимо этого для защиты от инсайдеров потребуется установка охранной сигнализации. Данные решения достаточно богато предоставлены на рынке защиты серверов. Цена подобного решения с ограничением доступа в контролируемую зону, системой сигнализации и видеонаблюдения колеблется от 200 000 рублей и выше Для примера возьмём сумму 250 000 рублей. Для защиты виртуальных машин от вирусных инфекций, на одном ядре сервера будет запущен McAfee Total Protection for Virtualization. Стоимость решения составляет от 42 200 рублей. Для предотвращения потери данных на хранилищах будет использоваться система Symantec Netbackup. Она позволяет надёжно провести резервное копирование информации и образов систем. Итоговая стоимость реализации подобного проекта составит: Реализацию подобного проектного решения на базе Microsoft можно скачать отсюда: http://www.microsoft.com/en-us/download/confirmation. aspx? id=2494 Вывод "Облачные технологии" - одна из наиболее активно развивающихся сфер IT-рынка в настоящее время. Если темпы роста технологий не уменьшатся, то к 2015 году они будут привносить в казну европейских стран более 170 млн. евро в год. В нашей стране к облачным технологиям относятся с опаской. Отчасти это вызвано закостенелостью взглядов руководства, отчасти недоверием к безопасности. Но данный вид технологий при всех их преимуществах и недостатках - это новый локомотив IT-прогресса. Приложению "с той стороны облака" совершенно неважно, формируете ли вы свой запрос на компьютере с x86 процессором Intel, AMD, VIA или составляете его на телефоне или смартфоне на базе ARM-процессора Freescale, OMAP, Tegra. Более того, ему по большому счёту будет без разницы, работаете ли вы под управлением Linux-операционок Google Chrome, OHA Android, Intel Moblin, Windows CE, Windows Mobile Windows XP/Vista/7, или используете для этого что-то ещё более экзотическое. Лишь бы запрос был составлен грамотно и понятен, а ваша система смогла "осилить" полученный ответ. Вопрос безопасности является одним из основных в облачных вычислениях и его решение позволит качественно повысить уровень услуг в компьютерной сфере. Однако в этом направлении еще очень много предстоит сделать. В нашей стране стоит начать с единого словаря терминов для всей IT-области. Выработать стандарты, опираясь на международный опыт. Выдвинуть требования к системам обеспечения защиты. Литература 1. Financial Considerations for Government Use of Cloud Computing - Правительство Австралии 2010. 2. Privacy and Cloud Computing for Australian Government Agencies 2007. Negotiating the cloud - legal issues in cloud computing agreements 2009. Журнал "Современная наука: актуальные проблемы теории и практики" 2012. Похожие работы на - Информационная безопасность в облачных вычислениях: уязвимости, методы и средства защиты, инструменты для проведения аудита и расследования инцидентов

Интервью с Алексеем Бердником, руководителем проектов департамента по работе со стратегическими клиентами Digital Design

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

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

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

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

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

С чем еще связаны риски перехода в облако?

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

Также существуют функциональные атаки на элементы облака. Для защиты них для каждой части облака необходимо использовать следующие средства защиты: для прокси – эффективную защиту от DoS-атак, для веб-сервера - контроль целостности страниц, для сервера приложений - экран уровня приложений, для СУБД - защиту от SQL-инъекций, для системы хранения данных – правильные бэкапы (резервное копирование), разграничение доступа. В отдельности каждые из этих защитных механизмов уже созданы, но они не собраны вместе для комплексной защиты облака, поэтому задачу по интеграции их в единую систему нужно решать во время создания облака.

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

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

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

Угрозы безопасности всегда порождают решения, способные их предотвратить. Какие из них наиболее эффективные?

– Один из наиболее эффективных способов защиты данных – это шифрование. Провайдер, предоставляющий доступ к данным, должен шифровать информацию клиента, хранящуюся в ЦОД, а также, в случае отсутствия необходимости, безвозвратно удалять. При передаче даже зашифрованные данные должны быть доступны только после аутентификации. Кроме того, доступ к данным следует осуществлять только через надежные протоколы AES, TLS, IPsec. Также более высокой надежности позволит достичь использование токенов и сертификатов при аутентификации. При авторизации также рекомендуется использовать LDAP (Lightweight Directory Access Protocol) и SAML (Security Assertion Markup Language) для прозрачного взаимодействия провайдера с системой идентификации. Кроме того, виртуальные сети должны быть развернуты с применением таких технологий как VPN (Virtual Private Network), VLAN (Virtual Local Area Network) VPLS (Virtual Private LAN Service).

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

Смерть Мерлина

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

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

Изначально облако было только одно - именно этим символом традиционно обозначали сеть Интернет. Это облако обозначало совокупность всех компьютеров, объединенных протоколом IP и имеющих собственный IP-адрес. Со временем в Интернет начали выделять серверные фермы, которые устанавливались у провайдеров и на которых базировались веб-проекты. При этом для обеспечения высокой нагрузки и отказоустойчивости наиболее крупные веб-системы становились многоуровневыми и распределенными.

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

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

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

Облачные вычисления в основном связывают с арендой приложений, определяя три типа таких услуг: IaaS - инфраструктура как сервис, PaaS - платформа как сервис и SaaS - программное обеспечение как сервис. Иногда и услуги "безопасность как сервис" также сокращают до SaaS, однако, чтобы не путать облачные услуги безопасности с арендой ПО лучше называть ее ISaaC - Information Security as a Cloud. Такие услуги также начинают предоставляться. Однако не следует путать аутсорсинг приложений и облачные вычисления, поскольку облака могут быть внутрикорпоративные, публичные и гибридные. У каждого из этих типов облаков есть свои особенности при организации системы защиты.

Три шага Вишну

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

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

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

Функциональные атаки на элементы облака . Этот тип атак связан с многослойностью облака, общим принципом безопасности, что общая защита системы равна защите самого слабого звена. Так успешна DoS-атака на обратный прокси, установленный перед облаком, заблокирует доступ ко всему облаку, не смотря на то, что внутри облака все связи будут работать без помех. Аналогично SQL-инъекция, прошедшая через сервер приложений даст доступ к данным системы, не зависимо от правил доступа в слое хранения данных. Для защиты от функциональных атак для каждого слоя облака нужно использовать специфичные для него средства защиты: для прокси - защиту от DoS-атак, для веб-сервер - контроль целостности страниц, для сервера приложений - экран уровня приложений, для слоя СУБД - защиту от SQL-инъекций, для системы хранения - резервное копирование и разграничение доступа. В отдельности каждые из этих защитных механизмов уже созданы, но они не собраны вместе для комплексной защиты облака, поэтому задачу по интеграции их в единую систему нужно решать во время создания облака.

Атаки на клиента . Этот тип атак отработан в веб-среде, но он также актуален и для облака, поскольку клиенты подключаются к облаку, как правило, с помощью браузера. В него попадают такие атаки как Cross Site Scripting (XSS), перехваты веб-сессий, воровство паролей, "человек посредине" и другие. Защитой от этих атак традиционно является строгая аутентификации и использование шифрованного соединения с взаимной аутентификацией, однако не все создатели "облаков" могут себе позволить столь расточительные и, как правило, не очень удобные средства защиты. Поэтому в этой отрасли информационной безопасности есть еще нерешенные задачи и пространство для создания новых средств защиты.

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

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

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

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

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

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

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

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

За седьмым небом

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

Возможно, именно эта легенда и подвигла создателей компании Trend Micro назвать один из своих проектов по защите облаков Cloud Nine - девятое облако. Это ведь явно выше седьмого. Впрочем, сейчас этим именем названы самые разнообразные вещи: песни, детективы, компьютерные игры, однако вполне возможно, что это имя было навеяно христианской легендой Павла.

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

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

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

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

Какие же еще защитные механизмы можно использовать для защиты облаков? Вопрос пока остается открытым.

2019

McAfee: 19 передовых практик в сфере облачной безопасности в 2019 году

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

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

2015: Forrester: Почему заказчики недовольны поставщиками облака?

Непрозрачное облако

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

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

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

«Среди всех сложностей сегодняшнего облака кроются и досадные изъяны, - пишет Лайлак Шёнбек (Lilac Schoenbeck), вице-президент по сопровождению и маркетингу продукта iland. - Столь важные метаданные не сообщаются, существенно тормозя принятие облака, и всё же организации строят планы роста исходя из допущения безграничности облачных ресурсов».

Где же ключ к достижению гармонии деловых отношений? Вот что нужно знать VAR’ам, чтобы постараться уладить проблемы и привести стороны к примирению.

Невнимание к клиентам

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

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

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

Слишком много секретов

Нежелание поставщика предоставлять всю информацию не только раздражает заказчиков, но часто стоит им денег.

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

«Отсутствие ясных данных о параметрах использования облака приводит к проблемам производительности, затруднениям отчетности перед руководством о реальной стоимости использования, оплате за ресурсы, так и не потребленные пользователями, и непредвиденным счетам», - констатирует Forrester.

А где метаданные?

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

Участники опроса отметили, что получаемые ими метаданные об облачных рабочих нагрузках обычно бывают неполными. Почти половина компаний ответила, что данные о соблюдении регулятивных норм отсутствуют, 44% указали на отсутствие данных о параметрах использования, 43% - ретроспективных данных, 39% - данных по безопасности, и 33% - данных биллинга и стоимости.

Вопрос прозрачности

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

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

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

Соблюдение регулятивных норм

Как ни крути, организации несут ответственность за все свои данные, будь то на локальных СХД или отправленные в облако.

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

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

Проблемы соответствия

Более 60% опрошенных компаний ответили, что проблемы соблюдения регулятивных требований ограничивают дальнейшее принятие облака.

Главные проблемы таковы:

• 55% компаний, связанных такими требованиями, ответили, что труднее всего для них реализовать надлежащие средства контроля.
• Примерно половина говорит, что им трудно понять уровень соответствия требованиям, обеспечиваемый их поставщиком облака.
• Еще половина респондентов ответила, что им трудно получить необходимую документацию от провайдера о соблюдении этих требований, чтобы пройти аудит. И 42% затрудняются получить документацию о соблюдении ими самими требований в отношении рабочих нагрузок, запущенных в облаке.

Проблемы миграции

Похоже, что процесс перехода (on-boarding) - еще одна область общей неудовлетворенности: чуть более половины опрошенных компаний ответили, что их не удовлетворяют процессы миграции и поддержки, которые предложили им поставщики облака.

Из 51% неудовлетворенных процессом миграции 26% ответили, что это заняло слишком много времени, и 21% пожаловались на отсутствие живого участия со стороны персонала провайдера.

Более половины были также не удовлетворены процессом поддержки: 22% указали на долгое ожидание ответа, 20% - недостаточные знания персонала поддержки, 19% - на затянувшийся процесс решения проблем, и 18% получили счета с более высокой, чем ожидалось, стоимостью поддержки.

Препятствия на пути в облако

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

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

2014

• Роль ИТ-подразделений постепенно меняется: перед ними стоит задача приспособиться к новым реалиям облачных ИТ. ИТ-подразделения должны рассказывать сотрудникам о проблемах безопасности, разрабатывать комплексные политики по управлению данными и по соблюдению законодательных требований, разрабатывать рекомендации по внедрению облачных сервисов и устанавливать правила относительно того, какие данные можно хранить в облаке, а какие – нет.
• ИТ-подразделения способны выполнить поставленную перед ними миссию по защите корпоративных данных и одновременно выступать в роли инструмента в реализации "Теневых ИТ", реализуя меры по обеспечению безопасности данных, например, внедряя подход `encryption-as-a-service` ("шифрование в виде сервиса"). Подобный подход позволяет ИТ-отделам централизованно управлять защитой данных в облаке, обеспечивая другим подразделениям компании возможность самостоятельно находить и пользоваться облачными сервисами по необходимости.
• По мере того, как всё больше компаний хранят свои данные в облаке, а их сотрудники всё активнее пользуются облачными сервисами, ИТ-подразделениям необходимо уделять больше внимания реализации более эффективных механизмов для контроля за пользовательским доступом, таких как многофакторная аутентификация. Это особенно актуально для компаний, которые обеспечивают третьим лицам и поставщикам доступ к своим данным в облаке. Решения многофакторной аутентификации могут управляться централизованно и обеспечивать более защищенный доступ ко всем приложениям и данным, где бы они ни размещались – в облаке, или на собственном оборудовании компании.

Данные Ponemon и SafeNet

Большинство ИТ-организаций находятся в неведении относительно того, каким образом осуществляется защита корпоративных данных в облаке – в результате компании подвергают рискам учетные записи и конфиденциальную информацию своих пользователей. Таков лишь один из выводов недавнего исследования осени 2014 года, проведённого институтом Ponemon по заказу SafeNet . В рамках исследования, озаглавленного "Проблемы управления информацией в облаке: глобальное исследование безопасности данных", во всём мире было опрошено более 1800 специалистов по информационным технологиям и ИТ-безопасности.

В числе прочих выводов, исследование показало, что хотя организации всё активнее используют возможности облачных вычислений, ИТ-подразделения корпораций сталкиваются с проблемами при управлении данными и обеспечении их безопасности в облаке. Опрос показал, что лишь в 38% организаций четко определены роли и ответственности за обеспечение защиты конфиденциальной и другой чувствительной информации в облаке. Усугубляет ситуацию то, что 44% корпоративных данных, хранящихся в облачном окружении, неподконтрольны ИТ-подразделениям и не управляются ими. К тому же более двух третей (71%) респондентов отметили, что сталкиваются с всё новыми сложностями при использовании традиционных механизмов и методик обеспечения безопасности для защиты конфиденциальных данных в облаке.

С ростом популярности облачных инфраструктур повышаются и риски утечек конфиденциальных данных Около двух третей опрошенных ИТ-специалистов (71%) подтвердили, что облачные вычисления сегодня имеют большое значение для корпораций, и более двух третей (78%) считают, что актуальность облачных вычислений сохранится и через два года. Кроме того, по оценкам респондентов около 33% всех потребностей их организаций в информационных технологиях и инфраструктуре обработки данных сегодня можно удовлетворить с помощью облачных ресурсов, а в течение следующих двух лет эта доля увеличится в среднем до 41%.

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

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

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

Более двух третей (71%) респондентов отметили, что защищать конфиденциальные данные пользователей, хранящиеся в облаке, с помощью традиционных средств и методов обеспечения безопасности становится всё сложнее, и около половины (48%) отмечают, что им становится всё сложнее контролировать или ограничивать для конечных пользователей доступ к облачным данным. В итоге более трети (34%) опрошенных ИТ-специалистов заявили, что в их организациях уже внедрены корпоративные политики, требующие в качестве обязательного условия для работы с определёнными сервисами облачных вычислений применения таких механизмов обеспечения безопасности как шифрование. Семьдесят один (71) процент опрошенных отметили что возможность шифрования или токенизации конфиденциальных или иных чувствительных данных имеет для них большое значение, и 79% считают, что значимость этих технологий в течение ближайших двух лет будет повышаться.

Отвечая на вопрос, что именно предпринимается в их компаниях для защиты данных в облаке, 43% респондентов сказали, что в их организациях для передачи данных используются частные сети. Примерно две пятых (39%) респондентов сказали, что в их компаниях для защиты данных в облаке применяется шифрование, токенизация и иные криптографические средства. Еще 33% опрошенных не знают, какие решения для обеспечения безопасности внедрены в их организациях, и 29% сказали, что используют платные сервисы безопасности, предоставляемые их поставщиками услуг облачных вычислений.

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

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

2013: Исследование Cloud Security Alliance

Cloud Security Alliance (CSA), некоммерческая отраслевая организация, продвигающая методы защиты в облаке, недавно обновила свой список главных угроз в отчете, озаглавленном «Облачное зло: 9 главных угроз в облачных услугах в 2013 году».

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

Итак, главные угрозы…

Кража данных

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

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

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

Подобно тому как опытный путешественник, опасаясь ограблений, не хранит все деньги и ценности в одном месте,

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

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

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

2. применять программы обогащения труда и ротации кадров;

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

4. устанавливать работникам скидки на продукцию, выпускаемую компанией, в которой они работают;

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

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

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

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

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

ЗАКЛЮЧЕНИЕ

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

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

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

Отправить свою хорошую работу в базу знаний просто. Используйте форму, расположенную ниже

Студенты, аспиранты, молодые ученые, использующие базу знаний в своей учебе и работе, будут вам очень благодарны.

Подобные документы

Сущность, формы, принципы и системы оплаты труда. Анализ фонда оплаты труда на примере в АО "НКМЗ". Методы вознаграждения работников, применяемые на предприятии. Направления по усовершенствованию системы оплаты и мотивации труда в условия рынка.

Анализ видов деятельности ООО УМТС "Сплав", характеристика системы организации учета оплаты труда. Система заработной платы как необходимый элемент организации оплаты труда. Особенности методов мотивации труда работников, структура фонда заработной платы.

курсовая работа, добавлен 01.09.2012


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

курсовая работа, добавлен 18.05.2010


Рассмотрение форм, источников формирования фондов оплаты труда, систем премирования и поощрения работников. Характеристика производственно-хозяйственной деятельности ПО "Пекарь": анализ себестоимости продукции, рентабельности, организации и оплаты труда.

дипломная работа, добавлен 25.05.2010


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

дипломная работа, добавлен 08.09.2010


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

дипломная работа, добавлен 22.12.2012


Сущность и принципы оплаты труда в рыночной экономике. Современные формы и системы оплаты труда. Анализ оплаты труда в ООО "Сигма" г. Кострома. Анализ системы оплаты труда работников. Совершенствование системы оплаты труда на исследуемом предприятии.

дипломная работа, добавлен 11.04.2012

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

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

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

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

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

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

Нормативы, подтверждающие перечисленные ранее функции, содержат­ся в ТК РФ и, как правило, фиксируются в трудовых и коллективных дого­ворах, которые заключает организация со своими наемными работниками.

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

Форма оплаты труда. Существуют две основные формы оплаты труда: повременная и сдельная. Повременная оплата предполагает расчет заработ­ной платы исходя из стоимости одного часа работы или оклада за фактиче­ски отработанное время. Эта форма заработной платы применяется при оп­лате труда специалистов и руководителей, так как они не производят кон­кретную продукцию, учитываемую штуками, метрами и килограммами. Их труд измеряется затраченным на свою работу временем.

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

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

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

Длительность расчетного периода. Длительность расчетного периода - частота выплат. Оплата труда может быть ежедневной, еженедельной, еже­месячной.

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

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

■ система оплаты должна ориентировать работника на достижение нужного предприятию результата, поэтому размер заработной пла­ты связывается с показателями эффективности работы всей органи­зации (прибыль, объем продаж, выполнение плана);

■ система оплаты должна быть средством управления персоналом, для этого руководителю необходимо иметь возможность как материального поощрения, так и наказания;

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

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

Однако в последнее время многие организа­ции приходят к использованию схемы оплаты труда, которая предполагает разделение выплат персоналу на три части.

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

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

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

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

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

Библиографическое описание:

Нестеров А.К. Мотивация труда персонала в организации [Электронный ресурс] // Образовательная энциклопедия сайт

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

Понятие и сущность мотивации труда

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

Можно видеть только результат мотивации – поведение человека.

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

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

Подходы к определению понятия трудовой мотивации

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

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

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

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

Теории мотивации персонала

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

Содержательные и процессуальные теории мотивации

1. Теория потребностей А. Маслоу
Потребности
1.1. Физиологические потребности	– качественная пища; – чистая вода; – хорошие жилищные условия; – благоприятные условия отдыха.	– справедливая зарплата; – ссуды на жилье; – санаторные путевки; – социальный пакет.
1.2. Потребности в безопасности	– защита от физических и моральных опасностей со стороны окружающей среды; – уверенность в том, что физиологические потребности будут удовлетворены.	– хороший морально-психологический климат в коллективе; – демократический стиль управления руководителя; – страхование от болезней; – помощь в экстремальных ситуациях
1.3. Социальные потребности	– общение; – подражание; – сопричастность; – солидарность, поддержка, дружба, взаимовыручка.	– возможность общаться; – демократический стиль руководства; – равные возможности, "равенство шансов"; – доска почета; – вынесение благодарностей; – признание заслуг; – справедливость во всем (в распределении работ, оценках, вознаграждениях); – программы культурно-оздоровительных мероприятий.
1.4. Потребности в признании и уважении	– самоуважение; – личные достижения; – компетентность; – уважение со стороны окружающих; – признание.	– достойная зарплата; – расширение полномочий; – персональные блага; – рост числа подчиненных; – всеобщее признание и уважение.
1.5. Потребности самовыражения	–реализация потенциальных возможностей; – рост личности; – призвание; – самовыражение; – любознательность; – творчество; – изобретательство; – рационализаторство; – занятие наукой.	– участие в управлении и принятии решений; – участие в проектных группах; – широкие возможности для обучения и повышения квалификации; – активный рост карьеры; – предоставление работы по интересам, по призванию; – профессиональная ориентация; – повышение творческого характера труда; – учет личных качеств и способностей работника; – премии за новаторство, изобретения, открытия; – выдвижение на государственные и международные премии.
2. Теория существования, связи и роста К. Альдерфера
Потребности
2.1. Потребности существования: физиологические, обеспечение безопасности, оплата труда	– пища, вода, жилье, отдых; – защита от физических опасностей; – уверенность в том, что физиологические потребности будут удовлетворены.	– достаточный уровень зарплаты; – оплата жилья; – социальный пакет; – система пенсионного обеспечения; – страхование от болезней.
2.2. Потребности связи: установление контактов, уважение, оценка личности	– общение; – сопричастность; – поддержка, дружба, взаимовыручка.	– возможность общаться; – благоприятный психологический климат в коллективе; – равные возможности; – вынесение благодарностей; – признание заслуг.
2.3. Потребности роста: развитие творческого потенциала, самореализация	– уважение, признание; – реализация потенциальных возможностей; – рост личности; – самовыражение, творчество.	– всеобщее признание и уважение; – право реализовать свои предложения; – возможности обучения и повышения квалификации; – премии за изобретения.
3. Теория приобретенных потребностей Д. МакКлелланда
Потребности
3.1. Потребность власти	– желание воздействовать на других людей, чувствовать себя полезным и значимым	– участие в управлении и принятии решений; – расширение полномочий; – рост числа подчиненных.
3.2. Потребность успеха	– участие в перспективных работах; – достижение цели; – престиж; – развитие карьеры.	Предоставление инициативы, широких полномочий; Поощрение за результаты; Участие в успехе; Международное признание; Присвоение звания "Лучший сотрудник года".
3.3. Потребность причастности	– общение; – подражание; – сопричастность; – солидарность, поддержка, дружба.	– возможность общаться; – благоприятный социальный микроклимат; – участие в управлении и принятии решений; – проведение совещаний; – оказание помощи другим; – деловые контакты.
4. Теория двух факторов Ф. Герцберга
Потребности
4.1. Гигиенические	– продвижение по службе; – признание и одобрение результатов работы; – высокая степень ответственности; – возможности творческого и делового роста.	– хороший морально-психологический климат; – нормальные условия работы; – справедливая зарплата; – доброжелательная атмосфера; – умеренный контроль за работой.
4.2. Мотивации		– предоставление инициативы, широких полномочий; – поощрение за результаты; – участие в успехе; – планирование карьеры; – справедливое вознаграждение; – предоставление высокой степени ответственности; – учеба и повышение квалификации.
Процессуальные теории мотивации
5. Теория ожиданий В. Врума
Потребности
5.1. Затраты – результаты	– значимость задачи; – выполнимость задания; – проведение необходимых консультаций.	– оценка результатов
5.2. Результаты вознаграждения	– определенность и своевременность вознаграждения.	– доверие к руководителю; – эффективность работы предприятия.
5.3. Валентность	– вознаграждение за достигнутую результативность труда.	– гарантия вознаграждения; – точное соответствие вознаграждения результатам работы.
6. Теория справедливости С. Адамса
Потребности
	– соответствие вознаграждения среднему значению вознаграждения других специалистов за аналогичную работу.	Применение компенсационной оплаты труда по "рыночной цене" работника.
7. Концепция партисипативного управления
Потребности
	– осознание важности и значимости своего труда для развития предприятия	– участие в управлении и принятии решений; – участие в проектах; – самоконтроль; – личная и групповая ответственность за результаты.

Источник: Виханский, О. С. Менеджмент: учебник / О. С. Виханский, А. И. Наумов. – 5-е изд., стереотип. – М.: Магистр: ИНФРА -М, 2012.

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

Методы мотивации труда персонала в организации

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

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

Методы мотивации представлены на схеме

Методы мотивации труда персонала

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

Прямые формы экономических методов:

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

Косвенные формы экономических методов:

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

Организационные методы:

1. Мотивация интересными целями по основной работе сотрудников;
2. Мотивация обогащением содержательного наполнения трудовой деятельности;
3. Мотивация участием в делах организации.

Морально-психологические методы:

1. Гордость за порученную и выполненную работу;
2. Ответственность за результаты работы;
3. Вызов, возможность показать свои способности;
4. Признание авторства результата сделанной работы или проекта;
5. Высокая оценка, может быть личной или публичной.

Требования к методам мотивации труда персонала организации

Направления совершенствования и повышения эффективности мотивации труда персонала в организации

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

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

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

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

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

Взаимозависимость мотивации сотрудников и результатов экономической деятельности организации является основой предприятия.

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

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

1. Помещение различных записей о достижениях работника в его личное дело.
2. Устная благодарность от лица руководства фирмы.
3. Дополнительное обучение за счет организации.
4. Оплаченное приглашение на обед в ресторане, которое компания выделяет сотруднику.
5. Гибкий график рабочего времени.
6. Предоставление автостоянки для парковки автомобиля и бесплатного бензина.
7. Более высокое качество оснащения рабочего места, а также приобретение нового оборудования для лучших работников по итогам года.
8. Помещение фотографии в стенгазету.
9. Сувенир со специальной пометкой "Лучший работник".
10. Размещение благодарных откликов клиентов таким образом, чтобы все могли их видеть.
11. Подписка на периодические специализированные издания.

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

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

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

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

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

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

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

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

Заработная плата - важнейшая часть системы оплаты и стимулирования труда, один из инструментов воздействия на эффективность труда работника. Это вершина системы стимулирования персонала предприятия, но при всей значимости заработная плата в большинстве успешных зарубежных фирм не превышает 70% дохода работника, остальные 30% дохода участвуют в распределении прибыли.

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

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

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

Наибольшее распространение на предприятиях различных форм собственности получили две формы тарифной системы оплаты труда:

Сдельная - за каждую единицу продукции или выполненный объем работ;

Повременная - за нормативное отработанное время, которое предусматривается тарифной системой.

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

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

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

Квалификационного уровня работника;

Коэффициента трудового участия (КТУ);

Фактически отработанного времени.

Квалификационный уровень работника предприятия устанавливается всем членам трудового коллектива.

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

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

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

Подпишитесь на новости

---