id: Гость   вход   регистрация
текущее время 23:41 28/03/2024
Автор темы: makc, тема открыта 01/08/2006 19:00 Печать
http://www.pgpru.com/Форум/РаботаСGnuPG/GPGВКорпоративномОкружении
создать
просмотр
ссылки

GPG в корпоративном окружении


Добрый день


Пытаюсь решить задачу шифрования почты открытым ключем. Так как компания в своей работе использует преимущественно открытый код да и пользователи равномерно распределены по платформам, включая Мак и Сан, в качестве базового софта выбран GPG. Все работает, шифруется/расшифровывается. На сейчас каждый из пользователей сгенерировал себе ключи, публичные были проверены и подписаны корпоративным ключем и далее помещены на кейсервер. Но меня гложет сомнения, правильно ли это? Может необходимо выдавать каждому сотруднику сабкей из основного корпоративного ключа? Вообщем я немного запутался, есть ли ссылка на документ о правильном построении дерева ключей фирмы? И еще есть вопросик, возможно ли реализовать в ГПГ схему типа ADK в PGP ?


 
Комментарии
— SATtva (01/08/2006 19:27)   профиль/связь   <#>
комментариев: 11558   документов: 1036   редакций: 4118
Вообщем я немного запутался, есть ли ссылка на документ о правильном построении дерева ключей фирмы ?

http://www.pgpru.com/manuals/pgppki/
Это в общих чертах. Вообще такие вещи делаются индивидуально, исходя из строения вашей организации. Например, если фирма небольшая, достаточно одного корневого ключа, перекрёстно заверенного всеми пользователями (т.е. корневой ключ подписывает ключи всех пользователей, а все пользователи подписывают корневой ключ). При этом корневому ключу должно быть выставлено полное доверие. Больше ничего, в принципе, не нужно. Конечно, если организация большая со множеством филиалов и отделений, схему придётся разветвить.

И еще есть вопросик, возможно ли реализовать в ГПГ схему типа ADK в PGP ?

Не в полном виде. ADK является запатентованной технологией PGPCorp, так что ожидать появления этой схемы в свободном софте не стоит. Да и сами разработчики GPG реагируют реакцией коленного рефлекса на любые упоминания о системах депонирования ключей или восстановления данных (по историческим причинам).

Вообще схема ADK является двунаправленной. Сотрудники фирмы при отправке почты используют т.н. Outbound ADK — это просто дополнительный ключ, наравне с их собственным ключом и ключом получателя, которыми их ПО шифрует сообщение.

Поскольку OADK определяется в настройках их собственной программы (конечно, так, что сам пользователь не может его убрать или изменить), похожий трюк можно проделать и в GnuPG с помощью команды recipient [keyID], заданной в gpg.conf (сам файл конфигурации, разумеется, придётся защитить от правки пользователем ПК).

Вторая часть ADK — Inbound ADK — добавляется в материал открытого ключа сотрудника, и используется внешним корреспондентом при шифровании письма для этого сотрудника фирмы. Разумеется, принудительным образом установить этот ключ в GPG Вам не удастся...

Впрочем, если у кого-нибудь есть иные соображения на этот счёт, с интересом их выслушаю.
— makc (01/08/2006 21:57)   профиль/связь   <#>
комментариев: 1   документов: 1   редакций: 0
SATtva:
Вообщем я немного запутался, есть ли ссылка на документ о правильном построении дерева ключей фирмы ?

http://www.pgpru.com/manuals/pgppki/
Это в общих чертах. Вообще такие вещи делаются индивидуально, исходя из строения вашей организации. Например, если фирма небольшая, достаточно одного корневого ключа, перекрёстно заверенного всеми пользователями (т.е. корневой ключ подписывает ключи всех пользователей, а все пользователи подписывают корневой ключ). При этом корневому ключу должно быть выставлено полное доверие. Больше ничего, в принципе, не нужно. Конечно, если организация большая со множеством филиалов и отделений, схему придётся разветвить.

Спасибо за развернутый ответ. Ссылку я читал, в английском варианте, русский открыл новые грани понимания ;)

И еще есть вопросик, возможно ли реализовать в ГПГ схему типа ADK в PGP ?

Не в полном виде. ADK является запатентованной технологией PGPCorp, так что ожидать появления этой схемы в свободном софте не стоит. Да и сами разработчики GPG реагируют реакцией коленного рефлекса на любые упоминания о системах депонирования ключей или восстановления данных (по историческим причинам).

Вообще схема ADK является двунаправленной. Сотрудники фирмы при отправке почты используют т.н. Outbound ADK — это просто дополнительный ключ, наравне с их собственным ключом и ключом получателя, которыми их ПО шифрует сообщение.

Поскольку OADK определяется в настройках их собственной программы (конечно, так, что сам пользователь не может его убрать или изменить), похожий трюк можно проделать и в GnuPG с помощью команды recipient [keyID], заданной в gpg.conf (сам файл конфигурации, разумеется, придётся защитить от правки пользователем ПК).

Вторая часть ADK — Inbound ADK — добавляется в материал открытого ключа сотрудника, и используется внешним корреспондентом при шифровании письма для этого сотрудника фирмы. Разумеется, принудительным образом установить этот ключ в GPG Вам не удастся...

Впрочем, если у кого-нибудь есть иные соображения на этот счёт, с интересом их выслушаю.

Собственно нам был нужен только OADK, для возможности восстановления шифрованных данных в случае недоступности сотрудника. И реализовали мы ее с использованием GPG так как вы описали. Думал может есть какая-то хитрость, например так подписать ключ сотрудника что-бы без мастер ключа кодирование было невозможно. Спасибо за развернутый ответ, подтверждение собственных действий третьей стороной всегда важно.

Появился еще вопрос – если мы подписываем мастер-ключ ключами всех сотрудников, то что делать при увольнении сотрудника? Просто не обращать на лишнюю подпись внимания ?
— SATtva (01/08/2006 22:32)   профиль/связь   <#>
комментариев: 11558   документов: 1036   редакций: 4118
Появился еще вопрос – если мы подписываем мастер-ключ ключами всех сотрудников, то что делать при увольнении сотрудника? Просто не обращать на лишнюю подпись внимания ?

Конечно. Она всё равно ни на что не повлияет. Удалить её окончательно, особенно если копия открытого ключа уже покинула пределы организации, вам вряд ли удастся. Просить же сотрудника перед уходом аннулировать свою подпись не только глупо, но и не совсем правильно, поскольку любые отозванные подписи на ключе увеличивают недоверие к нему со стороны посторонних.

А вот подпись от корневого ключа на ключе уволенного сотрудника нужно будет отозвать. А ещё лучше — аннулировать его ключ целиком, если корневой ключ был выбран в качестве "доверенного отменителя" (designated revoker; кто-нибудь предложит более элегантный перевод?).
Ваша оценка документа [показать результаты]
-3-2-1 0+1+2+3