Устранение конкретного заблуждения относительно межсетевого взаимодействия



С 2014 года Qrator Labs разрабатывает сервис BGP-мониторинга и аналитики под названием Qrator.Radar. Одна из его основных функций — мониторинг определенных аномалий BGP, которые могут привести к инциденту, который мы в дальнейшем будем называть либо утечкой маршрута BGP, либо захватом BGP.

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

Наша компания начала собирать модель отношений BGP за пару лет до появления RFC 7908, пытаясь определить, что такое утечка маршрута BGP. Два основных различия между этими временами событий были описаны как:
  • Маршруты перенаправляются через неправильные ASN / ссылки (утечки маршрутов), описываются как типы 1-4 RFC 7908;
  • Маршруты перенаправляются на неправильные ASN (Hijack), описанные как типы 5 и 6 RFC 7908.
Во время утечки маршрута BGP трафик, предназначенный для вашей сети, скорее всего, будет проходить неэффективно, что может привести к увеличению задержки в сети и потере пакетов. Тем не менее, он почти наверняка достигнет вашей сети, если по какой-либо причине нет критической перегрузки сети (например, из-за плохого намерения сбоя).

Во время перехвата BGP трафик, предназначенный для вашей сети, перенаправляется третьей стороне и остается там.

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

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

Чтобы обнаружить причину утечки маршрута, вам необходимо выяснить взаимосвязь между каждым из двух подключенных операторов и выяснить такие маршруты BGP (от сборщика BGP), которые нарушают формальную модель Гао-Рексфорда, для получения дополнительной информации см. с «отношениями AS» CAIDA.
Чтобы обнаружить угоны, вам необходимо знать, какие префиксы принадлежат каким интернет-провайдерам, и в большинстве случаев, когда появляется незарегистрированная пара префиксов интернет-провайдера — создайте сигнал тревоги или примите меры.
www.caida.org/data/as-relationships/

Чтобы предотвратить / смягчить захват, существует два стандартных подхода в рамках единой структуры проверки происхождения префикса. Вы можете зарегистрировать объект Route в IRR или создать объект ROA. Наша команда описала различия между этими подходами во время RIPE79. Однако общее — они оба указывают, какие префиксы принадлежат каким операторам (самими операторами), и пытаются заблокировать маршруты от интернет-провайдера с незарегистрированными префиксами (транзитными интернет-провайдерами).

Чтобы предотвратить / смягчить чистые утечки маршрутов, мы принимаем участие в создании открытой политики BGP. Другой подход — одноранговая блокировка — блокировка маршрутов с неожиданными соседями / интернет-провайдерами в AS_PATH.
datatracker.ietf.org/doc/draft-ietf-idr-bgp-open-policy/
archive.nanog.org/sites/default/files/Snijders_Everyday_Practical_Bgp.pdf
datatracker.ietf.org/doc/draft-ietf-sidrops-aspa-profile/

Проект ASPA IETF стоит немного в стороне от чистого предотвращения перехвата / утечки маршрутов, потому что он больше касается блокирования плохих AS_PATH (случаев утечки маршрутов и перехватов без / с плохой манипуляцией AS_PATH).

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

Подписание ROA против фильтрации ROA
Еще одно распространенное заблуждение связано с РОА. В алгоритмах ROA есть две стороны: подписывающая сторона — оператор, который предоставляет достоверную информацию о принадлежащих ему префиксах; и есть фильтрующая сторона — транзитный оператор, который отфильтровывает плохие маршруты в соответствии с информацией, предоставленной подписавшей стороной.

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

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

pCS

Мы успешно очистили достаточно дисков для метаданных. Теперь мы можем восстанавливать кольца. Фото: до vs после.

У нас есть 20% данных всего с одной копией. Сначала мы восстанавливаем избыточность данных. Затем мы даем доступ RO. Потом RW.


Приглашаем на бесплатный вебинар: выбор облака в 2021 году


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




www.webinar.gcorelabs.com

Разделяемая ответственность (shared responsibility). На стороне клиента



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

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

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

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

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

