Defaults.Exposed › Javítások › CAA rekordok

Hogyan javítsd ki: CAA rekordok

A CAA rekord egy rövid utasítás a domain beállításaiban, amely megnevezi, melyik tanúsítványkibocsátó cégek adhatnak ki 'lakatos' biztonsági tanúsítványt a webhelyed számára. Ha be van kapcsolva, más cég nem tud csendesen érvényes tanúsítványt kibocsátani a nevedben.

Az üzleted szempontjából lényeg: CAA rekord nélkül a világ szinte bármelyik, több száz tanúsítványkibocsátó cége ki tud adni egy valódi, teljesen megbízható lakatos tanúsítványt a te domainedre – lehetővé téve, hogy egy csaló tökéletesen hiteles, teljesen 'biztonságosnak' látszó klónt hozzon létre az oldaladból, hogy lehalássza az ügyfeleid bejelentkezéseit és kártyaadatait, anélkül, hogy bármi figyelmeztesse őket a képernyőn.

Mibe kerülhet ez neked

Egy csaló valódi tanúsítványt szerez az oldalad másolatához, tehát mutatja a zöld lakatot és a HTTPS-t – az ügyfeleid semmit sem látnak rossznak, beírják a jelszavaikat és kártya-számaikat, és csak akkor szerzel tudomást erről, amikor a visszaterhelések és dühös hívások megkezdődnek.
Az ügyfeleid adathalász-t kapnak a bejelentkezési oldal pixelszintű hasonmásán keresztül; az utókövetés – visszatérítések, ügyfélszolgálati terhelés, hírnévkárosodás – a márkádra hull, még akkor is, ha a valódi oldalad sosem volt megérintve.
Egy lehetséges ügyfél biztonsági vagy beszerzési csapata gyors ellenőrzést futtat a domaineden az aláírás előtt, nem lát CAA védelmet, és csendesen az 'alapoknál gyenge' rovatba sorol – kockáztatva egy üzletet egy beállítás miatt, amelynek hozzáadása öt percet vesz igénybe.
A világ egyik tanúsítványkibocsátó cégét feltörik (ez ismételten megtörtént – DigiNotar, Comodo, Symantec), és mivel soha nem mondtad meg, ki jogosult képviselni téged, a domainedet az teszi ki bárminek, amelyik a leggyengébb láncszemnek bizonyul.

Miért fontos. Jelenleg a kapu tárva-nyitva áll: a Föld bármelyik tanúsítványkibocsátó cége kezeskedhet egy olyan oldalért, amely azt állítja, hogy a tiéd, akár üzleteltél velük, akár nem. Egy CAA rekord lezárja azt az ajtót, így csak az általad választott szolgáltató tud tanúsítványokat kiadni – ez a legegyszerűbb, legolcsóbb védekezés az online vállalkozásod megszemélyesítése ellen.

A CAA rekordok egyszerű szavakkal

Minden biztonságos webhelynek van tanúsítványa – az, ami mögött a lakat van a böngészőben és a “https” az URL elején. Ezeket a tanúsítványokat tanúsítványkibocsátó hatóságok (CA) nevű szakosodott cégek adják ki: olyan nevek, mint a Let’s Encrypt, DigiCert, Sectigo, Google Trust Services. Amikor a böngésző érvényes tanúsítványt lát, mutatja a lakatot, és megmondja az ügyfelednek, hogy a kapcsolat valódi és biztonságos.

Íme az a rész, amelyet a legtöbb vállalkozónak soha nem mondanak el: alapból a világ több száz tanúsítványkibocsátó hatóságainak mindegyike engedélyezett tanúsítványt kiadni a te domainedre – akár hallottál róluk, akár nem. Egy CAA rekord (Certification Authority Authorization) egy egysoros megjegyzés, amelyet a domain DNS beállításaihoz adsz hozzá, és amely lényegében azt mondja: “csak ezek a szolgáltatók adhatnak ki nekem tanúsítványokat.” Minden legitim tanúsítványkibocsátó hatóság köteles az iparág szabályai alapján ellenőrizni ezt a megjegyzést a kibocsátás előtt – és visszautasítani, ha nincsenek rajta a listádon.

Ez a különbség egy nyitott bejárati ajtó között, amelyen bárki átmehet, és egy olyan között, amelyen csak az általad választott emberek tartanak kulcsot. És semmibe sem kerül hozzáadni.

