Turvaserveri ja rakenduse vahelise ühenduse turvamine

X-tee turvaserveris on võimalik ja vägagi soovitav kasutada HTTPS ühenduse loomisel klientrakendusega mõlemapoolset sertifikaatide kontrollimist ehk mTLS:

• klientrakenduse pöördumisel turvaserveri poole

• turvaserverist sissetulnud päringu edasisuunamisel teenust pakkuva rakenduse suunas

Klientrakendus → turvaserver

Turvaserveri poole pöördumisel X-tee päringu tegemiseks kasutage alati https:// algusega aadressi. Turvaserveris alamsüsteemi alt "Internal Servers" vahelehel saab määrata minimaalse turvalise ühenduse liigi, millega on lubatud veel ühendust klientrakendusega luua. Valikuid on kolm:

• HTTP - mingit suhtluskanali krüpteerimist ega osapoolte kontrolli ei toimu. Turvalisus madal. Lubab kõik ühendused, mis temani jõuavad.

• HTTPS NO AUTH - suhtluskanal on küll krüpteeritud, kuid osapoole kontrolli ei toimu. Turvalisus keskmine. Keelab http:// kasutamise.

• HTTPS - suhtluskanal on krüpteeritud ning turvaserver loob ühenduse ainult eelnevalt määratud klientrakendustega. Turvalisus kõrge. Välistab kõik madalamad valikud ühendumisel.

Kasutades Connection type: HTTPS valikut, tagab see, et suhtluskanalit pole enam lihtsalt võimalik pealt kuulata ning turvaserver võtab vastu ainult need ühendused, kus pöörduja on sama, mille kliendisertifikaat on alamsüsteemi alla "Information System TLS certificate" juurde eelnevalt imporditud (pildil roheline allajoonitud). 

"Information System TLS certificate" real võib olla mitmeid sertifikaate. Oluline on, et igas sertifikaadis oleks kas CN või SAN väljal klientrakenduse aadress, mis turvaserveri poole pöördub. Vajadusel on artikli lõpus terminali käsud selle vaatamiseks. Ühe rakenduse kohta võib olla mitu sertifikaati (näiteks enne eelmise aegumist võib uue juba varem üle laadida, et ei toimuks vana aegumisel katkestust). Usaldusahelat pole vaja üles laadida ning ainult väljastaja (issuer) sertifikaati ega wildcard sertifikaati kasutada ei saa.

Connection type: HTTPS valik ei luba enam turvaserveriga suhtlemisel kasutada http:// algusega aadressi. Kui keegi ikka üritab seda, siis logifaili proxy.log kirjutatakse veateade "Client (SUBSYSTEM) specifies HTTPS but did not supply TLS certificate". Reeglina üks rida eespoolt on sama logireaga seotud ühenduse loomise kanne, kust saab teada, mis IP aadressilt üritati http ühendus luua.

mTLS põhimõte

Parema turvalisuse tagamiseks saab turvaserveri ja rakenduse vahelises suhtluses rakendada mTLS põhimõtet. See toimib järgmiselt:

• Turvaserverisse on lisatud rakenduse TLS sertifikaat. Kui rakendus pöördub turvaserveri poole, siis turvaserver kontrollib kaasa pandud TLS sertifikaadi vastavust turvaserveris alamsüsteemi alla lisatud sertifikaadi vastu.

• Rakendus usaldab turvaserveri TLS sertifikaati. Kui turvaserver pöördub rakenduse poole, siis rakendus kontrollib turvaserveri poolt kaasa pandud TLS sertifikaadi vastavust rakenduse poolt usaldatud sertifikaatide vastu.

Kui üks neist kontrollidest ebaõnnestub (näiteks rakendus ei usalda seda TLS sertifikaati, mille turvaserver edastas), siis katkestab rakendus selle suhtluse ning X-tee päring ebaõnnestub.

