más allá de la seguridad perimetral | akamai...más allá de la seguridad perimetral 2 en otras...

WHITE PAPER DE AKAMAI

Más allá de la seguridad perimetralUna guía completa y viable para reducir los riesgos

Autor:

Charlie Gero – CTO, Akamai Technologies

Enterprise and Advanced Projects Group

Tabla de contenido

Breve reseña histórica sobre la arquitectura de red 1

El auge de la nube 1

Zero trust 2

BeyondCorp™ de Google 3

Servicios de seguridad en la nube de Akamai 4

Acceso a las aplicaciones frente a acceso a la red 6

Estado final deseado 7

Acceso a las aplicaciones 7

Acceso a Internet 8

Visionado arquitectónico 8

Transición de A a B 9

Suposiciones sobre la fase previa 9

Agrupación de usuarios 9

Metodología de agrupación de usuarios 10

1. Fase de verificación de aplicaciones 11

2. Fase de preparación del proxy de acceso 11

3. Fase de registro al laboratorio de pruebas 11

4. Fase de actualizaciones de seguridad 11

5. Fase de actualizaciones de rendimiento 12

6. Fase de registro de los usuarios externos 13

7. Fase de registro de los usuarios internos 13

8. Fase de migración a VLAN 13

Operaciones de la fase posterior 13

Resumen 13

Apéndice 14

Más allá de la seguridad perimetral 1

Breve reseña histórica sobre la arquitectura de redCuesta imaginar que ya hayan transcurrido casi 50 años desde que se conectaran los cuatro primeros sistemas informáticos al precursor de Internet: ARPANET. Desde entonces, se han producido grandes avances tecnológicos: las antiguas y rudimentarias redes conmutadas por paquetes han pasado a convertirse en una compleja y amplísima gama de sistemas autónomos sincronizados que recopilan datos a nivel mundial. El problema es que las amenazas cibernéticas han seguido el mismo camino, habiendo experimentado asimismo una gran evolución. En la última década, hemos sido testigos de ataques DDoS devastadores, de filtraciones de datos que han afectado a cientos de millones de personas, de exfiltraciones de datos de sistemas confidenciales del Gobierno, del auge del malware y de muchas otras cosas.

No obstante, a pesar de todos los cambios que se han producido a lo largo de este periodo de tiempo, tanto buenos como malos, hay una cosa que se ha resistido a cambiar: la arquitectura de red radial que utilizan la mayoría de las empresas.

Antiguamente, este tipo de arquitectura tenía sentido. Hace mucho tiempo, antes de que Internet fuera un lugar de trabajo tan concurrido y se convirtiera en una infraestructura básica, las empresas almacenaban el trabajo en centros de datos. En dichos centros de datos se alojaban las infraestructuras fundamentales y las aplicaciones necesarias para desempeñar las funciones. A medida que las sucursales, tiendas minoristas y ubicaciones satélite se hicieron hueco en la Red, empezaron a necesitar acceso a aplicaciones centralizadas. Para cubrir esta necesidad, las empresas comenzaron a crear sus propias redes de retorno para sus centros de datos principales. Al fin y al cabo, los centros de datos eran la ubicación central en la que se realizaban todas las operaciones.

Con el paso del tiempo, Internet comenzó a perfilarse como una herramienta comercial viable y revolucionaria. En 1994, los ingenieros de Netscape inventaron el protocolo criptográfico SSL, lo que originó el comercio online, y los empleados empezaron a exigir la disponibilidad de ciertos servicios empresariales través de Internet. Naturalmente, las empresas y los operadores que por aquel entonces creaban redes globales complejas atendieron estas peticiones haciendo lo que mejor sabían hacer: incorporar estos servicios en los mismos centros de datos en los que se alojaban sus aplicaciones internas y comprar enlaces de Internet para proporcionar una ruta hacia los mismos. De forma fortuita, esta práctica cumplió dos objetivos: los consumidores externos ahora podían entrar y, además, los empleados internos, distribuidos en un gran número de sucursales, tenían la posibilidad de salir. Durante un tiempo, este sistema radial se convirtió en el rey de las arquitecturas de red.

Con el paso del tiempo, no obstante, agentes malintencionados comenzaron a sacar provecho de esta arquitectura, lo que propició el surgimiento de un nuevo sector: la infraestructura de seguridad de los centros de datos. Como consecuencia de la canalización del tráfico de Internet en los centros de datos por parte de la arquitectura radial, se empezaron a desarrollar potentes funcionalidades de gran alcance destinadas a combatir esas líneas de alta capacidad. Los firewalls y la detección y prevención de intrusos controlaban el tráfico entrante, y las puertas de enlace web seguras garantizaban un funcionamiento adecuado en la dirección saliente. La creciente implementación de estos sistemas de seguridad en cuellos de botella centralizados sirvió además para consolidar la arquitectura radial como la arquitectura de red dominante. Durante un tiempo, este enfoque de seguridad de "castillo y foso" parecía ser viable, y la existencia de un perímetro de red en el que todos los agentes externos eran malos y todos los agentes

internos eran buenos se afianzó como el modelo dominante.

El auge de la nubeEn 1964, cinco años antes de que nuestros cuatro equipos de ARPANET estuvieran disponibles online, Bob Dylan escribió The Times They Are a-Changin’ (los tiempos están cambiando). Estas palabras no podrían describir mejor la predominancia de la nube en la última década. A raíz del surgimiento del software como servicio (SaaS), las empresas empezaron a darse cuenta de que era más fácil y mucho más seguro confiar a terceros la gestión de los sistemas de apoyo que no formaban parte de sus iniciativas principales. ¿Por qué se habría de recurrir a un sistema de CRM interno cuando se puede contratar a proveedores de SaaS para que lo hagan en sus propios servidores gestionados en la nube, que en principio son mucho más seguros y eficientes?

Incluso los sistemas que durante mucho tiempo se consideraron demasiado importantes como para migrarlos a la nube, como el correo electrónico, Active Directory (AD) y Identity se están transfiriendo a una infraestructura global en la nube como resultado del auge de Office 365 y G Suite.

Posteriormente, la aparición de la infraestructura como servicio (IaaS) y la computación en la nube supuso un cambio aún mayor. En lugar de limitarse a trasferir sistemas de apoyo complementarios a través de SaaS, productos como AWS (Amazon Web Services), Microsoft Azure, y Google Compute Platform permiten a las empresas virtualizar la propia infraestructura física bajo demanda y mediante formas de pago basadas en el consumo realizado. De este modo, se ha agilizado la implementación de las aplicaciones empresariales básicas de una forma nunca antes vista.

Arquitectura de red radial


En otras palabras, las aplicaciones han dejado de ser estáticas. Pero no son

las únicas: la fuerza laboral, por su parte, es cada vez más móvil. En efecto,

hoy en día es igual de probable que un empleado trabaje desde una

cafetería, su casa o un aeropuerto que desde el cubículo de una oficina.

Por este motivo, el perímetro de red ya no existe; al menos no de una

forma reconocible. En muchos casos, es posible encontrar a los empleados

y las aplicaciones de una empresa tanto a un lado como al otro del foso.

Y, con el surgimiento de los avanzados y persistentes programas de

