• Заменяем платный гудок на стандартный
• Управление в Интернете совершенствуется
• Телефон "Самсунг Ля Флер" (Samsung La Fleur): технические характеристики и отзывы Самсунг ля флер сенсорный андроид
• Прошивка Lenovo P780 (прошивка радиомодуля)
• Не идет звук через HDMI на телевизор с компьютера
• Как отключить тачпад на ноутбуке?
• • Ты создаёшь тест • Создай себе сам тест
• Если нет отформатированных заголовков
• Полное удаление антивируса ESET NOD32 с компьютера
• Последовательное и параллельное соединение резисторов Как понизить сопротивления переменного резистора

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

Сказка - ложь, да в ней намек

Начало этой истории можно рассказывать, как известную сказку. Было в фирме три админа: старший умный был детина, средний был и так и сяк, младший вовсе был… стажером-эникейщиком. Заводил юзеров в Active Directory и крутил хвосты цискам. Пришло время компании расширяться, и призвал царь, то есть босс, свое админское воинство. Желаю, говорит, новые веб-сервисы для наших клиентов, собственное файловое хранилище, управляемые базы данных и виртуальные машины для тестирования софта.

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

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

Средненький подал идею разместить всю IT-систему в дата-центре провайдера, на его каналах. На том и порешили. Однако тут нашу троицу поджидало несколько неожиданностей, не все из которых оказались приятными.

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

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

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

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

Безопасность в Яндекс.Облаке

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

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

Физический уровень

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

Кроме того, аппаратные средства Облака физически отделены от «большого Яндекса»: они расположены в разных стойках, но в точности так же проходят регулярное регламентное обслуживание и замену комплектующих. На границе этих двух инфраструктур используются аппаратные файрволы, а внутри Облака - программный Host-based Firewall. Кроме того, на коммутаторах Top-of-the-rack применяется система управления доступом ACL (Access Control List), что значительно повышает безопасность всей инфраструктуры. Яндекс на постоянной основе проводит сканирование Облака извне в поисках открытых портов и ошибок в конфигурации, благодаря чему потенциальную уязвимость можно распознать и ликвидировать заранее. Для работающих с ресурсами Облака сотрудников реализована централизованная система аутентификации по ключам SSH с ролевой моделью доступа, а все сессии администраторов логируются. Такой подход является частью повсеместно применяемой Яндексом модели Secure by default: безопасность закладывается в IT-инфраструктуру еще на этапе ее проектирования и разработки, а не добавляется потом, когда все уже запущено в эксплуатацию.

Инфраструктурный уровень

На уровне «аппаратно-программной логики» в Яндекс.Облаке используются три инфраструктурных сервиса: Compute Cloud, Virtual Private Cloud и Yandex Managed Services. А теперь о каждом из них чуть подробнее.

Compute Cloud

Этот сервис предоставляет масштабируемые вычислительные мощности для различных задач, таких как размещение веб-проектов и высоконагруженных сервисов, тестирование и прототипирование или временная миграция IT-инфраструктуры на период ремонта либо замены собственного оборудования. Управлять сервисом можно через консоль, командную строку (CLI), SDK или API.

Безопасность Compute Cloud базируется на том, что все клиентские виртуальные машины используют минимум два ядра, а при распределении памяти не применяется overcommitment. Поскольку в этом случае на ядре исполняется только клиентский код, система не подвержена уязвимостям вроде L1TF, Spectre и Meltdown или атакам на побочные каналы.

Кроме того, Яндекс использует собственную сборку Qemu/KVM, в которой отключено все лишнее, оставлен только минимальный набор кода и библиотек, необходимых для работы гипервизоров. При этом процессы запускаются под контролем инструментария на базе AppArmor, который с использованием политик безопасности определяет, к каким системным ресурсам и с какими привилегиями может получить доступ то или иное приложение. AppArmor, работающий поверх каждой виртуальной машины, уменьшает риск того, что клиентское приложение сможет получить доступ из ВМ к гипервизору. Для получения и обработки логов Яндекс выстроил процесс поставки данных от AppArmor и песочниц в собственный Splunk.

