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

· Между участниками процесса предоставления ИТ-услуги и её обслуживания не существует понимания возможностей и важности применения SLA. Таким образом, данное Соглашение на данном этапе часто воспринимается как формальность, особенно в российской действительности. Между тем, SLA имеет значимую роль как для поставщика облачного сервиса, так и для клиента.

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

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

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

o Пересмотр подхода к управлению уровнем обслуживания среди топ-менеджмента компании;

o Обучение сотрудников принятым подходам или найм сотрудников с соответствующей квалификацией;

o Определение необходимых услуг, отдаваемых на аутсорсинг, и метрик по качеству их обслуживания;

o Разработка шаблонов Соглашения об уровне обслуживания и внедрение в практику компании данного подхода;

o Внедрение систем мониторинга за уровнем обслуживания в компании.

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

Для грамотного составления Соглашения об уровне обслуживания необходимо выполнение следующих основополагающих требований:

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

· Индикаторы измеряются и контролируются в отношении контрольных значений с целью определения соответствия предъявляемым требованиям.

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

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

1. Анализ требований к качеству обслуживания со стороны пользователей. Если конечными пользователями / потребителями ИТ-услуги является компания-заказчик, то предъявляемые требования формируются с её стороны. Если конечные потребители - это клиенты компании-заказчика облачных услуг, то необходимо определить их требования к качеству обслуживания.

2. Выбор наиболее подходящих индикаторов (ключевых метрик) для определения состояния качества обслуживания.

3. Определение наиболее подходящего метода измерения и мониторинга.

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

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

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

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

· Широкий доступ к сети;

· Объединение ресурсов;

· Быстрая эластичность;

· Измеряемое обслуживание

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

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

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

Однозначно трактуемый, чётко определённый SLA обладает рядом преимуществ как для потребителя, так и для провайдера:

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

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

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

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

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

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

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

ГЛАВА 3. ПРАКТИЧЕСКАЯ РЕАЛИЗАЦИЯ

3.1 Классификация объектов защиты, угроз и уязвимостей в компании ООО «Эрендай Груп»

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

Табл. 1. Объекты информационной защиты в ООО «Эрендай Груп»

Категории документов / информации	Информация ограниченного доступа
	Персональные данные	Коммерческая тайна
Договора с клиентами	Сведения о представителях заказчика и компании ООО «Эрендай Груп»	Описание работ и порядка их выполнения, стоимость работ
Договора с подрядчиками	Сведения о представителях компании ООО «Эрендай Груп» и подрядчика	Описание работ и порядка их выполнения, стоимость работ
Бриф клиента	-	Заказ на предоставление каких-либо услуг, KPI
Коммерческое предложение клиенту	-	Идеи реализации задач клиента, методы и способы реализации задач, стоимость и сроки реализации работ
Разработанное ИТ-решение	Сведения о пользователях сайта/WEB-приложения, хранящиеся и обрабатываемые в базе данных	Код разрабатываемого ИТ-решения как инновация

По форме существования информационных объектов защиты используется несколько форматов - подробный перечень объектов защиты и формы их размещения / места расположения приведены в таблице 2 ниже.



Табл. 2. Форма и места расположения информационных объектов защиты

	Бумажный носитель	Электронный вид	Электронная почта	Др. ср-ва связи	Плёнка	Устный формат
		FTP-сервер	Облачные ресурсы
ПДн сотрудников ООО «Эрендай Груп»	?	?	?	?	?		?
ПДн заказчика	?	?	?	?	?		?
ПДн пользователей		?	?
Договора с клиентами	?	?	?	?
Договора с подрядчиками	?	?	?	?
Информация о стоимости работ	?	?	?	?	?		?
Бриф клиента		?	?	?
Идеи реализации		?	?	?
Методы и способы реализации		?	?	?

Угрозы и уязвимости информационной безопасности в ООО «Эрендай Груп» при аутсорсинге ИТ-услуг. В качестве угроз и уязвимостей информационной безопасности в компании ООО «Эрендай Груп» будут рассмотрены только те, что относятся к аутсорсингу ИТ-услуг. В таблице представлено несколько детализированных угроз в соответствии с классификацией, приведённой во 2-ой главе настоящего исследования, а также уязвимости, присутствующие в настоящий момент в организации и способные повлечь за собой реализацию угроз ИБ. В таблице 3 отражены уязвимости и угрозы, относящиеся к использованию облачных сервисов и ресурсов.



