Passordmanager for bedrift – fra valg til avslutning

En passordmanager løser ikke alle innloggingsproblemer. Den kan derimot gjøre unike, tilfeldige passord praktiske, gi kontrollert deling og la virksomheten fjerne én bruker uten å bytte alt for alle.

Verdien kommer først når løsningen er bedriftsstyrt. Et lappeteppe av private hvelv, nettlesere, regneark og chatmeldinger kan ha gode enkeltpassord og likevel mangle eier, avslutning og gjenoppretting.

NISTs gjeldende passordstandard krever at tjenester tillater passordmanagere og autofyll. For virksomheten er spørsmålet derfor hvordan verktøyet styres og forvaltes, ikke om ansatte skal huske alle passord selv.

Hva bør inn i passordmanageren?

En vanlig passordmanager er ikke automatisk riktig lager for private SSH-nøkler, databasehemmeligheter i produksjon eller CI/CD-tokens. Maskiner trenger ofte en løsning med kortlivede legitimasjoner, automatisk rotasjon og tilgang uten at en ansatt kopierer hemmeligheten.

Start med styringsmodellen

Bestem før leverandørvalg:

• hvem som er tjenesteeier og sikkerhetsansvarlig
• hvem som kan opprette administratorer og nødkontoer
• om hvelv er personlige, teamstyrte eller begge deler
• hvilke grupper som følger rolle og avdeling
• om private enheter og private e-postadresser er tillatt
• hvordan innlogging, MFA og gjenoppretting skal fungere
• hvem som kan eksportere hvilke data
• hvordan hendelser, avslutning og leverandørbytte håndteres
• hvilke typer hemmeligheter som skal ligge et annet sted

Uten disse valgene blir «sentral styring» ofte bare én administrator som kan gjøre alt.

Kravmatrise for anskaffelsen

1. Kryptografisk modell

Ikke stopp ved algoritmenavnet på forsiden. Be leverandøren forklare:

• hvor kryptering og dekryptering skjer
• hvilke data leverandøren kan lese
• hvordan hovedpassord eller passkey utleder og beskytter nøkler
• hvordan forsøk mot stjålet hvelv gjøres dyrere
• hvilke metadata som er synlige for tjenesten
• hvordan delte elementer krypteres og får ny tilgang
• hvordan nøkler roteres og gamle data migreres
• hva en kompromittert server, klient eller administrator kan gjøre

«Zero knowledge» er en arkitekturpåstand som må beskrives, ikke et sertifikat i seg selv. Åpen kildekode, ekstern revisjon og feilfinningsprogram kan gi innsikt, men ingen av delene garanterer sikker drift.

2. Innlogging og gjenoppretting

Krev eller vurder:

• phishing-resistent MFA eller passkey for brukere
• enhetsbundet sikkerhetsnøkkel for toppadministratorer
• håndheving, ikke bare frivillig MFA
• varsel ved ny enhet, faktor og gjenoppretting
• kontrollerte nødkontoer
• minst to ansvarlige uten delt innlogging
• dokumentert prosess når hovedpassord og enhet er tapt
• tilbakekalling av økter og kjente enheter

En administrativ gjenopprettingsfunksjon kan hindre permanent tap, men gir også en høyt privilegert vei inn. Avklar nøyaktig hva administratoren kan gjenopprette og hvilke varsler og godkjenninger som utløses.

3. Brukere, roller og grupper

Se etter:

• navngitte brukere og minst mulig administratorrett
• grupper som kan knyttes til avdeling eller rolle
• separat rett til å administrere brukere, policy, fakturering og sikkerhet
• livssyklusstyring via identitetsplattform der virksomheten trenger det
• sperring som også stopper synkronisering og aktive økter
• synlig eier for hvert teamhvelv
• gjest eller ekstern rolle med tydelige begrensninger

SSO kan forenkle livssyklusen, men gjør identitetsplattformen til en kritisk avhengighet. Test nødkonto og utfall før SSO håndheves.

4. Deling uten skjulte kopier

Test om løsningen:

• deler selve hvelvselementet fremfor en tekstkopi
• kan begrense lesing, redigering, deling og eksport
• viser hvem som har tilgang nå
• varsler ved ny eller bredere deling
• kan trekke tilbake én person uten å flytte alt
• håndterer eksterne mottakere med utløp
• gjør det tydelig at mottakeren kan ha sett eller kopiert hemmeligheten

«Skjul passord» hindrer ikke nødvendigvis at brukeren henter det via nettleser, utviklerverktøy, eksport eller måltjenesten. Ikke bruk funksjonen som bevis på at mottakeren aldri kunne kjenne passordet.

5. Logger og varsler

Avklar hvilke hendelser som faktisk finnes:

• innlogging, ny enhet og mislykket MFA
• opprettet, endret, slettet og flyttet element
• delt hvelv og endret gruppe
• eksport og administrativ gjenoppretting
• ny administrator og endret policy
• sperring og tilbakekalling av økt

Kontroller lagringstid, eksportformat, tidssone, tilgang og personvern. En logg som bare kan leses i leverandørens grensesnitt etter hendelsen, kan være utilstrekkelig for virksomhetens behov.

