Desarrollar una API en el ámbito sanitario para monetizar esa funcionalidad que encantará a tus usuarios finales, es una apuesta segura de éxito. Pero no querrás que cualquiera pueda hacer uso de ella sin la debida autorización: debes protegerla.
Habilitar los mecanismos de acceso al endpoint de tu API es uno de los aspectos fundamentales a tener en cuenta en la fase de diseño y uno de los más costosos en recursos y tiempo. Nubentos proporciona la interfaz ideal para ahorrarte este trabajo, pero aún así, es necesario aplicar algunas medidas de seguridad por tu parte.
En esta serie de artículos te mostraremos diferentes mecanismos para securizar el endpoint de tu API para Sanidad y cómo debemos realizar la configuración en la plataforma de Nubentos para conectarnos a él.
- Comenzaremos con el mecanismo más básico, ocultando al mundo el endpoint. Sencillo, rápido, pero aún demasiado expuesto.
- Continuaremos incorporando un mecanismo adicional básico: un usuario y contraseña para hacer peticiones al endpoint con autorización.
- Por último, veremos una solución aún más refinada y que nos ayudará a solventar las carencias de las anteriores soluciones.
¿Estás listo? Empecemos.
Tabla de Contenidos
Ocultar el endpoint al mundo
Partimos de la siguiente arquitectura, donde el proveedor de la API (tú) tiene un servidor de aplicaciones que atiende las peticiones. Dispone también de un balanceador de carga o proxy inverso, que se encargará de enrutar las peticiones que se realicen atendiendo al contexto solicitado.
De esta forma, al solicitar http://endpoint/api la petición llegará al servidor de aplicaciones que se encargará de responder. En caso de solicitar otro contexto, por ejemplo http://endpoint/doc, dirigirá la petición a un contenido estático.
La API REST que has desarrollado puede ser expuesta mediante una URL. Un primer paso para ocultar la existencia de tu API es ponerle un nombre críptico al dominio y gestionar cuidadosamente a quién proporcionamos esta URL.
Podríamos generar un nombre de dominio como: d635865a-dab5-4254-804f-7f65eb99aca2.apiprovider.com
Puedes usar el comando uuidgen para generar una cadena aleatoria. Tan solo debes asegurarte de que el primer carácter sea una letra para que cumpla con el RFC 1035.
Este método no es una buena práctica, porque tarde o temprano alguien podrá identificar la URL, ya sea por la configuración de los clientes que accedan a la API o escuchando el tráfico que se genera en la red.
¿Cómo realizamos esta configuración?
Para este ejemplo, las funciones de balanceador de carga estarán a cargo de una instancia de nginx (aunque también podríamos usar Apache WebServer 2.4).
Suponemos que tienes la dirección IP de tu servidor de aplicaciones donde estamos sirviendo una API REST (por ejemplo 192.168.0.10), que nos permite consultar un listado de doctores por su identificador.
Usando el recurso “/doctor” y pasándole el identificador “/1”, el resultado será una respuesta en formato json con los principales campos de la entidad doctor.
Partiremos de una instalación de nginx que está funcionando correctamente en el servidor como balanceador de carga. Puedes encontrar unas instrucciones de como instalar nginx en las distribuciones más comunes en este enlace http://docs.nginx.com. Para este ejemplo usaremos la instalación sobre Red Hat Linux.
En esencia, todo lo que necesitas hacer es configurar nginx con instrucciones sobre qué tipo de conexiones escuchar y hacia dónde redirigirlas.
Para ello, creamos un nuevo archivo de configuración utilizando el editor de texto que prefieras, por ejemplo con nano:
En el archivo load-balancer.conf definimos dos secciones, upstream y server, como en los ejemplos que siguen.
upstream applicationserver {
server 192.168.0.10:8080;
}
server {
listen 80;
server_name d635865a-dab5-4254-804f-7f65eb99aca2.apiprovider.com;
proxy_set_header Host $http_host;
location /api {
proxy_pass http://applicationserver;
}
}
Donde upstream se refiere a la dirección IP y puerto donde está escuchando el servidor de aplicaciones. Y server define el puerto donde se levanta el servidor de nginx y el host al que se asocia.
Tras recargar la configuración de nginx, éste sólo responderá a las peticiones que soliciten la URL http://d635865a-dab5-4254-804f-7f65eb99aca2.apiprovider.com/api/.
Tan solo tendrás que dar de alta en tu proveedor de dns un registro de tipo “A” asociando el dominio con la IP donde esté corriendo el servidor nginx.
Puedes validar que se ha propagado correctamente consultando al dns de tu equipo:
Server: 8.8.8.8
Address: 8.8.8.8 #53
Non-authoritative answer:
Name: d635865a-dab5-4254-804f-7f65eb99aca2.apiprovider.com
Address: 35.205.205.205
Como hemos indicado tan solo debemos conocer la URL para invocar a la API. A modo de prueba vamos a usar el comando “curl” solicitando los datos del “doctor” con identificador “1”.
* Connected to d635865a-dab5-4254-804f-7f65eb99aca2.apiprovider.com (::1) port 80 (#0)
> GET /api/doctor/1 HTTP/1.1
> Host: d635865a-dab5-4254-804f-7f65eb99aca2.apiprovider.com
> User-Agent: curl/7.54.0
> Accept: */*
>
< HTTP/1.1 200 OK
< Server: nginx/1.10.1
< Date: Sun, 18 Aug 2019 07:09:39 GMT
< Content-Type: application/json
< Content-Length: 332
< Connection: keep-alive
< Sl-Request-Valid: true
{
«category»: {
«id»: 45011383,
«name»: «enim ex laboris»
},
«id»: 1,
«name»: «doggie»,
«photoUrls»: [
«esse pariatur sit»,
«aute ad in»,
«voluptate velit»,
«officia proident sed ipsum»
],
«status»: «vacations»,
«tags»: [
{
«id»: 9940033,
«name»: «ut»
},
{
«id»: 35005282,
«name»: «non dolore dolore irure nostrud»
},
{
«id»: 5593403,
«name»: «ut nulla ipsum»
}
]
}
Como se puede ver los datos proporcionados son completamente ficticios.
¿Cómo registramos este tipo de endpoint en la plataforma Nubentos?
Es tan sencillo como acceder al portal de publicación con tu usuario de desarrollo y en el paso de Diseño de la creación de tu API, cumplimentar el campo de endpoint con la URL para el entorno correspondiente.
Como hemos comentado anteriormente, este método ofrece pocas garantías de seguridad, y no es el que recomendamos.
En el próximo número de esta mini serie, daremos un paso más en la dirección correcta hacia la securización del endpoint de tu API para Sanidad.
Accede a las siguientes partes:
0 comentarios