Удаленный защищенный крипто-диск

Привет знатокам криптографии! :)

Сам имел к ней весьма приблизительное представление, хотя и админ.
Но вот пришлось решать проблему. Дело в том, что есть у нас один параноидальный хомячок и он все требовал и требовал поставить ему PGP-диск для каких "особых" бизнес-задач.
В конце-концов он выпросил разрешение у директора, и пришлось нам поставить ему PGP-диск. Влепили ему старую "восьмерку", и теперь он ходит гордый, что "защитился".
А мы админы втихаря посмеиваемся, потому что как только он открывает на своем компе криптодиски, как мы все получаем к ним по сетке свободный доступ к их содержимому как к обычным дискам. В-общем, смехота.
Но вот нам самим понадобилось создать защищенные диски, но чтобы они были по настоящему защищены и по сетке нельзя было залезть в них, как в этот PGP.
Существуют ли вообще подобные решения?

На страницу: 1, 2, 3, 4, 5 След.

Комментарии

—	sentaus (15/04/2011 10:06) профиль/связь <#> комментариев: 1060 документов: 16 редакций: 32

А как уважаемый товарисч собирается закидывать на свой удалённый сервер СA-сертификаты и секретные ключи,

Разумеется никак, поскольку это не нужно.

Посмотрел на ваши ENCFS+SSHFS – вроде оно, но полной уверенности нет, т.к. я не специалист по крипто, нужна подсказка ;)

Я бы смотрел на варианты с пофайловым шифрованием, а не с большим файлом-контейнером. Файл-контейнер легко повредить из-за обрыва соединения. Но честно говоря, я не знаю, есть ли что-либо с таким функционалом под виндой.

—	*Гость* (15/04/2011 10:37) <#>

Разумеется никак, поскольку это не нужно.

Там же всё равно SSH, уязвимый к MITM без сертификатов, не?

—	sentaus (15/04/2011 12:03) профиль/связь <#> комментариев: 1060 документов: 16 редакций: 32

Там же всё равно SSH, уязвимый к MITM без сертификатов, не?

По SSH будут передаваться уже шифрованные (например encfs) данные. Даже если меллори залогинится по ssh, он увидит только шифрованные файлы.

—	*Гость* (15/04/2011 15:02) <#>

Кстати, не вполне понимаю, почему удалённый админ будет иметь полный доступ к серверу. Вы арендуете где-то dedicated-сервер, подключаетесть к KVM-серверу (разумеется, по шифрованному соединению), ставите систему, настраиваете. Откуда вообще возьмётся удалённый админ?

—	unknown (15/04/2011 15:22, исправлен 15/04/2011 15:23) профиль/связь <#> комментариев: 9796 документов: 488 редакций: 5664

На запись – куда? Непонятно. И какие это последствия.

Попросту говоря, админ сможет стереть ваш криптоконтейнер.

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

не вполне понимаю, почему удалённый админ будет иметь полный доступ к серверу. Вы арендуете где-то dedicated-сервер

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

—	*Гость* (16/04/2011 00:56) <#>

Например, есть железки, которые с работающей машины передают дампы памяти по сети

А со спарков — так вообще: можно хардварно и документированно снимать дампы оперативной памяти подключением к определённым разъёмам :)

—	*Гость* (17/04/2011 01:08) <#>

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

А под никсами?

—	*Гость* (17/04/2011 03:12) <#>

Под никсами есть как минимум стандартные варианты с EncFS и eCryptFS. Обсуждалось в /comment3680, /comment3683, /comment30735, а также в комментариях к топику "Шифрованные файловые системы".

—	*Гость* (17/04/2011 15:04) <#>

Файл-контейнер легко повредить из-за обрыва соединения.

И все они тоже боятся этой напасти?

—	*Гость* (17/04/2011 15:41) <#>

Казалось бы, если ФС журналируемая, то не повердится(?).

—	клавиши (17/04/2011 15:56) <#>

Да, но отказоустойчивость за счет журналируемости ФС это уже, как говорится, на крайний случай, фатальный. Может спасти данные, а может и нет, как повезет.

Было бы здорово, если бы криптоконтейнер был изначально спроектирован так, чтобы он был готов на уход пользователя "по-английски" без всяких потерь и других артефактов.

—	*Гость* (17/04/2011 16:14) <#>

Может спасти данные, а может и нет, как повезет.

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

—	SATtva (17/04/2011 16:16) профиль/связь <#> комментариев: 11558 документов: 1036 редакций: 4118

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

—	sentaus (17/04/2011 19:16) профиль/связь <#> комментариев: 1060 документов: 16 редакций: 32

Если журналируются не только метаданные, но и сами данные, то сама ФС не порастёт

И производительность будет сильно хуже.

—	*Гость* (17/04/2011 19:21) <#>

О порче данных в виде открытых на запись файлов при внезапных обрывах – это понятно, и происходит в нашей практике довольно часто, например, как сказал SATtva, при выдергивании вилки из розетки, и это понятно и объяснимо. Но другие данные при этом останутся целыми.

Напугало совсем другое – как сказал нам товарищ-гость,
"Файл-контейнер легко повредить из-за обрыва соединения".

А это, если оно произойдет, уже куда страшнее, так в поврежденном контейнере погибнут ВСЕ данные, которые туда сложили.

Может, товарищ-гость ошибся или имел в виду что-то другое?

На страницу: 1, 2, 3, 4, 5 След.

Ваша оценка документа [показать результаты]