• English
  • Română
MENU
Solicitați o demonstrație
+373 795 333 11
  • English
  • Română

De ce serviciile criptografice sunt nucleul securității cibernetice – și de ce m-am alăturat Ghesar

Într-o perioadă în care transformarea digitală a devenit un pilon fundamental al succesului afacerilor, piatra de temelie silențioasă care permite încrederea, securitatea și reziliența este criptografia. Fiecare întreprindere, fie că este conștientă, fie că nu, este profund dependentă de serviciile criptografice – totuși puține au o înțelegere a domeniului de aplicare, extinderii sau importanței strategice a acestor servicii.

Această realitate este motivul pentru care m-am alăturat Ghesar ca CEO. Ghesar oferă servicii criptografice inovatoare și soluții de automatizare care se află în centrul securității întreprinderilor. Pe măsură ce amenințările cibernetice cresc, informatica cuantică se profilează, iar sistemele de inteligență artificială necesită noi protecții, soluțiile Ghesar nu sunt doar importante – sunt esențiale pentru protejarea însăși infrastructurii afacerilor și societății moderne.

Nucleul ascuns al securității cibernetice

Criptografia alimentează aproape fiecare funcție critică în domeniul securității cibernetice:

Autentificare – Validarea identităților între sisteme, utilizatori și mașini

Protecția datelor și confidențialitate – Asigurarea confidențialității și integrității în tranzit, în repaus și în utilizare

Este, la propriu, nucleul de bază care susține fiecare funcție majoră de securitate cibernetică – PKI, CLM, IAM, PAM, DLP etc. – serviciile criptografice care alimentează aceste sisteme rămân negestionate, duplicate și periculos de fragmentate.

Extinderea criptografică negestionată

Majoritatea organizațiilor nu își dau seama că activele criptografice – chei, certificate, protocoale, algoritmi și servicii de semnare – se răspândesc cu o viteză fulgerătoare în mediile lor:

Aceste active sunt încorporate în nenumărate resurse IT, entități software, instrumente și sisteme – fiecare implementând propria instanță criptografică izolată. Această extindere structurată are ca rezultat:

Mai rău, majoritatea organizațiilor nici măcar nu pot vedea unde se află serviciile lor criptografice, darămite să le controleze.

Nevoia de control unificat al întreprinderii

Trebuie să începem să ne gândim la serviciile criptografice în același mod în care ne gândim la alte funcții de bază ale întreprinderii. Așa cum gestionarea identității și a accesului (IAM) sau securitatea endpoint-urilor necesită o guvernanță centrală, serviciile criptografice au nevoie de:

Întreprinderile trebuie să treacă de la utilizarea ad-hoc a criptografiei la o misiune criptografică strategică – în care serviciile cripto sunt unificate, guvernate, automatizate și integrate în întreaga afacere.

De ce Ghesar

Ghesar a fost fondată pentru a rezolva exact această problemă. Abordarea sa unică a serviciilor criptografice se bazează pe fundațiile centrate pe identitate și pe zero-trust, puse de inițiativele moderne de securitate cibernetică. Prin aplicarea controalelor de securitate la nivel criptografic primitiv, Ghesar este capabilă să traseze cea mai mică limită zero-trust posibilă – la nivel de date, care este similar cu nivelul celular al infrastructurii IT a unei întreprinderi. Această abordare permite un echilibru sănătos între Securitate, Performanță, Conformitate și Ușurință în Utilizare prin:

Într-o perioadă în care defecțiunile criptografice pot duce la întreruperi catastrofale, la acțiuni de reglementare sau la compromiterea statului-națiune, abordarea unificată a securității, axată pe criptografie pe primul loc, a Ghesar nu este doar inovatoare – este indispensabilă.

Drumul de dinainte

Într-o eră a schimbărilor digitale exponențiale, a avansului rapid al inteligenței artificiale, a apariției calculului cuantic, combinate cu explozia identităților automate și non-umane, a roboticii și a sistemelor autonome – miza nu a fost niciodată mai mare. Lumea noastră fizică și cea digitală se îmbină rapid într-o singură realitate inseparabilă.

