У небольшой компании, которая продаёт и устанавливает кухни, была обычная CRM: клиенты, адреса, замеры, история заказов и переписка. Владелица Марина не планировала строить ИТ-отдел. Когда менеджер перешёл на удалёнку, а ноутбук с базой начал зависать, она выбрала облачный сервис: подписка дешевле нового сервера, заходить можно откуда угодно, а провайдер обещал резервные копии и обновления.
Первые недели всё действительно работало. Потом клиент попросил объяснить, где хранятся его данные, и Марина поняла, что не может ответить точно. Внешний настройщик, который помогал переносить базу, сказал, что у него есть «общий доступ для поддержки». А в личном кабинете обнаружилось уведомление: часть резервных копий размещается в зарубежном сегменте, и тариф меняется.
Каждая из этих новостей по отдельности не выглядела катастрофой. Вместе они складывались в неприятную картину: компания не знала, где именно лежат данные, кто их видит и восстановятся ли они, если что-то случится. При этом юридически Марина по-прежнему оставалась той, кто отвечает за базу перед клиентами.
Облако не отменяет обязанности оператора. Оно меняет место и способ их выполнения, и именно поэтому переезд стоит планировать не как покупку подписки, а как передачу части работы с данными. Дальше разберём, что при этом нужно проверить, начиная с самого простого вопроса: где находится база.
Почему облако не отменяет вопрос «где данные»
Облако кажется местом без адреса. На самом деле у него есть страны, дата-центры, юрисдикции и люди, которые имеют доступ к железу. Закон о персональных данных требует, чтобы при сборе и хранении данных граждан России использовались базы данных на территории России. Это требование называют локализацией, и оно относится не к вывеске провайдера, а к тому, где физически размещена база.
Из этого не следует, что иностранное облако под запретом. Закон требует российскую базу и отдельно регулирует трансграничную передачу данных. Поэтому вопрос звучит не «наш ли это провайдер?», а «где находится основная база, где её копии и куда уходят данные при поддержке и обновлениях?».
У Марины основная база оказалась в России, а часть резервных копий — в зарубежном сегменте. Это не автоматический приговор, но и не техническая мелочь: копия содержит те же данные и участвует в обработке, поэтому её место хранения нужно оценивать отдельно. Если бы за границей оказалась сама база, ситуация была бы уже другой, и разбираться пришлось бы не с настройками тарифа, а с законностью обработки.
Провайдер редко хранит всё в одном месте. Крупный сервис может держать основную площадку в России, а резервную — в другой стране, привлекать подрядчиков для поддержки и использовать зарубежные инструменты мониторинга. Это нормальная инженерия, но оператору нужно знать маршрут данных, а не только город, указанный на сайте. Поэтому перед подписанием договора стоит попросить схему: где хранится база, где копии, кто имеет доступ и какие подрядчики участвуют.
Это звучит просто, пока не столкнёшься с ответом «всё в облаке». Такой ответ ничего не объясняет. Облако — это не одно место, а набор сервисов, и у каждого может быть свой контур. Пока Марина не получила схему, она не могла ни оценить риск, ни ответить клиенту.
Кто остаётся оператором, когда сервер чужой
Даже если база находится в России, ответственность никуда не переезжает. Оператор — тот, кто решает, зачем собираются данные и что в них входит; обработчик — тот, кто выполняет обработку по поручению оператора. В этой истории оператор — компания Марины, потому что именно она решает, какие поля собирать, зачем хранить историю заказов и сколько лет держать переписку.
Облачный провайдер и настройщик — обработчики, пока действуют в рамках поручения. Они могут хранить, передавать, делать копии и поддерживать работу системы, но не должны придумывать собственную цель для базы. Если провайдер начнёт использовать данные клиентов для собственного маркетинга или продажи аналитики, граница поручения исчезнет, и это станет отдельной проблемой, которую нельзя решить одной строкой в договоре.
У провайдера при этом есть свои процессы: биллинг, поддержка, анализ нагрузки. В них он может выступать самостоятельным оператором, и эту границу нужно понимать. Для Марины это означало практическую вещь: недостаточно выяснить, кто «владелец» базы. Нужно понять, кто именно может её видеть, кто отвечает за инцидент и к кому идут претензии клиентов.
Претензии пойдут к компании Марины, даже если ошибку допустил настройщик. Клиент оставлял данные магазину, а не сервису; регулятор тоже видит оператора, который организует обработку. Передать можно работу, но не ответственность. Эта фраза звучит как юридическая формула, но у неё есть очень практическое следствие: именно Марина должна была проверить, кому и какой доступ выдаёт.
Отсюда следующий вопрос. Если отвечать всё равно компании, то обещания провайдера нужно превратить в обязательства, которые можно проверить. Для этого и нужен договор — не как формальность для бухгалтерии, а как описание того, что произойдёт в плохой день.
Что должно быть в договоре, чтобы облако не стало дырой
Типовой договор на облачную подписку устроен удобно для провайдера: он может менять тариф, привлекать подрядчиков и обновлять условия, а данные клиента остаются «материалом» внутри сервиса. Для обычной работы этого достаточно, но для персональных данных — нет. Закон требует оформить поручение обработки договором и перечислить в нём действия с данными, но конкретный порядок взаимодействия стороны определяют сами. На практике договор должен отвечать не только на вопрос «сколько стоит», но и на вопросы «что можно делать с данными», «где они лежат» и «что будет, когда мы захотим уйти».
Сначала фиксируется предмет поручения: какие данные, для какой цели, какие действия разрешены и на какой срок. Без этого невозможно понять, вышел ли провайдер за рамки. Дальше — место хранения и порядок уведомления о его смене. На практике провайдер должен сообщать о переезде заранее, а не ставить перед фактом; у компании должно быть право отказаться и забрать данные без потери.
Отдельного места требует цепочка подрядчиков. Крупный сервис почти никогда не делает всё сам, и в договоре должно быть понятно, кого он привлекает, как сообщает о новых субобработчиках и может ли оператор возразить. Это не недоверие к провайдеру, а способ не узнать через год, что поддержку базы выполняет компания, о которой никто не слышал.
Дальше идут доступ и безопасность. Формулировка «обеспечить конфиденциальность» описывает намерение, но не даёт ответа на вопрос, кто именно откроет базу и по какому основанию. Нужны именные учётные записи, ограничение прав, ведение журналов, порядок отзыва доступа при увольнении и понятный список мер, которые провайдер применяет. Если провайдер отказывается обсуждать эти вещи, это уже результат проверки, а не повод отложить её.
Наконец, инцидент и выход. На практике в договоре важно закрепить срок и адрес уведомления об утечке или сбое, состав сведений и обязанность помогать расследованию. После окончания договора данные возвращаются в пригодном формате, копии уничтожаются, а доступы закрываются; хорошо, если есть письменное подтверждение. У Марины ничего этого не было, поэтому уведомление о смене условий она получила как неприятную новость, а не как событие, к которому можно подготовиться.
Как ограничить доступ и не потерять следы
Договор задаёт правила, но не мешает людям обходить их в спешке. Самый незаметный риск в этой истории — не зарубежная копия, а общий доступ. Настройщик получил одну учётную запись с правами администратора, потому что так было быстрее. Пароль знали ещё два человека: один помогал с переносом, второй остался на поддержке. Формально доступ был «у подрядчика», фактически его нельзя было посчитать по именам.
Общий доступ плох не тем, что кто-то обязательно украдёт данные. Он плох тем, что в момент вопроса невозможно ответить, кто что видел и выгружал. Если клиент пожалуется на звонок мошенника, компания не сможет проверить, откуда взялся номер. Поэтому доступ должен быть именным, с минимальными правами: человеку, который настраивает отчёты, не нужна возможность выгрузить всю базу, а сотруднику поддержки — постоянный доступ к архиву.
Дальше нужен порядок, который не зависит от памяти руководителя. Доступ выдаётся по заявке, на конкретную задачу и на ограниченный срок; после работы он закрывается. Для подрядчика полезна отдельная учётная запись, а не аккаунт сотрудника компании, и правило «сначала заявка, потом вход». Это звучит бюрократично, но именно такая скучная процедура позволяет потом восстановить картину.
Журналы — вторая половина этой работы. Нужно фиксировать, кто входил, когда, какие действия выполнял и откуда; для облака особенно важно, может ли оператор получить эти сведения от провайдера. Журнал не предотвращает утечку, но сокращает время на ответ. А в инциденте время решает: пока компания выясняет, кто и что делал, данные продолжают уходить.
Марина начала с малого: закрыла общий аккаунт, завела именные записи, ограничила выгрузку и попросила у провайдера отчёт о входах. Это не сделало облако безопасным целиком, но убрало главную неопределённость. Заодно выяснилось, что настройщик всё это время пользовался своей почтой для пересылки выгрузок, и это тоже пришлось менять. Именно так и работает ограничение доступа — не одним приказом, а последовательным сужением того, что человек может сделать без следа.
Почему копия в облаке не равна резервной копии
Даже идеальный порядок в доступах не спасает от ошибки, после которой данные нужно вернуть. Резервная копия в облаке звучит как гарантия: провайдер большой, у него наверняка всё настроено. Но копия внутри того же сервиса не всегда спасает от ошибки, компрометации аккаунта или удаления по запросу. Если администратор удалил контакты и очистил корзину, а версии хранятся ограниченно, «резервная копия» может оказаться не тем, что нужно.
У Марины был именно такой случай. Сотрудник случайно удалил карточку крупного клиента вместе с историей заказов; восстановление через поддержку заняло несколько дней, а часть переписки не вернулась. Только тогда выяснилось, что резервные копии делаются, но их восстановление никто не проверял. Провайдер не обманывал: копии действительно были, просто компания не знала, что именно они содержат и сколько времени займёт возврат.
Из этого следует практическое правило: проверять нужно не наличие копии, а восстановление. Регулярно стоит поднять копию в отдельное место, открыть последний заказ и убедиться, что данные читаются. Полезно заранее ответить на два деловых вопроса: сколько времени компания может работать без CRM и сколько последних изменений готова потерять. Ответы определяют частоту копирования и допустимую задержку, а не наоборот.
Есть и более тонкая проблема. Копия, которая лежит в том же аккаунте и удаляется теми же руками, не защищает от худшего сценария. Нужна копия, которую нельзя изменить или удалить из основного контура, с отдельными правами и отдельным местом хранения. Это может быть версия с защитой от удаления или выгрузка в другое хранилище; важно не название, а независимость.
У облака есть преимущество: провайдер может делать копии чаще и хранить их дольше, чем небольшая компания своими силами. Но преимущество работает только тогда, когда оператор понимает, что именно ему обещают. Марина попросила не общую фразу «бэкапы есть», а описание: что копируется, с какой периодичностью, где хранится, сколько времени восстанавливается и может ли она сама инициировать проверку. После этого разговор стал предметным.
Когда облако противопоказано — и что делать дальше
Теперь вернёмся к тому, с чего началась история. Через несколько месяцев провайдер сообщил, что меняет условия: обслуживающее юридическое лицо будет другим, часть тарифов исчезнет, а данные нужно перенести в новый контур до определённой даты. Это не обязательно уход с рынка, но зависимость та же: компания должна перестроиться в чужом графике. У Марины не было ни готового плана, ни уверенности, что выгрузка пройдёт без потерь. Это и есть главный риск облака — не обязательно утечка, а зависимость от чужого решения в момент, когда вы к нему не готовы.
План выхода нужен до входа. Он отвечает на простые вопросы: в каком формате можно забрать данные, кто отвечает за перенос, сколько это займёт, что произойдёт с копиями и как быстро закроется доступ. Хорошо, если есть проверочная выгрузка небольшой части базы: она показывает, читается ли формат и хватает ли полей. Если провайдер не может объяснить, как забрать данные, это не мелочь, а свойство сервиса, которое проявится в самый неудобный момент.
Оценка риска начинается не с длинного опросника, а с карты данных. Нужно выписать, какие сведения лежат в CRM, кто их вводит, кому они нужны для работы и что произойдёт, если они станут недоступны в разгар сезона. Дальше к каждому пункту добавляется вопрос о провайдере: что он делает с этими данными, какой у него доступ и что он обещает при сбое. Так становится видно, где облако экономит силы, а где просто переносит зависимость.
Когда облако противопоказано? Универсального запрета нет, но есть ситуации, где оно требует зрелости, которой у компании нет. Если речь идёт о специальных категориях — например, данных о здоровье или убеждениях, — цена ошибки выше, и общий облачный тариф с настройками по умолчанию не подходит. Если закон или отраслевые правила требуют конкретного контура, это нужно проверять отдельно, а не решать по названию сервиса. И если у компании нет человека, который отвечает за доступы, договор и восстановление, облако не создаст этого человека само.
Есть и более обыденное противопоказание: критичный процесс, остановка которого недопустима, при полном отсутствии ресурсов на разбор инцидента. В таком случае можно начать с менее критичной системы, а не переносить сразу всю базу. Облако — не экзамен на современность; это решение, у которого есть цена в виде управления подрядчиком. Если этой цены не видно, значит, её просто ещё не посчитали.
Марина в итоге не отказалась от облака. Она составила карту данных, переписала договор, разделила доступы, настроила проверку восстановления и договорилась о тестовой выгрузке. Часть функций она вернула на собственный сервер, потому что они оказались слишком тесно связаны с критичным процессом. Это не поражение и не победа облака, а нормальный результат: компания поняла, что именно она доверяет провайдеру, а что оставляет под своим контролем.
Теперь можно ответить на вопрос из заголовка. Переносить можно не «всё» и не «ничего»: можно переносить данные, для которых выдерживаются локализация, договор, доступ и восстановление. Нельзя переносить ответственность — она остаётся у компании, даже если сервер, поддержка и резервные копии находятся у подрядчика. Поэтому переезд стоит оценивать не по удобству интерфейса, а по тому, может ли компания назвать место хранения данных, ограничить доступ, восстановить копию и забрать базу при необходимости.
Если на эти вопросы есть ответы, облако становится управляемым инструментом, а не чёрным ящиком. Если ответов нет, удобный сервис просто переносит старые проблемы в чужую инфраструктуру и делает их менее заметными. Разница между этими двумя состояниями — не в технологии, а в том, сколько вопросов компания задала до того, как нажать «перенести».
Начать разбор стоит с закона о персональных данных простыми словами, затем посмотреть историю утечки через подрядчика и карточку 152-ФЗ. Если встретился незнакомый термин, его значение есть в словаре. Эти материалы помогут пройти путь от общего понимания закона до конкретных вопросов к своему провайдеру.