mTLS és Zero Trust szolgáltatások közötti

Amit az mTLS bevezetéskor beállítunk

Kiépítünk egy belső hitelesítésszolgáltatót, cert-managerrel vagy step-cával, amely minden szolgáltatásnak saját, rövid élettartamú tanúsítványt ad ki. A szolgáltatások a hívásoknál kölcsönösen igazolják magukat: nemcsak a kliens ellenőrzi a szervert, hanem fordítva is. Ez azt jelenti, hogy egy belső hálózaton belülre jutó támadó sem tud egyszerűen egy szolgáltatás nevében fellépni, mert a tanúsítvány nélkül a hívást a másik oldal elutasítja. Ezt a modellt fokozatosan vezetjük be, hogy a meglévő szolgáltatásaid ne álljanak le a bekötés közben.

• Belső hitelesítésszolgáltató, cert-manager vagy step-ca alapon
• Rövid élettartamú tanúsítványok minden szolgáltatásnak, automatikus kiadással
• Kölcsönös hitelesítés: mindkét fél igazolja magát a hívásnál
• Workload-identitás szolgáltatásonként, nem hálózati zónánként

Bevált gyakorlatok, amelyeket alkalmazunk

A Zero Trust lényege, hogy a belső hálózaton belüli hely önmagában nem jelent bizalmat. Ezt a szemléletet minden bevezetésnél ugyanazokkal a lépésekkel alkalmazzuk, és a dokumentációdban is rögzítjük, a tanúsítvány-rotáció ütemezésével együtt. Egy klasszikus, hálózati zónákra épülő bizalmi modell egyetlen kompromittált gépből az egész belső hálózatot elérhetővé teszi, míg az identitás-alapú modellben minden egyes hívást külön kell igazolni. Ez a különbség dönti el, mekkora kárt okozhat egyetlen sérült konténer a rendszer egészében.

• Nincs implicit bizalom a belső hálózaton belül sem
• Identitás szolgáltatásonként, nem géponként vagy alhálózatonként
• Legkisebb jogosultság elve minden szolgáltatás közötti hívásnál
• Automatizált tanúsítvány-rotáció, emberi beavatkozás nélkül
• Titkok titkosítva gitben (SOPS) vagy Vault-ban, sosem sima szövegben

Service mesh vagy sidecar nélküli megoldás

Egy teljes service mesh, mint a Linkerd vagy az Istio, automatikusan bevezeti az mTLS-t minden szolgáltatás között, és mérőszámokat, forgalomirányítást is ad hozzá, de egy külön futásidejű réteget és plusz erőforrást jelent. Kisebb rendszereknél gyakran sidecar nélküli megoldást javaslunk: a szolgáltatások könyvtárszinten kezelik az mTLS-t, egyszerűbb üzemeltetéssel. A választás a szolgáltatások számától és a csapatod tapasztalatától függ, ezt közösen mérjük fel.

• Service mesh: automatikus mTLS, forgalomirányítás, több erőforrás
• Sidecar nélküli: könyvtárszintű mTLS, egyszerűbb üzemeltetés
• A döntés a szolgáltatások számától és a csapat tapasztalatától függ

A beleértett órák és a bevezetés üteme

A belső hitelesítésszolgáltató kiépítése, az első szolgáltatások bekötése és a titokkezelés beállítása a havi órák terhére történik: 1–8 óra a VPS-terveken, csomagtól függően 5–10 óra a dedikált és 10 óra a GPU szervereken. Az ügyfélpanel DevOps szolgáltatások menüpontjából kéred, javasolt határidővel. Mivel a teljes szolgáltatás-állomány bekötése több hónapig is eltarthat, jellemzően szolgáltatás-csoportonként haladunk, a kritikusabbakkal kezdve, és minden szakasz végén tesztelt állapotot adunk át. A kereten felüli munkát külön, óradíj alapján számlázzuk.

Hogyan dolgozunk

1. Igényled a panelből

   Elmondod, hány szolgáltatásod van, és melyik kommunikál egymással bizalmasnak számító adatokkal, majd javasolsz egy határidőt a panelből.

2. Egyeztetjük a kereteket

   Feltérképezzük a szolgáltatások közötti hívásokat, kiválasztjuk a hitelesítésszolgáltatót és a rotációs ütemet, és meghatározzuk a bevezetés sorrendjét.

3. Megvalósítjuk és teszteljük a hívásokat

   Kiépítjük a hitelesítésszolgáltatót, bekötjük a szolgáltatásokat, teszteljük a kölcsönös hitelesítést, majd ellenőrizzük, hogy tanúsítvány nélkül a hívás elutasításra kerül.

4. Dokumentálva átadjuk

   Megkapod a hitelesítésszolgáltató konfigurációját, a rotációs ütemet, az új szolgáltatások bekötésének lépéseit és a titokkezelési eljárást.

Felhasználási esetek

Technológiák

• cert-manager
• step-ca
• Linkerd
• Istio
• HashiCorp Vault
• SOPS
• Prometheus

Gyakori kérdések

• Mi az az mTLS, és miben más, mint a sima TLS?

  A sima TLS-nél csak a kliens ellenőrzi a szerver tanúsítványát. Az mTLS-nél a szerver is ellenőrzi a kliens tanúsítványát, tehát mindkét fél igazolja magát. Szolgáltatások közötti kommunikációnál ez azt jelenti, hogy egyik oldal sem fogadhat el hívást ismeretlen vagy nem hitelesített féltől.

• Mi az a Zero Trust, és miért nem elég a hálózati tűzfal?

  A Zero Trust abból indul ki, hogy a belső hálózaton belüli hely önmagában nem bizonyíték a megbízhatóságra. Egy tűzfal a hálózat szélét védi, de egy már bejutott támadó szabadon mozoghat belül. A Zero Trust minden egyes hívást külön igazoltat, függetlenül attól, honnan érkezik.

• Mi az a rövid élettartamú tanúsítvány, és miért jobb, mint a hosszú?

  Egy néhány órás vagy napos érvényességű tanúsítvány automatikusan lejár, ha valamiért nem rotálódik újra, ami korlátozza egy ellopott kulcs kárát. Egy évekre kiadott tanúsítvány visszavonása gyakran elmarad, és sokáig felhasználható marad egy incidens után is.

• Kell nekem service mesh, vagy elég a sidecar nélküli mTLS?

  Kevesebb, tíznél kevesebb szolgáltatásnál a sidecar nélküli, könyvtárszintű mTLS jellemzően elegendő és egyszerűbb üzemeltetni. Egy service mesh akkor éri meg, ha sok szolgáltatásod van, és a forgalomirányítást, a mérőszámokat is a hálózati rétegben szeretnéd kezelni, nem az alkalmazáskódban.

• Hogyan tárolom biztonságosan a titkokat és a kulcsokat?

  Vagy titkosítva a gitben, SOPS-szal, ahol a titkosított fájl bátran verziózható, vagy egy külön titokkezelő szolgáltatásban, mint a Vault, ahonnan futáskor olvassa ki az alkalmazás. Egyik esetben sem kerül sima szövegként titok a kódba vagy a konfigurációs fájlba.

• Mennyivel lassítja le a rendszert az mTLS bevezetése?

  A titkosítás és a tanúsítvány-ellenőrzés mérhető, de jellemzően kis overheadet jelent modern hardveren. A gyakorlatban a nagyobb kihívás nem a teljesítmény, hanem a bevezetés szervezése: a tanúsítvány-kiadás és a rotáció automatizálása, hogy ne kelljen kézzel karbantartani.