Virtual Private Cloud

Сервис Virtual Private Cloud позволяет создавать облачные сети, используемые для передачи информации между различными ресурсами и их связи с интернетом. Физически этот сервис поддерживается тремя независимыми ЦОД. В этой среде логическая изоляция осуществляется на уровне многопротокольного взаимодействия - MPLS. При этом Яндекс постоянно проводит fuzzing стыка SDN и гипервизора, то есть со стороны виртуальных машин во внешнюю среду непрерывно направляется поток неправильно сформированных пакетов с целью получить отклик от SDN, проанализировать его и закрыть возможные бреши в конфигурации. Защита от DDoS-атак при создании виртуальных машин включается автоматически.

Yandex Managed Services

Yandex Managed Services - это программное окружение для управления различными сервисами: СУБД, кластерами Kubernetes, виртуальными серверами в инфраструктуре Яндекс.Облака. Здесь большую часть работы по обеспечению безопасности сервис берет на себя. Все резервное копирование, шифрование резервных копий, Vulnerability management и так далее обеспечивается автоматически программными средствами Яндекс.Облака.

Инструменты реагирования на инциденты

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

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

И последнее, но не самое маловажное пожелание заключалось в том, чтобы все инструменты имели открытый исходный код. Этим критериям полностью соответствует связка AppArmor + Osquery, которую и решено было использовать в Яндекс.Облаке.

AppArmor

AppArmor уже упоминался выше: это программный инструмент упреждающей защиты, основанный на настраиваемых профилях безопасности. Профили используют технологию разграничения доступа на основании меток конфиденциальности Mandatory Access Control (MAC), реализуемую с помощью LSM непосредственно в самом ядре Linux начиная с версии 2.6. Разработчики Яндекса остановили свой выбор на AppArmor по следующим соображениям:

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

Osquery

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

С помощью Osquery можно собирать информацию о состоянии различных компонентов операционной системы, аккумулировать ее, трансформировать в стандартизированный формат JSON и направлять выбранному получателю. Этот инструмент позволяет писать и направлять приложению стандартные SQL-запросы, которые сохраняются в базе данных rocksdb. Можно настроить периодичность и условия выполнения или обработки этих запросов.

В стандартных таблицах уже реализовано много возможностей, например можно получить список запущенных в системе процессов, установленных пакетов, текущий набор правил iptables, сущности crontab и прочее. «Из коробки» реализована поддержка получения и парсинга событий из системы аудита ядра (используется в Яндекс.Облаке для обработки событий AppArmor).

Сам Osquery написан на C++ и распространяется с открытыми исходниками, можно их модифицировать и как добавлять новые таблицы в основную кодовую базу, так и создавать свои расширения на C, Go или Python.

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

Выводы

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

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

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

ГРИГОРЬЕВ1 Виталий Робертович, кандидат технических наук, доцент КУЗНЕЦОВ2 Владимир Сергеевич

ПРОБЛЕМЫ ВЫЯВЛЕНИЯ УЯЗВИМОСТЕЙ В МОДЕЛИ ОБЛАЧНЫХ ВЫЧИСЛЕНИЙ

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

Целью данной статьи является обзор подходов к построению концептуальной модели облачных вычислений, приведенной в документе «NIST Cloud Computing Reference Architecture», и сравнение взглядов ведущих в этой области организаций на уязвимости в условиях данной модели вычислений, а также основных игроков на рынке создания облачных систем.

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

Пять основных характеристик

Самообслуживание по требованию

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

Оперативная эластичность - 1Т-

ресурсы могут оперативно масштабироваться в любую сторону по мере надобности.

Пул ресурсов - 1Т-ресурсы совместно используются различными приложениями и пользователями в несвязанном режиме.

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

Три сервисных модели

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

