Teste tilkoblingen og sikkerhet

En datakilde holder på nøkkelen til en ekte database — ofte en i produksjon. Denne siden dekker begge sidene av det ansvaret: hvordan du bekrefter at tilkoblingen virker før du lagrer, og hva plattformen gjør (og nekter å gjøre) med legitimasjonen etterpå.

#Teste tilkoblingen

Knappen Test tilkoblingen finnes i opprettelsesskjemaet og i modalen Rediger tilkobling, ved siden av lagrehandlingene:

1. Fyll ut tilkoblingsfeltene.
2. Trykk på Test tilkoblingen. Knappen skifter til Tester….
3. Plattformen åpner en ekte tilkobling til databasen, kjører en harmløs kontrollspørring, og lukker tilkoblingen. Ingenting skrives eller endres.
4. Ved suksess vises bekreftelsen «Tilkoblingen er OK.»; ved feil vises et varsel med meldingen databasemotoren ga tilbake — ordrett, fordi det er den som sier hva du må rette.

To spesialtilfeller:

• Ved redigering med tomt passord bruker testen det lagrede passordet — det vil si at den tester tilkoblingen slik den blir etter at du lagrer.
• I en SQLite som ikke er opprettet ennå finnes ingen knapp — filen finnes ikke, og en test der kunne bare lyve. Den dukker opp etter at du har lagret.

#Testen feilet — hva nå?

Meldingen kommer fra motoren, og varierer derfor; mønstrene gjør det ikke:

Symptom	Hva du skal sjekke
Det tar tid og ender i tidsavbrudd	Er Host og Port riktige? Godtar serveren tilkoblinger fra maskinen plattformen kjører på (brannmur, nett)?
Autentiseringsfeil / login failed	Bruker og Passord. I noen motorer også om den kontoen får koble seg til fra en annen maskin.
Ukjent database	Har feltet Database det nøyaktige navnet på basen inne i serveren?
SSL/TLS-feil på en SQL Server 2008/2012	Slå på Eldre TLS (gammel SQL Server) — det er akkurat det den er til for.
Sertifikatfeil i andre motorer	Bruk SSL / Encrypt alt etter hva serveren krever; på interne servere med eget sertifikat, Trust server certificate.
Oracle finner ikke tjenesten	Følger Connect string formen host:port/service_name? Er service_name navnet på tjenesten, ikke SID-en?

#Legitimasjon som aldri kommer tilbake til skjermen

Passordet til en datakilde skrives bare én gang: det går inn i skjemaet, og fra da av viser plattformen det aldri igjen — til ingen, aldri, ikke engang til den som skrev det.

• Når du åpner Rediger tilkobling, kommer alle feltene utfylt bortsett fra passordet. Feltet heter Passord (tomt = behold): står det tomt, beholdes det nåværende; fylles det ut, erstattes det.
• Det finnes ingen skjerm, ingen eksport og ingen tillatelse som gir passordet tilbake i klartekst. Mister du det, setter du et nytt på databaseserveren og skriver det nye her.
• I hvile ligger legitimasjonen kryptert — som skjemaene selv sier: «Alt krypteres i hvile.»

#Og når appen er på reise?

Når du eksporterer en app (Innstillinger → Eksporter app), velger du hva som skal skje med hemmelighetene:

• Uten hemmeligheter (anbefalt) — «Tilkoblingene til datakildene og hemmelighetene følger med tomme». Den som importerer i en annen installasjon fyller ut legitimasjonen på nytt — passordene reiser ikke.
• Med hemmeligheter, beskyttet av en passfrase — verdiene følger med kryptert med en passfrase du velger, og som blir etterspurt ved importen. «Uten passfrasen er hemmelighetene i pakken ugjenopprettelige.»

#Hvem får gjøre hva

Handling	Nødvendig profil i appen
Se listen over datakilder og bruke appen	Developer
Opprette, redigere, gi nytt navn til og slette datakilder	Administrator
SQL-konsoll, opprette/endre objekter (DDL)	Administrator

Det er derfor en developer kanskje ikke ser knappen Legg til datakilde eller menyen Rediger tilkobling — det er ikke en feil, det er profilen.

#Alt blir registrert

• Appens historikk — hver opprettelse, endring, navnebytte og sletting av en datakilde havner i endringshistorikken («Datakilde "crm" opprettet», «Datakilde "crm" endret», …), med forfatter og dato.
• Plattformens revisjon — de samme operasjonene blir liggende i revisjonssporet i Radar, med målet Datakilde.
• SQL-konsollen — når du kjører SQL som skriver eller endrer (en UPDATE, en DROP…), revideres hendelsen med typen operasjon og et fingeravtrykk av spørringen — uten selve SQL-teksten, slik at sensitive data som skrives i konsollen ikke havner i loggen.
• Radar → Tilstand — seksjonen Tilkoblinger til databaser viser tilkoblingene som er satt opp i alle appene. Og med en bevisst forsiktighet: «Denne siden kobler seg aldri til dem av seg selv: dette er produksjonsdatabaser, og å åpne tilkoblinger ved hvert besøk er trafikk ingen har bedt om.»

#God praksis

• Dedikert konto, minst mulige rettigheter. Opprett en bruker i databasen bare for appen, med tilgang bare til tabellene som trengs. Alt appen kjører — API-er, skript, konsoll — går gjennom den kontoen.
• Pek testene mot testdata. Når du tester et API som skriver, sier plattformen selv ifra: «Testen kjører pipelinen på ekte mot datakildene — en mutation skriver på ekte. Forsikre deg om at du peker på testdata.»
• Krypter tilkoblingen hver gang serveren tillater det (Bruk SSL / Encrypt) — særlig når databasen ligger i et annet nett.
• Navn som sier hvilket miljø det er. crm og crm-test unngår den verst tenkelige forvekslingen: å skrive på riktig sted i feil miljø.

#Vanlige spørsmål

• Viser Keplin meg passordet jeg lagret? Nei. Det skrives bare én gang — alternativet er å erstatte det.
• Rører Test tilkoblingen dataene? Nei. Den åpner tilkoblingen, kjører en harmløs kontrollspørring og lukker den.
• Hvorfor går testen gjennom, mens spørringen i API-et feiler? Testen validerer tilkoblingen, ikke rettighetene på hver tabell. Kan ikke kontoen lese eller skrive i en tabell, er det i den spørringen feilen dukker opp.
• Jeg endret passordet på databaseserveren — hva nå? API-ene og skriptene begynner å feile med autentiseringsfeil. Åpne Rediger tilkobling, skriv det nye passordet og Lagre.