Blog de Javier Jerónimo

Mejores Prácticas con Azure Policy - SSDLC - Automatizar la revisión

Thu, 13 Aug 2020 10:00:00 +0000

Esta es una serie de artículos con mi experiencia después de un año en un equipo de diseño e implementación de Azure Policy en el área de Ciber Seguridad Global de Grupo Santander. En estos artículos intentaré resumir las lecciones que hemos aprendido al diseñar, implementar y mantener Azure Policy:

Mejores Prácticas de Diseño Azure Policy - Estructura lógica simple

Mejores Prácticas de Diseño Azure Policy - Separación de Conceptos (SoC)

Mejores Prácticas de Diseño Azure Policy - Control de versiones

Mejores Prácticas de Diseño Azure Policy - Identificadores y trazabilidad

Mejores Prácticas con Azure Policy - SSDLC - Automatizar la revisión

Tabla de Contenido

Despliegue
Revisión de convenciones
Azure Policy - Mejor Práctica: Automatizar la revisión
Conclusión

Los artículos anteriores de esta serie de mejores prácticas introducían un conjunto de convenciones en el diseño de las definiciones de Azure Policy para que fueran facilmente gestionables. Una de mis obsesiones en proyectos software siempre ha sido que la información sea visible y accesible, pero además que se actualice de forma automática. Por eso adoro usar herramientas de gestión como Jira, donde puedes mostrar el grado de progreso de tareas, grupos de tareas (épicas) o versiones, sin más esfuero que el inicial de montar bien el proyecto. Las PPTs no se actualizan solas, supongo que por eso no me gustan tanto los informes en diapositivas.

En este artículo abordo ahora otra parte importante de la gestión del proyecto de Azure Policy: el despliegue y las pruebas previas. Aquí mi obsesión es la automatización. Comencemos…

Despliegue

Desde mi punto de vista el despliegue es una actividad que siendo esencial, debería ser casi transparente. Cierto es que esto requiere un nivel de madurez que permita implementarlo de forma que funcione sin problemas, pero creo que todo el tiempo que se invierta en automatizar al completo esta actividad, redunda en una mejor calidad del software que se despliega. Porque automatizar esta actividad al 100% afecta a la forma en la que se organiza el código, la configuración del propio software que se despliega, y lo hace mejorando ambos.

Me gusta mucho esta recomendación [ref]:

Deploying to production need not to be a ceremony. Production deployments need to be routine, boring events because same process is used all along for each environment. New features you deploy to production should give you excitement but not the deployment process J. You will add unnecessary complexity if you customize deployment process for each environment.

Hint: Use same repeatable and reliable way of deployments to each environments.

Y para desplegar en producción debes usar… abrimos el melón…

Yo no me lío, no quiero scripts complicados (despliegue imperativo), me gusta la idea de definir el estado deseado y que una herramienta se encargue de hacer todo lo necesario para que se cumpla (despliegue declarativo). Porque seamos realistas, conseguir idempotencia con una herramienta imperativa de despliegue no es sencillo, y ya sabemos que si un despliegue falla, lo hará cuando menos tiempo tengamos para revisarlo [ref]:

Todo lo que puede suceder, sucede.

He encontrado algunas referencias en Internet sobre este asunto, y en concreto usando Terraform, que me encanta. En esta serie de artículos no voy a definir cómo implementar adecuadamente un sistema de despliegue con Terraform en varios entornos, porque hay artículos muy buenos que ya lo hacen, como este: Azure Policy as Code with Terraform Part 1.

Siguiendo la guía del mismo autor en Using GitHub Actions and Terraform for IaC Automation he creado un repositorio con un ejemplo de Azure Policy que sigue las convenciones de mi serie de artículos: https://github.com/javierjeronimo/azure-policy-deploy-example

Una definición de Política Azure siguiendo las convenciones en el nombrado, versionado y contenido.
Un sencillo módulo Terraform para el despliegue de la misma. Ojo, que quizá existan mejores formas de desplegar cientos de definiciones y asociaciones usando for_each y otras construcciones de Terraform.
Un pipeline de GitHub Actions donde implemento las recomendaciones de este artículo.
Una organización (gratuita) y un espacio de trabajo en terraform.io.

Revisión automática

En el proceso revisión automática, como parte de CI/CD por ejemplo, debemos automatizar la mayor cantidad posible de actividades de revisión. En nuestro caso, tenemos los siguientes puntos importantes que podríamos revisar:

Definiciones de reglas de Azure Policy en ficheros .json.

Estos ficheros JSON deben cumplir con un esquema que define su estructura. Microsoft tiene publicado el esquema que define la forma de una definición de Azure Policy: https://schema.management.azure.com/schemas/2019-09-01/policyDefinition.json

Una comprobación que se puede automatizar facilmente consiste en comprobar si los ficheros .json cumplen con su esquema. Para ello podemos usar la herramienta Ajv: Another JSON Schema Validator.
Módulos Terraform en ficheros .tf.

Estos ficheros se pueden comprobar con los propios comandos del CLI de Terraform: validate, fmt, plan.
Convención de nombres para las definiciones de Azure Policy. Fundamental para poder automatizar la extracción de informes de trazabilidad, progreso, de nuestras definiciones.

En nuestro caso, el nombre de cada fichero JSON de Azure Policy debe seguir una convención y contener determinados campos en él. Podemos usar la herramienta file-name-linter que mediante expresiones regulares permite añadir reglas de validación sobre ficheros.

Existen otras validaciones que se pueden hacer, que se salen del alcance de este artículo:

Comprobaciones sobre ficheros importantes de un repositorio: licencia, fichero code owners, plantillas de issue de GitHub, etc. Repo Linter. Básicamente, que falle si alguien los borra.
Validación de documentación Markdown. markdownlint-cli

Azure Policy - Mejor Práctica: Automatizar la revisión

Como hemos visto, hay determinadas tareas de revisión que se debe automatizar, desde las más básicas relacionadas con la sintaxis o las convenciones de formato, hasta otras como convenciones en nombres de ficheros, que pueden ser útiles como he sugerido.

Por tanto, automatizar estas comprobaciones en el pipeline de CI/CD es fundamental, para que una revisión manual se pueda dedicar a aspectos más importantes, donde una persona aporta más valor que una máquina.

Esta buena práctica consiste por tanto en automatizar la revisión de:

Ficheros JSON con definiciones de Azure Policy con respecto al esquema que los define.
Otros ficheros, por ejemplo, Terraform, con los correspondientes comandos del CLI.
Convenciones de nombres de ficheros, importantes para trazabilidad de Azure Policy y mejor usabilidad al revisar grado de cumplimiento.

Conclusión

Ya programemos en un lenguaje al uso como C, JAVA o cualquier otra modernez, o lo hagamos representando nuestra lógica de negocio en formatos como YAML, JSON… nuestro código fuente siempre debe cumpir con las normas de sintaxis del lenguaje en cuestión.

Para lenguajes de programación de uso general, podemos revisar automáticamente la sintaxis y otros aspectos como la complejidad, la seguridad, etc., con herramientas como SonarQube.

Para herramientas que usan ficheros XML o JSON no disponemos de comprobaciones tan avanzadas, pero siempre tenemos la opción de revisar si los ficheros son conforme al esquema que los define. Esto es lo básico.

¿Por qué? Porque no tiene sentido que una persona dedique su esfuerzo a revisar algo que puede comprobar una máquina más rápido. Tenemos que centrar nuestros esfuerzos allá donde aportamos valor, y esto está del lado de la semántica de los programas (qué hacen) y no tanto del lado la sintaxis (cómo están escritos). Aunque esto segundo también requiere cuidado, por aspectos como la complejidad o seguridad. Como digo, hay que dedicar los esfuerzos (y costes) de la revisión efectuada por personas allá donde aportan valor.

