Előfordulhatna nálatok, hogy egy munkatárs elérhetetlensége esetén nem bírnátok egy feladatot végrehajtani jelszó hiányában?

Kérdés

Elő
38% (135 szavazat)
Nem, és erre internetes megoldásunk van
8% (28 szavazat)
Nem, és erre szigorúan intranetes / offline gépes megoldásunk van
19% (67 szavazat)
Nem, és erre papír és toll alapú megoldásunk van
6% (21 szavazat)
Nem, és erre szociális alapú szóbeli megoldásunk van
8% (30 szavazat)
Fogalmam sincs, nálunk ez mennyire megoldott
11% (39 szavazat)
Egyéb, leírom hozzászólásban
10% (35 szavazat)
Összes szavazat: 355

( trey | 2014. 12. 10., sze – 12:50 )

Először is, milyen elérhetetlenség? Engem értek már el törött könyökkel, mikor éppen toltak be a műtőbe, vagy külföldön is, amikor olyan szigeten voltam, ahol szinte semmi kommunikációs lehetőség nem volt.

Másodszor ahol minőségbiztosítás (pl. ISO) van érvényben, az szabályozza ezt a kérdést.

A betartását pedig az éves audit keretében ellenőrzik.

--
trey @ gépház

Az tiszta sor, hogy ha valamit szándékosan nem tartasz be, akkor tök mindegy, hogy van-e vagy nincs. Viszont ha szabályozva van, azt számon lehet kérni, arra lehet hivatkozni. Ha neked kellene dolgozni, de a címben leírt okból akadályoztatva vagy, akkor ha neked szegezik a kérdést, hogy miért nem csinálod, akkor te meg felteszed a kérdést, hogy az ISO / Informatikai Kézikönyv mit mond erről a helyzetről?

Innentől kezdve feléd nem nagyon lehet egyéb kérdés. Aki meg szart rá, az adjon számot róla, hogy miért szart rá.

--
trey @ gépház

( foci v | 2014. 12. 10., sze – 13:21 )

Miért milyen jelszót nem tudok megváltoztatni/feltörni?!
Volt ilyen amikor nem tudtam a domain kontroller admin jelszavát...
1 napig :)
Gabi

Mindezt tessék a szolgáltatás kiesése nélkül produkálni. Olyanhoz nekem is volt szerencsém, hogy üzemeltetésre kellett visszavenni eszközöket igen rövid idő alatt, és bizony ott ütemezett leállítás és az eszköz gyári "elfelejtett jelszó" procedúrája következett... Rengeteg autózással nyakon öntve - mindezt szolgáltatáskiesés nélkül nem lehetett volna megtenni; azóta arrafelé is szeretik a borítékba rakott jelszót :-P

"akkor a jelszo idoneknti megvaltoztatasa nem nagy divat arra fele se."

Ami atlagembereknel amugy is tobb biztonsagi kockazatot jelent mint amennyit kived (foleg ha 90 naponta kell valtoztatni, nem "valami eset utan" vagy "2 evente"). Nalam anno a Bukarest Bank diakkoromban ezzel a policy-jevel elerte hogy mar egy papirfecnin is rajta volt a netbankolos jelszavam es ha megtarthattam volna az elsot, ez sose tortenik meg.

1) az alapfelvetes az volt, hogy le van irva es be van rakva boritekba.
2) ez nem atlaguser account hanem olyan account ami miatt egy feladatot nem lehet vegrehajtani. Lehet ez sok minden, netbank, isp login stb. Attol fugg, hogy mennyire nagy kart okozhat kell rotalni.

Annyiban jogos, hogy nem kell mindenhol password rota de pl egy public server, nyitott ssh porttal es allowed root login-al, mondjuk megerne egy 90 napos jelszocseret minimum.

Ebben egyetertek, de azt nem atalgemberek uzemeltetik. Atlagember nem kapcsolodik SSH-ra. :) Az atlagemberek jelszo rotation-jevel volt a para.

Egyebkent lehet uj boritekot nyitni jelszo csere eseten, alairos "kezi log" mukodik. Es akkor beteszed a regi jelszavas boritek helyere, es alairod hogy te ekkor nyultal hozza. Szoval azzal a resszel nem ertem mi a gond.

+sok

Erre _semmilyen_ mentség nincsen.
Az még csak-csak, hogy kifelé nyitva a 22, van ilyen.
De root login-t semmiképp nem engednék, legfeljebb bizonyos usereknek sudo.
Még a keyboard-only autentikációt sem nézem jó szemmel. Aki be akar jelentkezni, annál legalább legyen ott a kulcs.

