Protección de Networking: VCN, equilibradores de carga y DNS

Recomendaciones de seguridad

El servicio Networking tiene una recopilación de funciones para aplicar el control de acceso de red y proteger el tráfico de VCN. En la siguiente tabla se muestran estas funciones.

Función de VCN Descripción de seguridad
Subredes públicas y privadas Su VCN se puede particionar en subredes. Las subredes han sido siempre específicas de un dominio de disponibilidad, pero ahora pueden ser regionales (abarcan todos los dominios de disponibilidad de la región). Las instancias dentro de subredes privadas no pueden tener direcciones IP públicas. Las instancias dentro de subredes públicas pueden tener direcciones IP públicas a su discreción.
Reglas de seguridad Las reglas de seguridad proporcionan capacidad de firewall con estado y sin estado para controlar el acceso de red en las instancias. Para implementar reglas de seguridad en su VCN, puede usar grupos de seguridad de red (NSG) o listas de seguridad. Para obtener más información, consulte Comparación de listas de seguridad y grupos de seguridad de red.
Gateways

Los gateways permiten a los recursos en una VNC comunicarse con los destinos fuera de la VCN. Entre los gateways se incluyen:

Reglas de tablas de rutas Las tablas de rutas controlan cómo se direcciona el tráfico desde las subredes de la VCN a los destinos fuera de la VCN. Los destinos de direccionamiento pueden ser gateways de VCN o direcciones IP privadas en la VCN.
Políticas de IAM para virtual-network-family Las políticas de IAM especifican el acceso y las acciones permitidas por los grupos de IAM en recursos de una VCN. Por ejemplo, las políticas de IAM pueden dar privilegios administrativos a los administradores de red que gestionen las VCN y acotar permisos a los usuarios normales.

Oracle recomienda supervisar periódicamente los logs de Oracle Cloud Infrastructure Audit para revisar los cambios en los grupos de seguridad de red de VCN, las listas de seguridad, las reglas de tablas de rutas y los gateways de VCN.

Segmentación de red: subredes de VCN

  • Formule una estrategia de subred por niveles para la VCN a fin de controlar el acceso de red. Un patrón de diseño común es tener los siguientes niveles de subred:

    1. Subred DMZ para equilibradores de carga.
    2. Subred pública para hosts a los que se puede acceder externamente, como instancias de NAT, instancias de detección de intrusiones (IDS) y servidores de aplicaciones web
    3. Subred privada para hosts internos como bases de datos.

    No se requiere ningún direccionamiento especial para que las instancias de las distintas subredes se comuniquen. Sin embargo, puede controlar los tipos de tráfico entre los diferentes niveles utilizando las listas de seguridad o los grupos de seguridad de red de la VCN.

  • Las instancias de la subred privada solo tienen direcciones IP privadas y solo otras instancias de la VCN pueden acceder a ellas. Oracle recomienda colocar los hosts sensibles a la seguridad (sistemas de base de datos, por ejemplo) en una subred privada y utilizar reglas de seguridad para controlar el tipo de conectividad a los hosts en una subred pública. Además de las reglas de seguridad de VCN, configure firewalls basados en host, como iptables, firewalld para el control de acceso de red, como mecanismo de protección exhaustiva.
  • Puede agregar un gateway de servicio a su VCN para permitir que los sistemas de base de datos de la subred privada realicen una copia de seguridad directamente en Object Storage sin que el tráfico pase por Internet. Debe configurar las reglas de seguridad y direccionamiento para permitir dicho tráfico. Para obtener más información sobre los sistemas de base de datos de máquina virtual o hardware dedicado, consulte Configuración de la red. Para obtener más información sobre los sistemas de base de datos Exadata, consulte Configuración de red para instancias de Exadata Cloud Service.

Control de acceso de red: reglas de seguridad de VCN

  • Utilice las reglas de seguridad de la VCN para restringir el acceso de red en las instancias. Por defecto, una regla de seguridad tiene estado, pero también se puede configurar para que no tenga estado. Una práctica común es utilizar reglas sin estado para aplicaciones de alto rendimiento. En el caso de que el tráfico de red coincida con las listas de seguridad con estado y sin estado, la regla sin estado tendrá prioridad. Para obtener más información sobre la configuración de reglas de seguridad de VCN, consulte Reglas de seguridad.
  • Para evitar el acceso no autorizado o ataques en instancias de Compute, Oracle recomienda que utilice una regla de seguridad de VCN para permitir el acceso SSH o RDP solo desde bloques de CIDR autorizados en lugar de dejarlos abiertos a Internet (0.0.0.0/0). Para mayor seguridad, puede activar temporalmente el acceso SSH (puerto 22) o RDP (puerto 3389) según sea necesario mediante la API de VCN UpdateNetworkSecurityGroupSecurityRules (si está utilizando grupos de seguridad de red) o UpdateSecurityList (si está utilizando listas de seguridad). Para obtener más información sobre la activación del acceso RDP, consulte Para activar el acceso RDP en Creación de una instancia. Para realizar comprobaciones de estado de instancias, Oracle recomienda configurar las reglas de seguridad de VCN para permitir pings ICMP. Para obtener más información, consulte Reglas para activar el ping.
  • Las bases son entidades lógicas que proporcionan acceso público seguro a los recursos de destino en la nube a los que, de lo contrario, no puede acceder desde Internet. Las basciones residen en una subred pública y establecen la infraestructura de red necesaria para conectar un usuario a un recurso de destino en una subred privada.
  • Las listas de seguridad y los grupos de seguridad de red (NSG) de VCN permiten el control de acceso de red crítico con la seguridad en las instancias informáticas, y es importante evitar cambios no intencionados o no autorizados en las listas de seguridad y los NSG. Para evitar cambios no autorizados, Oracle recomienda utilizar las políticas de IAM para permitir que solo los administradores de red realicen cambios en las listas de seguridad y los NSG.