malware y amenazas, es muy probable que usted esté dejando entrar a

los agentes maliciosos en el perímetro de forma involuntaria, dándoles

pleno acceso a sus activos más valiosos.

Adoptar un modelo de acceso y seguridad que funcionaba bien hace veinte años en el mundo moderno es, en el mejor de los casos, una decisión dudosa, y en el peor, una decisión peligrosa. Forrester Research declara lo siguiente en Future-Proof Your Digital Business With Zero Trust Security:

Y esto no es solo una teoría, sino una realidad que se desprende claramente de la cantidad masiva de filtraciones de datos de las que hemos sido testigos en los cinco últimos años, la inmensa mayoría de las cuales producidas como resultado de un abuso de la confianza dentro del perímetro de red.

Prueba del nivel de gravedad de la situación es el hecho de que las aplicaciones que fueron diseñadas para actuar dentro de un perímetro de red suelen ser las que tienen los peores perfiles de seguridad. Después de todo, si usted hubiera sido un programador hace diez años que suponía que solo los empleados autorizados con buenas intenciones podían acceder a su sistema, ¿se habría andado con tanto cuidado como el programador de hoy en día, quien sabe que un enorme ejército de hackers intentará explotar su aplicación basada en Internet?

Entonces, ¿cuál es la solución?

Zero trustHace unos cinco años, John Kindervag, referente intelectual en el campo y analista de Forrester por aquel entonces, propuso una solución que él mismo denominó "zero trust". El principio detrás de este concepto es bastante sencillo, pero muy efectivo: la confianza no es una cualidad de la ubicación. No se debe confiar en algo simplemente porque está detrás del firewall. Por el contrario, es aconsejable tener una concepción pesimista de la seguridad: ningún equipo, usuario o servidor es de fiar hasta que se demuestre lo contrario.

Lo que se debe hacer es realizar un control estricto de autenticación y autorización, y no transferir ningún dato hasta que se sepa con confianza que no existe ningún peligro. Asimismo, se deberían emplear métodos de analítica, filtrado y registro para comprobar que no se produce ningún comportamiento inadecuado, y siempre se debe prestar atención a las posibles señales de riesgo.

La economía de datos hace que la seguridad de red actual basada en el perímetro no sea eficaz. Como las empresas sacan beneficios de la información y las ideas por medio de un complejo ecosistema de negocios, la idea de un perímetro empresarial es singular e incluso se torna peligrosa.

Dentro = De con�anza

Aplicación 1

Aplicación 2

Aplicación 3

Dentro = De con�anza

Zero trust

Aplicación 1

Aplicación 2

Aplicación 3

Aplicación 1

Nada queda dentro

Aplicación 3

Aplicación 2


Este cambio radical de mentalidad podría evitar muchos de los riesgos que hemos observado a lo largo de la última

década. Los atacantes ya no podrían superar el foso para explotar las debilidades de su perímetro y, posteriormente,

sus datos y aplicaciones confidenciales, ya que no habría ningún foso. Solo habría aplicaciones y usuarios que deben

autenticarse mutuamente y verificar si tienen autorización antes de poder acceder.

Pero ¿cómo puede lograrse esto?

BeyondCorp™ de GoogleHace unos años, Google presentó su modelo de acceso zero trust (confianza cero) en varios white papers, conocido como "BeyondCorp". El aspecto más atractivo de BeyondCorp es que intenta resolver el problema de zero trust en todas las aplicaciones sin modificar el código, obteniendo acceso de forma sencilla y con independencia de la ubicación de la aplicación o del usuario. Con fines de debate, ofrecemos un diagrama simplificado del proceso:

En este diagrama, podemos ver una serie de elementos:

• Un usuario y un portátil: en el modelo de Google, los usuarios que necesitan acceder a las aplicaciones internas utilizan un portátil gestionado con un certificado instalado. Dicho portátil también ejecuta un pequeño agente de software.

• Proxy de acceso: el servidor que se encuentra en la parte superior de la línea microperimetral se conoce como "proxy de acceso". Su función es hacer cumplir las políticas de acceso seguro para las aplicaciones que se encuentran dentro del microperímetro. Es la única entidad que puede acceder directamente a las aplicaciones (aparte de las aplicaciones que se comunican entre sí directamente) y se aloja en la zona desmilitarizada (DMZ) del microperímetro.

• Base de datos de inventario de dispositivos: la base de datos del diagrama es responsable de mantener un registro del estado de seguridad de todos los portátiles y dispositivos de los empleados de Google. Se actualiza de forma periódica con la información más reciente.

• Aplicaciones: son las aplicaciones a las que necesitan acceder los empleados. Entre estas aplicaciones se encuentran Git, el correo electrónico, las bases de conocimiento interno, las aplicaciones financieras, las bases de datos, etc. No se puede acceder directamente a ellas desde fuera del microperímetro.

• Microperímetro: las aplicaciones están acordonadas del resto del mundo por un microperímetro. El único servidor que puede acceder es el proxy de acceso. Además, este microperímetro no necesita estar en un centro de datos físico, sino que puede encontrarse en un entorno de computación en la nube, como GCP ("Google Cloud Computing") o AWS.

Desde el punto de vista operativo, el flujo de trabajo de BeyondCorp es sumamente sencillo y efectivo. De forma periódica, el agente de software que se ejecuta en el equipo del empleado de Google se conecta a la base de datos de inventario de dispositivos y realiza una evaluación de la seguridad del dispositivo. Ofrece información sobre ciertos atributos, como el sistema operativo instalado, los parches en funcionamiento, el estado de las aplicaciones, los antivirus, etc.

La base de datos de inventario de dispositivos registra esta información y, con la ayuda de un componente conocido como "Trust Inferrer" (no se muestra), realiza una evaluación o valoración del portátil. En la implementación actual de Google, los datos no se limitan al agente de software del dispositivo del usuario final. También pueden proceder de escáneres de vulnerabilidades que se ejecutan en la red, del router, de los registros del firewall, etc. En esencia, la base de datos de inventario de dispositivos recopila continuamente toda la información posible para determinar, fuera de banda, el nivel de seguridad del propio dispositivo.

Aplicación 1

Aplicación 2

Aplicación 3

Aplicación 4

Microperímetro

Proxy de acceso

Base de datos de inventario de

dispositivos


Cualquier cambio de estado que se produzca en el dispositivo o de forma externa puede afectar a la evaluación

o valoración. Por ejemplo, si se descubre una vulnerabilidad de seguridad en un sistema operativo en particular,

Google puede programar a la base de datos de inventario de dispositivos fácilmente y de forma inmediata para que

baje la puntuación de todos los equipos que funcionen con la versión en cuestión.

Cuando el usuario de un dispositivo intenta acceder a una aplicación, se le redirige al proxy de acceso. El proxy de

acceso tiene políticas de acceso seguro definidas para cada aplicación que determinan qué usuarios pueden acceder

al recurso, así como el nivel de seguridad mínimo que necesita el dispositivo.

De hecho, lo que hace que sea tan potente es la combinación centrada en la aplicación de identidad de usuario y

nivel de seguridad del dispositivo. Por ejemplo, a Git solo pueden acceder los usuarios del grupo de desarrolladores

