Utilice el servicio Bastion para acceder a los recursos de una subred privada
Oracle Cloud Infrastructure Bastion proporciona acceso SSH privado y con límite de tiempo a recursos que no tienen puntos finales públicos.
Bastion es un servicio de infraestructura que puede sustituir a un servidor bastion que cree en Oracle Cloud Infrastructure (OCI). Las bases son gateways o proxies. Son entidades lógicas que proporcionan acceso seguro a los recursos de la nube a los que de lo contrario no se puede acceder desde Internet. Las bases residen en una subred pública y establecen la infraestructura de red necesaria para conectar a un usuario a un recurso de una subred privada.
La integración con Oracle Cloud Infrastructure Identity and Access Management (IAM) permite controlar quién puede gestionar un bastión o una sesión en un servicio de bastión. La integración con Oracle Cloud Infrastructure Audit proporciona una forma de supervisar las acciones administrativas relacionadas con el servicio bastion y las sesiones bastion.
Arquitectura
Esta arquitectura muestra dos formas de conectarse a subredes privadas. Una forma es conectarse a través de una subred de destino intermediaria, y la otra forma es conectarse directamente a la subred que contiene los recursos protegidos.
Al crear un servicio de base, puede especificar una lista de asignaciones de bloques CIDR y un tiempo máximo de actividad de sesión. En la creación del bastión, se establece una ruta de red entre el VCN del bastión y el VCN de cliente mediante una conexión inversa. Normalmente, los usuarios u operadores crean sesiones.
El siguiente diagrama ilustra esta arquitectura de referencia.
Descripción de la ilustración arquitectura- use-bastion-service.png
La arquitectura tiene los siguientes componentes:
- Región
Una región de Oracle Cloud Infrastructure es un área geográfica localizada que contiene uno o más centros de datos, denominados dominios de disponibilidad. Las regiones son independientes de otras regiones, y grandes distancias pueden separarlas (entre países o incluso continentes).
- Dominios de disponibilidad
Los dominios de disponibilidad son centros de datos independientes e independientes dentro de una región. Los recursos físicos de cada dominio de disponibilidad están aislados de los recursos de los demás dominios de disponibilidad, lo que proporciona tolerancia a fallos. Los dominios de disponibilidad no comparten infraestructura, como energía o refrigeración, o la red de dominio de disponibilidad interna. Por lo tanto, es poco probable que un fallo en un dominio de disponibilidad afecte a los otros dominios de disponibilidad de la región.
- Dominios de Fallos
Un dominio de fallo es una agrupación de hardware e infraestructura dentro de un dominio de disponibilidad. Cada dominio de disponibilidad tiene tres dominios de errores con energía y hardware independientes. Al distribuir recursos en varios dominios de errores, las aplicaciones pueden tolerar errores de servidor físico, mantenimiento del sistema y errores de energía dentro de un dominio de errores.
- Red virtual en la nube (VCN) y subredes
VCN es una red personalizable y definida por software que se configura en una región de Oracle Cloud Infrastructure. Al igual que las redes de centros de datos tradicionales, las VCN le proporcionan un control completo sobre su entorno de red. Una VCN puede tener varios bloques CIDR no superpuestos que puede cambiar después de crear VCN. Puede segmentar un VCN en subredes, que se pueden asignar a una región o a un dominio de disponibilidad. Cada subred consta de un rango contiguo de direcciones que no se superponen con las otras subredes de VCN. Puede cambiar el tamaño de una subred después de la creación. Una subred puede ser pública o privada.
- Servicio Bastión
El servicio bastion existe en una infraestructura gestionada por OCI, que no requiere gestión de infraestructura. La infraestructura gestionada es donde se crea el punto final público bastión, lo que permite a los clientes externos conectarse mediante las sesiones previamente definidas.
- Backend de servicio de base
El backend de Bastion Service almacena la configuración de la sesión y las claves públicas SSH que se utilizan para otorgar acceso a los sistemas de destino. Cuando sea necesario, los sistemas de destino utilizan el gateway de servicio para acceder al backend de Bastion Service.
- Punto Final Privado
El punto final privado conecta el servicio de base a las subredes de destino. La subred de destino puede ser una subred independiente, para un control más granular o en la misma subred de las instancias a las que desea acceder
Recomendaciones
Sus requisitos pueden diferir de la arquitectura descrita aquí. Utilice las siguientes recomendaciones como punto de partida.
- VCN
Al crear un VCN, determine el número de bloques CIDR necesarios y el tamaño de cada bloque en función del número de recursos que tiene previsto asociar a subredes en VCN. Utilice bloques CIDR que estén dentro del espacio de direcciones IP privadas estándar.
Seleccione bloques CIDR que no se superpongan con ninguna otra red (en Oracle Cloud Infrastructure, el centro de datos local u otro proveedor de nube) a la que desea configurar conexiones privadas.
Después de crear un VCN, puede cambiar, agregar y eliminar sus bloques CIDR.
Cuando diseñe las subredes, tenga en cuenta sus requisitos de flujo de tráfico y seguridad. Conecte todos los recursos dentro de un nivel o rol específico a la misma subred, que puede servir como límite de seguridad.
Utilice subredes regionales.
Tenga en cuenta que cada bastión aprovisionado toma dos direcciones IP de la subred de destino. Seleccione el bloque CIDR en función del número de bastiones que desea aprovisionar en una subred concreta. Por ejemplo, si tiene una subred con/30 CIDR, significa que tiene dos direcciones utilizables y si en ese CIDR tiene un recurso de destino, no tiene suficientes direcciones para provisionar un bastión. En este caso, el aprovisionamiento de bastiones fallará. Recomendamos que la subred de destino sea más amplia que/29.
- Seguridad
Utilice Oracle Cloud Guard para supervisar y mantener la seguridad de sus recursos en Oracle Cloud Infrastructure de forma proactiva. Cloud Guard utiliza recetas de detectores que puede definir para examinar sus recursos para detectar deficiencias de seguridad y para supervisar a los operadores y usuarios para realizar actividades de riesgo. Cuando se detecta cualquier actividad incorrecta o insegura, Cloud Guard recomienda acciones correctivas y ayuda a tomar esas acciones, en función de las recetas de respuesta que pueda definir.
Para los recursos que requieren la máxima seguridad, Oracle recomienda utilizar zonas de seguridad. Una zona de seguridad es un compartimento asociado a una receta definida por Oracle de políticas de seguridad que se basan en las mejores prácticas. Por ejemplo, los recursos de una zona de seguridad no deben ser accesibles desde el Internet público y deben cifrarse mediante claves gestionadas por el cliente. Al crear y actualizar recursos en una zona de seguridad, Oracle Cloud Infrastructure valida las operaciones con las políticas de la receta de zona de seguridad y niega las operaciones que violan cualquiera de las políticas.
- Base de OCI
TTL a nivel de bastión garantizará que ninguna de las sesiones creadas en el contexto de ese bastión tenga TTL más que el bastión. Debe establecer el TTL en el límite mínimo según su caso de uso. El mínimo es de 30 minutos y el máximo es de 3 horas. El TTL también se puede configurar en el nivel de sesión.
El bloque CIDR de la lista de permisos debe ser lo más estrecho posible según el escenario. Con esto, puede restringir los rangos de direcciones IP desde donde se permiten las conexiones SSH a los recursos de destino privados.
Se debe pensar en el tamaño de la subred de destino a la que se crea un bastión. Cada creación de bastión toma 2 direcciones IP. Por lo tanto, es mejor tener un rango/29 al menos para que tenga 6 direcciones IP utilizables. /30 tendría 2 direcciones IP, pero si en el futuro desea que la segunda instancia del bastión apunte a la misma subred, no podrá crearla. Recuerde que la subred de destino puede ser la subred desde la que está presente el recurso de destino o desde la que otras subredes de VCN de destino pueden permitir el tráfico.
Recomendaciones sobre políticas de seguridad
- Las reglas de entrada en la subred que tiene los recursos de destino deben permitir el tráfico TCP entrante desde una sola dirección IP que es la IP de punto final privada del bastión.
- Especifique el puerto exacto en un destino como 22 para Linux, 3389 para ventanas, 33060 para MySql, etc. Abstenerse de usar TODOS los puertos.
Utilice políticas de IAM específicas para escenarios de administrador y operador.
Consideraciones
- Región
Bastión es un servicio regional. Por ejemplo, los clientes necesitarían crear un bastión en PHX para acceder a los recursos de PHX. Por ejemplo, no se puede utilizar un bastión en PHX para acceder a recursos en IAD.
- Rendimiento
La creación de base debe estar dentro del SLO (2 minutos en la creación de la solicitud). La creación/terminación de sesión debe estar dentro del SLO. El reenvío de puertos es de 1 minutos (escenario de ruptura) y la sesión SSH gestionada es de 3 minutos. (uso normal)
- Seguridad
El tráfico desde bastión proviene del punto final privado de la subred. Con el fin de permitir el tráfico desde bastiones, permitir el tráfico de entrada y salida desde este punto final privado a los IP a los que se debe acceder a través de bastiones. Las políticas detalladas que restringen el acceso a un subconjunto de instancias ayudan a garantizar el nivel adecuado de acceso.
- Disponibilidad
El servicio debe proporcionar alta disponibilidad para crear/terminar bastiones y sesiones (basado en el ratio de errores de API). La disponibilidad objetivo es del 99.9%.
- Costo
No hay costo para utilizar OCI Bastion. Los clientes pueden crear hasta cinco bastiones por región por arrendamiento. Cada bastión sirve los recursos de destino en una VCN.
- Casos de Uso
Si el cliente desea acceder a hosts de destino privados que ejecutan imágenes nativas de OCI, están basados en Linux y ejecutan el agente v2 de OCA (con el plugin bastion activado en él), puede utilizar sesiones SSH gestionadas. Si el cliente desea acceder a recursos de destino privados que no tienen el agente en ejecución, están basados en Windows o tienen acceso a bases de datos (ATP o MySQL), puede utilizar sesiones SSH de reenvío de puertos.