Управление доступом пользователей
Управление учётными записями — это одна из важнейших возможностей клиентов облака для обеспечения безопасности. Для IaaS, PaaS и SaaS управление учётными записями и доступом является общей ответственностью, требующей настройки контроля доступа на основе ролей и применения различных способов аутентификации, контроля и мониторинга. В Yandex.Cloud на данный момент пользователям доступны следующие виды аккаунтов:
  • Аккаунты на Яндексе. Для аутентификации необходимо использовать логин и пароль либо ПИН-код и приложение Яндекс.Ключ, если настроена двухфакторная аутентификация.
  • Федеративные аккаунты. Сервис IAM принимает от стороннего поставщика удостоверений (identity provider) подписанный SAML-токен, который содержит информацию об аутентифицированном пользователе.
  • Сервисные аккаунты — особый тип аккаунтов, которые используются для доступа к ресурсам Yandex.Cloud от имени приложения.
То есть, провайдер предоставляет способы идентификации/аутентификации, а пользователь уже самостоятельно выбирает наиболее подходящий в зависимости от своего сценария применения облачной платформы.

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

Сетевая безопасность и контроль сети
Сетевой контроль на стороне клиента включает в себя настройку и использование сетевых средств безопасности, таких как VPN, балансировщики нагрузки (load balancers), шлюзы и прочее.
  • В решениях SaaS управление и безопасность для клиента заключается в настройке программного обеспечения, так как конфигурация сети выполняется поставщиком услуг.
  • В решениях IaaS клиент разделяет с облачным провайдером ответственность за развёртывание, защиту, настройку сетевых решений и управление ими.
Для защиты виртуальных машин и выделения зон разного уровня безопасности пользователям также доступен механизм групп безопасности (security groups). Для повышения доступности инфраструктуры в Yandex.Cloud есть возможность управлять входящим и исходящим интернет-трафиком, в том числе с помощью балансировщика нагрузки Yandex Network Load Balancer, а также сегментировать виртуальные сети среды Yandex.Cloud. Балансировщик нагрузки может быть интегрирован с сервисом Yandex DDoS Protection, который защитит ваш сервис от DDoS-атак. Для защиты от атак на уровне L7 рекомендуется использовать виртуальные образы или облачные сервисы с web application firewall (WAF).

Связь с локальной инфраструктурой можно обеспечивать с помощью VPN-инстанса, сетевых образов из Cloud Marketplace или Yandex Cloud Interconnect.

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

Защита данных
Для шифрования данных на управляемых пользователем ключах у клиентов Yandex.Cloud есть возможность применять сервис Yandex Key Management Service. Сервис предназначен для управления криптографическими ключами пользователя и предоставляет возможность шифрования данных при сохранении пользовательского контроля над ключами шифрования. Отдельного внимания заслуживает интеграция сервиса KMS с Yandex Object Storage: в этом случае пользователю достаточно указать ключ KMS, на котором необходимо шифровать данные бакета, и все данные будут защищены с помощью указанного ключа, а просмотр или модификация данных станут невозможны без прав доступа на указанных ключ. Таким образом, можно контролировать использование данных.

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

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

Разделяемая ответственность (shared responsibility). На стороне облака


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

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

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

Разделяемая ответственность
Ответственность провайдера и клиента различается в зависимости от модели использования облачных сервисов (IaaS — инфраструктура как услуга, PaaS — платформа как услуга, SaaS — программное обеспечение как услуга) и имеющихся у облачного провайдера защитных механизмов и политик: возможностей соблюдения законодательства, стратегии управления рисками, модели угроз и других факторов.


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

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

При использовании управляемых сервисов (PaaS/SaaS) забот у конечного пользователя становится гораздо меньше, так как провайдер уже обеспечивает защиту компонент PaaS/SaaS-сервисов. Например, в случае Yandex Managed Service for ClickHouse провайдер защищает виртуальные машины сервиса, выполняет резервное копирование базы данных и шифрует пользовательские данные. В то же время клиент обязан классифицировать данные, обеспечить разграничение доступа к данным, настроить процессы для их защиты, а также отвечает за управление своими пользователями и конечными устройствами.

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