Табл. 3. Угрозы и уязвимости в ООО «Эрендай Груп» при использовании облачных сервисов

	Угрозы специальных воздействий	Угрозы физического НСД	Угрозы программного НСД	Угрозы утечки информации	Угрозы социальной инженерии	Угрозы несоответствия законодательству
Уязвимости в системе безопасности облачных сервисов	Сетевые атаки; сбои и отказы; нарушение доступности	Повреждения ограждающих конструкций; нарушение доступности	Нарушение доступности	Сетевые атаки; общедоступность облачной инфраструктуры; потеря доверия к поставщику	Злоупотребления доверием потребителей облачных услуг	Нарушение доступности; несогласованность политик безопасности элементов облачной инфраструктуры
Некомпетентность сотрудников		Кража/потеря устройств	Кража/потеря устройств	Злоупотребления возможностями, предоставленными потребителям облачных услуг	Атаки на социальную инженерию
Уязвимость организации каналов обмена информацией	Сетевые атаки		Потеря управления облачными ресурсами
Ошибки управления сложными системами		Общедоступность облачной инфраструктуры	Неправильное GUI/API управление; потеря управления	Общедоступность облачной инфраструктуры
Ошибки использования ПО	Сетевые атаки; приостановка оказания облачных услуг; перегрузка систем		Незащищённое администрирование облачных услуг; потеря управления облачными ресурсами; «отказ в обслуживании»
Отсутствие регламента выбора поставщика и SLA	Потеря доверия к поставщику; приостановка оказания облачных услуг	Потеря доверия к поставщику	Потеря доверия к поставщику	Потеря доверия к поставщику	Недобросовестное исполнение обязательств поставщиками	Нарушение ФЗ №152 О персональных данных; блокировка облачного провайдера; административные и юридические проблемы

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

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

1. Составление и внедрение в компанию ООО «Эрендай Груп» на верхнем уровне следующих регламентов: выбора поставщика ИТ-услуг, использования облачных систем и ресурсов, управления доступами в облачных системах и ресурсах, пользования информацией с указанием порядка размещения критически важной информации в облачных ресурсах, обмена информацией между соответствующими лицами с помощью различных средств связи и систем;

2. Проведение работ с сотрудниками организации ООО «Эрендай Груп» по ознакомлению с вопросами обеспечения информационной безопасности предприятия, а также с составленными регламентами;

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

4. Разработка и внедрение плана по регулярному мониторингу в организации ООО «Эрендай Груп» сотрудниками действующих правил;

5. Составление и внедрение в работу с поставщиками ИТ-услуг соглашения об уровне и качестве предоставляемых услуг.

Реализация данного перечня работ позволит сократить количество уязвимостей в компании ООО «Эрендай Груп» или заменить на менее серьёзные по степени возможности реализации или последствиям уязвимости. Также предпринятые меры позволят сократить вероятность наступления таких рисковых событий, как:

1. Наличие уязвимостей в системе безопасности поставщиков ИТ-услуг; Сетевые атаки;

2. Атаки на социальную инженерию;

3. Неправильное GUI и / или API управление;

4. Кража и / или потеря устройств;

5. Физические опасности;

6. Перегрузка систем;

7. Неоценённые затраты на работу с поставщиками ИТ-услуг;

8. Блокировка поставщика в результате его несоответствия требованиям законодательства;

9. Административные и / или юридические проблемы;



3.2 Несоблюдение национального и иностранного законодательства

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

Облачные ИС, используемые в компании ООО «Эрендай Груп». В настоящий момент в компании ООО «Эрендай Груп» при работе над заказами клиентов используются следующие облачные информационные системы:

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

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

3. GitHub как инструмент ведения и реализации разработки WEB-сайтов. GitHub используется на этапе разработки сайтов и приложений для клиента в качестве места хранения исходного кода (в репозиториях) и ведения технической проектной документации (API, описание методов и пр.). К репозиториям предоставляется доступ на уровне администратора корпоративного аккаунта - таким образом, доступ к репозиторию может быть выдан как внутренним сотрудникам для реализации разработки, так и внешним подрядчикам, которые на том или ином проекте могут осуществлять разработку решения.

В компании ООО «Эрендай Груп» не проведён анализ поставщиков ИТ-услуг на предмет соответствия международным и российским регламентам и стандартам информационной безопасности, не разработаны рабочие инструкции по осуществлению работы в данных системах, в том числе о возможности и необходимости предоставления доступов тем или иным лицам и на каких условиях, а также не существует соглашения о уровне и качестве предоставления ИТ-услуг со стороны провайдеров облачных систем.