Las definiciones de Azure Policy se implementan en ficheros en formato JSON con un esquema bien definido. Esto no asegura la semántica de nuestras políticas, pero al menos sí que estas tienen la forma correcta. Y esto elimina problemas y quebraderos de cabeza futuros (post-despliegue).

Además, dado que el nombre de una Azure Policy es su identificador, tanto en informes como en el portal web de Azure, como vimos en otro artículo, es fundamental definir una convención. Esto lleva a requerir automatización en la revisión de estos nombres en el proceso de CI/CD.

Con estas revisiones automáticas, sabremos que no se subirán definiciones de Azure Policy incorrectas sintacticamente (lo que rompería el despliegue o la ejecución de la política), o que no tengan el nombre conforme a nuestra convención (lo que rompería nuestros informes automáticos de trazabilidad y/o progreso).

En el siguiente artículo abordaré las pruebas funcionales de regresión automáticas, con las que podremos saber cómo una política se comporta con un recurso creado ad-hoc para hacerla pasar o fallar.

Mejores Prácticas de Diseño Azure Policy - Identificadores y trazabilidad

Sun, 02 Aug 2020 10:00:00 +0000

Esta es una serie de artículos con mi experiencia después de un año en un equipo de diseño e implementación de Azure Policy en el área de Ciber Seguridad Global de Grupo Santander. En estos artículos intentaré resumir las lecciones que hemos aprendido al diseñar, implementar y mantener Azure Policy:

Mejores Prácticas de Diseño Azure Policy - Estructura lógica simple

Mejores Prácticas de Diseño Azure Policy - Separación de Conceptos (SoC)

Mejores Prácticas de Diseño Azure Policy - Control de versiones

Mejores Prácticas de Diseño Azure Policy - Identificadores y trazabilidad

Mejores Prácticas con Azure Policy - SSDLC - Automatizar la revisión

Tabla de Contenido

El objetivo de una Azure Policy
Trazabilidad
Identificadores
Azure Policy - Mejor Práctica de Diseño: Versionado de definiciones e iniciativas de Azure Policy
Conclusión

En artículos anteriores vimos una serie de recomendaciones para diseñar Azure policy de forma que sean fácilmente mantenibles: diseñar todas las definiciones siguiendo una convención en su estructura lógica, que además sea simple; separando distintos conceptos en distintas definiciones y versionando las mismas individualmente y en conjunto.

Siguiendo estas recomendaciones se tendrá una base de definiciones que debería crecer de forma mantenible, siendo cada una de ellas sencilla de mantener, acotada y controlada. Pero no podemos evitar la complejidad derivada del conjunto de definiciones, que crecerá irremediablemente hasta convertirse en inmanejable.

El objetivo de una Azure Policy

Antes de diseñar una Azure Policy debemos tener claro el objetivo que queremos con ello. Quizá queremos detectar un recurso con atributos de seguridad inválidos (ej. no cifrado en tránsito en Storage Account) o desplegado en una región que no deseamos. Esto aplica siempre que vayamos a diseñar una nueva Azure Policy.

Pero, ¿qué objetivo tenemos antes de empezar siquiera a diseñar definiciones de Azure Policy? ¿Un marco de normas de seguridad que queremos cumplir? ¿Limitar el gasto?

Sea lo que sea, algún objetivo tendremos, y ese objetivo define un alcance en dos dimensiones:

La dimensión de los productos de Azure: sobre qué productos queremos hacer las comprobaciones.
La dimensión de los atributos a revisar: qué queremos comprobar en cada producto.

Estas dos dimensiones definen la cantidad de trabajo que tenemos que hacer. Si las representamos en una tabla podemos ir rellenando las combinaciones para las que hemos creado una definición de Azure Policy:

Productos	Norma 1	Norma 2	Norma 3	Norma N
Azure Key Vault		X
Storage Account	X	X	X	X
…
Data Factory				X

Nuestro objetivo puede ser completar la tabla, o implementar Azure Policy para una columna que representa una norma crítica y prioritaria. También podría darse el caso de que el número de filas (productos Azure) fuera pequeño o creciera cada mes porque vamos usando más y más productos.

En cualquier caso, esta matriz de dos dimensiones, las normas que queremos implementar y los productos de Azure, define y permite hacer un seguimiento del grado de progreso en la implementación de Azure Policy.

Trazabilidad

Retomamos la buena práctica de la separación de conceptos y la aplicamos a la matriz de objetivo. Cada celda de la matriz representa una norma aplicada a un producto. Esto es un alcance muy bien definido y encaja a la perfección con la práctica de la separación de conceptos.

Vamos a suponer un alcance muy reducido a modo de ejemplo:

Productos	Norma 1	Norma 2
Azure Key Vault
Storage Account

En este ejemplo tenemos dos normas que queremos revisar y un conjunto de dos productos sobre los que hacer las comprobaciones. Por tanto, el número de definiciones de Azure Policy sería a priori de 4, cada una acotada a un producto y una norma concretos. Sencillo.

Como decía en la introducción, conforme esta tabla crece en columnas o filas, el número de definiciones evidentemente también lo hace, hasta que llegue un punto donde sea complicado revisar qué tenemos y qué no. Necesitamos una forma sencilla de trazar las definiciones de Azure Policy contra nuestro objetivo (celdas de la tabla).

Identificadores

Las Azure Policy se identifican por su nombre, como ya vimos en artículos anteriores. Esto hace que por ejemplo debamos incluir el número de versión como sufijo del propio nombre de la definición. Por ejemplo: Storage_Account_Norma_1-v1.0

Y acabo de introducir en el ejemplo lo que quería describir en este apartado…

Si cada celda de la tabla corresponde con una norma y un producto Azure, si usáramos identificadores, el ejemplo anterior quedaría así:

Productos	N1	N2
AKV	N1-AKV	N2-AKV
STA	N1-STA	N2-STA

Vamos a tomar esos identificadores como la forma de referirnos a las celdas de la tabla, que como dije, representan cada una de ellas definiciones de Azure Policy. Tendremos por tanto, cuatro potenciales definiciones de Azure Policy en este ejemplo:

N1-AKV
N1-STA
N2-AKV
N2-STA

Azure Policy - Mejor Práctica de Diseño: Identificadores y trazabilidad

Y con todo esto llegamos a la buena práctica de diseño de definiciones de Azure Policy: asignar identificadores a cada una, usando una convención basada en la tabla de objetivo (dimensiones de normas y productos), y usarlas en el nombre de cada definición.

Es decir, siguiendo con el ejemplo anterior, y teniendo en cuenta las mejores prácticas de esta serie de artículos, tendríamos las siguientes definiciones de políticas:

N1-AKV-v1.0.0
N1-STA-v1.0.0
N2-AKV-v1.0.0
N2-STA-v1.0.0

Pueden parecer identificadores crípticos, pero hay que tener en cuenta que N1 y N2 son identificadores de nuestras propias normas. Algo más cercado a la realidad podrían ser identificadores como N1 (requisito de red 1), D5 (requisito de datos 5), I2 (requisito de IAM 2).

El resultado es que tendremos una lista de ficheros con las definiciones, por ejemplo:

policy-definitions/
    N1-AKV-v1.0.0-rule.json
    N1-STA-v1.0.0-rule.json
    N2-AKV-v1.0.0-rule.json
    N2-STA-v1.0.0-rule.json

Con este listado de ficheros es trivial construir una hoja de cálculo donde se autorrellen las celdas de la tabla de objetivo, ya que todos los ficheros siguen la convención <id de norma>-<id de producto>-<version>-rule.json

Ya tenemos nuestra trazabilidad y una sencilla gestión del alcance de nuestra implementación con respecto a nuestro objetivo.

Podemos rizar el rizo y añadir una tercera dimensión: el modo de la Azure Policy.