Яндекс обеспечивает безопасность облачной платформы на следующих уровнях:
  • Безопасность дата-центров
  • Безопасность инфраструктуры
  • Защита на уровне данных
  • Соответствие стандартам
  • Безопасность дата-центров
ЦОДы можно считать фундаментом облачной платформы. Все серверные ресурсы Yandex.Cloud располагаются в собственноручно спроектированных и построенных дата-центрах на территории России, которые связаны собственными каналами связи. Это позволяет команде обеспечивать соответствующий уровень безопасности, включая необходимые параметры надежности. Кстати, о надежности наших ЦОДов мы уже рассказали первой статье серии. Меры безопасности в дата-центрах соответствуют лучшим практикам и включают в себя процедуры контроля доступа, видеонаблюдение и регламенты замены оборудования, реализующие процедуры очистки носителей с данными клиентов.

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

Безопасность физических машин и сервисных виртуальных машин обеспечивается на нескольких уровнях: используется ряд межсетевых экранов, а также дополнительные средства защиты (AppArmor, Seccomp, Osquery 4 и система мониторинга и оповещения о подозрительном поведении).

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

Защита данных. SDLC и defence in depth. Шифрование
Безопасность Yandex.Cloud организована таким образом, что одной угрозе противостоит набор средств защиты на разных уровнях. Такой подход удорожает любую потенциальную атаку и позволяет оперативно выявлять и предотвращать деятельность злоумышленников. Техническая команда платформы соблюдает процесс безопасной разработки (security development lifecycle, SDLC), выстраивая основу безопасности облачных сервисов с самых ранних этапов проекта. Дополняющая эти базовые принципы концепция эшелонированной обороны (defense in depth) обеспечивает многоступенчатую защиту, которая препятствует действиям злоумышленников и способствует раскрытию их деятельности еще при подготовке атаки.

Для шифрования разработаны несколько уровней:
  • Шифрование на уровне storage.
  • Шифрование на уровне баз данных Yandex Database. Данные шифруются непосредственно перед отправкой в storage.
  • Шифрование резервных копий данных в Managed Services for Databases (MDB). Все резервные копии, создаваемые MDB, шифруются перед отправкой в постоянное хранилище.
  • Шифрование данных при передаче.
Владельцем данных всегда является пользователь облачной платформы. Yandex.Cloud использует информацию клиента, размещенную на платформе, только для выполнения целей договора и уведомляет клиента об инцидентах, затрагивающих пользовательские данные.

Стандарты и законы
Как уже обозначалось выше, соответствие стандартам необходимо по двум причинам:
  • Это перепроверка самих себя и возможность подтвердить определенные тезисы в части безопасности клиентам.
  • Предоставление возможности клиентам приведения в соответствии (например, с 152-ФЗ или PCI DSS) их систем, при размещении в облаке.
В начале 2020 года Yandex.Cloud стала первой в России и СНГ публичной облачной платформой, выстроившей управление информационной безопасностью по стандарту ISO/IEC 27017:2015 и обеспечившей защиту персональных данных пользователей по международному стандарту ISO/IEC 27018:2019. Соответствие платформы требованиям международных нормативных документов подтверждено независимым аудитором — Британским институтом стандартов (BSI). Таким образом, наша платформа соответствует требованиям трех международных стандартов информационной безопасности: ISO/IEC 27001:2013, ISO/IEC 27017:2015, ISO/IEC 27018:2019.

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

Ну и наконец, платформа прошла аудит по требованиям ФЗ-152 и теперь соответствует более высокому уровню защищенности персональных данных — УЗ-1, что позволяет клиентам хранить и обрабатывать в том числе специальные категории персональные данных, например медицинские данные.

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

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

Плагин для гибридной работы с Citrix Virtual Apps and Desktops



Команда Yandex.Cloud разработала плагин для виртуальной инфраструктуры рабочих столов. С его помощью VDI Citrix интегрируется с облачной платформой. Плагин поддерживает гибридные инсталляции и позволяет перенести часть инфраструктуры в облако тем, кто уже работает с CVAD on-premise и нуждается в дополнительных мощностях для виртуальных рабочих мест и приложений.

