Что я могу использовать из AD (через LDAP) в качестве пользовательского ключа шифрования?

Я использую Perl/MySQL/Apache для создания небольшого внутреннего приложения для обмена информацией. Будут пользователи с разными уровнями безопасности, и многие из этих пользователей, вероятно, будут иметь привилегии root/admin для хост-сервера и других частей нашей сети.

Я изначально разработал что-то вроде этого:

Главный ключ будет использоваться для шифрования всего содержимого, но, очевидно, я не хочу, чтобы этот ключ хранился в виде простого текста (в коде или в БД), поэтому будет таблица Keys, в которой открытый ключ каждого пользователя используется для зашифровать копию шифра. Если по какой-то причине мастер-ключ необходимо будет изменить, все копии ключа могут быть сгенерированы заново, и никакие данные не будут потеряны.

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

Что я хотел бы сделать, так это использовать аутентификацию AD через LDAP вместо локального пароля для всех, кроме пользователя-администратора. Но, поскольку пароли пользователей могут меняться между входами в систему, я не могу полагаться на это как на зашифрованный текст для шифрования/дешифрования закрытых ключей.

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

Любые другие идеи или зияющие дыры в этом процессе? Я знаю, что процесс сервера потенциально может быть использован для создания дампа содержимого памяти, или пользователь root может прочитать то же самое через необработанный доступ, но это приемлемый риск. В конечном счете любой, у кого есть root или физический доступ, обычно заслуживает доверия. Тем не менее, я хочу, чтобы содержимое базы данных было зашифровано, чтобы честные люди оставались честными.


encryption security ldap perl
person SirNickity    schedule 20.06.2011    source источник
comment
Почему бы просто не использовать членство в группах AD/LDAP для управления доступом к данным?   -  person RickF    schedule 21.06.2011
comment
Меня беспокоит не контроль доступа. Мне нужно что-то использовать в качестве ключа шифрования, что было бы невозможно получить без учетных данных пользователя. У AD есть сертификаты и тому подобное, а NTFS шифрует локальные данные с помощью ключа хоста, а затем шифрует этот ключ с помощью ключа пользователя. Вот такой подход я хотел бы использовать. Так где взять этот ключ?   -  person SirNickity    schedule 21.06.2011

Ответы (1)


arrow_upward
0
arrow_downward

То, что вам нужно, просто невозможно с конфигурацией AD по умолчанию. По умолчанию все пользователи имеют полный доступ для чтения в разделе имен AD (где хранятся все пользовательские объекты), кроме того, AD также можно настроить, чтобы предоставить анонимным пользователям такой же доступ для чтения. AD не предназначена для хранения приватных данных, в основном она такая же приватная, как телефонная книга.

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

Например, вы можете использовать objectSid, который содержит SID пользователя в двоичном формате, или objectGUID, который содержит его глобально уникальный идентификатор объекта.

Однако атрибут objectSid можно изменить при изменении SID пользователя — в TechNet есть статья под названием «SID vs. GUID», в которой описывается, в каких сценариях можно изменить objectSid — http://technet.microsoft.com/en-us/library/cc961625.aspx.

person ShaMan-H_Fel    schedule 22.06.2011