Az emberek azt kérdezik, hol hagyja abba egy AWS Site-to-Site VPN a csomag védelmét, és egyetlen választ várnak: az átjárónál. A válasz hasznos változata megnevezi, melyik átjárónál, mert a virtuális magánátjáró és a tranzitátjáró különböző elrendezések különböző csatolási objektumokkal, és a bíráló, aki a rosszat feltételezi, az értékelés többi részét egy nem létező diagramra építi. Végezd el az alábbi három ellenőrzést sorrendben. Mindegyik vagy megerősíti a határt, vagy megmondja, hogy az előző válasz egy másik erőforrásra vonatkozott.

Nevezd meg a három végpontot, mielőtt bármit értékelsz

Ennek az útvonalnak a titkosítási átvizsgálásához három megnevezett dolog kell: az ügyfélátjáró, az AWS VPN-cél, amely lezárja az IPsecet, és az alkalmazás végpontja, amely fogadja a belső csomagot. Írd le őket az erőforrás-azonosítóikkal együtt, mielőtt akár egyetlen konzololdalt megnyitnál, mert minden e pont után egy állítás arról a háromról.

Az ügyfélátjáró a tiéd, és a konfigurációja látható számodra. Az AWS-cél felügyelt erőforrás, és a hiba az, hogy feltételezzük: egy VPN-kapcsolat csatlakozhat virtuális magánátjáróhoz vagy közvetlenül tranzitátjáróhoz, és egyik sem jelenti a másikat. A harmadik végpont az, amelyet az emberek kihagynak, és ez az egyetlen, amely az alkalmazásadatokra vonatkozó valódi kérdésre válaszol.

1. ellenőrzés: melyik átjáró zárja le valójában az alagutat

Mindkét elrendezés támogatott, és a Site-to-Site VPN architektúra-útmutató egymás mellett írja le őket, ezért az API-t kérdezd egy diagram helyett, amely gyakran egyéves. Egy kapcsolatra vonatkozó csak olvasási lekérdezés visszaadja a VPN-cél mezőit:

aws ec2 describe-vpn-connections --region eu-west-1   --vpn-connection-ids vpn-0123456789abcdef0   --query 'VpnConnections[0].{VGW:VpnGatewayId,TGW:TransitGatewayId,CGW:CustomerGatewayId,Category:Category}'

A megkülönböztető a TransitGatewayId, nem a VpnGatewayId. Az üres TransitGatewayId mezőjű kapcsolat önálló virtuális magánátjárónál végződik, míg a beállított mezőjű kapcsolat egy tranzitátjáró VPN-csatolásánál végződik, és VpnGatewayId ebben az esetben is kitöltve lehet, mert megnevezheti a csatolás hordozó átjáróját. Először a TGW mezőt olvasd, majd a csatolás típusát a csatoláslistából igazold, ne egy mező nevéből, mert azon a tranzitátjárón egy VPC-csatolás nem a VPN-csatolás. A célpéldány megtalálása egy csatlakoztatott VPC-ben semmit sem mond arról, melyik VPN-csatolás vitte a csomagot.

Amíg ott vagy, ellenőrizd az alagutakat. A kapcsolat két IPsec-alagutat hordoz a redundancia érdekében, és egy kapcsolat, amelynek második alagútja soha nem jött fel, valódi megállapítás az elérhetőség szempontjából, még ha a titkosítási határon semmit sem változtat:

aws ec2 describe-vpn-tunnels --region eu-west-1   --filters Name=vpn-connection-id,Values=vpn-0123456789abcdef0   --query 'VpnTunnels[].{Outside:OutsideIpAddress,State:State,Status:Status}'

2. ellenőrzés: mit hordoz még a belső csomag

Amint az IPsec lezárul, az AWS a kibontott csomagot azzal az útvonallal továbbítja, amelyik illeszkedett rá. Attól a ponttól a forgalom közönséges VPC-forgalom, és a VPN védelme véget ért. Ez nem hiányosság a szolgáltatásban; ez a határ jelentése, és az ellenőrzőlista pontja az, hogy ezt egyértelműen ki kell mondani ahelyett, hogy hagynánk, hogy "a VPN titkosított" álljon "az adatok végponttól végpontig titkosítottak" helyett.

Most vizsgáld meg, mi volt belül. Ha a belső csomag egyszerű szöveges alkalmazásprotokoll, semmi nem ad hozzá bizalmasságot lefelé, amíg valami más nem titkosítja. Ha a belső csomag már TLS-munkamenetet hordoz, a külső IPsec eltávolítása semmit sem változtat azon a munkameneten: védett marad a saját végpontjáig, bárhol is van az a végpont.

A szokásos túlkorrekció annak megállapítása, hogy minden, ami az átjáró mögött van, ki van téve. Nem az. A szolgáltatásforgalom, a tárolás titkosítása és az alkalmazás-TLS külön mechanizmusok külön feltételekkel, és mindegyiket a saját feltételei szerint kell értékelni, nem a VPN alakjából levezetni. Az ACCEPT-et mutató folyamatnapló-bejegyzés bizonyítja, hogy az útválasztás működött, és semmit sem mond a bizalmasságról, ami pontosan az a hiba, amelynek megelőzésére ez az ellenőrzőlista létezik.

3. ellenőrzés: mi zárja le a TLS-t az átjáró mögött

A hallgatót kövesd, ne a címet. Ha egy terheléselosztó vagy proxy zárja le a TLS-t, az ügyfél kapcsolata ott ér véget, és a proxy második kapcsolatot nyit a háttérrendszer felé, amely lehet egyszerű szöveg vagy más bizalmi láncú TLS. Egy privát IP-cím és egy illeszkedő útvonal nem bizonyíték erről a második kapcsolatról.

Teszteld azt a végpontot, amely igazán számít neked, a VPC belsejéből, azzal a névvel, amelyet az alkalmazás használ, nem egy egyszer feloldott IP-vel:

openssl s_client -connect internal.example:443 -servername internal.example -verify_return_error

Ismételd meg minden ugrásra, amelyen a kérés áthalad. Ha a válasz eltér a kliens felé néző név és a háttérrendszer neve között, pontosan azt a szakaszt találtad meg, amelyet a VPN soha nem fedett le, és ez a rögzítendő megállapítás.

Az eredményt szakaszokként rögzítsd, ne ítéletként

Ennek az ellenőrzőlistának a kimenete egy kis táblázat, szakaszonként egy sorral: ügyfélátjárótól az AWS VPN-célig, átjárótól a munkaterhelésig, munkaterheléstől az adattárig, és bármely proxy-ugrás közben. Minden sor megmondja, mi védi, és mitől függ ez a védelem. A "titkosított" mechanizmus és végpont nélkül nem sor.

Ezután válaszolj az eredeti követelményre ugyanazokkal a kifejezésekkel, amelyekkel feltették. Ha a követelmény az, hogy az adatok bizalmasak maradjanak, amíg a munkaterhelés megkapja őket, a VPN csak az első szakaszt teljesíti, a többi sornak pedig alkalmazásforgalomra, szolgáltatás-TLS-re vagy tárolás titkosítására van szüksége, külön beállítva és ellenőrizve.

Őrizd meg a kapcsolatazonosítókat, az alagutak állapotát és a tanúsítványok alanyait a feljegyzésben. Amikor valaki hat hónap múlva visszatér a tervezéshez, ez a három artefaktum percek alatt megválaszolja a határkérdést, ahelyett hogy a vitát egy diagramról újraindítanák.

Kapcsolódó cikkek