Платформа как услуга (PaaS) - платформа для разработки и развертывания приложений предоставляется как услуга разработчикам для создания, развертывания и управления приложениями SaaS. Обычно платформа включает в себя базы данных, ПО среднего слоя и инструменты для разработки, причем все это предоставляется как услуга через Интернет. PaaS часто ориентируется на язык программирования или API, например, Java или Python. Виртуализованная кластерная архитектура распределенных вычислений часто служит базой для систем

1 - МГТУ МИРЭА, доцент кафедры Информационная безопасность;

2 - Московский Государственный Университет Радиоэлектроники и Автоматики (МГТУ МИРЭА), студент.

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

Четыре модели развертывания

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

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

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

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

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

На рис. 1 представлена концептуальная модель облачных вычислений согласно документу «NIST Cloud Computing Reference Architecture». Согласно представленной на рис. 1 модели в стандарте выделяются основные участники облачной системы: облачный потребитель, облачный провайдер, облачный аудитор, облачный брокер, облачный посредник. Каждый участник - это человек или организация, выполняющий (ая) свои функции по реализации или предоставлению облачных вычислений. Облачный потребитель - лицо или организация, которая поддерживает бизнес-взаимодействие с другими ак-

Облачный потребитель

Облачный аудитор

С Аудит Л I безопасности J

I Аудит конфи- Л I денциальности J

(Аудит предостав- | ляемых услуг J

Облачный провайдер

Комплекс уровней

Пользовательский уровень

^ Сервис как услуга ^ ^ Платформа как услуга ^ Инфраструктура как услуга)

Уровень абстракции

Физический уровень

Облачный сервис

^ Поддержка J ^ Настройка J

Переносимость

Облачный брокер

Облачный посредник

Рис. 1. Концептуальная модель, разработанная специалистами NIST

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

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

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

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

Для адекватной оценки безопасности в облачных системах имеет смысл исследовать взгляды на угрозы данной области основных игроков рынка. Мы сравним существующие подходы к угрозам в облачных системах, представленные в документе NIST Cloud Computing Standards Roadmap с подходами, которые предлагают компании IBM, Oracle и VmWare.

Стандарт безопасности облачных вычислений, принятый Национальным институтом стандартов ^ВД США

Стандарт безопасности облачных вычислений (NIST Cloud Computing Standards Roadmap), принятый в NIST, охватывает возможные потенциальные типы атак на сервисы облачных вычислений:

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

♦ атаки, которые исходят из особенностей структуры и возможностей среды облачных вычислений для усиления и увеличения ущерба от атак;

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

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

♦ ограниченные возможности по шифрованию данных в среде с большим количеством участников;

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

♦ атаки, эксплуатирующие физическую абстракцию облачных ресурсов, и эксплуатирующие недостатки в записях и процедурах аудита;

♦ атаки на виртуальные машины, которые не были соответствующим образом обновлены;

♦ атаки, эксплуатирующие нестыковки в глобальных и частных политиках безопасности.

Также стандарт выделяет основные задачи безопасности для облачных вычислений:

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

♦ защита от «цепных» (supply chain threats) угроз; включает в себя подтверждение степени доверия и надежности сервис провайдера в той же степени, что и степень доверия используемого ПО и «железа»;

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

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

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

♦ развертывание контроля доступа и технологий обнаружения вторже-

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

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

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

Таким образом, Стандарт безопасности облачных вычислений (NIST Cloud Computing Standards Roadmap), принятый в NIST, определяет базовый список атак на облачные системы и список основных задач, которые должны

решаться посредством применения

соответствующих мер.

Сформулируем угрозы информационной безопасности облачной системы:

♦ У1 - угроза (компрометации, доступности, etc...) данным;

♦ У2 - угрозы, порождаемые особенностями структуры и возможностями архитектуры реализации распределенных вычислений;

♦ У4 - угрозы, связанные с некорректной моделью угроз;

♦ У5 - угрозы, связанные с некорректным использованием шифрования (необходимо использование шифрования в среде, где существуют несколько потоков данных);