Számos olyan szervert látok manapság, ahol zsigerből így van megcsinálva "mer' így kell" alapon. Miközben virtuális gépben futó kvázi applienaceről beszélünk, ahol egyetlen fő szolgáltatás fut (smtp, web, akármi), de ha netán több van ennél, akkor sincs nem-root system usernek az égegyadta világon semmi dolga shellben/ssh-n. Megnézve az ssh-ra engedélyezett 1db adminisztratív user .bash_history-ját, kizárólag "sudo su -" parancsok vannak benne évekre visszamenőleg, semmi(!) más. Ennek pl így mi az isten értelme van?

Kicsit kényszeresnek érzem ezt, és hátráltatónak néha. Aztán mikor megkérdezem hogy miért így van, akkor megvető pillantásokat látok, "na, ez se ért hozzá" felhanggal, de épkézláb magyarázatot azt nem igen kapok. Így szokás na, ne értetlenkedjél már, ezt mindenki tudja!

Persze a fenti kérdésnél vegyük figyelembe azt a tényt, hogy a jelszó bitang erős, vagy kulcs alapú, az ssh pedig nem érhető el a 22-es porton, és filterezve is van.

Pl. az az értelme, hogy a usernek nem kell tudni a root jelszót, mert sudo esetén a sajátjával autentikál.
Meg aztán ugye az egy másik kérdés, hogy engedélyezve van a sudo su. Illene egy korrekt sudoers-t csinálni.
Az a baj, hogy mindenki szeret root-ként ész nélkül nekiesni bármilyen problémának. Mert az gyorsabb(nak), egyszerűbb(nek tűnik elsőre). Pedig ez csak hozzáállás kérdése.

Az ügyfelekhez telepített hálózati eszközeinkből mind kiirtottuk a root hozzáférést. Először picit morogtak a fiúk, de aztán úgy tűnik, mégsem dőlt össze a világ.

Előfordul pl. olyan, hogy teljes és garantált visszakövethetőséget kell biztosítanod, mert az ügyféllel erre szerződtél. Amíg valaki (akár a mi, akár az ő munkatársuk) root-ként be tud lépni, ezt nem tudod garantálni. Mert elméletben babrálni tud a logokkal (local), a log démonnal (hogy remote se legyen), a tűzfallal (detto), akármivel.

Ritkán van olyan, hogy egyszerre mindennel babrálni kell. Általában vagy a hálózati interfészeket, vagy valamelyik service-t kell kefélgetni gond esetén. Sajnálom, ha egyeseknek bántja az egóját, ha mindeközben nem '#' a prompt.

>Pl. az az értelme, hogy a usernek nem kell tudni a root jelszót, mert sudo esetén a sajátjával autentikál.

Bocs, olyanra gondoltam ahol tudja, ő telepítette, ő üzemelteti, felel érte, stb.., csak beragadt nála ez a dolog.

A példának felhozott rendszereken egyetlen user van, és kizárólag azért hogy sudo-zzon, bármi amihez nyúl, root jogok kellennek hozzá. Természetesen ahol több system user van, akik aktívan használják a shellt egyéb célokra, az más tészta. Itt olyan szervereket képzelj el, amin nem fut más csak 1db exim, vagy egy apache, vagy egy dovecot. A logok feldologozása is remote történik, a szolgáltatáshoz kapcsolódó userek is adatbázisból jönnek. És ilyenből mondjuk van 100db, és minden egyes alkalommal belépnek a "joska" userrel, aztán sudoznak.

Nos, mindenkinek lelke rajta, hogyan üzemeltet.
Azért én nem örülnék neki, ha joska valamilyen okból megvadulna és trükközni kezdene a szervereken. Mivel root-ként a log démont is bármikor ki/be kapcsolhatja illetve átkonfigurálhatja, még észrevenni sincs esélyem.
Elfogadom, hogy vannak olyan helyzetek, ahol ez nem annyira számít, de ettől függetlenül nem örülnék neki.

Szerintem meg max egy kis nehézséget okoz a behatolónak az ha nincs elsőre root jo,ga semmi többet, már ha komoly szándékkal töri a rendszert.
Ez kb. annyit ér mint áthelyezni egy másik portra az ssh-t.
Hogy mire alapozom a véleményem? Egy szolgáltatáson keresztül feltörni egy rendszert sokkal nehezebb, mit mondjuk egy shell hozzáférésből csinálni egy root-t hozzáférést. Ha valaki bent van ssh-n akkor az onnantól nem a root jelszót fogja megpróbálni feltörni, sokkal valószínűbb hogy 0day hibát kihasználva fog hozzáférést szerezni.

