Облако не отменяет ответственность за данные и доступы

Облако снимает с компании часть тяжёлой работы: не нужно покупать серверы, менять диски и думать, где поставить ещё одну стойку. Но оно не снимает ответственность за данные. Я регулярно вижу опасную подмену: «сервис в облаке» начинают воспринимать как «за всё отвечает поставщик». Это примерно как хранить документы в хорошем архиве и перестать помнить, у кого есть ключи от шкафа.

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

Облако — это не «где-то там»

У любого облачного решения есть две части ответственности. Первая — инфраструктура: дата-центр, питание, сеть, базовая защита платформы. Её берёт на себя провайдер в пределах договора. Вторая — то, чем управляет сама компания: учётные записи, роли, настройки, резервные копии, выгрузки, подрядчики, связки с другими сервисами. Именно во второй части обычно и рождаются неприятные сюрпризы.

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

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

Права доступа живут дольше, чем люди

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

Это не бюрократия ради галочки. Доступ — как ключ от помещения. Если ключей много и на них нет бирок, рано или поздно придётся менять все замки сразу. В IT это обычно происходит в самый неудобный момент: когда надо срочно найти источник ошибки, отключить ушедшего сотрудника или разобраться с утечкой.

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

Отдельно стоит проверить технические учётные записи: роботов интеграций, ключи API, служебные почтовые ящики. Они часто получают максимум прав, потому что «иначе не заработает». На деле им обычно нужен один конкретный путь: прочитать заказ, передать статус, создать карточку. Чем уже права, тем меньше цена ошибки.

Резервная копия — не украшение договора

Фраза «у нас же облако» не отвечает на вопрос, можно ли восстановить нужные данные в нужный момент. У поставщика может быть своя защита от сбоя оборудования, но бизнесу важно другое: вернётся ли случайно удаленная карточка клиента, история согласований, файл договора или настройка процесса. Это зависит от конкретного сервиса и настроек.

Я бы проверял не наличие слова «backup» в презентации, а обычный сценарий. Допустим, вчера вечером в систему загрузили неверный файл и он разошёлся по связанным карточкам. Кто заметит это утром? Как найти точку восстановления? Можно ли вернуть только нужные записи, не откатывая всю работу отдела? Кто имеет право нажать эту кнопку?

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

Интеграции расширяют контур

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

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

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

Данные тоже нужно классифицировать по смыслу

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

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

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

Проверка начинается с обычного рабочего дня

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

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

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

Что я проверяю перед спокойной работой

Мне не нужен многотомный регламент, чтобы понять, есть ли у облачного контура хозяин. Достаточно пройтись по нескольким вопросам:

• Какие сервисы хранят важные данные и кто за каждый из них отвечает?
• Есть ли список администраторов, внешних подрядчиков и служебных учётных записей?
• Как закрывают доступ сотруднику в день ухода или смены роли?
• Какие интеграции могут читать или менять данные?
• Как выглядит проверенное восстановление одного файла, одной карточки и всей системы?
• Где лежат договоры, настройки доменов, платежей и резервных каналов связи?

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

Ответственность нельзя передать кнопкой

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

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