Introducción al Secure DevOps Kit for Azure

El 27 de abril del 2019 tuvimos una excelente jornada de #DevSecOps en Microsoft "GLOBAL AZURE BOOTCAMP 2019" Desde DevSecOps AR brindamos la charla "DevSecOps con Azure DevOps" de Luciano Moreira y Christian Ibiri.

Luego de nuestra charla tuvimos muchas consultas sobre Secure DevOps Kit for Azure en esta serie vamos a tratar de explicar sus principales características. 

ASC es muy útil para que los especialistas en Seguridad y Propietarios de cargas de trabajo en la nube monitoreen continuamente la higiene de seguridad de sus cargas de trabajo. Sin embargo, ASC es una herramienta de seguridad central para los recursos ya implementados.

Como sabemos, las aplicaciones en la época de la nube se están desarrollando en métodos ágiles y con la cultura DevOps. Esto significa que las aplicaciones no se implementan una sola vez como en el modo tradicional, sino en varias oleadas (por ejemplo, en sprints). Los equipos de desarrollo y operaciones ya no trabajan en silos, sino que cooperan a lo largo de todo el ciclo de vida de desarrollo de las aplicaciones.

En el contexto de la nube, las aplicaciones se despliegan en modo continuo (Integración continua/entrega continua, también conocida como CICD) y deben ser seguras desde la fase de codificación hasta el despliegue en producción.

Para lograrlo, no sólo los equipos de operaciones deben conocer y/o ser responsables de la seguridad de las aplicaciones de la nube. Los equipos de desarrollo también deberían contribuir a la seguridad de las aplicaciones de la nube e integrar la seguridad desde el principio y durante cada etapa. Para ello, una herramienta de seguridad como el Centro de Seguridad Azure no es apropiada para ser utilizada por los equipos de desarrollo para validar el estado de seguridad de sus aplicaciones antes de pasar a producción.

El Kit de Desarrollo Seguro para Azure (también conocido como AzSK) está ahí para complementar este vacío del Centro de Seguridad Azure.

Microsoft define AzSK como "un conjunto de automatización, extensiones, plugins, plantillas, módulos y otras herramientas que se combinan para ofrecer un flujo de trabajo de desarrollo enfocado en la seguridad para nuestros equipos de ingeniería de DevOps que trabajan en la nube". El objetivo del kit es capacitar a nuestros equipos para construir y utilizar soluciones basadas en Azure de manera consistente, repetible y eficiente con seguridad integrada en cada etapa".

AzSK ha sido desarrollado inicialmente para los equipos internos de Microsoft y liberado después para los usuarios de Azure. No es un producto comercial con soporte de usuario, pero es una solución gratuita para ser usada como tal, sin soporte de Microsoft.

La siguiente figura muestra cómo las 6 principales herramientas del kit de herramientas de DevOps se unen para permitir un desarrollo seguro en la nube.

El Kit de Desarrollo Seguro para el Azul es un marco que permite a los usuarios/clientes del azul:

• Asegurar sus suscripciones
• Asegurar su desarrollo
• Comprobar la seguridad en los oleoductos de Integración Continua/Entrega Continua
• Rastrear la deriva de la seguridad en la producción (Garantía continua)
• Monitorizar la seguridad en todas las etapas de DevOps (Alerta y Monitoreo)
• Riesgos de nubes agregados en toda la empresa (Gobernanza de riesgos de nubes/Telemetría de seguridad)

En este post, aprenderás las capacidades principales del Kit de Desarrollo Seguro para Azure (también conocido como AzSK).


1) Interesados en el Kit de Desarrollo Seguro para Azure (AzSK)


Los principales interesados que pueden utilizar AzSK en un ecosistema de Azure DevOps son los siguientes:

Partes interesadas	Capacidades relevantes de AzSK
Propietarios de suscripciones	Comprueba la salud de la seguridad general de las suscripciones de Azure Asegurarse de que los artefactos como las alertas de actividades importantes, la política de ARM, los bloqueos de recursos, las funciones del RBAC, etc., estén debidamente aprovisionados
Equipos de desarrollo o ingeniería	Obtén soporte en línea con consejos de seguridad y correcciones mientras escribes código para aplicaciones Azure Pruebe que los recursos Azure que están usando para las aplicaciones/soluciones están configurados y desplegados de forma segura Habilitar la seguridad en el CICD incluyendo varios ensayos de seguridad en los build/release pipelines
Equipos de implementación	Asegurar que una solución que se está desplegando en un entorno azul tiene un nivel de seguridad asegurado.
Equipos de operaciones	Rastree el estado de seguridad de una manera 'continua' y asegúrese de que no haya una 'deriva' descendente desde un estado seguro
Equipos de cumplimiento	Asegurar que se cumplan varios requisitos de cumplimiento, a menudo difíciles, (por ejemplo, SOX) para las soluciones basadas en el azufre
Equipos de seguridad	Usar todo lo anterior dependiendo de su dominio de InfoSec (Arquitecto, Analista, etc.)

2) Preparando el Kit de Desarrollo Seguro para Azure (AzSK)

La instalación de AzSK es muy sencilla. Consiste en los siguientes pasos sencillos:

Lanzar PowerShell ISE en lugar de la consola estándar de PowerShell
Verifique los prerrequisitos de PowerShell: verifique que PowerShell 5.0 o superior esté instalado con el comando $PSVersionTable

Instale el módulo AzSK PowerShell: Instalar-Módulo AzSK -Scope CurrentUser
El módulo AzSK PowerShell requiere los módulos AzureRM. Si los módulos AzureRM PowerShell no están instalados todavía, se instalarán durante la instalación del AzSK.

AzureRM es un conjunto de módulos de PowerShell que permite a los usuarios de Azure administrar (crear, leer, actualizar, eliminar, etc.) sus recursos de Azure desde PowerShell.

Después de la instalación de AzSK, puede comprobar lo que se ha instalado con el comando Get-InstalledModule de PowerShell de la siguiente manera:

Pueden ver que la última versión de AzSK (3.7.0) al momento de escribir este post ha sido instalada. También está la versión de los módulos dependientes de AzureRM PowerShell que han sido instalados.

El Kit de Desarrollo Seguro para Azure está evolucionando con el tiempo. Se recomienda utilizar siempre la última versión para escanear su entorno Azure para asegurarse de que está aprovechando los últimos controles de seguridad del módulo AzSK.

