Milyen shared password megoldást gondolsz hatékonynak?

Vélemény

Central pw management sw, pw-ket ki lehet csekkolni, majd becsekkolni egy új pw-t.
30% (40 szavazat)
Central pw management sw, pw-ket ki lehet csekkolni, majd becsekkolni ugyanazt a pw-t.
11% (15 szavazat)
Default pw-t mindenhova!
19% (25 szavazat)
Egyéb, leírom hozzászólásban.
40% (53 szavazat)
Összes szavazat: 133

( m.informatikus | 2017. 08. 27., v – 15:01 )

A probléma: van h. key nélkül, pw-vel kell használni _több embernek_ local usereket. Mi lehet a leghatékonyabb, ténylegesen jól működő megoldás a problémára?

( nxu | 2017. 08. 29., k – 15:11 )

A use case-t kell megváltoztatni, ha lehet.

( gyu v | 2017. 08. 29., k – 15:35 )

Bár élőben sosem láttam olyan konfigot összelőve, de nálam ezen a téren a szent grál az amit mondjuk egy SCB+ Lieberman párossal össze lehet lőni.

Lieberman kezeli amit kell pw-management oldalon.
Akár minden gépen, akár loginonként eltérő Administrator/root pw-vel, vagy amit csak el tudsz képzelni gyakori csere-berével.

Amikor meg ténylegesen adminkodnál valami szerveren, a tényleges belépést SCB-vel auditált kapcsolaton keresztül követed el, oda beazonosítod magad a domain usereddel _ÉS_ mivel megvan a megfelelő csoporttagságod az SCB majd elkéri az admin jelszót a liebermann-tól és majd átadja azt a szervernek.

Ennek butítottabb változata a kézzel (scripttel) cseréled a pw-ket a szervereken és kézzel (scripttel / API-n) updateled a pw-ket az SCB saját credstore-jában.

( gelei v | 2017. 08. 29., k – 16:47 )

(X) Egyéb

Kirúgni mindenkit, akinek köze van a szituáció létrejöttéhez.
2017-ben milyen use case létezhet arra, hogy mindenkinek szándékosan ugyanazt az 1 db local accountot kell nyúznia?

Ki mondta, hogy kell? Simán lehet olyan felállás, hogy alapból mindenkinek van saját accountja, de néha előfordul, hogy a saját account vagy nem elérhető (lehalt az LDAP server), vagy épp nem ismered a jelszót (2 hónappal ezelötti backup lett restore-olva).
____________________________________
Az embert 2 éven át arra tanítják hogyan álljon meg a 2 lábán, és hogyan beszéljen... Aztán azt mondják neki: -"Ülj le és kuss legyen!"..

Te nem tudom hogy vagy vele, de én már láttam hálózatot vesztett rendszert, ahol csak virtual terminalon keresztül lehetett belépni root-al, mert az individual ID-k meg a network issue miatt nem voltak elérhetőek LDAPról.
____________________________________
Az embert 2 éven át arra tanítják hogyan álljon meg a 2 lábán, és hogyan beszéljen... Aztán azt mondják neki: -"Ülj le és kuss legyen!"..

Ebben mondjuk lehet valami, mert esélyes, hogy én másként értelmeztem a kérdést: Az én olvasatomban a shared ID-knak* kell egy külön password manager tool amin keresztül ki tudják kérni az aktuális jelszót, viszont ezeket az ID-kat szökőévente ha egyszer kell általában használni - BAU melóra ott vannak az individual ID-k, az SSH kulcsok, sudo beállítások, RBAC meg amit akarsz..

* Azon ID-k amik egy csapaton belül meg kell legyenek osztva, de az ID direkt használata csak indokolt esetben engedélyezett, akkor is teljesen auditálhatóan dokumentálva.
____________________________________
Az embert 2 éven át arra tanítják hogyan álljon meg a 2 lábán, és hogyan beszéljen... Aztán azt mondják neki: -"Ülj le és kuss legyen!"..

Ezt játszd meg akkor amikor a szerver egy teljesen másik GEO lokáción van, és a helyi local supportosnak még azt se tudod elmagyarázni, hogy mit és hova dugjon hogy egyáltalán local terminalt kaphasson, mert kb mindenhez hozzányúlni retteg..
____________________________________
Az embert 2 éven át arra tanítják hogyan álljon meg a 2 lábán, és hogyan beszéljen... Aztán azt mondják neki: -"Ülj le és kuss legyen!"..

Több rendszergazda/operátor üzemeltet egy vagy több szervert, és nem akarod, hogy bárki is tudja a szerver aktuális jelszavát, kivéve a bejelentkezés idejéig, amit esetleg másvalakinek külön kell engedélyeznie (four eyes authorization)? Például root egy Linux szereveren?

A példában a sudo nem jó, mert erre a rövid időre kellene kigenerálni egy fájlt (/etc/sudoers.d/ alá), ami engedi a sudo-t, majd a session végén letörölni.

Szerinted a sudoersben csak egyetlen user szerepelhet?

Fel lehet venni az osszes admint oda, es mindenki a sajat jelszavaval piszkalhatja a /etc-t. Mar ha nincs csilliard szervered, es emiatt nem eri meg a fenti programok bevezetese.

De egy userhez is tartozhat tobb ssh kulcs..

--
Worrying about killer AI and the superintelligent robots is like worrying about overcrowding on Mars. - Garry Kasparov