Плагин позволяет управлять инфраструктурой в Yandex.Cloud с помощью инструмента Machine Creation Services — MCS. Также решение подходит для развертывания CVAD с нуля в облаке.

Плагин предоставляется бесплатно. Его разработка — результат партнерства Yandex.Cloud и Citrix.

Как это работает
Развертывание CVAD с нуля в облаке Yandex.Cloud

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

В облаке решение Citrix разворачивается быстро и стоит дешевле, чем on-premise. Всю инфраструктуру предоставляет и обслуживает провайдер, а платить нужно только за использованные ресурсы Yandex.Cloud.

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

Гибридное решение: on-premise + Yandex.Cloud
Когда решение CVAD развернуто on-premise, с ростом нагрузки возникает потребность в дополнительном оборудовании. IT-департаменту предприятия трудно точно спрогнозировать потребность в ресурсах. Задачу усложняет необходимость держать резервные мощности для пиковых нагрузок. Избыточная оценка приводит к неоправданным тратам на оборудование.

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

С плагином можно создавать гибридные инсталляции из физических и виртуальных ресурсов и управлять инфраструктурой VDI с помощью привычных инструментов. Подготовка и развертывание мастер-образов происходят автоматически с помощью инструментов Citrix Studio и PowerShell SDK, используемых в инсталляциях CVAD. Вся работа ведется в привычной среде Citrix — дополнительное обучение не требуется.

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

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

Почему Yandex.Cloud
Платформа Yandex.Cloud — масштабируемое и надежное решение для реализации любых IT-проектов. В облаке размещены сайты и приложения самого Яндекса. Гибкость платформы позволяет мгновенно наращивать и освобождать ресурсы, когда нагрузка меняется. Благодаря модели pay as you go (PAYG) вы не платите за неиспользуемые и простаивающие ресурсы — только за реально использованные мощности.

Все сервисы платформы, а не только дата-центры, соответствуют требованиям закона о защите персональных данных ФЗ-152 и имеют самый высокий уровень защиты — УЗ-1. Это позволяет предприятиям федерального и международного уровня размещать в Yandex.Cloud персональные данные. Система управления информационной безопасностью (СУИБ) сертифицирована по стандартам ISO 27001, ISO 27017 и ISO 27018. Сертификат высшего уровня безопасности PCI DSS — Level 1 — позволяет клиентам Yandex.Cloud защищать данные держателей банковских карт. Подробную информацию вы можете найти на странице Безопасность.

Фактический уровень SLA Yandex.Cloud за последние три года не опускается ниже 99,9996%.

Получить плагин и внедрить гибридное решение Citrix cloud.yandex.ru/blog/posts/2021/03/citrix-plugin#contact-form

Schlumberger и Yandex.Cloud помогут российским нефтегазовым компаниям ускорить цифровизацию


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

Среда DELFI объединяет ведущие программные решения от компании Schlumberger, включая программную платформу Petrel E& P, платформу для скважин Techlog и инструментарий для моделирования пласта высокого разрешения INTERSECT, и расширяет их возможности с помощью искусственного интеллекта и высокопроизводительных вычислений, которые становятся возможными благодаря облачным технологиям.

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

Наше стратегическое сотрудничество с Yandex.Cloud ускорит цифровую трансформацию российской энергетики. Размещая среду DELFI в Yandex.Cloud, мы предоставляем клиентам безопасный доступ к нашим ведущим ИИ и цифровым решениям в быстро развивающемся облачном сервисе по всей России. Благодаря передовым облачным технологиям и практически безграничным возможностям в области геофизики, инженеры и специалисты по обработке данных смогут ускорить свои рабочие процессы и анализ данных, что позволит улучшить важные решения для бизнеса. Развертывание комплекса DELFI поможет российскому энергетическому сектору повысить производительность всей производственной цепочки
прокомментировал Рустам Биктимиров, вице-президент по цифровым технологиям и интеграции компании Шлюмберже в России и Центральной Азии