Mibe kerülhet ez neked

A CAA rekord által lezárt kockázat a meggyőző megszemélyesítés. Amikor egy csaló valódi tanúsítványt szerezhet az oldal másolatához, a szokásos figyelmeztető jelek eltűnnek – nincs törött lakat, nincs “nem biztonságos” felirat, nincs tanúsítványhiba. Minden jónak tűnik, ami pontosan az, ami veszélyessé teszi.

A tökéletes hamis. Egy csaló regisztrál egy hasonló nézőpontú cím (vagy kompromittál egy utat az ügyfeleidhez), valódi tanúsítványt szerez, és tökéletes klónt állít fel a bejelentkezési vagy pénztári oldaladból – lakattal és mindennel. Az ügyfelek szokás szerint beírják a jelszavaikat és kártyaszámaikat. Az első hírt arról kapsz, hogy visszaterhelési hullám, csalási bejelentések és dühös telefonhívások érkeznek.
Az adathalász kampány a neveddel. A támadók “kérjük, erősítse meg a fiókját” e-maileket küldenek, amelyek az oldalad tanúsítvány-ellátott klónjára mutatnak. Mert az oldal teljesen biztonságosnak látszik, többen esnek be. A takarítás – az ügyfelek értesítése, visszatérítések, ügyfélszolgálati órák, a kínos nyilvános magyarázat – mind rád száll, még akkor is, ha a valódi szervereid sosem voltak megérintve.
Az üzlet, amely megáll egy ellenőrzőlistán. Egy nagyobb ügyfél biztonsági vagy beszerzési csapata átvizsgálja a domainedet az aláírás előtt. A “nincs CAA rekord” piros vagy borostyán tételként jelenik meg a neved mellett. Technikailag kis dolog, de az olvasata az, hogy “nem fedezi az alapokat,” és lelassíthat vagy megölhet egy szerződést, amelyet egyébként megnyertél volna.
Valaki más feltörése által elkapva. Egy tanúsítványkibocsátó hatóság, amellyel soha nem üzleteltél, feltörik – ez nem hipotetikus; a DigiNotar, a Comodo és a Symantec mind komoly incidenseket szenvedett el. Mivel soha nem korlátoztad, ki képviselhet téged, a támadó érvényes tanúsítványt szerezhet a domainedre ezen a gyenge CA-n keresztül. Egy CAA rekord visszautasította volna.
A wildcard vak folt. Még azok a vállalkozások is, amelyek gondosak a főoldaluknál, sokszor elfelejtik az aldomaineket. Egy issuewild szabály nélkül egy olyan támadó, aki wildcard tanúsítványt kap, lényegében kulcsot kap minden aldomainedhez, amelyeket valaha lesz.

Ezek egyike sem igényel kifinomult támadást a szervereid ellen. Az a tény kihasználja, hogy CAA rekord nélkül a szélesebb tanúsítványa-rendszer egyszerűen túl bizalmas a nevedben.

Mi ez pontosan, és mit jelent a „jó” beállítás

A CAA rekord a domain DNS-ében él – ugyanazokban a beállításokban, amelyek a domainedet a weboldaldhoz és az e-mailhez mutatnak. Minden rekordnak három része van: egy jelző, egy tag és egy érték. A fontos tagok:

issue — megnevez egy tanúsítványkibocsátó hatóságot, amely jogosult rendes tanúsítványokat kiadni a domainedhöz. Több lehet, egy minden legitim szolgáltatódhoz.
issuewild — szabályozza a wildcard tanúsítványokat (egy tanúsítvány, amely minden aldomaint fed, pl. *.example.com). Ha nem használsz wildcard-okat, az ajánlott beállítás teljesen blokkolja azokat.
iodef — opcionális elérhetőség, ahol értesítenek téged, ha egy tanúsítványkibocsátó hatóság visszautasít egy kérést a CAA politikád miatt. Ez a korai figyelmeztetés, hogy valaki próbálkozott.