Conectividad segura: intercambio de tráfico de FastConnect y gateways de VCN

  • Los gateways de VCN proporcionan conectividad externa (Internet, local o VCN intercambiada) a los hosts de VCN. Consulte la tabla anterior de este tema para obtener una lista de los tipos de gateways. Oracle recomienda utilizar una política de IAM para permitir que solo los administradores de red creen o modifiquen gateways de VCN.
  • Considere detenidamente permitir el acceso a Internet a cualquier instancia. Por ejemplo, no desea permitir accidentalmente el acceso de Internet en instancias de base de datos confidenciales. Para que una instancia de VCN sea accesible públicamente desde Internet, debe configurar las siguientes opciones de VCN:

    • La instancia debe estar en una subred pública de VCN.
    • La VCN que contiene la instancia debe tener un gateway de Internet activado y configurado para ser el destino de direccionamiento para el tráfico saliente.
    • La instancia debe tener una dirección IP pública asignada.
    • La lista de seguridad de VCN para la subred de la instancia debe estar configurada para permitir el tráfico entrante desde 0.0.0.0/0. O bien, si usa grupos de seguridad de red (NSG), la instancia debe estar en un NSG que permita dicho tráfico.
  • La VPN con IPSec proporciona conectividad entre la red local de un cliente y la VCN. Puede crear dos túneles de IPSec para alta disponibilidad. Para obtener más información sobre la creación de túneles de VPN para conectar DRG de VCN a CPU del cliente, consulte VPN de sitio a sitio.
  • El intercambio de tráfico de FastConnect permite conectar la red local a su VCN con un circuito privado para que el tráfico no pase por la red pública de Internet. Puede configurar el intercambio de tráfico privado (para conectarse a direcciones IP privadas) o el intercambio de tráfico público (para conectarse a puntos finales públicos de Oracle Cloud Infrastructure, como de Object Storage). Para obtener información sobre las opciones de intercambio de tráfico de FastConnect, consulte FastConnect.

Aplicaciones de seguridad virtual en una VCN

  • El servicio Networking permite implantar funciones de seguridad de red, como detección de intrusiones, firewalls de nivel de aplicación y NAT (aunque puede utilizar un gateway de NAT con la VCN). Para ello, puede direccionar todo el tráfico de subred a un host de seguridad de red mediante reglas de tablas de rutas que utilizan una dirección IP privada de VCN local como destino. Para obtener más información, consulte Utilización de una IP privada como destino de ruta. Para una alta disponibilidad, puede asignar al host de seguridad de gateway una dirección IP privada secundaria, que puede transferir a una VNIC en un host en espera en caso de fallo del host primario. Se pueden capturar logs completos de flujos de red o captura de paquetes de red en las instancias NAT mediante tcpdump, y los logs se pueden cargar periódicamente en un cubo de Object Storage.

  • Las aplicaciones de seguridad virtual se pueden ejecutar como máquinas virtuales (VM) en un modelo de servidor propio (BYOH) en una instancia con hardware dedicado. Las máquinas virtuales de aplicaciones de seguridad virtual que se ejecutan en la instancia con hardware dedicado BYOH tienen su propia VNIC secundaria, lo que proporciona conectividad directa a otras instancias y servicios en la VCN de VNIC. Para obtener información sobre la activación de BYOH en una instancia con hardware dedicado mediante un hipervisor KVM de código abierto, consulte Traiga su propio sistema operativo invitado de hipervisor.
  • Las aplicaciones de seguridad virtual también se pueden instalar en las máquinas virtuales de cálculo donde las imágenes VMDK o QCOW2 de las aplicaciones de seguridad se pueden importar usando la función Traer su propia imagen (BYOI). Sin embargo, debido a dependencias de infraestructura, es posible que la función BYOI no funcione para algunas aplicaciones, en cuyo caso, el modelo BYOH sería otra opción para usar. Para obtener más información sobre la importación de imágenes de aplicaciones en Oracle Cloud Infrastructure, consulte Traiga su propia imagen (BYOI).

