Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 142
А зачем вы храните пароли от ssh?
Я не программист, очевидно, чтобы передать при необходимости другому человеку. Хотя, даже без них, паролей хватает…
А вы в курсе, что пароли «передавать» не принято? И что у ssh есть такая замечательная вещь, как ключи?
я ж говорю я не программист, возможно вы правы и ssh мы не храним :)
Кем «принято» или «не принято»? Если мне надо дать человеку временный доступ на сервер, гораздо проще и быстрее сделать adduser и передать ему пароль, чем объяснять, что он должен сгененировать приватный и публичный ключи, отослать, потом ещё сконвертировать ключи в тот или иной формат в зависимости от его предпочтений в плане SSH клиента и ты тд и ты пы.
Если эта задача возникает постоянно, то все же предпочтительней использование ключей, тем более что скорее всего объяснять ничего не нужно будет, у клиента уже будет сгенерирован ключ, а даже если и нет, то особой проблемы в этом нет, в крайнем случае можно написать небольшой guide например как на Github'е. Если такая задача возникает редко, то вариант с временным юзером конечно имеет право на жизнь, но, например, у нас, авторизация на сервере только по ключам, и никуда ты не денешься.
Если у вас на серверах авторизация только по ключам — то колоть админам-параноикам живительный галоперидол до просветления.
Временный пароль для первого доступа — да. Дальше человек должен поменять пароль. А хранить общие пароли в общедоступной базе — нахрена вам вообще пароли? Сделайте один на всех на все случаи жизни.
Почему не в Q&A?
PKI рулит. Но не ко всему можно прикрутить, увы.
Для внутренних целей аутентификации на разнообразных сервисах рекомендую централизованную систему аутентификации на базе LDAP. Один сотрудник = один пользователь = один пароль, но разный доступ к разным системам.
Для внутренних целей аутентификации на разнообразных сервисах рекомендую централизованную систему аутентификации на базе LDAP. Один сотрудник = один пользователь = один пароль, но разный доступ к разным системам.
Я хочу скромно и без лишнего пафоса узнать, правда, мне очень любопытно, почему не «управление паролями», а «менеджмент паролей»? Наверно, я брюзжащее существо, но искренне считаю, что в данном случае это употребление так же убого, как и «инжиниринг успеха». Зачем городить сущности?
Я просто много просмотрел и прочитал всего по теме, чаще, особенно в переводах, употребляют слово менеджмент — вот, оттуда и прицепилось очевидно).
Программа «управлятор паролей» не найдена. Возможно, вы имели в виду «password manager».
а еще есть буржуазное слово «ресепшн», который очень мило режет слух.
Ну хорошо, а вот к примеру есть у вас доступ от клиентской панели управления (скажем на местерхосте), многопользовательский доступ к ней в принципе не возможен. А менять каждый раз пароль, значит напрягать клиента. К тому же, если пароль от панели контролирует клиент, в таких случаях оперативный доступ, часто — просто не возможен. Как в таких ситуациях решать вопрос?
>Какая-то «детская» у вас студия получается, извините.
Так вот мы и пытаемся встать на ноги :). За комментарии спасибо.
Так вот мы и пытаемся встать на ноги :). За комментарии спасибо.
хм… может это у вас недостаточно опыта чтобы представить что у кого-то могут возникнуть задачи с которыми вы не сталкивались?
Если вы например участвуете в проекте, в котором больше 1 субподрядчика, могут возникнуть еще и не такие заморочке.
Если в проекте 20+ фирм, вы для каждого девелопера и админа каждой фирмы будете заводить svn, ftp, vpn и пр. аккаунты?
Хотя признаю для вебдева это скорее редкость. Тем немение проблема актуальна.
Если вы например участвуете в проекте, в котором больше 1 субподрядчика, могут возникнуть еще и не такие заморочке.
Если в проекте 20+ фирм, вы для каждого девелопера и админа каждой фирмы будете заводить svn, ftp, vpn и пр. аккаунты?
Хотя признаю для вебдева это скорее редкость. Тем немение проблема актуальна.
ситуации не уникальны а рутинны. а если вы один из субподрядчиков, то не сильно то поменяешь политики.
Не совсем понимаю что вы имеете ввиду под «автоматизацией «общих паролей»». не хранить их в общей базе?
Мне сейчас совершенно не хочется ковыряться в архивах и приводить конкретику (уж извените), просто представьте что есть проекты (грамотно организованные) где такие проблеммы возникают постоянно.
Не совсем понимаю что вы имеете ввиду под «автоматизацией «общих паролей»». не хранить их в общей базе?
Мне сейчас совершенно не хочется ковыряться в архивах и приводить конкретику (уж извените), просто представьте что есть проекты (грамотно организованные) где такие проблеммы возникают постоянно.
> обязан НЕ — передавать
> несколько человек — каждому дается нужный доступ
Мсье шибко умный. Как же он дается без передачи?
> несколько человек — каждому дается нужный доступ
Мсье шибко умный. Как же он дается без передачи?
Хотите верьте, хотите нет — Excel внутри шифрованного контейнера. Листы — категории паролей. Строки — объекты. столбцы — имя; пароль; описание где зачем и почему.
Так и мы хранили долгое время :), когда клиентов становится много вам просто жизни не дадут своими запросами паролей, поэтому со временем к файлику получает доступ кто-то еще, и с каждым новым человеком вероятность того что файл попадет в не добрые руки все выше и выше :(
У нас файлик хранит только общие данные: доступ к серверам, СУБД и т.д. Это чисто программерская вещь и никто кроме отдела не может туда зайти. Да и потом у нас безопасность построена на уровне железа (MAC и т.д.)
Даже если этот файлик вынесут из организации — злоумышленникам это не поможет. Им тогда придется придти подключиться к сети, к которой не доберешься кроме как из здания или других зданий организации.
Личные данные клиентов у нас хранит база данных специально для этого написанная. И многие ПО написанные нами, используют эту базу для авторизации. И есть специально написанная админка, которая позволяет блокировать пользователя, менять ему пароль, заводить новых и т.д. Причем все действия можно сделать как на все ПО, так и на каждый индивидуально.
Даже если этот файлик вынесут из организации — злоумышленникам это не поможет. Им тогда придется придти подключиться к сети, к которой не доберешься кроме как из здания или других зданий организации.
Личные данные клиентов у нас хранит база данных специально для этого написанная. И многие ПО написанные нами, используют эту базу для авторизации. И есть специально написанная админка, которая позволяет блокировать пользователя, менять ему пароль, заводить новых и т.д. Причем все действия можно сделать как на все ПО, так и на каждый индивидуально.
Согласен, у вас конечно все более серьезно организованно.
А как связано МАС и безопасность?
А нынче ораничивать доступ по макадресам уже не в моде?
У нас нельзя принести свой ноутбук, к примеру, и подключить к нему сетевой кабель. Маршрутизатор и другое сетевое оборудование не даст вам ничего пока вы не пойдете и не пропишите MAC сетевой карты куда надо. А прописать это дело может только один человек, у которого есть туда доступ.
Если все правильно прописать — то сеть появится и будет доступ ко многим ctntdsv ресурсам согласно вашим правам в Active Directory.
Но интерфейс, из под которого можно такие права дать, находиться за сканером электронного индивидуального доступа (карта доступа).
такие дела ))
Если все правильно прописать — то сеть появится и будет доступ ко многим ctntdsv ресурсам согласно вашим правам в Active Directory.
Но интерфейс, из под которого можно такие права дать, находиться за сканером электронного индивидуального доступа (карта доступа).
такие дела ))
сетевым ресурсам*
извиняюсь.
извиняюсь.
Зато можно будет посмотреть какие мак-и гуляют по сети и прописать себе любой из них.
Хотите верьте, хотите нет — Excel внутри шифрованного контейнера.
Когда вы открываете файлик, он копируется в папочку Temp?
Под аналогичные цели делали свой сервис https://fireforge.net/projects/phpaclstore/
Позволяет завести список пользователей и древовидную структуру проектов-серверов-чего-то еще. Можно человеку выдать права (rwx как в Unix) на отдельный элемент или ветку, ACL одним словом. Каждый элемент дерева содержит скрытый текст, в котором мы храним параметры доступа к тому или иному объекту.
Из минусов. Сервис делали-делали, как довели до более-менее рабочего состояния для себя, развитие заморозилось. Скрытый текст хранится в базе в шифрованом состоянии, но пока единственный метод шифрования только xor+соль. Нет ssl.
В общем это недоделка, но если допилить…
Позволяет завести список пользователей и древовидную структуру проектов-серверов-чего-то еще. Можно человеку выдать права (rwx как в Unix) на отдельный элемент или ветку, ACL одним словом. Каждый элемент дерева содержит скрытый текст, в котором мы храним параметры доступа к тому или иному объекту.
Из минусов. Сервис делали-делали, как довели до более-менее рабочего состояния для себя, развитие заморозилось. Скрытый текст хранится в базе в шифрованом состоянии, но пока единственный метод шифрования только xor+соль. Нет ssl.
В общем это недоделка, но если допилить…
На такой путь я даже боюсь становится, что станет с такой разработкой, если человек который ее написал или был ее идеологом уволится из компании? Есть вариант вообще потрать время и нервы зря :(, хотя это конечно все справедливо только для маленьких компаний вроде нашей.
Думаю в этом случае просто остановится развитие, но сделанные наработки останутся и все будет работать. Пароли смените и автор/идеолог сможет только теоретически представлять где-что находится, но не пользоваться.
Одна инсталляция phpaclstore работает до сих пор и выполняет свои функции, несмотря на отсутствие развития и уход идеолога.
Впрочем, свои реализации отнимают время и ресурсы. Рассматривайте мой вариант как последнюю надежду, если не найдете более подходящее решение.
Одна инсталляция phpaclstore работает до сих пор и выполняет свои функции, несмотря на отсутствие развития и уход идеолога.
Впрочем, свои реализации отнимают время и ресурсы. Рассматривайте мой вариант как последнюю надежду, если не найдете более подходящее решение.
Я ждал, ждал, что же ты напишешь в этой теме :)
По сути: да, инсталляция работает, мы ею пользуемся.
Для потенциальных пользователей — сразу скажу, что не хватает поиска по базе и возможности переноса всего поддерева в другую ветку. В остальном — вполне удобно.
По сути: да, инсталляция работает, мы ею пользуемся.
Для потенциальных пользователей — сразу скажу, что не хватает поиска по базе и возможности переноса всего поддерева в другую ветку. В остальном — вполне удобно.
Вообще, пароли записывать ни куда не надо. Это не секурно. Ну — прилепите бумажки с паролями на мониторах…
KeePass.
+ dropbox)
Тоже им. Во второй версии не проблема открывать один файл несколькими пользователями, либо вообще синхронизировать при необходимости. Ну а доступ к файлу контролируется настройками безопасности + пароль
keepassx
Для личных целей лучше нету, ни как там насчет одновременного пишущего доступа к базе?
Во-первых, для работников можно заводить отдельных юзеров. Ну а дальше уже понятно?
Мы в MyTaskHelper.ru создали базу с тремя полями Название сервиса, Логин и пароль
Там и храним, очень удобно, также позволяет контроллировать уникальные пароли. В случае чего можно и экспортировать и напечатать.
Там и храним, очень удобно, также позволяет контроллировать уникальные пароли. В случае чего можно и экспортировать и напечатать.
Вам не надоело в каждом комментарии пиарить свой сервис?
Мы поделились с человеком нашим рецептом. То, что МТХ позволяет делать многое, только плюс сервиса, а Ваши минуса дело Ваше.
Правильно! Боритесь с ним! А то вдруг распиарит свой сервис, чего-нить еще добьется, а вы так и будете сидеть и «бороться».
просто можно пиарить красиво, а не писать на заборах кругом.
1Password с синхронизацией через DropBox.
Проще всего сделать сайтик. Там есть группы пользователей и есть группы документов (1 группа на 1 проект).
Active Directory. Отдельный пароль нужен только для svn.
мы используем passpack.com
Используем свою собственную Web систему. Доступ по HTTPS + шифрование информации о паролях в базе 3DES, распределение прав по отделам.
Я бы на вашем месте написал свой корпоративный веб-сервис. Будет удобная и полностью заточенная под ваши нужды система
Вот я лох то. В тех студиях, где я работал — всё в файликах, не запароленных никак. Бывало ещё и тупо на локальном сервере =)
Ушедшим сотрудникам доверяли, текущим тем более. Пока ничем не аукнулось.
Ушедшим сотрудникам доверяли, текущим тем более. Пока ничем не аукнулось.
поверьте это пока.., я долгое время тоже думал, что не аукнется :(
Ух ты, расскажите про этот печальный опыт, пожалуйста. Хотя бы вкратце.
Да рассказывать особо нечего, все достаточно банально… Один нехороший человек взял и слил пароли другим нехорошим людям, которым наша студия чем-то не угодила. Они сколько смогли успеть за ночь, столько и нагадили (базы удалили, кое-где шаблоны, скрипты и т.д.) мы конечно все восстановили, но приятного все равно — мало.
У нас был опыт — на сервере папку /var/ удалили. Для справки там mysql был, и логи.
Это опасно даже не из за сотрудников — просто тупо может пролезть троян или руткит и ваши пароли уйдут. Антивирусная защита увы не панацея.
Введите должность — системный администратор паролей.
Пароли доступа храню в защищенном файле Excel.
При необходимости создается временный аккаунт.
Пароли доступа храню в защищенном файле Excel.
При необходимости создается временный аккаунт.
Посмотрите Clipperz.
Имеется офлайн-версия, для установки на лок. сервер.
Мультиюзерность не поддерживается (один пароль на вход + одноразовые пароли).
Имеется офлайн-версия, для установки на лок. сервер.
Мультиюзерность не поддерживается (один пароль на вход + одноразовые пароли).
Lastpass позволяет расшаривать пароли для своих людей.
Password Keeper http://olegprojects.narod.ru/downloads/PassKeeper.html
ssh — авторизация по ключу
пароли для браузеров и прочего — kdewallet с отдельным общим файлом кошелька на NFS. Для личных паролей используется личный файл-кошелек.
пароли для браузеров и прочего — kdewallet с отдельным общим файлом кошелька на NFS. Для личных паролей используется личный файл-кошелек.
root доступ к серверам через VNC ip kvm для самых крайних случаев. Каждый хранит свои пароли как хочет, если что, можно сделать ресет.
Для доступа к «корпоративным» сервисам заводим для каждого сотрудника учетные записи, при уходе — просто их «банят» (или меняют пароль, удаление учетки не вариант). Для доступа к сторонним (чаще всего клиентским) сервисам, исключающим или сильно затрудняющим возможность доступа нескольких пользователей с нашей стороны — простенькая БД из 6-ти таблиц (user, group, client, service, permission, perm_detail) c веб-мордой, позволяющая оперативно предоставлять (или убирать) сотруднику доступ к паролям к тем или иным сервисам. Потенциальная уязвимость — при прекращении доступа сотрудника к паролю не исключено, что он может пользоваться доступом, если мы не уведомим клиента о необходимости смене пароля и сообщения нового нам (для части клиентов можем пароли сами менять, уведомляя об этом). Вообще стараемся, чтобы к сервисам одного клиента осуществлял доступ только один сотрудник, дабы лишний раз не напрягать клиентов своими внутренними «разборками» типа «у нас уволился старший помощник младшего верстальщика, смените пароль к ресурсу ftp://example.com для пользователя user и сообщите его нам»
Написали небольшое веб-приложение, которое хранит зашифрованные пароли в базе на локальном сервере. Расшифровываются ключом, хранящимся в головах.
В остальном обычный набор плюшек: юзеры с доступом по айпи и разовой авторизацией через ссылку на почту, категории с бесконечным вложением, поиск по всем полям, доступ юзеров к конкретным категориям, а не ко всему дереву.
В итоге избавились от необходимости писать в асечку или на почту с просьбой выслать доступы, как и отвечать на такие письма/сообщения.
Плюс есть личная категория со своим ключом и доступом только самого юзера, но ей, вроде бы, никто не пользуется =)
В остальном обычный набор плюшек: юзеры с доступом по айпи и разовой авторизацией через ссылку на почту, категории с бесконечным вложением, поиск по всем полям, доступ юзеров к конкретным категориям, а не ко всему дереву.
В итоге избавились от необходимости писать в асечку или на почту с просьбой выслать доступы, как и отвечать на такие письма/сообщения.
Плюс есть личная категория со своим ключом и доступом только самого юзера, но ей, вроде бы, никто не пользуется =)
В одной немецкой конторе где я работал пару лет (200+ сотрудников), использовали Password Manager XP. Он не такой удобный как KeePass, но позволяет работать с паролями одновременно нескольким пользователям.
Естественно не бесплатный, но если у вас большая студия…
Проблему с уволившимися сотрудниками до конца не решишь, особенно для внешних сервисов, но по возможности можно разрешать доступ к сервисам (ftp-например) только из внутренне сетки конторы. Из дому можно соответственно по VPN работать. После увольнения спертый пароль не поможет, если человек не сможет попасть в корпоративную сеть.
А в остальном на доверии, да. Без этого тоже никак.
Multi-user password manager
support for multiple databases;
ability to access passwords databases from multiple computers across the network;
adjustable user privileges per given database;
permissions can be set for folders or even individual records;
concurrent write access to a database for multiple users;
NT authentication support;
logging of all data changes;
users' actions logging (Professional / Corporate edition only);
Естественно не бесплатный, но если у вас большая студия…
Проблему с уволившимися сотрудниками до конца не решишь, особенно для внешних сервисов, но по возможности можно разрешать доступ к сервисам (ftp-например) только из внутренне сетки конторы. Из дому можно соответственно по VPN работать. После увольнения спертый пароль не поможет, если человек не сможет попасть в корпоративную сеть.
А в остальном на доверии, да. Без этого тоже никак.
Эникейщик, вэбмастер и менеджер. Пользуюсь LastPass.com. Имеется возможность делегировать пароли.
Пользуюсь блокнотом. Файл лежит на шифрованом томе.
У нас примерно такая схема:
1. У каждого сотрудника свой keepass-файл с его персональными паролями к сервисам и необходимым службам. Все файлы хранятся в онлайне, можно получить доступ из любого места. При изменении/добавлении паролей, новых служб файлы синхронизируются.
2. Мастер-пароль для шифрации этого файла сотрудник знает наизусть, обычно это какой-то легкозапоминаемый стишок или что-то подобное, типа «мама мыла раму» в английской раскладке.
3. Этот же мастер-пароль хранится в отдельном файле masterbase, то есть пароли для всех сотрудников хранятся там. Любой администратор может взять файл пользователя и от его имени куда-то зайти, потестировать работу чего-то и т.п. Мастер-пароль к masterbase администраторы знают наизусть, тоже стихи всякие :-)
4. Плюс есть еще служебные файлы, некий administrative, в котором хранятся пароли к DNS, всяким там железкам и т.п.
5. Ключи ssh всем админам генерируются отдельно, с использованием того же мастер-пароля, хранить их смысла нет где-то в онлайнах, обычно на флешке он или еще где-то. В крайнем случае можно зайти паролем из masterbase/administrative/еще чего-то.
В общем, все достаточно прозаично, легко расширяется и можно не боятся утечки. У нас нет большого количества отделов и админов, которые отвечают за разные сервисы. Но если повятся, то точно так же легко это можно расширить, разделив функционал файлов.
1. У каждого сотрудника свой keepass-файл с его персональными паролями к сервисам и необходимым службам. Все файлы хранятся в онлайне, можно получить доступ из любого места. При изменении/добавлении паролей, новых служб файлы синхронизируются.
2. Мастер-пароль для шифрации этого файла сотрудник знает наизусть, обычно это какой-то легкозапоминаемый стишок или что-то подобное, типа «мама мыла раму» в английской раскладке.
3. Этот же мастер-пароль хранится в отдельном файле masterbase, то есть пароли для всех сотрудников хранятся там. Любой администратор может взять файл пользователя и от его имени куда-то зайти, потестировать работу чего-то и т.п. Мастер-пароль к masterbase администраторы знают наизусть, тоже стихи всякие :-)
4. Плюс есть еще служебные файлы, некий administrative, в котором хранятся пароли к DNS, всяким там железкам и т.п.
5. Ключи ssh всем админам генерируются отдельно, с использованием того же мастер-пароля, хранить их смысла нет где-то в онлайнах, обычно на флешке он или еще где-то. В крайнем случае можно зайти паролем из masterbase/administrative/еще чего-то.
В общем, все достаточно прозаично, легко расширяется и можно не боятся утечки. У нас нет большого количества отделов и админов, которые отвечают за разные сервисы. Но если повятся, то точно так же легко это можно расширить, разделив функционал файлов.
А почему никто ещё не сказал про такую прелестную штуку, как cpassman
opensource, функционал довольно высок. На сайте была демка)
opensource, функционал довольно высок. На сайте была демка)
Демка — не имеется в виду версия с урезанным функционалом для разжигания аппетита с последующим предложением купить полную версию, как можно было подумать, прочитав мой коммент выше.
www.cpassman.org/demo — здесь можно попробовать поюзать эту замечательную штуковину, перед тем, как разворачивать её у себя.
Вкратце cpassman — веб-приложение для хранения паролей. Роли с разделением прав и прочее присутствует.
www.cpassman.org/demo — здесь можно попробовать поюзать эту замечательную штуковину, перед тем, как разворачивать её у себя.
Вкратце cpassman — веб-приложение для хранения паролей. Роли с разделением прав и прочее присутствует.
password safe
контейнеры можно открывать по сети, +vpn например
сделать несколько контейнеров в зависимости от уровня доступа:
— для менеждеров
— для сисодминов
— для контентщиков
контейнеры можно открывать по сети, +vpn например
сделать несколько контейнеров в зависимости от уровня доступа:
— для менеждеров
— для сисодминов
— для контентщиков
Достался мне год назад сайт по наследству. В первую очереди полез в таблицу «administrators» и увидел там 5 записей с правами админа. Именя были типа test***, *названиестудии*, и т.п., пароли у всех одинаковые. Ну ладно думаю, потёр всё, создал себе учетку… Но мысль о возможности наличия этих записей в других проектах этой студии мне покоя не давала. Залез я на их сайт, и что вы думаете? Все проекты начиная с 2005 года имели те же самые записи! Все! Абсолютно все! А сайты с неплохим пузом, начиная от 1500тиц и 4пр. Я им в саппорт отписал, и до сих пор они это не пофиксили! А прошло уже месяцев 8-9.
надо туда сапу вешать )) (шутка)
надо туда сапу вешать )) (шутка)
truecrypt
_http://www.enterprise-password-safe.com/
в идеале система хранения паролей должна интегрироваться с тикетной системой используемой в компании.
в идеале система хранения паролей должна интегрироваться с тикетной системой используемой в компании.
пароли только в бумажном ежедневнике. ничего в электронном виде.
а вот сертификаты на флешках, дискетах, токенах и прочее конечно имеется
бухгалтерский консалтинг 200+ человек, москва
а дома свое добро на KeePass
сейчас как раз ищу под него мобильный клиент.
плохо ищется(
а вот сертификаты на флешках, дискетах, токенах и прочее конечно имеется
бухгалтерский консалтинг 200+ человек, москва
а дома свое добро на KeePass
сейчас как раз ищу под него мобильный клиент.
плохо ищется(
смешно читать спор идеалистов-параноиков с людьми, которые занимаются реальной работой
Как ключи выдаются мне:
Как хранятся у меня локально:
И, разумеется, файрвол на серверах, дающий доступ только к нужным вещам и только из нужных мест. Приватный ключ или пароль на SSH вне сети компании совершенно бесполезен. Если нужен всё же доступ извне — есть VPN в локальную сеть организации.
- Доступ к git — закрытые ключи несимметричного шифра, выдаются сисадмином.
- Пароли на те места, где нужен пароль (например, таким был бы пароль на FTP у разделяемого между юзерами хостинга, если бы у нас были такие проекты) — закрытая страница проектной wiki, доступная лишь участников проекта.
- Разовый доступ — в нашем случае не имеет смысла. Сейчас объясню, почему. О целенаправленном доступе к данным — любой сотрудник, которому доступ может потребоваться, обладает квалификацией сделать себе доступ навечно, воспользовавшись разовым логином. О случайной порче данных — подавляющему же большинству доступ к боевым серверам просто не нужен. При грамотно организованном процессе дизайнеру, верстальщику, тестировщику и Javascript-программисту доступ к серверу ни к чему, а вся работа на сервере, как правило, ограничивается запуском /var/www/<project-name>-<deployment-suffix>/bin/update, что так же минимизирует риск что-то случайно испортить.
Как хранятся у меня локально:
- HTTP, HTTPS, SVN, IMAP — kpasswordmanager сам их расшифровывает и вставляет в формы в браузере или другом приложении. Шифр симметричный, хранение ключа в ОЗУ 15 минут.
- VCS, SSH — шифрованый симметричным шифром раздел с закрытыми парами ключей
И, разумеется, файрвол на серверах, дающий доступ только к нужным вещам и только из нужных мест. Приватный ключ или пароль на SSH вне сети компании совершенно бесполезен. Если нужен всё же доступ извне — есть VPN в локальную сеть организации.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Поделитесь опытом, как у вас в студии организовано хранение и менеджмент паролей?