Cloudflare se često promatra kao još jedan tehnički servis povezan s domenom, DNS zapisima ili hostingom. Međutim, Cloudflare pristup može imati jako ulogu u osiguravanju kvalitetnog funkcioniranja suvremene web trgovine. On se nalazi između posjetitelja i poslužitelja na kojem se web trgovina nalazi. Kroz njega može prolaziti velik dio prometa, a njegove postavke mogu utjecati na dostupnost, sigurnost, brzinu i stabilnost web stranice.
Zbog toga agencija koja je odgovorna za tehničko održavanje web trgovine treba imati odgovarajući pristup Cloudflare računu.
Ne zato da bi preuzela vlasništvo nad računom, nego da bi mogla izvršavati odgovornosti koje je preuzela.
Cloudflare više nije samo DNS servis
Cloudflare može obavljati nekoliko važnih funkcija:
- upravljanje DNS zapisima
- zaštitu od DDoS napada
- filtriranje sumnjivog prometa
- blokiranje zlonamjernih botova
- ograničavanje prevelikog broja zahtjeva
- upravljanje predmemoriranjem sadržaja
- analizu sigurnosnih događaja i prometa
- usmjeravanje prometa prema izvornom poslužitelju
Cloudflareova zaštita od DDoS napada automatski prepoznaje i ublažava napade na mrežnom i aplikacijskom sloju. Uz automatsku zaštitu, Cloudflare preporučuje korištenje dodatnih WAF i rate-limiting pravila kako bi se zaštita prilagodila načinu rada konkretne web aplikacije.
Drugim riječima, Cloudflare nije samo mjesto na kojem se povremeno promijeni DNS zapis. On može biti važan dio sigurnosne i operativne infrastrukture web trgovine.
Zašto pristup treba biti dostupan prije incidenta
Najgori trenutak za rješavanje pitanja pristupa jest trenutak u kojem web trgovina već ima problem.
Zamislimo situaciju u kojoj web stranica postane izrazito spora ili nedostupna zbog naglog povećanja prometa. Uzrok može biti marketinška kampanja, agresivno indeksiranje, neželjeni botovi, pokušaj napada ili velik broj zahtjeva prema posebno zahtjevnom dijelu aplikacije. Razvojni i DevOps tim mogu analizirati poslužitelj, aplikaciju i bazu podataka. Međutim, bez pristupa Cloudflareu možda neće moći:
- utvrditi strukturu i izvor prometa
- privremeno blokirati problematične IP adrese ili države
- postaviti rate-limiting pravilo
- prilagoditi WAF zaštitu
- aktivirati dodatnu zaštitu od botova
- promijeniti način predmemoriranja
- provjeriti blokira li postojeće pravilo legitimne korisnike
- brzo preusmjeriti ili ograničiti promet
Cloudflare koristi informacije poput HTTP zaglavlja, putanje, metode zahtjeva, korisničkog agenta, izvorišne IP adrese i količine zahtjeva kako bi prepoznao sumnjive obrasce i različite vrste napada. Agencija bez pristupa tim informacijama vidi samo dio problema – uglavnom posljedice koje dolaze do poslužitelja.
To može značiti da tim odgovoran za dostupnost web trgovine zna da problem postoji, ali nema pristup sustavu kroz koji ga je najbrže moguće ublažiti.
Protiv botova se ne možemo učinkovito boriti samo unutar aplikacije
Automatizirani promet danas predstavlja značajan dio ukupnog internetskog prometa. Nisu svi botovi zlonamjerni, ali pojedini botovi mogu:
- prekomjerno indeksirati katalog
- generirati velik broj zahtjeva prema pretrazi
- provjeravati dostupnost ili cijene tisuća proizvoda
- pokušavati preuzeti sadržaj web trgovine
- opterećivati košaricu, prijavu ili checkout
- tražiti sigurnosne propuste
- stvarati lažne račune ili pokušaje prijave
Dio takvog prometa moguće je kontrolirati unutar same aplikacije ili na poslužitelju. Međutim, tada su zahtjevi već stigli do infrastrukture web trgovine i počeli trošiti njezine resurse. Cloudflare može identificirati i zaustaviti sumnjivi promet prije nego što dođe do izvornog poslužitelja. Ovisno o korištenom paketu, dostupne su različite mogućnosti upravljanja botovima, WAF pravilima i automatiziranim reakcijama.
Za Magento i druge složenije eCommerce platforme to je posebno važno. Jedan automatizirani zahtjev prema zahtjevnoj stranici može potrošiti znatno više poslužiteljskih resursa od posluživanja statičnog sadržaja iz Cloudflareove predmemorije.
Zato zaštita web trgovine ne bi trebala početi tek u aplikaciji. Trebala bi početi na rubu mreže, prije nego što neželjeni promet dođe do aplikacije.
Pristup ne znači da agencija treba biti vlasnik računa
Cloudflare račun i domena trebaju ostati u vlasništvu klijenta. Preporučeni model nije dijeljenje glavne korisničke lozinke ili prijenos cijelog računa agenciji. Cloudflare omogućuje dodavanje pojedinačnih članova i dodjeljivanje pristupa kroz različite uloge i opsege ovlasti. Pristup se može ograničiti na određenu domenu i samo na funkcionalnosti koje su agenciji potrebne.
Primjerice, ovisno o opsegu ugovorene podrške, agenciji mogu biti potrebne ovlasti za:
- pregled analitike i sigurnosnih događaja
- upravljanje DNS zapisima
- upravljanje WAF i firewall pravilima
- konfiguriranje predmemoriranja
- upravljanje pravilima za botove i ograničavanje prometa
Administratorske ovlasti nad cijelim korisničkim računom često nisu potrebne. Na taj način klijent zadržava vlasništvo i kontrolu, dok agencija dobiva dovoljno ovlasti da može kvalitetno obavljati svoj posao.
Promjene moraju biti sljedive
Razumljivo je da klijenti mogu biti oprezni prilikom dodjeljivanja pristupa infrastrukturi. Zato je važno koristiti zasebne korisničke račune, odgovarajuće ovlasti i višefaktorsku autentifikaciju. Nije preporučljivo da više osoba koristi iste pristupne podatke. Cloudflareovi audit logovi bilježe aktivnosti korisnika i promjene konfiguracije. Moguće je vidjeti tko je napravio određenu promjenu, kada ju je napravio i na koji se resurs ona odnosila. To omogućuje veću transparentnost, jednostavnije istraživanje incidenata i jasniju podjelu odgovornosti.
Dobar model pristupa zato uključuje:
- Cloudflare račun u vlasništvu klijenta.
- Zaseban korisnički račun za svaku ovlaštenu osobu ili partnersku organizaciju.
- Samo one ovlasti koje su potrebne za ugovoreni opseg rada.
- Obaveznu višefaktorsku autentifikaciju.
- Periodičnu provjeru aktivnih korisnika i dodijeljenih ovlasti.
- Uklanjanje pristupa nakon završetka suradnje.
Bez pristupa nije moguće preuzeti punu odgovornost
Klijent može odlučiti da agenciji ne želi omogućiti pristup Cloudflareu. Međutim, tada treba biti jasno što takva odluka znači. Agencija može nastaviti održavati aplikaciju i poslužitelj, ali ne može preuzeti punu odgovornost za probleme čije se sprječavanje ili rješavanje nalazi unutar Cloudflare konfiguracije.
U slučaju incidenta tada je potrebno kontaktirati osobu na strani klijenta, objasniti potrebnu promjenu, pričekati njezinu dostupnost i zatim provjeriti je li promjena pravilno provedena.
Tijekom radnog vremena to može uzrokovati nepotrebno usporavanje reakcije. Izvan radnog vremena, tijekom vikenda ili za vrijeme intenzivne prodajne kampanje može predstavljati ozbiljan poslovni rizik.
Zato pitanje Cloudflare pristupa nije samo tehničko pitanje. To je pitanje odgovornosti i operativnog modela suradnje.
Ako se od agencije očekuje da:
- prati stabilnost web trgovine
- reagira na sigurnosne incidente
- istražuje neobične skokove prometa
- zaštiti infrastrukturu od preopterećenja
- podržava velike kampanje i prodajna razdoblja
- brzo reagira kada web trgovina postane nedostupna
onda joj treba omogućiti pristup alatima pomoću kojih te zadatke može izvršiti.
Pristup prije problema, a ne nakon njega
Cloudflare pristup najbolje je definirati prilikom početka projekta ili preuzimanja održavanja web trgovine.
Tada se mogu unaprijed dogovoriti:
- potrebne korisničke uloge
- dopuštene vrste promjena
- način odobravanja rizičnijih zahvata
- postupak reagiranja tijekom incidenta
- kontakt-osobe na strani klijenta i agencije
- način evidentiranja provedenih promjena
Cilj je osigurati da ljudi od kojih se očekuje zaštita i stabilnost web trgovine imaju pravovremen pristup sustavima o kojima ta stabilnost ovisi. Kad velik broj botova, napad ili neočekivani promet ugroze web trgovinu, nije dovoljno samo pitati:
“Tko je ovo mogao spriječiti?”
Potrebno je unaprijed osigurati da osoba koja to može spriječiti ima pristup alatima koji su joj za to potrebni.
