Loginoplysninger krydser hele tiden grænserne mellem teams. Platformteamet giver en deploy-nøgle til et produktteam, supporten får administratorlogin til en leverandørs portal, økonomi giver bankens API-token til udviklerne til en integration. Hver overdragelse er rutine, og hver af dem er det sted, hvor loginoplysninger oftest ender i en Slack-tråd for altid.
En sikker måde at overdrage loginoplysninger mellem teams handler mindre om et smart værktøj end om en klar regel for, hvilket af to værktøjer du skal bruge, plus nogle få vaner omkring det. Denne guide beskriver reglen og vanerne: begræns loginoplysningerne, lever dem uden at lægge dem i en besked, udpeg en ejer, og fjern dem til tiden.
Den ene beslutning, der betyder noget: boks eller engangslink
Alt andet følger af, hvordan det modtagende team vil bruge loginoplysningerne.
| Det modtagende team vil | Brug | Hvorfor |
|---|---|---|
| Blive ved med at bruge dem, flere personer, uden slutdato | En fælles boks i jeres adgangskodeadministrator eller secrets manager | Navngiven adgang, tilbagekaldelse og rotation ét sted |
| Bruge dem én gang, eller én person har brug for dem kortvarigt | Et hemmeligt engangslink | Beskeden indeholder kun et link, kopien destrueres ved første åbning |
| Køre dem fra kode eller CI | En secrets manager med maskinidentiteter | Intet menneske ser nogensinde værdien |
Boksen er det autoritative system. Hvis loginoplysningerne skal leve videre efter overdragelsen, hører de hjemme i en fælles boks, som det modtagende team ejer, med medlemmer tilføjet ved navn. De fleste adgangskodeadministratorer til virksomheder og værktøjer som Vault eller AWS Secrets Manager klarer det godt.
Engangslinket er til selve overførslen, når en boks ikke passer: modtageren er ikke i din boks, loginoplysningerne er midlertidige, eller du skal give en værdi til én person lige nu. Hemmeligheden krypteres i din browser, den gemte kopi destrueres, første gang linket åbnes, og selve linket holder op med at virke, når det udløber, hvis ingen åbner det. Hemmelige links og adgangskodeadministratorer gennemgår grænsetilfældene.
Aldrig e-mail, chat, delte dokumenter eller sager. De gemmer alle kopier, de synkroniserer alle til enheder, du ikke styrer, og de kan alle gennemsøges af den næste, der kommer ind på kontoen.
Begræns loginoplysningerne, før de flyttes
En god kanal kan ikke reparere loginoplysninger med for mange rettigheder.
- Opret en separat konto til det modtagende team eller den modtagende person i stedet for at låne en konto, der er knyttet til en bestemt medarbejder. Delte identiteter kan ikke revideres og kan ikke fjernes rent.
- Giv de rettigheder, opgaven kræver. Et team, der læser rapporter, har ikke brug for skriveadgang. Et team, der deployer, har ikke brug for adgang til fakturering.
- Roter først, hvis værdien har været sendt rundt. Hvis den eksisterende nøgle er blevet indsat forskellige steder, så udsted en ny til overdragelsen i stedet for at sprede den gamle endnu mere.
- Gennemsøg materialet omkring opgaven. Sager, runbooks, eksempelkonfigurationer og scripts, der hører til opgaven, indeholder ofte netop de loginoplysninger, du er ved at overdrage. Fjern dem før overdragelsen, ellers er overdragelsen den mindste del af eksponeringen.
Selve overdragelsen
- Bekræft modtageren via en kanal, din organisation allerede har tillid til: sagen, en kendt leder, et videoopkald. Adresser, der ligner de rigtige, og navne, der er udfyldt automatisk, er den sædvanlige måde, en hemmelighed havner det forkerte sted.
- Lever via det valgte værktøj. Boks: tilføj personen til den fælles samling. Link: indsæt værdien i værktøjet til hemmelige engangslinks, sæt udløbet til det reelle tidsrum (en time, hvis modtageren venter, et døgn på tværs af tidszoner), sæt grænsen for visninger til én, tilføj en adgangssætning med en Pro-konto til alt følsomt, og send linket.
- Send konteksten for sig. Brugernavnet, værten og det, som loginoplysningerne giver adgang til, sendes i en almindelig besked, aldrig sammen med linket. En enkelt lækket besked må aldrig indeholde begge halvdele.
- Registrer overdragelsen i jeres autoritative system uden hemmeligheden: modtager, formål, system, ejer, slutdato.
- Bed om bekræftelse af adgangen, ikke af værdien. ”Kan du logge ind?” er det rigtige spørgsmål. ”Send mig nøglen tilbage, så jeg kan tjekke den” er ikke.
For et team, der gør det ofte, laver LinkPilots Slack-app en indsat adgangskode om til et engangslink direkte i kanalen, så vanen ikke afhænger af, at alle husker at åbne et andet værktøj.
Udpeg en ejer, og gennemgå efter en fast plan
Loginoplysninger uden en ejer bliver aldrig skiftet eller fjernet. Det modtagende team skal udpege én person, der står til ansvar for værdien: hvem der har den, hvem der ellers har brug for den, og hvornår den forsvinder.
- Mindst mulige rettigheder efter rolle, med roller eller grupper, hvor det gør administrationen enklere, så én fratrædelse ikke betyder én nulstilling pr. system.
- Flerfaktorgodkendelse på boksen, fordi boksen nu er det, der er værd at angribe.
- En fast rytme for gennemgang, der passer til følsomheden: hvert kvartal for de fleste delte loginoplysninger, ved hver ændring i teamet for adgang til produktion.
- Revider overdragelserne. En boks viser, hvem der har tilgået hvad. En LinkPilot-konto på Pro viser en revisionslog for hvert hemmeligt link, så du kan se, hvornår en engangsvisning skete, og matche den med modtagerens bekræftelse.
Udløb, rotation og eksponering
Beslut, hvornår loginoplysningernes levetid slutter, før den begynder.
- Midlertidig adgang slutter på den aftalte dato. Fjern kontoen eller medlemskabet af boksen, og tilbagekald ethvert engangslink, der aldrig blev åbnet.
- Rotation følger risikoen, ikke kun kalenderen: efter en fratrædelse, efter et leverandørskifte, efter enhver mistanke om eksponering og efter en fast plan for alt, der lever længe.
- Et mistænkt læk er et læk, indtil det modsatte er bevist. Roter i det system, der accepterer loginoplysningerne, giv ejeren besked, og opdater de job og tjenester, der var afhængige af den gamle værdi. Guiden til API-nøgler har en tjekliste til rotation, der gælder for de fleste typer loginoplysninger.
To værktøjer, én regel for at vælge mellem dem og en ejer for hver værdi. Det er hele systemet, og det holder til langt flere overdragelser end et politikdokument, som folk holder op med at læse.