El módulo AzSK proporciona diferentes capacidades de auto-actualización con respecto a las diferentes etapas de DevOps:

Escaneos Adhoc: si está ejecutando la versión más antigua del escaneo AzSK desde su máquina local, recibirá una advertencia así como las instrucciones necesarias para actualizar el módulo. Puede registrarse para la actualización automática (a partir de la versión AzSK 2.8.x) e ir con la actualización manual ejecutando el siguiente comando: Set-AzSKPolicySettings -AutoUpdate On. Luego, durante la ejecución de cualquier comando de AzSK, si se libera una nueva versión, el flujo de trabajo de actualización automática se inicia automáticamente como sigue:

• El usuario es informado de la disponibilidad de una nueva versión y debe decidir si se actualiza o no. Si el usuario decide actualizarse, el flujo de trabajo de actualización continúa con los siguientes pasos
• Se pide al usuario que guarde su trabajo en todas las sesiones activas de PowerShell incluyendo la actual
• Se solicita al usuario que cierre todas las sesiones activas de PowerShell incluyendo la actual

Escáneres de Aseguramiento Continuo (CA): El módulo AzSK ejecuta los escaneos a través de CA, se actualiza automáticamente. Cada escaneo comprueba inicialmente si se ha lanzado alguna nueva versión y auto actualiza el módulo instalado a la última versión. No se requiere ninguna acción por parte del usuario.

Extensión AzSK CICD: el comportamiento por defecto de la extensión AzSK CICD es ejecutar siempre el escaneo usando el último módulo de AzSK de la galería.

3) Tipos de recursos Azure soportados

AzSK comenzó con el apoyo de sólo unos pocos tipos de recursos de Azure, pero actualmente (versión 3.7.0) soporta más de 35 tipos de recursos de Azure, incluyendo la suscripción.

A diferencia del Centro de Seguridad Azure, que permite monitorear la seguridad de algunos recursos básicos, incluyendo la suscripción, la computación y las aplicaciones, la red y el almacenamiento ya desplegados, AzSK permite a los clientes escanear la seguridad de más recursos Azure en diferentes etapas de DevOps.

Para tener la lista de todos los tipos de recursos de los servicios Azure que actualmente son soportados por su módulo AzSK PowerShell instalado, puede ejecutar el comando Get-AzSKSupportedResourceTypes de la siguiente manera:

Todos estos recursos Azure soportados tienen disponibles las Pruebas de Verificación de Seguridad (SVT) y estas SVT serán invocadas cada vez que se ejecute el comando Get-AzSKAzureServicesSecurityStatus.

Dependiendo de sus necesidades, puede ejecutar las pruebas de verificación de seguridad o los escaneos de todos los recursos de su entorno Azure o sólo de un subconjunto de recursos. Veremos cómo se hace en la siguiente sección o post, usando las capacidades de filtrado de los comandos de AzSK.

4) Comandos AzSK soportados

El actual AzSK (versión 3.7.0) proporciona más de 40 comandos de PowerShell que pueden ser listados con el comando de PowerShell Get-Help AzSK de la siguiente manera:

Como para cualquier cmdlet de PowerShell, puedes obtener los detalles de cada comando de AzSK escribiendo Get-Help <AzSK function/command>.

Por ejemplo, los detalles sobre el comando Get-AzSKSubscriptionSecurityStatus de AzSK se pueden obtener de la siguiente manera:

Es muy importante saber que algunos comandos de AzSK requieren más privilegios en Azure que otros. La siguiente tabla proporciona los permisos necesarios para algunos comandos clave de AzSK:

Comando	Alias	Descripción	Permiso requerido
Get-AzSKAzureServicesSecurityStatus	GRS	Escanea un conjunto de RG (o la suscripción completa)	Lector con suscripción o RG respectivos
Get-AzSKContinuousAssurance	GCA	Valida el estado de la cuenta de automatización de Continuous Assurance , incluida la condición de varios artefactos, como la cuenta de almacenamiento, horarios, runbooks, etc.	Lector en suscripción
Get-AzSKControlsStatus	GACS	Cmdlet único que combina Get-AzSKSubscriptionSecurityStatus, Get-AzSKAzureServicesSecurityStatus	Unión de permisos
Get-AzSKSubscriptionSecurityStatus	GSS	Escanea una suscripción de Azure en busca de mejores prácticas de seguridad y líneas de base de configuración para cosas como alertas, políticas ARM, RBAC, ASC, etc.	Lector en suscripción
Get-AzSKInfo	GAI	Ayuda a los usuarios a obtener detalles de varios componentes de AzSK	Lector en suscripción, Colaborador en AzSKRG
Install-AzSKContinuousAssurance	ICA	Configura la garantía continua de una suscripción. Esto crea varios artefactos, como el grupo de recursos, la cuenta de almacenamiento y la cuenta de automatización.	Propietario en suscripción
Install-AzSKOMSSolution	IOM	Crea e implementa una vista de OMS en una suscripción que tiene un espacio de trabajo de OMS	Lector en suscripción
Install-AzSKOrganizationPolicy	IOP	Este comando está destinado a ser utilizado por el equipo central de la Organización para configurar políticas específicas de la Organización	Colaborador en suscripción
Remove-AzSKAlerts	RAL	Elimina las alertas configuradas por AzSK	Propietario en suscripción
Remove-AzSKARMPolicies	RAP	Elimina la política ARM configurada por AzSK	Propietario en suscripción
Remove-AzSKSubscriptionRBAC	RRB	Elimina la configuración RBAC de AzSK. Por defecto, las cuentas centrales "obligatorias" no se eliminan y las cuentas "obsoletas" siempre se eliminan	Propietario en suscripción
Remove-AzSKSubscriptionSecurity	RSS	Elimina la configuración realizada a través de Set-AzSKSubscriptionSecurity	Propietario en suscripción
Repair-AzSKAzureServicesSecurity	RRS	Soluciona los controles de seguridad para varios recursos de Azure utilizando los scripts de reparación automatizados generados al ejecutar el comando de exploración AzSK "Get-AzSKAzureServicesSecurityStatus" con el indicador '-GenerateFixScript'	Colaborador en suscripción o respectivos RG
Repair-AzSKSubscriptionSecurity	RASS	Soluciona los controles relacionados con la seguridad de la suscripción utilizando los scripts de reparación automatizados generados al ejecutar el comando de escaneo AzSK "Get-AzSKSubscriptionSecurityStatus" con el indicador '-GenerateFixScript'	Colaborador en suscripción
Set-AzSKAlerts	SAA	"Configura alertas de actividad para la suscripción. Las alertas pueden tener un alcance de suscripción o RG. Esto se llama internamente por Set-AzSKSubscriptionSecurity"	Propietario en suscripción
Set-AzSKARMPolicies	SAP	"Configura un conjunto básico de políticas ARM en una suscripción. Esto se llama internamente por Set-AzSKSubscriptionSecurity"	Propietario en suscripción
Set-AzSKAzureSecurityCenterPolicies	SSC	Establece políticas de ASC y puntos de contacto de seguridad.	Lector en suscripción
Set-AzSKOMSSettings	SOS	Configura AzSK para enviar resultados de escaneo al espacio de trabajo de OMS proporcionado	Lector en suscripción
Set-AzSKPolicySettings	SPS	Configura la URL del servidor que utiliza AzSK para descargar controles y configurar JSON. Si no se llama a esto, AzSK se ejecuta en modo 'org-neutral' utilizando una política genérica	Lector en suscripción
Set-AzSKSubscriptionRBAC	SRB	Configura RBAC para una suscripción	Propietario en suscripción
Set-AzSKSubscriptionSecurity	SSS	Comando maestro que toma entradas combinadas e invoca los comandos de configuración individuales para RBAC, política ARM, Alertas y ASC	Propietario en suscripción

