# WordPress drošības kontrolsaraksts: praktiska nostiprināšana vietņu īpašniekiem un izstrādātājiem > Uz prevenciju vērsts WordPress drošības kontrolsaraksts, kas aptver atjauninājumus, piekļuves kontroli, dublējumkopijas, konfigurācijas nostiprināšanu, uzraudzību un brīdi, kad aizdomas par kompromitēšanu prasa strukturētu reaģēšanu uz incidentu. - Canonical: https://asgru.com/lv/wordpress-drosibas-kontrolsaraksts-praktiska-nostiprinasana-vietnu-ipasniekiem-un-izstradatajiem/ - Language: lv - Author: asgru - Published: 2026-09-15T22:51:25+02:00 - Updated: 2026-09-16T18:14:24+02:00 Lielākā daļa WordPress kompromitēšanas gadījumu nesākas ar eksotisku nulles dienas ievainojamību. Biežāk cēlonis ir ikdienišķs: pamests spraudnis, atkārtoti izmantota parole, atklāts hostinga konts, pārmērīgas atļaujas vai nekad nepārbaudīta dublējuma kopija. Šis WordPress drošības kontrolsaraksts ir vērsts uz profilaksi. Tajā skaidrots, kā samazināt kompromitēšanas iespējamību, ierobežot nozagta konta radīto kaitējumu un saglabāt iespēju atjaunot vietni, ja aizsardzības pasākumi neizdodas. Ja vietne jau novirza apmeklētājus, sūta aizdomīgus e-pastus, rāda nezināmus administratoru kontus vai izraisa pārlūkprogrammas vai meklētājprogrammas brīdinājumus, uzskatiet to par aktīvu incidentu, nevis ikdienas uzturēšanu. Pirms tīrīšanas mēģinājuma saglabājiet pierādījumus un izmeklējiet cēloni. ## Sāciet ar precīzu inventarizāciju WordPress vietni nevar aizsargāt, ja nevienam nav uzticama priekšstata par to, kas darbojas, kam ir piekļuve un kur tiek glabāti kritiskie piekļuves dati. Inventarizācija bieži atklāj patiesos riskus: aizmirstu testa kopiju, spraudni, kas instalēts vienreizējai kampaņai, vecu darbuzņēmēja kontu vai domēna reģistratora kontu, ko kontrolē viens darbinieks. Pirms iestatījumu mainīšanas fiksējiet šādu informāciju: - WordPress kodola versija, aktīvā tēma, bērntēma un instalētie spraudņi; - katra spraudņa un tēmas mērķis, īpašnieks un atjaunināšanas statuss; - WordPress administratora, hostinga, domēna reģistratora, DNS, SFTP/SSH, datubāzes, dublējumkopiju, e-pasta pakalpojuma un maksājumu pakalpojumu sniedzēja konti; - vietnes produkcijas, testa, izstrādes un vecās migrētās kopijas; - dublējumkopiju atrašanās vieta, biežums, glabāšanas periods un dokumentēta atjaunošanas procedūra; - trešo pušu integrācijas, API atslēgas, tīmekļa aizķeres, maksājumu pakalpojumi un veidlapu galamērķi. Dzēsiet neaktīvos spraudņus un tēmas, kas vairs nav vajadzīgas. Neaktīvs kods joprojām ir kods serverī: tas var ietvert ievainojamību, tikt nejauši atkārtoti aktivizēts vai apgrūtināt incidenta izmeklēšanu. Vienas aktuālas WordPress noklusējuma tēmas saglabāšana kā rezerves risinājuma ir pamatota; vairāku gadu vecu komerciālo tēmu paturēšana parasti nav. ## 1. Izveidojiet atjaunināšanas politiku, kas nerada darbības traucējumus Atjauninājumi ir viens no vērtīgākajiem WordPress drošības kontroles pasākumiem. Taču “nekavējoties atjaunināt visu produkcijas vidē” nav politika. Vietnē ar pielāgotām veidnēm, WooCommerce paplašinājumiem, kešatmiņu vai ārējām integrācijām nepārbaudīts atjauninājums var radīt cita veida incidentu. Praktisks atjaunināšanas process izskatās šādi: - Pārliecinieties, ka aktuālā dublējumkopija ir pilnīga un atjaunojama. - Pārskatiet apjomu: WordPress kodols, spraudņi, tēmas, PHP un servera programmatūra ir atsevišķi slāņi. - Uzņēmējdarbībai kritiskās vai pielāgotās vietnēs vispirms ieviesiet izmaiņas testa vidē. - Pārbaudiet svarīgos lietotāju ceļus: pieteikšanos, veidlapas, meklēšanu, norēķināšanos, maksājumu atzvanus, klientu kontus un pielāgotās integrācijas. - Ieviesiet izmaiņas produkcijas vidē un pārskatiet lietojumprogrammas un servera žurnālus, lai konstatētu jaunas kļūdas. WordPress mazākās versijas laidieni parasti ir paredzēti tūlītējai ieviešanai, jo īpaši, ja tajos ir drošības labojumi. Lielie WordPress laidieni, spraudņu atjauninājumi un PHP jauninājumi sarežģītās vietnēs prasa saderības pārbaudi. Precīzs biežums ir atkarīgs no vietnes, taču zināmu atjauninājumu neieviešana mēnešiem ilgi reti ir pamatots uzņēmējdarbības lēmums. Tā paša procesa ietvaros pārskatiet PHP atbalstu. WordPress var turpināt darboties vecākā PHP laidienā, taču tas nenozīmē, ka šo laidienu atbalsta PHP uzturētāji vai jūsu hostinga pakalpojumu sniedzējs. Plānojiet PHP jauninājumus kā pārbaudītus uzturēšanas darbus, nevis gaidiet piespiedu hostinga izmaiņas. ## 2. Pirms drošības rīku pievienošanas samaziniet piekļuvi Piekļuves kontrole ir svarīgāka par pieteikšanās URL slēpšanu vai vairāku pārklājošos drošības spraudņu instalēšanu. Tiklīdz uzbrucējam ir derīga administratora parole vai piekļuve e-pasta kontam, ko izmanto paroļu atiestatīšanai, daudzi kosmētiski nostiprināšanas pasākumi sniedz nelielu aizsardzību. ### Izmantojiet individuālus kontus un mazāko nepieciešamo privilēģiju principu Katram cilvēkam jābūt individuālam WordPress kontam. Koplietoti administratoru konti nevajadzīgi apgrūtina piekļuves atcelšanu, atbildības noteikšanu un incidentu izmeklēšanu. Piešķiriet zemāko lomu, kas ļauj personai veikt savu darbu: - Abonents lietotājiem, kuriem nepieciešams tikai konts; - Līdzautors vai Autors ierobežotām publicēšanas darbplūsmām; - Redaktors satura pārvaldībai bez piekļuves visas vietnes konfigurācijai; - Administrators tikai personām, kurām jāpārvalda lietotāji, iestatījumi, spraudņi, tēmas vai kods. Pārskatiet administratoru kontus vismaz reizi ceturksnī un nekavējoties pēc darbinieku, aģentūras vai piegādātāju izmaiņām. Nepazīstams administratora konts ir incidenta signāls, nevis jautājums, ko atlikt līdz nākamajai pārskatīšanai. ### Pieprasiet unikālas paroles un daudzfaktoru autentifikāciju Izmantojiet garas, unikālas paroles, kas glabātas uzticamā paroļu pārvaldniekā. Neizmantojiet WordPress piekļuves datus atkārtoti hostinga, domēna reģistratora, DNS, e-pasta vai citiem pakalpojumiem. E-pastam jāpievērš īpaša uzmanība, jo kontrole pār paroles atiestatīšanas pastkasti var kļūt par kontroli pār vietni. Iespējojiet daudzfaktoru autentifikāciju WordPress administratoriem un hostinga, domēna, DNS un e-pasta kontiem visur, kur pakalpojumu sniedzējs to atbalsta. Piekļuves atcelšanas procesā pārskatiet atkopšanas kodus, atkopšanas e-pasta adreses un reģistrētās ierīces. Daudzfaktoru autentifikācija, kas piesaistīta bijušā darbinieka tālrunim vai neuzraudzītai pastkastei, nav pilnvērtīgs kontroles pasākums. ### Aizsargājiet servera un izvietošanas piekļuvi Atspējojiet kontus, kas vairs nav nepieciešami. Dodiet priekšroku SSH atslēgām, nevis ar paroli balstītai SSH piekļuvei. Ja hostinga platforma to ļauj, izmantojiet atsevišķus kontus un pēc noklusējuma nepiešķiriet neierobežotu piekļuvi produkcijas videi katram izstrādātājam. Datubāzes piekļuves dati, izvietošanas noslēpumi un API atslēgas nedrīkst tikt augšupielādētas publiskās repozitorijās vai sūtītas parastā e-pastā. ## 3. Nostipriniet WordPress konfigurāciju un failu atļaujas Nostiprināšana padara biežākos uzbrukuma ceļus mazāk lietderīgus. Ieviešana ir atkarīga no hostinga un izvietošanas modeļa, tāpēc konfigurācijas izmaiņas pārbaudiet testa vidē un saglabājiet iespēju tās atsaukt. ### Atspējojiet vadības paneļa failu redaktoru produkcijas vidē Pēc noklusējuma WordPress administratori var rediģēt tēmu un spraudņu failus no vadības paneļa. Produkcijas vietnē šī ērtība ir risks: kompromitētu administratora kontu var izmantot, lai tieši mainītu PHP kodu. Pievienojiet šo rindu failā wp-config.php virs rindas, kurā teikts “That’s all, stop editing”: define( 'DISALLOW_FILE_EDIT', true ); Tas atspējo tēmu un spraudņu failu redaktorus WordPress vadības panelī. Tas netraucē parastiem atjauninājumiem un neaizstāj servera drošību. Likumīgas koda izmaiņas veiciet, izmantojot kontrolētu izvietošanas procesu, SFTP vai SSH. ### Izmantojiet atļaujas, lai nodrošinātu īpašumtiesības, nevis apietu kļūdas Aizsargājiet wp-config.php ar jūsu servera iestatījumam piemērotām īpašumtiesībām un atļaujām. Ja hostings to atbalsta, glabājiet sensitīvo konfigurāciju ārpus publiskās dokumentu saknes. Nekopējiet atļauju vērtības akli no pamācības: Apache, PHP-FPM, konteineriem un pārvaldītām WordPress platformām var būt atšķirīgas prasības. Mērķis ir vienkāršs: WordPress un paredzētajam izvietošanas procesam jāspēj lasīt vai modificēt vajadzīgos failus, savukārt nesaistīti lietotāji un procesi to nedrīkst spēt. Neveidojiet failus vai direktorijus rakstāmus visiem lietotājiem tikai atjaunināšanas kļūdas novēršanai. Tas parasti slēpj izvietošanas vai īpašumtiesību problēmu, vienlaikus paplašinot uzbrukuma virsmu. ### Kontrolējiet, kas var ieviest izpildāmu kodu Pārvaldītām produkcijas vietnēm apsveriet darbplūsmu, kurā spraudņu un tēmu instalēšana notiek tikai apstiprinātā laidiena procesā. Tas nav piemērots katrai redakcijas komandai, taču ir vērtīgi situācijās, kur izstrādātāji pārvalda izvietošanu un satura lietotājiem nevajadzētu būt iespējai ieviest jaunu izpildāmu kodu. Darbības noteikums ir svarīgāks par vienu iestatījumu: nosakiet, kas produkcijas vidē var pievienot, atjaunināt un noņemt kodu, un pēc tam skaidri definējiet šo atbildību. ## 4. Aizsargājiet pieteikšanās un lietojumprogrammas ieejas punktus Automatizēti pieteikšanās mēģinājumi publiskās WordPress vietnēs ir ierasti. Lietderīga atbilde ir daudzslāņu kontrole, nevis drošības teātris. - Pieprasiet daudzfaktoru autentifikāciju priviliģētiem kontiem. - Izmantojiet ātruma ierobežošanu vai pieteikšanās mēģinājumu kontroli hostinga, CDN, tīmekļa lietojumprogrammu ugunsmūra vai piemērota WordPress drošības slāņa līmenī. - Izmantojiet CDN vai tīmekļa lietojumprogrammu ugunsmūri, ja to pamato vietnes datplūsma un pakļautība riskiem, jo īpaši, ja tā saņem atkārtotus automatizētus uzbrukumus. - Noņemiet neizmantotos kontus un izvairieties no prognozējamiem administratoru lietotājvārdiem. - Pārskatiet XML-RPC, pamatojoties uz faktiskajām atkarībām. Ja to neizmanto neviena nepieciešama mobilā lietotne, publicēšanas darbplūsma vai integrācija, tā ierobežošana var samazināt nevajadzīgu pakļautību riskiem. Pieteikšanās URL maiņa var samazināt zemas kvalitātes automatizēto troksni, taču tā nav primārā drošības robeža. Tā nekad nedrīkst aizstāt daudzfaktoru autentifikāciju, paroļu higiēnu, lomu kontroli un ātruma ierobežošanu. ## 5. Uztveriet dublējumkopijas kā atjaunošanas kontroles pasākumu Dublējumkopija ir noderīga tikai tad, ja tā ir pilnīga, izolēta no kompromitētās vides un atjaunojama. Tikai datubāzes dublējumkopijā var nebūt augšupielāžu un pielāgota koda. Dublējumkopija, kas glabājas tikai tajā pašā hostinga kontā, var nebūt pieejama, kad konts ir kompromitēts. Dublējumkopija, kas nekad nav atjaunota, ir pieņēmums, nevis atjaunošanas plāns. Glabājiet gan datubāzes, gan failu dublējumkopijas, vismaz vienu kopiju glabājiet atsevišķi no produkcijas hostinga konta un nosakiet glabāšanas periodu atbilstoši uzņēmējdarbības prasībām. E-komercijas vietnei, kas ik dienu apstrādā pasūtījumus, ir ļoti atšķirīga datu zuduma pieļaujamība nekā reprezentācijas vietnei, kuru atjaunina reizi mēnesī. Pārbaudiet atjaunošanu nepubliskā vidē. Apstipriniet, ka atjaunotā vietne tiek ielādēta, multivides faili ir pieejami, pastāv sagaidāmie dati un darbojas kritiskās funkcijas, piemēram, veidlapas vai norēķināšanās. Dublējumkopiju krātuvei nepieciešama tāda pati piekļuves disciplīna kā produkcijas videi: konkrēti lietotāji, unikāli piekļuves dati un daudzfaktoru autentifikācija, ja tā ir pieejama. Lielākām vietnēm definējiet divus mērķus: - Atjaunošanas punkta mērķis (RPO): maksimālais pieļaujamais datu zudums. RPO 24 stundas nozīmē, ka uzņēmums var pieņemt līdz vienas dienas izmaiņu zudumu. - Atjaunošanas laika mērķis (RTO): maksimālais pieļaujamais laiks pakalpojuma atjaunošanai. Tie ir uzņēmējdarbības lēmumi, nevis tehniski apzīmējumi. Tie nosaka dublējumkopiju biežumu, glabāšanas periodu, hostinga arhitektūru un nepieciešamo sagatavotības līmeni atjaunošanai. ## 6. Uzraugiet nozīmīgas izmaiņas, ne tikai ļaunprogrammatūru Ļaunprogrammatūras skenēšana ir noderīga, taču tīrs skenēšanas rezultāts nepierāda, ka vietne ir droša. Atklāšana ir atkarīga no tā, ko skeneris atpazīst, ko tas var pārbaudīt un kā kompromitēšana izpaužas. Jauni administratoru konti, mainīti DNS ieraksti, negaidīti plānotie uzdevumi, modificēti faili un neparasti izejošie e-pasti var būt tikpat svarīgi signāli. Veidojiet uzraudzības rutīnu, aptverot: - neveiksmīgu pieteikšanās mēģinājumu modeļus un veiksmīgas administratoru pieteikšanās; - jaunus, dzēstus vai ar mainītām privilēģijām WordPress lietotājus; - kodola, spraudņu un tēmu izmaiņas; - negaidītas kritisko failu modifikācijas; - pieejamību, TLS sertifikāta derīguma termiņa beigšanos un domēna vai DNS izmaiņas; - tīmekļa servera un PHP kļūdu žurnālus, jo īpaši pēc laidieniem; - izejošo e-pastu apjomu un veidlapu iesniegumus, kas liecina par ļaunprātīgu izmantošanu. Izvēlieties rīkus atbilstoši videi, nevis instalējiet vairākus spraudņus, kas visi skenē failus, darbina ugunsmūrus un sūta brīdinājumus. Jūsu hostings, CDN, uzraudzības pakalpojumu sniedzējs un esošie WordPress rīki jau var segt daļu no steka. Dublēti kontroles pasākumi var patērēt resursus, radīt konfliktējošus iestatījumus un atstāt situāciju, kurā neviens nav skaidri atbildīgs par reaģēšanu uz brīdinājumiem. ## 7. Iekļaujiet pielāgotu kodu un integrācijas drošības pārskatā WordPress drošība neaprobežojas ar vadības paneli. Pielāgots REST galapunkts, veidlapu apstrādātājs, tīmekļa aizķere, maksājumu integrācija vai individuāli izstrādāts spraudnis var radīt lielāku risku nekā standarta WordPress instalācija. Pārskatiet pielāgoto funkcionalitāti pēc būtiskām izmaiņām un pirms sensitīvu sistēmu pieslēgšanas. Īpašu uzmanību pievērsiet autorizācijas pārbaudēm, ievades validācijai, izvades ekranēšanai, nonce izmantošanai administratīvām darbībām, failu augšupielādes apstrādei, API atslēgu glabāšanai un kļūdu ziņojumiem, kas atklāj iekšējas detaļas. Vietnei ar pielāgotiem spraudņiem vai uzņēmējdarbībai kritiskām integrācijām mērķtiecīgs [WordPress koda drošības audits](https://asgru.com/lv/wordpress-koda-drosibas-audits-ko-tas-ietver-un-kad-to-pasutit/) sniedz atbildes, ko konfigurācijas kontrolsaraksts nevar sniegt. Kontrolsaraksts samazina ikdienas darbības nepilnības; koda pārskats pārbauda lietojumprogrammas loģiku, atļaujas un uzticības robežas. Drošības prasībām jābūt arī daļai no pieņemšanas kritērijiem pārbūves un integrācijas darbiem, nevis pēcapdomai pēc funkcijas palaišanas. Plašākiem arhitektūras un uzturēšanas apsvērumiem skatiet [WordPress vietnes uzlabošanas un integrācijas plānošanu](https://asgru.com/lv/wordpress-vietnes-pilnveidosana-pielagotas-funkcijas-integracijas-un-modernizacija/). ## 8. Definējiet incidenta slieksni, pirms tas ir nepieciešams Neviens kontroles pasākums negarantē, ka vietne nekad netiks kompromitēta. Praktiskā atšķirība starp pārvaldāmu un ieilgušu incidentu bieži ir tā, vai komanda laikus atpazīst brīdinājuma pazīmes un izvairās iznīcināt noderīgus pierādījumus. Nekavējoties eskalējiet, ja atrodat neizskaidrojamus administratoru kontus, mainītu maksājumu informāciju, nepazīstamu kodu spraudņu vai tēmu failos, surogātpasta novirzīšanas, pārlūkprogrammas vai meklētājprogrammas brīdinājumus, neparastus izejošos e-pastus vai aizdomīgas darbības hostinga žurnālos. Fiksējiet novēroto, saglabājiet attiecīgos žurnālus un dublējumkopijas, piesardzīgi ierobežojiet piekļuvi un iesaistiet hostinga pakalpojumu sniedzēju vai kvalificētu reaģēšanas uz incidentiem pakalpojumu sniedzēju. Nepieņemiet, ka viena aizdomīga faila dzēšana vai spraudņu atjaunināšana ir novērsusi kompromitēšanu. Pēc atjaunošanas nomainiet piekļuves datus un noslēpumus, identificējiet iespējamo ieejas punktu, pārskatiet iespējamo pakļautības periodu un novērsiet pamatā esošo nepilnību. Dublējumkopijas atjaunošana, neatrodot cēloni, var vienkārši atjaunot to pašu ievainojamību. ## WordPress drošības kontrolsaraksts: praktiska uzturēšanas rutīna ### Reizi nedēļā vai pēc atjauninājumu izlaišanas - Pārskatiet un ieviesiet pārbaudītus WordPress kodola, spraudņu un tēmu atjauninājumus. - Pārbaudiet dublējumkopiju pabeigšanu un izmeklējiet brīdinājumus par neveiksmīgām dublējumkopijām. - Pārskatiet drošības, pieejamības un kļūdu brīdinājumus, kuriem nepieciešama rīcība. ### Reizi mēnesī - Pārskatiet administratoru kontus, instalētos spraudņus, tēmas un integrāciju piekļuves datus. - Pārbaudiet kritiskos vietnes ceļus, tostarp pieteikšanos, veidlapas, norēķināšanos un attiecīgās kontu sadaļas. - Pārskatiet žurnālus un izmeklējiet negaidītas failu vai konfigurācijas izmaiņas. ### Reizi ceturksnī - Pārbaudiet atjaunošanu drošā, nepubliskā vidē. - Pārskatiet piekļuvi WordPress, hostingam, DNS, domēna reģistrācijai, e-pastam un dublējumkopiju krātuvei. - Apstipriniet, ka daudzfaktoru autentifikācijas metodes un atkopšanas informācija pieder aktīviem darbiniekiem. - Noņemiet vecās testa kopijas, neaktīvos pakalpojumus un integrācijas, kurām vairs nav uzņēmējdarbības mērķa. ### Pēc jebkurām būtiskām izmaiņām - Pārbaudiet funkcionalitāti un pārskatiet žurnālus. - Pārbaudiet, ka aktuālās dublējumkopijas ir veiksmīgi pabeigtas. - Dokumentējiet jaunus kontus, API atslēgas, atļaujas un trešo pušu atkarības. ## Bieži uzdotie jautājumi ### Vai ar drošības spraudni pietiek, lai aizsargātu WordPress? Nē. Drošības spraudnis var nodrošināt noderīgu uzraudzību, pieteikšanās aizsardzību un brīdinājumus, taču tas nevar kompensēt vāju hostinga piekļuves aizsardzību, atkārtoti izmantotas paroles, neatbalstītu servera programmatūru, nedrošu pielāgotu kodu vai nepārbaudītas dublējumkopijas. WordPress drošība aptver lietojumprogrammu, serveri, DNS, e-pastu, dublējumkopiju krātuvi un cilvēkus, kuri var piekļūt katram slānim. ### Vai katram WordPress spraudnim jāatjauninās automātiski? Automātiskie atjauninājumi var samazināt laiku, kurā zināmas problēmas paliek atklātas, jo īpaši vienkāršākās vietnēs. Sarežģītās vai ieņēmumiem kritiskās vietnēs atjauninājumi jāapvieno ar pārbaudēm testa vidē un atcelšanas plānu. Pareizā izvēle ir dokumentēta politika, kas balstīta uz dīkstāves sekām un komandas spēju uzraudzīt izmaiņas. ### Vai WordPress pieteikšanās lapas slēpšana padara vietni drošu? Nē. Tā var samazināt oportūnistisku automatizētu datplūsmu, taču uzbrucēji WordPress instalācijas var identificēt pēc citiem signāliem. Par prioritāti nosakiet daudzfaktoru autentifikāciju, stipras unikālas paroles, mazāko nepieciešamo privilēģiju lomas un ātruma ierobežošanu. ### Cik bieži jāveido WordPress vietnes dublējumkopijas? Nosakiet dublējumkopiju biežumu atbilstoši datu apjomam, ko uzņēmums var atļauties zaudēt. Vietnei, kas saņem pasūtījumus, reģistrācijas vai ikdienas satura izmaiņas, nepieciešami biežāki atjaunošanas punkti nekā statiskai vietnei. Iekļaujiet failus un datubāzi, glabājiet ārpusvietas kopiju un regulāri pārbaudiet atjaunošanu. ### Kas man jādara, ja domāju, ka mana WordPress vietne ir uzlauzta? Neuztveriet šo problēmu kā parastu atjaunināšanas uzdevumu. Saglabājiet pierādījumus, fiksējiet simptomus, attiecīgā gadījumā ierobežojiet piekļuvi, ja nepieciešams, sazinieties ar hostinga pakalpojumu sniedzēju un izmantojiet strukturētu novēršanas procesu. Kad ir apstiprināts, ka vietne ir tīra, izmantojiet šo kontrolsarakstu, lai novērstu apstākļus, kas pieļāva kompromitēšanu. ## Praktiskā prioritāte Ja šomēnes veicat tikai piecas darbības, noņemiet nevajadzīgu kodu un kontus; ieviesiet kavētos atjauninājumus, izmantojot pārbaudītu procesu; nodrošiniet daudzfaktoru autentifikāciju priviliģētai piekļuvei; pārbaudiet ārpusvietas atjaunošanu; un pārskatiet, kas kontrolē hostingu, DNS, domēnu, e-pastu un dublējumkopijas. Šie kontroles pasākumi novērš ievērojamu daļu novēršamu WordPress risku, neradot spraudņu kaudzi un maldīgu drošības sajūtu. Ja ir iesaistīta pielāgota funkcionalitāte, sensitīvas integrācijas vai būtiskas uzņēmējdarbības sekas, uzturēšanas plānam pievienojiet uz kodu vērstu drošības pārskatu.