Las traducciones son generadas a través de traducción automática. En caso de conflicto entre la traducción y la version original de inglés, prevalecerá la version en inglés.
Seguridad de la infraestructura en AWS Transfer Family
Como servicio gestionado, AWS Transfer Family está protegido por la seguridad de la red AWS global. Para obtener información sobre los servicios AWS de seguridad y cómo se AWS protege la infraestructura, consulte Seguridad AWS en la nube
Utiliza las llamadas a la API AWS publicadas para acceder a AWS Transfer Family través de la red. Los clientes deben admitir lo siguiente:
-
Seguridad de la capa de transporte (TLS). Exigimos TLS 1.2 y recomendamos TLS 1.3.
-
Conjuntos de cifrado con confidencialidad directa total (PFS) como DHE (Ephemeral Diffie-Hellman) o ECDHE (Elliptic Curve Ephemeral Diffie-Hellman). La mayoría de los sistemas modernos como Java 7 y posteriores son compatibles con estos modos.
Evite colocarlos NLBs y NATs delante de los AWS Transfer Family servidores
nota
Los servidores configurados con los protocolos FTP y FTPS solo permiten una configuración con una VPC: no hay ningún punto final público disponible para FTP/FTPS.
Muchos clientes configuran un Network Load Balancer (NLB) para enrutar el tráfico a su servidor. AWS Transfer Family Por lo general, lo hacen porque crearon su servidor antes de que AWS se les ofreciera una forma de acceder a él desde su VPC y desde Internet, o para admitir FTP en Internet. Esta configuración no solo aumenta los costes para los clientes, sino que también puede provocar otros problemas, que se describen en esta sección.
Las pasarelas NAT son un componente obligatorio cuando los clientes se conectan desde la red privada de un cliente a través de un firewall corporativo. Sin embargo, debe tener en cuenta que cuando muchos clientes están detrás de la misma puerta de enlace NAT, esto puede afectar al rendimiento y a los límites de conexión. Si hay un NLB o NAT en la ruta de comunicación entre el cliente y el servidor FTP o FTPS, el servidor no puede reconocer con precisión la dirección IP del cliente, ya que solo AWS Transfer Family ve la dirección IP del NLB o NAT.
Si utiliza la configuración de un servidor Transfer Family detrás de un NLB, le recomendamos que se traslade a un punto final de VPC y utilice una dirección IP elástica en lugar de utilizar un NLB. Cuando utilice puertas de enlace NAT, tenga en cuenta las limitaciones de conexión que se describen a continuación.
Si utiliza el protocolo FTPS, esta configuración no solo reduce su capacidad de auditar quién accede a su servidor, sino que también puede afectar al rendimiento. AWS Transfer Family utiliza la dirección IP de origen para dividir las conexiones en nuestro plano de datos. En el caso de FTPS, esto significa que, en lugar de tener 10 000 conexiones simultáneas, los servidores Transfer Family con puertas de enlace NLB o NAT en la ruta de comunicación están limitados a solo 300 conexiones simultáneas.
Si bien recomendamos evitar los balanceadores de carga de red delante de AWS Transfer Family los servidores, si la implementación de FTP o FTPS requiere un NLB o NAT en la ruta de comunicación del cliente, siga estas recomendaciones:
-
En el caso de un NLB, utilice el puerto 21 para las comprobaciones de estado, en lugar de los puertos 8192-8200.
-
Para el AWS Transfer Family servidor, habilite la reanudación de la sesión TLS mediante la configuración.
TlsSessionResumptionMode = ENFORCEDnota
Este es el modo recomendado, ya que proporciona una seguridad mejorada:
-
Requiere que los clientes utilicen la reanudación de la sesión TLS para las conexiones posteriores.
-
Ofrece garantías de seguridad más sólidas al garantizar la coherencia de los parámetros de cifrado.
-
Ayuda a prevenir posibles ataques de degradación.
-
Mantiene el cumplimiento de los estándares de seguridad a la vez que optimiza el rendimiento.
-
-
Si es posible, deje de usar un NLB para aprovechar al máximo los límites de AWS Transfer Family rendimiento y conexión.
Para obtener más información sobre las alternativas de NLB, póngase en contacto con el equipo de gestión de AWS Transfer Family productos a través de AWS Support. Para obtener más información sobre cómo mejorar su postura de seguridad, consulte la entrada del blog Seis consejos para mejorar la seguridad de su AWS Transfer Family servidor
Seguridad de la infraestructura de conectividad de VPC
Los conectores SFTP con salida de VPC proporcionan una seguridad de infraestructura mejorada mediante el aislamiento de la red y la conectividad privada:
Ventajas del aislamiento de la red
-
Tráfico de red privada: todo el tráfico de los conectores a los servidores SFTP privados permanece dentro de la VPC y nunca pasa por la Internet pública.
-
Salida controlada: en el caso de los puntos finales públicos a los que se accede mediante VPC, el tráfico se enruta a través de las puertas de enlace NAT, lo que le permite controlar las direcciones IP de salida y las políticas de red.
-
Controles de seguridad de VPC: aproveche los grupos de seguridad de VPC, la red y las tablas de enrutamiento existentes para controlar el acceso a la red ACLs de los conectores.
-
Conectividad híbrida: acceda a los servidores SFTP locales a través de conexiones VPN o Direct Connect establecidas sin exposición adicional a Internet.
Resource Gateway: consideraciones de seguridad
Las pasarelas de recursos proporcionan puntos de entrada seguros para el acceso a los recursos entre VPC:
-
Implementación en zonas de disponibilidad múltiples: las pasarelas de recursos requieren subredes en al menos dos zonas de disponibilidad para lograr una alta disponibilidad y tolerancia a los errores.
-
Controles de grupos de seguridad: configure los grupos de seguridad para restringir el acceso a los puertos SFTP (normalmente el puerto 22) únicamente desde fuentes autorizadas.
-
Ubicación de subredes privadas: implemente pasarelas de recursos en subredes privadas cuando se conecte a servidores SFTP privados para mantener el aislamiento de la red.
-
Límites de conexión: cada Resource Gateway admite hasta 350 conexiones simultáneas con un tiempo de espera de 350 segundos para las conexiones TCP.