Как предотвратить утечку данных с облачного сервера: рекомендации Алексея Кузовкина
Кузовкин Алексей Викторович – IT-предприниматель, экс-председатель совета директоров группы компаний «Армада». Алексей Викторович обладает колоссальным опытом управления инновационными и IT-проектами.
“Облачными” сервисами в простонародье называют компании, которые готовы за определенную, часто небольшую, плату предоставить пользователю дополнительное место для хранения данных. При этом информация хранится на сервере компании, пользователь не заморачивается обслуживанием серверных мощностей. Быстрое подключение облака позволяет сразу значительно увеличить объем хранилища компании, решать проблемы с обеспечением ресурсами новых проектов.
Итак, применение облачных сервисов имеет следующие преимущества:
● возможность быстро расширить деятельность компании, запустить новые сервисы и проекты без необходимости закупок собственного серверного оборудования;
● снижение расходов на обслуживание техники, отсутствие необходимости ее замены, защиты программными средствами (например, от DDoS-атак);
● повышение эффективности работы, сокращение штата проекта на специалистов по аппаратному обеспечению и другие.
Однако, по законам диалектической логики, любой прогресс должен оплачиваться, иными словами, у каждой медали есть плохая и хорошая стороны. Повсеместное использование облачных сервисов в компании также может иметь следствием возникновение дополнительных опасностей для бизнеса с точки зрения сохранности данных. Ведь в последние несколько лет мир постоянно сотрясают скандалы с утечкой данных, включая чувствительные, с серверов крупнейших мировых корпораций, таких как “Яндекс”.
Проблема конфиденциальности данных
При взаимодействии с облачным сервисом неизменно возникает проблема сохранности конфиденциальных данных. Ведь хранение и обработка информации физически проводится на оборудовании провайдера. Риск того, что он не справится с попытками хищения чувствительной информации, есть всегда.
При этом чаще всего объектами таких атак становятся:
● базы данных;
● виртуальные серверы;
● незащищенные каналы передачи данных;
● секреты, хранилища данных и другие объекты в составе арендованного у провайдера облака.
Снизить риски до нуля не выйдет, однако можно максимально усложнить задачу злоумышленнику, решившему похитить информацию с облачного сервиса, используемого, например, для совместной работы. Могут быть приняты следующие меры:
● шифрование базы данных. Это сделает бессмысленной ее кражу без ключа;
● шифрование каналов передачи данных;
● удаление программного обеспечения провайдера. Часто оно предварительно устанавливается для упрощения управления консолью, однако в таком бизнесе, как, например, банковское дело или платежные системы, это может представлять опасность;
● осуществление непрерывного мониторинга состояния сервера;
● постоянный контроль целостности программного обеспечения;
● обязательное введение многофакторной аутентификации и т. д.
Проблемы с доступом к серверу
Проблемы с доступом к серверу и хранящимся на нем данным могут возникать по разным причинам, не только по вине хакеров. На самом деле более частым препятствием на пути постоянного использования одного облачного сервиса является противодействие провайдера. Он может ограничить доступ к содержимому по разным причинам, которые влияют на его деятельность. Часть из них находится в его компетенции, часть – нет. Отсутствие доступа к серверу по вине провайдера чаще всего связано со следующими причинами.
1. Компания нарушила условия договора. Например, разместила на сервере недопустимую информацию, которая может скомпрометировать поставщика хостинга.
2. На стороне провайдера случился технический сбой или возникла другая проблема, например, истек срок сертификата безопасности. Его нужно продлевать, чтобы сайт беспрепятственно отображался в выдаче поисковых систем.
3. Политические катаклизмы, санкции, которые напрямую запрещают некоторым иностранным компаниям работать с IT-проектом.
4. Другие причины и поводы для отказа от продления договора провайдером.
Когда доступ к облачному сервису утрачен, все данные на нем оказываются недоступными. Если ситуация сворачивания сотрудничества с поставщиком услуг кажется неизбежной, следует заранее озаботиться выводом данных с хранилища на другой сервис или на физический сервер. Специалисты выделяют следующие правила безопасного использования облака:
● всегда создавать резервную копию основных данных. Можно задействовать другой облачный сервис или купить свой сервер;
● не использовать рутовый аккаунт для администрирования проектов на сервере. Рутовой называется учетная запись с самыми широкими полномочиями по облаку (управление архитектурой). Так будет меньше поводов для его компрометирования;
● всегда поддерживать связь с провайдером, следить за обновлениями и новостями компании. Так отказ в пролонгации договора не станет неожиданностью;
● создавать OU для каждого сотрудника, имеющего доступ к облаку, то есть четко разграничивать полномочия и доступ.
Несанкционированное изменение программного обеспечения
Физический контроль над серверами остается у компании, сдающей их в аренду, что в любом случае создает теоретический риск того, что фактические владельцы решат без санкции изменить имеющийся на сервисе программный код. Полностью застраховаться от этого риска нельзя, потому для сотрудничества лучше выбирать проверенные компании с многолетней историей, ведь от качества исходного кода на облачном сервисе будет зависеть и качество работы проекта.
Минимизировать риск можно путем внедрения в работу коллектива непрерывного мониторинга целостности программного обеспечения, а также путем обеспечения полного контроля доверенным лицом репозитория исходного кода.
Что же в итоге?
Использование облачных сервисов в современной экономике — это не прихоть компаний, а необходимость. Только с их помощью можно резко увеличить объем необходимых для расширения проекта ресурсов, ведь IT-проекты часто развиваются взрывными темпами (достаточно вспомнить взлет OpenAI и ее проблемы с наплывом пользователей на серверы).
Использование облака таит в себе несколько опасностей, однако их всегда можно минимизировать путем обеспечения полного контроля над кодом и архитектурой, сведением к минимуму влияния провайдера на процессы управления хранилищем.
