Чем важнее для вашего бизнеса приложение, которое вы передаете в ЦОД, тем тщательнее должен прорабатываться вопрос безопасности.
Когда речь заходит о безопасности клиентских данных и приложений, размещенных в ЦОДе, чаще всего имеется в виду конфиденциальность данных: владелец информации опасается, что его данные могут похитить. В модель угроз входят действия как злоумышленников, которые могут взломать защиту ЦОДа и завладеть данными, так и сотрудников и администраторов самого ЦОДа и даже представителей многочисленных проверяющих органов, которые могут получить доступ к информации по решению суда и скопировать данные не только конкретного приложения, но и всех остальных.
Обычно подобный риск устраняется посредством применения комплексной системы шифрования, когда ключи находятся лишь у владельца информации, а в ЦОДе данные хранятся уже зашифрованными. Такая организация хранения не мешает сотрудникам ЦОДа проводить служебные операции, например архивирование, но делает бессмысленным хищение данных любым способом.
Однако централизация привносит и новые риски, затрагивающие прежде всего доступность. Очевидно, что у команды коммерческого ЦОДа возможностей по обеспечению информационной безопасности больше, чем у конкретной компании, размещающей там свои данные, — как по количеству квалифицированных специалистов, так и по разнообразию оборудования, предназначенного для защиты данных. Но и атакам КЦОДы подвергаются намного чаще, поэтому появился новый вид угроз — вероятность оказаться жертвой атаки на другого клиента.
В первую очередь это касается DDoS-атак. Обычно злоумышленники не мелочатся, генерируя атаку сразу на всю систему защиты ЦОДа. В результате не являющиеся целью атаки «соседи» по ЦОДу тоже становятся недоступны. DDoS-атаки нередко используются как способ отвлечения внимания службы безопасности от хакерских атак, которые часто направлены на конкретного клиента ЦОДа, но в итоге может оказаться скомпрометированной вся инфраструктура.
К тому же надо четко понимать, что как бы ни была хороша защита ЦОДа, ее возможности по обеспечению безопасности сторонних приложений на прикладном уровне ограниченны. К сожалению, нельзя делегировать ЦОДу защиту приложений и данных в них целиком и полностью — если в приложениях имеются уязвимости, в каком бы защищенном ЦОДе они ни размещались, их взлом — вопрос времени.
И уж тем более ЦОД не защитит от мошенничества, когда для взлома приложения используются недекларированные возможности, оставленные разработчиками случайно или намеренно. Конечно, «продвинутые» ЦОДы применяют различные сканеры уязвимостей для анализа защищенности обслуживаемых приложений, но, даже если они что-то обнаружат в вашем приложении, оперативно исправлять недочеты — ваша задача.
Поэтому, выбирая ЦОД, нужно беспокоиться не только о его надежности с точки зрения резервирования ключевых элементов инфраструктуры. Необходимо выяснить, сколько имеется эшелонов защиты, поинтересоваться их качеством, способами изолирования приложений, возможностью получения выделенного канала и получить рекомендации по исправлению уязвимостей. Кроме того, стоит изучить имеющуюся статистику попыток проникновения в инфраструктуру ЦОДа и наиболее часто атакуемые приложения, размещенные в нем.
И чем важнее для вашего бизнеса приложение, которое вы передаете в ЦОД, тем тщательнее должен прорабатываться вопрос безопасности.