Como puedes ver, para beneficiarte de AzSK, necesitas tener los permisos apropiados de Azure (Azure RBAC), dependiendo de tu papel en el ecosistema de DevOps:

• Lector en suscripción o grupos de recursos respectivos (RG)
• Controlador en suscripción o en los respectivos RG
• Propietario en suscripción

Conclusión

En este artículo, centrado en la introducción del Kit de Desarrollo Seguro para Azure (AzSK), describí las capacidades básicas necesarias para comenzar con AzSK. Aprendiste los siguientes aspectos:

• Los principales interesados en AzSK
• La guía de configuración del AzSK
• El AzSK apoyó los tipos de recursos de Azure
• Los comandos soportados por AzSK
• Los principales permisos requeridos por el RBAC de Azure para AzSK

En el próximo artículo, no centraremos en los controles del AzSK y en cómo aprovecharlos para asegurar sus aplicaciones en la nube a lo largo de las etapas de DevOps.

GLOBAL AZURE BOOTCAMP 2019

El 27 de abril del 2019 tuvimos una excelente jornada de #DevSecOps en Microsoft. Los eventos de las comunidades siempre retornan grandes frutos!! Desde DevSecOps AR brindamos la charla "DevSecOps con Azure DevOps" de Luciano Moreira y Christian Ibiri.

En Abril de 2013 se organizó el primer Global Azure Bootcamp en más de 134 localizaciones alrededor del mundo. En Argentina, el evento se realiza desde el año 2014 y reune cada año a más de 80 profesionales de IT junto con los máximos expertos del país sobre la nube de Microsoft para compartir experiencias, conocimiento, hands-on-labs y un día completo conociendo un poco más sobre Cloud Computing.

Introducción a la seguridad de la infraestructura de Microsoft Azure

En este artículo, me centraré en algunos mecanismos utilizados por Microsoft ‍ para asegurar la infraestructura azure . Como para cualquier nube pública ‍, los controles de seguridad ‍ de la infraestructura de la plataforma de la nube son la base de la seguridad en la nube. A pesar de la seguridad global es compartido entre el proveedor de servicios cloud (CSP) y los clientes de servicios de nube (CSC) también llamados inquilinos, CSC se basa totalmente en el CSP para la seguridad de la nube de infraestructura de plataforma.

Amazon Web Services ( AWS ‍) y microsoft azure ‍ lideran el segmento público IaaS / PaaS del mercado mundial de nubes . Desde el comienzo de la primera oferta de servicios IaaS lanzada en 2006 por AWS que se centra en 3 servicios clave (EC2, EBS y S3), AWS sigue siendo el líder dominante en este segmento, pero AWS está siendo desafiado seriamente por Microsoft Azure que comenzó en 2012 y quién está cerrando la brecha en términos de participación de mercado. De acuerdo con el Informe del Estado de la Nube de RightScale 2018 , que se centra en Multi-Cloud Estrategia, AWS continúa liderando, pero Azure crece más rápido que AWS.

En 2018, Azure aumentó su adopción en un 11%, mientras que fue del 7% para AWS, en comparación con 2017.

En nuestra comunidad Peerlyst, ya hay artículos importantes centrados en la seguridad de AWS , gracias a personas como Yogesh Gupta, CISSP®️ CCSK CCSP ‍, Magda CHELLY, CISSP, Ph.D. , Guurhart y muchos otros.

Es por eso que decidí enfocar un par de publicaciones en la seguridad de Microsoft Azure .

Podrá probar sus conocimientos sobre la seguridad de la infraestructura de Azure mediante un cuestionario adjunto al final de esta publicación.

Esta publicación resaltará los siguientes aspectos de la seguridad de la infraestructura de Azure :

• Modelo de responsabilidad compartida en Azure
• Seguridad física de Azure
• Disponibilidad de infraestructura de Azure
• Tipos de usuarios que acceden a los servicios de Azure
• Protección de datos del cliente de Azure

1) Modelo de responsabilidad compartida en Azure


La siguiente imagen muestra las áreas de responsabilidad, de acuerdo con el modelo de servicio en la nube y el tipo de implementación (Software como servicio [SaaS], Plataforma como servicio [PaaS], Infraestructura como servicio [IaaS] y local) .

El cliente (CSC) es responsable de los datos , las cuentas , los puntos finales y la administración de acceso, independientemente del tipo de implementación o modelo de servicio en la nube.

Microsoft (CSP) es responsable de los hosts físicos , la red y el centro de datos en la nube pública.

Las responsabilidades para la infraestructura de identidad y directorio , la aplicación , los controles de red y el sistema operativo varían según el modelo de servicio en la nube. Pueden ser propiedad de CSC, CSP o compartidos por ambos.

Ya proporcioné en mis 3 publicaciones anteriores, algunos consejos y recomendaciones para lidiar con el modelo de responsabilidad compartida en la nube pública. Todos esos detalles son aplicables a Microsoft Azure.

