Dacă mâine pierzi aplicațiile firmei, poți recupera totul? 8 riscuri IT pentru IMM-uri

O aplicație internă poate dispărea într-o singură zi: cineva șterge ceva din greșeală, un cont este spart sau serverul cedează. Un backup te ajută doar dacă îl poți restaura. Mai jos găsești cele 8 riscuri care apar cel mai des în firmele mici și 7 întrebări pe care să le pui echipei tale IT.

De ce contează aplicațiile interne într-o firmă mică?

Multe firme mici lucrează cu o aplicație făcută de doi sau trei oameni. Ea adună date din mai multe surse și le arată conducerii într-un tablou de bord (dashboard). Merge bine, așa că nimeni nu se mai gândește la ea.

Problema apare când se schimbă ceva. Un administrator șterge o regulă. Cineva modifică felul în care se calculează un raport. Un cont cu drepturi mari ajunge pe mâini greșite.

În acel moment contează două lucruri: să afli repede ce s-a întâmplat și să poți reveni la varianta bună.

Care sunt cele 8 riscuri IT pe care să le cunoști?

1. Greșeli sau abuzuri din interior

   Un om cu drepturi mari poate șterge sau strica ceva, de cele mai multe ori din greșeală.

   Verifică: cine are drept de administrator și dacă schimbările importante au nevoie de aprobare.

2. Cod modificat fără control

   O schimbare făcută în grabă poate strica un calcul fără ca aplicația să se oprească.

   Verifică: codul stă într-un sistem cu istoric, de exemplu Git, și fiecare schimbare este văzută de a doua persoană.

3. Date raportate greșit

   O regulă de filtrare schimbată poate scoate tranzacții din rapoarte, fără niciun mesaj de eroare.

   Verifică: există un istoric al regulilor și cineva compară periodic rapoartele cu datele din sursă.

4. Componente software compromise

   Aplicațiile folosesc biblioteci scrise de alții. Una vulnerabilă îți aduce problema în casă (supply chain attack).

   Verifică: de unde vin componentele și dacă primesc actualizări de securitate.

5. Parole și chei de acces furate

   Cu o cheie de acces furată (token API), atacatorul poate face tot ce permite cheia respectivă.

   Verifică: cheile sunt păstrate în siguranță și schimbate periodic, iar conturile folosesc autentificare în doi pași.

   Pentru conturile Microsoft, renunțarea la MFA prin SMS este un pas concret în aceeași direcție.

6. Un singur punct de eșec

   Dacă totul depinde de un singur server sau de un singur om, orice problemă acolo oprește firma.

   Verifică: există copii ținute separat și instrucțiuni scrise de recuperare.

   Un server care se oprește brusc la o pană de curent poate pierde date, așa că verifică și cât rezistă echipamentele pe un UPS.

7. Ransomware

   Un atacator cu drepturi suficiente îți poate cripta fișierele și cere bani ca să le deblocheze.

   Verifică: backup-ul este ținut separat și protejat, iar restaurarea a fost testată.

8. Nu se știe cine ce a schimbat

   Fără jurnale de activitate, nu poți afla cine a modificat o setare și când.

   Verifică: modificările sunt înregistrate, iar jurnalele nu pot fi șterse de oricine.

Ce faci când tabloul de bord merge, dar datele sunt greșite?

Acesta este riscul cel mai greu de văzut. Un exemplu: un programator schimbă din greșeală o regulă de filtrare și o parte din tranzacții dispar din rapoarte. Aplicația merge și nu apare nicio eroare. Conducerea ia decizii pe cifre incomplete, iar firma observă abia după două săptămâni.

Soluția este o verificare simplă, făcută regulat: compari cifrele din raport cu cele din sistemele din care vin datele. Specialiștii o numesc reconcilierea datelor. Dacă cifrele nu se potrivesc, afli în câteva zile.

Backup sau plan de recuperare: care este diferența?

Backup înseamnă că ai o copie a datelor. Planul de recuperare (disaster recovery) înseamnă că știi cum repornești aplicația din acea copie, cine o face și cât durează. Poți avea primul fără al doilea.

Două cifre te ajută să stabilești de ce ai nevoie:

• RPO: câte ore de date îți permiți să pierzi.
• RTO: în cât timp trebuie să meargă din nou aplicația.

De exemplu, un RPO de o oră și un RTO de patru ore înseamnă backup cel puțin o dată pe oră și o restaurare care durează sub patru ore. Afli dacă te încadrezi doar făcând un test.

Dacă nu ai decis încă unde păstrezi copiile, vezi când merită un NAS și când cloud-ul.

Cine controlează codul și accesul la aplicație?

Dacă aplicația a fost făcută de un angajat sau de o firmă externă, află unde este codul și cine are parola de administrator. Contul principal trebuie să fie al firmei, iar parola să nu fie știută de un singur om.

Dacă lucrezi cu un furnizor extern, trece în contract cine deține codul și cine răspunde de recuperare.

Două reguli simple reduc mult riscul:

• Drepturi minime: fiecare om primește doar accesul de care are nevoie.
• Patru ochi: o schimbare importantă este verificată de altcineva înainte să ajungă în aplicația folosită zilnic.

7 întrebări pentru echipa ta IT

Nu trebuie să fii specialist ca să le pui. Dacă primești „nu” sau „nu știu” la mai mult de două, merită o verificare mai atentă.

• Avem o listă la zi cu cei care au drept de administrator?
• Codul aplicației este într-un cont care aparține firmei?
• Putem vedea ce s-a schimbat și putem reveni la varianta dinainte?
• Schimbările importante sunt verificate de a doua persoană?
• Backup-ul este ținut separat, astfel încât să nu poată fi șters odată cu sistemul principal?
• Când am testat ultima oară o restaurare și cât a durat?
• Compară cineva rapoartele cu datele din sursă?

Dacă vrei să vezi cum se leagă serverul, backup-ul, rețeaua și alimentarea într-un singur plan, citește ghidul nostru de infrastructură IT pentru firme mici.

Lista este orientativă și nu înlocuiește un audit de securitate.

Întrebări frecvente

Este suficient să am backup?

Nu. Backup-ul trebuie ținut separat și testat. O copie pe care nu o poți restaura nu te ajută.

Poate un angajat să șteargă toată aplicația?

Da, dacă are drepturi de administrator și nimic nu îl oprește. De aceea limitezi drepturile și ții backup-ul separat.

Ce este un backup care nu poate fi modificat?

Este o copie pe care nimeni nu o poate schimba sau șterge o perioadă stabilită (immutable backup). Te apără atunci când un atacator încearcă să distrugă și copiile.

Ce se întâmplă dacă pleacă omul care a făcut aplicația?

Dacă firma are codul, documentația și conturile, altcineva o poate prelua. Dacă nu, depinzi de o singură persoană.

Cât de des testez restaurarea?

Depinde de cât de importantă este aplicația. Ca punct de plecare: o dată pe an și după fiecare schimbare mare.

Este suficient un antivirus?

Nu. Antivirusul oprește o parte din atacuri. Nu te ajută dacă cineva șterge date din greșeală sau dacă backup-ul nu poate fi restaurat.

Citește și: Cybersecurity și AI pentru IMM-uri: 7 măsuri esențiale · NIS2 pentru firme în România