Los ficheros del ejemplo podrían quedar de la siguiente forma, donde una misma combinación norma-producto podría estar implementada en modo detectivo (audit) y preventivo (deny) al mismo tiempo, por ejemplo en ámbitos de asignación distintos:
policy-definitions/
    N1-AKV-AUDIT-v1.0.0-rule.json
    N1-AKV-DENY-v1.0.0-rule.json
    N1-STA-AUDIT-v1.0.0-rule.json
    N2-AKV-AUDIT-v1.0.0-rule.json
    N2-STA-AUDIT-v1.0.0-rule.json

Conclusión

Separando conceptos de forma que cada definición de Azure Policy corresponda con un alcance reducido y muy determinado de nuestros objetivos conseguimos simplificar la gestión de un gran número de Azure Policy. Si añadimos a esto una convención en los nombres, permitimos automatizar la gestión de la trazabilidad.

Además, esta forma de identificar y nombrar definiciones de Azure Policy nos va a obligar a seguir el principio de separación de conceptos, pues si no dicha trazabilidad automática dejará de funcionar. Estamos pues en un círculo virtuoso.

El resultado es que puede crecer el número de definiciones de Azure Policy tanto como se desee, pero tendremos el control de qué tenemos y qué nos falta con respecto a nuestro objetivo. Es importante plantearse un objetivo de conjunto además del objetivo concreto de cada Azure Policy.

Esto simplifica mucho la gestión del alcance. Imaginemos este entorno:

10 controles de seguridad que queremos comprobar
40 productos de Azure, que no es nada descabellado, pongamos un ejemplo:

Generic , ASG , Subnet , Routing Table , Virtual Network , Azure Firewall , Load Balancer , Network Interface , Security Center , DevOps , Bastion , Key Vault , Private DNS , Private Endpoint , Recovery Vault , Shared Image gallery , Storage Account , WAF , Cognitive , CosmosDB , Data Bricks , Data Factory , Data Lake Sto g1 , HD Insights , MSQL , MySQL , PostgreSQL , Redis Cache , Search Service , SQL DataWarehouse , AKS , API Manager , App Service , App Serv. Env. , Container Reg. , EventHub , Front Door , Functions , Logic App , OpenShift cluster , ServiceBus , Notification HUB

En este ejemplo nos salen 400 potenciales definiciones de Azure Policy. Si bien es cierto que no todas tendrán sentido, por ejemplo, porque el requisito de cifrado en tránsito no se lo apliquemos a la red virtual, o el de IAM venga implementado de forma implítica por el plan de control de Azure, este es nuestro universo de posibles Azure Policy que debemos implementar y mantener.

Quiero usar ese número para demostrar que con pocos controles o normas que queramos comprobar, dado que el número de productos es grande, enseguida tendremos un número poco manejable de definciones de Azure Policy. Si no seguimos todas las buenas prácticas de diseño de esta serie de artículos, la gestión será un infierno.

En siguientes artículos trataré el asunto del proceso de desarrollo: integración continua, pruebas automatizadas, etc. Vamos a apoyarnos en las prácticas de diseño y convenciones de esta serie de artículos para automatizar gran parte del trabajo de revisión que se debe hacer sobre nuevas definiciones de Azure Policy.

Mejores Prácticas de Diseño Azure Policy - Control de versiones

Mon, 27 Jul 2020 17:00:00 +0000

Esta es una serie de artículos con mi experiencia después de un año en un equipo de diseño e implementación de Azure Policy en el área de Ciber Seguridad Global de Grupo Santander. En estos artículos intentaré resumir las lecciones que hemos aprendido al diseñar, implementar y mantener Azure Policy:

Mejores Prácticas de Diseño Azure Policy - Estructura lógica simple

Mejores Prácticas de Diseño Azure Policy - Separación de Conceptos (SoC)

Mejores Prácticas de Diseño Azure Policy - Control de versiones

Mejores Prácticas de Diseño Azure Policy - Identificadores y trazabilidad

Mejores Prácticas con Azure Policy - SSDLC - Automatizar la revisión

Tabla de Contenido

Control de versiones
Objetivo del control de versiones
Versionado del conjunto de Azure Policy
Azure Policy - Mejor Práctica de Diseño: Versionado de definiciones e iniciativas de Azure Policy
Conclusión

En el primer artículo presenté la que desde mi punto de vista es la primera mejor práctica al diseñar definiciones de Azure Policy: definir una estructura simple y crear una convención de diseño para implementar todas las definiciones. En el segundo di continuidad a ese principio con la separación de conceptos, teniendo con resultado de ambos cada política separada en su propia definición, sin mezclar conceptos y con una estructura igual en todas ellas para facilitar el mantenimiento.

En este artículo vamos a gestionar la complejidad derivada de tener muchas políticas: cómo versionarlas y gestionar su despliegue en producción.

Control de versiones

Me gusta esta definición de la Wikipedia, es bastante sencilla [referencia]:

Se llama control de versiones a la gestión de los diversos cambios que se realizan sobre los elementos de algún producto o una configuración del mismo. Una versión, revisión o edición de un producto, es el estado en el que se encuentra el mismo en un momento dado de su desarrollo o modificación.

El control de versiones es fundamental y además es muy fácil de introducir en un proyecto: basta con alojar los ficheros en un repositorio que soporte control de versiones. En los proyectos software son habituales los sistemas de control de versiones como git. ¿Qué se consigue con ello? Pues básicamente no perder ficheros o cambios y tener un histórico de los mismos, además de que usando todas las capacidades de los sistemas de control de versiones y las formas de trabajo que permiten, se consigue que varias personas colaboren en la misma línea base de código de forma eficiente.

Primer paso: alojar los ficheros en un sistema de control de versiones. Ejemplo: git.

Objetivo del control de versiones

Con los ficheros bajo control, que es lo básico, nos tenemos que plantear quién va a usar nuestras Azure Policy, porque esto define cómo debemos implementar el control de versiones.

Si enfocamos cada política de forma individual, como un componente software atómico, con una finalidad bien definida (recordemos el principio de separación de conceptos que estamos aplicando), la política en sí misma podría estar versionada. Pero cuando me refiero a estar versionada no me refiero a que esté alojada y gestionada por un sistema de control de versiones, que lo está, si no que tenga versiones explícitas. Por ejemplo, una Azure Policy podría tener una versión propia v1.3.0, y si tras una serie de cambios la versión de esa política cambiara a v1.3.1, tendríamos información muy útil sobre los cambios que hubiera sufrido.

En cambio, podemos ver el conjunto de todas nuestras políticas como un todo, porque por ejemplo implementen un marco de controles normativo, y necesitemos hacer referencia a qué versión de dicho marco normativo correspondan. En este caso, todas las Azure Policy estarían grupadas en un todo y este conjunto estaría versionada. Por ejemplo, podríamos tener un conjunto de Azure Policy y versionarlo como v1.1.

Estos dos tipos de versionados, el individual de cada Azure Policy y el grupal de un conjunto de ellas se pueden, y deben, combinar:

El versionado individual estaría enfocado al desarrollador de Azure Policy, o a un técnico que quiere conocer los detalles de la lógica de la política y su efecto.

Este versionado es fundamental si tratamos cada definición de Azure Policy como un componente software. Es muy fácil de implementar, puede parecer excesivo, pero a la larga mitiga el ruido y la confusión que se generan cuando hay incidencias o peticiones de soporte con respecto al efecto que están teniendo las Azure Policy que implementamos.
El versionado en conjunto estaría enfocado al auditor, que quiere comprobar el grado de cumplimiento de sus recursos de Azure con respecto a una versión concreta del conjunto de políticas.

Sin este versionado en conjunto, un auditor no puede usar las Azure Policy como métrica de cumplimiento, pues si hacemos cambios en las políticas y el auditor no es consciente de ello, le generará incertidumbre. Con este versionado, podemos hacer cambios en definiciones individuales de políticas (por ejemplo una mejora), pero mantener el conjunto versionado sin alterar, creando una nueva versión de conjunto y dejando al auditor la elección de usar una versión de conjunto u otra para usar como métrica.

