Съхраняване на пароли към клиентско оборудване
Общност от ръководители на ИТ компании, ИТ отдели и сервизни центрове
Влез с:
Упълномощаване
Нови потребители
Във веригата от внедрявания се сблъскахме с такъв въпрос. И как съхранявате пароли за различен хардуер, който имат вашите клиенти?
Със сървърите е ясно, там можете да създавате акаунти, прикачени към администратори, и какво да правите с суичове, различни елементи на ACS, рутери и т.н. Тук личните пароли не са много подходящи и не можете да сте сигурни, че целият хардуер на всички клиенти ще поддържа Radius, какво да правя? Може би някой вече има готови решения или мисли по тази тема? Ще се радвам на всякакви препоръки.
Коментари (33)
Дмитрий вероятно имаше предвид: База данни за управление на услуги (SMDB) от библиотеката ITIL, което означава DB за управление на конфигурацията (CMDB)
Можете да започнете да копаете от тук))
Благодаря за отговора, повече подробности са написани тук: http://www.osp.ru/os/2009/05/9862477/
Дмитрий предложи твърде широко решение на моя тесен проблем. Няма ли споделени корпоративни мениджъри на пароли?
SMDB със сигурност е добър, но за начало трябва да направите пълен опис, където ще бъдат посочени всички пароли за оборудването.
Но най-трудното е да поддържате както инвентара, така и SMDB в текущото състояние, тъй като често всичко се променя много динамично и на физическо ниво и е много трудно да се запише всичко в числа.
Анатолий, улучи целта! След пълна инвентаризация и въвеждане на данните в базата знания се натъкнах на проблема със съхраняването на пароли. KB съхранява обща информация за предназначението, местоположението и метода на достъп до оборудването, но съхранява паролите за достъп заеднос тази информация не я смятам за вярна, затова повдигнах този въпрос за обсъждане.
2wooch благодаря, ще погледна!
Е, също така е възможно да се направи карта (топология) на мрежата, където ще бъдат посочени всички необходими изяви и пароли или връзки към тях (къде да се търси), тя е бързо достъпна, но ако има много zhileaz, тогава ще отнеме доста време, за да се разпръсне какво е за какво и защо работи. Не е като без SMDB.
Нека просто кажем: пълен инвентар + мрежова карта. За малък бизнес това е нормално и не е нужно да се стараете много, за да опишете SMDB.
Ако някой има други идеи и виждания, ще се радвам да ги чуя. :)
Колеги, вашият бранш много се отдалечи от темата. Но темата за взаимодействието с изпълнителите на 1C е много интересна)
Улесних някои клиенти, изгоних всички от мрежата и от сървърите, направих виртуален сървър-огледало на истинския и те ровят там колкото им трябва и получават достъп до истинския чрез заявка в стриктна и съгласувана форма, 90% от проблемите изчезват веднага)
забавни истории. не искам да чуя. трала-ла-ла.
и между другото, там могат да се обсъждат и моделират много чисто практически ситуации, но ситуации в нашата област - не е нужно да ходите на цирк.
Така че вече втора седмица призовавам хората да се съберат, досега успяха да усвоят първата среща с малък екип.
Следва виртуална среща.
Винаги сте добре дошли да се присъедините)
И темата как да сложите пари в джоба си и повече е по-интересна?
Може да има само един отговорен.
ако има няколко ИТ изпълнители, тогава сферите на влияние (включително пароли) са строго разграничени.
вече премина през други пътища. не доведе до нищо добро.
Не споря - периодично имаме такива ситуации в рамките на различни проекти.
Доставчик (консултант, аутсорсинг)осигурен е необходимият и достатъчен достъп - той и администрира (внедрява) новото и обучава нашите. Една от последните задачи на проекта е прехвърлянето на правата на нашите администратори и изключване от "мениджмънта" на доставчика (. ). Веднага след като стигнахме до такава схема, проблемите с разгръщането (внедряването) на нова с активното участие на "външни лица" практически изчезнаха. Докато "новостта" не е преминала в търговска експлоатация - цялата отговорност (както и "пароли и изяви") е на "внедрителите", а щом премине - наша отговорност.
сега използваме KeePass като работеща опция. Програмните файлове се намират на корпоративния сървър в центъра за данни. служителят, отговорен за определена компания, получава достъп до файла и паролата. за поддържане на едни и същи пароли късам яйцата, не винаги в преносен смисъл. Всички 6 промени са задължителни. от професионалистите - ако клиентът иска паролите - изхвърляме файла и разпространението на програмата до него. и има генератор на пароли.
има и 2-ра опция, искам да я използвам, но се поврежда, като плъзгате всички пароли ръчно (да, твърде мързеливо)). на едно и също място на базата на сървъра sql под всеки клиент. достъп през стандартен phpmyadmin - Създавам потребител и парола за базата данни за конкретен служител, клиентът, ако желае, получава паролата от базата данни и уеб фейса на phpadmin. Веднага щом той прекрати договора, дезактивирам този потребител. печалба. от минусите е по-малко удобно без генератор на пароли и копирането е малко по-дълго, отколкото от мениджър на пароли.