desde portátiles que tengan un sistema operativo moderno y todos los parches actualizados. El directorio de una

empresa puede tener una política mucho menos restrictiva, lo que permite que cualquier persona con una cuenta

válida puede acceder a los datos, siempre y cuando utilice un equipo con un sistema operativo más moderno que

Windows XP. No basta simplemente con decir que el grupo de finanzas tiene acceso a información confidencial de

contabilidad. Las políticas garantizan que los equipos desde los que se accede son seguros.

La autenticación de usuario comienza tras la conexión al proxy de acceso y se realiza a través de una sesión

autenticada mutuamente, mediante el certificado del portátil del cliente. Si la autenticación es correcta, el proxy de

acceso no solo sabe quién está intentando acceder, sino también desde qué equipo lo hace.

Gracias al empleo de dicha información de conformidad con las políticas definidas anteriormente, y junto con la base

de datos de inventario de dispositivos, el proxy de acceso está en posición de tomar una decisión sobre si autorizar la

conexión a la aplicación o no.

Una última cosa que se ha destacar es el nivel de ambición de BeyondCorp. En general, Zero trust es una estrategia y

BeyondCorp es simplemente un método para lograrlo. Hoy en día, este software de Google no está a disposición del

público fuera de la nube y, de forma altruista, ha ofrecido a la comunidad una forma de alcanzar un nivel zero trust.

Servicios de seguridad en la nube de AkamaiEn el modelo clásico de BeyondCorp, el proxy de acceso es un servidor dentro de una DMZ diseñado para conceder

o denegar el acceso a los servicios dentro del microperímetro. Si nos paramos a pensar en la cantidad de trabajo que

debe realizar un servidor de estas características, no tardamos en darnos cuenta de que es bastante abrumador.

Como mínimo, el proxy de acceso se encarga de la terminación de las conexiones TLS con el cliente, realizar la

autenticación, consultar la base de datos de inventario de dispositivos, hacer cumplir las políticas y, por último,

establecer conexiones proxy con los servicios que se encuentran dentro del microperímetro, muchos de los cuales

también necesitan cifrado. Esto ya es de por sí bastante laborioso, y si luego queremos añadir servicios como un

firewall de aplicaciones web (WAF) y un análisis de comportamiento, la carga de trabajo puede ser abrumadora.

Y eso, solo en lo que respecta a la CPU. Algunas funciones, como el almacenamiento en caché, que puede realizarse

a través del centro de datos de un enlace ascendente de Internet, ofrecen muchos más beneficios cuando están en el

enlace de Internet, más cerca de los usuarios, donde hay, en efecto, un ancho de banda infinito.


Si bien la arquitectura estándar de proxy de acceso BeyondCorp supone un gran avance en materia de seguridad, la necesidad de implementarla por completo dentro de su propia DMZ limita la capacidad de la nube para contrarrestar los ataques, proporcionar un ancho de banda infinito para el almacenamiento en caché y aumentar los recursos automáticamente según sea necesario.

Akamai es una empresa de nube nativa que ha introducido una ligera modificación arquitectónica en el proxy de acceso tradicional, lo que le permite operar en la nube, aumentar sus recursos para responder a la demanda, gestionar recursos que tienen un alto consumo de CPU en nuestra red, en lugar de en su equipo, absorber los ataques y acercar el contenido almacenado en caché a los usuarios. A esto lo llamamos Enterprise Application Access, EAA para abreviar, y posee las siguientes características:

Con esta arquitectura, las aplicaciones se migran a un microperímetro, del mismo modo que se haría con el modelo tradicional BeyondCorp. Sin embargo, en lugar de situar el proxy de acceso en la DMZ, se ejecuta una máquina virtual (VM ) denominada "conector de Akamai" dentro del microperímetro. No es necesario que esté, ni debe estar, dentro de la DMZ. Su dirección debe estar en un espacio de IP privada y no debe ser accesible directamente desde Internet. De hecho, debe parecer exactamente igual que cualquier otra aplicación situada dentro del microperímetro.

Cuando el conector de Akamai se inicia, establece inmediatamente una conexión cifrada a la nube de Akamai. Una vez conectado a Akamai, el conector descarga la configuración de los servidores de Akamai y se prepara para establecer conexiones.

Cuando un usuario de sus aplicaciones internas trata de acceder a un servicio alojado dentro del microperímetro, se le redirige a Akamai a través de un DNS CNAME y se le conecta al nodo de entrada de Akamai. Es en este nodo, más cercano al usuario, donde Akamai puede realizar tareas como WAF, detección de bots, análisis de comportamiento y almacenamiento en caché. De este modo, se obtiene un rendimiento óptimo y la capacidad de mantener los agentes maliciosos potenciales lo más lejos posible de las ubicaciones, aplicaciones y datos físicos.

Si el usuario final pasa todos los controles, se le enruta a través de la superposición de red avanzada de Akamai al perímetro EAA de Akamai, donde se realizan las funciones de autenticación normal, autenticación multifactorial (MFA), inicio de sesión único e identidad de dispositivo. Si el usuario y el equipo están autorizados, la conexión del cliente se vincula a la conexión saliente desde el conector de Akamai. El tráfico de la sesión del usuario fluye a través de esta conexión de proxy a la del conector de Akamai y, posteriormente, se conecta a la aplicación o al servicio solicitados, estableciéndose una ruta de datos completa.

Este método de acceso tiene claras e importantes ventajas. Las actividades más vulnerables desde el punto de vista del rendimiento y de la seguridad se realizan en el perímetro de red más cercano al usuario final, donde Akamai tiene más de 200 000 equipos distribuidos por todo el mundo. Además, la entrada vulnerable al microperímetro se realiza a través de un túnel de aplicaciones invertido, lo que elimina de forma eficaz la visibilidad de la IP del perímetro y reduce el riesgo de sufrir ataques volumétricos.

El uso de este paradigma no supone un cambio radical de lo que sabemos hasta ahora: simplemente ofrece una solución más eficiente. Cuando hablemos de escalonamiento, haremos referencia a este enfoque, puesto que creemos que es más rápido y seguro, pero los conceptos generales se aplican también al enfoque tradicional del proxy de acceso BeyondCorp.

Aplicación 1

Aplicación 2

Aplicación 3

Aplicación 4

Centro de datos

Conector de Akamai

Nodo de entrada de Akamai

Perímetro EAA de Akamai


Acceso a las aplicaciones frente a acceso a la redLos lectores de este artículo podrían equiparar este enfoque al de una red privada virtual (VPN), pero se estarían haciendo un flaco favor. Las VPN proporcionan acceso a nivel de red y, debido a su base tecnológica, garantizan que la seguridad y el rendimiento estén inversamente relacionados con la capacidad de gestión y la simplicidad.

Si usted es de los que utilizan una configuración de VPN sencilla, probablemente esté haciendo lo mismo que muchas empresas: permitiendo que los usuarios registrados tengan acceso a su red a nivel de IP. Y ya sabemos lo peligroso que es esto. ¿Por qué los teleoperadores tienen acceso a la IP de repositorios de código fuente? ¿O por qué un contratista que utiliza su sistema de facturación debería tener acceso a los terminales de procesamiento de tarjetas de crédito? Solo debería concederse acceso a los datos estrictamente relacionados con la tarea que se va a desempeñar.

