Ověřování v AWS Client VPN: oprávnění IAM nejsou způsob přihlášení

Když uživateli udělíte oprávnění vytvořit nebo popsat endpoint AWS Client VPN, neznamená to, že se k němu tento uživatel může připojit. Jde o dva různé druhy identity: IAM řídí volání AWS API a endpoint přijímá jen metody ověřování klienta, které jsou na něm nakonfigurované. Uživatel tedy může mít široká práva v konzoli a přesto nemít nic, co by klient VPN mohl předložit. Rozhodněte, které metodě endpoint důvěřuje, a potom rozhodněte, zda je plný tunel správný tvar pro přístup, který udělujete.

Identita API není identita tunelu

Když někdo řekne „role IAM je připojená, proč VPN pořád nefunguje“, odpověď obvykle je, že žádný krok v toku připojení tuto roli nečte. Klient předloží certifikát, uživatelské jméno a heslo AD, nebo tvrzení SAML. Endpoint jedno z toho ověří a potom přidělí adresu.

IAM je pořád důležitý, jen později a jinde: vytvoření endpointu, přidružení podsítí, publikování tras a psaní autorizačních pravidel jsou akce API. Držte tato oprávnění omezená na operátory, kteří je potřebují, místo abyste každému uživateli dávali možnost přepsat přístupová pravidla endpointu.

Vybírejte z metod, které endpoint podporuje

AWS Client VPN přijímá vzájemné ověřování certifikátem, ověřování přes Active Directory a federované ověřování založené na SAML. Certifikát serveru je vyžadován bez ohledu na to, kterou klientskou metodu zvolíte, a konfigurace, která metody kombinuje, vyžaduje úspěch obou, ne jedné.

Certifikáty se nejlevněji zavádějí a nejsnáze se ve velkém pokazí, protože každý uživatel potřebuje pověření a každý odchod vyžaduje odvolání. Ověřování přes adresář přesouvá tento životní cyklus do existujícího systému. Federace ho přesouvá k poskytovateli identity a přidává ke klientovi krok v prohlížeči.

Přečtěte si vlastní konfiguraci endpointu, než začnete ladit klienta. Pokud je vzájemné ověřování zapnuté vedle metody založené na uživateli, klient s platným certifikátem, ale bez účtu v adresáři, stále selže a chyba obvykle vypadá jako obecný problém s handshake.

Federace není předávání přístupových klíčů

Nastavení SAML nepředává do tunelu přístupové klíče IAM ani token převzaté role. Poskytovatel identity ověří osobu, vrátí tvrzení a endpoint ho přijme v rámci důvěry, kterou jste nastavili. Výsledná relace je relace VPN, ne relace AWS API.

Tento rozdíl určuje, kdo může co diagnostikovat. Problémy s IdP se projeví jako chyba prohlížeče nebo klienta ještě předtím, než tunel existuje, zatímco problémy s tunelem se projeví po úspěšném tvrzení. Zeptejte se, na kterou z těch dvou věcí se díváte, než otevřete kteroukoli konzoli.

Po přihlášení stále rozhodují trasy a autorizace

Ověření dá relaci adresu; nedá jí cíl. Trasy endpointu říkají klientovi, do kterých podsítí má posílat, autorizační pravidla rozhodují, kteří uživatelé mohou dosáhnout kterých z těchto podsítí, a o zbytku rozhodují bezpečnostní skupiny a vlastní oprávnění cíle.

Proto uživatel, který se úspěšně ověří, může stále nedosáhnout databáze. Zkontrolujte přidružení směrovací tabulky k podsíti, autorizační pravidlo pro skupinu uživatele a bezpečnostní skupinu na cíli v tomto pořadí, protože každé z nich vytváří jiný druh vypršení.

Pro jednu privátní databázi porovnejte s přesměrováním portů

Pokud je skutečným úkolem jedno schválené připojení k jedné privátní databázi, je plný síťový tunel volbou, ne požadavkem. AWS Systems Manager Session Manager může přes IAM otevřít relaci přesměrování portu ke spravovanému uzlu a tento uzel dosáhne databáze v privátní síti. Uživatel nikdy nedostane adresu VPC. Spravovaný uzel se stane jediným hostitelem, který může dosáhnout portu databáze, což je obvykle to, co bezpečnostní revize chtěla. Uživatelé pak potřebují lokálního klienta a příkaz relace místo profilu VPN.

Kompromis je rozsah proti předpokladům. Přesměrování portů potřebuje agenta SSM na spravovaném uzlu, síťovou dostupnost z tohoto uzlu do databáze, plugin Session Manager na uživatelově počítači a oprávnění spustit právě tuto relaci. Není to cesta do každé podsítě a nepřenese libovolné protokoly tak jako tunel.

V obou případech ponechte vlastní identitu databáze na místě. Ověření TLS a ověřování v databázi nezmizí jen proto, že cesta byla autorizována přes IAM, a schválená relace nic neříká o tom, které tabulky uživatel smí číst.

Vybírejte podle rozsahu a životního cyklu: tunel, když mnoho uživatelů potřebuje mnoho cílů a můžete provozovat životní cyklus certifikátů nebo adresáře; relaci přesměrování, když několik lidí potřebuje jednu službu a raději nechcete rozdávat síťové adresy. V obou případech zaznamenejte metodu ověřování, autorizační pravidlo a přihlášení do databáze jako tři oddělená fakta, protože selhávají odděleně.