Akkor arra a 20 percre beteszed a usert a sudoers-be szereplő csoportba, majd a sesssion végén kiveszed?
És hogyan oldod meg, hogy arra a szerverre a mondjuk 2000 vagy éppen 250.000 accountból csak pár tudjon egyáltalán belépni?

Az authorized_keys-be hogyan teszed be a kulcsot és hogy törlöd?

És hogyan trackeled, hogy kinek melyik szerverhez van hozzáférése, ha kell, név szerint (Gipsz Jakab a www2-höz hozzáfér root userrel, de az ns1-hez nem)?

Rugalmatlan elerhetetlen megrendelo, aki egyetlen accountot adott evekkel ezelott, es amugy se fizet a ceg maintenance-ert, csak a fejlesztesert fizetett anno, ezert "oruljon hogy mukodik"?

A donteshozokat akik ezt nem akarjak lecserelni dragan, vagy lefejlesztetni a korabbi kulsos fejlesztoceggel a rendesebb user managementet szinten dragan pedig nem tudod kirugni: ok a fonokeid. :P

( sj | 2017. 08. 29., k – 17:19 )

ez a dizajn fucked by design...

--
t-systems-es it architect allast keres. Jelige: csak webshopot ne kelljen...

( Nyosigomboc v | 2017. 08. 29., k – 21:05 )

Egyik BME-s tanarom eladason elmondott egy feladatra 3 megoldast, es utana feltette a kerdest: melyik a legjobb? A valasz termeszetesen az, hogy "attol fugg". Ha nem az lenne, akkor csak 1 megoldas lenne ra.

A kavefozot mutato webcam kepere teljesen jo egy default pw (mondjuk a takineni macskajanak a neve). A ceges, kivulrol is elerheto akarmilyen serverre meg van praktikusabb. Marinenit nem farasztanam az utobbival, az adminnak meg a Cirmiketol allna egnek a haja.

--
Worrying about killer AI and the superintelligent robots is like worrying about overcrowding on Mars. - Garry Kasparov

( hnsz2002 v | 2017. 08. 30., sze – 06:07 )

Egyiket se. Mindenkinek legyen saját usere+jelszava.
Biztonságilag is sokkal jobb, illetve ha valami történik, látható hogy melyik userrel volt, és nincs egymásra mutogatás.
--
"Sose a gép a hülye."

( zrubi v | 2017. 08. 30., sze – 09:13 )

Ha mindenképp szükség van shared password-re, akkor nyilván az egyszer használatost javasolnám. (azaz az 1. opció)

Azonban ilyet a gyakorlatban én még nem láttam értelmesen működni (használni)

Helyette azonban eddig minden általam ismert cégnél gagyi, - de legalább mindenre használt default password volt. Őőőő vagyisinkább van. ;)

--
zrubi.hu

( joco01 v | 2017. 08. 30., sze – 09:30 )

Nyilvánvaló, hogy ahol csak lehet, minden felhasználónak egyedi loginja legyen. De van sok olyan helyzet, ahol ez nem szükséges/nem működik. Pl. a cég közös Ipon accountja, a printer jelszava, a riasztó kódja, stb. Az is nyilvánvaló, hogy tartozik access control és audit a közös jelszavakhoz. De több ember is elérheti ugyanazt a jelszót.

( htmm v | 2017. 08. 30., sze – 10:07 )

Ha mar ilyen takolasok kellenek, akkor:

* Central pw management sw, pw-ket ki lehet csekkolni, majd a pw manager megvaltoztatja a jelszot

(Az elso pont becsekkolni egy új pw-t resze ott bukik, hogy az aktualis ember tudja az uj jelszot.)

--
http://blog.htmm.hu/

( hory v | 2017. 08. 30., sze – 19:12 )

Mondjuk attol is fugg, hogy amugy hogy van vedve a rendszer. Teszem azt, egy shared password is lehet OK, ha pl. knockd vedi a tuzfalat es csak sima user login utan ferheto hozza a root.

( asd | 2017. 09. 01., p – 20:23 )

Nincs hatekony shared password megoldas.

A legjobb megoldas, ha jelszavakat nem osztanak meg tobb ember kozott, mert a jelszo mint eszkoz, hitelesitesre, es nem felhatalmazasra szolgal.

Lehet ugyan hitelesites helyett felhatalmazasra (vagy arra is) hasznalni, es belepni a 'kozossegi jelszokezelok' temakorebe, de ha valaki ebben az iranyban gondolkodik, akkor van egy kalapacsa, es epp mindent szognek nez, azaz van egy megoldasa, es azt akarja mindenre raeroltetni.

Ha valaki tudja a jelszot, akkor egyszerre van azonositva es hitelesitve is a szolgaltatas hasznalatahoz, es csak ugy lehet tole 'elvenni' a felhatalmazast, hogy a hitelesitest valtoztatod meg.

Arrol ne is beszeljunk, hogy a jelszavak ilyen kezelese az egeszet DAC (https://en.wikipedia.org/wiki/Discretionary_access_control) alacsonyitja le, szoval egyszeruen: ha valaki tudja a jelszot, tovabb is adhatja, megtarthatja, direkt vagy veletlenul kiszivarogtathatja.

OTP is egy jelszo, tehat mukodokepes megodas lehet TOTP-t konfiguralni es egy kozponti szerverre bizni a jelszo kiadasat.

Dániel Vásárhelyi
https://www.linkedin.com/profile/view?id=36130803