3.3 Регламент выбора поставщика ИТ-услуг и разработка SLA

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

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

Темы, в соответствии с которыми составлен список вопросов к поставщикам ИТ-услуг, представлены ниже:

1. Организационная безопасность, структура и риск-менеджмент;

2. Обязанности и обязательства;

3. Стихийные бедствия и резервные копии;

4. Юридические и административные вопросы;

5. Безопасность персонала;

6. Управление доступом;

7. Программное обеспечение;

8. Интерфейсы пользователя, управления и прикладного программирования;

9. Мониторинг и логирование;

10. Взаимодействие и портативность;

11. Масштабирование и стоимостные затраты;

12. Соблюдение национального и международного законодательств.

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

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

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

· Наличие сертификации в отношении стандартов управления рисками информационной безопасности, включая заявление о сфере применения. Среди международных стандартов к данной категории относится, например, ISO 27001, полным аналогом которого является российский стандарт ГОСТ Р ИСО/МЭК 27001. Таким образом, наличие сертификации по указанным выше стандартам является хорошим показателем для поставщика ИТ-услуг.

· Опубликованные аудиторские отчёты независимых аудиторов.

· Наличие самостоятельно проведённой оценки по отраслевому стандарту и/или передовой практике.

· И пр.

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

· Общая политика и подход к управлению рисками безопасности;

· Наличие или отсутствие контактных центров по инцидентам безопасности;

· Наличие или отсутствие критической зависимости поставщика облачных ИТ-услуг от третьих лиц;

· Соответствие передовым практикам и/или отраслевым стандартам в области управления рисками.

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

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

· Активы находятся в зоне ответственности провайдера ИТ-услуг;

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

· Перечисление примеров инцидентов, попадающих под ответственность провайдера;

· Перечень задач и обязанностей, за которые несёт ответственность заказчик.

Документы и гарантии, в которых может и должна быть отражена данная информация:

· Контракт и/или SLA, в которых упомянуты соответствующие задачи по безопасности с распределением зон ответственности;

· Приведённые классификация инцидентов и сроки реагирования на инциденты / восстановления нормальной работоспособности системы;

· Финансовая компенсация в случае наступления инцидентов безопасности соответствующими сторонами.

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

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

· Политика и меры обеспечения физической безопасности (резервное питание, огнетушители и т.д.);

· Избыточность сети, географическая распределённость, зоны доступности, контроль доступа;

· Резервные копии и механизмы обеспечения отказоустойчивости;

· Планы аварийного восстановления.

Документы и гарантии, в которых может и должна быть отражена данная информация:

· Соответствующие положения, включённые в контракт / договор и / или SLA;

· KPI по времени на восстановление облачных систем и ресурсов.

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

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

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

· Реализация экспорта гарантированных данных.

Документы и гарантии, в которых может и должна быть отражена данная информация:

· Соответствующие положения о доступе к данным в договоре и / или SLA;

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

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

Вопрос, на который необходимо получить ответ: «Как провайдер гарантирует, что его персонал работает надёжно?». Возможные ответы:

· Наличие обучения и / или сертификации ключевых позиций и ролей среди персонала провайдера;

· Проведение тестирования на проникновение (p-тест) и тестирования социальной инженерии и предоставление соответствующих результатов;

· Соблюдение стандарта или передовой практики СМИБ (система менеджмента информационной безопасности, или ISMS - Information Security Management System);

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

Документы и гарантии, в которых может и должна быть отражена данная информация:

· Сертификация и / или самооценка в соответствии со стандартами и / или передовой практикой СМИБ.

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

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

· Предоставление мер по защите от несанкционированного физического доступа;

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

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

· Соблюдение стандартов и / или передовых практик в соответствии со СМИБ.

Документы и гарантии, в которых может и должна быть отражена данная информация:

· Сертификация и / или самооценка в соответствии со стандартами и / или передовой практикой СМИБ.

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

Вопрос, на который необходимо получить ответ: «Как провайдер обеспечивает безопасность программного обеспечения и какое ПО остаётся в зоне ответственности компании-заказчика?». Возможные варианты ответа:

· Защищённый метод разработки ПО;

· Процесс управления уязвимостями (контактные точки для уязвимостей, время для отчёта и т.д.);

· Обучение разработчиков - сотрудников компании-поставщика ИТ-услуг;

