2022/02/09 16:22:33

TADeтали:
Правила выбора IaaS высокой степени защищенности

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

Содержание

Развитие IaaS подхлестывает пандемия

Наиболее активными потребителями IaaS стали компании, работающие на конкурентных рынках, прежде всего в сфере b2c. Это банки, разработчики мобильных приложений, ритейл. Современный потребитель особенно восприимчив к уровню сервиса, и, как правило, он уходит к той компании, которая в нужное время предлагает услуги, наиболее релевантные его ожиданиям. Те предприятия, которые не отвечают запросам клиентов, проигрывают в конкурентной борьбе. Переход на облачную инфраструктуру позволяет более гибко реагировать на изменения рыночной ситуации, быстро запускать новые сервисы, оперативно сегментировать клиентские группы для генерации фокусных предложений. Например, в 2020 году, на фоне перехода к удаленной работе многие пользователи стали активнее заказывать продукты через мобильные приложения. Так, в MasterCard посчитали, что в самый разгар локдауна каждый пятый доллар в сфере торговли потребители тратили онлайн, в то время как в 2019 году – только каждый седьмой. В итоге на быстрорастущем рынке онлайн-ритейла и доставки выиграли те компании, которые смогли предложить наиболее удобные приложения со стабильным качеством работы. Те компании, которые опоздали всего на полгода-год, теперь вынуждены изо всех сил догонять конкурентов. Добиться этого становится все сложнее еще и потому, что доступность вычислительного оборудования начиная с 2021 года существенно уменьшилась. Из-за кризиса полупроводников сроки доставки удлинились с привычных для заказчиков 8-10 недель до полугода. Некоторые системы можно ждать год и более. В результате тормозятся планы компаний по цифровизации и автоматизации процессов.

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

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

Почему IaaS используют не все компании

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

«
Уровень использования IaaS обычно зависит от размера организации и стоящих перед ней задач, — объясняет Сергей Зинкевич. — Как правило, сравнительно небольшие компании охотно размещают в облаке все приложения, тогда как у заказчиков корпоративного уровня среди многочисленных систем есть круг тех, которые работают давно и стабильно — на еще не старом железе. То есть имеется некое наследие, которое в краткосрочной или среднесрочной перспективе нецелесообразно рассматривать в контексте IaaS. Кроме того, есть ПО, например, СУБД Oracle, которое сложно лицензировать в облаке. Но таких приложений обычно всего 5-15%. В то же время, согласно данным КРОК Облачные сервисы, 25-35% приложений крупной компании – это обычно те системы, которые отвечают за взаимодействие с заказчиками или клиентами, и их всегда можно смело переносить в облако. Решения о переводе оставшихся 50-60% приложений лучше принимать внутри компании, тщательно взвесив все «за» и «против».
»

Роль доступности инфраструктуры

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

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

Как разработать стратегию безопасности при работе с IaaS

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

Беспокойство за сохранность конфиденциальной информации часто приводит руководителей к мысли о том, что будет лучше, если система продолжит работать на собственном сервере «под столом». Но, во-первых, из-за роста объема данных требуется организовать сложную инфраструктуру хранения. Во-вторых, поддержка собственного центра обработки данных требует колоссальных усилий – от выбора места установки стоек с серверами и закупки дорогостоящего оборудования до обеспечения бесперебойной подачи электроэнергии, организации систем кондиционирования и пожаротушения. Из-за того, что создать и эксплуатировать нужную инфраструктуру становится все сложнее (вычислительное оборудование дорожает, а из-за кризиса полупроводников поставки решений откладываются на полгода-год), в лагере облачных сервисов количество сторонников растет. И при переходе на облачную модель у новых клиентов неизбежно возникает вопрос: как проверить, что провайдер обеспечил все меры защиты в облачной инфраструктуре?Как DevOps-сервис помогает «разгрузить» высоконагруженные системы BPMSoft 2.2 т

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

ЦОД провайдера, который заботится о своей репутации и бизнесе своих клиентов, работает на основе строгих регламентов, с которыми заказчик всегда может попросить ознакомиться (естественно, под NDA). Например, он может убедиться, что в регламенте четко разграничены роли доступа к ресурсам ЦОДа и что учетная запись уволившегося сотрудника оперативно удаляется из Active Directory.

Область информационной безопасности в целом хорошо регламентирована, и поставщик IaaS должен предоставить соответствующие лицензии и сертификаты, подтверждающие то, что услуга оказывается в соответствии со всеми нормативно-правовыми актами и лучшими практиками. Один из основных стандартов, которым руководствуются провайдеры, – ISO 27001. Он устанавливает требования к системе менеджмента ИБ и аккумулирует ключевые практики в области управления ИБ. Еще один важный стандарт – PCI DSS. Он создан для защиты процессинга и описывает все уровни защиты платежной инфраструктуры – от физической безопасности до уровня приложений, но фактически может быть применим в деятельности любой организации.

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

«
Находясь под столь жесткими регламентами, компания-провайдер IaaS должна регулярно поддерживать высокий уровень информационной безопасности, иначе ее бизнес будет страдать от многочисленных исков со стороны клиентов, чьи данные окажутся скомпрометированы, — обращает внимание Сергей Зинкевич. — Получается, что внешнее облако обычно даже лучше защищено, чем внутренняя инфраструктура любой компании. Поэтому в мире все больше примеров, когда компании полностью уходят в облака. Например, один из крупнейших в мире инвестиционных банков Goldman Sachs перевел свою инфраструктуру в облако Amazon`.
»

Вопрос хранения персональных данных во внешней среде раньше решался нетривиально. Из-за сложности в аттестации гипервизоров определенных типов (а на определенном этапе — невозможности такой аттестации) в публичном облаке формально можно было держать только данные 3 и 4 типа, в то время как самые ценные с точки зрения бизнеса персональные данные (1 и 2 тип, это вся личная, медицинская, биометрическая информация) необходимо было мигрировать на выделенное оборудование в ЦОД. Благодаря расширению возможностей по аттестации всех уровней инфраструктуры в облаке по требованиям ФСТЭК России, такие ограничения были сняты. В результате этого с 2021 года многие крупные облачные провайдеры прошли процедуру аттестации, чтобы подтвердить высокий уровень защищенности своей платформы и упростить заказчикам работу с персональными данными из облака.

Как разграничить зоны ответственности

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

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