У меня есть клиенты в индустрии финансовых услуг, которые настаивают на том, что SaaS, размещенный в публичных облаках, таких как Amazon, не так безопасен, как размещение в частном центре обработки данных. Однако я не могу найти конкретных подробностей о том, в чем могут заключаться эти недостатки безопасности. Я могу думать только о двух отличиях:
Для (1) AWS прошел аудит на предмет обеспечения физической безопасности оборудования. Я могу зашифровать все данные в состоянии покоя (жесткий диск и БД) и все данные во внутренней сети (VPC).
Для (2) Cisco и Barracuda предлагают виртуальные устройства безопасности, работающие в AWS. Я могу запустить их в слое перед веб-серверами.
Есть ли какая-то функция безопасности, которую банк может использовать в собственном центре обработки данных, которую я не могу воспроизвести на AWS?
Спасибо.
Это может быть не технический вопрос безопасности, а скорее вопрос полного контроля и (интерпретации) нормативных требований и соблюдения.
В Закон о ценных бумагах и биржах 1934 года (с поправками) содержит Правила 17a-3 и 17a-4 которые относятся к резервному копированию и архивированию электронных записей. Регулирующий орган финансовой отрасли также имеет правила в отношении Сторонних поставщиков, которые в основном гласят, что поставщик финансовых услуг не может освободить себя от обязательств по соблюдению и оттеснить их на Стороннего поставщика.
Таким образом, если Amazon (временно) теряет (доступ) к своим данным, финансовое учреждение по-прежнему несет полную ответственность и не может спрятаться за Amazon и их SLA. В этом отношении для регулируемого бизнеса финансового учреждения гораздо важнее делать это самостоятельно и сохранять 100% контроль.
Более-менее незапланированная перезагрузка Amazon или например Rackspace в их графике, а не в вашем собственном, может восприниматься как довольно большой риск
Техническая проблема заключается в том, что многие основные приложения, используемые финансовыми учреждениями, представляют собой классические приложения, большие монолитные базы данных и приложения с большим количеством транзакций, требующих малой задержки, которые просто не спроектированы для соответствия шаблону, необходимому для успешного облачного приложения.
Amazon Условия использования или не так "плохо", как некоторые облачные провайдеры, но они предлагают только применять разумные и надлежащие меры, призванные помочь вам защитить ваш Контент от случайной или незаконной потери, доступа или раскрытия и привычный отказ от ответственности, за который многие выступают: «ОТСУТСТВИЕ ЗАЯВЛЕНИЙ ИЛИ ГАРАНТИЙ» следует ожидать ...
Если у вас есть физический доступ к машине, вы всегда можете скомпрометировать ее.
С Amazon, имеющим такой доступ, вы на один шаг дальше от взлома, чем когда у вас есть собственные серверы в собственном бункере ... Я имею в виду центр обработки данных.
Им по-прежнему нужно расшифровать ваши данные, но они могут сделать снимок и выполнить дешифрование в автономном режиме (и у них есть огромный дата-центр, ожидающий простоя для выполнения какой-то задачи), и через 5 лет они знают вашего крупнейшего клиента, сколько у него денег, как много он тратит на ваше банковское обслуживание и так далее.
Это проблема не только Amazon. Другие игроки, такие как, например, Microsoft, строят огромный центр обработки данных недалеко от Дублина, совершенно в глуши, но прямо рядом с огромной «хлебной фабрикой» того же размера. Там только хлеб пекут, правда! ;)
Совсем недавно Amazon пришлось перезагрузить часть своей инфраструктуры (они говорили о менее чем 10%: http://aws.amazon.com/blogs/aws/ec2-mainasted-update/) из-за уязвимости в системе безопасности.
Подробности в то время были неизвестны, поскольку они находились под эмбарго.
Теперь ясно, что причиной этого была уязвимость Xen: http://xenbits.xen.org/xsa/advisory-108.html
Цитата:
Неисправный или злонамеренный гость HVM может вывести из строя хост или прочитать данные
в отношении других гостей или самого гипервизора.
Как клиент вы не можете контролировать, где работают ваши экземпляры (например, кто ваши «соседи»).
Банк, имеющий собственный центр обработки данных или арендующий частное облако, может полностью исключить подобный компромисс.
Совершенно очевидно, что злоумышленник может воспользоваться этим нетривиально.
Даже если у него есть такой неизвестный эксплойт, нацелить на отдельный сайт практически невозможно.
Если избегать общедоступного облака из-за этого имеет смысл, так как этот институт в значительной степени зависит от собственной оценки рисков.