2) Seguridad física de Azure


Al momento de escribir este artículo, la infraestructura global de Azure incluye 54 regiones (en comparación con 19 regiones para AWS) y está disponible en 140 países.

• Una región es un conjunto de centros de datos que están interconectados a través de una red masiva y resistente.
• Las regiones de Azure están organizadas en geografías. Una geografía de Azure garantiza que los requisitos de residencia , soberanía , cumplimiento y resistencia de los datos se cumplan dentro de los límites geográficos .
• Las geografías permiten a los clientes con necesidades específicas de residencia y cumplimiento de datos mantener sus datos y aplicaciones cerca. CSC necesita verificar cuidadosamente cualquier requisito de residencia de datos antes de decidir qué regiones se pueden usar para un caso de uso dedicado. CSC puede restringir las ubicaciones donde se pueden crear recursos utilizando el concepto de la Política de Azure . La Política de Azure es una de las características que le permite a CSC hacer cumplir la gobernanza dentro de Azure. Es un servicio en Azure que CSC usa para crear, asignar y administrar políticas. Estas políticas aplican diferentes reglas y efectos sobre los recursos de CSC, por lo que esos recursos siguen cumpliendo con sus estándares corporativosy acuerdos de nivel de servicio. La representación JSON de la política integrada utilizada para restringir la ubicación de recursos en Azure es la siguiente:

• Una región incluye varias zonas de disponibilidad.
• Las zonas de disponibilidad son ubicaciones físicamente separadas dentro de una región de Azure. Cada zona de disponibilidad está compuesta por uno o más centros de datos equipados con alimentación, refrigeración y redes independientes.
• La siguiente figura muestra cómo la infraestructura global de Azure combina zonas y zonas de disponibilidad dentro del mismo límite de residencia de datos para alta disponibilidad, recuperación ante desastres y respaldo :

La seguridad física de Microsoft Azure incluye:

• Centros de datos administrados con una amplia capa de protección (aprobación de acceso en el perímetro de la instalación, en el perímetro del edificio, en el piso del centro de datos , etc.)
• Revisiones periódicas de seguridad física de las instalaciones, para garantizar que los centros de datos aborden adecuadamente los requisitos de seguridad de Azure (por ejemplo, separación de funciones entre el proveedor de alojamiento del centro de datos y la administración del servicio de Azure)
• Dispositivos de soporte de datos: uso de mejores prácticas y solución de limpieza compatible con NIST-800-88
• Eliminación del equipo al final de la vida útil del sistema.
• Amplio conjunto de estándares de cumplimiento internacionales y específicos de la industria , como ISO 27001 , ISO 27017, ISO 27018, HIPAA , FedRAMP , SOC 1 y SOC 2. La lista completa de los marcos de cumplimiento de Azure se puede encontrar aquí .

3) Disponibilidad de infraestructura de Azure

El equipo de Microsoft Cloud Infrastructure and Operations ( MCIO ) diseña, construye, opera y mejora la seguridad de la infraestructura de la nube.

La disponibilidad de la infraestructura de Azure se basa en:

• Las fuentes de alimentación ininterrumpida y los grandes bancos de baterías aseguran que la electricidad permanezca continua si ocurre una interrupción de energía a corto plazo
• Los generadores de emergencia proporcionan energía de respaldo para interrupciones prolongadas y mantenimiento planificado
• Reservas de combustible en el sitio si ocurre un desastre natural
• Las redes de fibra óptica robustas y de alta velocidad conectan centros de datos con otros centros principales y usuarios de Internet .
• Los nodos informáticos alojan las cargas de trabajo más cercanas a los usuarios para reducir la latencia, proporcionar redundancia geográfica y aumentar la capacidad de recuperación general del servicio
• Un equipo de ingenieros trabaja las 24 horas para garantizar que los servicios estén disponibles de forma permanente.
• Alta disponibilidad a través de monitoreo avanzado y respuesta a incidentes , soporte de servicio y capacidad de respaldo de failover
• Los centros de operaciones de Microsoft distribuidos geográficamente funcionan 24/7/365
• Los datos se mantuvieron duraderos en dos ubicaciones para la recuperación ante desastres (CSC puede elegir la ubicación del sitio de respaldo y Azure mantiene constantemente tres réplicas saludables de sus datos en ambas ubicaciones). Esta estrategia de redundancia de Azure se denomina almacenamiento geo-redundante (GRS).
• Se puede acceder a la base de datos a través de una puerta de enlace de Internet con disponibilidad sostenida de la base de datos.
• Almacenamiento entregado a través de un servicio de almacenamiento altamente escalable y duradero , que proporciona puntos finales de conectividad (es decir, una aplicación puede acceder al servicio de almacenamiento directamente)

4) Tipos de usuarios que acceden a los servicios de Azure

Varios grupos de ingeniería llamados equipos de servicio administran el soporte del servicio de Azure. Cada equipo de servicio es responsable de un área específica. Cada equipo de servicio debe poner a disposición un ingeniero las 24 horas del día, los 7 días de la semana, para investigar y resolver las fallas que puedan ocurrir.


Los tipos de usuarios se resumen en la siguiente tabla:

Role	Tipo de usuario	Nivel de sensibilidad	Privilegios Autorizados	Tipo de acceso
Ingeniero de Azure Datacenter	Interno	Sin acceso a los datos del cliente.	=> Gestionar la seguridad física del local => Propiedad operativa y mantenimiento de herramientas críticas de seguridad	Acceso persistente al medio ambiente.
Ingeniero de respuesta rápida (clasificación de incidentes)	Interno	Acceso a los datos del cliente.	=> Gestionar comunicaciones entre MCIO, soporte y equipos de ingeniería. => Triage incidentes de plataforma, los problemas de implementación, y las solicitudes de servicio	Acceso justo a tiempo al entorno, con acceso limitado y persistente a sistemas que no son clientes.
Ingeniero de implementación de Azure	Interno	Acceso a los datos del cliente.	Implemente y actualice los componentes de la plataforma, el software y los cambios de configuración programados para admitir Azure	Acceso justo a tiempo al entorno, con acceso persistente limitado a sistemas que no son clientes
Soporte de interrupción del cliente de Azure	Interno	Acceso a los datos del cliente.	=> Depurar y diagnosticar interrupciones y fallas de la plataforma para inquilinos informáticos individuales y cuentas de Azure. => Analizar fallas. Impulse soluciones críticas para la plataforma o el cliente e impulse mejoras técnicas en todo el soporte.	Acceso justo a tiempo al entorno, con acceso persistente limitado a sistemas que no son clientes
Ingeniero de sitio en vivo de Azure	Interno	Acceso a los datos del cliente.	=> Diagnosticar y mitigar el estado de la plataforma mediante el uso de herramientas de diagnóstico. => Arreglos de unidades para controladores de volumen , reparar elementos resultantes de interrupciones y ayudar a acciones de restauración de interrupciones	Acceso justo a tiempo al entorno, con acceso persistente limitado a sistemas que no son clientes
Clientes de Azure	Externo	N/A	N/A	N/A

