Session Manager utan öppna portar

Session Manager, en funktion i AWS Systems Manager (SSM), ger interaktiv shell-åtkomst till EC2-instanser och lokala servrar utan att några inkommande portar öppnas. Det är viktigt att förstå exakt hur detta fungerar inför provet, eftersom det ligger till grund för modern administration utan bastioner.

Det hela börjar med SSM Agent, en programvara som är förinstallerad på de flesta AWS AMI:er (Amazon Machine Images). Agenten körs på instansen och initierar en utgående anslutning till Systems Manager-tjänstens endpoints. Eftersom instansen själv ansluter utåt behövs aldrig någon inkommande regel; säkerhetsgruppen kan blockera all inkommande trafik.

För att SSM ska fungera behöver instansen en IAM-roll (via sin instansprofil) som ger Systems Manager-behörigheter, vanligtvis den hanterade policyn AmazonSSMManagedInstanceCore. Utan denna roll kan agenten inte registrera sig, så att koppla rätt roll är det första felsökningssteget när en instans inte visas som en hanterad nod.

Session Manager fungerar även för instanser i privata subnät utan publik IP-adress. Agenten når SSM antingen via en NAT-gateway eller, säkrare, via VPC-gränssnittsendpoints (PrivateLink) för ssm, ssmmessages och ec2messages. Endpoints håller all trafik i AWS-nätverket utan att den någonsin går ut på internet.

En auktoriserad användare startar en session från konsolen, CLI:t eller SDK:t. Kommandot nedan öppnar ett shell på en hanterad instans utan att någon SSH-klient, nyckel eller öppen port behövs. IAM avgör om användaren över huvud taget får starta sessionen.

Vem som får öppna en session styrs helt av IAM-principer för åtgärden ssm:StartSession. Du kan begränsa åtkomsten till specifika instanser med hjälp av taggar, begränsa vilka användare som får ansluta och även styra vilka SSM-dokument (sessionstyper) de får använda. Detta ersätter distribution av SSH-nycklar med centraliserad och granskningsbar IAM-kontroll.

Ett kraftfullt mönster är att begränsa sessionsåtkomst med en instanss tagg. En policy kan tillåta ssm:StartSession endast på instanser med taggen, exempelvis Environment=Dev, så att utvecklare når utvecklingsmaskiner men aldrig produktion. Denna attributbaserade kontroll skalar smidigt och tillämpar minsta privilegium utan policyer för varje enskild instans.

Sessionsdata är krypterad under överföring med TLS, och du kan kräva KMS-kryptering för sessionskanalen för ytterligare säkerhet. Tillsammans med avsaknaden av öppna portar innebär detta att administrativ trafik både är osynlig för internet och skyddad från början till slut, vilket uppfyller strikta efterlevnadskrav.

Session Manager stöder även portvidarebefordran, där en port från din dator tunnlas till en port på instansen (eller vidare) via den säkra SSM-kanalen. Det gör att du kan nå RDP eller en databas utan att exponera portarna publikt, vilket eliminerar ännu ett skäl till att team tidigare använde bastioner.

Säkerhetsmodellen är övertygande: inga inkommande portar att angripa, inga SSH-nycklar som kan läcka, IAM-baserad åtkomstkontroll, valfria privata endpoints och kryptering överallt. Alla svagheter i traditionell fjärråtkomst hanteras, vilket är anledningen till att provet betraktar Session Manager som standardsvaret för säker administration.

Session Manager använder en utgående SSM Agent tillsammans med en instansroll med AmazonSSMManagedInstanceCore för att ge shell-åtkomst med inga inkommande portar, ingen publik IP-adress och inga nycklar. Åtkomsten styrs av IAM (ssm:StartSession), begränsas med taggar, krypteras under överföring och kan nås privat via VPC-endpoints. Tjänsten stöder även säker portvidarebefordran.

Session Manager ger shell-åtkomst via den utgående SSM Agent och en instansroll (AmazonSSMManagedInstanceCore) och kräver inga inkommande portar, ingen publik IP-adress och inga nycklar. Åtkomsten styrs av IAM (ssm:StartSession), begränsas med taggar, krypteras med TLS/KMS och fungerar privat via VPC-endpoints för ssm, ssmmessages och ec2messages. Tjänsten stöder även säker portvidarebefordran.