Mit jelent a „jó” beállítás: legalább egy issue (vagy issuewild) rekord jelen van, megnevezve a ténylegesen használt szolgáltatókat, a wildcard-okkal vagy egy névesített szolgáltatóra korlátozva, vagy blokkolva. Ez az a mérce, amelyet ez az ellenőrzés mér – megkeresi a domain CAA rekordjait több független feloldón keresztül, és átmegy, ha valódi issue vagy issuewild politikát talál. Egy domain, amelynek egyáltalán nincsenek CAA rekordjai, úgy kezeli az ellenőrzés, mint a nyitott ajtót.

Befolyásolja-e a besorolásomat? Igen. Egy hiányzó CAA rekord pontozásos tétel, és közepes súlyossággal van megjelölve – ez valódi rés, nem csak “jó, ha megvan,” mert valódi megszemélyesítési utat hagy nyitva. A rekord hozzáadása lezárja a rést és megszünteti a megállapítást.

Hogyan javítsd ki (ingyenes, ~5 perc)

Add ezt a részt annak, aki a domainedet vagy weboldaladat kezeli – a javítás ingyenes. Ez egy kis DNS-módosítás, nem egy újraépítés. Mi csak akkor számítunk fel díjat, ha később azt szeretnéd, hogy figyeljük a rekord meglétét; hozzáadni semmibe sem kerül.

1. lépés – Derítsd ki, melyik tanúsítványkibocsátó hatóságot használod ténylegesen. Ez az egy lépés érdemes helyesen elvégezni, mert a rossz szolgáltató felsorolása blokkolhatja a következő megújítást. Közös esetek:

Let’s Encrypt – sok hoszt és vezérlőpanel (cPanel, Plesk) használja → letsencrypt.org
Cloudflare (ha az él-tanúsítványodat adja ki) → letsencrypt.org, digicert.com, comodoca.com, pki.goog és ssl.com (a Cloudflare több háttér CA-t használ; sorold fel azokat, amelyeket az irányítópultja mutat, vagy a teljes készletet, hogy a megújítások soha ne törjenek)
Google Workspace / Google Trust Services → pki.goog
DigiCert → digicert.com
Sectigo / Comodo → sectigo.com (és comodoca.com)
Microsoft 365 / Azure – a Microsoft általában DigiCert-et használ a managed tanúsítványokhoz → digicert.com (erősítsd meg a portálodon)

Ha bizonytalan vagy, nézd meg a jelenlegi tanúsítványt a böngészőben (kattints a lakatra → tanúsítvány részletei → “Kibocsátó”), hogy kiderítsd, ki adta ki.

2. lépés – Jelentkezz be a DNS-szolgáltatódhoz. Ez az, ahol a domain rekordjai élnek – általában a registrar-od, a webszervert-hoszt vagy a Cloudflare. Keresd meg a DNS rekordok részt, és válaszd az új rekord hozzáadását CAA típussal (egyes felületek ezt 257 típusnak jelölik).

3. lépés – Adj hozzá issue rekordot minden általad használt szolgáltatóhoz. A Let’s Encrypt esetén például:

example.com.   CAA   0 issue "letsencrypt.org"

Adj hozzá egy issue sort minden legitim szolgáltatóra. A legtöbb DNS irányítópult külön mezőket ad a jelzőre (0), tagre (issue) és értékre (a CA domainje), tehát nem kell beírni az egész sort kézzel.

4. lépés – Szabályozd a wildcard tanúsítványokat. Ha nem használsz wildcard-okat, tiltsd le teljesen, hogy senki nem kaphat csendesen egyet:

example.com.   CAA   0 issuewild ";"

Ha igen használsz wildcard-okat, nevesítsd a szolgáltatót: 0 issuewild "letsencrypt.org".

5. lépés – (Ajánlott) Adj hozzá értesítési elérhetőséget. Hogy értesítsenek, valahányszor egy CA visszautasít egy kísérletet – a korai figyelmeztetésed, hogy valaki próbálkozott:

example.com.   CAA   0 iodef "mailto:[email protected]"

6. lépés – Mentsd és ellenőrizd. Futtasd a dig CAA example.com parancsot (vagy használj bármilyen online DNS-keresési eszközt), és erősítsd meg, hogy a rekordok megjelennek. A változások néhány perctől néhány óráig terjedhetnek, amíg elterjednek az interneten. A meglévő tanúsítványod és minden megújítás végig működik – a CAA csak az új kibocsátást szabályozza.