Serviciile criptografice nu sunt o funcționalitate IT back-end retrogradată la o artă obscură și rezervată câtorva practicieni. Ele sunt fundamentale pentru protejarea modului nostru de viață viitor – literalmente, însăși fundația pe care se construiește încrederea. Trebuie să recunoaștem și să îmbrățișăm rolul critic pe care aceste servicii îl contribuie la interacțiunile noastre digitale continue și la menținerea ecosistemului nostru social și economic de zi cu zi.

M-am alăturat Ghesar pentru că cred că viziunea, tehnologia și expertiza lor în domeniu sunt esențiale în rezolvarea acestor provocări actuale și în continuă evoluție. Ghesar oferă organizațiilor o „cale de urmat” strategică în activarea și controlul serviciilor criptografice la nivel tactic și holistic – și le ajută să securizeze sistemele care ne securizează lumea.

Aflați cum o arhitectură de semnare hash pe partea clientului poate accelera semnăturile digitale în mediul dvs. IT.

Asigurarea securității și performanței semnăturilor digitale este o prioritate maximă pentru fiecare lider InfoSec și DevSecOps. Deoarece multe companii trec la un mediu de lucru la distanță din cauza pandemiei globale în curs, această sarcină devine considerabil mai dificilă.

Cum asigurați securitatea tuturor semnăturilor digitale în cadrul unei forțe de muncă complet la distanță, fără a compromite performanța?

Semnături digitale pentru echipe distribuite

Întrucât multe companii adoptă politici de lucru de acasă pentru a menține siguranța membrilor echipei în mijlocul pandemiei de COVID-19, obținerea atât a unei securități de neegalat, cât și a performanței de top a semnăturilor digitale pentru o echipă distribuită geografic este acum esențială pentru operațiunile de afaceri.

Când vine vorba de activarea semnăturilor digitale pentru o echipă distribuită, există trei abordări generale:

Păstrați cheile private în software și distribuiți-le membrilor echipei, după cum este necesar.

Plasați cheile în protecție hardware (adică un modul de securitate hardware) și distribuiți mai multe HSM-uri către diferitele echipe ale companiei dvs.

Stocați cheile într-un HSM gestionat centralizat și oferiți acces proxy tuturor utilizatorilor finali.

Opțiunea 1 prezintă riscuri majore de securitate și nu ar trebui luată în considerare de nicio companie care își prețuiește securitatea datelor. Atunci când cheile de semnare sunt stocate în software, nivelul de protecție din jurul acestora este pur și simplu prea slab pentru confort. Atacatorii ar putea obține acces la chei prin compromiterea dispozitivului unui angajat sau prin extragerea cheilor din software-ul în sine.

Opțiunea 2 oferă o securitate îmbunătățită în comparație cu prima abordare, dar vine cu un preț descurajant. Modulele de securitate hardware sunt costisitoare, așa că achiziționarea mai multor HSM-uri nu este cea mai rentabilă abordare pentru a permite semnături digitale securizate pentru o echipă mare. Mai mult, menținerea sincronizării mai multor dispozitive hardware și efectuarea gestionării cheilor pe mai multe HSM-uri este o sarcină foarte dificilă.

Opțiunea 3 este soluția optimă, dacă se poate realiza menținând în același timp performanțe excelente. Aici intervine semnarea hash.

Ce este semnarea hash?

Termenul „semnare hash” poate fi confuz, deoarece practic toate schemele de semnătură digitală utilizează o formă de funcție hash criptografică.

În general, o semnătură digitală este produsă prin hashing-ul documentului sau codului care trebuie semnat, apoi prin aplicarea operațiunii de cheie privată criptografică asupra valorii hash rezultate. Deoarece funcțiile hash criptografice produc în mod determinist o ieșire mică, de lungime fixă, dintr-o intrare de date de dimensiune arbitrară, hash-ul servește ca amprentă electronică a datelor. Hash-ul datelor este o componentă a semnăturii digitale a acestor date, permițând verificatorilor să detecteze cu ușurință dacă au fost făcute modificări documentului sau codului după finalizarea semnăturii.

Rețineți că cheia privată nu este necesară în procesul de semnătură digitală decât după ce datele sunt procesate prin hashing. Ca atare, nu este necesar să trimiteți toate datele către un server de semnare pentru a crea o semnătură digitală. În schimb, hashing-ul poate fi efectuat local, doar valoarea hash fiind trimisă către serverul de semnare pentru a finaliza semnătura digitală cu operațiunea cheii private.

