Хоть что-то конкретное про безопасность ВМ 2

Порадовал развернутый комментарий к записи Хоть что-то конкретное про безопасность ВМ:

arsenyspb>Интересно как картина IOPS меняется

Кто мешает проверить? :)

Вообще спасибо Михаилу - тема хоть и не новая, но в интересном разрезе (впору ветку создавать на руссишгруппенфоруме Вари, бо в формате комментов блога оттянуться не удастся - утонет пост быстро). Могу лишь отметить, что дисковое криптование пригодно не только для защиты данных от компрометации при краже VM`ки (так же как до этого правильные пацаны шифровали быкапы) - оно так же убережёт от компрометации собственно "рабочий" (активный) набор данных на самих боевых серверах.

За себя могу сказать - ТС продукт неплохой, использовал его на платформах Вин и Мак (и слегка - на лине). На физмашинах современного класса (C2D, C2Q) трансфер на крипторазделах теряет не более 10-15% на массированных дисковых операциях (копирование больших объёмов данных) - скажем, "чистый" трансфер на терабайтной Барракуде с примерно 90-100МБ/с падает до 75-80МБ/с на Барракуде, криптованной ТС (AES). Загрузка проца при этом не превышает 20% на одном из ядер. IOPS`ы пока не мерил (не успел). Также имею одну VM`ку с XP в роли лёгкого SQL-сервера (MySQL), полностью зашифрованную ТС - замеров не делал, но со своими задачами она справляется не хуже, чем было до криптования.

По поводу обсуждаемой заметки...
Всё написано правильно, но варианты защиты инфы далеко не исчерпываются описанной схемой. Например, если СХД позволяет, можно закриптовать его volume, положить на него чувствительную инфу и отдать по NFS в распоряжение VM`ки (лежащей на соседнем volume, можно и некриптованном). Тогда спёртая VM`ка, будучи запущенной во вражеском логове, не увидит штатного NFS-ресурса и лежащих на нём данных.
Если СХД есть "чОрный ящик" от крутого вендора, не позволяющий поставить на себя ТС, то можно отдать её LUN как iSCSI нашей VM`ке, закриптовать полученный "диск" и положить на него данные - при таком раскладе можно даже не использовать описанное в статье FDE (тогда решается проблема автостарта): достаточно сделать автомонтирование криптотома iSCSI в стартующей VM`ке с привязкой к своей сети (точнее, её доверенному ресурсу) - тогда опять же спёртая VM`ка будет долго и безуспешно искать криптотом iSCSI в чужой сети.

Maria Sidorova>
Антон, не соглашусь.
...
2. Если ресурсы попадают под 152 ФЗ, то это требование распространяется не только на государственные учреждения.

Мария, Вы, конечно, формально правы, но ФЗ №152 - "мёртвый закон" (мёртвый во многих смыслах). Я понимаю, что в дискуссиях о нём Вы играете на своём поле (и я Вам не соперник), но длительный мониторинг ресурсов по ПДн укрепил меня в мысли, что или этот "закон" сожрёт всё, до чего дотянется, или сам будет сожран (как вариант - выхолощен).
Мне близка точка зрения коллег из области ИБ о том, что в разрезе ФЗ 152 голова у нас болит не столько как защитить данные, сколько как защититься от регуляторов. Соответственно мы, технари, будем защищать данные, а наши коллеги-юристы пусть думают, как при таких раскладах защищаться от регуляторов. :)

С уважением,
Umlyaut.