Fra og med versjon 17.32.160 LTS, 20.0 PROD og 17.33.270 BETA har Invantive SQL endret standardinnstillingene for tilkoblinger til MySQL, PostgreSQL og SQL Server for å håndheve kryptering av datatransport ved bruk av SSL. Denne artikkelen gir noen tips om riktig konfigurasjon av sertifikater. De er derimot kun forslag. Konsulter din databaseadministrator, sikkerhetsansvarlig eller IT-leverandør for mer dyptgående kunnskap og anvendelse for din lokale situasjon.
Fra versjon 20.0.112 og 20.1.261 BETA har standardene for SQL Server blitt finjustert: standardkryptering er deaktivert når en SQL Server-databeholder ble registrert fra oppdagelse og enten aksesseres ved hjelp av pipedriveren (Windows Intern database) eller datakilden/servernavnet ikke inneholder et desimalt punkt (‘.’). Dette gjør første bruk enklere, siden få (om noen) bla-bare lokale SQL Server-installasjoner eksisterer med riktig sertifikatkonfigurasjon.
Typisk SQL Server-feil
Etter en oppgradering kan du støte på en feil med kode itgenclr038, itgenclr121 eller itgenase498 som:
provider: SSL-leverandør, feil: 0 - Sertifikatkjeden ble utstedt av en autoritet som ikke er klarert.
Eller
SSL-leverandør, feil: 0 - Det angitte prinsipalnavnet er feil.
Typisk PostgreSQL-feil
På PostgreSQL kan du støte på en feil som:
Validering av eksternt sertifikat mislyktes
eller en itgenclr072 med tekst som:
AuthenticationException
Unntak ved utførelse av SSL-håndtrykk.
Det eksterne sertifikatet ble avvist av den angitte RemoteCertificateValidationCallback.
eller en itgenclr139 feil som:
SSL-tilkobling forespurt. Ingen SSL-aktivert tilkobling fra denne verten er konfigurert.
Typisk MySQL-feil
På MySQL kan du støte på en feil som:
Verteren NOE støtter ikke SSL-tilkoblinger.
Angrepsmetode
De anbefalte trinnene for slike problemer er:
- Konfigurer riktig transportkryptering.
- Sjekk med din sikkerhetsansvarlige om ukryptert og usikret datatransport mellom din Invantive SQL-node og databasen er tillatt.
- Hvis ja, deaktiver den nåværende standardkrypteringen.
Konfigurer transportkryptering
Transportkrypteringen må konfigureres på klienten som oppretter tilkoblingen. For lokale produkter, er dette serveren eller enheten som brukes til å kjøre Invantive-produktet. Invantive online-produkter gir varierende mengder konfigurasjonsmuligheter, men det er vanligvis ikke mulig å laste inn egendefinerte eller ikke-standard sertifikater.
Azure
På Azure distribuerer Microsoft som standard de nødvendige sertifikatene på serveren, som som standard aksepteres på Microsoft Windows.
Vennligst sørg for at du bruker riktig vertsnavn, som myname.database.windows.net.
Amazon
På Amazon kan det hende du må laste inn sertifikatkjeden på din klient. Følg AWS-instruksjonene, som vanligvis er:
- Last ned AWS offentlige nøkkel fra https://s3.amazonaws.com/rds-downloads/rds-combined-ca-bundle.pem.
- Konverter det til et sertifikat ved å bruke https://www.sslshopper.com/ssl-converter.html (konverter til PKCS#7/P7B).
- Importer p7b-filen til sertifikatlageret.
Egenadministrert server
For lokale og egenadministrerte servere, vennligst konsulter din lokale administrator.
Deaktiver standardkryptering
Disse trinnene beskriver hvordan man deaktiverer en forespørsel om kryptering initiert av klientprogramvaren ved å endre tilkoblingsstrengen. Både databaseserveren og klienten må være enige om kryptering, så det er ikke alltid mulig å tilby en klient-kun løsning.
Plasseringen av tilkoblingsstrengen varierer, men i de fleste distribusjonsscenarier kan den finnes i settings*.xml-filer (formatbeskrivelse). Disse ligger vanligvis i %USERPROFILE%\invantive mappen; konsulter kunnskapsbasert artikkel 7208961 for mer informasjon.
Innenfor settings*.xml-filene kan tilkoblingsstrengen forekomme som en del av en databeholderdefinisjon som:
<database
...
connectionString="Server=dbhost.com;Initial Catalog=database;Persist Security Info=False;User ID=user;Password=secret;Connection Timeout=30;"
Og i attributter som tilkoblingsstrengen brukt for Invantive Data Replicator:
dataCacheConnectionString="provider=SqlServer;connectionString={Server=dbhost.com;Database=database;User Id=user;Password=secret}"
Invantive dokumentasjonen inneholder mer bakgrunnsinformasjon om oppsett av settings*.xml-filer. Alternativt kan din lokale databaseadministrator kanskje hjelpe deg.
SQL Server-endring
Som et første trinn kan du ønske å fortsette å bruke kryptering, men tillate noen angrep ved å endre tilkoblingsstrengen for å inkludere:
hostNameInCertificate=*.domain.name
Alternativt kan du ønske å fortsette å bruke kryptering, men tillate flere angrep som instance man-in-the-middle angrep ved å endre tilkoblingsstrengen for å inkludere:
TrustServerCertificate=True
Som en siste utvei, deaktiver krypteringen fullstendig ved å bruke:
Encrypt=false
SQL Server-eksempel
For eksempel, fullstendig deaktivering av SQL Server-krypteringen i tilkoblingsstrengen som en del av en databeholderdefinisjon gitt ovenfor fører til:
<database
...
connectionString="Encrypt=false;Server=dbhost.com;Initial Catalog=...original..."
Og for SQL Server brukt til å lagre Invantive Data Replicator-repositoriet gitt ovenfor:
dataCacheConnectionString="provider=SqlServer;connectionString={Encrypt=false;Server=...original...}"
PostgreSQL
Som et første trinn kan du ønske å fortsette å bruke kryptering, men tillate flere angrep som instance man-in-the-middle angrep ved å endre tilkoblingsstrengen for å inkludere:
Trust Server Certificate=True
Som en siste utvei, tillat deaktivering av kryptering ved å bruke:
SslMode=Prefer
MySQL
Som et første trinn kan du ønske å fortsette å bruke kryptering, men tillate flere angrep som instance man-in-the-middle angrep ved å endre tilkoblingsstrengen for å inkludere:
SslMode=VerifyCA
Som en siste utvei, tillat deaktivering av kryptering ved å bruke:
SslMode=Preferred