Безопасно ли переносить наши данные в облако или лучше хранить их на собственном сервере?

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

Собственный сервер и облако: в чём реальная разница?

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

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

Короче говоря, собственный сервер означает «защищаем сами»; но если никто этим реально не занимается, данные могут быть защищены хуже, чем кажется.

Кто что защищает? Разделённая ответственность

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

Резервное копирование: самая забываемая половина безопасности

Безопасность — это не только защита от злоумышленника, но и защита от потери данных. Может выйти из строя диск, сотрудник может случайно удалить папку, программа-вымогатель может заблокировать файлы. В таких случаях единственное спасение — регулярная резервная копия, хранящаяся в отдельном месте. Вопросы, которые нужно задать:

• Как часто делается резервная копия?
• Хранится ли резервная копия отдельно от места, где находятся основные данные?
• Как долго хранятся резервные копии?
• Когда в последний раз проверялось восстановление из резервной копии?

Последний вопрос особенно важен: резервная копия, которую ни разу не проверяли, — это копия, работоспособность которой не доказана. Где хранятся записи клиентов, записи на приём и записи ассистента в продуктах URİKEM, как часто они резервируются и как долго хранятся, мы открыто описали в разделе безопасность данных.

Доступ: кто может видеть данные?

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

Когда в дело вступает искусственный интеллект

В инструменте на основе искусственного интеллекта возникает дополнительный вопрос: что происходит, когда текст отправляется в сервис ИИ? Эту тему мы отдельно рассмотрели в статье учится ли ИИ на ваших данных. Коротко: объём отправляемых данных нужно сводить к минимуму, в договоре должно быть указано, использует ли поставщик сервиса данные для обучения моделей, а если данные передаются за рубеж, это с точки зрения персональных данных требует дополнительного уведомления и согласия.

Вопросы, которые стоит задать до принятия решения

• В какой стране и на инфраструктуре какого поставщика находятся данные?
• Кто управляет инфраструктурой, а кто — приложением и учётными записями?
• Как часто, куда делается резервная копия и как долго она хранится?
• Кто имеет доступ и как доступ закрывается?
• Если услуга прекратится, в каком формате мы получим данные обратно?

На что обратить внимание

Не принимайте решение на основе общих фраз вроде «облако безопасно» или «собственный сервер надёжнее». Оба варианта безопасны при правильном управлении и рискованны при небрежности. Если вы обрабатываете персональные данные, то место их хранения и передача за рубеж важны и с точки зрения KVKK (закона Турции о защите персональных данных); получите по этому вопросу мнение своего юридического консультанта. Попросите компанию-разработчика, с которой вы работаете, дать письменные ответы на вопросы выше; компания, которая не может ответить, возможно, не знает и того, как защищает ваши данные.

Частые вопросы

Облако безопаснее собственного сервера?

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

Что нужно сделать для резервного копирования данных?

Убедитесь, что резервная копия делается регулярно, хранится отдельно от основных данных и сохраняется в течение определённого срока. Самое важное — время от времени реально проверять восстановление из резервной копии.

Если мы откажемся от услуги, сможем ли мы получить данные обратно?

Это вопрос, который должен быть прописан в договоре с самого начала. До начала работы спросите, в каком формате (например, Excel или CSV) данные будут переданы при прекращении услуги и как они будут удалены после этого.