Como pueden ver en la tabla anterior, casi todos los equipos de servicio internos de Azure tienen acceso a los datos de los clientes. Se deben establecer procedimientos y controles de seguridad estrictos para prevenir y protegerse contra los ataques internos (maliciosos o errores).

Por ejemplo, el personal de operaciones de Azure debe utilizar estaciones de trabajo administrativas seguras (SAW). Con las SAW, el personal administrativo utiliza una cuenta administrativa asignada individualmente que es independiente de la cuenta de usuario estándar del usuario. La SAW se basa en esa práctica de separación de cuentas al proporcionar una estación de trabajo fiable para esas cuentas sensibles.

También cabe mencionar que los usuarios internos pueden ser empleados directos de Microsoft o subcontratistas.

5) Protección de datos del cliente azure

Los principios fundamentales que rigen la protección de los datos de los clientes en Azure son los siguientes:

• El acceso a los datos de los clientes por parte de las operaciones de Microsoft y el personal de apoyo se deniega por defecto
• Se requiere la aprobación de los dirigentes antes de conceder el acceso a los datos de los clientes
• No hay cuentas de usuario o de administrador en las máquinas virtuales de los clientes (VM)
• Conceder el menor privilegio que se requiere para completar la tarea
• Auditar y registrar las solicitudes de acceso a los datos de los clientes
• Al personal de apoyo de Azure se le asignan cuentas corporativas únicas de Active Directory por Microsoft
• Azure se basa en el Directorio Activo corporativo de Microsoft, administrado por Microsoft Information Technology (MSIT), para controlar el acceso a los sistemas de información clave
• Se requiere una autenticación multifactorial, y el acceso sólo se concede desde consolas seguras o estaciones de trabajo administrativas seguras (SAW)

Otras características de protección de datos proporcionadas por Azure a los clientes (por defecto o como opción) incluyen:

Segregación de datos: Azure es un servicio multiarrendatario (varios clientes comparten los mismos anfitriones físicos). Azure utiliza el aislamiento lógico para segregar los datos de cada cliente de los datos de los demás.

Protección de datos en reposo: Azure proporciona a los clientes la capacidad de cifrar los datos que almacenan en la plataforma, pero esto no se hace de forma predeterminada. Los clientes son responsables de garantizar que los datos almacenados en Azure se cifren de acuerdo con sus estándares. Azure ofrece una amplia gama de capacidades de cifrado, dando a los clientes la flexibilidad de elegir la solución que mejor se adapte a sus necesidades (Cifrado de disco Azure para cifrar las máquinas virtuales de los clientes, Cifrado de servicio de almacenamiento Azure para cifrar los datos almacenados en las cuentas de almacenamiento de los clientes, etc.). Azure Key Vault ayuda a los clientes a gestionar fácilmente las claves que utilizan las aplicaciones y servicios en la nube para cifrar los datos.

Protección de datos en tránsito: Los clientes pueden habilitar el cifrado para el tráfico entre sus propias máquinas virtuales y los usuarios finales. Azure protege los datos en tránsito hacia o desde componentes externos y los datos en tránsito internamente, como entre dos redes virtuales. Azure utiliza el protocolo de seguridad de capa de transporte (TLS) 1.2 o posterior, estándar de la industria, con claves de cifrado RSA/SHA256 de 2.048 bits.

Redundancia de datos: Microsoft ayuda a garantizar la protección de los datos en caso de ciberataque o daño físico a un centro de datos. Los datos pueden ser replicados dentro de un área geográfica seleccionada para la redundancia. Los clientes tienen múltiples opciones para replicar los datos, incluyendo el número de copias y el número y ubicación de los centros de datos de replicación. Las posibles opciones de replicación incluyen lo siguiente:

• Almacenamiento local redundante (LRS): mantiene tres copias de los datos de los clientes. El LRS se replica tres veces en una sola instalación en una sola región. El LRS protege los datos de los clientes de los fallos normales de hardware, pero no de los fallos de una sola instalación. El SLA para el LRS es de al menos el 99,999999999% (11 veces el número 9).
• Almacenamiento redundante de zona (ZRS): mantiene tres copias de sus datos como en el caso del LRS pero, el ZRS se replica tres veces en dos o tres instalaciones para proporcionar una mayor durabilidad. La replicación se produce dentro de una sola región o a través de dos regiones (los datos de los clientes son duraderos dentro de una sola región). El SLA para el ZRS es de al menos 99,9999999999% (12 veces el número 9).
• Almacenamiento geo-redundante (GRS): El almacenamiento geo-redundante está habilitado para la cuenta de almacenamiento de los clientes de forma predeterminada cuando la crean. El GRS mantiene seis copias de sus datos. Con GRS, los datos de los clientes se replican tres veces dentro de la región primaria. Los datos también se replican tres veces en la región secundaria a cientos de kilómetros de la región primaria, proporcionando el mayor nivel de durabilidad. GRS ayuda a asegurar que los datos de los clientes son duraderos en dos regiones separadas. El SLA para el GRS es de al menos 99,99999999999999% (16 veces el número 9).

Los clientes deben seleccionar cuidadosamente su estrategia de redundancia de almacenamiento durante la creación de la cuenta de almacenamiento, basándose en sus requisitos de disponibilidad así como en las limitaciones de costes.

Destrucción de datos: Microsoft sigue normas estrictas para sobrescribir los recursos de almacenamiento antes de su reutilización (cuando los clientes eliminan los datos o dejan Azure). Microsoft ejecuta una eliminación completa de los datos a petición del cliente y al finalizar el contrato.