Para solucionar este problema, puede dividir las aplicaciones a través de una red de área local virtual (VLAN) en segmentos independientes situados tras un firewall y aplicar reglas basadas en un rango de IP obsoleto para los usuarios individuales o grupos en el agregador de VPN. Este sistema es vulnerable y propenso a errores. Con frecuencia, los administradores pierden la conexión en el peor momento. Es posible que una persona de mantenimiento haya desplazado los equipos para colocarlos en otro estante o haya tenido que restablecer la IP en un nuevo rango. En cuestión de segundos, empiezan a entrar llamadas de usuarios que no tienen acceso al sistema. O tal vez la arquitectura de una aplicación ha cambiado durante una actualización de software y a los usuarios se les ha redirigido a otro equipo como parte del flujo de trabajo, pero determinados usuarios no pueden acceder a dicho equipo, ya que las reglas de firewall no están actualizadas. Esta arquitectura requiere que haya un sistema que permita a los propietarios de las aplicaciones, los administradores de red y los grupos de seguridad comunicarse entre sí cuando se produzcan estos cambios, con el objetivo de evitar que haya periodos de inactividad.

Por experiencia, sabemos muy bien lo que ocurre cuando esta coordinación falla. Los administradores tratan de seguir las prácticas recomendadas, pero, en un momento de desesperación como este, se implanta la temida regla de IP "ANY/ANY ALLOW" como una solución rápida hasta que el problema se diagnostique y solucione, la cual permite que los usuarios afectados tengan acceso a todo. Sin embargo, normalmente no hay tiempo para volver atrás y corregir brechas de seguridad antiguas. Por tanto, el uso de una VPN va acompañado de una serie de gastos operativos considerables y de una gran complejidad para solucionar los problemas de seguridad ocasionados por el acceso horizontal sin restricciones. Dicha complejidad a menudo se traduce en brechas en las defensas y en la implementación de soluciones rápidas que, a largo plazo, reducen el nivel de seguridad.

Y lo mismo ocurre con el rendimiento. En la VPN más sencilla, todo el tráfico se redirige al centro de datos, lo cual puede ralentizar en gran medida el acceso a los activos de Internet y SaaS como consecuencia del bucle invertido de NAT, así como provocar un aumento de tráfico en enlaces ascendentes de Internet dentro del centro de datos para operaciones no comerciales, como Facebook y YouTube. ¿Por qué se habría de volver a conceder acceso normal a Internet a un usuario que ya está fuera del perímetro?

Para solucionar este problema de rendimiento, los administradores suelen emplear túneles divididos para marcar los rangos de IP que pueden conectarse a la VPN y los rangos que deberían salir directamente a Internet. Esta solución es muy eficaz y sencilla cuando solo se cuenta con un perímetro interno. Sin embargo, la cosa empieza a complicarse a medida que se añaden varios centros de datos y nubes privadas virtuales (VPC ) en proveedores de IaaS. En este caso, los administradores deben decidir si instalarán agregadores de VPN en todos los centros de datos y determinar cómo gestionarán los túneles multipunto divididos de forma eficaz.

Como ya hemos dicho, todas estas soluciones son posibles teóricamente, e incluso puede que usted esté utilizando una combinación de las mismas. El problema es que las tareas necesarias para implementar dichas soluciones correctamente, mantenerlas y, al mismo tiempo, ofrecer una seguridad y un rendimiento adecuados suelen ser demasiado complejas desde el punto de vista operativo. En muchos casos, las empresas se convencen a sí mismas de que, como los empleados pueden acceder a sus aplicaciones, todo debería funcionar sin problemas. Hasta que, un día, una de las soluciones rápidas descritas anteriormente desemboca en una brecha de seguridad catastrófica o en una degradación del rendimiento que provoca una interrupción en la red o una considerable disminución de la productividad de los empleados.

Esto no quiere decir que las VPN no sean útiles; todo lo contrario. En el caso de la infraestructura de centros de datos múltiples, de hecho, el acceso de sitio a sitio puede ser muy eficaz. No obstante, el acceso a nivel de red no es la mejor solución en el caso de la utilización de aplicaciones por parte de los usuarios, ya que dicho acceso compromete de forma antinatural la seguridad y el rendimiento en aras de la simplicidad.

Lo que hace que los enfoques basados en proxy, como BeyondCorp y Akamai Enterprise Application Access, llamen tanto la atención es el acceso a nivel de aplicación. Con el acceso a nivel de aplicación, el rendimiento y la seguridad se desvinculan de la complejidad. La explicación es tan obvia como sencilla.


Simplemente hay que agrupar todas las aplicaciones que comparten una localidad (alojadas en el mismo centro de datos o en la misma VPC, por ejemplo), alojarlas en un espacio de IP de red privada o en una VLAN restringida, introducir un proxy de acceso en la DMZ del microperímetro y... ¡listo!

Los propietarios de las aplicaciones establecen sus propias políticas de seguridad para el proxy de acceso, como quién puede tener acceso y a qué nivel de seguridad del dispositivo, y lo que es más interesante: los usuarios pueden estar en cualquier lugar. No se hace una distinción entre "dentro" y "fuera" del perímetro, ya que no hay ningún perímetro de red que incluya a los usuarios finales. Lo mismo es trabajar desde una cafetería que desde una oficina; lo único que importa es si el usuario está autorizado y si el equipo es seguro.

Con el acceso a nivel de aplicación, el rendimiento es teóricamente óptimo, a pesar de la facilidad de implementación y uso. Los usuarios solo necesitan una conexión a Internet para acceder a las aplicaciones directamente, con independencia de dónde estén alojadas o de dónde se ubique el usuario. De esta forma, Internet enruta paquetes de destino sin tener que pasar por agregadores ni intermediarios que no estén en la ruta.

De hecho, con el acceso a nivel de aplicación, las redes internas suelen funcionar como Wi-Fi de invitados. Recuerde que, para que zero trust sea eficaz, no se puede tratar a los usuarios internos y externos de forma diferente: es necesario comprobar que todos y cada uno de ellos son de confianza.

Estado final deseado

Acceso a la aplicaciónSegún el moderno modelo zero trust, todas las aplicaciones deben estar segmentadas en sus propios microperímetros en función de la ubicación y el objetivo. Estos microperímetros deben estar en VLAN privadas con un espacio de IP privada y solo deben ser accesibles desde el proxy de acceso que los protege.

Dejamos a la discreción de cada empresa el determinar si desean ofrecer una microsegmentación aún mayor dentro de los microperímetros para detener la escalada y el movimiento horizontales en el caso de que la aplicación esté en peligro. Podemos ver el valor teórico de este tipo de estrategias, pero creemos que, en la práctica, el nivel de complejidad para conseguir una correcta segmentación suele ser demasiado alto como para justificar el mayor grado de seguridad. Cualquiera que haya intentado desenmarañar los puntos de contacto que hay detrás del perímetro de una aplicación compleja sabe lo delicado que puede ser segmentar las aplicaciones. No obstante, si el entorno es propicio para el mantenimiento de dicha segmentación, recomendamos implementarla.

