AETHER
Gauti auditą

8 KSRA reikalavimų blokai paaiškinti paprastai

Paskutinį kartą atnaujinta: 2026 m. balandžio 23 d.

KSRA (Kibernetinio saugumo reikalavimų aprašas) — 100+ puslapių dokumentas, kurio pilną perskaitymą atliko nedaugelis. Bet struktūriškai KSRA susideda iš 8 pagrindinių blokų, kurie atitinka NIS2 direktyvos 21 straipsnio 2 dalies reikalavimus. Šiame straipsnyje — kiekvieno bloko paaiškinimas paprastais žodžiais, konkrečios priemonės ir patarimai, nuo ko pradėti.

1. Valdymas (KSRA 5–30)

Ką tai reiškia: įmonė turi turėti aiškią kibernetinio saugumo valdymo struktūrą — kas už ką atsakingas, kas patvirtina sprendimus, kokia yra politika.

Konkrečios priemonės:

  • Paskirtas atsakingas asmuo — ne būtinai full-time CISO, bet dokumentuotas įpareigojimas (pvz. „IT vadovas yra atsakingas už kibernetinį saugumą pagal direktoriaus 2026-01-15 įsakymą Nr. 12")
  • Kibernetinio saugumo politika — 10–30 puslapių dokumentas, patvirtintas valdybos (arba direktoriaus) posėdžio protokolu. Aprašo principus, rolių paskirstymą, bendrą kryptis.
  • Metinė peržiūra — politika ir struktūra peržiūrima bent kartą per metus, rezultatai dokumentuojami.

Nuo ko pradėti:paskirkite asmenį + parašykite 2–3 puslapių politikos draft'ą. Ne tobulai iš pirmo karto — tobulinsite su laiku.

2. Rizikos valdymas (KSRA 15–22)

Ką tai reiškia: įmonė turi sistematiškai identifikuoti, įvertinti ir valdyti kibernetinio saugumo rizikas.

Konkrečios priemonės:

  • Rizikų registras — lentelė su tokiais stulpeliais: rizikos aprašymas, tikimybė (1–5), poveikis (1–5), bendra reikšmė (tikimybė × poveikis), mitigacijos priemonė, atsakingas, terminas.
  • Metodika — trumpas dokumentas (2–3 puslapiai), kuris aprašo, kaip jūs identifikuojate rizikas, kaip vertinate, kaip priimate sprendimus dėl mitigacijos.
  • Peržiūra — registras atnaujinamas bent kartą per metus, taip pat kai įvyksta svarbūs pasikeitimai (naujos sistemos, naujas incidentas ir pan.).

3. Žmogiškieji ištekliai (KSRA 45–55)

Ką tai reiškia: darbuotojai — didžiausia kibernetinio saugumo rizika. Jiems reikia mokymų ir aiškių procedūrų.

Konkrečios priemonės:

  • Kibernetinės higienos mokymai — kasmet, dokumentuotas dalyvavimas. Turinys: phishing, slaptažodžių politika, BYOD, remote work, social engineering, duomenų klasifikacija.
  • Phishing pratybos — bent 2 kartus per metus. Automatizuotos platformos (KnowBe4, Cofense, Proofpoint) arba rankinis scenarijus.
  • Incidentų pranešimo kultūra — darbuotojai žino, kur pranešti apie įtartiną veiklą (el. pašto adresas, Slack kanalas). Jokio baudimo už pranešimą — skatinama.
  • Onboarding + offboarding procedūros — aiškūs procesai prieigos suteikimui ir panaikinimui, kai darbuotojas pradeda arba baigia.

4. Tiekimo grandinė (KSRA 33–38)

Ką tai reiškia: IT tiekėjai (cloud, MSP, programinė įranga) yra jūsų saugumo dalis. Jei juos pažeidžia, jūsų duomenys irgi rizikuoja.

Konkrečios priemonės:

  • Tiekėjų saugumo vertinimas — klausimynas prieš sutartį: ar turi ISO 27001? SOC 2? Kur saugomi duomenys? Kokia incidentų pranešimo tvarka? Subprocessorių sąrašas?
  • Saugumo sąlygos sutartyse — aiškios sąlygos dėl incidentų pranešimo (pvz. per 24 val.), teisę į auditą, duomenų grąžinimo/ištrynimo procedūras sutarties pabaigoje.
  • Reguliari peržiūra — bent kartą per metus tikrinama, ar tiekėjai atnaujino savo saugumo standartus.
  • Žemiausių privilegijų principas — tiekėjai gauna tik tas prieigas, kurios būtinos paslaugai teikti.

5. Prieigos kontrolė (KSRA 60–63)

Ką tai reiškia: kas gali prisijungti prie ko, kada ir kaip. Tai yra vienas iš didžiausių „low-hanging fruit" blokų — greitas pagerinimas su palyginti mažomis investicijomis.

Konkrečios priemonės:

  • MFA visoms paskyroms — ne tik administratoriams. Bet kuri paskyra su prieiga prie įmonės svarbių sistemų turi turėti antrą faktorių (Authenticator app, hardware key, SMS tik kaip fallback).
  • Stipri slaptažodžių politika — 12+ simbolių, ne žodyno žodis, nenaudotas kitur, keičiamas tik kai yra įrodymas apie kompromitavimą (ne kas 90 dienų — tai atgyvenęs standartas).
  • Prieigos teisių registras — kas turi kokias teises kurioje sistemoje. Ketvirtinė peržiūra: ar dar reikia? ar darbuotojas dar turi tą rolę?
  • Žemiausių privilegijų principas — kiekvienas gauna minimum reikalingą prieigą, ne „visi admin, nes patogu".

6. Kriptografija (KSRA 65–67)

Ką tai reiškia: duomenys turi būti šifruojami tiek saugojimo metu (at-rest), tiek perdavimo metu (in-transit).

Konkrečios priemonės:

  • TLS 1.2+ visur— jokio HTTP jūsų viešai prieinamuose endpoint'uose. TLS 1.0/1.1 — išjungti (legacy, pažeidžiami).
  • At-rest šifravimas — diskų lygio (BitLocker, LUKS), DB lygio (Supabase/Postgres turi default'u), failų sistemų lygio (S3 SSE).
  • Raktų valdymas — dokumentuota tvarka, kaip generuojami, saugomi, rotuojami, naikinami kriptografiniai raktai. HSM arba cloud KMS (AWS KMS, Azure Key Vault).
  • Nenaudokite atgyvenusių algoritmų — MD5, SHA-1, RC4, DES. Šiandienos minimumas: SHA-256, AES-256-GCM, RSA-2048+.

7. Tinklo ir sistemų saugumas (KSRA 70–72)

Ką tai reiškia: tinklo infrastruktūra, operacinės sistemos, programinės įrangos pataisymai ir endpoint apsauga.

Konkrečios priemonės:

  • Patch management — kritinės pataisos per 72 val. nuo CVE išleidimo. Priklauso nuo automatizacijos — WSUS (Windows), Ansible, Satellite (RHEL), arba centrally managed MDM.
  • Tinklo segmentacija — production ≠ test aplinka, admin tinklas atskirtas, DMZ aiškiai apibrėžtas. VLAN'ai, firewall'ų politikos.
  • EDR (Endpoint Detection and Response) — centralizuotai valdomas antivirus/EDR. Market standartas: CrowdStrike Falcon, SentinelOne, Microsoft Defender for Endpoint.
  • Loginimas ir stebėjimas — centralizuotas žurnalų valdymas (SIEM/Graylog/ELK), peržiūros procedūros, anomalijų identifikacija.

8. Incidentų valdymas (KSRA 8 skirsnis)

Ką tai reiškia: kai įvyksta saugumo incidentas, įmonė turi žinoti, ką daryti, kas ką daro, ir kada pranešti NKSC.

Konkrečios priemonės:

  • Incidentų valdymo planas — dokumentuotas, su aiškiais vaidmenimis (IC/incident commander, komunikacija, techninis atsakas, teisinis atsakas).
  • Pranešimas NKSC: pirminis per 24 val., detalus per 72 val.. Formos yra NKSC svetainėje. Pranešimo praleidimas — atskira bauda.
  • Tabletop exercise— bent kartą per metus. Komanda simuliuoja incidentą pagal scenarijų, testuoja sprendimus be realaus pavojaus. Tai yra rimčiausias compliance'o priemonė — dažnai atskleidžia dokumentacijos spragas.
  • Atsarginės kopijos (3-2-1 principas) — 3 kopijos, 2 skirtingos laikmenos, 1 off-site. Bent dalis — offline arba air-gapped, kad išgyventų ransomware.
  • Post-incident review — po incidento pildoma analizė: kas įvyko, kodėl, ką keisime, kad nebepasikartotų.

Prioritizacija — nuo ko pradėti?

Mūsų rekomendacija 100–500 darbuotojų įmonei:

  1. Blokas 1 (Valdymas) — be atsakingo asmens niekas nejuda. Pradėkite čia, pirmas mėnuo.
  2. Blokas 5 (Prieigos kontrolė) — MFA yra vienas didžiausių grąžų/kaštų santykis. Jei neturite — įdiekite pirmiau.
  3. Blokas 2 (Rizikos) — be rizikų registro kiti blokai neturi konteksto. Antras prioritetas.
  4. Blokas 8 (Incidentai) — kartu su blokas 2, nes incidentų plano pagrindas — rizikų analizė.
  5. Blokai 3, 4, 6, 7 — palaipsniui per 12–24 mėn., pagal biudžeto ir komandos galimybes.

Nori konkretaus plano savo įmonei?

AETHER auditas per 48 val. pateikia gap'o analizę pagal šiuos 8 blokus, prioritetus, terminus ir biudžeto įvertinimą. Pirmi 5 klientai — nemokamai.

Užsiregistruok arba skaityk, kaip veikia auditas.

Susiję straipsniai ir resursai

Autorius: Aleksandras (Azora Lab). Straipsnis informacinis — ne teisinė konsultacija. Konkrečios priemonės parinktinos pagal įmonės kontekstą.