Nos, hangsúlyozom, személyes vélemény következik.
Szerintem a(z időalapú) password rota inkább rossz, mint jó.
Nálunk pl.
- egy csomó kollégának e miatt van gyenge jelszava
- egy csomó kolléga emiatt használ szisztematikus, vagy kikövetkeztethető jelszavakat
- e miatt van felírva egy csomó jelszó, sokszor magára a gépre (a változtatott rész mindig tollal áthúzva, mellé írva az aktuális)

Az emberek nem változnak. Hiába követelsz meg minimum hosszt és karakterosztályokat, a 'paraszt' úgyis megtalálja a módját, hogy az entrópia kicsi legyen vagy az egymást követő jelszókban valamilyen szisztéma legyen.

Inkább legyen erős jelszava, amit nem ír fel sehova és komolyan veszi, vigyáz rá.

+1

A Diákhitel Direkt ilyen. 30 naponta új jelszó, nem lehet az, ami már volt (itt állítólag csak az utolsó 3 nem lehet, de tapasztalat szerint semmi olyan, ami volt), legyen benne anyám kínja is, stb.
Én rühellem.
Ennek okán az átlagos használat úgy néz ki (nálam), hogy jelszóemlékeztető, valami bullshit új jelszó, majd legközelebb újra.
--
blogom

Miért is nem? A technikai jelszavakra valóban a standard 30-60-90 napnál hosszabb lejárat a jellemző - cserébe viszont a minimum hossz, illetve a kötelezően használandó karakterosztályok száma nagyobb. És a borítékra rá lehet írni, hogy mikor lett leadva - ez alapján meg az azokat kezelő személy(ek) tudják force-olni a boríték- és jelszócserét.

És a jelszókezelő jelszavát ki fogja ismerni? Vagy mindenki, akinek van legalább egy érintett rendszerére vonatkozó jelszó benne?
A borítéknak az előnye többek között az egyszerű kezelés, a hozzáférés naplózhatósága és észlelhetősége, megfelelő elhelyezés/tárolás esetén katasztrófatűrése, a jogosultságok egyszerű kezelhetősége, shared secret alkalmazása is faék egyszerű vele, stb. Ja, és nem jelszó, hanem kulcsfelvételi jogosultság kell a hozzáféréshez, ami illendően pozícióhoz kötött jogosultság.

"És a jelszókezelő jelszavát ki fogja ismerni?"
Hat akinek kell, nem kell mindent egy jelszokezelobe berakni, problem solved.

"Ja, és nem jelszó, hanem kulcsfelvételi jogosultság kell a hozzáféréshez, ami illendően pozícióhoz kötött jogosultság."
ertem, es ezt softwarebol nem trivialis megoldani?

"hozzáférés naplózhatósága és észlelhetősége"
szoval minden reggel megnezitek, hogy a boritek epsegben van-e?

"a jogosultságok egyszerű kezelhetősége"
hat ez pont annyira igaz mint a egy teszem azt passwordsafe filera. Aki tudja, hogy hol a kulcs, mi a jelszo stb.

"shared secret alkalmazása is faék egyszerű vele"
igen, valoban egyszerubb berakni egy pendriveot egy boritekba es pendrive integritycheck minden reggel miutan meggyozodtunk rola, hogy a boritek epsegben van:/

Nem kell senkinek sem birtokolnia olyan információt a boríték esetében, ami a hozzáféréshez szükséges. Bármilyen más megoldás esetében meg igen. És ez az információ nem köthető kizárólag pozícióhoz, csak személyhez. Legalább kettőnek kell ismerni (akik pl. nem utazhatnak egy autóban...), és rendelkezésre kell állniuk 7x24 órában (legalább az egyiküknek). Ha bármelyiküket elküldik, akkor jelszócsere következik.

Szoftverből hogy oldod meg, hogy a "biztonsági felelős" pozícióhoz kötöd a hozzáférést? Például a címtár (amiben a céghierarchiát is letároltad) helyreállításához van szükség a jelszóra.

Nem minden reggel, hanem bármikor ellenőrizhető, hogy történt-e hozzáférés a jelszavakhoz. De akár az is lehet, hogy a páncélszekrényhez kettő kulcs van, és két jogosult személy (pontosabban két, jogosultságot jelentő pozíciót betöltő személy) kell a kinyitásához. A lényeg, hogy nem információ, hanem jogosultság kell a hozzáféréshez.