Una ventaja de usar combinar tipos de versionado es que se pueden desarrollar las Azure Policy de forma ágil, con cambios frecuentes, y controlando qué cambio sufren cada una de ellas individualmente, pero al mismo tiempo quitar incertidumbre al usuario que usa el conjunto de políticas como métrica de cumplimiento. Este segundo usuario necesita certidumbre, y esto muchas veces se traduce en cambios menos frecuentes. Por ejemplo, si un conjunto de Azure Policy se usan como métrica de seguridad del uso de Azure, quizá no se admitan cambios más que con una frecuencia anual en la definición de esas políticas.

Versionado del conjunto de Azure Policy

Para el versioneado de un conjunto de definiciones de Azure Policy se pueden usar las iniciativas, que entre sus usos también se pueden usar para asignar políticas en conjunto a un alcance determinado.

Una iniciativa está relacionada con definiciones de Azure Policy, y por tanto, podemos usar la iniciativa a modo de versionado, por ejemplo mi-iniciativa-v1.0.0 podría ser una iniciativa que incluya mi-política-1 en su versión 1.0.0 y mi-política-2 en su versión 1.0.1. Con estos dos niveles de control de versiones, podríamos mejorar mi-política-2 con un cambio menor (una mejora, un añadido) y crear una nueva versión 1.1.0 con lo que tendríamos control de las versiones de dicha definición de Azure Policy, pero al mismo tiempo podríamos hacer que mi-iniciativa-v1.0.0 no cambiara y crear una nueva mi-iniciativa-v1.1.0 que incluyera la nueva versión de la política.

Si no gestionamos versiones en ambos niveles, en la práctica estamos haciendo que el conjunto de definiciones de Azure Policy agrupadas en una iniciativa se convierta en un LATEST, es decir, una versión perpetua que siempre contiene lo último. Esto, como hemos dicho, genera una incertidumbre que no siempre se podrá aceptar.

Ventaja

Azure Security Center permite ver en una pestaña de cumplimiento regulatorio el nivel de cumplimiento contra estándares reconocidos. Podemos hacer que una iniciativa que agrupe nuestras propias definiciones de Azure Policy sea uno de esos estándares. De esta forma, estaremos añadiendo una interfaz sencilla, centralizada en Azure Security Center, sobre el nivel de cumplimiento sobre nuestro conjunto de Azure Policy.

Si decidimos darle este uso a las iniciativas, entonces necesitamos versionarlas probablemente, por aquello de dar certidumbre a quien las usa como métrica. Podríamos en ese caso publicar nuestro estándar versionado, y de hecho es lo que hace Azure:

Azure Policy - Mejor Práctica de Diseño: Versionado de definiciones e iniciativas de Azure Policy

Llegamos pues al resumen: es obligatorio usar control de versiones en el proceso de gestión de Azure Policy (el código), más que recomendable versionar cada definición de Azure Policy de forma individual y recomendable versionar el conjunto de Azure Policy mediante iniciativas.

Y mi consejo es no reinventar la rueda y establecer un lenguaje que todos entendamos: semantic versioning: https://semver.org/

Veamos ahora cómo hacerlo…

Implementando versionado de Azure Policy

Básicamente tenemos dos opciones:

Añadir el número de versión como sufijo al nombre del fichero. Esto es un clásico y casi siempre es la mejor opción, porque además en este caso el nombre se usa como identificador de la Azure Policy, con lo que si queremos apuntar a distintas versiones de la misma definición va a ser la única forma de hacerlo.

De esta forma podríamos tener dos Azure Policy desplegadas:
- mi-política-1_v1.0.0
- mi-política-1_v1.1.0
En realidad son la misma política, pero en distintas versiones. Si ahora tenemos una iniciativa que por ejemplo está congelada porque se usa en la organización para medir el nivel de seguridad en Azure, y se ha decidido que sólo se hacen cambios en ella cada semestre previo comité, pues podemos mantener la iniciativa apuntando a la vesión 1.0.0 de la política, aunque podamos publicar una nueva versión con la corrección y darle otro uso (ej: herramienta para los equipos de desarrollo para que sepan el grado de cumplimiento que tendrán en producción recursos que están en desarrollo).
Añadir un metadato a la definición al desplegarla en el tenant de AzureAD.

Es más limpia, pero dado que la URL que referencia a una definición de Azure Policy desplegada no incluye este campo, no servirá para referenciarla. Son simplemente metadatos muy útiles si queremos referenciar desde ellos conceptos como el commit del repo git desde el que se desplegó, la versión, etc.

Posible mejora para Azure Policy: que la versión sea un atributo con entidad en las definiciones y además se pueda referenciar en la URL de forma opcional, por ejemplo: /providers/Microsoft.Management/managementgroups/mi-management-group-1/providers/Microsoft.Authorization/policyDefinitions/mi-politica-1#v1.0.0

La recomendación es usar el primero, es decir, añadir un sufijo con el número de versión, tanto a los nombres de las definciones de Azure Policy como a las iniciativas que las agrupan.

Conclusión

Las Azure Policy son un componente software, sí implementado en un lenguaje JSON con expresiones lógicas, pero un componente software al fin y al cabo que define el comportamiento del Azure Resource Manager, componente importante en Azure. Por tanto, usar un sistema de control de versiones (ej: git) y versionar tanto las definiciones de Azure Policy como sus agrupaciones lógicas (iniciativas) es fundamental.

En el siguiente artículo trataré cómo gestionar el crecimiento descontrolado de definiciones de Azure Policy, dado que el número de productos en Azure es gigante y nuestras normas, que derivan en Azure Policy, serán complejas: cómo gestionar la trazabilidad entre las definiciones de Azure Policy que tenemos con los productos y las normas que cubren.

Mejores Prácticas de Diseño Azure Policy - Separación de Conceptos (SoC)

Mon, 20 Jul 2020 22:00:00 +0000

Esta es una serie de artículos con mi experiencia después de un año en un equipo de diseño e implementación de Azure Policy en el área de Ciber Seguridad Global de Grupo Santander. En estos artículos intentaré resumir las lecciones que hemos aprendido al diseñar, implementar y mantener Azure Policy:

Mejores Prácticas de Diseño Azure Policy - Estructura lógica simple

Mejores Prácticas de Diseño Azure Policy - Separación de Conceptos (SoC)

Mejores Prácticas de Diseño Azure Policy - Control de versiones

Mejores Prácticas de Diseño Azure Policy - Identificadores y trazabilidad

Mejores Prácticas con Azure Policy - SSDLC - Automatizar la revisión

Tabla de Contenido

Convención: estructura lógica simple
Comprobando varios atributos de un recurso
Antes de seguir: operadores prefijos / operadores infijos y sintaxis en Azure Policy
Dónde quiero llegar
Azure Policy - Mejor Práctica de Diseño: Separación de Conceptos (SoC)
Conclusión
- Mejora para sintaxis de Azure Policy

En el primer artículo presenté la que desde mi punto de vista es la primera mejor práctica al diseñar definiciones de Azure Policy: definir una estructura simple y crear una convención de diseño para implementar todas las definiciones. Vamos a retomar en el punto donde lo dejamos antes de llegar a la siguiente mejor práctica que recomiendo.

Convención: estructura lógica simple

El lenguaje usado para definir Azure Policy es un lenguaje que usa únicamente expresiones lógicas, lo que hace que la complejidad de una definición aumente descontroladamente si no se establecen unas normas básicas de diseño.

Siguiendo con el razonamiento del artículo anterior, supongamos que tenemos definida la siguiente estructura como convención en el diseño de definiciones de Azure Policy:

si( RECURSO y FILTRO y ATRIBUTO ) entonces EFECTO

El EFECTO en las Azure Policy está relacionado con un recurso que no es conforme a nuestra norma, es decir, cuyo atributo no tiene el valor esperado. Vamos a actualizar la estructura para negar el atributo porque es más cercano a la realidad de las definiciones que crearemos casi siempre:

si( RECURSO y FILTRO y (no ATRIBUTO) ) entonces EFECTO