6. Plattform og tilgjengelighet

Pilotér de faktiske kombinasjonene av nettleser, mobil, operativsystem og apper. Test:

• autofyll på riktig domene og i underdomener
• flere kontoer på samme tjeneste
• skjermleser og tastaturnavigasjon
• privat vindu, mobilapp og delt arbeidsstasjon
• offline-behov og synkroniseringskonflikt
• utenlandsreise og ny enhet
• passkeys og TOTP hvis de skal lagres i samme løsning

En nettlesers innebygde passordlager kan være et forsvarlig valg i et styrt miljø. Spørsmålet er ikke bare «nettleser eller egen app», men om virksomheten kan håndheve konto, enhet, deling, eksport og avslutning. Velg én godkjent kilde per arbeidsflyt og unngå usynlig dobbeltlagring.

7. Portabilitet og avvikling

Be om et testmiljø og utfør en reell eksport før kjøp. Kontroller:

• format og dokumentasjon
• mapper, eierskap og deling
• egendefinerte felt og notater
• TOTP-frø, vedlegg og passkeys
• historikk og slettede elementer
• logger og administrativ konfigurasjon
• hvordan eksportfilen beskyttes og slettes
• frist og prosess for sletting hos leverandøren

En CSV-eksport kan inneholde alle hemmeligheter i klartekst og likevel mangle viktige data. Portabilitet betyr at virksomheten har testet flytting, ikke bare at det finnes en eksportknapp.

Sammenlign løsninger med vektede krav

Pris per bruker er lite nyttig hvis eksport, logger, SSO eller gjenoppretting krever en annen plan. Be om totalpris for faktiske krav, binding, oppsigelse og datatilgang etter opphør.

Migrer uten å lage en ny lekkasje

1. Kartlegg kildene

Finn nettlesere, private managere, telefoner, regneark, dokumenter, chat, wiki, kode og gamle leverandørhvelv. Ikke be ansatte sende passordene til prosjektlederen.

2. Bygg målstrukturen

Opprett grupper og hvelv etter ansvar, ikke tilfeldig avdeling hvis arbeidsflyten går på tvers. Sett eier og minst to kontrollerte administratorer.

3. Sikre plattformen først

Håndhev sterk MFA, kontroller gjenoppretting og test nødkonto før de første produksjonspassordene importeres.

4. Importer kontrollert

Eksporter bare på en styrt, oppdatert enhet. Frakoble eller begrens synkronisering av klartekstfilen, importer, sammenlign antall og stikkprøver, og slett eksporten fra enhet, papirkurv, skylagring og prosjektmappe etter bekreftet migrering.

5. Rydd og roter etter risiko

Finn duplikater, svake og gjenbrukte passord, manglende eier og gamle kontoer. Roter først delte, eksponerte og kritiske passord. Et massebytte uten eiere eller test kan låse systemer ute.

6. Stopp den gamle arbeidsflyten

Fjern gamle nettleserutvidelser og private delingskanaler etter en avtalt overgang. Gi brukerne en tydelig måte å få hjelp og melde feil på.

Daglig bruk

• la manageren generere unike passord
• kontroller hele domenet før autofyll og innlogging
• bruk teamhvelv fremfor å sende tekstkopier
• registrer eier og formål for delte elementer
• legg aldri hovedpassord eller gjenopprettingskode i samme hvelv som eneste kopi
• rapporter uventet MFA, ny enhet eller endret element raskt
• fjern gamle kontoer i måltjenesten, ikke bare fra hvelvet
• bruk passkey når tjenesten og virksomhetens modell støtter det

Den detaljerte passordpolicyen for e-post og kontoer forklarer lengde, lekkede passord og når bytte er nødvendig.

Når en ansatt slutter

1. Sperr brukeren i identitetsplattform og passordmanager til avtalt tidspunkt.
2. Tilbakekall økter, enheter og delingslenker.
3. Overfør eierskap til personlige jobbelementer som virksomheten trenger.
4. Fjern brukerens grupper, teamhvelv og gjestetilganger.
5. Finn hvilke hemmeligheter brukeren kunne se eller eksportere.
6. Roter delte og kritiske hemmeligheter etter risiko.
7. Kontroller eksporthendelser og nylige administrative endringer.
8. Fjern gamle kontoer og tilgang i måltjenestene.
9. Dokumenter gjennomført kontroll og gjenstående avvik.

Å slette personen fra passordmanageren bytter ikke passordet hos leverandøren og tilbakekaller ikke alltid en allerede kopiert hemmelighet.

Kvartalskontroll

Hva tilbyr Vymo?

Vymos publiserte domene-, e-post- og webhotellprodukter inkluderer ikke en bedrifts-passordmanager, SSO, hemmelighetslager eller administrasjon av kundens passordhvelv. Vymo skal heller ikke motta passord eller gjenopprettingskoder i kontaktskjema eller vanlig e-post.

Bruk kravmatrisen til å velge en egen leverandør. Hvis spørsmålet gjelder hvilke Vymo-kontoer og roller virksomheten faktisk trenger, send antall brukere og ønsket ansvarsdeling – uten hemmeligheter eller eksportfiler.