Попытка защититься от администратора...
Модератор: Модераторы
Сообщений: 3
• Страница 1 из 1
ribentrop » 10 янв 2007, 18:55
Добрый день, всех с прошедшими Праздниками!
Помогите, пожалуйста, со следующей задачкой! Нужно защититься от администратора сети (домена)! Вопрос такой в инете неодократно задавался, но ответом было, как правило, такое: «защищаться от администратора это тупо»... Тупо, но надо!
Ну так вот. Сначала описательная часть, а потом, собственно, вопрос.
Пытаемся призвать себе на помощь EFS, использование которой по любому планируется в сети.
В EFS есть так называемые агенты восстановления, которые могут получить доступ к зашифрованным пользовательским данным согласно определенной ранее политики восстановления. Так вот, прятать от админа пользовательские данные EFS-шифрованием бессмысленно, т.к. админ по умолчанию является агентом восстановления любого EFS-зашифрованного ресурса, т.е. доступ к нему он все равно получит. Исключение админа из политики восстановления EFS-зашифрованных ресурсов дело не спасает – являясь админом он так же просто может добавить себя туда или еще наплодить других агентов восстановления с какими угодно правами.
Теперь как мне думается, можно было бы решить задачу в контексте таких вот реалий. Получается несколько натянуто, но все таки:
Первоначальное развертывания системы производит администратор (доменный админ). Он делает следующее:
1. Создает профили администраторов с «ущемленными правами». Этим «администраторам» (будем называть их под-админами) позволяется делать только необходимое для администрирования системы – заводить юзеров, предоставлять доступ, делать бэкап. НО: они не имеют право определять политику восстановления EFS-зашифрованных ресурсов, т.е. создавать агентов восстановления (или причислять себя к таковым). Тем самым, защищаем зашифрованные данные пользователя от будущих админов системы (ими как раз и будут эти «под-админы»). В идеале, вообще запретить таким типам все, что связано с шифрованием.
2. Создает по необходимости агентов восстановления. Полномочия у них минимальны.
3. Заводит папочки, юзеров, разграничивает доступ.
4. Кладет свою смарт-карту с паролем для авторизации в сети в сейф к начальнику службы безопасности, например. Т.е. исчезает из системы.
Итак, мы имеем систему без суперадмина, который мог бы потревожить данные пользователей, а все административные функции выполняются созданными ранее «под-админами», которые не могут просмотреть в зашифрованные ресурсы. В случае, если юзер теряет свой закрытый ключик (предварительно импортированный на смарткарту), в дело вступает агент восстановления, которому под-админ предоставляет доступ к папочке, где тому надо поработать.
Теперь, собственно, вопрос: как вы ко всему этому относитесь?
Можно ли создать такого ущербного админа («под-админа»), полномочия которого позволили бы ему администрить систему, но не позволяли бы общаться с EFS-зашифрованными ресурсами? (В идеале, конечно хотелось бы знать, какие и где выставить галочки, чтобы сконфигурировать ущемленные полномочия такого «под-админа», но это уже слишком нагло с моей стороны!:)) Как я понимаю, создавать такого админа можно «сверху» - то есть создать юзера с правами админа и урезать права до желаемого уровня, или «снизу» - создать юзера с правами юзера и добавлять права ему до необходимого уровня. Но сам я разбираюсь в том, что да как кому урезать, мягко говоря, небыстро.... Хотелось бы знать, приду к чему-нибудь, двигаясь в этом направлении? Какие-нибудь советы…
В узком смысле задача стоит защититься именно за счет EFS-а (никакие там, например, PGP-решения не рассматриваются). А в более широком смысле хотелось бы создать систему, защищенную каким-либо образом от администратора уже не важно чем. Если у кого опыт общения с системами защиты контента, буду очень рад услышать и пообщаться!
Спасибо!!!
Помогите, пожалуйста, со следующей задачкой! Нужно защититься от администратора сети (домена)! Вопрос такой в инете неодократно задавался, но ответом было, как правило, такое: «защищаться от администратора это тупо»... Тупо, но надо!
Ну так вот. Сначала описательная часть, а потом, собственно, вопрос.
Пытаемся призвать себе на помощь EFS, использование которой по любому планируется в сети.
В EFS есть так называемые агенты восстановления, которые могут получить доступ к зашифрованным пользовательским данным согласно определенной ранее политики восстановления. Так вот, прятать от админа пользовательские данные EFS-шифрованием бессмысленно, т.к. админ по умолчанию является агентом восстановления любого EFS-зашифрованного ресурса, т.е. доступ к нему он все равно получит. Исключение админа из политики восстановления EFS-зашифрованных ресурсов дело не спасает – являясь админом он так же просто может добавить себя туда или еще наплодить других агентов восстановления с какими угодно правами.
Теперь как мне думается, можно было бы решить задачу в контексте таких вот реалий. Получается несколько натянуто, но все таки:
Первоначальное развертывания системы производит администратор (доменный админ). Он делает следующее:
1. Создает профили администраторов с «ущемленными правами». Этим «администраторам» (будем называть их под-админами) позволяется делать только необходимое для администрирования системы – заводить юзеров, предоставлять доступ, делать бэкап. НО: они не имеют право определять политику восстановления EFS-зашифрованных ресурсов, т.е. создавать агентов восстановления (или причислять себя к таковым). Тем самым, защищаем зашифрованные данные пользователя от будущих админов системы (ими как раз и будут эти «под-админы»). В идеале, вообще запретить таким типам все, что связано с шифрованием.
2. Создает по необходимости агентов восстановления. Полномочия у них минимальны.
3. Заводит папочки, юзеров, разграничивает доступ.
4. Кладет свою смарт-карту с паролем для авторизации в сети в сейф к начальнику службы безопасности, например. Т.е. исчезает из системы.
Итак, мы имеем систему без суперадмина, который мог бы потревожить данные пользователей, а все административные функции выполняются созданными ранее «под-админами», которые не могут просмотреть в зашифрованные ресурсы. В случае, если юзер теряет свой закрытый ключик (предварительно импортированный на смарткарту), в дело вступает агент восстановления, которому под-админ предоставляет доступ к папочке, где тому надо поработать.
Теперь, собственно, вопрос: как вы ко всему этому относитесь?
Можно ли создать такого ущербного админа («под-админа»), полномочия которого позволили бы ему администрить систему, но не позволяли бы общаться с EFS-зашифрованными ресурсами? (В идеале, конечно хотелось бы знать, какие и где выставить галочки, чтобы сконфигурировать ущемленные полномочия такого «под-админа», но это уже слишком нагло с моей стороны!:)) Как я понимаю, создавать такого админа можно «сверху» - то есть создать юзера с правами админа и урезать права до желаемого уровня, или «снизу» - создать юзера с правами юзера и добавлять права ему до необходимого уровня. Но сам я разбираюсь в том, что да как кому урезать, мягко говоря, небыстро.... Хотелось бы знать, приду к чему-нибудь, двигаясь в этом направлении? Какие-нибудь советы…
В узком смысле задача стоит защититься именно за счет EFS-а (никакие там, например, PGP-решения не рассматриваются). А в более широком смысле хотелось бы создать систему, защищенную каким-либо образом от администратора уже не важно чем. Если у кого опыт общения с системами защиты контента, буду очень рад услышать и пообщаться!
Спасибо!!!
- biruk
- Активный пользователь
- Сообщения: 1134
- Зарегистрирован: 19 июл 2004, 11:30
- Откуда: Москва
biruk » 10 янв 2007, 21:05
да... серьезно.
... и между клиентом и сервером ipsec... и между серверами тоже...
и продумайте как будете осуществлять резервное копирование и восстановление.
а если у вас будет sql то тогда что шифровать? поля ? разработчики это не учитывают по-дефолту.
в приципе, так должно сработать... для файлов.
но я не знаю никого, кто такое же делал
имхо, нужно правильно прописать политику безопасности, определить категории данных (для каждой категории своя политика), права и обязанности пользователей, санкции за разглашение.Вообщем, нужен системный подход, а не пляска от возможностей операционной системы.
и делать упор на аудит.
потому как если произойдет утечка, без аудита будете просто гадать - кто?! админ не знал - нет ключа... или знал?! или мог хакерским методом завладеть?
и не просто аудит, а такой, который с большой вероятностью не сможет быть оспорен в суде.
и кстати, по вине админов % утечки информации не такой уж большой.
а вот от легальных пользователей, которые имеют доступ к информации - максимальный.
вот. надеюсь ваша компания наймет безопасника или реализует совместный проект с какой-нить фирмой, которая долго занимается it sec.
а на форумах, вам подскажут только какое-нить частное решение, а в комплексе - нет.
... и между клиентом и сервером ipsec... и между серверами тоже...
и продумайте как будете осуществлять резервное копирование и восстановление.
а если у вас будет sql то тогда что шифровать? поля ? разработчики это не учитывают по-дефолту.
в приципе, так должно сработать... для файлов.
но я не знаю никого, кто такое же делал
имхо, нужно правильно прописать политику безопасности, определить категории данных (для каждой категории своя политика), права и обязанности пользователей, санкции за разглашение.Вообщем, нужен системный подход, а не пляска от возможностей операционной системы.
и делать упор на аудит.
потому как если произойдет утечка, без аудита будете просто гадать - кто?! админ не знал - нет ключа... или знал?! или мог хакерским методом завладеть?
и не просто аудит, а такой, который с большой вероятностью не сможет быть оспорен в суде.
и кстати, по вине админов % утечки информации не такой уж большой.
а вот от легальных пользователей, которые имеют доступ к информации - максимальный.
вот. надеюсь ваша компания наймет безопасника или реализует совместный проект с какой-нить фирмой, которая долго занимается it sec.
а на форумах, вам подскажут только какое-нить частное решение, а в комплексе - нет.
Trust me - i know what i’m doing © Sledge Hummer
sea » 11 янв 2007, 06:35
ribentrop
| Цитата | ||
| как вы ко всему этому относитесь?
[/quote] Да нормально. У каждого своя специфика.
|