Por ejemplo, vamos a definir una política para comprobar que:

Todo Storage Account
Con la etiqueta importante con valor si
Deba tener protocolo HTTPS en su API activado.

La definición, siguiendo la estructura, sería:

si( "tipo=Storage Account" y "etiqueta importante=si" y (no "https") ) entonces EFECTO

La estructura sigue siendo la misma, pero buscamos recursos que tengan un valor no esperado en el atributo. Estos recursos representan un problema y sobre ellos haremos actuar a Azure:

Detectando: efecto será audit.
Corrigiendo: efecto será alterar el valor para que sea el deseado.
Previniendo: efecto será denegar el despliegue de todo recurso que no cumpla con la norma.

Comprobando varios atributos de un recurso

Con nuestra estructura ya adaptada al proceso de buscar recursos no conformes con nuestra norma vamos a analizar qué sucede cuando necesitamos hacer más complejas las expresiones lógicas en ella.

En algunos casos la expresión lógica RECURSO o FILTRO no son simples comprobaciones de un atributo. Por ejemplo, para encontrar recursos de tipo WAF, debemos buscar los Application Gateways de sku=WAF. En este ejemplo, la condición RECURSO de nuestra estructura se convierte en una expresión lógica en sí misma:

RECURSO := tipo="Application Gateway" y sku="WAF"

Lo que hace que nuestra definición pase a ser:

si( (tipo=AGW y sku=WAF) y FILTRO y (no ATRIBUTO) ) entonces EFECTO

Vamos a complicar haciendo que el filtro nos permita encontrar los WAF que tengan la etiqueta sistema con valor 1 ó 2 (porque tenemos varios sistemas pero queremos hacer comprobaciones sólo sobre estos dos, es un ejemplo…):

FILTRO := etiqueta sistema=1 o etiqueta sistema=2

Completando de nuevo la definición:

si( (tipo=AGW y sku=WAF) y (etiqueta sistema=1 o etiqueta sistema=2) y (no ATRIBUTO) ) entonces EFECTO

Aunque en la expresión de RECURSO los parénteris no afecten al resultado (axiomas y teoremas del álgebra de Boole), los he mantenido para que se siga apreciando la convención en la estructura de la definición: si( RECURSO y FILTRO y (no ATRIBUTO) ) entonces EFECTO. Sí es importante el paréntesis en el caso de la expresión de FILTRO porque fijaos que dentro cambia el operador, que pasa a ser o porque esperamos encontrar recursos de uno u otro tipo indistintamente, y para ambos queremos hacer la comprobación.

La expresión lógica con dos condiciones y para encontrar el tipo de recurso, y dos condiciones o para quedarnos sólo con el subconjunto de recursos que nos interesan, ya se empieza a complicar.

Antes de seguir: operadores prefijos / operadores infijos y sintaxis en Azure Policy

Las expresiones en los lenguajes de programación se pueden escribir mediante operadores prefijos, infijos y sufijos. Por ejemplo, para la suma de A y B:

Prefijo: + A B
Infijo: A + B
Sufijo: A B +

En los ejemplos que he puesto hasta ahora he usado la notación infija de los operadores, porque es la que usamos de forma natural:

si( RECURSO y FILTRO y (no ATRIBUTO) ) entonces EFECTO

Vamos a escribir esta misma estructura con operadores prefijos:

si( y RECURSO FILTRO (no ATRIBUTO) ) entonces EFECTO

O si estuviéramos en un lenguaje funcional: si( y( RECURSO, FILTRO, no( ATRIBUTO) ) ) ...

Y si lo representamos en forma de árbol:

si
- y
  - RECURSO
  - FILTRO
  - no ATRIBUTO
entonces
- EFECTO

Y ahora el último ejemplo para tener una representación visual de una definición más compleja: si( (tipo=AGW y sku=WAF) y (etiqueta sistema=1 o etiqueta sistema=2) y (no ATRIBUTO) ) entonces EFECTO

si
- y
  - y
    - tipo=AGW
    - sku=WAF
  - o
    - etiqueta sistema=1
    - etiqueta sistema=2
  - no
    - ATRIBUTO
entonces
- EFECTO

En la sintaxis de Azure Policy, los operadores son prefijos:

Producto (y): se expresa con el operador prefijo allOf (todos deben cumplirse)
Suma (o): se expresa con el operador prefijo anyOf (alguno debe cumplirse)
si: se expresa con el operador prefijo if
entonces: se expresa con el operador prefijo then
no: se expresa con el operador prefijo not

Nuestro ejemplo queda como sigue:

if
- allOf
  - allOf
    - tipo=AGW
    - sku=WAF
  - anyOf
    - etiqueta sistema=1
    - etiqueta sistema=2
  - not
    - ATRIBUTO
then
- EFECTO

Dónde quiero llegar

Esta historia que estoy contando tiene un objetivo: demostrar que la sintaxis de las Azure Policy, al estar basada en expresiones lógicas donde combinaremos los operadores y, o, no, condiciones sobre atributos y las propiedades distributivas y otras leyes del álgebra de Boole… llevan a que una definición de Azure Policy no crezca o envejezca de forma que sea facilmente mantenible.

La complejidad lógica de una Azure Policy, si no se tiene como objetivo principal la simplicidad, las hace inmanejables con el paso del tiempo.

Azure Policy - Mejor Práctica de Diseño: Separación de Conceptos (SoC)

Es fundamental que una definición de Azure Policy implemente un sólo concepto, una sola norma que queremos validar.

Porque no es lo mismo tener una Azure Policy que tenga la estructura:

si( RECURSO y FILTRO y (no ATRIBUTO) ) entonces EFECTO

Que tener:

si( RECURSO y FILTRO y (no ATRIBUTO1 o no ATRIBUTO2 o no ATRIBUTO3) ) entonces EFECTO

Porque como hemos visto antes, ya estamos mezclando operadores anidados y en este pseudo-código se puede llegar a ver la estructura de forma sencilla, pero cuando se codifica con la sintaxis JSON de una Azure Policy, el código es más largo y menos legible.

Apliquemos entonces el principio de la separación de conceptos, y del mismo modo que separamos en ficheros/métodos/clases/módulos/componentes un sistema, hagamos lo mismo con las reglas: una regla por definición.

El último ejemplo quedaría:

Definición primera: si( RECURSO y FILTRO y (no ATRIBUTO1) ) entonces EFECTO
Definición segunda: si( RECURSO y FILTRO y (no ATRIBUTO2) ) entonces EFECTO
Definición tercera: si( RECURSO y FILTRO y (no ATRIBUTO3) ) entonces EFECTO

Donde cada una de ellas es más legible, está en su propia definición, en su propio fichero JSON. Esto tiene grandes ventajas cuando varios programadores trabajan sobre la misma línea base, porque las posibilidades de conflicto en un fichero son menores, al tener más ficheros cada uno con una responsabilidad más específica.

Conclusión

La segunda mejor práctica es sencilla pero algunas veces los programadores tendemos a pasarla por alto: separa conceptos. Una Azure Policy = un fichero JSON = una norma = una estructura sencilla si( RECURSO y FILTRO y (no ATRIBUTO) ) entonces EFECTO

No pasa nada por crear más definiciones, cada una tendrá una responsabilidad bien definida, cada una será más legible.

Mejora para sintaxis de Azure Policy

En ingeniería del software hay una norma que consiste en no duplicar, en encapsular y reutilizar.

En el ejemplo trivial donde, para un mismo tipo de recurso queríamos comprobar tres atributos distintos (tres normas distintas para el mismo tipo de atributo), teníamos:

Definición primera: si( RECURSO y FILTRO y (no ATRIBUTO1) ) entonces EFECTO
Definición segunda: si( RECURSO y FILTRO y (no ATRIBUTO2) ) entonces EFECTO
Definición tercera: si( RECURSO y FILTRO y (no ATRIBUTO3) ) entonces EFECTO