Az egészről az a városi legenda jut az eszembe, hogy a NASA-nál csilió dollárért kifejlesztettek egy súlytalanságban is működő tollat. Az oroszok meg ceruzát használtak. Normális szabályzattal és folyamatokkal a papír - boríték - páncélszekrény, mint katasztrófatár a jelszavaknak teljesen jó megoldás.

"Nem kell senkinek sem birtokolnia olyan információt a boríték esetében, ami a hozzáféréshez szükséges."
Ertem, szoval senkinek nem kell tudnia, hogy hol a szef, hogy kell kinyitni stb.

"Szoftverből hogy oldod meg, hogy a "biztonsági felelős" pozícióhoz kötöd a hozzáférést? Például a címtár (amiben a céghierarchiát is letároltad) helyreállításához van szükség a jelszóra."
ugyanugy ahogy te megoldod a biztonsagi felelos potlasat ha eluti a busz.

"A lényeg, hogy nem információ, hanem jogosultság kell a hozzáféréshez."
ertem, es ezt softwarebol nem lehet megoldani:)

"Normális szabályzattal és folyamatokkal a papír - boríték - páncélszekrény, mint katasztrófatár a jelszavaknak teljesen jó megoldás."
normalis szabalyzattal es folyamatokkal sok mindent meg lehet oldani, de ebbol nem kellene azt a kovetkeztetest levonni, hogy az a jo megoldas.

Nem akarod érteni. Egyébként meg az, hogy hol vannak tárolva a borítékok, ki férhet hozzá, a kulcsokhoz ki(k) férhetnek hozzá az szabályzatban leírt, leírható információ. Egy jelszókezelő rendszerben a hasonló infó (hogyan nyerhető ki/érhető el a tárolt jelszó) egy további jelszó, vagy jelszó jellegű információ - vagy épp egy smartcard, ami borítékba zárva ott figyel a páncélszekrényben.

ha a biztonsági felelős szerepkört betöltő személyt elüti a villamos, a helyettesítési rend szerint megvan, hogy ki jogosult eljárni, ergo a pótlás semmilyen problémával nem jár. Igen, ha a helyettest is elüti, akkor van neki főnöke, van cégvezetés, aki tud intézkedni, utasítást adni, hogy a kulcsot kapja meg, és X, Y, és Z. kollégákkal jegyzőkönyvezve kinyitja, előszedi, felbontja, és megy tovább az élet.

Információ kontra jogosultság... Ahhoz, hogy valamilyen jogosultságot, pontosabban szerepkört elérj egy biztonsági rendszerben valamilyen módon azonosítanod kell magadat. Lehet ez akár egy smartcard is, de ha elég a kártya _birtoklása_, akkor azt kell úgy védeni, mint a jelszavak összességét, ha viszont a birtokálás mellett információ is kell, akkor ezt az információt (pin, passphrase) is el kell valamilyen módon úgy tárolni, hogy szükség esetén elérhető legyen.
Persze, az m-ből n darab smartcard együttesen nyitja a jelszótárat lehet megoldás- viszont ezeket is tárolni kell valahol (m>n)

A megoldás valahol a középúton található: jelszókezelő/jelszósafe szoftver, aminek a "vészkulcsa" valahol, fizikailag védetten van tárolva.

Akkor ismét. Lehet jelszókezelő rendszerben tárolni majdnem minden jelszót, illetve hozzáféréshez/jogosultsághoz szükséges információt - egyet nem. Azt, ami ehhez a jelszótárhoz ad korlátlan (vagy részben korlátlan), személytől független hozzáférést. (A kulcsdoboz kulcsát is tárolni kell valahol.)
Na ezt a jelszót/információt hol és hogyan tárolod el katasztrófahelyzet esetére? Lehet kombinálni az elektronikus és a papír alapon működő, katasztrófahelyzet kezelésére szolgáló jelszótárat, de a papíron, nem IT-rendszerben lerakott biztonsági példányt nem igazán tudod kihagyni.