Independientemente de si los usuarios están dentro o fuera del perímetro, se les debería obligar a acceder a todas las aplicaciones a través de proxies de acceso, tales como Enterprise Application Access de Akamai, que no solo realiza una autenticación estándar, sino también MFA. Además, debería existir una sólida base de datos de inventario de dispositivos que hiciera un seguimiento de las medidas de seguridad de todos los dispositivos con acceso a sus recursos, por si los propietarios de las aplicaciones quisieran diseñar políticas al respecto. Asimismo, es posible que se necesitara algún método de gestión de certificados o dispositivos móviles (MDM) que proporcione certificados a los equipos y los revoque si la seguridad está comprometida.

Por otro lado, tenemos la firme convicción de que zero trust no termina con la autenticación y autorización. Un modelo moderno también requiere un proceso de inspección y análisis del tráfico que circula por los proxies que ofrezca protección contra las amenazas persistentes avanzadas y los usuarios malintencionados más obstinados.

Asimismo, además del proxy de acceso, se debería añadir un WAF, sistema de seguridad fundamental para evitar los ataques (deliberados o involuntarios) a las aplicaciones internas por parte de los usuarios. También se pueden utilizar otros sistemas avanzados, como la detección de humanos o bots, para los sitios sin interfaz de programación de aplicaciones (API), con el objetivo de garantizar que no haya malware oculto en forma de terminales válidos.

La prevención de DDoS cobra especial relevancia cuando sube sus aplicaciones a Internet y las hace accesibles a través de proxies de acceso. Debe asociarse con proveedores que puedan contrarrestar los ataques lanzados contra sus microperímetros y proxies de acceso; de este modo, no tendrá que detener las operaciones en ningún momento.

Por último, para garantizar que sus aplicaciones tengan un rendimiento óptimo y que los usuarios no solo acepten este cambio de acceso, sino que también esten a favor del mismo, los proxies de acceso deberán estar protegidos por redes que potencien el rendimiento. Concretamente, las redes de distribución de contenido (CDN) y las superposiciones de enrutamiento en línea deberían ser parte de su arsenal, no solo para facilitar el acceso, sino también para mejorar el rendimiento de una forma nunca antes vista.


Acceso a InternetPuede ser beneficioso considerar la implantación de soluciones como Akamai Enterprise Application Access para proteger a sus aplicaciones de los agentes maliciosos. Sin este tipo de soluciones, ¿quién impide que sus propios usuarios se conviertan en agentes maliciosos a causa de las infecciones de malware? A este respecto, la prevención y la detección juegan un papel crucial en el control del tráfico saliente.

Con el paso del tiempo, la seguridad de extremos para dispositivos gestionados cobrará una mayor importancia, y esperamos que las soluciones de antivirus basadas en el aprendizaje automático sigan superando a los antivirus tradicionales en la identificación de amenazas de día cero. Si bien algunas empresas podrían considerar que las listas blancas de aplicaciones o los sistemas de escritorio de aislamiento de procesos proporcionan un nivel de prevención contra amenazas aún mayor, otras podrían verse disuadidas por la rigidez y dificultad de la implementación.

Por otro lado, deberían implantarse sistemas de prevención basados en la nube para proteger a los usuarios finales. Los sistemas tradicionales, como SWG y NGFW, seguirán siendo importantes, pero necesitarán la ayuda de soluciones específicas que se ocupen de los casos de uso de mayor riesgo, como el aislamiento remoto de exploradores, los entornos de pruebas, el análisis de archivos ejecutables desde la web y las puertas de enlace de correo electrónico que detectan los archivos adjuntos de phishing y malware.

Si bien la prevención es importante, creemos que la detección seguirá siendo la herramienta principal de los administradores para luchar contra las constantes amenazas que ponen en peligro la seguridad de los usuarios. Un sistema de estas características que es fácil de implementar e increíblemente eficaz es el firewall de DNS. Como el firewall de DNS es una herramienta utilizada habitualmente tanto por software inocuo como malicioso, es un excelente sistema para detectar infecciones, y la facilidad de implementación de esta solución la convierte en un recurso inestimable.

Visionado arquitectónicoSi lo ponemos todo en conjunto, esperamos que sus usuarios y aplicaciones trabajen en un marco así en un mundo en el que la estrategia zero trust esté a la orden del día:

Modelo de protección avanzada de terminales para dispositivos gestionados

Aplicación 1

Aplicación N

...

Centros de datos nativos

Aplicación 1

Aplicación N

...

Estrategia de nube múltiple

AWS

Aplicación 1

Aplicación N

...

Azure

. . .

Base de datos de inventario de dispositivos

Protección contra DDoS

Puerta de enlace de correo electrónico en la nube

Análisis de DNS en la nube

Inspección de SWG/NGFW/HTTP; aislamiento del navegador

Internet

Firewall de aplicaciones web Detección de bots o agentes maliciosos Almacenamiento en caché globalLEYENDA:


Ir de A a BHasta ahora hemos visto un estudio bastante minucioso sobre zero trust, incluida la forma en que debería operar una empresa con dicho modelo y la metodología CARTA. No obstante, así como los sistemas de seguridad funcionan mejor cuando son fáciles de implantar, la implementación de las nuevas arquitecturas también debe ser sencilla y escalonable. Ninguna empresa, independientemente de su envergadura, sería capaz de transformar todo su sistema de red de la noche a la mañana. Zero trust es una estrategia, y también lo es su implementación.

En nuestra opinión, el mejor enfoque para lograr una arquitectura zero trust integral consiste en comenzar la transición de aplicaciones a un modelo Enterprise Application Access en pequeños lotes que no sean demasiado difíciles de gestionar. El tamaño de cada lote variará en función del número de recursos que se puedan dedicar; algunas empresas, por ejemplo, solo podrán implementarla una por una. En cualquier caso, cada aplicación pasará por varias fases antes de lograr un modelo zero trust global. Asimismo, deberá asegurarse de que la aplicación funciona correctamente en cada fase y que la política de autorizaciones se cumple según lo previsto.

Desde principios del año 2018, Enterprise Application Access es compatible con aplicaciones HTTP(S), VNC, RDP y SSH, y no se necesita instalar a los clientes. La implementación de evaluaciones de seguridad y otros protocolos a través del uso de clientes se han programado para más adelante en el año 2018. Así pues, primero deberemos escalonar las aplicaciones web para que sean compatibles con las funcionalidades de EEA.

Suposiciones sobre la fase previaLas siguientes suposiciones se hacen en relación con el estado de la fase previa de su red:

• Las aplicaciones y los usuarios de su perímetro actual pueden conectarse directamente a través de IP.

• Se ha instalado un conector EEA de Akamai en su perímetro actual.

• Se ha creado una VLAN protegida para alojar las aplicaciones empresariales.

• Se ha instalado un conector EAA de Akamai en la VLAN protegida.

• Los usuarios empresariales situados fuera del perímetro seguirán teniendo una VPN instalada durante la fase de escalonamiento para poder conectarse a las aplicaciones que todavía no se han migrado.

• Si se desea implantar un sistema de identificación para los dispositivos gestionados, se instalarán certificados en los equipos de los usuarios finales a través de algún método fuera de banda, como MDM.