¿No sería bueno poder definir RECURSO y FILTRO en una expresión, importarla desde nuestras definiciones y así no duplicar código?

Algo como:

Definición primera: si( MI_PRODUCTO1 y (no ATRIBUTO1) ) entonces EFECTO
Definición segunda: si( MI_PRODUCTO1 y (no ATRIBUTO2) ) entonces EFECTO
Definición tercera: si( MI_PRODUCTO1 y (no ATRIBUTO3) ) entonces EFECTO
Expresión: MI_PRODUCTO1 := RECURSO y FILTRO

Algo como lo siguiente, donde dos definiciones incluyen una referencia a una tercera donde se define la parte común RECURSO y FILTRO:

Definición primera:

...
{
  "allOf": [
    { "$ref": "#/products/sta_importante" },
    {
      "field": "location",
      "notEquals": "global"
    }
  ]
}
...

Definición segunda:

...
{
  "allOf": [
    { "$ref": "#/products/sta_importante" },
    {
      "field": "Microsoft.Storage/storageAccounts/supportsHttpsTrafficOnly",
      "equals": "false"
    }
  ]
}
...

Siendo la parte común:

{
  "products": {
    "sta_importante": {
      "allOf": [
        {
          "field": "type",
          "equals": "Microsoft.Storage/storageAccounts"
        },
        {
          "field": "tags.importante",
          "matchInsensitively": "si"
        }
      ]
    }
  }
}

Esto permitiría modularizar las expresiones lógicas y por ende, hacer más legible y mantenible el código de las Azure Policy.

En el siguiente artículo continuaremos tirando del hilo sobre el hecho de que las definiciones de Azure Policy son componentes software en un sistema lo que lleva a mejores prácticas relacionadas: control de versiones, etc.

Mejores Prácticas de Diseño Azure Policy - Estructura lógica simple

Sat, 18 Jul 2020 16:00:00 +0000

Esta es una serie de artículos con mi experiencia después de un año en un equipo de diseño e implementación de Azure Policy en el área de Ciber Seguridad Global de Grupo Santander. En estos artículos intentaré resumir las lecciones que hemos aprendido al diseñar, implementar y mantener Azure Policy:

Mejores Prácticas de Diseño Azure Policy - Estructura lógica simple

Mejores Prácticas de Diseño Azure Policy - Separación de Conceptos (SoC)

Mejores Prácticas de Diseño Azure Policy - Control de versiones

Mejores Prácticas de Diseño Azure Policy - Identificadores y trazabilidad

Mejores Prácticas con Azure Policy - SSDLC - Automatizar la revisión

Tabla de Contenido

Introducción a Azure Policy
Algebra de Boole
Azure Policy - Mejor Práctica de Diseño: simplifica la lógica de la definición
Estructura básica de una Azure Policy
Conclusión

Introducción a Azure Policy

La definición más corta que se me ocurre de una Azure Policy es:

Una tecnología basada en un lenguaje JSON que permite definir reglas lógicas sobre atributos de recursos de Azure. Estas reglas lógicas (y, o, entonces, para todo, etc) ofrecen flexibilidad para implementar controles detectivos, correctivos, lo más importante, preventivos, sobre recursos en Azure.

Usos que se pueden hacer de Azure Policy:

Controles detectivos: lo que se suele llamar auditoría continua, es decir, detección casi en tiempo real del cambio en un atributo de un recurso de nube a un valor no deseado. Por ejemplo, la desactivación de cifrado en tránsito en el API de una base de datos gestionada.
Controles correctivos: como los detectivos pero además de detectar el recurso no conforme con la regla, cambian el valor del atributo para que sea el deseado.
Controles preventivos: dentro de lo que se suele llamar el shift-left de la seguridad, es decir, llevar los controles de seguridad a la izquierda en el ciclo de desarrollo (más cerca del diseño, mucho antes de la fase de operación y mantenimiento de los sistemas), las Azure Policy permiten implementar controles preventivos en el momento mismo de despliegue de los recursos de nube.

Haciendo uso de la propia definición de Microsoft del ciclo de desarrollo seguro del software, las Azure Policy como controles preventivos estarían en la fase Release, mientras que las Azure Policy como controles detectivos y correctivos estarían en la fase Response:

Es decir, con Azure Policy podemos crear por una parte reglas que detecten y corrijan recursos ya desplegados que tienen atributos con valores no deseados, y por otra, reglas que impidan desplegar siquiera estos recursos.

Antes de continuar quiero aclarar mi postura al respecto del shift-left de la seguyridad y es la siguiente: detectar y opcionalmente corregir un problema en la configuración de seguridad de un sistema cuando ya está en producción es demasiado tarde y hacerlo cuando se está en el proceso mismo de despliegue es igualmente tarde y además un generador de ruido infinito. Quien no haya sufrido las prisas de un despliegue-que-llega-tarde-para-negocio que levante la mano. Y ahora imaginad que falla porque se pasaron por alto requisitos durante la fase de diseño e implementación y la Azure Policy lo deniega. Resultado: caos absoluto.

Álgebra de Boole

Como decía en la introducción, las definiciones de Azure Policy que implementan nuestros controles, lo hacen con un lenguaje basado en JSON cuya sintaxis permite definir reglas lógicas.

El álgebra de Boole define todas las reglas que estamos habituados a usar en programación en las expresiones condicionales, que en el álgebra de Boole reciben el nombre de operadores, axiomas, teoremas…:

complemento: que solemos llamar negación, es decir, el NOT.
suma: que solemos llamar o, es decir, el OR.
producto: que solemos llamar y, el AND.

Y todas las propiedades que más o menos aplicamos de forma automática:

A and B es lo mismo que B and A (ley conmutativa del producto).
A or B es lo mismo que B or A (ley conmutativa de la suma).
not not A es A (doble negación).
A and (B or C) es lo mismo que (A and B) or (A and C) (distributiva respecto del producto).
A or (B and C) es lo mismo que (A or B) and (A or C) (distributiva respecto de la suma).
…

Y las Leyes de Morgan, que junto con lo anterior, me llevan a mi primer mejor práctica de diseño de Azure Policy:

not (A and B) es lo mismo que (not A) or (not B)
not (A or B) es lo mismo que (not A) and (not B)

Azure Policy - Mejor Práctica de Diseño: simplifica la lógica de la definición

Antes de implementar una Azure Policy, debes dominar el álgebra de Boole. Quizá en tus estudios tuviste esta asignatura (en informática hay varias asignaturas: álgebra, lógica de primer orden, programación…), y si no, en matemáticas básicas también se tratan estos axiomas (pensando en sumas y productos en vez de en operadores OR y AND).

En cualquier caso, un programador con cierta experiencia en casi cualquier lenguaje, habrá sudado depurando condiciones lógicas en los programas que crea o mantiene.

¿Por qué pongo este principio como el primero?

Por lo siguiente…

Estructura básica de una Azure Policy

Dejando de lado los detalles técnicos de la sintaxis de Azure Policy, que siempre tienen zonas oscuras como todo lenguaje de programación, la estructura de una Azure Policy, desde un punto de vista de alto nivel, podría ser algo así:

Tipo de recurso sobre el que quiero comprobar atributos. Por ejemplo: Storage Account (STA).
Filtro adicional sobre los recursos de ese tipo para aplicar el control solo a algunos. Por ejemplo, sólo las STA que tengan una etiqueta concreta.
Condición sobre el atributo que quiero comprobar. Por ejemplo, si el cifrado en tránsito está desactivado (HTTPS).
Efecto: detectivo/preventivo/…

Además, en muchos casos, la lógica de una Azure Policy es del tipo si... entonces..., con lo que la estructura sería así:

Si…
1. El recurso es del tipo que busco, y…
2. El recurso cumple con el filtro adicional, y…
3. El atributo tiene el valor que busco
Entonces: el efecto debe ser…

De pronto, ya estamos usando álgebra de Boole:

si ( TIPO y FILTRO y VALOR ) entonces EFECTO

