Die vorliegende Übersetzung wurde maschinell erstellt. Im Falle eines Konflikts oder eines Widerspruchs zwischen dieser übersetzten Fassung und der englischen Fassung (einschließlich infolge von Verzögerungen bei der Übersetzung) ist die englische Fassung maßgeblich.
Sicherheit der Infrastruktur in AWS Transfer Family
Als verwalteter Dienst AWS Transfer Family ist er durch AWS globale Netzwerksicherheit geschützt. Informationen zu AWS Sicherheitsdiensten und zum AWS Schutz der Infrastruktur finden Sie unter AWS Cloud-Sicherheit
Für den Zugriff AWS Transfer Family über das Netzwerk verwenden Sie AWS veröffentlichte API-Aufrufe. Kunden müssen Folgendes unterstützen:
-
Transport Layer Security (TLS). Wir benötigen TLS 1.2 und empfehlen TLS 1.3.
-
Verschlüsselungssammlungen mit Perfect Forward Secrecy (PFS) wie DHE (Ephemeral) oder ECDHE (Elliptic Curve Ephemeral Diffie-Hellman). Diffie-Hellman Die meisten modernen Systeme wie Java 7 und höher unterstützen diese Modi.
Vermeiden Sie es, NLBs und NATs vor AWS Transfer Family Server
Anmerkung
Server, die mit FTP- und FTPS-Protokollen konfiguriert sind, ermöglichen nur eine Konfiguration mit einer VPC: Für ist kein öffentlicher Endpunkt verfügbar. FTP/FTPS
Viele Kunden konfigurieren einen Network Load Balancer (NLB), um den Datenverkehr an ihren Server weiterzuleiten. AWS Transfer Family In der Regel tun sie dies entweder, weil sie ihren Server zuvor erstellt haben und ihnen eine Möglichkeit AWS geboten haben, sowohl von ihrer VPC als auch vom Internet aus darauf zuzugreifen, oder weil sie FTP im Internet unterstützen. Diese Konfiguration erhöht nicht nur die Kosten für Kunden, sondern kann auch zu anderen Problemen führen, die wir in diesem Abschnitt beschreiben.
NAT-Gateways sind eine obligatorische Komponente, wenn Clients von einem privaten Kundennetzwerk hinter einer Unternehmensfirewall aus eine Verbindung herstellen. Beachten Sie jedoch, dass sich dies auf die Leistung und die Verbindungsbeschränkungen auswirken kann, wenn sich viele Clients hinter demselben NAT-Gateway befinden. Wenn sich auf dem Kommunikationspfad vom Client zum FTP- oder FTPS-Server ein NLB oder NAT befindet, kann der Server die IP-Adresse des Clients nicht genau erkennen, da AWS Transfer Family nur die IP-Adresse des NLB oder NAT angezeigt wird.
Wenn Sie die Konfiguration eines Transfer Family-Servers hinter einem NLB verwenden, empfehlen wir Ihnen, zu einem VPC-Endpunkt zu wechseln und eine Elastic IP-Adresse anstelle eines NLB zu verwenden. Beachten Sie bei der Verwendung von NAT-Gateways die unten beschriebenen Verbindungsbeschränkungen.
Wenn Sie das FTPS-Protokoll verwenden, reduziert diese Konfiguration nicht nur Ihre Möglichkeiten, zu überprüfen, wer auf Ihren Server zugreift, sondern sie kann sich auch auf die Leistung auswirken. AWS Transfer Family verwendet die Quell-IP-Adresse, um Ihre Verbindungen auf unserer Datenebene gemeinsam zu nutzen. Für FTPS bedeutet dies, dass Server der Transfer Family mit NLB- oder NAT-Gateways auf der Kommunikationsroute nicht über 10.000 gleichzeitige Verbindungen verfügen, sondern auf nur 300 gleichzeitige Verbindungen beschränkt sind.
Wir empfehlen zwar, Network Load Balancer vor AWS Transfer Family Servern zu vermeiden, aber wenn Ihre FTP- oder FTPS-Implementierung einen NLB oder NAT auf der Kommunikationsroute vom Client erfordert, folgen Sie diesen Empfehlungen:
-
Verwenden Sie für einen NLB Port 21 für Integritätsprüfungen anstelle der Ports 8192-8200.
-
Aktivieren Sie für den AWS Transfer Family Server die Wiederaufnahme der TLS-Sitzung, indem Sie Folgendes festlegen.
TlsSessionResumptionMode = ENFORCEDAnmerkung
Dies ist der empfohlene Modus, da er eine erhöhte Sicherheit bietet:
-
Erfordert, dass die Clients die TLS-Sitzungswiederaufnahme für nachfolgende Verbindungen verwenden.
-
Bietet stärkere Sicherheitsgarantien, indem konsistente Verschlüsselungsparameter gewährleistet werden.
-
Hilft, potenzielle Downgrade-Angriffe zu verhindern.
-
Sorgt für die Einhaltung der Sicherheitsstandards und optimiert gleichzeitig die Leistung.
-
-
Wenn möglich, sollten Sie von der Verwendung eines NLB abrücken, um die AWS Transfer Family Leistungs- und Verbindungsbeschränkungen voll auszuschöpfen.
Für weitere Informationen zu NLB-Alternativen wenden Sie sich über AWS den Support an das AWS Transfer Family Produktmanagementteam. Weitere Informationen zur Verbesserung Ihrer Sicherheitslage finden Sie im Blogbeitrag Sechs Tipps zur Verbesserung der Sicherheit Ihres AWS Transfer Family Servers
Sicherheit der VPC-Konnektivität und Infrastruktur
SFTP-Konnektoren mit VPC-Ausgang bieten eine verbesserte Infrastruktursicherheit durch Netzwerkisolierung und private Konnektivität:
Vorteile der Netzwerkisolierung
-
Privater Netzwerkverkehr: Der gesamte Connector-Verkehr zu privaten SFTP-Servern verbleibt in Ihrer VPC und durchquert niemals das öffentliche Internet.
-
Kontrollierter Ausgang: Bei öffentlichen Endpunkten, auf die über VPC zugegriffen wird, wird der Datenverkehr über Ihre NAT-Gateways geleitet, sodass Sie die Kontrolle über ausgehende IP-Adressen und Netzwerkrichtlinien haben.
-
VPC-Sicherheitskontrollen: Nutzen Sie vorhandene VPC-Sicherheitsgruppen, Netzwerk-ACLs und Routing-Tabellen, um den Connector-Netzwerkzugriff zu steuern.
-
Hybride Konnektivität: Greifen Sie über etablierte VPN- oder Direct Connect-Verbindungen auf lokale SFTP-Server zu, ohne dass das Internet zusätzlich gefährdet ist.
Überlegungen zur Sicherheit von Resource Gateway
Resource Gateways bieten sichere Zugangspunkte für Cross-VPC Resource Access:
-
Multi-AZ Bereitstellung: Resource Gateways benötigen Subnetze in mindestens zwei Availability Zones, um eine hohe Verfügbarkeit und Fehlertoleranz zu gewährleisten.
-
Sicherheitsgruppensteuerung: Konfigurieren Sie Sicherheitsgruppen, um den Zugriff auf SFTP-Ports (normalerweise Port 22) nur von autorisierten Quellen aus einzuschränken.
-
Platzierung privater Subnetze: Stellen Sie Resource Gateways in privaten Subnetzen bereit, wenn Sie eine Verbindung zu privaten SFTP-Servern herstellen, um die Netzwerkisolierung aufrechtzuerhalten.
-
Verbindungsbeschränkungen: Jedes Resource Gateway unterstützt bis zu 350 gleichzeitige Verbindungen mit einem Leerlaufzeitlimit von 350 Sekunden für TCP-Verbindungen.