Īsi sakot: Statiska vietne sastāv no gataviem HTML, CSS un attēlu failiem, ko tīmekļa serveris tikai piegādā. Tā kā serverī nedarbojas ne PHP, ne datubāze, nepilnības, piemēram, PHP2Shell, SQL injekcija vai ievadītas webshell, kā risks lielā mērā atkrīt. Statiskas vietnes drošībai savukārt svarīgi ir citi aspekti: aizsargātas piekļuves hostingam, domēnam un būvēšanas rīkiem, uzturētas atkarības un rūpīgi izvēlēti trešo pušu pakalpojumi. Tā galvenokārt der vietnēm, kas reti mainās un kurām nav vajadzīgi klientu konti.
Kāpēc jautājums tiek uzdots tieši tagad
PHP2Shell daudziem uzņēmumiem parādīja, cik daudz ir atkarīgs no vienas komponentes. Uzņēmuma vietne ar desmit lapām, kas tiek atjaunināta reizi ceturksnī, darbojās uz tā paša PHP kā liels interneta veikals un tādējādi bija pakļauta tai pašai kritiskajai nepilnībai. Saskaņā ar plašsaziņas līdzekļu ziņām pat iestādes un pašvaldības ir piesardzības nolūkā atslēgušas vietnes.
Tad rodas jautājums: vai mūsu vietnei serverī vispār vajadzīgs PHP? Daudziem maziem un vidējiem uzņēmumiem godīgā atbilde ir: piegādei bieži nē. PHP katrā pieprasījumā lapu ģenerē no jauna, kaut gan saturs nedēļām nav mainījies. Kā tas tehniski norit, apraksta Kā PHP ģenerē tīmekļa lapu. Ko nozīmē pati nepilnība, izskaidro Kas ir PHP2Shell?.
Kā darbojas statiska vietne
Statiskā vietnē lapa netiek ģenerēta apmeklējuma laikā, bet iepriekš. Statisko lapu ģenerators, piemēram, Hugo, Jekyll vai Eleventy, ņem tekstus, attēlus un veidnes un no tiem būvē gatavus failus. Šie faili tiek augšupielādēti vienkāršā tīmekļa serverī vai satura piegādes tīklā (Content-Delivery-Netz), tātad sadalītā piegādes tīklā.
Redaktoriem priekšā var atrasties rediģēšanas rīks, kas pieņem izmaiņas un aktivizē pārbūvi. Daļēji šim nolūkam izmanto tā saukto Headless-CMS, kas pārvalda tikai saturu un pats nav publiski sasniedzams. Apmeklētājs no tā neko neredz; viņš saņem tikai gatavos failus.
Statiska vietne un drošība salīdzinājumā
| Kritērijs | Dinamisks PHP CMS | Statiska vietne |
|---|---|---|
| Programmu loģika publiskajā serverī | Jā, katrā pieprasījumā | Nē |
| Risks no nepilnībām PHP interpretatorā | Jā, kā pie PHP2Shell | Piegādes serverī atkrīt |
| Publiski pieslēgta datubāze | Jā | Nē |
| Tipiskas ieejas vietas | Spraudņi, administratora pieteikšanās, augšupielādes, serveris | Piekļuves hostingam, domēnam, būvēšanas sistēmai, trešo pušu pakalpojumi |
| Veidlapas, meklēšana, klienta konts | Iebūvēti | Tikai caur ārējiem pakalpojumiem vai atsevišķām funkcijām |
| Uzturēšanas darbs redaktoriem | Neliels, ierastā saskarne | Atkarīgs no redakcijas rīka |
| Apkope | Regulāri CMS, spraudņu un PHP atjauninājumi | Būvēšanas rīku un atkarību atjauninājumi |
| Piemērotība | Veikali, portāli, daudzi redaktori, biežas izmaiņas | Uzņēmuma vietnes, nosēšanās lapas, dokumentācija |
Tabula rāda: uzbrukuma virsma pārvietojas, tā nepazūd. Publiski sasniedzama PHP servera vietā jāaizsargā konts pie hostinga pakalpojumu sniedzēja, domēns, būvēšanas konveijers (build pipeline) un, iespējams, redakcijas rīks.
Kādi riski statiskām vietnēm paliek
Pirmkārt, piekļuves. Kas pārņem hostinga kontu, domēna piekļuvi vai koda repozitoriju, var mainīt vietni, pilnīgi bez PHP. Divfaktoru pieteikšanās un personiski konti tāpēc ir obligāti.
Otrkārt, atkarības. Ģeneratori un veidnes bieži ienes daudz pakotņu, piemēram, no npm. Tās jāuztur aktuālas, jo kompromitēta atkarība būvēšanas laikā var ierakstīt ļaunprātīgu kodu gatavajos failos. Kā to organizēt, apraksta Atkarību uzturēšana aktuālā stāvoklī.
Treškārt, trešo pušu pakalpojumi. Veidlapu pakalpojumi, meklēšanas funkcijas, analīzes rīki un iekļautie skripti darbojas apmeklētāju pārlūkā vai svešos serveros. Katrs no šiem pakalpojumiem ir uzticības attiecības, arī datu aizsardzības ziņā.
Ceturtkārt, pārlūka puse. Arī statiskai lapai jāiestata drošības galvenes (Security Headers), piemēram, Content-Security-Policy, kas nosaka, kurus skriptus drīkst ielādēt. Pamati ir sadaļā Drošības galvenes vietnēm.
Pirms pārejas pārbaudiet, kādas funkcijas jūsu vietne patiešām izmanto. Bieži to ir mazāk, nekā domāts: lapas, attēli, kontaktu veidlapa. Tad ceļš uz statisku vietni ir īsāks, nekā sākumā šķiet.
Kam pāreja atmaksājas un kam ne
Statiska vietne labi der uzņēmuma lapām ar pārskatāmu apjomu, kampaņu nosēšanās lapām, produktu dokumentācijai un karjeras lapām. Pāreja īpaši atmaksājas, ja līdzšinējā vietne darbojas uz vecas PHP versijas un jauninājums tāpat būtu jāveic.
Mazāk tā der interneta veikaliem, klientu portāliem, rezervēšanas sistēmām un vietnēm ar daudziem redaktoriem, kas publicē katru dienu. Šeit dinamiska sistēma paliek lietderīga. Palīdzēt var jaukta forma: veikals paliek dinamisks un tiek labi nostiprināts, ceļveži un uzņēmuma lapas tiek piegādāti statiski.
Bieži par zemu novērtēta priekšrocība parādās ārkārtas situācijā. Tā kā gatavos failus jebkurā brīdī var pārbūvēt no veidnēm un satura, manipulētu vietni var ātri atiestatīt uz zināmu, tīru stāvokli. Priekšnosacījums ir, ka saturs un veidnes atrodas aizsargātā repozitorijā, izmaiņas tiek izsekojami protokolētas un neviens nerediģē failus tieši serverī.
Drošības pakalpojumu sniedzējs pārejai nav obligāti vajadzīgs; to var paveikt aģentūra vai izstrādātājs. Ja līdzšinējā vietne bija kompromitēta, saturs tomēr pirms pārņemšanas jāpārbauda. Uz to iedziļinās Pēc uzlaušanas mainīt CMS?.
Kā PHP SOS palīdz konkrēti?
- Mēs pārbaudām, kādas funkcijas jūsu vietnei tiešām vajadzīgas, un atklāti sakām, vai statisks risinājums der.
- Mēs pārejas gadījumā nodrošinām piekļuves hostingam, domēnam un būvēšanas sistēmai ar divfaktoru pieteikšanos un personiskiem kontiem.
- Mēs pārbaudām trešo pušu pakalpojumus un iestatām drošības galvenes, lai jaunā vietne būtu labi aizsargāta arī pārlūkā.
- Palikušajām PHP sistēmām mēs uzņemamies atjauninājumus un uzraudzību drošības apkopes līgumā.
Secinājums
Statiska vietne nav universāls līdzeklis, bet daudzām uzņēmuma lapām tas ir vienkāršākais veids, kā atbrīvoties no visas riska klases. Kur PHP nedarbojas, PHP2Shell neko nevar izdarīt. Iegūtā drošība tomēr turas tikai tad, ja piekļuves, atkarības un trešo pušu pakalpojumi tiek uztverti tikpat nopietni kā agrāk serveris.
Biežāk uzdotie jautājumi
Vai statisku vietni tomēr var uzlauzt?
Jā. Atkrīt servera puses programmu loģika un līdz ar to liela uzbrukumu klase. Uzbrucamas tomēr paliek piekļuves hostingam, domēnam un būvēšanas sistēmai, iekļautie trešo pušu pakalpojumi un rīki, ar kuriem lapa tiek ģenerēta.
Vai statiskai vietnei var būt kontaktu veidlapas?
Jā, caur ārēju veidlapu pakalpojumu vai nelielu, atsevišķi darbinātu funkciju. Tad datu apstrāde notiek šajā pakalpojumā. Noskaidrojiet datu aizsardzību un datu apstrādi uzdevumā (AVV), pirms to iekļaujat.
Vai redaktori statisku vietni var uzturēt paši?
Ar piemērotu redakcijas rīku jā. Daudzi risinājumi piedāvā rediģēšanas saskarni, no kuras lapa pēc tam tiek ģenerēta no jauna. Komandām, kas ik dienu maina daudz satura, klasisks CMS tomēr bieži ir ērtāks.
Vai pāreja atmaksājas interneta veikalam?
Parasti ne pilnībā. Iepirkumu grozam, klienta kontam un maksājumam vajadzīga servera puses loģika. Iespējams daļas, piemēram, ceļvežus vai uzņēmuma lapas, piegādāt statiski un veikalu darbināt atsevišķi.