Ja, ha a portás józsibácsihoz odamegy a cég új vezetője, és utasítást ad a kulcs kiadására Gipsz Jakab részére, akkor józsibácsi oda tudja neki adni, és bekerül a kulcsfelvételi naplóba, hogy ez történt - és bár senki élő ember, aki korábban hozzáférhetett a jelszavak biztonsági példányait tartalmazó borítékokhoz, már nem maradt elérhető közelségben, de a jelszavakat elő lehet szedni, és lehet használni azokat.
Ha mindez csak IT-rendszerben van megoldva, akkor az cummicecin, mert ha senki sem tudja azt a passphrase-t, amit a korábbi jogosult dolgozók, akkor hogy is fognak hozzáférni a jelszavak biztonsági példányaihoz...?

És mi van akkor, ha adott jelszó előszedéséhez nincs senki, aki képes kiszedni a jelszókezelőből az adott jelszót? A titkosítás visszafejtéséhez mire van szükség? A boríték nagy előnye, hogy nem titkosít, de elfedi a jelszót, és ez - a borítékok megfelelő kezelése és tárolása mellett ("titkosítás" helyett ott van a széf, aminek a kinyitásához valamilyen tulajdonság/képesség/eszközzel rendelkezés kell) megszünteti az adott személytől, technikai eszköztől, szoftvertől való függését a jelszóhoz való hozzáférésnek.

"("titkosítás" helyett ott van a széf, aminek a kinyitásához valamilyen tulajdonság/képesség/eszközzel rendelkezés kell) megszünteti az adott személytől, technikai eszköztől, szoftvertől való függését a jelszóhoz való hozzáférésnek."

Es mi van ha elfelejtik/elhagyjak a szef kombinaciojat, kulcsat stb?

Ketten vagyunk, akiknek full hozzáférése van. A titkosítást visszafejtéséhez passphrase kell. Magyarul ha hozzá akarsz férni a jelszavakhoz, akkor két (saját) jelszót kell bepötyögnöd. Az első hozzáférést ad a jelszó kezelőhöz, a második pedig dekódolja a letöltött adatbázist.

Aláírom, hogy szükséges van ilyenünk.
Csak pont olyan kollégák után kellet ilyet megtennünk akik rajtam nagyon komolyan számon kérték, ha valamilyen szolgáltatást nem dokumentáltam le vagy egy jelszót nem borítékoltam.....
Utána pedig amikor elkerültek innen akkor már nekem kellet utánuk dolgozni.

( freeoli v | 2014. 12. 10., sze – 13:47 )

Elég nagy szar lenne.

Persze így is fogóval kell a legelemibb információkat is kihúzni elég sok emberből, mert a jelszó az még nagyon kevés, oké, metaforikusan van kulcsom a szobához, be tudok menni, de ha nem tudom kit kell helyretenni akkor sokat kell dolgozni odabenn.

( willy v | 2014. 12. 10., sze – 14:17 )

Az ilyen jelszóhoz tudás is társul, anélkül nincs értelme ilyen jelszavaknak amit más nem tud.

( KoGa v | 2014. 12. 10., sze – 14:30 )

(x) Nem, mert mindenhova van root jelszóm :)

( junior013 | 2014. 12. 10., sze – 16:13 )

Jelen helyzetben nem, a korábbi helyemen viszont rajtam kívül senkinek nem volt hozzáférése a rendszerekhez (borítékban sem) - bár ha lett volna sem mentek volna vele sokra (problémák okozásán kívül).
És Murphy-hez hűen, ahányszor elmentem nyári szabadságra, másnap beütött valami gebasz :(

( carlcolt | 2014. 12. 10., sze – 17:30 )

Meglep a papiralapu megoldasok (pl. jelszoboritek) gyenge szereplese, pedig szerintem ketsegkivul az az egyik legkoltseghatekonyabb (mar ameddig egy iroda van nem valami multirol beszelunk ahol telephelyek szazkilometerekre egymastol). Raadasul a jelszo uj boritekba tetele eseten lehet kezzel "logot irni", alairogatni, etc., nincs annal tisztabb megoldas szerintem. Azt meg mindenki eszreveszi ha felnyitottak egy boritekot.

Kis forditas amugy az eredmenyekhez:
"Nem, és erre szociális alapú szóbeli megoldásunk van" === "Elofordulhat"
"Fogalmam sincs, nálunk ez mennyire megoldott" === Elofordulhat mert a tieidet se kerte el senki

;)

( necrolite | 2014. 12. 10., sze – 22:14 )

Mindenhol password a jelszó és porbléma eliminálva.

( Fisher v | 2014. 12. 11., cs – 08:47 )

Ki tudok találni olyan szituációt amikor igen, elő. De hogy az be is következzen...

( janoszen v | 2014. 12. 11., cs – 14:22 )

Nalunk redundans munkatarsak vannak.