Architektúra · Védett statikus kiszolgálás
Statikus WordPress védelme CloudFront aláírt sütikkel
A Cognito igazolja az identitást, egy aláíró időkorlátos CloudFront-hozzáférést ad, a CloudFront pedig kikényszeríti a védett statikus útvonalakat anélkül, hogy vissza kellene állítani a WordPress PHP-munkameneteit.
Látogató → védett CloudFront-útvonal ↓ nincs érvényes süti Gatey → Amazon Cognito ↓ elfogadott identitás Aláíró szolgáltatás → aláírt sütik ↓ CloudFront → privát S3-objektum
Bizalmi határok
Az identitás, a statikus fájlhozzáférés és az API-jogosultság különálló vezérlők
A Cognito-token identitást igazol. A CloudFront aláírt süti a kijelölt statikus objektumok lekérését szabályozza. A védett API-knak továbbra is saját JWT-, IAM- vagy szolgáltatásoldali jogosultságkezelésre van szükségük. Ezek elkülönítése megakadályozza, hogy egyetlen hitelesítő adat univerzális engedéllyé váljon.
Identitás: böngésző → Cognito → tokenek Statikus hozzáférés: elfogadott identitás → aláíró → CloudFront-süti → védett útvonal API-művelet: böngésző → engedélyezett API → backendvalidáció A WordPress marad a CMS, és kérésidőben nem ő kényszeríti ki a látogatói hozzáférést.
Kiszolgálási határ A privát S3-objektumok maradjanak a CloudFront mögött. A linkek elrejtése, a JavaScriptes korlátozás vagy a sikeres bejelentkezés önmagában nem védi meg a statikus objektumot.
Mit hoz létre a biztonságos statikus stack
A védelmi réteg a tárolásra, a peremhálózati kiszolgálásra, az aláírásra, az identitásra és a visszaélés elleni védelemre is kiterjed. A táblázat bemutatja az összetevők felelősségét és biztonsági határát.
| Erőforrás / képesség | Cél | Biztonsági határ | Tervezési megjegyzés |
|---|---|---|---|
| S3-forrás | Az exportált statikus WordPress-fájlokat tárolja | Az objektumok ne legyenek nyilvánosak, ha a CloudFront a kiszolgálási határ | A Static Publisher publikálhatja a fájlokat; a védelmi stack szabályozza a hozzáférési útvonalat. |
| CloudFront-disztribúció | Nyilvános és védett útvonalakat szolgál ki a peremhálózaton | A védett viselkedések aláírt sütiket igényelnek | A védett útvonalak listája architekturális paraméter, nem témabeállítás. |
| CloudFront kulcscsoport / nyilvános kulcs | Lehetővé teszi az aláírt sütik szabályzataláírásának ellenőrzését | A nyilvános kulcsot a CloudFront látja; a privát kulcs az aláírónál marad | A kulcsrotációhoz üzemeltetési eljárás kell. |
| Aláíró szolgáltatás | Identitás-ellenőrzés után aláírt sütiket ad ki | Privát kulcs KMS/SSM-ben vagy azzal egyenértékű védett tárolóban | A sütihatókörtől függően API Gateway + Lambda vagy azonos domaines peremlogika lehet. |
| Cognito/Gatey-integráció | A sütik kiadása előtt hitelesíti a látogatót | Az identitástokenek elkülönülnek a CloudFront-sütiktől | A bejelentkezési oldal a statikus webhely része lehet. |
| Útvonal-, DNS- és tanúsítványopciók | Összerendelik a nyilvános webhelyet és az opcionális API-/aláíró domaint | A TLS és a hostnevek határozzák meg a sütik működését | A domainstratégia ugyanolyan fontos, mint a Lambda-kód. |
| WAF- / sebességkorlátok | Csökkentik a nyilvános és aláíróútvonalak visszaéléseit | Peremhálózati szűrés a futtatókörnyezet előtt | Különösen hasznos nyilvánosan elérhető védett útvonalaknál és aláíróvégpontoknál. |
Aláírt sütik és JWT-k
Ezek a hitelesítő adatok eltérő dolgokat igazolnak. Az összevetés megakadályozza, hogy az identitástokeneket, ideiglenes AWS-hitelesítő adatokat, CloudFront hozzáférési sütiket és WordPress-munkameneteket felcserélhetőnek tekintsük.
| Artefaktum | Kibocsátó | Ellenőrző | Legjobb felhasználás |
|---|---|---|---|
| Cognito ID-/hozzáférési token | Amazon Cognito a hitelesítés után | Frontendkód, API Gateway authorizer, backend Lambda | A felhasználó identitásának és az identitáshoz tartozó scope-ok vagy claim-ek igazolása. |
| IAM-hitelesítő adatok | Cognito Identity Pool / STS | AWS-szolgáltatásjogosultság | IAM által engedélyezett API-k vagy szolgáltatások hívása böngészőből ideiglenes, korlátozott jogosultsággal. |
| CloudFront aláírt süti | A privát kulcsot birtokló megbízható aláíró | CloudFront a peremhálózaton | Statikus objektumok lekérésének engedélyezése vagy tiltása kijelölt útvonalminták alatt. |
| WordPress bejelentkezési süti | WordPress/PHP futtatókörnyezet | WordPress | Admin- vagy hagyományos dinamikus WordPress-munkamenetek, nem statikus peremhálózati jogosultság. |
Útvonalvédelmi modell
Az útvonalkategóriákat telepítés előtt egyértelművé kell tenni. A táblázat különválasztja a nyilvános oldalakat, védett statikus objektumokat, fiókoldalakat, API-kat és nagyobb kockázatú végpontokat.
| Útvonalkategória | Példa | Kikényszerítés | Gyakori hiba |
|---|---|---|---|
| Nyilvános tartalom | /, /about/, /blog/, assetek | CloudFront-gyorsítótár és S3 Origin Access Control | Privát JSON, feltöltések vagy generált fájlok véletlenül nyilvános előtag alá kerülnek. |
| Védett statikus tartalom | /members/*, /training/*, /client/* | CloudFront aláírt sütik az illeszkedő viselkedésekhez/útvonalmintákhoz | Csak a linkek elrejtése, miközben az objektumok közvetlenül lekérhetők. |
| Bejelentkezési és fiókoldalak | /signin/, /profile/ | Gatey + Cognito böngészős folyamat | A bejelentkezési oldal szerveroldali WordPress-állapotként kezelése. |
| Védett API-k | /api/* vagy konfigurált API Gateway domain | Cognito authorizer, JWT scope-ok vagy IAM | Feltételezni, hogy a CloudFront-süti API-módosításokra is jogosít. |
| AI- vagy workflow-végpontok | /frontend/prompt, /forms/submit | Végpontspecifikus hitelesítés, WAF, reCAPTCHA és sebességkorlát | Az oldal-hozzáférési logika újrahasználata nagyobb kockázatú futásidejű műveleteknél. |
Fontos hibamódok
A védelmi modell könnyebben üzemeltethető, ha a gyakori hibák egyértelműek. A táblázat a látható tünetekhez valószínű okot és elsőként ellenőrizendő határt rendel.
| Hibamód | Tünet | Valószínű ok | Javítás iránya |
|---|---|---|---|
| A védett útvonal bejelentkezési hurokba kerül | A felhasználó bejelentkezik, de ismét a belépési oldalra jut | Eltérő süti-domain/útvonal, hiányzó CloudFront-sütik vagy a böngésző elutasítja az attribútumokat | Ellenőrizze a Set-Cookie fejléceket, host-/domainbeállításokat, valamint a SameSite és Secure attribútumokat. |
| A védett fájl nyilvános | A privát URL inkognitóban bejelentkezés nélkül megnyílik | Nyilvános S3-objektum, nem védett CloudFront-viselkedés vagy közvetlen forrás-URL | Tiltsa az S3 nyilvános hozzáférést, kényszerítse ki a CloudFront forráshozzáférését, és ellenőrizze az útvonalmintákat. |
| 403 érvényes bejelentkezés után | A CloudFront AccessDenied választ ad | Lejárt süti, hibás kulcspárazonosító, érvénytelen aláírás vagy eltérő szabályzatútvonal | Ellenőrizze a süti élettartamát, a kulcscsoportot, az aláíró privát kulcsát és a CloudFront erőforrásmintáját. |
| Egyik aldomainen működik, másikon nem | A sütik nem vagy hibásan kerülnek elküldésre | Domain- és hosthoz kötött sütik eltérése vagy webhelyek közötti ütközés | Törekedjen az azonos domaines kiadásra, vagy külön hostokkal és kulcsokkal válassza szét a környezeteket. |
| Az API működik oldal-hozzáférés nélkül, vagy fordítva | API-hívás sikerül, de a statikus oldal nem nyílik meg, vagy fordítva | A külön hitelesítési rétegek eltérően vannak konfigurálva | A statikus hozzáférést és az API-jogosultságot külön szabályzatként kezelje és dokumentálja. |
Megvalósítási útvonal
A védett útvonalakat még publikálás előtt tervezze meg
A védett tartalom modelljét még azelőtt egyértelműen rögzíteni kell, hogy a statikus csomag éles környezetbe kerül.
- Nyilvános és védett útvonalkategóriák meghatározása — Azonosítsa, mely URL-ek és assetek maradnak nyilvánosak, és mely útvonalminták igényelnek hitelesített, aláírt sütis hozzáférést.
- Cognito-alapú identitás konfigurálása — Használja a Gateyt és a konfigurált Cognito User Poolt a böngészős bejelentkezéshez, MFA-hoz, profilhoz vagy SSO-hoz anélkül, hogy a WordPress lenne a frontend munkamenet-authoritása.
- Az aláíró és a CloudFront-szabályzat telepítése — Az aláírókulcs maradjon a megbízható aláíróoldalon, a sütiszabályzat csak a szükséges útvonalakra terjedjen ki, a süti élettartama pedig igazodjon a védett tartalomhoz.
- A hozzáférés tesztelése kiszolgálási problémaként — Külön ellenőrizze a névtelen tiltást, a bejelentkezés utáni hozzáférést, a lejáratot, a közvetlen S3-hozzáférést, a sütidomaint és az API-jogosultságot.
Mikor megfelelő az aláírt sütis védelem
Jó választás
Megosztott statikus tartalom hitelesített hozzáféréssel
- A statikus WordPress-webhely tagsági, ügyfél-, dokumentációs, oktatási vagy portálútvonalai megosztott statikus objektumokként megvalósíthatók.
- A nyilvános és védett oldalakat is CloudFronton keresztül szeretné kiszolgálni a PHP-munkamenetek visszaállítása nélkül.
- A látogatói identitást már a Cognito kezeli, vagy ezt szánja az alkalmazás identitáshatárának.
Válasszon másik mintát
Más jogosultsági modell kell, ha
- Magát az oldalt a szerveren felhasználónként eltérően kell renderelni.
- A hozzáférést minden kérésnél azonnal vissza kell tudni vonni, ezért nem támaszkodhat megfelelően rövid aláírt süti-élettartamra.
- A webhely teljesen dinamikus marad, és a szokásos WordPress szerepkör- és munkamenetvédelem már megfelel a követelménynek.
Problémaútmutatók
Az architektúra által támogatott vásárlói problémák
Hogyan adhatok bejelentkezést statikus WordPresshez PHP-munkamenetek nélkül?
Kezdje a Bejelentkezés hozzáadása statikus WordPresshez a PHP-munkamenetek visszaállítása nélkül című útmutatóval. Ez az identitás szétválasztását magyarázza el; az architektúra pedig a külön CloudFront-kiszolgálási vezérlést.
A Cognito váltsa le a WordPresst az alkalmazás identitásrétegeként?
Lásd az Amazon Cognito használata WordPress helyett az alkalmazás identitásrétegeként című útmutatót, ha a bejelentkezésnek a WordPressen túl API-kra, statikus frontendekre vagy más alkalmazásfelületekre is ki kell terjednie.
A meglévő SAML- vagy OIDC-identitásszolgáltatók továbbra is használhatók?
A föderációs esetre lásd a WordPress összekapcsolása meglévő SAML- és OIDC-identitásszolgáltatókkal külön bejelentkezési folyamatok építése nélkül című útmutatót. A Cognito maradhat az identitásközpont, a védett statikus réteg pedig felhasználhatja a kapott hitelesített állapotot.
A statikus bejelentkezés automatikusan jogosultságot ad az API-khoz?
Nem. Az aláírt statikus hozzáférés és a védett API-műveletek külön határok. A backendnek önállóan kell ellenőriznie a JWT-, IAM- vagy más támogatott jogosultsági mechanizmust.
Induljon a hozzáférési problémából
Adjon bejelentkezést a WordPress-munkamenetréteg visszaállítása nélkül
A vásárlói problémához használja a biztonságos statikus megoldást, ezt az architektúrát pedig akkor, ha kijelölt fájlok vagy útvonalak CloudFront által kikényszerített védelmet is igényelnek.