Această metodă de hashing pe partea clientului, cunoscută sub numele de semnare hash, îmbunătățește considerabil performanța semnăturilor digitale generate de la distanță.

Fără semnarea hash, companiile care optează pentru Opțiunea 3 – adică stocarea tuturor materialelor cheii private în HSM-uri gestionate central – trebuie să încarce toate datele semnate în serviciul central de semnare, apoi să descarce întregul pachet semnat odată ce semnătura este completă. Pentru orice caz de utilizare care necesită crearea de semnături pentru fișiere mari (de exemplu, semnarea codului, semnarea documentelor, marcarea temporală criptografică a copiilor de rezervă etc.), aceasta înseamnă că este necesar să se transporte volume mari de date prin rețea de două ori, ceea ce duce la generarea lentă a semnăturilor și la un consum inutil de lățime de bandă.

Odată cu implementarea corectă a semnării hash, această problemă este rezolvată. Deoarece doar hash-ul datelor semnate este trimis prin rețea către serverul de semnare, transmisiile de lățime de bandă sunt menținute la minimum, iar procesul de semnătură digitală este accelerat.

Provocări cu semnarea hash

Deși semnarea bazată pe hash oferă avantaje semnificative în ceea ce privește performanța semnăturii digitale, aceasta vine și cu câteva provocări. În special, există două provocări majore legate de semnarea bazată pe hash: integrările clienților și securitatea.

Integrări ale clienților

Multe instrumente de semnare din prezent presupun că cheia de semnare se află pe computerul local pe care este executat instrumentul. În mod similar, API-urile modulului de securitate hardware (HSM) presupun implicit că datele care trebuie semnate se află pe mașina conectată direct la HSM. Desigur, primul scenariu prezintă riscuri majore de securitate, în timp ce cel de-al doilea nu este cazul semnării hash.

Implementarea unei arhitecturi de semnare hash pe partea clientului cu instrumentele existente, toate acestea păstrând în același timp cheile de semnare blocate în siguranță într-un HSM sau manager de chei al întreprinderii, este o sarcină extrem de complexă. Necesită multă muncă de dezvoltare la nivel scăzut din partea experților în criptografie care fac în mod transparent toată munca grea pentru dvs.

Din fericire, exact asta adoră să facă echipa de la Ghesar. Am conceput produsul nostru emblematic, E-semnatura, pentru a veni cu acești furnizori criptografici gata de utilizare imediată pe toate platformele majore, inclusiv Apple, Microsoft, Java, Android, GPG, RPM, Linux, OpenSSL și multe altele. Indiferent dacă semnați cod, documente, handshake-uri de tip provocare-răspuns sau orice alt tip de date, integrările client ale E-semnatura fac ca aceasta să fie o experiență perfectă pentru utilizatorii finali.

Securitate

Cu semnarea hash, serverul de semnare vede doar hash-ul datelor, nu toate datele semnate. Prin urmare, serverul de semnare nu poate analiza aceste date foarte ușor. Pentru a depăși acest lucru, Ghesar a integrat câteva caracteristici cruciale în platforma E-semnatura Sign, inclusiv:

Sunteți gata să aflați mai multe despre cum E-semnatura poate îmbunătăți securitatea și performanța semnăturilor digitale în mediul dvs.? Contactați echipa Ghesar. Deși produsul E-semnatura este gestionat complet de client, echipa Ghesar va fi bucuroasă să vă găzduiască gratuit dovada conceptului, astfel încât să puteți experimenta viteza și integrările perfecte ale E-semnatura.

Vă sună familiar? Lucrați la o companie la un proiect mare și sunteți pe cale să treceți la producție, dar trebuie să adăugați ultimele retușuri. Vi se spune că aveți nevoie de certificate TLS pentru echilibratoarele de încărcare, serverele de aplicații și serverele de baze de date, un loc sigur de unde să bootați câteva secrete și să activați criptarea bazei de date. Pare destul de simplu, trebuie doar să aflați de la cine să solicitați acest lucru. Nu ați fi putut greși mai mult – sunteți brusc inundați de întrebări și de un labirint de arbore decizional:

Se va dovedi că va dura aproape la fel de mult până la finalizarea ultimelor retușuri precum a durat finalizarea grosului proiectului până acum.

