Inconvenientes de seguridad

La seguridad proporciona garantías de confidencialidad, integridad y disponibilidad de los datos y sistemas de una organización. Al diseñar un sistema, casi nunca puede poner en peligro los controles de seguridad. Igualmente, al mejorar la seguridad de una arquitectura, puede haber un impacto en la confiabilidad, la eficacia del rendimiento, el costo y la excelencia operativa. En este artículo se describen algunas de estas consideraciones.

Seguridad frente a confiabilidad

Las aplicaciones de confianza son resistentes y de alta disponibilidad. Todos los componentes arquitectónicos son factores para lograr sus requisitos de confiabilidad. La seguridad de la carga de trabajo suele convertirse en muchas capas de la arquitectura, así como las operaciones y los requisitos de tiempo de ejecución de la carga de trabajo; igualmente, pueden tener sus propias implicaciones en la resistencia o la disponibilidad.

Por ejemplo, los proveedores de identidades y los servicios de autorización son dependencias críticas que se deben tener en cuenta. Esto incluye el servicio de identidad (Plataforma de identidad de Microsoft) y las bibliotecas que le permiten facilitar el uso de esos servicios. En algunos puntos de la arquitectura, un error en una capa de identidad es terminal. En otros puntos, la confiabilidad todavía se puede lograr a través de estrategias como el almacenamiento en caché, el uso de los TCL en tokens de acceso y otros. La validación de notificaciones de OAuth2 puede producirse principalmente si está desconectada del proveedor de notificaciones. Sin embargo, no se pueden lograr todos los requisitos de autorización de esa manera. En esas situaciones, la confiabilidad se puede intercambiar en favor de una seguridad completa.

Muchas cargas de trabajo pueden degradar rápidamente la funcionalidad con la pérdida de controles de seguridad críticos. Considere la posibilidad de evaluar cada componente de la arquitectura para detectar esa condición.

Otras consideraciones de seguridad que podrían afectar a la confiabilidad son:

• Certificaciones deficientes o manuales o prácticas de rotación de claves. Si no se llevan a cabo esas tareas, se pueden producir problemas de confiabilidad.
• Entidades de servicio que han expirado. Por ejemplo, una canalización de implementación que usaba una entidad de servicio puede producir un error en una fecha posterior, si la clave de acceso de esa entidad de seguridad ha expirado. El uso de identidades administradas le permite mantener alta la confiabilidad, al tiempo que mantiene los privilegios mínimos en esa identidad.
• La alta disponibilidad se logra a menudo mediante la redundancia (activa o pasiva); asimismo, los controles de seguridad también deben alinearse con el mecanismo de conmutación por error. Por ejemplo, la conmutación por error de una cuenta de almacenamiento a otra mediante la confiabilidad puede afectar la forma en que se administra la sesión de autorización activa del cliente. El uso de la identidad administrada con la integración de Azure AD para obtener acceso al almacenamiento puede dar lugar a una mayor confiabilidad, ya que el cliente no tiene que administrar tokens de SAS al cambiar a la nueva cuenta de almacenamiento.

Optimización de seguridad frente a costos

Aumentar la seguridad de la carga de trabajo casi siempre dará lugar a un mayor costo. Pero existen varias formas para optimizar esos costos.

• Es posible que la seguridad máxima no siempre sea práctica en todos los entornos. Por ello, evalúe los requisitos de seguridad en entornos de preproducción y producción. ¿Necesita servicios como Azure DDoS Protection, Azure Sentinel, HSM dedicados o Azure Defender en la preproducción? ¿Es suficiente simular el bucle interno de los controles de seguridad? Si los recursos no son accesibles públicamente, ¿puede usar algunos controles para ahorrar costos? Elija siempre esas opciones, si, y solo si, el entorno reducido aún cumple con los requisitos comerciales.

• Las características de seguridad prémium también pueden aumentar el costo. Existen áreas en las que puede reducir el costo mediante las características de seguridad nativas. Por ejemplo, evite implementar roles personalizados si puede usar roles integrados.

• Cada control de seguridad tiene la oportunidad de afectar a los flujos de trabajo; asimismo, los flujos de trabajo que implican a personas pueden ser costosos. Un control de seguridad que impide que se haga el trabajo debe evaluarse como necesario o debe ser innecesariamente redundante. El costo total de propiedad (TCO) incluye los costos operativos para desarrolladores, operadores, SecOps de TI y protocolos de seguridad onerosos. Así pues, debe decidir dónde "menos" puede ser "suficiente" para optimizar los costos.

• El costo total de propiedad incluye el tiempo necesario para realizar las tareas. Por ello, la optimización de ese tiempo optimizará el costo. El uso de las características de la plataforma puede reducir el TCO y mejorar la posición de seguridad. En lugar de entrenar a un ingeniero para que revise manualmente los registros y correlacione los patrones de acceso, use la inteligencia en servicios, como Azure Defender o las alertas de Sentinel.

Seguridad frente a la excelencia operativa

La excelencia operativa implica comprender el comportamiento del negocio y la carga de trabajo, así como aplicar las cantidades adecuadas de automatización y observabilidad en esos procesos.

• Administración de versiones

  Su organización es la que debe definir las puertas de calidad (manuales o automatizadas) como parte de sus prácticas de implementación segura. Evalúe si cada puerta es obligatoria u opcional, teniendo en cuenta si es útil crearla, y tenga en cuenta el costo adicional de complejidad (y tiempo) que conlleva esa versión. Agregar controles de seguridad al proceso hace que las comprobaciones sean más valiosas en ese punto del proceso que cualquier ganancia (generalmente simplicidad y tiempo) al no tenerlas en su lugar.

• Directivas de la organización

  Los equipos a menudo pueden beneficiarse de la colaboración y el uso de habilidades multifuncionales en todas las etapas del ciclo de vida de la carga de trabajo, desde el desarrollo hasta la producción. Sin embargo, la directiva de la organización o los problemas normativos pueden impedir este acceso de gran alcance. Considere, cuando sea posible, aislar los sistemas que sí necesitan directivas de acceso reforzadas de los que no. Evite aplicar el modelo "un solo tamaño fijo" a todos los componentes del sistema. Es más fácil optimizar las operaciones en sistemas que permiten un acceso menos regulado. En el caso de los sistemas que exigen acceso regulado, se espera que la complejidad aumente, lo que conduce a un mayor costo.

• Consideraciones sobre compatibilidad

  Las arquitecturas más "útiles" son las que son más transparentes para todos los involucrados y, a menudo, tienen la menor cantidad de controles de seguridad. Agregar controles de seguridad a la arquitectura, como fuentes de telemetría filtradas, registros censurados, restricciones de acceso del sistema en tiempo de ejecución, entre otros, puede afectar a la compatibilidad de una solución. La adición de controles de seguridad a menudo requiere agregar soluciones compensatorias o en peligro para la observabilidad en la plataforma.

Vínculo relacionado

Vuelva al artículo principal: Seguridad