Ülevalpool oleval pildi "Security Server certificate" plokis on näha turvaserveri enda sertifikaat, mida turvaserver ise edastab rakendusele kui selle poole pöördub. Rakendades mTLS põhimõtet, peab rakendus seda TLS sertifikaati usaldama, et turvaserveri poolt algatatud päringut teenindada. Vaikimisi on "Security Server certificate" puhul tegemist self-signed tüüpi sertifikaadiga, mille saab soovi korral asendada usaldusahelaga sertifikaadi vastu. Viide juhendile.

Turvaserver → teenust pakkuv rakendus

X-tee turvaserveris saab vajadusel aktiveerida teenust pakkuva serveri poolse kliendisertifikaadi kontrolli. Ilma selleta saadab turvaserver päringu alati edasi, kui ühenduse loomine õnnestus, kuid aktiveerides valiku "Verify TLS certificate", kontrollib turvaserver, et kas teise osapoole sertifikaat on olemas tema poolt usaldatude hulgas "Information System TLS certificate" all. Viimane asub ülevalpool pildil kujutatud alamsüsteemi all "Internal Servers" vahelehel.

Samamoodi nagu peab kasutama klientrakenduses suhtluses turvaserveriga HTTPS, siis alati kasutage turvaserveris teenusrakenduse pöörduspunktis ehk Service URL https:// algusega aadressi. Olles eelnevalt laadinud teenusrakenduse sertifikaadi "Internal Servers" → "Information System TLS certificate" alla ja valides valiku "Verify TLS certificate", toimub peale Save nuppu vajutamist ühendamise katse teenuse URL pihta. Kui sertifikaadi kontroll ebaõnnestub, siis kuvatakse vastav teade ja tuleb veenduda, et kas ikka antud teenuse URL aadressilt vastanud rakendus esitab enda sertifikaadiks sama, mille laadisite esimesel pildil näidatud kohas alamsüsteemi alla. Soovitan kasutada allpool kasulike käskude hulgas olevat openssl käsku rakenduse kliendisertifikaadi nägemiseks.

Timeout (s) abil saab määrata mitu sekundit ootab turvaserver teenuserakenduselt vastust. Vaikimisi on see 60 sekundit. Antud lehel tehtud muudatused on vaja enne väljumist kindlasti salvestada Save nupuga. 

Kasulikud terminali käsud

Sertifikaadi lugemine failist:

openssl x509 -noout -text sertifikaat.crt

Ühenduse kliendisertifikaadi vaatamine:

openssl s_client -showcerts -connect RAKENDUSE_AADRESS:PORT 2>/dev/null

# Ühenduse kliendisertifikaadi vaatamine lahti parsitud kujul:
openssl s_client -showcerts -connect RAKENDUSE_AADRESS:PORT 2>/dev/null | openssl x509 -noout -text

Self-signed sertifikaadi genereerimine HTTPS ühenduse jaoks:

Saab kasutada näiteks "Internal TLS certificates" jaoks. Sertifikaadi sisu saab peale genereerimist lugeda eespool toodud käsu abil.

# genereerib rakenduse sertifikaadi (kehtivusega 1200 päeva) ja selle privaat võtme:
openssl req -x509 -nodes -days 1200 -newkey rsa:2048 -keyout certificate.key -out certificate.crt

Käsurealt turvaserveri poole ühenduse loomine:

Katsetamiseks, et kas ikka õige sertifikaat on alamsüsteemi alla lisatud ning kas Connection Type: HTTPS on rakendatud. Käsurea alguses olev x-tee_näidispäringu fail on vaja esmalt luua kasutades malliks näiteks seda listMethods näidispäringut, kus vaja sisestada enda alamsüsteemi andmed (Client jaotises). Certificate.key ja certificate.crt on vastavalt klientrakenduse avalik sertifikaat ja tema privaat võti. Võib kasutada ka eelmises näites tehtud self-signed omi.

curl -v -d @x-tee_näidispäring.xml -H "Content-Type: text/xml; charset=UTF-8" -H "SOAPAction:" https://TURVASERVERI_AADRESS --cert certificate.crt --key certificate.key --insecure