Dacă acest lucru vă sună familiar, nu vă faceți griji, nu sunteți singuri. Nu este un secret faptul că tehnologia se mișcă rapid, dar de multe ori infrastructura și procesele noastre rămân în urmă. Acum vedem cum industria recuperează terenul pierdut prin implementarea Serviciilor Criptografice Enterprise. La nivel înalt, echipa Serviciilor Criptografice Enterprise este responsabilă pentru gestionarea și utilizarea securizată a cheilor, certificatelor și secretelor. Întrucât aceste primitive criptografice sunt utilizate în atât de multe dintre cazurile de utilizare și protocoalele utilizate în mod obișnuit, echipa Serviciilor Criptografice Enterprise joacă un rol crucial în strategia generală de securitate a întreprinderii.

Exemple de servicii criptografice

Câteva exemple de responsabilități pentru echipa Enterprise Cryptographic Services includ:

  1. Generare și stocare securizată a cheilor
  2. Gestionarea dispozitivelor criptografice care stochează cheile, fie local, în cloud sau în ambele
  3. Emitere și reînnoire automată și manuală a certificatelor
  4. Distrugerea corectă a cheilor și revocarea certificatelor atunci când este necesar
  5. Crearea, rotația și distrugerea automată și manuală a secretelor
  6. Auditarea permisiunilor pentru chei și, în mod ideal, a utilizării cheilor în timp real pentru a asigura conformitatea cu politicile corporative

Scule adecvate

Pentru a conduce corect o echipă de Servicii Criptografice pentru Întreprinderi, este necesară infrastructura și instrumentele adecvate. Aceste instrumente ar trebui să ofere cel puțin:

Indiferent dacă abia începeți călătoria către Serviciile Criptografice pentru Întreprinderi, aveți deja un serviciu dezvoltat sau vă aflați undeva la mijloc, Ghesar este aici pentru a vă ajuta. Avem o vastă experiență în crearea, implementarea și gestionarea soluțiilor de Servicii Criptografice pentru Întreprinderi, inclusiv cea mai bună soluție din clasa noastră. Ghesar, pentru întreprinderi mari și mijlocii. Vă rugăm contact us la noi pentru a discuta despre nevoile dumneavoastră.

Revocarea unui certificat invalidează certificatul înainte de data de expirare programată. Există numeroase motive pentru revocarea unui certificat, inclusiv, dar fără a se limita la, compromiterea sau pierderea cheii private corespunzătoare, imposibilitatea cheii și multe altele. Deși revocarea este de obicei discutată în contextul certificatelor X.509, alte tipuri de certificate, cum ar fi secure shell (SSH) și o confidențialitate destul de bună (PGP) (da, ne referim la cheile publice PGP ca certificate) acceptă, de asemenea, revocarea. În ciuda faptului că conceptul de revocare are un suport larg, în paragrafele următoare vom arăta cum implementările sunt mai complicate, cu o mulțime de cazuri limită și un suport general slab.

Metode de revocare a certificatului

Cea mai obișnuită metodă de revocare a unui certificat este prin publicarea unei liste de certificate revocate pe care clienții le pot consuma. În lumea X.509, acest lucru se face printr-un Certificate Revocation List (CRL). Iîn acest caz, Certificate Authority (CA) publică CRL-ul care conține lista certificatelor, starea de revocare (adică, Revocat sau Hold), motivul revocării (adică, nespecificat, keyCompromise, cACompromise, affiliationChanged, superseded, cessationOfOperation, certificateHold, removeFromCRL, privilegeWithdrawn sau aACompromise) și momentul în care a avut loc revocarea (notă: conform RFC 5280 există o diferență între data revocării și data invalidității, dar Ballot CSC-12 din cadrul Forumului CA/Browser a simplificat acest lucru în 2021).