Propiedad de los datos del cliente: Microsoft no inspecciona, aprueba o monitorea las aplicaciones que los clientes despliegan en Azure. Microsoft no sabe qué tipo de datos eligen los clientes para almacenar en Azure. Microsoft no reclama la propiedad de los datos sobre la información de los clientes almacenada en Azure.

Descubrimiento electrónico (e-discovery): Los clientes de Azure son responsables de cumplir con los requisitos de e-discovery en su uso de los servicios de Azure. Si un cliente debe cumplir con requisitos específicos de e-discovery, puede considerar la posibilidad de exportar sus datos a un entorno específico. Los clientes pueden solicitar la exportación de sus datos al departamento de atención al cliente de Azure si es necesario.

Los controles de seguridad para la protección de datos de los clientes en Azure dependen del tipo de servicio. Tomemos el ejemplo de Azure SQL Database, que es un componente de Azure PaaS utilizado por la mayoría de los clientes para almacenar sus datos. Las características de seguridad implementadas por Azure incluyen:

• Uso del protocolo TDS: La base de datos Azure SQL sólo admite el protocolo de flujo de datos tabulares (TDS), que requiere que la base de datos sea accesible sólo a través del puerto predeterminado de TCP/1433.
• DoSGuard: Servicio de puerta de enlace de la base de datos SQL utilizado para evitar los ataques de denegación de servicio (DoS). DoSGuard rastrea activamente los inicios de sesión fallidos desde las direcciones IP. Si hay varios inicios de sesión fallidos desde una dirección IP específica dentro de un período, la dirección IP se bloquea para acceder a cualquier recurso del servicio durante un período predefinido
• Cortafuegos de la base de datos Azure SQL: La Base de Datos SQL Azure incluye una funcionalidad de firewall, que por defecto impide todo acceso al servidor de la Base de Datos SQL

El cortafuegos de la puerta de enlace de la base de datos Azure SQL impide de forma predeterminada que todos los clientes de TDS accedan a las instancias de la base de datos Azure SQL. Depende de los clientes decidir qué tipo de acceso debe ser autorizado en cada instancia de la base de datos SQL. Los clientes deben configurar el acceso mediante el uso de listas de control de acceso (ACL) para permitir las conexiones de la base de datos Azure SQL por direcciones de Internet de origen y destino, protocolos y números de puerto.

Resumen

En este artículo, ofrecí una visión general de algunas capacidades clave de seguridad utilizadas por Microsoft para asegurar su infraestructura de la plataforma Azure. Los aspectos destacados en este post incluyen:

• El modelo de responsabilidad compartida en Azure
• La Seguridad Física Azure
• La disponibilidad de la infraestructura azure
• Los tipos de usuarios que acceden a los servicios de Azure
• La protección de datos del cliente azure
• Los aspectos mencionados no son los únicos que deben considerarse en términos de seguridad de la infraestructura del Azure, sino que proporcionan a los clientes una visión general de los mecanismos implementados por el Azure para cumplir con las responsabilidades de seguridad de la infraestructura.

Key references and additional resources

• Azure Global Infrastructure
• Azure Infrastructure Security
• Microsoft Azure Reference Architectures
• RightScale 2018 State of The Cloud Report
• Amazon AWS vs. Microsft Azure in 2018: a quick cloud comparison
• Microsoft Azure Closes IaaS Adoption Gap with Amazon AWS
• Microsoft Azure Compliances

Workshop azure devsecops Microsoft Argentina

Como muchos de mis seguidores en las redes me han solicitado, comparto la presentación del workshop azure devsecops Microsoft Argentina.

Workshop azure devsecops Microsoft Argentina from Luciano Moreira da Cruz

Cómo montar un entorno devops en la nube

¡Hola Legion!  Bienvenido a otro post. Hoy vamos a hablar de cómo montar un entorno DevOps en la nube y qué servicios utilizar.

Si usted no sabe las ventajas de la nube o en duda sobre qué proveedor a contratar, ver nuestro post sobre  qué proveedor de computación en la nube para elegir . Vea cómo Cloud Legion le puede ayudar con los servicios DevOps  https://cloudlegion.com.ar/servicios/hybridit.html .

¿Qué es DevOps?
La palabra DevOps es una unión de otras dos: desarrollo (Dev) y operación (Ops) de software. Con eso, no tenemos una metodología o un marco de trabajo. Pero sí una cultura organizacional donde el desarrollo para una mejor ejecución del software es el foco de todo trabajo.

Primero, todos los involucrados deben estar comprometidos y sentirse responsables por el producto como un todo, y no partes de él. Las características como el código colectivo, la responsabilidad, la búsqueda de la mejora, la optimización, los artefactos secos y la objetividad son fundamentales.

DevOps no se califica por la adopción de una herramienta o implementación de una buena práctica. Sin embargo, son algunas de esas adopciones que hacen que el proceso pueda fluir y entregar los objetivos esperados.

Vamos a ver a continuación lo que es importante para esa cultura en la organización.

Buenas practicas
Ver algunas de las buenas prácticas a adoptar cuando se tiene una cultura DevOps:

• Desarrollo ágil - ágil con el desarrollo de software iterativo e incremental, la entrega de una mayor funcionalidad en menos tiempo;
• Las pruebas - pruebas de unidad, integración y sistema de identificar los problemas a tiempo y reducir los problemas de errores en la ejecución;
• Infraestructura como Código - guiones de infraestructura con todos los requisitos necesarios para la aplicación, la normalización y la normalización del medio ambiente;
• Integración / suministro continuo - repositorios de código para integrar los incrementos desarrollados, pasando el resultado de una serie de validaciones y la disponibilidad del código para ser desplegado en cualquier entorno;
• entornos aislados - entornos de desarrollo, pruebas, aprobación y producción completamente aislado, evitando código no autorizado operan en áreas restringidas;
• La automatización - todo es repetitivo debe ser automatizado, ahorrando tiempo y liberando recursos que pueden ser asignados a otras áreas;
• Gestión de incidentes - Entradas para aprender de los errores siempre, con una mejora en los productos entregados a sus usuarios;
• Monitoreo y métricas - técnicas de recolección y análisis de datos en tiempo real, proporcionando una manera de reaccionar mucho más rápido que el comportamiento no deseado.

La siguiente tabla, el Indmax , muestra una forma interesante de cómo a integrar algunas de estas mejores prácticas