Сервис Yandex.Cloud был выбран из-за его обширной и постоянно растущей сети центров обработки данных по всей России, поддерживаемых собственными технологиями и сервисами для хранения, обработки и анализа данных с расширенными цифровыми возможностями, включая искусственный интеллект. Сервис Yandex.Cloud также соответствует международным и российским стандартам защиты и безопасности данных, в том числе требованиям 152-ФЗ, стандарту безопасности платежных карт PCI DSS и сертификатам соответствия международным стандартам информационной безопасности ISO 27001, ISO 27017 и ISO 27018.

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

Новый сервис Yandex Cloud DNS


На платформе Yandex.Cloud запущен сервис Yandex Cloud DNS для управления ресурсными записями и доменными именами (DNS), а также их публикации в глобальной системе (DNS). Сервис упрощает администрирование проектов за счёт работы с общим интерфейсом для управления хостами и ссылающимися на них доменами.
cloud.yandex.ru/services/dns

Yandex Cloud DNS позволяет создавать и настраивать внутренние и публичные DNS-зоны в консоли облака Yandex.Cloud, а также в API, CLI или Terraform. Доступ к внутренним зонам возможен только из сети (VPC) пользователя. Прочитать записи из публичных зон смогут все.

Подробнее о работе сервиса читайте в документации.
cloud.yandex.ru/docs/dns/

Какие задачи решит сервис
Делегирование и управление доменами. В Cloud DNS вы можете управлять своими доменами, купленными у любого регистратора, и доступом по этим именам к приложениям, развёрнутым в облаке. Технология Anycast делает DNS-системы Yandex Cloud более надёжными, безопасными, отказоустойчивыми.

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

Стабильность высоконагруженных приложений. Cloud DNS создан на базе производительной и высокодоступной инфраструктуры Yandex.Cloud. Распределённая система DNS-серверов и минимальная задержка отклика позволяют ему обрабатывать трафик ключевых бизнес-приложений.

Сервис находится на стадии Preview и не тарифицируется.
cloud.yandex.ru/docs/overview/concepts/launch-stages

Аудит облачной инфраструктуры с Cloud Advisor



Cloud Advisor — это партнерское решение для обеспечения безопасности, производительности, отказоустойчивости и оптимизации IT-инфраструктуры, расположенной в Yandex.Cloud. Его выпустили основатели компании Agnitum, известной по продукту Outpost Firewall.

Для проведения автоматического анализа инфраструктуры достаточно зарегистрироваться на сайте Cloud Advisor и подключить облако Yandex.Cloud. Аудит позволяет решить ряд вопросов, например, подвержено ли облако воздействию актуальных угроз безопасности, насколько оно соответствует практикам использования облачных сервисов и рекомендациям провайдера.
cloudadvisor.ru/



Какие задачи помогает решить Cloud Advisor
Обеспечение безопасности

По данным Gartner, практически все успешные атаки на облачные сервисы являются результатом их неверной настройки пользователем, неграмотного управления и допущенных ошибок (Отчёт Gartner «Innovation Insight for Cloud Security Posture Management», 25 января 2019).

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


Для обеспечения безопасности Cloud Advisor автоматически проверяет облачные ресурсы в рамках продуктов Object Storage, Compute Cloud, Identity and Access Management, Yandex Database, Virtual Private Cloud, Load Balancer, Cloud Functions, Key Management Service. Проверки осуществляются ежечасно, что позволяет обнаружить уязвимость практически сразу после появления. Специалисты Cloud Advisor постоянно следят за возникновением новых угроз и появлением новых функций облачных сервисов, обновляют инструмент и добавляют проверки.

Оптимизация расходов
По данным Flexera, 35% бюджета на облака расходуется впустую (Отчёт Flexera «State of the Cloud Report» за 2020 год). Cloud Advisor сканирует облачную инфраструктуру и позволяет выявить неиспользуемые и неподключенные, а также недостаточно загруженные ресурсы.

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

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


