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
Поэтому неудивительно, что вопрос доступности и производительности бизнес-критичных систем всегда очень важен для компаний, а бизнес очень трепетно подходит к выбору инфраструктурных моделей и продуктов. К числу обязательных для бизнеса также относится вопрос о безопасности данных, которые связаны с той или иной системой. Руководителям компании важно убедиться в том, что данные будут храниться в надежном месте, что они не будут скомпрометированы и к ним не получит доступ злоумышленник.
Беспокойство за сохранность конфиденциальной информации часто приводит руководителей к мысли о том, что будет лучше, если система продолжит работать на собственном сервере «под столом». Но, во-первых, из-за роста объема данных требуется организовать сложную инфраструктуру хранения. Во-вторых, поддержка собственного центра обработки данных требует колоссальных усилий – от выбора места установки стоек с серверами и закупки дорогостоящего оборудования до обеспечения бесперебойной подачи электроэнергии, организации систем кондиционирования и пожаротушения. Из-за того, что создать и эксплуатировать нужную инфраструктуру становится все сложнее (вычислительное оборудование дорожает, а из-за кризиса полупроводников поставки решений откладываются на полгода-год), в лагере облачных сервисов количество сторонников растет. И при переходе на облачную модель у новых клиентов неизбежно возникает вопрос: как проверить, что провайдер обеспечил все меры защиты в облачной инфраструктуре?
Есть ряд организационно-технических мер, выполнение которых позволяет провайдеру гарантировать фактически 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-матрицы, бывают нетипичные ситуации, поэтому очень важно, чтобы поставщик услуг и заказчик работали как единая команда, не перекладывая ответственность друг на друга, а стремясь совместно решить задачу. |