РегистрацияРазмонтирование криптодисков по тревоге
Как известно, для обеспечения практической безопасности недостаточно стойкого шифрования данных, не менее важным является быстрое прекращение доступа к ним в случае тревоги. Анализируя известные мне случаи, я пришел к выводу, что далеко не всегда удается размонтировать криптодиски в момент опасности. Это существенная брешь в практической безопасности, и с этим надо что-то делать.
Поэтому мне хотелось бы обсудить эту проблему и различные способы ее решения, для последующей реализации наиболее удачных идей в DiskCryptor. Для начала предлагаю следующие варианты подачи тревоги:
1 – Тревожная кнопка.
2 – Появление/исчезновение определенных файлов (подача тревоги посредством подключения/отключения внешних носителей, по сети, и.т.д.)
3 – Пропадание связи с контрольным сервером.
4 – Подача тревоги через удаленный сервер (автоматическая тревога при пропадании связи с ним).
Обсуждаем эти варианты и предлагаем свои.
комментариев: 11558 документов: 1036 редакций: 4118
А если серьезно то тревожная кнопка самое надежное плюс запараллелить ее с герконами на двери в "компютерное убежище":)
ЗЫ Не забываем про крепкие двери и бронированные окна!
Уже тестируется консольная версия, но есть задержка с разработкой GUI, поэтому релиз будет как только, так сразу.
тут
А вообще, по зрелому размышлению, для любого из этих вариантов решений, есть рождаемые ими проблемы. В частности – ложные срабатывания. И если вы думаете, что это не такая уж проблема, то смею настаивать на своём мнении: без действенной "защиты от дурака" – всё может быстро превратиться в некий фарс, поскольку с какого-то момента пользователи потребуют убрать функцию Тревоги...
Возможный вариант: при извлечении носителя с тревожным keyfile, или срабатывании тревожной кнопки или потери связи с удаленным сервером – программа даёт возможность отменить немедленное действие (как возможный вариант – схлопывание контейнера). Например – выводит окно с просьбой "ввести код отмены или, типа, через 15 секунд будет нанесен ракетный удар по пингвинам". Соответственно, если тревога была ложной (случайно удалили ключевой носитель или просто обрыв связи), то хоть кто-то да сможет ввести пароль отмены...
И далее мы получаем следующую проблему, порождаемую такой вот "защитой от дурака": этот некоторый люфт времени, даваемый пользователю для принятия окончательного решения, может позволить атакующему добраться до некоторых файлов и за 15 секунд что-то да увидеть... Тут, на мой неискушенный взгляд, может быть только одно решение: на это время принятия решение и ввода отменяющего пароля (или бездействия), криптоконтейнер должен быть заблокирован для любых действий с файлами в нем... И если таки поступает отменяющий код (пользователь вводит пароль отмены, поскольку тревогу была ложной), то дальше работа продолжается как обычно.
Правда есть один нюанс: как Я понимаю, есть ряд программ (баз данных), которые не совсем корректно могут себя повести в следствие кратковременной потери контакта между Клиентом на компе пользователя и базой в заблокированном контейнере. В лучшем случае – потребуется перезапуск базы данных, но сколько может "умереть" при этом данных – никто не скажет...
Вообщем, Я думаю, что это надо отдать на откуп пользователем, в смысле – функцию временной блокировки, функцию "защиты от дурака" с окном для ввода пароля подтверждения, время реакции и текст сообщения в окне – это пусть задается при первоначальной настройке контейнера. Главное – чтобы этот функционал был, а будут его использовать и как именно – это дело личное, я бы сказал – интимное... ;-)