Platform gyorsnotes: A Cloudflare-en: DNS → Records → Add record → típus CAA. A Google Workspace-nél a DNS-t a registrar-odnál kezeled (vagy a Cloud DNS-nél, ha azt használod) – add hozzá a CAA rekordokat ott a pki.goog-gal. A Microsoft 365-nél a CAA nincs beállítva az M365 adminisztrációs központban; add hozzá bárhol, ahol a domain DNS-e hosztolt, felsorolva a managed tanúsítvány CA-dat (általában DigiCert). A általános hosztoknál (GoDaddy, Namecheap, stb.) ugyanabban a DNS panelben van, ahol az A és MX rekordok élnek.

Általános hibák

A rossz CA felsorolása – vagy egynek kihagyása. A legjelentősebb valódi kockázat nem a biztonság, hanem a saját megújításaid blokkolása. Ha több kibocsátót használsz (pl. egy a főoldalhoz és egy a Cloudflare mögött), sorold fel mindegyiket. Ha bizonytalan, sorolj fel néhányat, amelyekben megbízol, inkább túl sokat, mint túl keveset.
issue beállítása, de a wildcard-ok figyelmen kívül hagyása. Egy domain, amely korlátozza a rendes tanúsítványokat, de nem mond semmit a wildcard-okról, a hatékonyabb wildcard utat még mindig nyitva hagyja. Mindig állítsd be az issuewild-ot is – vagy a szolgáltatódra, vagy a ";" értékre a blokkoláshoz.
CAA elhelyezése a rossz névnél. A CAA-t a tanúsítványkibocsátó hatóság az exact tanúsítandó névnél olvassa, felfelé haladva a fában. A domainedhöz a csúcson való beállítás (az “apex,” pl. example.com) a helyes lépés – ez alapból lefedi az aldomaineket, hacsak egy aldomain nem állít be sajátot.
Feltételezni, hogy a platform már megtette. A Cloudflare, a Google és a Microsoft kezelik a tanúsítványokat, de nem adnak hozzá CAA rekordokat neked. Hacsak te nem adtad hozzá, a domainedet még mindig nyitva van.
Egyszeri dologként kezelni, figyelés nélkül. Egy késői DNS-migráció, registrar-csere, vagy rekordok “rendbetétele” csendesen elveszejtheti a CAA védelmedet. Érdemes meggyőződni, hogy még mindig ott van, miután bármilyen DNS-módosítást végeztél.

A technikai réteg (add át az IT-személyednek)

A CAA az RFC 8659-ben van meghatározva és a CA/Browser Forum Baseline Requirements értelmében érvényesített – minden nyilvánosan megbízható CA köteles ellenőrizni a CAA-t kibocsátáskor. A rekordok a <jelzők> <tag> <érték> formát veszik fel, issue, issuewild és iodef tagekkel. Egy nem üres issue vagy issuewild politika az, ami kielégíti ezt az ellenőrzést; csak az iodef megléte nem (ez jelentés, nem engedélyezés).

Egy szilárd alap az apex-nél:

example.com.   CAA   0 issue "letsencrypt.org"
example.com.   CAA   0 issuewild ";"
example.com.   CAA   0 iodef "mailto:[email protected]"

Megjegyzések az implementálónak:

CAA fa-felfelé haladás: a CA-k a kért FQDN-től felfelé értékelik a CAA-t az apexig, megállva az első névnél, amelyhez CAA rekordkészlet van. Egy apex-nél lévő rekord ezért megvédi az összes aldomaint, hacsak egy aldomain nem ad ki sajátot, amit tehet – hasznos, ha egy adott aldomain más kibocsátót használ.
A ; érték az issuewild-ban azt jelenti: “egyetlen CA sem adhat ki wildcard-okat” – explicit tagadás. Használd mindig, amikor a wildcard-ok nem részei a beállításodnak.
A 0 jelző a kibocsátó-kritikus jelző; a 0 (nem kritikus) a helyes normál használathoz. Kerüld a kritikus bit beállítását, hacsak nem érted teljesen, mert egy félreértett kritikus tag okozhat konform CA-knak a kibocsátás megtagadását.
Több kibocsátó: több issue rekord megengedett és összeadódó – sorold fel minden CA-t, amely legitimen a stackedben van (beleértve a háttér CA-kat, amelyeket a CDN/él-szolgáltatód használ) a megújítási hibák megelőzésére.
Ellenőrzés: dig CAA example.com +short, vagy ellenőrizd a CA/Browser Forum CAA tesztelési eszközein. Ez az ellenőrzés maga CAA-t kérdez le több független feloldón keresztül (helyi DNS, majd Google, Cloudflare és Quad9 DNS-over-HTTPS tartalékként), és elfogadja az első hiteles választ, tehát egy egyedüli feloldó kiesése nem produkál hamis “nincs CAA” eredményt.
DNSSEC párosítás: a CAA megmondja a CA-knak, ki adhat ki; a DNSSEC megakadályozza a CAA válasz meghamisítását az átvitel során. Komplementálisak – nagy értékű domainekhez, futtasd mindkettőt.