Esta estructura es sencilla de entender: si se cumplen las tres condiciones TIPO y FILTRO y el VALOR es el esperado, entonces se produce el efecto.

Sencillo, ¿no?

Consejo:

Como en cualquier lenguaje de programación, se debe definir una convención en el diseño de Azure Policy, por ejemplo, forzando a usar siempre una misma estructura, como la definida arriba.

Consejo:

Y como en cualquier otro lenguaje de programación, se deben implementar comprobaciones automáticas estáticas sobre la calidad de un programa: comprobar automáticamente que el fichero JSON que define una Azure Policy es conforme al esquema JSON de estas.

Conclusión

Es muy importante partir de una estructura sencilla y establecer una convención de diseño al crear Azure Policy, porque las reglas lógicas se complican cuando hay varias condiciones, estas se anidan y aplicamos las leyes y axiomas presentados anteriormente. Disponer de una estructura para repasar a alto nivel una Azure Policy es fundamental para el proceso de revisión y la mantenibilidad de las mismas. Como en todo componente software, se implementa una vez pero se mantiene para siempre y hay que simplificar para que sea entendible.

En el siguiente artículo de mejores prácticas daré continuidad a estos puntos abiertos y enlazaré con la importancia de (1) tener una estructura simple y convención de diseño de Azure Policy, y (2) conocer el álgebra de Boole al diseñar estas reglas.

Notes on article: Towards Secure Cloud Orchestration for Multi-Cloud Deployments

Sat, 05 Jan 2019 00:00:00 +0000

Notes on article: ‘Towards Secure Cloud Orchestration for Multi-Cloud Deployments’

These are just some personal notes on the article: http://doi.acm.org/10.1145/3195870.3195874

Assumptions

Hardware integrity
Physical Security
Low-Level Software Stack
Cryptographic Security
Availability

Adversary Capabilities

Network Infrastructure <== network is not trusted

High Level Attacks

VM Substitution Attack: start vulnerable VMs
Host Substitution Attack: bypass VM placement policies.
Storage Host Substitution Attack: bypass storage placement policies.
Resource Parasite Attack: bypass infrastructure configuration policies, e.g. for running processes.
Placement Bias Attack: bypass placement policies in federated environments.

Orchestration Security Enablers

Crypto Engine
Credential Manager
Firewall Service
PKI Manager
Attestation Service: Image Integrity Verifier, Image Delta Verifier

Sistema de gestión de API – KONG (2)

Sat, 24 Nov 2018 00:00:00 +0000

Hace unos años, allá por 2016, cuando trabajaba en Genexies Mobile, tuve mi primer contacto con KONG, un API manager que por aquel momento no tenía mucho recorrido (Sistema de gestión de API – KONG).

Recientemente he empezado a trabajar revisando la Arquitectura de Seguridad de un proyecto de innovación y resulta que usan KONG como API manager. Mi sorpresa ha sido mayúscula cuando he visto todo lo que había progresado el proyecto KONG desde la última vez que supe algo de él.

Conforme empiece a profundizar en el análisis de la Arquitectura de Seguridad de esos componentes del sistema, iré dejando una seria de posts aquí a modo de puntos claves para hacer una integración segura de este sistema de API Manager.

Saludos.

Instalación de minishift y Containers Development Kit (RedHat) en macOS

Wed, 27 Dec 2017 10:40:26 +0000

OpenShift es una plataforma de desarrollo basada en contenedores de RedHat, creada sobre Kubernetes y siguiendo la filosofía de muchas plataformas y frameworks actuales. Es decir, tiene un CLI para operar con ella.

Minishift es un CLI para lanzar en tu propia estación de trabajo un mini-cluster de OpenShift.

CDK (Containers Development Kit) son un conjunto de herramientas (JDK 1.8, entorno basado en Eclipse…) para el desarrollo rápido de aplicaciones JAVA basadas en contenedores. Básicamente, poder desarrollar aplicaciones sin tener que dedicarle mucho tiempo a montar el entorno y con un montón de configuraciones (en el IDE por ejemplo), para que desplegar en local y depurar sean acciones a las que no haya que dedicarle mucho tiempo.

Son herramientas o soluciones de RedHat, pero no dejan de estar basadas en otras de código abierto, con lo que no es “peligroso” apoyarse en ellas para el desarrollo, siempre que se tenga clara la línea que separa ambas, y conociendo lo que subyace.

Para instalar el entorno en macOS hay principalmente dos opciones:

Seguir las instrucciones oficiales y descargar paquetes desde el navegador.
Usar homebrew, o una mezcla de ambas, pero instalando desde esta herramienta lo más posible.

He optado por la segunda, y aquí está la chuleta:

# Para usar virtualización "nativa" xhyve en macOS:
brew info --installed docker-machine-driver-xhyve

# Ahora sí:
brew install docker-machine-driver-xhyve
docker-machine-driver-xhyve need root owner and uid
sudo chown root:wheel $(brew --prefix)/opt/docker-machine-driver-xhyve/bin/docker-machine-driver-xhyve
sudo chmod u+s $(brew --prefix)/opt/docker-machine-driver-xhyve/bin/docker-machine-driver-xhyve

brew cask install minishift

# Ojito con los servicios proxy corporativos, porque la instalación captura
# la configuración y la inyecta en la máquina virtual...
export HTTPS_PROXY="http://odio.los.proxies:3128"
export HTTP_PROXY="http://odio.los.proxies:3128"

# Y al arrancar el cluster por primera vez, lo crea...
minishift start

# CLI de OpenShift
brew install openshift-cli

# Probando, probando, 1, 2, 3... ssssí, ssssí
eval $(minishift oc-env)
oc whoami
oc project

# Acceso via web (developer/developer por defecto en minishift):
open "https://192.168.64.4:8443"

# Hecho.

Espero que sirva de ayuda.

WineHQ en macOS: instalación de Sparx Enterprise Architect

Fri, 22 Dec 2017 10:36:22 +0000

Hace mucho tiempo que no usaba WineHQ, tenía muchas expectativas en él para la necesidad que tenía y la verdad es que no me ha decepcionado nada en absoluto.

En concreto necesitaba instalar Sparx Enterprise Architect en macOS y encontré una pequeña guía en los foros de la herramienta: https://www.sparxsystems.com/support/faq/enterprise-architect-WINE.html#point1

Aunque las instrucciones en esa guía son para una distribución de Linux basada en Debian, sirven para macOS con algunos cambios. También tuve que hacer algunos pasos adicionales, y como en parte uso este blog como un super-post-it donde dejar anotadas cosas que quizá necesite en el futuro, pues ahí va:

brew install wine winetricks
winetricks msxml3 msxml4 mdac28

# En mi caso, por otras herramientas relacionadas con EA, tuve que instalar también:
winetricks dotnet452 corefonts

# Y para que las fuentes se vean "decentes":
winetricks fontsmooth-rgb

# Finalmente:
wine msiexec /i easetupfull.msi

# Para configurar el tamaño de la fuente en pantalla:
wine winecfg

Y fin.

Calidad del código de proyectos de código abierto

Fri, 12 May 2017 15:33:34 +0000

Estamos emocionados con los proyectos de código abierto. Tanto, que en ocasiones ni miramos la licencia, pero ese es otro tema de debate…

¿Has comprobado alguna vez la calidad del código de un proyecto de código abierto que usas? ¿De alguna de las decenas de dependencias que instala tu npm o maven de turno? ¿De al menos la más importante? (dejo a tu elección la definición de “importante”).

Yo no.

Pero…

Desde hace unos meses trabajo en un equipo de ciberseguridad, y entre lo que estoy aprendiendo y los boletines de seguridad a los que me estoy suscribiendo, cada vez tengo más miedito en el cuerpo.