Medio ambiente devops en la nube
Como se dijo anteriormente, DevOps no se restringe al uso de herramientas. Por el contrario, muchas prácticas en el día a día deben ser adoptadas y la cultura adaptada para que se alcance un ambiente DevOps. Pero eso no quiere decir que las herramientas no ayuden en ese proceso.

Para ello, vamos a ver algunas partes del ciclo de vida del software que pueden ser ayudadas por el uso de herramientas en la nube.

Repositorio de código
Actualmente existen varias plataformas proveedor de repositorios de código. GitHub , Bitbucket , gitlab y otros son algunas de las principales plataformas de Git. Pero, ¿por qué Git?

Porque el Git posee una estructura que recibe muy bien los procesos de integración - CI - y entrega - CD - continua. Todas estas plataformas son fáciles de integrar en procesos CI y CD. Además, el modelo de arquitectura descentralizada del versión de código por el Git es algo poderoso, ligero y flexible para equipos de todos los tamaños.

Los mayores proveedores de la nube tienen sus propios servicios para el código de versiones de Git: AWS CodeCommit  o nube Fuente Repo .

Integración continua
El proceso de integración continua implica un análisis constante del código. En este sentido, los códigos versionados y promovidos entornos específicos deben ser compilables y ejecutables.

Pero de nada sirve tener un código compilable y ejecutable presentando varios bugs y drenando la experiencia de los usuarios. En consecuencia, se deben construir pruebas que sean automatizables y puedan garantizar el comportamiento esperado del software.

La integración continua se puede implementar: directamente en las herramientas de Git, los servicios de proveedor de nube ( AWS CodePipeline o AWS CodeBuild ) o programa informático diseñado para este (Jenkins, CI gitlab, TeamCity, Travis CI o bambú).

Entrega continua
La entrega continua es un proceso que extiende y complementa el de integración continua. Con eso, podemos tomar el punto final de la integración, el paquete compilado, probado y listo para ser implantado, e implantarlo.

Esta implementación debe realizarse de manera automatizada, pero no necesariamente se activará automáticamente. Esto depende del proceso interno de la empresa. Este paso final se realizará en un ambiente pre acordado con el usuario, pudiendo ser hasta el de producción.

Normalmente, esta actividad se realiza con ayuda de secuencias de comandos relacionadas con el entorno y el servidor de aplicación de software. Las actualizaciones de entorno y del esquema de base de datos pueden ser necesarias en ese momento.

Algunos servicios en la nube para esto son: AWS CodeDeploy y servicio de aplicaciones .

Desplegar
Uno los principios del DevOps es la continuidad del servicio. En este sentido, es importante que las versiones sean liberadas para los clientes, minimizando los impactos en su usabilidad.

Algunas estrategias utilizadas para realizar el deploy son:


Aplicaciones sin alta disponibilidad (única instancia con el software):

• Único objetivo: sin la reversión del despliegue, la implementación genera tiempo muerto y sin aumento de costo

Aplicaciones con alta disponibilidad (múltiples instancias con el software):

• Todos a la vez: sin la reversión de la implementación, la implementación genera el tiempo de inactividad y sin aumento de costo;
• Mínimo en servicio: deploy puede ser revertido, la implementación no genera downtime y sin aumento de costo. Mantiene el mínimo de servicio necesario para mantener la experiencia del usuario;
• Gradual: Deploy se puede revertir, la implementación no genera downtime y sin aumento de costo. Implanta a un ritmo constante hasta alcanzar todo el ambiente;
• Blue / Green: deploy se puede revertir, la implementación no genera downtime y genera un aumento de costo. Crea un nuevo entorno y conmuta el direccionamiento cuando es funcional. Puede ser probado en paralelo.

De esta manera, sus equipos deben analizar el costo beneficio de cada una y utilizar las herramientas de la manera correcta. Algunos servicios que facilitan la creación de ambientes para desplegar la nube son: Heroku , Elastic Beanstalk , App Engine y servicios en la nube .

Métrica
Por último, toda aplicación disponible debe ser monitoreada y medida. Para que estos datos puedan alimentar el proceso de mejora continua, las aplicaciones deben tener métricas de infraestructura y de usabilidad recogidas y analizadas.

Algunos servicios de infraestructura para las métricas colección son: CloudWatch , Stackdrive y Azure monitor . En cuanto al nivel de usabilidad del software, se pueden utilizar herramientas tales como: ELK ,  Mixpanel , Hotjar y Inspectlet .



¿Te gustó estos consejos sobre cómo montar un entorno de devops en la nube? ¿Tiene otras preguntas al respecto? ¡Deja un comentario!

¿Qué proveedor de cloud computing elegir?

¡Hola Legion! Bienvenido a otro post. Hoy vamos a hablar de la comparación y elegir el mejor proveedor de cloud computing para su escenario.

¿Por qué ir a la nube?
Cuando una empresa decide ir a la nube, ¿cuáles serán los principales puntos considerados por sus decisores? Un informe elaborado por Rightscale mostró que los cuatro primeros puntos están vinculados a hacer más con menos.

Con eso, podemos ver que la ganancia de productividad con bajos costos aparece de manera dominante en relación con los motivos que llevan a las empresas a la nube, además, varios otros datos fueron planteados por el informe. Echa un vistazo a los resultados finales en  http://www.rightscale.com/2018-cloud-report .

En este sentido, otro informe que refuerza el movimiento de la utilización de la nube es liberado por IDP: Nube Mundial de la infraestructura de TI . Podemos ver el aumento del mercado que utiliza cloud, ya sea pública o privada, y con el paso de los años, comparado al mercado de data center tradicional.

CompareCloud
Finalmente, hay un sitio web que muestra a los proveedores de servicio: http://comparecloud.in/ .

Esta página sirve como una guía rápida para analizar las posibilidades y entender cómo cada proveedor entrega el servicio en un determinado nicho. Lo mejor de todo es que está abierto a los cambios a través de GitHub con enlaces a las documentaciones.

Preguntas a realizar
Antes de la toma de decisiones algunas consideraciones son importantes. Con este propósito, intente seguir este checklist y evaluar los puntos de los pros y los contras de cada proveedor para su situación.

1. Centro de datos en regiones geográficas deseables?
Su empresa puede tener restricciones en cuanto a la ubicación geográfica de donde sus datos deben ser almacenados o incluso de donde puedan ser traficados, impidiendo que las rutas salgan del país.