Állítsd be a tárhelyszolgáltatódnál

Lépésről lépésre a népszerű szolgáltatóknál:

GYIK

Nem vagyok technikai beállítottságú – megoldhatok ezt magam?

Nem kell értened a részleteket, de a javítás egy kis módosítás a domain DNS beállításaiban, tehát legjobb átadni annak, aki a weboldaladat vagy domainedet kezeli. Küldd el nekik az alábbi 'Hogyan javítsd ki' részt – ez egy öt perces, ingyenes módosítás. Mi csak akkor számítunk fel díjat, ha később azt szeretnéd, hogy figyeljük a rekord meglétét; maga a javítás mindig ingyenes.

Tönkreteszi-e a hozzáadása a weboldalamat vagy a tanúsítványomat?

Nem – amíg felsorolod a ténylegesen használt tanúsítványkibocsátót, minden pontosan úgy működik tovább, mint korábban. Egy CAA rekord nem érinti vagy cseréli a meglévő tanúsítványodat; csak azt szabályozza, ki adhat ki újakat. Az egyetlen módja a bajokozásnak az, ha a valódi szolgáltatót kihagyod a listából, ami blokkolhatja a következő automatikus megújítást – az alábbi lépések kifejezetten ennek elkerülésére vannak írva.

Ha a tanúsítványokat ma már automatikusan adják ki, miért van erre szükségem?

Az automatikus tanúsítványok rendben vannak és kényelmesek – a probléma az, hogy a rendszer alapból mindenkinek nyitva áll, beleértve azt is, aki téged személyesít meg. Egy CAA rekord egyszerűen megnevezi, kinek van engedélye, egy nyitott ajtóból olyat csinálva, amelyen csak a te lakatod van. Az automatikus kibocsátással párhuzamosan működik, nem ellene.

Befolyásolja-e a Google rangsorolásomat vagy a besorolásomat ezen a jelentésen?

Befolyásolja a biztonsági besorolásodat – egy hiányzó CAA rekord pontozásos tétel, közepes súlyosságú résként megjelölve, mert egy valódi megszemélyesítési utat hagy nyitva. Nem közvetlen Google rangsorolási tényező, de a megszemélyesítés és adathalász, amelyet megakadályoz, pontosan azok az incidensek, amelyek károsítják a bizalmat és a forgalmat. Akárhogy is, ez gyors, ingyenes nyeremény.

Mi a különbség az 'issue' és az 'issuewild' között?

Az 'issue' rekord a rendes tanúsítványokat szabályozza a domainedre és aldomaineire. Az 'issuewild' rekord a wildcard tanúsítványokat szabályozza – az egyetlen tanúsítványt, amely minden lehetséges aldomaint egyszerre fed (pl. *.example.com). A wildcard-ok erősebbek és ezért rossz kezekben kockázatosabbak, tehát jó gyakorlat külön szabályozni őket: ha nem használsz wildcard-okat, tiltsd le teljesen.

Cloudflare-t / Google Workspace-t / Microsoft 365-öt használunk – ez már fedezi ezt?

Nem automatikusan. Ezek a platformok kezelik a tanúsítványaidat neked, de hacsak nem adtál explicit módon hozzá CAA rekordokat, a domainedet még mindig azt mondja a világnak: 'bármelyik hatóság kibocsáthat.' A jó hír az, hogy a javítás ugyanolyan egyszerű DNS-módosítás mindegyiken, és ahol a Cloudflare vagy a hosted kiad tanúsítványokat, egyszerűen felsorolod azt a szolgáltatót. Az alább lévő fix részben a platform-specifikus megjegyzések lefedik a közös eseteket.