Una vez cumplidos estos prerrequisitos, podemos comenzar a hablar de las fases por las que pasará cada aplicación durante el proceso de transición. Dichas fases deben tener un altísimo grado de precisión; por tanto, a medida que se vaya acostumbrando al proceso, es posible que quiera combinar alguna de ellas.

Agrupación de usuariosParte de nuestro proceso de escalonamiento de aplicaciones comprenderá una eliminación progresiva de esta característica para determinados grupos de usuarios. Recomendamos que cada aplicación tenga tres grupos generales de usuarios:

• Laboratorio de pruebas: estos usuarios serán responsables de verificar la integridad funcional de la aplicación cuando se facilite el acceso por primera vez a través de Enterprise Application Access. Deben estar familiarizados con la semántica operacional de la aplicación para comprobar el comportamiento estándar y los casos extremos.

Al haber varias funciones de seguridad y rendimiento adicionales, estos usuarios también deben tener la experiencia necesaria para determinar si las medidas de seguridad funcionan según lo esperado y si hay

beneficios en términos de rendimiento.

Animamos a las organizaciones que dispongan de una gran cantidad de aplicaciones a que consideren la posibilidad de invertir en herramientas que sean compatibles con funciones estándar no específicas a determinadas aplicaciones, como pruebas genéricas de control de rendimiento, y que realicen controles de seguridad de forma periódica y automática sin la necesidad de contar con un alto grado de supervisión humana. Algunos de los controles específicos de seguridad que deberían realizarse con dichas herramientas son la inyección SQL, las secuencias de comandos en sitios cruzados (XSS), la detección de bots y la inyección de comandos.


• Usuarios externos: este es el primer grupo de usuarios de producción de Enterprise Application Access y está conformado por todos los usuarios válidos que accederán a la aplicación desde fuera del perímetro de red. Este grupo trabajará de forma dinámica. En otras palabras, cuando los usuarios salgan del perímetro de red, entrarán en este grupo de forma dinámica y, cuando entren en el perímetro, saldrán del grupo de forma dinámica.

• Usuarios internos: este es el grupo final de usuarios de producción de Enterprise Application Access y completa la migración de todos los usuarios de la aplicación. Este grupo está conformado por todos los usuarios válidos que accederán a la aplicación desde dentro del perímetro de red. Al igual que el grupo de usuarios externos, la pertenencia a este grupo es dinámica. Los usuarios se unirán a este grupo automáticamente cuando entren en el

perímetro de red interno y se unirán al grupo de usuarios externos cuando salgan.

Metodología de agrupación de usuariosEn nuestro ejemplo de escalonamiento, utilizaremos el producto EEA de Akamai como nuestro proxy de acceso. Akamai incorpora aplicaciones en su red distribuida mediante el uso de DNS: Los nombres de host de la aplicación se envían a Akamai a través de CNAME para dirigir a los usuarios a nuestra plataforma.

Por lo tanto, los usuarios cuyas búsquedas de nombres de hosts terminen en la cadena CNAME de Akamai recibirán acceso a la red global de Akamai, mientras que los usuarios cuyas búsquedas den lugar a la devolución del informe A interno original seguirán accediendo a la aplicación mediante el antiguo método de perímetro. Aprovecharemos esta arquitectura para escalonar los diferentes grupos de usuarios en Enterprise Application Access para cada aplicación controlando los grupos que siguen la cadena CNAME y los usuarios que reciben los informes A internos.

Para ello, utilizaremos DNS Views, también conocido como DNS de horizonte dividido, para identificar los tres grupos de usuarios. DNS View es un método por el cual dos o más usuarios que buscan exactamente el mismo nombre de host pueden recibir respuestas completamente diferentes en función de sus direcciones IP de origen. Por ejemplo, un usuario de China que busca www.foo.bar podría recibir una dirección IP completamente distinta a la de un usuario del Reino Unido, aunque ambos hayan buscado el mismo nombre de host.

Para emplear este método, organizaremos los diferentes grupos de usuarios por sus bloques CIDR de origen. Todos los usuarios del laboratorio de pruebas se alojarán en un bloque CIDR; los usuarios internos estarán dentro del bloque CIDR que defina toda su red interna y los usuarios externos provendrán de todas las IP que no coincidan con los dos primeros grupos.

Hoy en día, todos los servidores DNS normales que implementan las empresas en entornos modernos son compatibles con esta función. A modo de ejemplo, ofrecemos una configuración para el paquete de código abierto ISC BIND en el apéndice, en el que las aplicaciones para las que desea habilitar Enterprise Application Access se alojan en el dominio yourhost.com. Ahora que entendemos cómo se dividen los diferentes grupos de usuarios, podemos

empezar a analizar las fases de implementación de las aplicaciones.

Perímetro de red

Perímetro EAA de Akamai

Usuarios internosUsuarios externos

Laboratorio de pruebas

3

1

2

https://www.isc.org/downloads/bind


1. Fase de verificación de aplicacionesEn esta fase, debe comprobar que la aplicación cumple los requisitos del proxy de acceso implementado. En el caso de Akamai EAA, debe asegurarse de que la aplicación es compatible con alguno de los siguientes protocolos: HTTP, HTTPS, RDP o SSH.

2. Fase de preparación del proxy de accesoA continuación, debe configurar el proxy de acceso para que reconozca la aplicación y sus derechos de seguridad y acceso. En el caso de Akamai EAA, realizará la configuración en la nube, la cual se aplicará a todos los conectores de Akamai de forma instantánea, así como a la red de Akamai, a fin de que todos los equipos de Akamai Edge puedan prestar servicio a los usuarios finales.

3. Fase de registro al laboratorio de pruebasAhora que el proxy de acceso reconoce la aplicación en cuestión, podemos comenzar a incorporar a los usuarios. En esta fase, suponiendo que estamos utilizando el proxy de acceso de Akamai EAA, deberá modificar sus DNS Views tal como describimos anteriormente para redirigir a los miembros del grupo del laboratorio de pruebas a Akamai a través de CNAME, al nombre de host de la aplicación que hayan buscado.

Nada más realizar esta acción, cada vez que los miembros del laboratorio de pruebas intenten acceder a una aplicación determinada, serán redirigidos a la red global de Akamai.

Durante este tiempo, los miembros del laboratorio de pruebas deberán verificar que la autenticación está funcionando correctamente, que la autenticación multifactorial está bien configurada y que el inicio de sesión único funciona en todas las aplicaciones que han sido incorporadas previamente. Y lo que es más importante: en este momento se deberán ejecutar pruebas exhaustivas sobre el correcto funcionamiento de la aplicación.

4. Fase de actualizaciones de seguridadAhora que los miembros del laboratorio de pruebas pueden acceder a la aplicación de forma segura mediante Enterprise Application Access, debería considerar habilitar funciones avanzadas de seguridad que el modelo de perímetro tradicional no incorporaba. En esta sección, haremos referencia a productos de seguridad específicos de Akamai que funcionan bien con el proxy de acceso Akamai EAA y se habilitan a través del mismo. En cualquier caso, las recomendaciones generales y la fase de implementación de los productos no varían, independientemente de que utilice o no estos productos en concreto.

