Proyecto librería de Aspects

Este repositorio contiene una librería de aspects. Los aspects son una herramienta de AWS que nos permite aplicar una operación determinada a todos los constructs dentro de un mismo bloque o módulo. En el ámbito de la arquitectura, se usarán los aspects para asegurar que los objetos creados en los stacks cumplen unos criterios generales, de observabilidad y de seguridad determinados. De esta manera, mediante la importación de esta librería en otro proyecto, se checkearán las propiedades de cada uno de los objetos creados en un stack, asegurando que los valores se encuentran dentro de los establecidos por el proyecto.

La arquitectura se asegura de realizar estas validaciones mediante dos vías:

• La importación, aplicación y personalización de determinadas reglas proporcionadas por AWS a través de la utilidad cdk-nag Enlace a la documentación proporcionada por AWS. Es posible la aplicación directa de esta librería en cualquier proyecto, asegurando el cumplimiento de determinados estándares de seguridad. Sin embargo, se ha decidido realizar una personalización de las reglas que cdk-nag incluye, de manera que se han modificado las reglas que se aplican, así como el nivel de error de algunas de las mismas.

• La creación de validaciones propias de la arquitectura. Con esto se pretende asegurar el cumplimiento de determinados aspectos de seguridad y utilización que no están cubiertos por las reglas importadas de cdk-nag.

Aplicación de la librería

La librería de Aspectos diferencia a la hora de aplicar las reglas que la forman. Esta diferenciación se basa en dos factores: el tipo de aplicación con la que se esté trabajando, a distinguir entre Backend, BFF y Front, y el entorno en el que se desplegará nuestra aplicación, a distinguir entre Sandbox, Desarrollo, Pre-producción y Producción. Por tanto, será necesario indicar que tipo de arquitectura y entorno se está utilizando a la hora de hacer uso de la librería, para que se apliquen unas reglas u otras.

Para ello, será necesario pasar los siguientes parámetros a la hora de crear la clase ARCHValidation, encargada de aplicar los aspectos a una app de CDK:

• app: Objeto de tipo cdk.App con la aplicación que se crea para poner en funcionamiento el arquetipo.
• envTypes: Parámetro de tipo EnvironmentTypes, creado para representar los tipos de entorno disponibles (SND,DEV, PRE y PRO)
• archTypes: Parámetro de tipo RefArchitectureTypes, creado para representar los tipos de arquitecturas disponibles (BACK, BFF y FRONT)
• input: Fichero package.json del proyecto, en el que se buscarán códigos de nuevas iniciativas válidos.

Organización de las clases de la librería

De manera interna, la librería arch-cdk-aspects, organiza las clases que aplican las reglas por la tipología del servicio que evalúan. Las distintas tipologías son: compute, database, integration, networking, orchestration, security y storage.

Cabe destacar que todas estas clases y la organización de las mismas, es transparente para el usuario, que simplemente deberá aplicar el uso de la librería como ya se ha indicado en esta documentación.

Reglas con diferenciación por entorno

Como se ha comentado, algunas de las reglas no se aplican de la misma manera en todos los entornos o tipos de arquitectura. A continuación, se van a indicar las reglas que diferencian por entorno y el nivel de error con el que se aplican en cada uno.

| Rule-ID | SND | DEV | PRE | PRO | |--------------|--------------|--------------|--------------|--------------| | APIGWSSLEnabled | WARNING | WARNING | ERROR | ERROR | | APIGWCacheEnabledAndEncrypted | WARNING | WARNING | ERROR | ERROR | | CloudFrontDistributionHttpsViewerNoOutdatedSSL | WARNING | WARNING | ERROR | ERROR | | CloudFrontDistributionNoOutdatedSSL | WARNING | WARNING | ERROR | ERROR | | ALBHttpToHttpsRedirection | WARNING | WARNING | ERROR | ERROR | | ALBHttpDropInvalidHeaderEnabled | WARNING | WARNING | ERROR | ERROR | | WAFLogsReplication | WARNING | WARNING | ERROR | ERROR |

Reglas con diferenciación por arquitectura

Como se ha comentado, algunas de las reglas no se aplican de la misma manera en todos los entornos o tipos de arquitectura. A continuación, se van a indicar las reglas que diferencian por arquitectura y el nivel de error con el que se aplican en cada una.

| Rule-ID | BACK | BFF | FRONT | |--------------|--------------|--------------|--------------| | LambdaInsideVPC | ERROR | WARNING | No aplica | | APIGWCacheEnabledAndEncrypted | ERROR | WARNING | No aplica |

Enlaces a la documentación de las reglas

• Reglas aplicadas a los servicios de computación

• Reglas aplicadas a los servicios de bases de datos

• Reglas aplicadas a los servicios de integración

• Reglas aplicadas a los servicios de orquestación

• Reglas aplicadas a los servicios de almacenamiento

• Reglas aplicadas a los servicios de seguridad

• Reglas aplicadas a los servicios de networking

• Reglas aplicadas a los servicios de analytics

Supresión de una regla de aspectos

Es posible suprimir la aplicación de cada una de las reglas que conforman los aspectos de seguridad. Es necesario destacar que, para suprimir el uso de alguna regla, se debe contar con autorización para ello.

Para consultar el proceso de supresión de reglas, se proporciona la siguiente documentación.

Uso de Tagging

Esta librería ofrece la posibilidad de taggear los recursos que se despliegan. Para ello, se hace uso de la clase ARCHTagging. Igual que ocurre con los aspectos, los tags se aplican a nivel de aplicación CDK, por tanto, se debe llamar al constructor de ARCHTagging tras haber creado la App. Es necesario mencionar que, puesto que se aplican a nivel de App, todos los recursos dentro de esta, incluirán los tags al ser desplegados.

Para consultar el proceso de taggeo de recursos, se proporciona la siguiente documentación.