Cloudflare kõige ees: mida proxy kaitseb

„Panime Cloudflare’i ette, oleme kaitstud.“ See lause on pooleldi tõsi. Saidi või rakenduse ette paigutatud pöördproxy muudab palju: ülekoormusrünnakud peatuvad enne serverit, kahtlased päringud filtreeritakse, failid lähevad teele külastajale lähedasest vahemälust. Kuid see näeb ainult seda, mis temast läbi läheb, ja mõnikord tegutseb see Teie nimel, ilma et Te oleksite seda palunud. See artikkel seab asjad paika, meie pilvetaristu aluse juhendi raames.

Võtame näiteks Cloudflare’i, sest me kasutame seda ja selle seaded on avalikult dokumenteeritud. Sama lahendus on olemas mujalgi: suurte pilvede juures (Amazon CloudFront koos AWS WAF-iga, Azure Front Door, Google Cloud Armor), sisuedastusvõrkudes nagu Fastly, Akamai või Euroopa Bunny, või Teie enda serverisse paigaldatud pöördproxyga. Selle artikli küsimused kehtivad kõigi kohta.

Lühidalt

• Pöördproxy võtab kõik päringud vastu Teie serveri asemel ja edastab sellele ainult need, mis tema reeglitest läbi lähevad.
• Cloudflare’i puhul on kaitse ülekoormusrünnakute vastu kõigi pakettide hinnas, võrgust kuni rakenduseni.
• See ei kaitse haavatavat rakendust, otse ligipääsetavat serverit ega varastatud kasutajatunnuseid.
• See võib muuta seda, mida Teie sait serveerib, robots.txt kaasa arvatud: kontrollige tootmisaadressi, mitte oma koodi.
• Kõik käib tema kaudu: proxy rike on Teie teenuste rike ja taasteplaan peab sellega arvestama.

Mida pöördproxy teeb

See paigutus selgitab kõike muud: proxy kaitseb seda, mis temast läbi läheb, ja ainult seda.

Mida see kaitseb

Ülekoormusrünnakud. Rünnak, mis ujutab serveri päringutega üle, paneb selle maha, olenemata selle koodi kvaliteedist. Ülemaailmne võrk neelab selle mahu enne, kui see Teieni jõuab. Cloudflare’i DDoS-kaitse dokumentatsioon märgib, et mahupiiranguta standardkaitse, võrgukihtidest kuni rakenduskihini, on kõigi pakettide hinnas.

Kahtlased päringud. Veebirakenduse tulemüür uurib sissetulevaid veebi- ja API-päringuid ning filtreerib soovimatut liiklust reeglistike järgi: pakkuja hallatavad reeglid, Teie kirjutatud reeglid, sageduspiirangud. Ulatus sõltub paketist: algpaketis on üks hallatud reeglistik ja üks sageduspiirangu reegel.

Krüpteerimine ja vahemälu. Proxy esitab külastajatele sertifikaadi ja serveerib oma vahemälust faile, mis ei muutu. Kõige rohkem võidab staatiline sait: kõik selle lehed on failid.

Teie serveri aadress. Kui DNS-kirjed käivad läbi proxy, näeb külastaja ainult proxy aadresse. Ühel tingimusel, mida allpool täpsustatakse: et miski muu ei reedaks tegelikku aadressi.

Mida see ei kaitse

Otse ligipääsetav server. Cloudflare kirjeldab oma lehel lähteserveri kaitsmise kohta, mis võib tegeliku aadressi reeta: proxy kaudu mitte suunatud DNS-kirjed (SPF, TXT), samal masinal majutatud e-posti server, DNS-ajalugu enne proxy kasutuselevõttu. Selle vastumeetmed: võtta serveris vastu ainult Cloudflare’i aadressidelt tulevat liiklust, autentida proxy päringuid või väljuv tunnel, mis väldib igasugust avalikku aadressi. Ja muuta serveri aadressi pärast kasutuselevõttu.

Rakendus ise. Veebirakenduse tulemüür tunneb ära teadaolevad rünnakud; see ei paranda haavatavat laiendust ega vigast loogikat. Uuendused jäävad Teie asjaks, nagu näitab meie artikkel häkitud WordPressi saitide kohta.

Kasutajatunnused. Sisselogimine varastatud parooli või API-võtmega näeb välja nagu tavaline sisselogimine. Seda riski käsitletakse mujal: meeskonna paroolihaldur ja tehisintellekti projektide API-võtmete kaitse.

Proxy tegutseb ka Teie nimel