· Процедуры выкатки исправлений и обновлений;

· Использование стандартов и / или передовых практик (например, в соответствии с ISO 27034 или его российским аналогом ГОСТ Р ИСО/МЭК 27034-1-2014).

Документы и гарантии, в которых может и должна быть отражена данная информация:

· Информация о прошлых уязвимостях соответствующего программного обеспечения;

· Отчёты о наличии уязвимостей;

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

· Меры по обеспечению безопасности ПО (например, использование BSIMM или OpenSAMM).

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

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

· Перечисление методов аутентификации в GUI и через API;

· Меры защиты для интерфейсов администратора;

· Процессы аутентификации для интерфейса администрирования;

· Ограничения по IP, роли и привилегии администратора.

Документы и гарантии, в которых может и должна быть отражена данная информация:

· Технические документы с описанием интерфейсов и практикуемых методов защиты.

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

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

· Панель мониторинга с доступом к мониторингу производительность системы;

· Журналы транзакций и журналы производительности;

· Предупреждения / оповещения и триггеры для уведомления.

Документы и гарантии, в которых может и должна быть отражена данная информация:

· Соответствующий пункт в SLA о наличии журналов транзакций.

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

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

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

Документы и гарантии, в которых может и должна быть отражена данная информация:

· Соответствующие положения в контракте или SLA;

· Аудиторские отчёты, сертификаты, отчёт о произведённой самооценке с указанием соответствия стандартам.

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

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

· Примеры сценариев эластичности, калькуляции затрат и т.д.;

· Уведомления о расходах и ограничения выставления счетов.

Документы и гарантии, в которых может и должна быть отражена данная информация:

· Соответствующие положения в контракте или SLA;

· Отчёт о производительности.

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

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

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

· Соответствующая иностранная юрисдикция и применимое иностранное законодательство;

· Расположение центров обработки данных;

· Применимое законодательство о защите персональных данных.

Документы и гарантии, в которых может и должна быть отражена данная информация:

· Ссылки на соответствующие законодательства.

В приложении № 1 приведена таблица, составленная с целью демонстрации соответствия между темами опросника для поставщика ИТ-услуг и рисками, которые регулируются данной темой в зависимости от ответов провайдера.

Соглашение об уровне обслуживания. Как видно из приведённых выше данных, многие пункты с целью обеспечения безопасности данных и процессов в облачных сервисах фиксируются в контрактах и / или соглашении об уровне и качестве услуг (SLA). Согласно методологии ITIL, в компании должен быть внедрён и налажен процесс управления уровнем сервиса (SLM - Service Level Management), основной целью которого является обеспечение гарантии согласованного с заказчиком уровня обслуживания. Данный процесс выстраивается на основании соглашения об уровне услуг, в рамках которого фиксируются перечень предоставляемых поставщиком ИТ-услуг и их описание, KPI (целевые показатели) предоставляемого обслуживания, распределяются зоны ответственности между провайдером ИТ-услуг и компанией-заказчиком.

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

Ниже приводится шаблон составления SLA:

· Содержание;

· Технические особенности;

· Географические особенности, охват;

· Аспекты безопасности (наличие сертификаций, соответствие российским стандартам, пр.);

· Срок действия Соглашения;

· Обязательства по качеству обслуживания.

Процесс составления SLA состоит из следующих основных шагов:

· Определить перечень предоставляемых ИТ-услуг облачным сервисом;

· Определить состав ключевых показателей предоставления ИТ-услуг, на основании которых можно измерять определённый уровень предоставляемого сервиса и которые включают пороговые значения - минимальное и целевое;

· Определить ключевые показатели, влияющие на гарантии предоставления ИТ-услуг;

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

· Определить формат мониторинга выполнения условий SLA;

· Описать процессы определения компенсации и выплаты соответствующей стороне.

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

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

· Время предоставления услуги. Для всех облачных сервисов стандартным целевым показателем является круглосуточное предоставление услуг в формате 24х7.

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

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

· Уровень доступности. Необходимо определить допустимое время простоя предоставления услуги в месяц и, соответственно, в год. Важно учитывать, что данный показатель влияет на непрерывность предоставления сервиса и функционирование бизнес-процессов компании-заказчика. Целевым показателем, к которому необходимо стремиться, для данного случая будет являться цифра в 100%, то есть непрерывное предоставление ИТ-услуг.

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

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

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

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

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

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

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

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

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

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