Deși CRL-urile funcționează în teorie, ele prezintă numeroase probleme în practică. Pentru ca CRL-ul să fie accesat, acesta trebuie să fie disponibil clientului în timp real și, prin urmare, trebuie să fie accesibil „online”. Deși acest lucru nu este de obicei o problemă atunci când navigați pe site-uri web de pe web-ul public, poate fi o problemă în rețelele private și în cazurile de utilizare care nu se bazează pe securitatea nivelului de transport (TLS) (de exemplu, validarea semnăturilor pe cod sau documente pe o mașină offline). În plus, dacă CA-ul este popular, este posibil să fi emis o mulțime de certificate, ceea ce poate duce la CRL-uri mari care consumă multă lățime de bandă, au un impact negativ asupra performanței și deschid posibilitățile de atacuri de tip denial of service (DoS). Pentru a combate acest lucru, CA-urile publică periodic noi CRL-uri, iar clienții stochează în cache rezultatele CRL-urilor, ceea ce duce la o altă problemă – învechirea CRL-urilor. Dacă un certificat a fost revocat, poate dura uneori până la 24 de ore înainte ca un client să vadă starea actualizată și, până atunci, poate fi prea târziu.

Pentru a depăși aceste probleme, Online Certificate Status Protocol (OCSP) a fost conceput. OCSP permite clienților să interogheze starea unui singur certificat în timp real, reducând astfel semnificativ dimensiunea datelor transferate și îmbunătățind performanța și atenuarea DoS. Cu toate acestea, deoarece clientul interoghează un anumit certificat în momentul în care este consumat, acesta transmite informații către CA despre serviciul pe care îl consumă clientul și, prin urmare, are probleme de confidențialitate. OCSP poate, de asemenea, să pună o povară considerabilă asupra CA-urilor, în special pentru certificatele care sunt consumate adesea de mai mulți clienți diferiți (de exemplu, pentru site-uri web populare). Protocoale precum OCSP with stapling au fost concepute pentru a depăși această problemă, dar nu au fost niciodată adoptate pe scară largă.

Deschidere nereușită vs. Închidere nereușită

Datorită dependenței de infrastructura CA pentru verificarea stării de revocare, clienții trebuie să decidă ce să facă dacă starea de revocare nu poate fi verificată. Ar trebui ca clientul să se deschidă în mod eșuat (adică să continue cu o operațiune precum accesarea site-ului web) sau ar trebui să se închidă în mod eșuat (adică să nu continue cu operațiunea, ceea ce ar putea însemna imposibilitatea accesării unui site web sau a instalării de software)? Eșecul închiderii leagă disponibilitatea sistemului de disponibilitatea infrastructurii CA. Eșecul deschiderii lasă ușa deschisă atacatorilor pentru a ataca infrastructura CA, astfel încât clienții să nu vadă că un certificat compromis a fost marcat ca revocat. Unele browsere aleg să deschidă în mod eșuat, în timp ce altele au optat să nu verifice nici măcar starea de revocare și se bazează în schimb pe certificate cu durată scurtă de viață.

Impactul unui certificat revocat

Dacă clientul poate detecta că certificatul este revocat, ce ar trebui să facă? Unele cazuri de utilizare sunt destul de evidente. De exemplu, într-un caz TLS în care un client interoghează starea certificatului în timp real, un certificat revocat înseamnă că endpoint-ul (de exemplu, serverul pe care încercați să îl accesați) nu ar trebui să fie de încredere și handshake-ul TLS ar trebui să se încheie. Dar ce se întâmplă cu alte… use cases unde a fost semnat ceva în trecut, înainte ca certificatul să fie revocat? De exemplu, software care a fost semnat în mod legitim code signed în trecut, înainte ca cheia sa privată să fie compromisă și certificatul să fie revocat? Ar trebui să treacă în continuare validarea? Ei bine, dacă clientul poate verifica că semnătura a fost produsă înainte de compromiterea cheii, atunci da, ar trebui să treacă validarea. Acesta este motivul pentru care marcarea temporală criptografică este atât de importantă – permite clientului să verifice în mod fiabil când a fost produs ceva, astfel încât să poată compara acest lucru cu datele de revocare și expirare. Notă: din punct de vedere tehnic cryptographic timestamping permite unui client să verifice dacă ceva a fost produs la sau înainte de o anumită dată, nu neapărat data la care au fost produse datele, dar această distincție depășește scopul acestei postări.

Cele mai bune practici

Având în vedere complexitățile revocării, sprijinul mixt pentru aceasta din partea clienților obișnuiți și ramificațiile utilizării necorespunzătoare, ce ar trebui să facă o întreprindere? Două dintre cele mai bune practici de urmat sunt:

1. Utilizați marcarea temporală criptografică

2. Folosește certificate cu durată scurtă de viață