Mājaslapā ir HTTPS, tātad viss ir droši? Tas ir izplatīts, bet nepilnīgs priekšstats. Šifrēts savienojums palīdz aizsargāt informāciju ceļā starp apmeklētāja pārlūku un serveri, taču tas nepasargā no visām kļūdām datu glabāšanā, lietotāju piekļuvē vai ārējo sistēmu savienojumos. Uzņēmumam svarīgi saprast ne tikai to, vai sertifikāts ir uzstādīts, bet arī to, kas notiek pēc pieteikuma nosūtīšanas.

Šis ceļvedis koncentrējas uz drošības robežām: ko nodrošina SSL, kur sākas citu tehnisko risinājumu atbildība un kā plānot klientu datu apriti. Tas palīdzēs uzdot precīzākus jautājumus mājaslapas uzturētājam un izvairīties no situācijas, kurā drošs savienojums rada nepamatotu pārliecību par visas sistēmas drošību.

1. Ko SSL patiesībā aizsargā

Ikdienā joprojām lieto apzīmējumu SSL sertifikāts, lai gan mūsdienās savienojumu šifrēšanai izmanto TLS protokolu. HTTPS ir HTTP saziņa, ko aizsargā TLS. Pareizi izveidots savienojums palīdz nodrošināt nosūtītās informācijas konfidencialitāti un integritāti: trešajām personām ir ievērojami grūtāk datus nolasīt vai nepamanīti mainīt pārraides laikā.

Sertifikāts arī palīdz pārlūkam pārbaudīt, vai savienojums izveidots ar attiecīgajam domēnam atbilstošu serveri. Tomēr derīgs sertifikāts nav apliecinājums uzņēmuma godprātībai. Arī krāpnieciska vietne var izmantot HTTPS. Tāpēc apmeklētājam jāpievērš uzmanība domēna rakstībai, savukārt uzņēmumam savās vēstulēs un piedāvājumos jāizmanto konsekventas, atpazīstamas saites.

SSL neizlemj, kurš darbinieks drīkst apskatīt klientu sarakstu. Tas arī nenovērš kaitīgu programmatūru apmeklētāja ierīcē un nepadara publiski pieejamu dokumentu privātu. Šifrēšana pārraides laikā ir viens drošības slānis, nevis aizvietotājs piekļuves kontrolei vai atbildīgai datu pārvaldībai.

• HTTPS aizsargā saziņu starp konkrētajiem savienojuma galapunktiem.
• Sertifikāts jāuztur derīgs un atbilstošs izmantotajiem domēna vārdiem.
• Datu glabāšanas un piekļuves aizsardzība jārisina atsevišķi.

2. HTTPS jādarbojas visā mājaslapā

Nepietiek ar to, ka sākumlapa atveras ar HTTPS. Arī kontaktformām, autorizācijas lapām, attēliem, skriptiem un citiem resursiem jāizmanto droši savienojumi. Ja HTTPS lapa mēģina ielādēt resursus pa HTTP, rodas jaukts saturs. Pārlūks šādus resursus var bloķēt vai mēģināt ielādēt drošā veidā, taču uz šo uzvedību nevajadzētu paļauties kā uz konfigurācijas aizvietotāju.

Praktisks sākumpunkts ir vienota domēna versija. Izvēlieties galveno adresi ar vai bez www un nodrošiniet korektas pāradresācijas uz tās HTTPS versiju. Sertifikātam jāaptver arī tās HTTPS adreses, no kurām paredzēta pāradresācija, jo drošā savienojuma pārbaude notiek pirms pāradresācijas saņemšanas.

Tehniskajam uzturētājam ir vērts jautāt arī par HSTS. Šī drošības galvene pārlūkam norāda turpmāk izmantot tikai HTTPS noteiktā laikposmā. Tā jāievieš pārdomāti, īpaši tad, ja iestatījums aptvers apakšdomēnus. Nepārbaudīta konfigurācija var padarīt nepieejamus pakalpojumus, kuri vēl nav sagatavoti drošam savienojumam.

1. Atveriet lapu gan ar HTTP, gan HTTPS adresi un pārbaudiet galarezultātu.
2. Izmēģiniet abas domēna versijas, ja izmantojat arī www.
3. Pārbaudiet svarīgākās formas un ārējo resursu ielādi.
4. Noskaidrojiet, kurš atbild par sertifikāta atjaunošanu un kļūdu paziņojumiem.

3. Datu ceļš nebeidzas pie formas pogas

Iedomājieties pakalpojuma pieteikumu: klients ievada kontaktinformāciju, mājaslapa to pieņem, paziņojums nonāk e-pastā, bet ieraksts tiek izveidots CRM. Vēlāk no šiem datiem sagatavo PDF piedāvājumu. Katrs posms ir atsevišķs savienojums vai glabāšanas vieta. Mājaslapas SSL sertifikāts pats par sevi nenodrošina visu šo posmu aizsardzību.

Uzzīmējiet vienkāršu datu aprites shēmu. Pie katra posma pierakstiet, kāda informācija tiek nosūtīta, kur tā paliek un kam tā ir pieejama. Bieži vien šādi kļūst redzamas nevajadzīgas kopijas: pilns pieteikums vairākās pastkastēs, izklājlapa koplietotā mapē vai lejupielādēts dokuments personīgajā datorā.