Recomendamos habilitar el producto Akamai Kona Site Defender para aprovechar la funcionalidad WAF. Una vez hecho esto, los miembros del laboratorio de pruebas deben comprobar que la plataforma WAF protege a la aplicación de los ataques de inyección SQL, secuencias de comandos en sitios cruzados e inyección de comandos.

Otra funcionalidad que se puede habilitar fácilmente con el proxy de acceso Akamai EAA y Akamai Ion es la evaluación de seguridad Lightweight Clientless. Con una configuración mínima, los propietarios de las aplicaciones pueden establecer políticas sobre los navegadores y sistemas operativos a los que la aplicación debería denegar acceso. Por ejemplo, mediante la inspección de encabezados, Akamai puede filtrar las versiones obsoletas de Firefox, las cuales puede suponer un riesgo para la seguridad.

En esta fase, los propietarios de las aplicaciones también deberían considerar la detección de humanos o bots, una funcionalidad de seguridad sencilla pero increíblemente potente. Si la aplicación en cuestión no es un servidor API y, por tanto, no debería accederse a la misma programáticamente, puede habilitar esta función a través del producto Akamai Bot Manager y configurar la plataforma para que rechace las conexiones cuyo origen (humano o de bot) no pueda determinarse con un alto grado de certeza mediante analítica avanzada. De este modo, se pretenden prevenir ataques de malware y otras amenazas persistentes avanzadas ocultas tras sesiones de usuario válidas.


En esta fase también se determinará si el acceso a la aplicación en cuestión deberá restringirse a los dispositivos gestionados. De ser así, y si proporciona certificados a los dispositivos finales, podrá cargar su certificado público Autoridad de Certificado de Akamai EAA para que pueda rechazar todas las conexiones procedentes de los equipos que no estén gestionados.

Por último, también se pueden habilitar restricciones geográficas y basadas en IP. Si conoce listas blancas o negras basadas en CIDR que deberían utilizarse o regiones geográficas a las que se debería negar el acceso, podrá habilitarlas y analizarlas en esta fase.

Independientemente de las funciones que habilite, en esta fase su laboratorio de pruebas debe garantizar no solo que las opciones de seguridad funcionen correctamente, sino también que no impidan el correcto funcionamiento de la aplicación.

5. Fase de actualizaciones de rendimientoUna vez que tenemos la aplicación y las medidas de seguridad a punto, lo próximo que debemos comprobar es si el rendimiento es adecuado. En el modelo tradicional de acceso y seguridad basados en el perímetro, el rendimiento de las empresas suele estar limitado por la rigidez del servidor de aplicaciones y los vínculos asociados a la empresa entre sucursales.

A veces, se pueden implementar algunas funciones, como el almacenamiento en caché dentro del perímetro, para mitigar estos problemas, pero no suelen funcionar correctamente cuando los empleados viajan y se salen del perímetro, ya que, cuanto más cerca del perímetro está el usuario, mejores son los tiempos de respuesta.

En esta fase, deberá evaluar si las aplicaciones necesitan una mejora de rendimiento; de ser así, deberá utilizar el almacenamiento en caché y otras técnicas disponibles. Si ha estado utilizando el proxy de acceso EAA, sería conveniente realizar una actualización que habilite la CDN global avanzada de Akamai a través de nuestro producto Ion. De este modo, podrá almacenar caché de todo el mundo a través de los 250 000 servidores de Akamai, ofreciendo un rendimiento óptimo a sus usuarios, con independencia de su ubicación. Asimismo, podrá acceder a la red superpuesta avanzada de Akamai, en la que la corrección de errores de reenvío (FEC), la optimización de rutas y la replicación de paquetes prácticamente reducen a cero el número de paquetes perdidos y proporcionan un enrutamiento basado en el rendimiento.

Cabe señalar que esta fase puede retrasarse de forma opcional e implementarse tras la fase de registro de los usuarios externos, dado que es posible que los usuarios externos puedan ofrecer una mejor evaluación de los beneficios relativos, en términos de rendimiento, desde fuera del perímetro de red.

En cualquier caso, recomendamos implantar un proceso de instrumentación del rendimiento en esta fase, así como antes de la fase de registro de aplicaciones, con el objetivo de evaluar con exactitud los beneficios. Esto puede conseguirse mediante plugins del navegador, gráficos en cascada o servicios de supervisión del rendimiento de terceros.

6. Fase de registro de los usuarios externosPara cuando haya llegado a esta fase, la aplicación ya se habrá lanzado, será accesible a través de Enterprise Application Access, tendrá importantes actualizaciones de seguridad, tal vez se haya mejorado y un laboratorio de pruebas interno la habrá probado para garantizar que funciona según lo previsto.

Ahora es el momento de ponerla a disposición de un público más amplio. Llegados a este punto, recomendamos sincronizarla con los usuarios externos, ya que esta forma de acceso terminará eliminando la VPN para estos usuarios. Además, estos son los usuarios a los que más suelen afectarles estos problemas de rendimiento y los que se encuentran en los entornos más hostiles cuando su ubicación pone a las aplicaciones y los datos en peligro. La mayor ventaja de Enterprise Application Access es que puede proporcionar un mejor rendimiento y una mayor seguridad para este grupo de usuarios.


Antes de entrar en esta fase mediante la modificación de DNS View, recomendamos que notifique

a dichos usuarios para que la transición no les pille por sorpresa. Si todo se ha configurado

correctamente hasta este momento, estos usuarios prácticamente no deberían notar la transición,

a excepción, eso sí, de una mejora del rendimiento. Sin embargo, si los usuarios están avisados de

antemano, estarán alerta para ver si todo funciona correctamente y, si algo va mal, sabrán cuál es el

motivo y estarán listos para ponerse en contacto con el administrador correspondiente.

7. Fase de registro de los usuarios internos

En esta fase, los usuarios externos llevan un tiempo registrados y se han solucionado todos los

errores de funcionamiento. Llegados a este punto, puede eliminar todas las referencias a la

aplicación desde la configuración específica de DNS View y añadirla como una entrada CNAME a

la vista común. Una vez hecho esto, todos los usuarios deben comenzar a acceder a la aplicación

inmediatamente con el proxy Enterprise Application Access.

En esta fase, todos los procedimientos que se utilizaron para notificar a los usuarios externos

deberán utilizarse para los usuarios internos. Tras estas seis fases, se deberían haber detectado y

solucionado todos los errores generales o de configuración. De ser así, a estas alturas la transición

operativa de la aplicación a Enterprise Application Access debería ser satisfactoria y todos los

usuarios deberían estar disfrutando de las ventajas de un acceso más sencillo, rápido y seguro.

8. Fase de migración VLAN

Una vez que haya transcurrido un periodo de tiempo considerable desde la fase de registro

de los usuarios internos, podrá migrar finalmente la aplicación a la VLAN protegida. Antes de

hacerlo, es preciso tener que cuenta que, aunque todos los usuarios válidos se dirigen a través de

Enterprise Application Access mediante el DNS, todavía se puede acceder directamente al servidor

de la aplicación en sí a través de su dirección IP y, por tanto, es vulnerable a los ataques de malware

dentro del perímetro de red.

