Comments 16
Можно хоть какие-то примеры привести софта для автоматизации данного процесса? Практика с сейфом есть, а с софтом — нет, только теория :(
Конечно можно :). Не хотел чтобы сочли пост рекламой в каком-либо виде.
Из лидеров рынка я бы выделил ERPM от Lieberman Software и комплексное решение от Cyber-Ark. Есть решения от монстров рынка Identity Management — IBM и Oracle. Они не могут похвастаться большой функциональностью, это лишь дополнения к основным IdM продуктам. Есть нишевые решения, например Hytrust специализируется на защите виртуальных сред.
Из лидеров рынка я бы выделил ERPM от Lieberman Software и комплексное решение от Cyber-Ark. Есть решения от монстров рынка Identity Management — IBM и Oracle. Они не могут похвастаться большой функциональностью, это лишь дополнения к основным IdM продуктам. Есть нишевые решения, например Hytrust специализируется на защите виртуальных сред.
Можно добавить Xceedium и Quest
Зачем мучать людей веб-интерфейсами и прочими изощренными велосипедами, когда можно сразу использовать многофакторную аутентификацию, включая биометрическую, включить логи, обеспечить их надежное хранение и удобный доступ к ним для аудита? А если человек находится под давлением (терморектальный криптоанализ, семья в заложниках и т.п.), он и при системе «пароли в шкафчике» сможет сделать то, что от него требуют.
Тут бы разумнее смотрелась система управления правами и шифрование, дающее, скажем, сделать дамп базы, но не позволяющее без разрешения уполномоченным лицом его расшифровать, но ведь администраторам часто требуется доступ к данным на различных уровнях.
Тут бы разумнее смотрелась система управления правами и шифрование, дающее, скажем, сделать дамп базы, но не позволяющее без разрешения уполномоченным лицом его расшифровать, но ведь администраторам часто требуется доступ к данным на различных уровнях.
Так все эти «велосипеды» отчасти и придуманы для того, чтобы приладить многофакторную аутентификацию к тем системам, устройствам и т.п., которые сами этого делать не умеют. Я вижу два основных плюса от использования подобных систем:
1. Строгая аутентификация пользователей, причем для всех систем используется один каталог пользователей.
2. Централизованный аудит обращения ко всем системам.
Но я ни в коем случае не буду утверждать, что эти системы нужно обязательно ставить всем и везде. Стоят они не дешево, преимущества, действительно, сходу не очевидны. Так что перед принятием решения о внедрении (или не внедрении) подобных решений, сначала нужно прийти к пониманию почему и зачем это делается.
1. Строгая аутентификация пользователей, причем для всех систем используется один каталог пользователей.
2. Централизованный аудит обращения ко всем системам.
Но я ни в коем случае не буду утверждать, что эти системы нужно обязательно ставить всем и везде. Стоят они не дешево, преимущества, действительно, сходу не очевидны. Так что перед принятием решения о внедрении (или не внедрении) подобных решений, сначала нужно прийти к пониманию почему и зачем это делается.
В одной веселой контое видел разделяемые пароли.
Одна половина пароля у СБ, другая у ИТ. Приходят к терминалу для работы с критичной системой вместе, вводят по очереди свои части, ИТшник работает, СБшник бдит.
Одна половина пароля у СБ, другая у ИТ. Приходят к терминалу для работы с критичной системой вместе, вводят по очереди свои части, ИТшник работает, СБшник бдит.
Тоже встречал такой подход (возможно даже в той же самой конторе :-) ), думал, что это вполне нормальная практика, когда:
1. Для всех штатных операций каждый пользователь имеет персонифицированную учетную запись.
2. Все не персонифицированные учетные записи имеют разделенный пароль, а каждая часть в свою очередь в сейфе у соответствующего подразделения. После использования пароль меняется.
Думаю было бы удобно, если как то улучшить эту схему так, чтобы представителям подразделений можно было ввести свою персонифицированную и в сумме они давали права keys of the kingdom.
1. Для всех штатных операций каждый пользователь имеет персонифицированную учетную запись.
2. Все не персонифицированные учетные записи имеют разделенный пароль, а каждая часть в свою очередь в сейфе у соответствующего подразделения. После использования пароль меняется.
Думаю было бы удобно, если как то улучшить эту схему так, чтобы представителям подразделений можно было ввести свою персонифицированную и в сумме они давали права keys of the kingdom.
Объясните, пожалуйста, зачем вообще привилегированным учетным записям назначать пароли? И потом их героически менять? Разве нет механизма, подобного sudo в unix? Когда юзер всегда логинится под своей личной учетной записью, а потом, если ему это явно разрешено, может с нее переключиться на привилегированную. В этом случае не нужно никаких паролей менять вообще, а давать/отбирать права можно моментально и централизованно.
Правильно понимаю, что переключившись на привилегированную мы получаем неограниченные привилегии? Тогда что мешает нам сначала слить/изменить/испортить данные и после этого очистить все протоколы доступа и будто бы ничего не было?
Логи же по сети все отправляются на другую машину, к которой ни у кого, кроме Президента Человечества, нет доступа. Не? И как этот вопрос относится к sudo?
Правильно понимаю, что этот пресловутый Президент Человечества может единолично творить что хочет?
Возможно я не до конца понимаю, что делает sudo, предлагаю разобрать на конкретном примере. Не хочу привязываться к ОС, по этому пример такой — есть СУБД Oracle, в ней есть пользователь sys, под которым можно сделать все что угодно, а потом почистить за собой следы. Допустим, там был бы механизм, когда обычный персонифицированный пользователь может написать sudo и получить права sys'а, как это остановит его от последующей зачистки следов? А когда пароль разделен, а части в конвертах по сейфам, то подобный инцидент возможен только в случае сговора нескольких лиц.
И да, такие учетные записи не предназначены для постоянного использования, только для каких либо исключительных ситуаций. Если же возникает потребность в их регулярном использовании, то значит имеются проблемы в системе прав/ролей персонифицированных учетных записей.
Возможно я не до конца понимаю, что делает sudo, предлагаю разобрать на конкретном примере. Не хочу привязываться к ОС, по этому пример такой — есть СУБД Oracle, в ней есть пользователь sys, под которым можно сделать все что угодно, а потом почистить за собой следы. Допустим, там был бы механизм, когда обычный персонифицированный пользователь может написать sudo и получить права sys'а, как это остановит его от последующей зачистки следов? А когда пароль разделен, а части в конвертах по сейфам, то подобный инцидент возможен только в случае сговора нескольких лиц.
И да, такие учетные записи не предназначены для постоянного использования, только для каких либо исключительных ситуаций. Если же возникает потребность в их регулярном использовании, то значит имеются проблемы в системе прав/ролей персонифицированных учетных записей.
sudo — один из механизмов предназначенных для решения проблемы.
Но увы, не везде есть и применим. И всегда кому то надо хранить самый главный пароль, тобы потом починить то, что натворили пользователи из wheel :)
Но увы, не везде есть и применим. И всегда кому то надо хранить самый главный пароль, тобы потом починить то, что натворили пользователи из wheel :)
Хранить — не значит выдавать всем и менять его каждую минуту. Самый главный пароль требуется лишь в самых экстренных случаях, которые происходят 1-2 раза за все время жизни компании. Топик явно не о нем. Я просто правда не понимаю то, что описано в топике и потом так яростно и на полном серьезе обсуждается в комментариях — что, реально кто-то раздает кому-то вот такие главные пароли «из сейфа» и потом их меняет, кладет в сейф и т.д.? Зачем? О том и вопрос.
Так вся эта кухня для того и придумана. В идеальном случае человек входит в систему под личной учеткой, потом приходит на специальную веб-страничку и говорит: «дай ка мне доступ к серверу ABCDEF». И ему сразу открывается терминал в эту систему.
Пароли в данной ситуации — это только средство предоставить ему доступ.
Пароли в данной ситуации — это только средство предоставить ему доступ.
Sign up to leave a comment.
Управление привилегированными учетными записями