Kui Drupal moodul märgitakse turvariski tõttu mittetoetatuks

🎧 Kuula kõiki artikleid järjest

19. augustil 2026 oli Drupal.org turvalehel mitu contrib-projekti, mille turvatiim märkis turvariski tõttu mittetoetatuks. Selline teade ei tähenda ainult järjekordset uuendust. See tähendab, et saidiomanik peab teadma, kas moodul on tema saidil kasutusel ja mida teha siis, kui parandust ei ole.

Augustis 2026 avaldas Drupal.org turvateadete leht↗ (avaneb uues aknas) mitu teadet, kus contrib-projekt märgiti turvariski tõttu mittetoetatuks. Näited olid Screenshot, Link content parser ja Gammu SMS Daemon. Nädal varem olid turvateadetes ka Quick Tabs, External Authentication, Entity Share Websub, Diff ja Commerce PayPal.

Kõik need moodulid ei puuduta iga Drupal-saiti. Mõni on väga spetsiifiline. Mõni risk rakendub ainult kindla seadistuse või õigustega kasutaja puhul.

Ohtlik on hoopis see, kui saidiomanik ei tea, kas selline moodul on tema saidil kasutusel.

Unsupported ei tähenda lihtsalt vana moodulit

Drupal.org kasutab turvateadetes sõna "unsupported" siis, kui projekt ei saa enam tavapärast turvatuge. Kui teates öeldakse, et projekt märgitakse turvariski tõttu mittetoetatuks, on olukord tõsisem kui tavaline vananenud moodul.

Tavapärase turvauuenduse puhul on töövoog selge:

• loed turvateadet;
• uuendad mooduli parandatud versioonile;
• käivitad andmebaasiuuendused, kui neid on;
• tühjendad cache'i;
• testid peamised töövood;
• avaldad muudatuse.

Unsupported-teate puhul võib parandatud versiooni üldse mitte olla. See muudab küsimuse tehnilisest uuendusest riskijuhtimise otsuseks.

Kõige halvem vastus on "ootame ja vaatame". Kui moodulil on teadaolev turvarisk ning projekt ei saa enam turvatuge, ei ole ootamine hooldusplaan.

Esimene küsimus: kas moodul on saidil tegelikult kasutusel?

Ära alusta mooduli kustutamisest. Alusta inventuurist.

Kontrolli:

• kas moodul on composer.json või composer.lock failis;
• kas moodul on Drupal adminis sisse lülitatud;
• kas seda kasutatakse konfiguratsioonis, väljatüübis, vaates, plokis, vormis või integratsioonis;
• kas mooduli funktsioon on avalikus veebis nähtav või ainult admin-liideses;
• millised rollid saavad seda funktsiooni kasutada;
• kas moodul salvestab oma andmeid eraldi tabelitesse.

Mõnikord on moodul koodibaasis alles, kuid ei ole enam sisse lülitatud. Mõnikord on ta sisse lülitatud, aga tegelik funktsioon on aastaid kasutamata. Mõnikord on ta nähtamatu, kuid seotud olulise töövooga: sisu import, makse, autentimine, väljade kuvamine või sisutoimetaja abivahend.

Alles pärast seda saab otsustada, kas risk on kriitiline või piiratud.

Teine küsimus: kas risk jõuab päris kasutajani?

Turvateate kriitilisus ei ole sama mis konkreetse saidi risk.

Näiteks võib ligipääsu vea risk olla väga tõsine saidil, kus anonüümne kasutaja näeb või muudab andmeid. Sama moodul võib olla vähem kriitiline saidil, kus funktsioon on kasutusel ainult piiratud admin-rolliga.

SSRF-i risk on teine näide. Kui moodul võtab vastu URL-e ja teeb serverist päringuid, võib probleem puudutada mitte ainult Drupalit, vaid ka sisemist võrku, pilveteenuseid ja serveri metaandmeid.

Seetõttu tuleb küsida:

• kas rünnak eeldab sisselogimist;
• kas rünnak eeldab kindlat rolli;
• kas haavatav funktsioon on avalikult kättesaadav;
• kas moodul puutub kokku kasutaja sisendiga;
• kas moodul teeb serveripoolseid päringuid;
• kas viga võib mõjutada andmeid, makseid, kontosid või privaatseid faile.

See ei ole juristi ega turunduse küsimus. See on tehniline kontroll, mida peab tegema inimene, kes tunneb konkreetset saiti.

Kolm võimalikku lahendust

Kui moodul on saidil kasutusel ja teade on relevantne, on tavaliselt kolm teed.

Uuenda, kui parandatud versioon on olemas. Mõne turvateate puhul on olemas uus versioon. Siis on töö tavapärane: uuendus tehakse testkeskkonnas, kontrollitakse töövood ja alles seejärel viiakse muudatus live'i. Drupal.orgi ametlik moodulite ja teemade Composeriga uuendamise juhis↗ (avaneb uues aknas) kirjeldab põhisamme: composer update, drush updatedb, drush cache:rebuild ja composer audit.