E-pasta paziņojumā var pietikt ar norādi, ka saņemts jauns pieteikums, un saiti uz sistēmu, kurā jāautorizējas. Tas samazina datu izplatīšanu, tomēr arī saitei jābūt veidotai droši. Klienta vārdu, tālruni vai citus sensitīvus datus nevajadzētu ievietot adreses parametros, jo URL var nonākt pārlūka vēsturē un žurnālos.

Arī automatizācijas rīkiem un MI palīgiem nosūtiet tikai uzdevumam nepieciešamo informāciju. Ja jāizveido piedāvājuma struktūra, pilna klientu datubāze nav vajadzīga. Pirms integrācijas noskaidrojiet pakalpojuma datu izmantošanas un glabāšanas nosacījumus, nevis pieņemiet, ka šifrēts savienojums atrisina arī šos jautājumus.

4. Piekļuves tiesības aizsargā datus pēc saņemšanas

Pēc datu nonākšanas sistēmā galvenais jautājums ir: kurš tos var apskatīt, mainīt vai eksportēt? Nelielā komandā kopīgs administratora konts var šķist ērts, taču tas apgrūtina darbību izsekošanu un piekļuves atsaukšanu. Katram darbiniekam vēlams savs konts ar viņa pienākumiem atbilstošām tiesībām.

Satura redaktoram parasti nav nepieciešama piekļuve visiem klientu ierakstiem. Savukārt pārdošanas darbiniekam nav automātiski jāpiešķir iespēja mainīt mājaslapas tehniskos iestatījumus. Mazāko nepieciešamo tiesību princips samazina iespējamās sekas gan kļūdas, gan konta pārņemšanas gadījumā.

• Izmantojiet unikālas paroles un uzticamu paroļu pārvaldnieku.
• Ieslēdziet daudzfaktoru autentifikāciju sistēmās, kur tā pieejama.
• Ārējiem speciālistiem piešķiriet piekļuvi tikai nepieciešamajam darbam un laikam.
• Pēc sadarbības beigām atsauciet kontus, aktīvās sesijas un vairs nevajadzīgās integrāciju piekļuves.
• Regulāri pārskatiet, kam atļauts lejupielādēt klientu datus.

Īpašu uzmanību pievērsiet dokumentiem. Sarežģīta vai nejauša faila adrese nav pilnvērtīga piekļuves kontrole. Ja PDF piedāvājums paredzēts konkrētam klientam, jāizvērtē autorizācija vai ierobežota termiņa piekļuve. Meklētājiem dota norāde lapu neindeksēt arī neaizliedz cilvēkam atvērt zināmu adresi.

5. Glabāšana, rezerves kopijas un integrāciju noslēpumi

Šifrēšana pārraides laikā un šifrēšana glabāšanas laikā risina atšķirīgus riskus. Otrā var palīdzēt aizsargāt datubāzes, diskus vai rezerves kopijas, taču tās lietderība atkarīga arī no šifrēšanas atslēgu pārvaldības. Ja uzbrucējs iegūst pilnvērtīgu piekļuvi lietotnei, ar diska šifrēšanu vien var nepietikt.

Rezerves kopijām nepieciešama tāda pati uzmanība kā darba sistēmai. Noskaidrojiet, kur tās glabājas, kam pieejamas, cik ilgi tiek saglabātas un vai ir pārbaudīta atjaunošana. Kopija palīdz atgūt datus, bet pati par sevi nenovērš to noplūdi. Arī vecās kopijās var palikt informācija, kas ikdienas sistēmā vairs nav vajadzīga.

Integrāciju API atslēgas, paroles un piekļuves marķieri nedrīkst nonākt publiskā lapas kodā vai koplietotos dokumentos. Ja atslēga paredzēta tikai servera lietošanai, to nevar droši paslēpt pārlūkā izpildāmā skriptā. Integrāciju konfigurēšanā jānodala publiskie iestatījumi no noslēpumiem un jāparedz iespēja piekļuvi atsaukt.

6. Ko precizēt ar mājaslapas pakalpojuma sniedzēju

Pirms darba sākšanas vienojieties par atbildības sadalījumu. Kas uztur servera vidi, kas pārvalda lietotāju kontus un kas konfigurē ārējos savienojumus? Atbildēm jābūt konkrētām. Formulējums “drošība ir iekļauta” nepasaka, vai pakalpojums ietver arī rezerves kopijas, piekļuves pārvaldību vai konkrētu integrāciju uzturēšanu.

99web.lv profesionāla mājaslapa maksā 9,99 €/mēn. ar PVN; cenā ir iekļauts hostings, SSL, uzturēšana un MI rediģēšanas kredīti. Mājaslapu var veidot pats ar MI vai izvēlēties no kataloga. Papildus pieejami CRM, e-pasta sistēmas, rēķinu vadība, internetveikals, procesu automatizācija, MI konsultanti un čati, PDF piedāvājumi un atskaites.

Izvēloties šos risinājumus, pārrunājiet tieši sava uzņēmuma datu apriti un nepieciešamos drošības iestatījumus. Projektu vadītājs ir pieejams jebkurā brīdī, lai apspriestu prasības un precizētu risinājuma iespējas. Sāciet ar saprotamu mājaslapu un pārdomātiem datu savienojumiem: izmēģiniet 99web.lv un dodieties reģistrēties.