Miedito porque absolutamente todos los proyectos que conozco dependen de otros de código abierto, y porque ~~aporreamos el teclado~~ programamos a una velocidad que nos hace pasar por alto muchas cosas, entre ellas la seguridad. No pienso siquiera en “programación segura”, es decir, que seas un verdadero Ninja de la programación (no un Ninja-postureo) y que no te hagan un overflow… o seamos más actuales, que no te hagan una inyección de SQL (es muy triste que en 2017 todavía estemos hablando de esto)… o te ejecuten código JavaScript en el servidor Node.js de tu API REST molona (porque te envíen un JSON malicioso que no sanitizas)…

Y lo peor de todo es que si nos tomamos la seguridad como se merece, con un buen modelo de madurez encima de la mesa (lo hay, ya haré otro artículo al respecto), pasar de cero a “algo” es casi trivial.

Repito, pasar de “no hacemos ninguna comprobación de seguridad de nuestro código” a “pasamos comprobaciones básicas en nuestro sistema de integración casi-continua” es… TRI-VI-AL.

Mal de muchos, consuelo de tontos

Las barbaridades que se oyen sobre cómo trabajan en startups y no-tan-startups… vamos a ser positivos, vayamos a cómo hacerlo.

Programar es un arte y ahora viene una máquina a decirte tal o cual…

Pero atención, usar analizadores estáticos de código, que es de lo que voy a hablar en el artículo, que son herramientas que buscan patrones en el código, que buscan la adhesión a convenciones… puede hacer algo de daño al principio. Siempre existen falsos positivos, hay reglas con las que no todos los ingenieros estamos de acuerdo (por eso debemos tener criterio), y algunas, aun cuando están justificadas, incluso escuecen.

No puedes suponer que después de varios años escribiendo código de una forma, vayas a aceptar las recomendaciones con alegria y gozo. Algunas no te gustarán. Otras incluso harán que te aflore un sentimiento de vergüenza sobre el código que has podido escribir en el pasado. Creo que eso es positivo, significa que estás aprendiendo de los errores, pero sólo lo consigues con la mente abierta. No hay nada más objetivo que la crítica (constructiva) de un algoritmo basado en evidencias y el conocimiento de muchos ingenieros.

Comprobaciones básicas on-premise

Voy a centrarme sólo en aplicaciones JAVA + MAVEN, pero con algo de Google se pueden encontrar alternativas para otros lenguajes para muchos de los puntos que listo a continuación (https://docs.sonarqube.org/display/PLUG/Plugin+Library).

Calidad del código: seguir convenciones

A estas alturas, no vamos a discutir este tema recurrente.

Opción 1 – “cero” esfuerzo (SonarQube)

Cómo: SonarQube / SonarJava, el plugin oficialmente soportado por SonarQube para JAVA hace este tipo de comprobaciones.

Si usas MAVEN, instala SonarQube y después: https://docs.sonarqube.org/display/SCAN/Analyzing+with+SonarQube+Scanner+for+Maven

Qué: “Coding Convention” (https://www.sonarsource.com/why-us/products/codeanalyzers/sonarjava.html)

Resultado: Comprobaciones típicas de JAVA.

Opción 2 – Instalar otro plugin adicionalmente (SonarQube)

Cómo: SonarQube Checkstyle plugin (https://github.com/checkstyle/sonar-checkstyle)

Qué: Checkstyle para JAVA (http://checkstyle.sourceforge.net/)

Resultado: Las comprobaciones básicas de SonarJava y las de Checkstyle. Ooook.

Calidad del código: evitar malos olores

Las comunicaciones entre las personas que forman una organización imitan la estructura de la organización. Del mismo modo, el código huele según el estado de ánimo del programador en cada momento, o de sus hábitos.

Cómo: SonarQube / SonarJava

Qué: 218 reglas específicas de “Code Smells” (https://www.sonarsource.com/why-us/products/codeanalyzers/sonarjava/rules.html#Code_Smell_Detection)

Resultado: No sólo convenciones, si no estructuras y uso del lenguaje que tienen mala pinta… Oooooook.

Calidad del código: programación segura-qué?

Hay muchas fuentes de documentación sobre seguridad (errores típicos de programación, vulnerabilidades, etc). Un analizador estático de código es capaz de encontrar patrones de programación insegura (somos tan predecibles los programadores…), así que…

Opción 1 – “cero” esfuerzo (SonarQube)

Cómo: SonarQube / SonarJava

Qué: 212 reglas específicas que cubren recomendaciones de seguridad de los siguientes “estándares”

CWE (Common Weakness Enumeration): https://cwe.mitre.org/
CWE/SANS TOP 25 Most Dangerous Software Errors: https://www.sans.org/top25-software-errors/
OWASP Top Ten (10 Most Critical Web Application Security Risks): https://www.owasp.org/index.php/Category:OWASP_Top_Ten_Project
MISRA: https://www.misra.org.uk/MISRAHome/WhatisMISRA/tabid/66/Default.aspx
SEI CERT (Software Engineering Institute / Carnegie Mellon University): https://www.securecoding.cert.org/confluence/display/seccode/SEI+CERT+Coding+Standards

Resultado: Resulta que sólo con SonarJava ya tenemos unas cuantas comprobaciones de calidad… Ooooooooook

Opción 2 – OWASP Dependency Check (JAVA / .NET)

¿Usas alguna dependencia con vulnerabilidades conocidas? Lo primero es conocer la respuesta a esta pregunta, y lo segundo actualizar tus dependencias vulnerables a versiones sin esa vulnerabilidad CONOCIDA. Resalto lo de CONOCIDA.

Qué: OWASP Dependency Check

Cómo: herramienta integrable con MAVEN, ANT, sbt… https://www.owasp.org/index.php/OWASP_Dependency_Check

Resultado: Otro plugin más en el flujo de compilación de MAVEN, pero te obliga a mantenerte al día…

Comprobaciones básicas en-la-nube

Para proyectos de código abierto existen muchos recursos gratuitos en internet. Todas las startups están como locas captando usuarios, y las que ofrecen productos y servicios entorno al desarrollo de aplicaciones no son menos.

Así que si tienes un proyecto de código abierto, te puedes evitar instalar un SonarQube, un TeamCity y toda la parafernalia que los rodea. Simplemente podrás darte de alta, indicar cuáles son tus repositorios y darle al “play”:

SonarQube: ellos mismos ofrecen un servicio online gratuito para proyectos de código abierto, así que todas las comprobaciones de la sección anterior están disponibles.
CodeClimate: “Obtén revisiones de código automatizadas para cobertura de pruebas, complejidad, duplicación, seguridad, estilo y más, y mezcla con confianza”. Los filtros para navegar por los problemas encontrados son un poco pobres, pero es un primer paso.
Codacy: me da la impresión de que internamente usan SonarQube, la interfaz está muy cuidada y me ha gustado bastante.

Y con TravisCI completamos el ciclo…

Volviendo al tema…

Por tanto… todo software de código abierto que se precie, sin invertir un céntimo, tiene acceso a recursos que le permitirían revisar la calidad de su código, incluso desde el punto de vista de la seguridad.

Supongamos que alguien, por ejemplo yo, está evaluando soluciones de código abierto de un tipo concreto. Estas ofrecen versiones “enterprise” (EE) que aportan valor adicional a la versión “community” (OSS), que será las que contrates cuando tomes la decisión de cuál usar.

Al haber varias empresas ofreciendo soluciones de ese tipo, bajo ese mismo modelo de negocio OSS+EE, ¿no deberían todas ellas cuidar su código? ¿no deberían aprovechar todos los recursos que hubiera disponibles? ¿no deberían demostrar públicamente que su producto EE está sostenido por una solución de código abierto de calidad comprobable, de calidad de la buena…?

Pues no. Y es una pena.

Solución

Quieres evaluar una solución de código abierto porque te estás planteando contratar los servicios de la versión “enterprise”. Pues si ellos no han hecho bien su trabajo, al menos podrás:

Crear un “fork” de su repositorio community.
Darte tú de alta en los servicios.
Configurarlos hacia tus “forks”.
Analizar el código.
FIN.