Dette er definitivt en navnestandard som mange synes å mene noe om. La oss derfor krympe dette inn til å omhandle navnestandard for servere.  Satt på spissen finnes det i hovedsak to strategier. Dette er den enkle og kompliserte strategien.

Den enkle strategien går ut på å navngi serverne sine med et løpenummer for eksempel server001, server002 osv. En annen variant i kategorien enkel, kan være å velge ut et tema fra noe man har kjært. Eksempelvis karakterer i Andeby, for deretter å kalle serverne sine for Donald, Pluto og lignende. Denne varianten bør velges med varsomhet i miljø som eksponerer tjenestenavn direkte mot forretning og kunder som ikke nødvendigvis er like begeistret for temaet.

Strategien som undertegnede definerer som komplisert, baserer seg på en modell som søker å gi tilleggsinformasjon ut i fra serverens navn. Dette kan fungere godt. Et eksempel kan være navnet oslapp001 som indikerer at dette er applikasjonsserver 001 plassert i Oslo.

Det kompliserte elementet i denne strategien er ikke å forklare lokasjon og funksjon, men snarere å finne en balanse i hva som skal forklares. Det er her mange går i fellen. Ofte som et resultat av at det finnes en eller flere ildsjeler som med de beste intensjoner ønsker å forklare mest mulig.

Det er også en risiko for at en komplisert navnestandard mister sin hensikt. Dette kan skje når det ikke tas høyde for miljøendringer. Et eksempel på dette kan være at to datasenter slås sammen og man har benyttet variabler for disse i servernavn.

Det finnes ingen fasit eller mal for en god eller dårlig standard. En ting som passer bra for i en organisasjon kan fort bli en fadese i en annen virksomhet. På generelt grunnlag holder undertegnede en knapp på den enkle varianten med server001. Dette fordi den virker i alle miljø og vil aldri bli utdatert. Øvrig informasjon om selve tjenesten kan lagres separat i en et dokument, katalogtjeneste eller lignende. Noen vil også argumentere for at denne strategien er best i forhold til sikkerhet. Dette fordi man eksponerer ingen opplysninger om serveren ut i fra navn.

Hvis man stiller de samme menneskene spørsmålet om hvordan antivirus oppdateres i virksomheten, kommer det uten unntak helt andre svar. Det er helt andre lover og regler som gjelder for antivirus. Dess oftere antivirus definisjonsfilene oppdateres, jo bedre er det. Det kan i hvert fall tyde slik på svarene man får. Det er ikke uvanlig at antivirusdefinisjonsfiler oppdateres opptil flere ganger per døgn i virksomheten. Dette er for så vidt helt greit, men det er ikke dette punktet som skiller oppdatering av antivirus fra andre typer oppdateringer. En ny antivirusdefinisjon, testes sjelden eller aldri i virksomheter før den slippes i produksjon. Det synes som et utstrakt mål at oppdateringer av antivirus skal ut så raskt som overhode mulig.

Hvorfor er dette et problem?

De aller fleste leverandører av antivirusprogramvare har ved en feiltagelse sluppet oppdateringer som har ført til at legale filer feilaktig identifiseres som virus. Noen ganger går dette bra, fordi virksomhetene ikke rekker å oppdatere sine egne kjernesystemer før den ondartede definisjonsfilen trekkes tilbake fra leverandør. Andre ganger får dette katastrofale følger ved at for eksempel kritiske tjenester og operativsystem stopper i det oppdateringen blir gjeldende i et miljø.

Virksomheter er i dag så redd for et virusutbrudd at antivirustjenestenes definisjonsfiler oppdateres for ofte og ukritisk. I praksis spiller mange russisk rullett med sitt produksjonsmiljø fordi man unnlater å teste definisjoner i forkant av en oppdatering. Ved hjelp av simple rutiner som allerede finnes i forbindelse med oppdateringer av annen programvare, kan risikoen for at antivirus blir virus elimineres.

Det finnes mange måter å håndtere mengden av passord på. Klassikerne er lapper og lagring i tekstfil (et lurt sted). En annen velkjent taktikk for å slippe å notere ned passordet er rett og slett å benytte samme passord overalt. Jeg har en god venn som har den strategien. Det finnes ikke et system som han har tilgang til hvor passordet er noe annet enn melk10 eller en nærliggende variant (Les: melk10mars).

For inntil få år siden hadde undertegnede en passordstrategi som i sin helhet var lagret i den biologiske harddisk. I praksis var det to utfordringer i denne strategien som gjorde at ting ble uoverkommelig.

Det første problemet var lengden på passord. Strategien og systemet var basert på lange passord. Normalt over 15 karakterer, et tall som ikke er helt tilfeldig. I det et passord passerer 15 karakterer i et Windows domene kan ikke domenekontrollerne lagre passordet i det svake LanManager (LM) formatet. En av feilene i systemet er at det finnes påfallende mange tjenester som ikke tillater lange passord. Et eksempel på det er finn.no som har en begrensning 12 karakterer. Det holdt derfor ikke å ha en strategi for å lage lange unike passord, jeg måtte også ha en plan for hvordan jeg skulle håndtere alle restriksjoner.

Utfordring nummer to knyttet seg til metadata. En ting er å huske passord, men hva med brukernavn? Utfordringen ledet faktisk til et problem. Jeg var til stadighet nødt til å få tilsendt innloggingsdetaljer via e-post. Ikke fordi jeg hadde glemt passord, men fordi jeg ikke husket brukernavn. Typisk for situasjonen er at man mater inn alle sine e-post adresser i tur og orden helt til tilbakestillingstjenesten bekrefter at kontoen finnes og nytt passord er sendt. Sammen med dette får man også tak i alle andre detaljer knyttet til kontoen, slik som brukernavn.

Strategien ble som nevnt tidligere forkastet for noen år siden. Godt utstyrt med personlig stolthet, satt det som vanlig langt inne å gjøre en adferdsendring. Dette på tross av at alle utenforstående faktorer tilsa at dette var det eneste riktige å gjøre. Jeg skal derfor ærlig innrømme at skifte av strategi var godt hjulpet av det faktum at jeg ble introdusert for et fantastisk redskap. Verktøyet ble benyttet i en driftsavdeling hos en av mine kunder. Samtlige passord og innloggingsdetaljer ble oppbevart og lagret i ulike databaser ved hjelp av dette verktøyet. Det finnes helt sikkert et utall applikasjoner som gjør nøyaktig samme jobben, men det var første gang jeg så et slikt produkt.

Produktet som jeg sikter til heter KeePass. Det er ikke så ofte man får den følelsen med programvare, men produktet bare stemte et hundre prosent. Det var så tydelig at de som hadde lagd produktet forstod hvilke utfordringer som er knyttet til oppbevaring av brukernavn og passord. Sikkerheten rundt produktet er god. KeePass støtter AES og SHA-256 bit kryptering og alle data lagres i en flat databasefil. Det er heller ikke behov for å installere noe på klienten hvor KeePass skal benyttes. En eksekverbar fil er alt som skal til. KeePass er et gratis sourceforge prosjekt som du finner på http://keepass.info. Applikasjonen utviklet seg raskt til å bli en av mine viktigste og mest kjærkomne verktøy for å overleve i jungelen av passord. Hvor er dine passord?
Kilder:
http://research.microsoft.com/en-us/um/people/cormac/papers/www2007.pdf