Esta última fase elimina todo acceso directo a través de IP para proteger a la aplicación de todas las

amenazas, y solo permite el paso a través del proxy de acceso.

Una vez terminado este proceso, la transición de la aplicación a Enterprise Application Access se

considerará oficialmente finalizada.

Operaciones de la fase posterior

Una vez que ha migrado todas las aplicaciones a Enterprise Application Access, podrá comenzar a realizar la

extracción completa de los clientes VPN de los sistemas de usuario final.

Asimismo, podrá considerar la conversión de la red de usuarios internos en una red Wi-Fi de invitados, ya que ahora

cuenta con un modelo de acceso a la aplicación “zero trust”.

Por último, en esta fase debería plantearse proteger la conectividad del centro de datos y de los microperímetros

contra los ataques DDoS avanzados. El producto Akamai Prolexic podrá ayudarle en esta empresa.

ResumenLas arquitecturas de red radial tradicionales, junto con el perímetro de seguridad "castillo y foso", no pueden

garantizar un rendimiento ni una seguridad óptimos en el entorno empresarial móvil y basado en la nube de hoy

en día. Este es un problema al que todas las empresas deben hacer frente si no quieren ser vulnerables. El rechazo

a adoptar arquitecturas de seguridad empresariales más sólidas es la causa número uno de las brechas que se

producen actualmente, y esta situación solo va a empeorar. En pocas palabras, no se puede estar seguro detrás del

perímetro, ya que dicho perímetro ya no existe.


ApéndiceTodos los servidores DNS que implementan las empresas en los ambientes modernos de hoy en día son compatibles

con DNS Views. A modo de ejemplo, ofrecemos una configuración para el paquete de código abierto ISC BIND,

en cuyo dominio, yourhost.com, se alojan las aplicaciones para las que desea habilitar Enterprise Application Access.

El archivo de configuración principal tendrá un aspecto similar al que se muestra en la siguiente imagen:

Entonces, ¿cómo podemos conseguir un modelo zero trust?

Los servicios de seguridad en la nube de Akamai pueden combinarse para crear una arquitectura zero trust amplia e

integral que no solo facilita un acceso seguro a las aplicaciones en un entorno de nube nativa, sino que también saca

partido de la nube para eliminar casi por completo la necesidad de utilizar redes empresariales internas.

Si utiliza el proxy de acceso distribuido avanzado con Enterprise Application Access y la potente plataforma global

de Akamai, por fin podrá migrar a un mundo sin perímetro de una forma increíblemente fácil, introduciendo sus

aplicaciones gradualmente una por una, reduciendo el riesgo de la migración casi a cero y beneficiándose de los

20 años de experiencia de la plataforma ofreciendo soluciones de rendimiento y seguridad de vanguardia.

A medida que este campo continúe evolucionando, le aseguramos que Akamai estará con usted durante todo el

trayecto, ayudándole durante el proceso de adopción de una arquitectura de red que no solo facilita acceso a sus

aplicaciones y datos, sino que lo hace de una manera verdaderamente fácil de gestionar y manteniendo en todo

momento los más altos niveles de seguridad y rendimiento.

named.conf

acl testlab { 10.0.2.0/24; };

acl internal { 10.0.0.0/8; };

view “testlab” {

match-clients { testlab; };

recursion yes;

zone “yourhost.com” {

type master;

file “yourhost.com.testlab.zone”;

};

};

view “internal” {

match-clients { internal; };

recursion yes;


type master;

file “yourhost.com.internal.zone”;

};

};


Utilizaremos un único archivo de zona para todas las entradas que se compartan entre todas las vistas. Estos son los hosts

y las entradas DNS que permanecen invariables independientemente del grupo de usuarios en el que se encuentre.

Serán únicos para su organización, pero pueden tener un aspecto similar al que se muestra en la siguiente imagen:

Cada grupo de usuarios que tenga acceso a una aplicación a través de Enterprise Application Access tendrá un

archivo de zona específico con un aspecto similar al que se muestra en la siguiente imagen (app1.yourhost.com es la

aplicación que ha migrado en este ejemplo):

view “external” {

match-clients { any; };

recursion no;


type master;

file “yourhost.com.external.zone”;

};

};

common.zone

a$TTL 86400

@ IN SOA ns1.yourhost.com. ns1.yourhost.com. (

2001062501 ; serial

21600 ; refresh after 6 hours

3600 ; retry after 1 hour

604800 ; expire after 1 week

86400 ) ; minimum TTL of 1 day

yourhost.com. IN NS ns1.yourhost.com.

yourhost.com. IN NS ns1.yourhost.com.

ns1.yourhost.com. IN A 10.0.1.1

ns2.yourhost.com. IN A 10.0.1.2

server1.yourhost.com. IN A 10.0.1.101

server2.yourhost.com. IN A 10.0.1.102

additional common entries…

$INCLUDE “common.zone”;

app1.yourhost.com. IN CNAME app1.yourhost.com.sohacloud.akamai.com.


Akamai, la plataforma de distribución en la nube más grande y respetada del mundo, ayuda a sus clientes a ofrecer las mejores y más seguras experiencias digitales, independientemente del dispositivo, en cualquier momento y en cualquier lugar. La plataforma ampliamente distribuida de Akamai ofrece una escala inigualable, con más de 200 000 servidores repartidos por 130 países, para garantizar a sus clientes el máximo rendimiento y protección frente a las amenazas. La cartera de soluciones de rendimiento web y móvil, seguridad en la nube, acceso empresarial y distribución de vídeo de Akamai está respaldada por un servicio de atención al cliente excepcional y una supervisión ininterrumpida. Para descubrir por qué las principales instituciones financieras, líderes de retail online, proveedores de contenidos multimedia y de entretenimiento, y organizaciones gubernamentales confían en Akamai, visite www.akamai.com/es/es y blogs.akamai.com/es/, o siga a @Akamai en Twitter. Puede encontrar los datos de contacto de todas nuestras oficinas en www.akamai.com/es/es/. Publicado en marzo de 2018.

Para dar un ejemplo más concreto, si los grupos del laboratorio de pruebas y de usuarios externos acceden a una

aplicación Jira interna a través Enterprise Application Access, pero los usuarios internos todavía acceden al perímetro

de la forma tradicional, los archivos de zona tendrían un aspecto similar al que se muestra en la siguiente imagen:

Los archivos de zona para los grupos de usuarios que aún no acceden a la aplicación a través de

Enterprise Application Access tendrían el siguiente aspecto (la dirección IP proporcionada es solo de ejemplo):


app1.yourhost.com. IN A 10.0.1.105

yourhost.com.testlab.zone


app1.yourhost.com. IN CNAME jira.yourhost.com.sohacloud.akamai.com.

yourhost.com.external.zone


app1.yourhost.com. IN CNAME jira.yourhost.com.sohacloud.akamai.com.

yourhost.com.internal.zone


app1.yourhost.com. IN A 10.0.1.156

http://www.akamai.com/es/es

http://blogs.akamai.com/es/

https://twitter.com/Akamai

https://www.akamai.com/es/es/locations.jsp

más allá de la seguridad perimetral | akamai...más allá de la seguridad perimetral 2 en otras...

Documents