Equilibradores de carga

  • Los equilibradores de carga de Oracle Cloud Infrastructure permiten conexiones TLS completas entre las aplicaciones y una VCN de un cliente. La conexión TLS se puede terminar en un equilibrador de carga HTTP o en un servidor backend mediante un equilibrador de carga TCP. Los equilibradores de carga utilizan TLS1.2 por defecto. Para obtener información sobre la configuración de un listener HTTPS, consulte Listeners for Load Balancers. También puede cargar sus propios certificados TLS. Para obtener más información, consulte Certificados SSL para equilibradores de carga.
  • Puede configurar el acceso de red para equilibradores de carga mediante listas de seguridad de red o grupos de seguridad de red de VCN. Este método proporciona una funcionalidad similar a los firewalls de equilibradores de carga tradicionales. Para los equilibradores de carga públicos, Oracle recomienda utilizar una subred pública regional (por ejemplo, subred DMZ) para instanciar los equilibradores de carga en una configuración de alta disponibilidad en dos dominios de disponibilidad diferentes. Puede configurar las reglas de firewall del equilibrador de carga mediante la configuración de los grupos de seguridad de red del equilibrador de carga o las listas de seguridad de la subred. Para obtener más información sobre la creación de listas de seguridad del equilibrador de carga, consulte Actualización de listas de seguridad del equilibrador de carga y uso permitido del tráfico de Internet al listener. De forma similar, debe configurar las listas de seguridad o los grupos de seguridad de red de VCN para servidores backend para limitar el tráfico solo desde los equilibradores de carga públicos. Para obtener más información sobre la configuración de las listas de seguridad de servidores backend, consulte Actualización de reglas para limitar el tráfico a los servidores de backend.

Registros y zonas de DNS

Las zonas y los registros de DNS son fundamentales para la accesibilidad de las propiedades web. Las actualizaciones incorrectas o supresiones no autorizadas pueden provocar la interrupción de los servicios, a los que se accede mediante nombres de DNS. Oracle recomienda limitar los usuarios de IAM que pueden modificar los registros y las zonas de DNS.

Políticas de dirección de gestión de tráfico DNS

Las actualizaciones incorrectas o las supresiones no autorizadas de las políticas de dirección de gestión de tráfico DNS pueden provocar la interrupción de los servicios debido a una dirección incorrecta del tráfico o a un fallo de failover. Oracle recomienda limitar los usuarios de IAM que pueden modificar las políticas de dirección de gestión de tráfico DNS.

Ejemplos de política de seguridad

Permitir que los usuarios solo vean listas de seguridad

Los administradores de red son el personal que debe tener la capacidad de crear y gestionar grupos de seguridad de red y listas de seguridad.

Sin embargo, es posible que tenga usuarios de red que necesiten conocer las reglas de seguridad que están en un grupo de seguridad de red (NSG) o una lista de seguridad en particular.

La primera línea de la siguiente política de ejemplo permite que el grupo NetworkUsers vea las listas de seguridad y su contenido. Esta política no permite al grupo crear, asociar, suprimir o modificar listas de seguridad.

La segunda línea permite al grupo NetworkUsers ver las reglas de seguridad en los NSG y, además, ver qué VNIC y recursos principales están en los NSG. La segunda línea no permite que el grupo NetworkUsers cambie las reglas de seguridad en los NSG.

Allow group NetworkUsers to inspect security-lists in tenancy
Allow group NetworkUsers to use network-security-groups in tenancy

Evitar que los usuarios creen conexiones externas a Internet

En algunos casos, puede que necesite evitar que los usuarios creen conexiones externas a Internet en su instancia de VCN. En la siguiente política de ejemplo, el grupo de NetworkUsers no puede crear un gateway de Internet.

Allow group NetworkUsers to manage internet-gateways in tenancy
 where request.permission!='INTERNET_GATEWAY_CREATE'

Impedir que los usuarios actualicen registros y zonas de DNS

En la siguiente política de ejemplo, se impide que el grupo NetworkUsers suprima y actualice registros y zonas de DNS

Allow group NetworkUsers to manage dns-records in tenancy
 where all {request.permission!='DNS_RECORD_DELETE', 
            request.permission!='DNS_RECORD_UPDATE'} 
Allow group NetworkUsers to manage dns-zones in tenancy
 where all {request.permission!='DNS_ZONE_DELETE', 
            request.permission!='DNS_ZONE_UPDATE'}

Comandos útiles de la CLI

En todos los ejemplos siguientes, las variables de entorno $T, $C y $VCN están definidas como OCID de arrendamiento, OCID de compartimiento y OCID de VCN, respectivamente.

Mostrar listas de seguridad abiertas en una VCN

# list open (0.0.0.0/0) security lists in VCN $VCN in compartment $C 
oci network security-list list -c $C --vcn-id $VCN | grep "source" | grep "\"0.0.0.0/0\""

Mostrar gateways en una VCN

# list all internet gateways in VCN $VCN in compartment $C 
oci network internet-gateway list -c $C --vcn-id $VCN 
# list all DRGs in compartment $C 
oci network drg list -c $C 
# list all local peering gateways in vcn $VCN in compartment $C 
oci network local-peering-gateway list -c $C --vcn-id $VCN

Mostrar reglas de tablas de rutas en una VCN

# list route table rules in VCN $VCN in compartment $C 
oci network route-table list -c $C --vcn-id $VCN