Cloud Advisor предоставляет единую панель управления с группировкой по приоритетам. У Cloud Advisor нет доступа к данным внутри виртуальных машин, данным в управляемых базах данных или S3-хранилище. Продукт не требует установки дополнительных компонентов внутри инфраструктуры и осуществляет её постоянный мониторинг без участия пользователя. Рекомендации Cloud Advisor базируются на документации Yandex, методологии AWS Well-Architectured Framework и Center for Internet Security (CIS).

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

Aristos: Зачем выбирать между «облаком» или выделенным сервером, когда можно взять лучшее от обоих

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

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

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

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

Андрей, расскажите, чем занимается компания?
Мы работаем в области ритейла. Предлагаем услуги аутсорсинга электронной коммерции крупным международным брендам. Например, сотрудничаем с Philips, Castrol, Nestle, DeWalt и другими. Создаем и разрабатываем сайты, решаем задачи логистики. Бухгалтерия, закупки, склады — это все завязано на нас.

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

С чего началось строительство IT-платформы?
Первый сервер мы арендовали в 2011 году в Нидерландах — под официальный интернет-магазин Philips. Тогда еще не было 152-ФЗ, который обязывал бы нас хранить персональные данные в России, да и головной офис Philips настаивал, чтобы серверы находились в Европе. На этом сервере хранились и база данных, и веб-сервер, и программный код.

В первые годы работы нам удалось запустить на этой же платформе проекты и для других крупных брендов — Tefal, Olympus, Oursson, Oppo. По мере роста проектов росла и нагрузка. Чтобы её оптимизировать, мы решили перенести базу данных на отдельный сервер.

Так мы работали до 2014 года — в кризис курс доллара резко вырос, а с ним и стоимость серверов в Европе. Арендовать там стало невыгодно, и мы задумались о необходимости переноса инфраструктуры в Россию. Дополнительным аргументом в пользу такого решения стал тот факт, что мы периодически сталкивались с проблемами доступности серверов — для клиентов из России пинг до Европы выше, чем внутри страны. Соответственно, скорость обслуживания медленнее.

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

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


Мы арендовали три сервера под разные задачи, и на тот момент наша инфраструктура была такой:
  • Технический сервер, так называемый dev-сервер, с рядом вспомогательных сервисов (тестовый сервер, git-сервер, мониторинг доступности, сервис управления проектами, телефония и др.).
  • Отдельный сервер под базу данных и сервисы, обслуживающие непосредственно интернет-магазины.
  • Производительный сервер для обслуживания HTTP-запросов (веб-сервер и обработка запросов со стороны бэкэнд-логики).
С ростом нагрузки возникла необходимость масштабирования вычислительных мощностей. Постепенно мы переработали программную часть инфраструктуры таким образом, что стало возможным запускать ее на неограниченном количестве серверов. Подключили сервис-балансировщик. Его задача — самостоятельно оценивать производительность и нагрузку на каждом из доступных серверов, а затем распределять нагрузку между наименее загруженными серверами.
За счёт этих решений мы смогли реализовать быстрое горизонтальное масштабирование — меньше времени тратить на то, чтобы добавлять новые серверы в общую архитектуру. А кроме того, повысили доступность наших проектов.
Также в первые две недели после переезда мы объединили все серверы в локальную сеть с помощью услуги VLAN. До этого момента серверы общались друг с другом через интернет. И чтобы обратиться к базе данных, требовалось отправить запрос на внешний IP. Такое решение было ненадёжным сразу по двум причинам. Во-первых, сервисы смотрели «наружу», что само по себе не безопасно. А во-вторых, терялась скорость при передаче данных из-за избыточности маршрута. Часть вспомогательных сервисов распределяется между серверами, поэтому нам требовалась оперативная связь между ними. В тот момент этого нам не хватало. Организация локальной сети решила эти проблемы.

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

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

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

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

Базы данных (SQL и NoSQL), поисковый сервис, функциональные приложения для работы проекта, API — теперь каждый компонент масштабируется независимо от остальных.

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

Облачные серверы связываются с выделенными через IPv6 туннель и WireGuard VPN. А за распределение нагрузки отвечает сервер с системой программной балансировки. Систему разрабатывали самостоятельно, так как хотели иметь полный контроль над поведением балансировщика.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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