KeePass is encrypted en werkt prima naar mijn mening. :)

Gewoon Twee-factor authenticatie toepassen?

Keepass?
Deze gebruik ik zelf zakelijk en prive.
Password generator en ook een auto-complete zit erin...

Inderdaad niet veilig overal zelfde accounts voor te gebruiken.

Je moet er wel rekening mee houden dat het gebruik van Keepass wel inhoud dat je dus al je passworden met een code versleuteld. Als deze code bekend raakt kun je dus alles wat er door keepass beveiligd is benaderen.

Dus dat ene password moet wel erg veilig zijn !

Er is mi. nooit zoveel verschil tussen 1 id. + pw gebruiken voor alle systemen of alle systemen laten verschillen en deze dan opslaan in KP en dat dan weer beveiligen door 1 password. en daar deze KeePass door meerdere gebruikers benaderd moet worden is dit dus een gedeeld pw. En hoe deel je op een veilige manier een password .....

enterprise oplossingen zijn er ook. Denk aan bijvoorbeeld Enterprise Password Vault, Secret Server of Liebersoft.

Ik werk al een jaar met Safewallet, is een betaalde variant met eigen sync server tegenwoordig.
Browser Plug-in voor site passworden binnen Firefox, Chrome, IE....
Apple, Windows, Android, Password Gen, Security Center (geeft aan welke Passwords te zwak zijn of dubbel zijn)..

Op dit moment gratis te verkrijgen op safewallet.com (nieuwe versie is uitgebracht)

Niet alleen Keepass is password management, er zijn een heel scala aan manieren op passwords te managen.

Daarnaast zijn er ook allerlei authenticatie en authorisatie mechanismen als LDAP of TACACS etc, waar je ook weer password policies op kunt instellen (sterkte van het ww en houdbaarheid van het ww etc).

Overal een ander uid en ww die vervolgens nooit veranderd vs op meerdere systemen een uid en ww die wel veranderd...mooie afweging.

Of tokens, ook mooi.

En dat is te doen voor een enterprice omgeving?
ik spreek dan over een IT afdeling van 10 man, 15 locaties, veel apparatuur.
Ik ken keepass maar dan heb je 1 database die versleuteld is met 1 wachtwoord een keyfile en mogelijk een gebruikersaccount.

Oh oh wat een suggesties. Keepass voor iedereen en al je switches! Knap hoor.

Eigenlijk wil je dat iedere beheerder een eigen toegang heeft. Dit geeft problemen want om nou iedere keer dat er iemand bijkomt of weggaat(!) alle switchconfigs te vernieuwen, dat schiet niet op. Ook niet als je configs backuppen en restoren volledig geautomatiseerd hebt, al verzacht dat de pijn. Valt me een beetje tegen dat je school kennelijk helemaal niets over dit soort dingen gezegd heeft, maar sleutelwoorden die je zoekt zijn bijvoorbeeld "RADIUS" en "TACACS+". De meeste managed netwerkapparatuur praat daar wel mee. Hoe je dan single points of failure voorkomt... huiswerk.

Wat je ook wel ziet is dat er met ssh sleutels gewerkt wordt, maar inrichten is daar ook weer tricky. Je kan kijken naar zgn. "bastion hosts" (je wil er minstens twee) waar iedereen verbinding mee maakt en van daaruit pas de switches op kan. Hoe je dan de verbinding bastion<->switches netjes afdekt ligt weer sterk aan hoe erg je alles wil dichttimmeren. Dit is altijd tricky want als er iets misgaat en je kan niet meer bij de management interface van je eigen infrastructuur... maar alweer: huiswerk. Hint: Kijk (ook) naar SNMPv3.

Verder heb je nog SSO dingen als kerberos of die redmondse bastaardafgeleide. Of je dat wil voor je infrastructuur moet je ook maar uitzoeken. En ik hoop voor je dat je netwerkmeuk niet "web managed" is want dan kan je eigenlijk niks verbeteren.

Lijkt me wel voldoende ideen om een stage mee vol te maken.

Yep, en dat is dan gelijk het probleem. Je kunt helaas geen wachtwoorden delen met collega's met dat programma. Het is wel een prima tool voor jezelf. Ik vind vooral de auto-type feature erg handig.

V.w.b. netwerk apparatuur kun je heel veel doen met een centrale Radius of TACACS. Daar is het zeker niet nodig om gedeelde accounts te hebben. Gedeelde accounts komt de audittrail (wie heeft wat gedaan en wanneer) zeker niet ten goede.

Je ontkomt er echter niet aan om enkele accounts te delen. Meestal worden dergelijke accounts gebruikt voor geautomatiseerde scripts. Om problemen daarmee op te kunnen lossen zal het hele team de login gegevens moeten weten.

Ik gooi ook nog even het volgende in de groep: Wat vinden jullie in dit verband van Roboform?

Mee eens maar in de praktijk komt 't regelmatig voor.

Ik weet er alles van, ik ben bezig met een security audit voor mijn afstudeer stage. Laat ik kort zeggen dat ik zeer triest ben over de staat van beveiliging. Er is altijd gedacht, het werkt, afblijven.

