A lecke végére el tudod magyarázni, mit bizonyít az mTLS, és mit nem; meg tudod különböztetni a szolgáltatás identitását a felhasználó jogosultságától, és fel tudod sorolni a token ellenőrzésének legfontosabb lépéseit.
Miért kell?
Szolgáltatások között is ellenőrizni kell, ki hív, mire jogosult, és milyen erőforrást érint. A belső hálózat nem automatikusan megbízható: hibás konfiguráció, kompromittált komponens vagy véletlen publikus útvonal miatt illetéktelen hívó is elérheti a szolgáltatást.
Titkosított kapcsolat és identitás: TLS és mTLS
A TLS (Transport Layer Security) titkosított kapcsolatot ad, és a szerver tanúsítványa alapján a kliens ellenőrizheti, kihez kapcsolódik. Az RFC 8446 (TLS 1.3) szerint a tanúsítvánnyal hitelesítő szerver opcionálisan kérhet tanúsítványt a klienstől is. Ez az mTLS (mutual TLS, kölcsönös TLS): mindkét fél tanúsítvánnyal igazolja magát. Szolgáltatás- vagy munkaterhelés-identitást adhat, de önmagában nem mondja meg, milyen üzleti műveletet végezhet az azonosított hívó.
Tanúsítványkezeléshez kibocsátás, érvényesség, megújítás és bizalmi gyökér tartozik. A lejárt vagy ismeretlen tanúsítványt nem szabad az ellenőrzés kikapcsolásával „megjavítani”.
Szolgáltatás- és felhasználói kontextus
Egy hívás lehet tisztán szolgáltatásművelet, vagy egy felhasználó nevében végzett. A kettőt meg kell különböztetni: a szolgáltatás saját identitása mellett szükség lehet a felhasználó jogosultságára és a bérlő (tenant) kontextusára is. Egy publikus kliensnek kiadott tokent nem érdemes automatikusan minden belső szolgáltatásnak továbbítani, ha azok nem a megengedett címzettek.
Token ellenőrzése (JWT)
Ha a kontextus JWT (JSON Web Token) formában utazik, az RFC 8725 (JWT Best Current Practices) szerint egyebek mellett:
a könyvtár csak a hívó által megadott algoritmusokat fogadja el; az algoritmus és a kulcs összetartozik;
az aláíró kulcsnak a kibocsátóhoz (iss) kell tartoznia, és a sub értékét az alkalmazás ismert alanyaival kell összevetni;
ha egy kibocsátó több címzettnek ad ki tokent, az aud (címzett) megléte és egyezése kötelezően ellenőrizendő;
a kid és a kulcsforrást megadó URL-mezők (jku, x5u) injektálásra és SSRF-re adhatnak lehetőséget, ezért szűrni kell őket;
a különböző célú JWT-k ellenőrzési szabályai legyenek kölcsönösen kizáróak (például typ fejléccel).
A token tartalmának dekódolása nem hitelesítés.
Objektumszintű jogosultság
A belépési pont (átjáró) hitelesíthet és előzetes hozzáférési szabályt alkalmazhat. A szolgáltatás azonban az adatgazda: ő tudja eldönteni, hogy a hívó módosíthatja-e az adott rekordot. Az OWASP API Security Top 10 első helyén szereplő BOLA (Broken Object Level Authorization) lényege, hogy a támadó a kérésben megváltoztat egy objektumazonosítót, és olyan adathoz fér hozzá, amelyhez nem lenne joga. Az OWASP szerint az ellenőrzés nem elég azzal, hogy összevetik a munkamenet felhasználóját az azonosítóval; minden olyan függvényben ellenőrizni kell, hogy a bejelentkezett felhasználó végezheti-e a műveletet a kért rekorddal, amely a kliens bemenetéből ér el adatot.
flowchart LR
C["Kliens"] --> G["Átjáró: hitelesítés"]
G --> S["Szolgáltatás: hívó és hatókör"]
S --> A["Rekord- és bérlőszintű jogosultság"]
A --> D[("Saját adat")]
A kliens által küldött bérlőazonosítót össze kell vetni a hiteles kontextussal. A cache, a háttérmunka és az eseményfogyasztás se veszítse el ezt a határt: egy jogosultságilag hibás cache vagy read model érzékeny adatot adhat másik felhasználónak.
Legkisebb jogosultság és naplózás
A szolgáltatás csak a szükséges API-kat és adatokat érje el. Az API-hatókör és az adatbázis-jogosultság együtt csökkenti a kompromittált komponens hatását. A naplóba ne kerüljenek tokenek, jelszavak és érzékeny tartalom. A trace-azonosító megfigyelési adat, nem jogosultsági bizonyíték.
Gyakori tévhitek
Állítás
Pontosítás
„A belső hálózaton nem kell hitelesíteni.”
A belső hálózat nem automatikusan megbízható.
„Az mTLS jogosultságot is ad.”
Identitást ad, a jogosultságot külön kell eldönteni.
„A JWT dekódolása elég.”
Aláírást, kibocsátót, címzettet és időt is ellenőrizni kell.
„A bejelentkezett felhasználó minden azonosítót használhat.”
Rekordonként ellenőrizendő a jogosultság.
Röviden
A TLS titkosít és a szervert azonosítja; az mTLS a klienst is.
Az identitás nem jogosultság.
A JWT ellenőrzése: algoritmus, kibocsátó, címzett, alany, időbeli feltételek, kulcsforrás.
A rekordszintű jogosultságot az adatgazda szolgáltatás érvényesíti.
Ellenőrző kérdések
Mit bizonyít az mTLS, és mit nem dönt el?
Miért kell a szolgáltatásnak a rekord tulajdonosát ellenőriznie gateway mögött is?
Milyen hibát okozhat a bérlőkontextus nélküli megosztott cache?
Szolgáltatásidentitás, mTLS és jogosultság
Célok
A lecke végére el tudod magyarázni, mit bizonyít az mTLS, és mit nem; meg tudod különböztetni a szolgáltatás identitását a felhasználó jogosultságától, és fel tudod sorolni a token ellenőrzésének legfontosabb lépéseit.
Miért kell?
Szolgáltatások között is ellenőrizni kell, ki hív, mire jogosult, és milyen erőforrást érint. A belső hálózat nem automatikusan megbízható: hibás konfiguráció, kompromittált komponens vagy véletlen publikus útvonal miatt illetéktelen hívó is elérheti a szolgáltatást.
Titkosított kapcsolat és identitás: TLS és mTLS
A TLS (Transport Layer Security) titkosított kapcsolatot ad, és a szerver tanúsítványa alapján a kliens ellenőrizheti, kihez kapcsolódik. Az RFC 8446 (TLS 1.3) szerint a tanúsítvánnyal hitelesítő szerver opcionálisan kérhet tanúsítványt a klienstől is. Ez az mTLS (mutual TLS, kölcsönös TLS): mindkét fél tanúsítvánnyal igazolja magát. Szolgáltatás- vagy munkaterhelés-identitást adhat, de önmagában nem mondja meg, milyen üzleti műveletet végezhet az azonosított hívó.
Tanúsítványkezeléshez kibocsátás, érvényesség, megújítás és bizalmi gyökér tartozik. A lejárt vagy ismeretlen tanúsítványt nem szabad az ellenőrzés kikapcsolásával „megjavítani”.
Szolgáltatás- és felhasználói kontextus
Egy hívás lehet tisztán szolgáltatásművelet, vagy egy felhasználó nevében végzett. A kettőt meg kell különböztetni: a szolgáltatás saját identitása mellett szükség lehet a felhasználó jogosultságára és a bérlő (tenant) kontextusára is. Egy publikus kliensnek kiadott tokent nem érdemes automatikusan minden belső szolgáltatásnak továbbítani, ha azok nem a megengedett címzettek.
Token ellenőrzése (JWT)
Ha a kontextus JWT (JSON Web Token) formában utazik, az RFC 8725 (JWT Best Current Practices) szerint egyebek mellett:
iss) kell tartoznia, és asubértékét az alkalmazás ismert alanyaival kell összevetni;aud(címzett) megléte és egyezése kötelezően ellenőrizendő;kidés a kulcsforrást megadó URL-mezők (jku,x5u) injektálásra és SSRF-re adhatnak lehetőséget, ezért szűrni kell őket;typfejléccel).A token tartalmának dekódolása nem hitelesítés.
Objektumszintű jogosultság
A belépési pont (átjáró) hitelesíthet és előzetes hozzáférési szabályt alkalmazhat. A szolgáltatás azonban az adatgazda: ő tudja eldönteni, hogy a hívó módosíthatja-e az adott rekordot. Az OWASP API Security Top 10 első helyén szereplő BOLA (Broken Object Level Authorization) lényege, hogy a támadó a kérésben megváltoztat egy objektumazonosítót, és olyan adathoz fér hozzá, amelyhez nem lenne joga. Az OWASP szerint az ellenőrzés nem elég azzal, hogy összevetik a munkamenet felhasználóját az azonosítóval; minden olyan függvényben ellenőrizni kell, hogy a bejelentkezett felhasználó végezheti-e a műveletet a kért rekorddal, amely a kliens bemenetéből ér el adatot.
flowchart LR C["Kliens"] --> G["Átjáró: hitelesítés"] G --> S["Szolgáltatás: hívó és hatókör"] S --> A["Rekord- és bérlőszintű jogosultság"] A --> D[("Saját adat")]A kliens által küldött bérlőazonosítót össze kell vetni a hiteles kontextussal. A cache, a háttérmunka és az eseményfogyasztás se veszítse el ezt a határt: egy jogosultságilag hibás cache vagy read model érzékeny adatot adhat másik felhasználónak.
Legkisebb jogosultság és naplózás
A szolgáltatás csak a szükséges API-kat és adatokat érje el. Az API-hatókör és az adatbázis-jogosultság együtt csökkenti a kompromittált komponens hatását. A naplóba ne kerüljenek tokenek, jelszavak és érzékeny tartalom. A trace-azonosító megfigyelési adat, nem jogosultsági bizonyíték.
Gyakori tévhitek
Röviden
Ellenőrző kérdések
Források