Sådan sender du et midlertidigt databaselogin sikkert til en konsulent

En konsulent, der skal rette en import, finjustere en forespørgsel eller migrere en tabel, har som regel brug for et databaselogin til det. Risikoen er sjældent konsulenten. Den er selve loginet: oprettet i hast, bredere end opgaven, indsat i en e-mail og stadig aktivt seks måneder efter, at fakturaen er betalt.

Løsningen er en kort rutine. Afgør, om der overhovedet er brug for direkte adgang, opret en bruger, der er afgrænset og allerede har en slutdato, send adgangskoden via et hemmeligt engangslink i stedet for en besked, der gemmer kopier, lås netværksadgangen ned, og luk kontoen, når arbejdet er færdigt. Denne guide gennemgår hvert trin med de præcise kommandoer, hvor de hjælper.

Har konsulenten brug for direkte adgang til databasen?

Start med opgaven, ikke med anmodningen. ”Ret importen” kan betyde, at én tabel skal læses, eller at der skal skriveadgang til halvdelen af skemaet. Spørg efter handlingen, miljøet og de tabeller, det drejer sig om, og find derefter en billigere måde at give adgangen på.

• En staging-database med en nylig, renset kopi dækker det meste fejlfindings- og migreringsarbejde, uden at rigtige kundedata bliver eksponeret.
• Et applikations- eller administrations-API er ofte nok, når konsulenten skal ændre data og ikke skemaet.
• En læsereplika giver ren analyse et sted at køre uden at røre den primære database.

Passer ingen af dem, og kan adgang til produktion ikke undgås, så skriv en kort note om, hvorfor. Den note bliver begrundelsen, når nogen senere gennemgår adgangen.

Opret en bruger, der er afgrænset og allerede udløber

Udlever aldrig et delt login eller en medarbejders loginoplysninger. En dedikeret bruger er det, der gør, at du kan se, hvad konsulenten har gjort, begrænse, hvad konsulenten kan nå, og fjerne adgangen uden at påvirke andre. Sæt udløbet på brugeren, når du opretter den, så adgangen slutter, selv hvis du glemmer det.

I PostgreSQL ser en bruger, der kun kan læse to tabeller og holder op med at virke på en fast dato, sådan ud:

CREATE ROLE contractor_jo LOGIN PASSWORD 'generated-elsewhere'
  VALID UNTIL '2026-11-08 18:00+00';
GRANT CONNECT ON DATABASE app TO contractor_jo;
GRANT USAGE ON SCHEMA public TO contractor_jo;
GRANT SELECT ON orders, order_items TO contractor_jo;

MySQL har CREATE USER ... PASSWORD EXPIRE INTERVAL 14 DAY, og administrerede tjenester som RDS, Cloud SQL og Supabase lader dig gøre det samme fra deres konsoller eller med kortlivede IAM-baserede tokens. Brug det, din platform understøtter, og generer adgangskoden med en adgangskodeadministrator i stedet for at finde på en selv.

Giv det mindste sæt tilladelser, der løser den aftalte opgave. Til fejlfinding betyder det SELECT på bestemte tabeller. Til en migrering betyder det skriveadgang til de objekter, der skal ændres, og intet andet. Owner- og superuser-roller er aldrig det rigtige svar for en midlertidig konto.

Sådan sender du et midlertidigt databaselogin til en konsulent

Adgangskoden er den eneste del af overdragelsen, der skal holdes hemmelig. Vært, port, databasenavn og brugernavn er nyttige for en angriber, men ikke nok i sig selv, så de kan sendes i en almindelig besked. Hold de to dele adskilt.

1. Bekræft modtagerens identitet gennem en kanal, du allerede stoler på, for eksempel e-mailtråden om kontrakten eller et opkald. Adresser, der ligner den rigtige, er en almindelig måde, hvorpå loginoplysninger havner i den forkerte indbakke.
2. Opret et hemmeligt engangslink, der kun indeholder adgangskoden. Med LinkPilot krypteres teksten i din browser, før den gemmes, den gemte kopi destrueres, første gang linket åbnes, og du kan vælge et udløb på en time, 24 timer eller syv dage. Pro-konti kan sætte et selvvalgt udløb, tilføje en adgangssætning og se en revisionslog over, hvornår linket blev åbnet.
3. Send linket i den almindelige tråd med en kort note om, hvad det er til, og hvornår det udløber. Skriv ikke brugernavnet i samme besked som linket.
4. Send forbindelsesoplysningerne for sig: vært, port, database, brugernavn, og om TLS er påkrævet. En ekstra e-mail eller en kommentar i en ticket er fint, for intet i den er hemmeligt i sig selv.
5. Giv en eventuel adgangssætning videre via en anden kanal, for eksempel en sms eller et opkald.
6. Bed konsulenten bekræfte, at linket kunne åbnes. Hvis linket melder, at det allerede er vist, og konsulenten ikke har åbnet det, så betragt adgangskoden som afsløret, og skift den.

En adgangskodeadministrators delingsfunktion er et fornuftigt alternativ, når konsulenten allerede er med i jeres boks. Til en enkelt opgave undgår et engangslink, at der skal oprettes en konto bare for at overdrage én værdi. Guiden Hemmelige links eller adgangskodeadministratorer gennemgår, hvornår hver af dem passer.

Lås forbindelsen ned

En velafgrænset bruger på en åben port er stadig et problem. Tre tiltag lukker det meste af hullet.

• Kræv TLS på forbindelsen, og bed konsulenten sætte sslmode=require eller det tilsvarende i sit program. Mange programmer falder stille tilbage til klartekst, hvis du ikke insisterer.
• Begræns, hvor der forbindes fra, med en IP-tilladelsesliste, en VPN eller en bastion host. At tillade konsulentens adresse, så længe arbejdet varer, er hurtigt at sætte op og hurtigt at fjerne.
• Del kun det, opgaven kræver. Konsulenten har ikke brug for diagrammet over det interne netværk, de andre databaser på serveren eller URL'en til administrationskonsollen.

Tilbyder din platform kortlivede IAM-tokens i stedet for faste adgangskoder, er det som regel det bedste valg, og så forsvinder overdragelsen af adgangskoden helt.

Hold øje med kontoen, og luk den

Slå logning af godkendelse og forespørgsler til for den nye bruger, før arbejdet starter, så du kan sammenligne, hvad der skete, med det, der var aftalt. Login på skæve tidspunkter eller forespørgsler mod tabeller, der ikke har med opgaven at gøre, er værd at spørge ind til, ikke at anklage nogen for.

Når opgaven slutter, eller omfanget ændrer sig, så gør fire ting samme dag:

1. Slet eller deaktiver brugeren, og bekræft, at den ikke længere kan forbinde.
2. Fjern den netværkstilladelse, du har tilføjet til konsulenten.
3. Skift alle hemmeligheder, der fulgte med loginet, for eksempel en applikationsadgangskode, der stod i samme ticket.
4. Registrer overdragelsen: hvem der havde adgang, til hvad, fra hvornår til hvornår, og hvorfor. Gem registreringen, ikke adgangskoden.

Et midlertidigt login, der er afgrænset, udløber, leveres én gang og lukkes til tiden, er ikke en sikkerhedsmæssig undtagelse. Det er simpelthen sådan, adgang for konsulenter bør fungere.

Læs også

• Sådan deler du API-nøgler sikkert
• Sikker linkdeling for udviklere
• Sådan virker hemmelige engangslinks
• Udløbende links: hemmeligheden destrueres, den bliver ikke bare viderestillet