Безопасность данных в облаке

Лучше приспособить выделенный сервер. Установить ОС с шифрованием всех разделов. И уже на нём разворачивать свою виртуальную инфраструктуру. На случай перезагрузки LUKS можно будет разблокировать через SSH(unlocking rootfs via ssh login in initramfs).

По поводу п. 2-3, есть некие скептические соображения в FAQ. Режимы дискового шифрования не рассчитывались на то, что противник может наблюдать изменения шифртекста в любой момент времени (даже при редких бэкапах без полной перешифровки всего содержимого). А тем более в облаке, где даже при помощи тайминга можно попытаться собрать какую-то дополнительную информацию.

Можно или передавать полностью зашифрованное сообщение целиком (почта, обмен файлами), или поток шифрованных данных (VPN) между двумя доверяемыми хостами, но нет хорошо обоснованных по стойкости методов для работы с шифртекстом на недоверяемой стороне, в котором идёт поблочная/посекторная работа с файловой системой, даже если ключа у недоверямой стороны нет.

Лучше приспособить выделенный сервер. Установить ОС с шифрованием всех разделов. И уже на нём разворачивать свою виртуальную инфраструктуру. На случай перезагрузки LUKS можно будет разблокировать через SSH(unlocking rootfs via ssh login in initramfs).

Если у противника есть физический доступ к серверу, он может снимать открытые данные с памяти, вытаскивать разными способами ключи шифрования, тот же initramfs временно протроянить.

Физически выделенный или VPS, неважно.
Для критических данных туда можно складывать каждый раз заново перешифровываемый архив, а вот насчёт удалённого подмонтируемого шифрованного диска (даже при условии, что конечно же ключи к противнику никак не попадают) всё равно рискованно.

Это всё слишком теоретические атаки, они слишком далеки от реальных уязвимостей или нет?

Эта и прочие атаки на TLS/SSL — слишком теоретические или нет?

1. В принципе возможно использовать данные в облаке, чтобы они не попали в чужие руки?

Только если данные в облаке хранятся в зашифрованом виде и ключи к ним в облако никогда не попадают.

2. Решае ли данную проблему использование diskcryptor/truecrypt, если ключевые файлы находятся на другой машине, а не в облаке?

Нет. Администратор делает снапшот виртуалки и копирует его, после чего из дампа памяти извлекаются ключи (например программой Elcomsoft Forensic disk decryptor), и расшифровываются виртуальные диски. Можно сделать по-другому, модифицировать снапшот так чтобы внедрить бекдор в внутреннюю ОС, и через него извлечь нужные данные.

3. Решает ли данную проблему использование dmcrypt/luks?

Нет. Концептуально защититься невозможно. Практически – можете попробовать безопасность через неясность, всякие хитрости, трюки и кастомную сборку криптософта с секретной обфускацией. Эти хитрости усложнят выковыривание данных в годном виде (потребуется квалифицированный реверсер), но расковырять снапшот виртуалки – вопрос лишь времени и денег.

— Гость (07/02/2013 14:34) в своём ответе, возможно, путает систему с данными и ключами, целиком развёрнутую во враждебной виртуалке. В то время как мне показалось, что понятие "облако" ТС использовал ради красного словца, а на самом деле просто монтирует там удалённо шифрованный том с данными, не запуская никакой системы с ключами. А расшифровывает по сети на своей локальной доверяемой машине. Т.е. "облако" — это у него просто вариант удалённо монтируемого файлохранилища с локальным шифрованием, когда по сети гуляют только шифрованные данные, но не ключи и не более того.

При этом даже такое использование "облаков" теоретически небезопасно.

Удаленное монтирование блочного устройства через интернет будет слишком тормозным чтобы с ним можно было работать. Поэтому моя телепатия подсказывает что самый первый гость имел ввиду простое шифрование дисков виртуалки на ней же.

имел ввиду простое шифрование дисков виртуалки на ней же

а вы имеете ввиду, что диски гостевой системы шифруются программным обеспечением самой гостевой системы?
так как, шифровать можно 3-мя основными способами:
1. диск *.vmdk (vmware) размещается на зашифрованном разделе или в контейнере.
2. шифрование средствами самой вирт машины (vmware – access control)/
3. программой шифрования, установленной в гостевой системе (как в физической системе).

Вместо предположений лучше бы здесь нашли удобный shell-сервис, подрубились бы с помощью sshfs, запилили бы там трукрипт и заценили скорость в полевых условиях.

есть ощущение, что там либо по инвайтам либо за бабло.

Есть же всякие eCryptFS, Tahoe... не обязательно блочно. Правда, с безопасностью пофайлового шифрования всё, наверное, ещё хуже.

3. программой шифрования, установленной в гостевой системе (как в физической системе).

Для пользователя VDS доступен только этот способ.

Вместо предположений лучше бы здесь нашли удобный shell-сервис, подрубились бы с помощью sshfs, запилили бы там трукрипт и заценили скорость в полевых условиях.

Никаких предположений, все проверено. Абсолютно неюзабельно, сотня мелких файлов может копироваться час. Не важно какая у тебя ширина канала, все решает пинг и только пинг.

Есть же всякие eCryptFS, Tahoe... не обязательно блочно. Правда, с безопасностью пофайлового шифрования всё, наверное, ещё хуже

Пофайловое шифрование в разы юзабельнее за счет префетчинга и локального кеширования.

Tahoe разрабатывался именно как сетевое хранилище с соответствующей моделью угрозы и адаптацией протокола, но вряд ли подойдёт для ТС, которому требуется развёртывание на единственной удалённой подконтрольной системе. Tahoe — штука распределённая.