Комментарии 22
Феерическая ахинея. И это называется компания, занимающаяся безопасностью?
Сисадмин, генерирующий и рассылающий закрытые ключи пользователям? Их приватные ключи?
Я такую контору с такими советами на километр не подпущу к любой организации, с которой имею дружеские отношения.
Сисадмин, генерирующий и рассылающий закрытые ключи пользователям? Их приватные ключи?
Я такую контору с такими советами на километр не подпущу к любой организации, с которой имею дружеские отношения.
Сисадмин рассылает pfx-сертификаты, содержащие приватные ключи пользователей. Но сертификаты такого типа, а значит и приватные ключи, защищены паролем.
Но это как ОДИН из вариантов. Сценарий когда админ выдает ключи всем пользователям, в том числе и закрытые (кроме руководящего звена) очень часто прописывается в политике криптографисечкой защиты самой компании. Это естественно, у руководства компании должна быть возможность читать любую корпоративную переписку.
Конечно, более правильный сценарий таков: на стороне клиента формируется закрытый ключ и запрос на сертифкат. Запрос отсылается на сервер и админ выдает сертификат, а закрытый ключ остается всегда у пользователя. В текущей версии CyberSafe, о которой идет речь в статье, такой возможности нет и она будет реализована в следующих версиях.
Но это как ОДИН из вариантов. Сценарий когда админ выдает ключи всем пользователям, в том числе и закрытые (кроме руководящего звена) очень часто прописывается в политике криптографисечкой защиты самой компании. Это естественно, у руководства компании должна быть возможность читать любую корпоративную переписку.
Конечно, более правильный сценарий таков: на стороне клиента формируется закрытый ключ и запрос на сертифкат. Запрос отсылается на сервер и админ выдает сертификат, а закрытый ключ остается всегда у пользователя. В текущей версии CyberSafe, о которой идет речь в статье, такой возможности нет и она будет реализована в следующих версиях.
Ключ для шифрования данных должен храниться на сервере в специальном хранилище. Иначе при утере устройства с закрытым ключом все, что зашифровано можно будет выбросить.
Ключи авторизации и аутентификации, сессионные ключи можно и нужно генерить непосредственно на конечном устройстве.
Ключи авторизации и аутентификации, сессионные ключи можно и нужно генерить непосредственно на конечном устройстве.
Именно. Я лениво пролистывал ленту, ожидая очередной рассказ про генерацию запросов на сертификаты, и тут, блямс, гигантская, феерическая дыра.
Кошмар, на самом деле. Начиная от неподписанного профиля, заканчивая генерацией ключей на сервере. Вы в курсе, что iOS поддерживает SCEP запросы с локальной генерацией ключей?
Мда, видать я не так и плохо разбираюсь в ИБ, читал статью и волосы шевелились во всех местах :)
Это зависит от политики компании. У нас, например, СБ требует однозначно чтобы у них были ключи. Руководство создает себе самостоятельно либо с запросом на сервер, но всем остальным… Были случаи, когда потом сотрудники с ключами пропадали, а вместе с ними и все их документы и почта. Так что пеной брызгать по-моему не уместно.
Никто и не брызжет, но слать по почте уж простите.
Согласен. Это уж очень упрощенный вариант. Если только почтовик свой. А на публичный конечно не стоит. Не знаю насколько публика сталкивалась с написанием и проверкой соблюдением крипто инструкций для офисного планктона. Мы внедряли как-то криптографию в секретариат и бухгалтерию, с запросами и выработкой ключей через AD CA. Чуть не до увольнений дошло со стороны девочек. В итоге руководство плюнуло на все и сказало нам самим им все настроить, выдать и пароль задать!
Плохо внедряли значит. Autoenrollment сертификатов прекрасно работает в Active Directory. При правильной настройке все прозрачно для пользователя, большинство вообще не замечает, что изменилось, просто в Outlook появилась возможность подписывать и шифровать письма.
Очень даже уместно. Для шифрования данных действительно необходимо генерировать ключи на сервере, складывать в хранилище ключей и БЕЗОПАСНЫМ способом доставлять в пользовательское хранилище, на мобильном устройстве, смарт-карте, USB-токене. В статье тупо предлагается установить файл с парой ключей. А как оно попало на устройство? По почте, с сайта, через USB? Как защищен способ доставки ключей?
Если бы на iOS использовался двухфакторный метод доставки профиля конфигрурации и ключ шифрования шел в зашифрованном профиле, тогда вопросов бы не было. Даже https ресурс с некой системой авторизации (OTP, secure link) был более-менее профессиональным решением. А сейчас это просто некий ЦС с выгрузкой PKCS12 и все.
Хорошим тоном является организация публичного LDAP для доступа ко всем сертификатам сотрудников, настройка почты и адресной книги через профили конфигурации (для iOS/OSX). Но до этого вам далеко, похоже… :-)
Если бы на iOS использовался двухфакторный метод доставки профиля конфигрурации и ключ шифрования шел в зашифрованном профиле, тогда вопросов бы не было. Даже https ресурс с некой системой авторизации (OTP, secure link) был более-менее профессиональным решением. А сейчас это просто некий ЦС с выгрузкой PKCS12 и все.
Хорошим тоном является организация публичного LDAP для доступа ко всем сертификатам сотрудников, настройка почты и адресной книги через профили конфигурации (для iOS/OSX). Но до этого вам далеко, похоже… :-)
«А как оно попало на устройство?»
В статье написано об этом. Даже дважды — в каждом из п.1 для каждого из алгоритмов настроек.
В статье написано об этом. Даже дважды — в каждом из п.1 для каждого из алгоритмов настроек.
Это был риторический вопрос, подразумевалось что защиты при доставке нет никакой.
Согласен. Почтой, тем более с паролем можно только если свой суперзащищенный почтовик. А так… описанная Вами выше схемы, конечно, надежные.
Если pfx передается по открытой почте, то сам файл действительно никак не защищен. Но как вы получите из него приватный ключ пользователя, если он защищен паролем, имеющим как минимум 128 бит энтропии?
Ну и второй вариант — прямо на устройство через usb. Об этом написано в статье.
Ну и второй вариант — прямо на устройство через usb. Об этом написано в статье.
Это зависит от того, как передается пароль конечному пользователю. Можно подсмотреть СМС на телефоне, подслушать разговор по телефону, посмотреть в бумажку с паролем. Можно позвонить в техподдержку и притвориться жертвой, забывшей пароль. Если есть файл, то дальше дело техники, в большинстве случаев.
Согласен, но это уже действительно риторика. Если в компании есть служба поддержки, знающая пароли к приватным ключам пользователей и она вот-так вот выдаст пароль любому позвонившему, тогда это уже будет на совести самой компании.
Аналогично можно рассуждать и о способах, позволяющих злоумышленнику заполучить установленный в хранилище pfx-файл пользователя.
Аналогично можно рассуждать и о способах, позволяющих злоумышленнику заполучить установленный в хранилище pfx-файл пользователя.
Интересная темя для организаций у которых сотрудники работают удаленно очень актуальна.
На планшете тоже работает аналогично =)
Система актуальна не толь ко для удаленных работников, но и для реализации переписки в офисе между директорами и бухгалтерией или между кадрами и бухгалтерами. В любом случае необходима защита переписки.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Защита электронной почты в организациях с использованием мобильных устройств