Proxy võib muuta seda, mida Teie sait serveerib: lisada päiseid, ümber kirjutada aadressi, lisada faili. Need valikud on kasulikud, kui need valitakse, ja salakavalad, kui need on vaikimisi sisse lülitatud.

Sellest tulenev reegel on lihtne: kontrollitakse, mida serveerib tootmisaadress, mitte seda, mida sisaldab hoidla. Selle blokeerimise tagajärgi nähtavusele tehisintellekti assistentides kirjeldab meie artikkel sellest, mis teeb saidi tehisintellekti jaoks tsiteeritavaks.

Ainus läbipääsupunkt

Kõik käib läbi proxy: kui see kukub, kukuvad koos sellega Teie teenused, isegi kui Teie server töötab korralikult. Cloudflare avaldas üksikasjaliku kirjelduse oma 18. novembri 2025 rikkest:

1. 11.20 UTC

   Cloudflare’i võrk hakkab liiklust suunamast ebaõnnestuma. Robotite haldamise konfiguratsioonifail, mis oli andmebaasi õiguste muutmise järel liiga suureks kasvanud, paneb proxy tarkvara kokku jooksma.

2. 17.06 UTC

   Kõik Cloudflare’i süsteemid töötavad taas normaalselt.

See ei ole argument proxyde vastu: ka üksik server kukub, ja sagedamini. See on argument selle plaani kirjutamiseks. Piisab kolmest ettevaatusabinõust: väline sond, mis testib teenust läbi proxy (vt meie järelevalve juhendit), kirjalik protseduur saidi serveerimiseks ilma proxyta, kui rike kestab, ning juurdepääsud proxy kontole, mis on hoitud koos teiste hädaolukorra juurdepääsudega katastroofijärgses taasteplaanis.

Mida meie teeme

Oma serveris kehtib sama põhimõte väiksemas mahus: üks pöördproxy kõigi teenuste ees, mis koondab sertifikaadid ja juurdepääsureeglid, ning teenused ise on internetile suletud.

Kust alustada

1. 01Inventeerida, mis on avatud.

   Iga domeen ja alamdomeen, mida see serveerib ja kas see käib läbi proxy.

2. 02Sulgeda otsene juurdepääs.

   Server võtab vastu ainult proxy, seejärel muuta selle aadressi, kui see on juba ringelnud.

3. 03Üle vaadata sisselülitatud valikud.

   Robotite haldus, ümberkirjutused, lisatud failid: hoida alles see, mis on valitud, eemaldada ülejäänu.

4. 04Kontrollida, mida serveeritakse.

   Robots.txt, päised ja ümbersuunamised, tootmisaadressil.

5. 05Arvestada rikkega.

   Väline sond, kirjalik möödahiilimise protseduur, hädaolukorra juurdepääsud.

Ülejäänud töö

Proxy on vaid üks aluse kiht. Majutuskoht valitakse kasutuse järgi (pühendatud server, VPS või pilv) ja selle arvet jälgitakse (kuluartiklid, mis pilvearvet paisutavad). Mida proxy ei kaitse, seda käsitletakse varukoopiatega, hästi hallatud andmebaasiga (hallatud või oma Postgres) ja taristuga, mida osatakse uuesti üles ehitada (taristu koodina). Kubernetes ei ole vajalik, et panna proxy mõne teenuse ette (millal VKE seda ei vaja), ja tootmises olev n8n paigutatakse selle taha nagu teisedki (isehostitud n8n). E-postil, mis võib serveri aadressi reeta, on oma artikkel (ettevõtte e-post: Google, Microsoft või Euroopa majutaja). Otsuste poolel: tööriistad, mis tasub esimesena SaaS-ist välja tuua, SaaS-ist väljumise kulu kolme aasta jooksul, pilvemigratsioon ilma kõike lõhkumata, sõltuvus Ameerika pilvest, riistvara tehisintellekti mudeli käitamiseks ja NIS2 Prantsusmaal.

Meie SaaS-ist väljumine paigaldab Teie tööriistad ühe pöördproxy taha, Teile kuuluvasse serverisse, koos testitud varukoopiate ja halduse dokumentatsiooniga: 5 500 € ja kolm nädalat.

Korduma kippuvad küsimused

Allikad

1. Cloudflare, DDoS-kaitse (uus vahekaart)developers.cloudflare.com
2. Cloudflare, veebirakenduse tulemüür (WAF) (uus vahekaart)developers.cloudflare.com
3. Cloudflare, lähteserveri kaitsmine (uus vahekaart)developers.cloudflare.com
4. Cloudflare, Cloudflare outage on November 18, 2025 (uus vahekaart)blog.cloudflare.com