Обеспечение безопасности групповой работы в облаке сервиса Wrike

Обеспечение безопасности групповой работы в облаке сервиса Wrike

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

 

 

  1. Введение
  2. Любое облако для бизнеса создает риски
  3. Как оценить надежность облачного сервиса
  4. Средства и способы защиты информации в сервисе Wrike
    1. 4.1. Физическая безопасность
    2. 4.2. Сетевая и системная безопасность
    3. 4.3. Безопасность приложений
    4. 4.4. Организационная защита информации
  5. Выводы

 

Введение

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

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

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

 

Любое облако для бизнеса создает риски

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

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

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

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

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

Впрочем, даже и без злоумышленника информация в облаке все равно может оказаться доступной извне. Стоит вспомнить, например, об относительно свежем инциденте, когда Яндекс любезно проиндексировал конфиденциальные данные сначала из сервиса «Документы Google», а затем и из служб электронной коммерции. Когда-то давно мы писали о том, что считавшийся достаточно надежным доступ по ссылке (при котором с информацией может ознакомиться только тот пользователь, у которого есть сгенерированный специально для него URL) внезапно устарел. Это случилось после того, как поисковые системы начали создавать свои браузеры и использовать их для пополнения баз данных — любая страница, куда заходил человек, незамедлительно индексировалась. К сожалению, эта проблема существует и по сей день: данные не защищаются полноценной авторизацией, а следовательно, могут быть обнаружены посторонними лицами.

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

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

 

Как оценить надежность облачного сервиса

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

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

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

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

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

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

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

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

 

Средства и способы защиты информации в сервисе Wrike

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

Физическая безопасность

Wrike пользуется двумя базовыми дата-центрами, расположенными в США и ЕС. Оба соответствуют требованиям стандарта ISO 27001; американский центр обработки данных также отвечает стандарту SSAE 16 TypeII, а европейский — ISAE 3402. Данные пользователей из Евросоюза хранятся изолированно от всех остальных. Разработчик сообщает, что оба дата-центра находятся под круглосуточной охраной и снабжены средствами физического контроля доступа и биометрической аутентификации; кроме того, ведется отслеживание всех данных и операций над ними (Digital Surveillance). Получить доступ к устройствам и программному обеспечению может только авторизованный персонал, а журналы событий и записи о входах в систему регулярно проверяются. На случай форс-мажорных обстоятельств Wrike поддерживает дублирующую инфраструктуру в облаке Google, которая также соответствует требованиям стандартов, названных выше. Имеется защита от сбоев электропитания, установлены датчики дыма и огня, несущие конструкции укреплены для сопротивления сейсмическим воздействиям.

Также разработчик обещает, что время аптайма составит не менее 99,9%. В тех случаях, когда сервис временно недоступен (например, на срок планового техобслуживания), пользователи могут обратиться к автономной копии Wrike и открыть сохраненные проекты в режиме «только чтение». По доступным сведениям, постоянно ведется резервное копирование и дублирование баз данных, что позволяет, с одной стороны, обеспечить оперативное восстановление информации, а с другой стороны — предотвратить отказы в обслуживании (т. к. экземпляры БД доступны на дополнительных серверах с разным географическим расположением).

Сетевая и системная безопасность

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

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

Безопасность приложений

Wrike применяет протокол безопасности жизненного цикла приложений, которому свойственны:

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

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

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

Также Wrike поддерживает работу пользователей с проектами через мобильные приложения для операционных систем iOSи Android, причем эти приложения тоже имеют ряд защитных функций — например, проверяют, не открыт ли root-доступ и не выполнялся ли джейлбрейк на устройстве.

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

Организационная защита информации

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

 

Выводы

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

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

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

Полезные ссылки: 
Yandex Zen AMПодписывайтесь на канал "Anti-Malware" в Yandex Zen, чтобы узнавать о новостях и эксклюзивных материалах по информационной безопасности в своей персональной ленте.

RSS: Новые статьи на Anti-Malware.ru