Eemalda või lülita välja, kui funktsiooni enam ei kasutata. See on sageli kõige puhtam lahendus. Enne eemaldamist tuleb aga kontrollida konfiguratsiooni ja andmeid. Drupal mooduli väljalülitamine võib eemaldada väljatüübi, plokiliigi või integratsiooni, mida mõni leht veel kasutab.

Asenda moodul teise lahendusega. Kui funktsioon on vajalik, aga moodulil ei ole turvalist tulevikku, tuleb otsida alternatiiv. See võib olla teine contrib-moodul, väike custom-moodul või ärinõude muutmine. Mõnikord on odavam muuta töövoogu kui hoida riskantset sõltuvust elus.

Hea otsus sõltub saidist. Sama turvateade võib ühe projekti jaoks tähendada 30-minutilist eemaldamist ja teise jaoks mitmepäevast asendustööd.

Ära paranda tootmises pimesi

Turvariskiga mooduli puhul on surve kiiresti tegutseda. Kiirus on oluline, aga pime muudatus live'is võib rikkuda sama kriitilise töövoo, mida üritad kaitsta.

Miinimumprotsess peaks olema:

1. Tuvasta moodul ja versioon.
2. Kontrolli, kas moodul on sisse lülitatud ja kasutusel.
3. Loe turvateadet ning vaata, millistel tingimustel risk rakendub.
4. Tee varukoopia.
5. Tee muudatus testkeskkonnas.
6. Käivita andmebaasiuuendused ja cache'i tühjendus.
7. Testi avalik vaade, admin-liides ja mooduliga seotud töövood.
8. Planeeri tootmiskeskkonna muudatus.
9. Dokumenteeri, mis tehti ja miks.

Kui testkeskkonda, varukoopiat või versioonihaldust ei ole, on see eraldi probleem. Sellisel juhul ei ole küsimus ainult ühes moodulis. Küsimus on selles, kas Drupal saiti saab üldse turvaliselt hooldada.

Mida saidiomanik peaks arendajalt küsima?

Kui saad teate, et mõni Drupal moodul on turvariski tõttu unsupported, küsi arendajalt või hoolduspartnerilt konkreetseid vastuseid:

• Kas see moodul on meie saidil olemas?
• Kas see on sisse lülitatud?
• Milline funktsioon sellest sõltub?
• Kas turvarisk puudutab meie seadistust?
• Kas olemas on parandatud versioon?
• Kui parandust ei ole, kas eemaldame, asendame või piirame riski ajutiselt?
• Millal muudatus testitakse ja avaldatakse?
• Kuidas kontrollime pärast muudatust, et vormid, õigused ja sisutöövood töötavad?

Vastus "vaatame järgmises uuendusringis" ei ole piisav, kui teade puudutab aktiivset ja haavatavat funktsiooni.

Kuidas selliseid olukordi ennetada?

Kõiki contrib-moodulite riske ei saa ette näha. Küll aga saab vähendada olukordi, kus üks vana moodul hoiab kogu saiti pantvangis.

Praktiline ennetus:

• ära paigalda moodulit ühe väikese mugavuse pärast ilma hooldatavust hindamata;
• kontrolli enne kasutuselevõttu Security Advisory Coverage infot;
• hoia moodulite nimekiri lühike ja põhjendatud;
• eemalda kasutamata moodulid, mitte ainult ära lülita neid välja;
• dokumenteeri, milline ärifunktsioon iga olulisema mooduli taga on;
• tee regulaarselt composer audit kontrolli;
• hoia testkeskkond ja varukoopiad töökorras;
• kontrolli mooduliriske enne Drupal 10, 11 või 12 uuendust.

Meil on eraldi artikkel ka sellest, kuidas hinnata, kas Drupal moodul on mahajäetud või riskantne. Unsupported-turvateade on sellest järgmine aste: risk ei ole enam teoreetiline, vaid ametlikult nähtav.

WebPro soovitus

Kui Drupal.org märgib kasutusel oleva mooduli turvariski tõttu mittetoetatuks, käsitle seda hooldustööna, mitte uudisena, mille võib kõrvale panna.

Väikese saidi puhul võib lahendus olla lihtne: moodul eemaldada, konfiguratsioon puhastada ja töövood üle kontrollida. Suurema platvormi puhul võib olla vaja tehnilist auditit, sest üks moodul võib olla seotud õiguste, sisumudeli, integratsioonide või andmetega.

WebPro kontrollib selliseid riske Drupal hoolduse ja tehnilise auditi käigus. Kui pole selge, millised moodulid saidil töötavad, alusta Drupal auditist või lase koodibaas ja Composer-sõltuvused üle vaadata.

Turvateate mõte ei ole paanikat tekitada. Selle mõte on anda võimalus tegutseda enne, kui teadaolevast probleemist saab päris intsident.

WebPro Company OÜ Tehniline juht: Kaido Toomingas

Vajad Drupal abi?

Kui artikkel puudutab sinu olukorda, ei pea kõike lõpuni lugema. Sinuga suhtleb päris inimene ja aitab järgmise sammuni jõuda.

Võta ühendust