Ik ga morgen eens een labomgeving opstellen met Radius, dat is inderdaad wel een goede.
Kijken in hoe veren ik dat kan intregreren als een advies.

In ieder geval alvast bedankt voor de adviezen.

mits je mysql/php goed dicht zet is teampass ook een mooie tool voor de it-afdeling
http://www.teampass.net/
je kunt rollen definieren, zodat bijvoorbeeld niet iedereen bij alle serviceaccounts kan.

"Is het verstandig om alle apparatuur te voorzien van andere login. Zo ja, hoe kan dit het beste worden geregeld? Van alle apparatuur logingegevens onthouden is namelijk vrijwel onmogelijk."

Indien er een goede audit trail is, goede controls voor password complexiteit, en een goed beleid om regelmatig passwords te wijzigen, dan is centralized password management op zich geen probleem (i.e. middels een radius server).

Ik heb geen idee hoe grootschalig je omgeving is, maar denk ook aan de kosten die het met zich meebrengt om alle apparatuur te voorzien van verschillende login/password combinaties. Naast de vraag of het praktisch is. Ik zou dan liever gebruik maken van een one time password middels een token.

Hierbij hoeven medewerkers niet allemaal verschillende passwords te onthouden -en- je hebt niets aan een onderschept password indien je geen token hebt.

Niet mee eens. Het hoeft voor een beheerorganizatie niet uit te maken, mits het een subset van gebruikers is die formeel beheer recht hebben gekregen. Eerst aanloggen met een eigen indivudeel account, vervolgens rechten verhogen middels SU of Enable achtige tools. Met Radius en TACACS zou dit geen probleem hoeven zijn.

Waar ik echter geen commentaar op heb gezien is de suggestie om 2-factor te gebruiken. Idealiter wil je kunnen zien wie wat wanneer gedaan heeft, dit is uitstekend op te lossen met token authentication.

Nee, token authenticatie is alleen een versterkte authenticatie. Je weet wat zekerder wie op welk moment ingelogd was.
Je weet dan nog niet wat de op dat moment ingelogde personen (ja, meervoud, dat kan) gedaan hebben.
En token authenticatie an sich zegt ook nog niks over meer of minder beperkte rechten. Het kan een token authenticatie zijn die meteen naar een verder niet gelogd maximaal privilege niveau gaat.

Dat zijn de andere twee A's in "AAA" . Authenticatie, Authorisatie, Accounting .
Authorisatie laat iemand die inlogt bepaalde rechten wel of niet hebben, en accounting is het vastleggen van welke acties die ingelogde persoon uitvoert.

TACACS+ als protocol geeft technisch de beste mogelijkheden om ook die andere twee A's te controleren.
Je kunt elk commando laten loggen door de tacacs server, en ook elk commando laten authoriseren.
Zo kun je mensen beperkte configuratie access geven, bijvoorbeeld wel interfaces configureren maar geen routing protocollen. Of andere nuttige troubleshooting tools , die typisch wel priviliged access vereisen maar geen configuratie wijzigingen.
In een wat grotere organisatie met 1e/2e/3e lijns beheer is dat erg wenselijk.

Radius heeft op dat vlak wat minder mogelijkheden.
(Maar de stap van 'lokale accounts op een device gedeeld door het hele team' naar 'individuele accounts beheerd op een radius server is al een enorme verbetering. In in veel organisaties goed genoeg ).

('su' -- het unix commando wordt klein geschreven. "Substitute user" volgens de manpage hier.)

Je wil nog steeds die mogelijkheid van gebruikersrechten veranderen alsook ophogen beperken tot die groep, en een enkel wachtwoord is nog steeds vervelend om voor heel die groep te moeten veranderen als er iemand uit de groep verdwijnt.

Op unices kan je bijvoorbeeld su limiteren tot accounts in de wheel group (echte unix, linux heeft dat verprutst omwille van iemand zijn ideologie; lees de laatste paragraaf in info su. je kan het overigens wel weer aanzetten via PAM) en dan root maar gewoon wachtwoordloos te laten. Zeker als de consoletoegang netjes is afgesloten (slot op de deur, sleutel netjes beheerd) kan dat, en op het moment dat je die console echt nodig hebt wil je niet moeten hannessen met ingewikkelde rootwachtwoorden.

Maar dan moeten je policies en sleutelbeheer wel in orde zijn natuurlijk.

Tokens zijn een ingewikkeld soort wachtwoordalternatief waar je extra complexiteit in je backend voor nodig hebt, niet iets dat op zichzelf het probleem van een gedeeld beheersaccount oplost. Je moet nog steeds iedereen zijn eigen inlogaccount geven, anders valt er niet bij te houden wie er onder dat ene beheersaccount nou wat gedaan heeft. Dus je argumentatie is een geval van causatie met correlatie verwarren.

Het is verder een leuke suggestie mits al je switches ook met die tokens praten, natuurlijk. We hebben het hier (nouja, dat was de vraag, niet iedereen heeft dat ook gelezen) over netwerkapparatuur, en die doen dat niet. Of je moet dat via, oh hee, RADIUS of TACACS+ inbouwen. En die waren al genoemd.