Īsi sakot: Līgumam ar IT pakalpojumu sniedzēju drošība nav jāpiemin tikai garāmejot, bet konkrēti jāregulē: kas kuras komponentes atjaunina, kādā termiņā un ar kādu pierādījumu, kā tiek ziņots par kritiskām ievainojamībām, kas incidenta gadījumā piedalās, kā glabā žurnālus un pārvalda piekļuves un kas notiek izstājoties. Šī lapa dod vispārīgas norādes un nav juridiska konsultācija; līgumus pārbauda jurists.
Jautājums, ko uzdeva PHP2Shell: kas ir atbildīgs?
- gada 21. oktobrī plkst. 16.00 pēc Vācijas laika PHP projekts publicēja ielāpus. BSI (Vācijas Federālais informācijas drošības birojs) ieteica nekavējoties atjaunināt vai, kur tas nebija iespējams, tīmekļa serverus uz laiku atvienot no tīkla. Daudzos uzņēmumos pēc tam sākās nevis darbs, bet atbildības meklēšana. Aģentūra norādīja uz hostinga sniedzēju, hostinga sniedzējs uz līgumu, un līgumā bija rakstīts „apkope pēc darba apjoma".
Šādas nepilnības līgumos nav atsevišķs gadījums. Daudzi līgumi ar aģentūrām un pakalpojumu sniedzējiem tika noslēgti, kad runa bija par vietnes izveidi, nevis par tās drošu darbību gadiem ilgi. Kritiska ievainojamība PHP izpildes vidē, kas neskar ne CMS, ne lietojumprogrammas kodu, tad viegli iekrīt starp visiem krēsliem.
Kas IT pakalpojumu sniedzēja līgumam par drošību jānosaka
Turpmākais pārskats min punktus, kas praksē izrādījušies svarīgi. Tas neaizstāj juridisku pārbaudi, bet palīdz atpazīt nepilnības esošajā līgumā.
| Regulējuma punkts | Kas jāfiksē | Saistība ar PHP2Shell |
|---|---|---|
| Pakalpojuma apjoms | kuri slāņi tiek uzturēti: operētājsistēma, PHP izpildes vide, tīmekļa serveris, CMS, spraudņi, savs kods | PHP izpildes vides uzskaitījumā bieži trūka |
| Atjauninājumu termiņi | iedalīti pēc smaguma pakāpes, ar izņēmuma noteikumu ārkārtas gadījumiem | kritiska ievainojamība ar CVSS v4.0 9.2 |
| Pārstartēšana un pierādījums | atjauninājumi skaitās pabeigti tikai pēc visu procesu pārstartēšanas, ar rakstveida apliecinājumu | jauni faili vien ievainojamību neaizver |
| Informēšana | aktīvs paziņojums par kritiskām ievainojamībām, ar novērtējumu un plānu | daudziem klientiem bija jāvaicā pašiem |
| Līdzdalība incidentos | atbalsts analīzē, nodrošināšanā, atjaunošanā, kontaktpersona | pēdu meklēšana pēc ielāpa |
| Žurnāli | veids, glabāšana, izsniegšana pēc pieprasījuma | speciālistu prese ieteica žurnālus saglabāt no 20.10. |
| Piekļuves | personiski konti, divu faktoru pieteikšanās, visu piekļuvju saraksts | kam vispār bija piekļuve? |
| Apakšuzņēmēji | kas vēl iesaistīts, informēšana par maiņu | hostinga sniedzēja hostinga sniedzējs |
| Programmatūras dzīves beigas | brīdinājums savlaicīgi pirms atbalsta beigām, migrācijas plāns | PHP 8.2 atbalsts beidzas 31.12.2026 |
| Izstāšanās | datu, dokumentācijas un piekļuvju nodošana, tiesību atņemšana | maiņa pēc incidenta |
Termiņi un pierādījumi: punkti, kas svarīgi visvairāk
Termiņi ir kodols. Formulējums, piemēram, „laikus", ārkārtas gadījumā nepalīdz. Vienojieties par termiņiem atsevišķi pēc smaguma pakāpes un nosakiet, pēc kā smaguma pakāpi mēra, piemēram, pēc ražotāja vai BSI klasifikācijas. Ārkārtējām situācijām jābūt ārkārtas noteikumam: kas ir sasniedzams, kas lemj, vai sistēma uz laiku tiek atvienota no tīkla, un kā tiek norēķināts par papildu darbu.
Tikpat svarīgs ir pierādījums. PHP2Shell gadījumā parādītais versijas numurs bieži maz pateica, jo distributīvi un hostinga sniedzēji labojumus ievieš kā backport. Noturīgs pierādījums nosauc pakotnes stāvokli, instalēšanas brīdi un visu PHP procesu pārstartēšanu. Kuras norādes tieši ir svarīgas, apraksta Kā pajautāt hostinga sniedzējam par ielāpa statusu. Iekļaujiet šīs norādes līgumā kā obligātu saturu.
Lieciet pakalpojumu sniedzējam pie līguma pievienot uzdevumu matricu: viena rinda katrai komponentei, viena kolonna katram uzdevumam, katrā šūnā vārds. Nepilnības tad tūlīt redzamas, ilgi pirms atnāk nākamais paziņojums.
Piekļuves, apakšuzņēmēji un izstāšanās
Pakalpojumu sniedzējiem vajadzīgas piekļuves, un tieši tās ir biežs uzbrukuma ceļš. Nosakiet, ka katra persona saņem savu kontu, ka divu faktoru pieteikšanās ir obligāta, kur tehnika to atļauj, un ka jebkurā laikā varat pieprasīt aktuālu visu piekļuvju sarakstu. Aizgājušie pakalpojumu sniedzēja darbinieki laikus jānoņem no visām sistēmām.
Ja pakalpojumu sniedzējs pats strādā ar partneriem, piemēram, datu centru vai specializētu forensikas komandu, jums tas jāzina. Ja kāds no šiem partneriem apstrādā personas datus, klāt nāk datu aizsardzības tiesību pienākumi. Vairāk par to rakstā Datu apstrāde uzdevumā, ja pakalpojumu sniedzēji piekļūst serverim.
Izstāšanos līguma slēgšanas brīdī aizmirst visbiežāk. Fiksējiet, ka līguma beigās dati, konfigurācija, dokumentācija un piekļuves dati tiek nodoti pilnībā, visas pakalpojumu sniedzēja piekļuves tiek atņemtas un tas tiek apstiprināts rakstveidā. Tieši pēc incidenta sakārtota maiņa citādi ir grūta.
Esošo līgumu pārbaude: kā rīkoties
Visus līgumus no jauna pārrunāt nav jāvajag. Sākumam pietiek ar pragmatisku gaitu:
- Savākt visus līgumus ar aģentūrām, hostinga un IT pakalpojumu sniedzējiem, kas skar vietnes vai serverus.
- Katru līgumu salīdzināt ar iepriekšējo tabulu un atzīmēt atklātos punktus.
- Svarīgākās nepilnības rakstveidā apspriest ar pakalpojumu sniedzēju, sākot ar pakalpojuma apjomu, termiņiem un pierādījumu.
- Rezultātus fiksēt kā papildu vienošanos un likt juridiski pārbaudīt.
- Uzdevumu matricu pārņemt ārkārtas rīcības plānā.
Uzņēmuma vadībai šis solis ir arī rūpības jautājums. Kas skaidri nosaka atbildības un dokumentē lēmumus, tas ir labākā pozīcijā, ja vēlāk tiek uzdoti jautājumi. Fonu piedāvā Uzņēmuma vadības atbildība par IT drošības nepilnībām. Tipisko uzdevumu sadali uzturētiem serveriem apraksta Pārvaldīts serveris: atbildības noskaidrošana.
Kā PHP SOS palīdz konkrēti?
- Mēs izlasām jūsu esošos līgumus un pakalpojumu aprakstus no tehniskā viedokļa un atzīmējam, kuru komponenšu un uzdevumu trūkst.
- Mēs izveidojam uzdevumu matricu visām vietnēm un serveriem, ko varat saskaņot ar saviem pakalpojumu sniedzējiem.
- Mēs formulējam tehniskās prasības termiņiem, pierādījumiem un ziņošanas ceļiem, ko jūsu jurists var pārņemt līgumā.
- Kur neviens nav atbildīgs, mēs uzdevumus uzņemamies paši ar drošības uzturēšanas līgumu ar skaidri aprakstītu apjomu.
Secinājums: Labs līgums nenovērš drošības nepilnību, bet novērš, ka ārkārtas gadījumā laiks tiek zaudēts jautājumam par atbildību. Šī lapa ir vispārīga informācija un nav juridiska konsultācija.
Biežāk uzdotie jautājumi
Vai IT pakalpojumu sniedzējam drošības atjauninājumi jāievieš bez pasūtījuma?
Tas atkarīgs no līguma. Bez skaidra regulējuma bieži ir strīdīgi, vai atjauninājumi pieder pie nodrošināmā pakalpojuma. Tāpēc līgumā nepārprotami jānosaka, kas kuras komponentes atjaunina un kādā termiņā. Juridiskajam novērtējumam atsevišķā gadījumā atbildīgs ir jurists.
Vai man papildus vajadzīgs AVV?
Ja pakalpojumu sniedzējs uzdevumā apstrādā personas datus vai var tiem piekļūt, parasti nepieciešams datu apstrādes līgums pēc VDAR 28. panta. Tas neaizstāj pakalpojumu līgumu, bet to papildina. Noskaidrojiet to ar savu datu aizsardzības speciālistu.
Kādi termiņi drošības atjauninājumiem ir ierasti?
Fiksētu vērtību nav. Lietderīgs ir iedalījums pēc smaguma pakāpes, piemēram, atsevišķi termiņi kritiskām, augstām un pārējām ievainojamībām. Svarīgi, lai termiņi ir rakstveidā un ietver izņēmuma noteikumu ārkārtas gadījumiem, piemēram, PHP2Shell.
Kas notiek ar piekļuvēm, kad līgums beidzas?
To vajadzētu noteikt līgumā: datu atdošana vai dzēšana, piekļuves datu un dokumentācijas nodošana, visu pakalpojumu sniedzēja piekļuvju atņemšana un apstiprinājums par to.