Выбрать технологию автоматизации маркетинга — значит учесть много факторов. Вместе с коллегами из «Яндекса», «Додо Пиццы», ROSTIC’S, Okko.tv разобрались в разнице между on-premise и облачным решением и сформулировали критерии.
27 июня 2024
Как выбрать решение для автоматизации маркетинга: облако или on-premise. Подробный разбор
При выборе платформы автоматизации маркетинга перед командой рано или поздно встает выбор: on-premise, то есть развертывание на своих серверах, или облачное решение. Разобрались, какие преимущества есть у каждого решения и на какие неочевидные критерии обратить внимание при выборе.
В статье — мнения экспертов «Яндекса», «Оператора Газпром ИД», «Додо Пиццы», ROSTIC’S, «Самолета», «Здравсити», аптек «Вита», Okko.tv, «Улыбки радуги», Synergetic, ГК «ТрансТехСервис», а также консультантов в сфере информационной безопасности.
Содержание:
Кратко: когда лучше on-premise, когда — облако
Ниже мы собрали много мнений о том, какой класс решений лучше подойдет в том или ином случае. Спикеры поделились разным опытом и неочевидными нюансами. Если свести их мысли к нескольким абзацам, то ситуация выглядит так:
On-premise — лучший выбор, если у вас уникальные и сложные бизнес-процессы. При этом есть достаточно ИТ-ресурсов, в том числе на регулярную поддержку и доработку, особенно если вы тестируете много маркетинговых гипотез. Важно также наличие экспертов в информационной безопасности и работе с инфраструктурой.
Облако — лучший выбор, если вам нужно быстро запускаться, подключать новые фичи и тестировать гипотезы. При этом нет задачи выстроить уникально сложный CJM, хранить данные на своей стороне. И нет избытка ИТ-ресурсов, а также внутренней экспертизы в информационной безопасности и работе с инфраструктурой.
Что касается безопасности и надежности, то в случае с on-premise вся ответственность лежит на компании. В облачных решениях все зависит от размера вложений и качества процессов вендора. Ориентироваться стоит на соблюдение стандартов и то, работает ли вендор с крупными компаниями с сильной службой безопасности.
Важно помнить, что ни облако, ни on-premise не является гарантией защиты от утечек. Поэтому главный критерий выбора — все-таки бизнес-польза: как новое решение поможет улучшить CJM и повлияет на ключевые метрики.
Сравнение on-premise и облака
Преимущества on-premise: кастомизация и полный контроль
On-premise — развертывание решения на своих серверах. Встречается в двух вариантах: разработка с нуля силами компании или покупка готового решения у вендора. Их достоинства одинаковые, поэтому ниже будем говорить об on-premise в целом.
Решение можно настроить под себя до мелочей
Вендоры on-premise-решений и собственная разработка готовы подстроить продукт под бизнес-процессы компании. Это особенно важно для компаний не из ритейла или с уникально сложной бизнес-логикой. Например, можно предусмотреть быструю обработку большого количества товарных фичей или десятков миллионов клиентов, учесть нетипичный CJM (как у медицинских клиник).
Вендоры on-premise-решений готовы бесплатно дорабатывать продукт, если он затрагивает «боли» многих клиентов — это повышает приоритет разработки. Если же нам нужен специфический функционал и быстро, его всегда можно заказать. С облачным решением получить нужную доработку вне очереди не получится даже за деньги.
Облачные решения обычно заточены под e-commerce. Для других отраслей они подходят неидеально: слишком отличаются структура данных и бизнес-процессы. У меня был неудачный опыт внедрения облачного CDP для медицинской сети. Проект не взлетел, потому что не удалось совместить логику CJM клиник и платформы.
В таких случаях больше подходят on-premise-решения, где все можно подстроить под специфику бизнеса. Но возможен и гибридный подход: мы в «Самолете» используем on-premise-решения как основу для инфраструктуры, а облачные сервисы — для коммуникаций.
Я продавал платформу автоматизации маркетинга Mindbox три года. Чем крупнее бизнес, тем чаще я слышу запрос на специфические фичи. Бывают ситуации, когда мы действительно не можем предоставить требуемый уровень кастомизации и сами отказываемся от проекта. Например, недавно у меня был запрос от букмекерской конторы — нужны были продвинутые элементы геймификации для сайта. У нас есть простые механики типа «колеса фортуны» — разрабатывать более сложные шаблоны под заказ мы не готовы.
Но зачастую нужно просто разобраться, в чем конечная цель кастомизации, ее польза для бизнеса. Возможно, есть решения с готовым функционалом. Например, многие думают, что Mindbox подходит только для e-commerce, потому что сущности в платформе называются «продукты», «заказы» и так далее. Но на те же сущности можно разложить процессы почти в любом бизнесе — от B2B до финтеха.
Например, сервис MoneyMan адаптировал логику нашей платформы под выдачу займов. Статус займа обновляется каждую ночь, а у нас предусмотрен лимит — не более ста редактирований заказа. Коллеги настроили автоудаление промежуточных состояний заказа — это никак не повлияло на бизнес-логику, но позволило избежать ошибок.
Полный контроль за данными и производительностью
On-premise по умолчанию дает больше контроля: серверы, данные — все остается в собственном периметре. А если вендор, скажем, уходит из России, компания может и дальше использовать решение, пусть и без поддержки и обновлений.
On-premise-решения чаще выбирают крупные компании с большим объемом данных: им важно сохранять полный контроль. Особенно принципиально это для бизнеса с высоким чеком. Это как раз случай недвижимости: мы владеем чувствительной информацией о крупных тратах клиентов.
Другое дело, что отказаться от on-premise гораздо сложнее, чем поменять одно облако на другое, — это оборотная сторона развертывания решения в своем периметре.
Мы предпочитаем хранить данные в своем периметре. Это дает полный контроль, в том числе над производительностью системы. Выделив достаточное количество железа, можно достичь оптимальных показателей и по пропускной способности, и по отказоустойчивости системы за счет перераспределения нагрузки.
Еще один момент — SLA, соглашение об уровне сервиса. Облачные решения обещают быструю реакцию 24/7, но не все и не всегда обеспечивают доступность системы в нерабочее время. On-premise — это гарантия 100%-ной доступности в любое время. Круглосуточная поддержка требует бóльших затрат на инженеров, но позволяет оперативно реагировать на критические инциденты даже в новогоднюю ночь.
Мы предпочитаем самостоятельно контролировать все системы и наращивать собственную экспертность. Поэтому наш выбор — on-premise, где мы сами отвечаем за надежность, безопасность и доступность инфраструктуры. При этом в работе с on-premise-решениями экспертность в информационной безопасности становится критически важной.
Облачные решения используем, если нет других вариантов. Например, пытались разработать собственное решение для работы с маркетинговыми рассылками, но оставили эту идею из-за сложности. В результате купили облачный Mindbox из-за отсутствия альтернативы под наши требования — используем его для рассылок, проведения тестов и сбора данных по ним.
После февраля 2022 года наш прошлый сервис ушел из России — те, у кого была облачная версия, сразу лишились программы лояльности и рассылок. У нас была on-premise-версия, и мы спокойно могли пользоваться ею еще год, пока не закончилась лицензия.
Когда мы искали новый сервис, то изначально рассматривали только on-premise. Но, к сожалению, такие решения или были слишком дорогими, или не отвечали нашим требованиям, например не могли отправлять каскадные рассылки. В результате выбрали облачный Mindbox и пока не планируем от него отказываться.
Преимущества облака: быстрый запуск, новые фичи, экономия на железе и людях
Быстрый запуск и подключение новых модулей
Развертывание облака и подключение новых модулей происходит за пару кликов, после чего можно сразу приступать к интеграции. Для on-premise сначала придется обсудить бизнес-процессы, закупить и развернуть железо.
Внедрение. Преимущество облачных SaaS-решений в том, что это стандартный продукт с четко прописанными протоколами интеграции, включая API, загрузки и выгрузки данных. Вся техническая документация передается разработчикам клиента — понятно, что именно нужно делать.
А большинство on-premise энтерпрайз-проектов по-своему уникальны: вендоры подстраиваются под особенности клиентов. Из-за этого на развертывание уходит больше времени: нужно обсудить бизнес-процессы, затем написать требования под витрины, которые будут отображать данные, потом протестировать их.
Конечно, все зависит от особенностей конкретного бизнеса, но, по моему опыту, внедрение on-premise занимает в два-три раза больше времени, чем SaaS-решения.
Подключение новых модулей. Облачные решения более гибкие. Там есть готовые модули, поэтому подключение новых опций требует значительно меньше ресурсов, чем с on-premise.
Например, если вы хотите отправлять автоматические рассылки и используете облачное решение, то у вас для этого все есть. Конечно, может потребоваться дополнительная интеграция, но сам процесс уже настроен. Данные собираются и обрабатываются в режиме реального времени, затем срабатывает триггер и рассылки отправляются.
С on-premise гораздо сложнее: для автоматических рассылок нужно много чего настроить. Поясню на простом примере брошенной корзины. Чтобы запустить такую механику, нужно собирать события с сайта или приложения в режиме реального времени и загружать их в высоконагруженный и быстродоступный сервис. Для этого придется купить отдельный realtime-модуль (не всегда, но часто), дорогое железо с оперативной памятью, настроить мониторинги доступности, например с помощью Grafana, а также интегрировать сервис для сбора событий с сервисом для отправки коммуникаций.
Чаще появляются новые фичи
У облачных решений много клиентов из разных сфер — это помогает держать руку на пульсе и вовремя реагировать на запросы рынка. Есть и технические отличия: облачные сервисы могут постоянно выкатывать новые релизы — у on-premise нет такой возможности.
У облачных решений нет проблем с развитием продукта. Они работают со многими компаниями из разных сфер — не нужно ничего придумывать, достаточно слушать, чего хотят клиенты. Происходит постоянный custdev, поэтому облачные сервисы хорошо реагируют на запросы рынка.
Вендорам on-premise-решений сложнее: круг их клиентов ограничен. Хуже всего тем, кто сам разрабатывает продукт. Такие компании реагируют только на собственные запросы и рискуют отстать от рынка. Им нужно придумывать, как собирать информацию о том, что происходит. Это можно решить с помощью найма, но только частично.
Мы в Mindbox разрабатываем продукт на основе обратной связи от клиентов: чтобы реализовать новую фичу, ориентируемся на их боли и потребности. Поскольку продукт развернут в облаке, мы можем быстро доставить обновление всем клиентам. Технически это занимает час, но для надежности действуем итерациями: сначала раскатываем фичу на небольшую тестовую группу, ждем два часа, затем открываем доступ всем клиентам. Облако — это процесс постоянной выкатки релизов, что позволяет быстро внедрять изменения.
Вендоры on-premise-решений выпускают новые релизы реже, обычно раз в месяц. По-другому не получится: нельзя удалить из продукта устаревшую фичу, пока все клиенты не обновятся до последней версии. Если бы on-premise-решения обновлялись так же часто, как облачные, им пришлось бы подстраиваться под график обновлений, согласованный с клиентом, и ждать релиза. В коде накапливались бы устаревшие фрагменты. Они усложняют кодовую базу, замедляют прохождение релизов и тестов, а в конечном счете — всю разработку.
Мы часто общаемся с продуктовыми командами Mindbox и обсуждаем новые фичи. Из последнего — post-view-отчетность. Сначала собрали такой отчет для себя, его увидела наша менеджер, рассказала коллегам, и они сами пришли к нам с вопросами. Мы несколько раз созванивались, обсуждали варианты отчетности и ее важность для нас — сейчас этот функционал уже в работе.
Использование дешевле, нет неожиданных трат на железо
Облачные решения дешевле из-за того, что компании не нужно покупать и поддерживать железо. Эти расходы распределяются на всех клиентов облака — бизнесу не нужно пытаться прогнозировать затраты на несколько лет вперед.
Есть две основные причины, почему облако обычно дешевле:
Облако требует меньше вложений. Серверы закуплены, продукт работает и не требует усилий по развертыванию для каждого нового клиента. Не нужна и выделенная команда по каждому контракту: не поддерживаем разные версии продукта, не разбираемся с конфигурацией клиентских серверов.
Мы делали примерный просчет того, насколько Mindbox был бы дороже для клиентов в случае on-premise: для базы в 1 миллион контактов минимум в пять раз, для базы от 1 до 10 миллионов — в три раза.
Стоимость железа распределяется на всех клиентов. Железо обходится дешевле, потому что нагрузка на него распределяется: клиенты отправляют рассылки в разное время. Получается, что бизнес оплачивает только реальное использование серверов. В случае с on-premise компании приходится оплачивать и простой — на железо приходится существенная часть затрат при выборе on-premise.
В облаке есть возможность динамически увеличивать ресурсы: в пиковые моменты, например во время «черной пятницы», автоматически подключаются виртуальные машины в «Яндекс Облаке». Платим только за время их использования, что также повышает экономическую эффективность для нас и, соответственно, наших клиентов. С on-premise пришлось бы закупать дополнительное железо, которое простаивает бóльшую часть года.
Всегда нужно считать полную стоимость проекта: я могу купить облако, а могу развернуть решение на своих серверах. В первом случае я получу готовый продукт с минимальным time-to-market. Например, для отправки первых рассылок даже не нужна полная интеграция: достаточно выгрузить список клиентов. Сделать это под силу любому начинающему разработчику за полчаса.
Разрабатывать решение своими силами сложно и дорого: нужны высокопрофессиональные разработчики. В результате компания получит «свой» продукт, но вместе с ним и дополнительную единицу администрирования, на которую нужно будет выделять ресурс техподдержки.
Даже при внедрении готового on-premise-решения придется заложить затраты на обслуживание железа, лицензионные платежи, организацию взаимодействия с поставщиками железа и софта. А если речь о продуктах, требующих высокой надежности, например процессинге программы лояльности, обслуживание должно быть круглосуточным, а это существенные дополнительные расходы.
Прогноз стоимости обычно делается на пять лет и учитывает не только рост базы, но и покупку дополнительных модулей, например программы лояльности. Для малого и среднего бизнеса использование облака по умолчанию дешевле, чем on-premise. Но с ростом картина может измениться: при нашем размере базы on-premise-решение обошлось бы дешевле.
Разница в стоимости определяется самой сутью решений. Облако — это покупка только лицензии, масштабирование происходит на стороне вендора. С on-premise нужно заложить стоимость не только самого решения, но и железа, а также затраты на его поддержку и обслуживание.
Прогноз нужного количества железа и его конфигурации (так называемый сайзинг) — сложная задача. Я много раз сталкивался с ситуацией, когда бизнес ошибался с сайзингом и оказывалось, что при растущей базе железо не вытягивает запросы маркетинга. Возникает необходимость докупать или арендовать железо.
On-premise требует и постоянной поддержки: вам потребуется команда, состоящая из системных администраторов, data-инженеров, DevOps-инженеров, аналитиков и специалистов по ETL-процессам (они перекладывают данные в нужную структуру), а также сильная служба информационной безопасности.
Ниже потребность в ИТ-ресурсах, экспертизе в безопасности и управлении инфраструктурой
Безопасность и поддержка облачных решений обеспечиваются вендором — компании не нужно нанимать дорогих дефицитных специалистов и развивать собственную экспертность.
У малых и средних предприятий может не хватать ресурсов, чтобы обеспечить штат экспертами в узкоспециализированных отраслях ИТ и кибербезопасности. Для таких компаний облачные решения и услуги становятся спасением, поскольку с их использованием исчезают затраты на поддержание собственной инфраструктуры, а также проблемы найма.
Если у вас большой штат специалистов по кибербезопасности и управлению инфраструктурой, можно рассмотреть вариант on-premise — он даст больше контроля над продуктом и сервисом. Правда, в ИТ большой дефицит специалистов, так что поиск нужных людей может стать непростой задачей.
Мы в «Додо» стараемся использовать облачные решения, а не on-premise, потому что хотим заниматься своим делом, тем, что хорошо умеем. А хорошо умеем мы делать продукт для пиццерий — франчайзи и клиентов. У нас есть собственная информационная система Dodo IS — разрабатываем ее максимально надежной и безопасной. А хостинг, работа с железом, менеджмент серверов — не наша экспертиза, и мы стараемся не брать на себя лишнюю работу.
Нам эффективнее делегировать вопрос безопасности клиентских данных. У Synergetic просто нет такой экспертизы, как у облачных платформ, где команда информационной безопасности следит за происходящим и при необходимости готова принять нужные меры.
Проще восстановить данные после взлома или сбоя во внутреннем периметре
Если в собственной инфраструктуре компании происходит сбой, то за бэкапом данных можно обратиться в облачный сервис.
За последние полгода в Mindbox трижды обращались клиенты с просьбой передать им данные для восстановления собственных баз. Причиной потери данных может стать взлом или технический сбой, например при критической ошибке разработки.
В двух из трех случаев Mindbox был единственным сервисом, который продолжал функционировать. И благодаря тому, что расчет заказов для касс происходит на нашей стороне, продажи в офлайне не останавливались.
На что обратить внимание при выборе решения
Чтобы выбрать технологию для автоматизации маркетинга, приходится учитывать множество параметров: требования к функционалу, стоимость использования, сложность интеграции и другие технические детали, о которых в обычной работе директору по маркетингу задумываться не приходится. Помимо этого, для каждого класса решений есть свои критерии выбора — собрали их в список.
Критерии при выборе on-premise
Соответствие бизнес-целям и процессам компании
Нужно сравнить цели компании на два-три года минимум с тем, какие возможности предоставляет on-premise. Иначе вы можете попасть в ситуацию, когда решение будет тормозить ваше развитие, а переинтегироваться будет слишком дорого и сложно.
Например, вам может понадобиться программа лояльности или автоматические рассылки в режиме реального времени. Или, возможно, вы планируете перейти от скидочной к балльной программе лояльности — у вас должно быть четкое видение того, будет ли нужная опция в продукте.
Нет уязвимостей в коде
Компания-вендор может быть сертифицирована, например по ISO 27001. Но это не гарантирует информационную безопасность при развертывании внутри контура: у вендора нет доступа к вашей инфраструктуре и процессам. Поэтому при выборе on-premise ответственность за безопасность инфраструктуры ложится на плечи заказчика. Единственное, что можно сделать с точки зрения продукта — независимый аудит исходного кода на уязвимости. Аудиторы дают рекомендации, а после устранения уязвимостей делают повторное заключение.
Доступ к серверам
On-premise — необязательно полностью изолированный продукт: доступ для установки и настройки может быть у инженеров вендора. Этот фактор нужно учесть в модели угроз — в документе с перечнем всех используемых сервисов и возможных рисков. В итоге может оказаться, что риски равны при обоих вариантах развертывания. Стоит также продумать безопасные входы для инженеров поддержки и прописать юридические аспекты.
Поддержка продукта
Очень важно, как on-premise-решение сопровождается после покупки. Сюда входит все — от обновления продукта и устранения уязвимостей до доработки фичей.
Например, недавно мы хотели купить одно on-premise-решение, но оказалось, что вендор не планирует устранять существующие уязвимости, потому что сфокусирован на развитии облака. Нас не устраивает такой подход.
При выборе on-premise важно понять, как происходит обновление продукта — как часто и насколько сложно. Если обновление бесшовное, то есть незаметное для компании, то неважно, как часто оно происходит. Если же обновление происходит не автоматически и требует нескольких часов работы инженера (и обычно ночью, чтобы не останавливать бизнес-процессы), то лучше, чтобы оно происходило как можно реже. В этом случае на стороне вендора должно быть серьезное тестирование уязвимостей новой версии, чтобы не пришлось ее «откатывать».
Работа с обновлениями в нашей on-premise CDP происходит оперативно и отлаженно: вендор присылает файл с обновлением, его быстро «накатывает» DevOps-инженер. Обновления происходят ночью — без даунтайма и влияния на работоспособность. И «откатывать» их назад нам за несколько лет не приходилось: мы получаем отточенные версии без багов. Но так происходит не у всех вендоров — не всегда поддержка on-premise-решений работает качественно и оперативно.
Критерии при выборе облака
Соответствие целям компании
Сначала нужно определить бизнес-требования — понять, зачем, что и как вы будете делать. И только потом подбирать продукт под эти требования: по мановению волшебной палочки никакой вендор не решит задачи бизнеса. Проблема в том, что зачастую продукт покупают без четких целей. Но ни один продукт или решение не определит за вас бизнес-требования.
Требования к безопасности
У нас в «Яндексе» есть список требований к новым сервисам, оформленный в виде анкеты с вопросами. Среди требований — шифрование трафика и логирование событий, связанных с идентификацией и выдачей прав. Для SaaS-решений — изолированное хранение баз компаний-клиентов.
Спрашиваем также про управление обновлениями и инфраструктуру, на которой работает продукт. Сам по себе он может быть суперсовременным, но, если использует устаревшую операционную систему с кучей уязвимостей, нам он не подойдет.
Для нас обязательно, чтобы серверы были расположены на территории России, — это снижает вероятность потери доступа к данным. Важна также возможность дополнительно обезопасить базу, например разграничить права доступа к клиентским данным, замаскировать персональные данные или поставить ограничения на выгрузку.
Если в вашей компании есть служба безопасности, которая может оценить риски, имеет смысл запросить описание системы защиты данных. Другой вариант — заказать внешний аудит. Полезно также поговорить с сотрудником вендора, отвечающим за безопасность. Важно не просто формальное соблюдение стандартов, а то, какие усилия компания прикладывает для обеспечения и роста уровня безопасности.
Мы, например, стараемся постоянно улучшаться: раньше проверяли доступы сотрудников раз в квартал, сейчас используем систему алертов, которая проводит постоянный мониторинг. Или еще пример: в стандарте не указано, какой именно тест проникновения заказывать. Раньше делали относительно простой, он охватывал только админки наших клиентов. Сейчас заказываем расширенный тест, который также проверяет сервисы, обрабатывающие данные.
Официальные сертификаты и аудиты
При выборе решения мы в первую очередь обращаем внимание на сертификаты и выполнение стандартов, гарантирующих информационную безопасность системы. В частности, смотрим на соответствие требованиям 152-ФЗ и международному стандарту ISO27001:2013. Важно также, чтобы проводился аудит всей системы на наличие уязвимостей и его прохождение подтверждалось соответствующими сертификатами.
Мощность решения
Если речь об энтерпрайз-компании, то нужно понять, позволит ли облако обрабатывать весь объем данных: делать запросы и сегментации, в какой гранулярности. И, конечно, оценить, как долго запросы будут обсчитываться. Для этого можно, например, загрузить свою базу гостей и заказов и измерить, как долго будут считаться основные сегменты.
Чувствительность информации и круг пользователей
При выборе облачного решения отталкиваемся от критичности данных и требований надежности. Условно, если нужно разработать чат-бота, который будет присылать информацию об открытии новых пиццерий, используя информацию из открытого API, такую работу можно доверить вчерашнему студенту. Он соберет чат-бота на какой-нибудь no-code-платформе за вечер.
Но если речь идет о персональных данных клиентов или о другой чувствительной информации, то нам нужна компания с именем, выстроенными процессами и технологиями. Аудиты и сертификаты для нас косвенный признак, важнее — репутация, люди и культура.
При выборе нового решения мы смотрим на круг потенциальных пользователей и чувствительность данных, которые будут обрабатываться. Чем шире круг пользователей и выше чувствительность данных, тем строже требования.
В случае с маркетинговыми решениями требования по безопасности заведомо очень высокие, потому что с этими решениями взаимодействует очень много сотрудников: разработчики, отвечающие за интеграцию, менеджеры, настраивающие рассылки и акции. Кроме того, через такие платформы проходят персональные данные клиентов.
Реакция на утечки
При выборе решения очень важна реакция на утечки — даже не сам их факт, потому что гарантии 100%-ной безопасности нет ни у кого, особенно во время нынешней волны кибератак. В идеале компания должна сразу опубликовать информацию об утечке и рассказать, что утекло и как, какие действия предприняли для улучшения своей системы.
Безопасность on-premise и облака
Традиционно в России меньше доверяют облакам, чем on-premise, хотя с точки зрения безопасности между ними нет принципиальной разницы.
Мне кажется, что идея хранить данные в своем периметре — пережиток прошлого и не гарантирует безопасности. Публикации об утечках информации в крупных компаниях появляются постоянно, и это только публичная информация, реальность намного хуже — это видно по количеству спам-звонков. А если крупные компании, которые допускают утечки, при их уровне информационной безопасности не могут гарантировать сохранность данных, то что уж говорить о компаниях малого и среднего бизнеса с гораздо более низким уровнем ИБ.
По моему мнению, выбирать нужно не между облаком и on-premise как таковыми, а ориентироваться на пользу для бизнеса. Собственная разработка точнее учитывает потребности конкретной компании. Но чтобы такое решение стало сопоставимым по качеству с тем, что разработано специализированной компанией, должно пройти время. Time-to-market облаков несопоставимо быстрее, поэтому я апологет таких решений, особенно когда нужен быстрый запуск.
Чтобы обеспечить безопасность данных при выборе облачного решения, достаточно ориентироваться на репутацию вендора и проверять базовые характеристики, например количество утечек и судебных тяжб, а также обсудить способы защиты информации. Естественно, защита данных должна соответствовать их категории и чувствительности потери для бизнеса.
Идея, что чувствительные данные могут храниться на чужих серверах или в облаке, а не на собственном железе в соседней комнате, все еще не нравится российским безопасникам. Важно помнить, что ни облако, ни on-premise — не гарантия защиты от утечек. А дальше вопрос к пользователям: читали ли они инструкции, используют ли пароли сложнее, чем 123456.
Главная проблема в том, что традиционно в России строят защиту от внешнего атакующего. Но утечки происходят и по вине сотрудников. Бывает и комбинация факторов. Например, бывший сотрудник, у которого забыли отобрать права: он атакует снаружи, но по факту действует как инсайдер.
Для «Здравсити» нет принципиальной разницы, облачное это решение или on-premise. В нашей области нет обязательного требования хранить данные на своих серверах, а обеспечивать безопасность нам помогают внутренние процессы и регулярные аудиты.
Сомнения компаний, которые не готовы отдавать данные в облако, можно свести к четырем основным пунктам.
В работе мне часто приходится сталкиваться с опасениями бизнеса относительно безопасности облачных решений. Ниже расскажу, какие из них правдивы, а какие беспочвенны.
1. В облаке выше риск утечки данных?
Уровень надежности и безопасности облачного сервиса зависит от размера вложений и качества процессов вендора. При выборе посоветовал бы ориентироваться на то, с какими клиентами работает вендор. Если в портфеле есть крупные федеральные сети, это хороший признак: у таких компаний обычно сильная служба безопасности, которая тщательно проверяет вендоров.
2. Облачный сервис использует данные для обогащения чужой клиентской базы?
Такой риск действительно есть, поэтому нужно уточнять правила конкретного вендора. Мы, например, храним базы клиентов изолированно: для каждого клиента есть свой экземпляр продукта и только у него есть доступ к базе данных.
3. Не все компании имеют право по закону использовать облачные решения?
Действительно, в облаке нельзя хранить особые категории персональных данных, к которым относится банковская и медицинская тайны. Но это не значит, что запрет распространяется на все данные банков и больниц.
Так, банки могут запускать попапы на сайте для привлечения новых клиентов, отправлять массовые рассылки без персонализации или использовать облачный сервис просто как шлюз для отправки с сегментацией на своей стороне.
Медучреждения чуть более свободны в работе с персональными данными, если они не затрагивают медицинскую тайну. Они, например, могут предлагать клиенту записаться к врачу, если тот просматривал сведения о нем на сайте (аналог брошенного просмотра в e-commerce). Или персонализировать рассылки на основе пола и возраста, например отправлять письмо о профилактике рака груди женщинам определенного возраста.
4. Если передавать данные по выручке и заказам стороннему решению, то доступ к ним получит Федеральная налоговая служба?
Некоторые компании хранят данные на своих серверах за рубежом — это уловка, чтобы до них не дотянулась налоговая. В этом смысле облако прозрачнее: проверяющий действительно имеет право прийти к вендору и запросить данные. Тут я ничего не могу посоветовать, кроме «белого» ведения бизнеса.