♦ У6 - угрозы, связанные с использованием нестандартных API при разработке;

♦ У7 - угрозы виртуализации;

♦ У8 - угрозы, эксплуатирующие нестыковки в глобальных политиках безопасности.

Взгляд на проблемы обеспечения безопасности облачных вычислений, принятый в компании IBM

Документ Cloud Security Guidance IBM Recommendations for the Implementation of Cloud Security позволяет нам сделать выводы о взглядах на обеспечение безопасности, сформированных специалистами компании IBM. На основе этого документа мы можем расширить предложенный ранее список угроз, а именно:

♦ У9 - угрозы, связанные с доступом сторонних лиц к физическим ресур-сам\системам;

♦ У10 - угрозы, связанные с некорректной утилизацией (жизненный цикл) персональной информации;

♦ У11 - угрозы, связанные с нарушением региональных, национальных и интернациональных законов, касающихся обрабатываемой информации.

Подходы компаний IBM, Oracle и VmWare к обеспечению безопасности облачных вычислений

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

В табл. 1 приводятся основные классы уязвимостей, сформулированные компаниями в своих продуктах. Табл. 1 позволяет увидеть отсутствие полного покрытия угроз у исследованных компаний и сформулировать «ядро угроз», созданное компаниями в своих облачных системах:

♦ угроза данным;

♦ угрозы, основанные на структуре\ возможностях распределенных вычислений;

♦ угрозы, связанные с некорректной моделью угроз;

♦ угрозы виртуализации.

Заключение

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

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

Таблица 1. Классы уязвимостеи

Источник Декларируемые угрозы

У1 У2 У3 У4 У5 У6 У7 У8 У9 У10 У11

NIST + + + + + + + + - - -

IBM + + + + + - + - + + +

Sun/Oracle + + + + - - + - - + -

VmWare + + + + - - + - - - -

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

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

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

Литература

1. Cloud Security Guidance IBM Recommendations for the Implementation of Cloud Security, ibm.com/redbooks, November 2, 2009.

2. http://www.vmware.com/technical-resources/security/index.html.

3. NIST Cloud. Computing Reference Architecture, National Institute of Standards and. Technology, Special Publication. 500-292, September 2011.

4. NIST Cloud. Computing Standards Roadmap, National Institute of Standards and. Technology, Special Publication. 500-291, July 2011.

5. http://www.oracle.com/technetwork/indexes/documentation/index.html.

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

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

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

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

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.

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

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

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

Когда Эрик Шмит, ныне глава 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 и другие. Правда, стоит использовать те их варианты, которые могут работать в среде виртуализации - это будет эффективней.

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

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

• Как обнулить контроллер батареи ноутбука Сброс контроллера батареи
• Программа для сравнения текстовых файлов Сравнение 2х файлов
• Как подключить винчестер от компьютера к ноутбуку Подключение hdd sata к ноутбуку
• Телефоны Meizu Bluetooth - это стандарт безопасного беспроводного переноса данных между различными устройствами разного типа на небольшие расстояния
• Asc 10 pro лицензионный ключ
• Все способы зайти в админку WordPress
• Как связаться с техподдержкой Вконтакте?
• BETWEEN в T-SQL – примеры использования логического оператора Пример использования оператора BETWEEN в секции WHERE
• Первое знакомство с информационно поисковыми системами
• Создание загрузочной флешки

• Заменяем платный гудок на стандартный
• Управление в Интернете совершенствуется
• Телефон "Самсунг Ля Флер" (Samsung La Fleur): технические характеристики и отзывы Самсунг ля флер сенсорный андроид
• Прошивка Lenovo P780 (прошивка радиомодуля)
• Не идет звук через HDMI на телевизор с компьютера
• Как отключить тачпад на ноутбуке?
• • Ты создаёшь тест • Создай себе сам тест
• Если нет отформатированных заголовков
• Полное удаление антивируса ESET NOD32 с компьютера
• Последовательное и параллельное соединение резисторов Как понизить сопротивления переменного резистора