ЗАКЛЮЧЕНИЕ

В результате проделанной работы получены следующие результаты и выводы:

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

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

3. Для компании ООО «Эрендай Груп» определена проблема обеспечения информационной безопасности на предприятии. Наличие большого количества угроз и уязвимостей в компании при передаче ИТ-услуг на аутсорсинг связан в первую очередь с отсутствием регламентов и подходов к выбору поставщиков ИТ-услуг (облачных провайдеров) и составлению Соглашения об уровне обслуживания с ними с определёнными метриками и параметрами.

4. Разработаны методы и подходы к выбору поставщика ИТ-услуг и составлению Соглашения об уровне обслуживания.

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

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

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

СПИСОК ЛИТЕРАТУРЫ

1. RightScale 2018 State of the Cloud Report [Электронный ресурс]. - URL: https://assets.rightscale.com/uploads/pdfs/RightScale-2018-State-of-the-Cloud-Report.pdf. (Дата обращения: 05.02.2018)

2. Стандарт ISO/IEC 27017 «Code of practice for information security controls based on ISO/IEC 27002 for cloud services»

3. Стандарт ISO/IEC 27018:2014 «Code of practice for protection of personally identifiable information (PII) in public clouds acting as PII processors»

4. Стандарт ISO/IEC 27036-1 «Information security for supplier relationships - Part 1: Overview and concepts»

5. Стандарт ISO/IEC 27036-2 «Information security for supplier relationships - Part 2: Requirements»

6. Стандарт ISO/IEC 27036-3 «Information security for supplier relationships - Part 3: Guidelines for information and communication technology supply chain security»

7. Стандарт ISO/IEC 27036-4 «Information security for supplier relationships - Part 4: Guidelines for security of cloud services»

8. ITIL (Information Technology Infrastructure Library) Version 3

9. ФЗ «Об информации, информационных технологиях и защите информации» от 27.07.2006 г. №149-ФЗ

10. Федеральный закон «О персональных данных» от 27.07.2006 г. №152-ФЗ

11. Указ Президента РФ от 6.03.97 г. № 188 "Об утверждении перечня сведений конфиденциального характера"

12. Методический документ ФСТЭК России «Методика определения угроз безопасности информации в информационных системах»

13. Методический документ ФСТЭК России «Базовая модель угроз безопасности персональных данных при их обработке в информационных системах персональных данных»

14. ГОСТ Р ИСО/МЭК 27000-2012 Информационная технология. Методы и средства обеспечения безопасности. Системы менеджмента информационной безопасности. Общий обзор и терминология

15. ГОСТ Р ИСО/МЭК 27001-2006 Информационная технология. Методы и средства обеспечения безопасности. Системы менеджмента информационной безопасности. Требования

16. ГОСТ Р ИСО/МЭК 27002-2012 Информационная технология. Методы и средства обеспечения безопасности. Свод норм и правил менеджмента безопасности

17. ГОСТ Р ИСО/МЭК 27003-2012 Информационная технология. Методы и средства обеспечения безопасности. Системы менеджмента информационной безопасности. Руководство по реализации системы менеджмента информационной безопасности

18. ГОСТ Р ИСО/МЭК 27004-2011 Информационная технология. Методы и средства обеспечения безопасности. Менеджмент информационной безопасности. Измерения

19. ГОСТ Р ИСО/МЭК 27005-2010 Информационная технология. Методы и средства обеспечения безопасности. Менеджмент риска информационной безопасности

20. ISO/IEC TS 27017:2015 / ITU-T X.1631 -- Information technology -- Security techniques -- Code of practice for information security controls based on ISO/IEC 27002 for cloud services

21. ISO/IEC 27018:2014 Information technology -- Security techniques -- Code of practice for protection of personally identifiable information (PII) in public clouds acting as PII processors

22. NIST SP 800-144 «Руководство по обеспечению безопасности и защиты персональных данных при использовании публичных облачных вычислений»

23. ETSI TR 103125 «Облака - Соглашения о качестве услуг для облачных сервисов»

24. Dr. M.A.C. Dekker «Critical Cloud Computing: CIIP Perspective on Cloud Computing» // European Network and Information Security Agency (ENISA). 2012. Version 1.0

25. Dr. M.A.C. Dekker, Dimitra Liveri «Cloud Security Guide for SMEs: Cloud computing security risks and opportunities for SMEs» // European Network and Information Security Agency (ENISA). 2015. SME version

...