Con el fin de garantizar la alineación con las leyes y las reglas de cumplimiento, su nube de proveedores debe ofrecer regiones donde sus negocios están presentes.

2. Cobro en monedas soportadas?
La mayoría de los proveedores tienen como medio de pago tarjeta de crédito internacional en dólares. Pero existe una salida para quien desea pagar en moneda nacional, en boleto o por una transferencia bancaria: broker.

Broker son empresas que absorben los pagos directos con los proveedores y repasan los valores a los contratistas utilizando medios más fáciles.

3. Latencia aceptable?
Existen sitios expertos en presentar datos sobre la latencia de los centros de datos de los cloud providers. Vea algunos de ellos y analice con sus requisitos:

• AWS - entre usted y los centros de datos:  http://www.cloudping.info/ ;
• AWS - entre los centros de los datos del proveedor: https://www.cloudping.co/ ;
• Azul - entre usted y los centros de datos:  http://www.azurespeed.com/ ;
• GCP - entre usted y los centros de datos: http://www.gcping.com ;

4. Disponibilidad y actualizaciones atienden sus necesidades?
Aunque la construcción de la aplicación debe ser hecha para garantizar el SLA de sus clientes, de nada sirve si la infraestructura de su proveedor no es adecuada. En ese sentido, evalúen si los niveles de SLA prometidos son compatibles con los de sus sistemas.

Salvo problemas catastróficos, un gran proveedor de cloud computing ofrece servicios con disponibilidad por encima del 99,99%. Sin embargo, contractualmente ellos pueden ofrecer menos, sólo para no tener problemas de un eventual incumplimiento.

5. ¿Alcance al encuentro de su mercado?
Cuando evalúe el alcance de su proveedor, no piense sólo en el alcance físico o geográfico, sino en analizar todos los servicios ofrecidos y los que su empresa va a consumir.

Por ejemplo, si el negocio coreano de su empresa es almacenamiento y copia de seguridad, soluciones de Internet de las cosas (IOT), recopilación y análisis de big data o sistemas de inteligencia artificial, los servicios ofrecidos y las facilidades de integración del proveedor deben ser ponderados con mucho cuidado. Estos pueden ser la diferencia entre el éxito y la falla del día a día de su operación.

6. Flexibilidad para desarrollar y entregar soluciones?
Al mismo tiempo que su equipo de desarrollo trabaja y entrega soluciones, un equipo de operaciones necesita poner a disposición, mantener y medir las aplicaciones en producción. Con el fin de garantizar la integración entre estos equipos y la continuidad de sus servicios, los proveedores tienen servicios que permiten la implementación de prácticas DevOps .

De este modo, si su empresa ya es practicante de esa cultura, vale la pena ver cómo los servicios de integración continua (CI) y entrega continua (CD) pueden ser llevados para ser nativamente utilizados en la nube.

7. Facilidades para planes de contingencia, backups y recuperación de desastres?
Independiente de cómo su operación ocurre, sus servicios necesitan esas rutinas. Una vez más, la mayoría de los proveedores pueden tener estrategias que atiendan a esto.

Pero saber cómo implementar en cada proveedor y analizar las facilidades como métricas recogidas, reducción de tiempo muerto, minimización de la pérdida de datos, automatización y costos es muy importante.

8. Poseer las garantías y certificaciones de seguridad necesarias?
El movimiento de ida a nube despierta mucha inseguridad cuando la privacidad y confidencialidad de sus datos. Para ello, los proveedores buscan dar seguridad a sus clientes, obteniendo certificaciones en el área de seguridad y sometiéndose a la auditoría de organismos internacionales.
Para tener una idea siguen las certificaciones de algunos de los principales proveedores:

• AWS compliance
• Azure compliance
• GCP compliance

¿Cuán importante es la elección de un socio?
Antes de migrar se deben evaluar muchas preguntas y muchos puntos a ponderarse. Durante la migración existe una complejidad de diseño de la mejor arquitectura, equilibrando costos, disponibilidad, seguridad y escalabilidad del ambiente. Después del establecimiento del ambiente, se debe implementar un ciclo de análisis y mejora continua. Con él, se deben recoger métricas y generar insumos para mejorar sus sistemas.

Crear un equipo interno capacitado para actuar en esa área puede ser muy caro. Las novedades presentadas por los proveedores son casi diarias y los servicios crecen cada año.

De esta manera, la mejor manera de extraer lo mejor de la nube es contar con un socio certificado y calificado para ayudarle en sus demandas.


¿Te gustó estos consejos? ¿Tiene otras preguntas al respecto? ¡Deja un comentario!

Participa en el Cuestionario del 6o Estudio de Estado de la Seguridad en La Nube

Participa en el Cuestionario del 6o Estudio de Estado de la Seguridad en La Nube ISMS Forum; los Capítulos Español, Peruano, Argentino, Chileno, Boliviano y Brasileño de Cloud Security Alliance; e ISACA Madrid; le invitan a participar en la encuesta para conocer su opinión sobre el estado de aplicación de la seguridad en la Nube, en el marco del Sexto Estudio sobre el Estado de la Seguridad en Cloud Computing que continúa los estudios realizados en 2013, 2014, 2015, 2016 y 2017. El cuestionario está disponible en https://es.surveymonkey.com/r/YNMD6VR Estimamos que su participación al responder el cuestionario no le llevará más de 10 minutos. La encuesta estará disponible para su respuesta hasta el lunes 24 de septiembre de 2018, a las 14:00, y sus resultados serán publicados en el mes de noviembre. En caso de facilitarnos una dirección de correo electrónico junto con sus respuestas, le haremos llegar directamente el informe final del estudio antes de su publicación. El objetivo del estudio es identificar la evolución de la adopción de soluciones y servicios en la Nube, desde una perspectiva centrada en la seguridad de la información, de los datos y de los servicios corporativos, analizando su influencia en la forma en la que se adoptan o no servicios en la Nube. Las respuestas u otra información que nos proporcione no se asociarán con su nombre o el de su organización en ningún informe resultado del presente estudio. Sus respuestas serán usadas únicamente de forma agregada con las respuestas de otros participantes, incorporándose dicho resultado agregado y anonimizado en un informe que se hará público. ¡¡ Muchas gracias por su colaboración!!