Compartición de recursos entre cuentas
Esta guía de aprendizaje puede incurrir en costes. Utilice Estimador de costes para generar una estimación del coste basada en el uso previsto.
Esta guía de aprendizaje le guía a través de distintas opciones sobre cómo compartir recursos basados en la nube entre cuentas.
Un número incontable de servicios se ofrecen en Internet. Es probable que tenga cuentas en muchos proveedores de servicios. Para utilizar estos servicios, normalmente se accede a ellos con una combinación de identidad de usuario (ID) y contraseña o proporcionando algún tipo de clave de API o señal de acceso, a menudo combinada con niveles adicionales (factores) de autenticación. Al crear aplicaciones nativas en la nube con una arquitectura basada en microservicios, los componentes individuales pueden utilizar las mismas técnicas para acceder entre sí para la colaboración. Lo ideal es que la configuración se pueda automatizar y que el ámbito de acceso sea el mínimo necesario para aumentar la seguridad.
Con un foco en los servicios de nube, puede denominarse conector, enlace de servicio o autorización de servicio a servicio. Este enlace de servicio automatizado proporciona una integración más estrecha y normalmente combina la autenticación y la autorización en una única configuración automatizada. Normalmente, el enlace de servicio requiere que los servicios estén en la misma cuenta de nube. Esa agrupación es lógica y simplifica el desarrollo y el funcionamiento. Pero a veces, los requisitos organizativos, y especialmente los relacionados con la seguridad y el cumplimiento, podrían significar separar algunos servicios y mantenerlos en las cuentas centrales. Por lo tanto, las aplicaciones tienen que compartir recursos entre cuentas. El uso compartido puede ser entre cuentas en un entorno deIBM Cloud Enterprise o sin una organización empresarial formal.
Esta guía de aprendizaje le guía a través de los casos de uso típicos y las ventajas de compartir recursos de nube entre cuentas. Aprenderá a implementar estos escenarios de compartición comunes, ya sea de forma manual o totalmente automatizada con Terraform.
Objetivos
- Comprender las ventajas de compartir recursos entre cuentas
- Conozca las diferentes técnicas para compartir recursos entre cuentas
Visión general del uso compartido de recursos
No es inusual encontrar acceso a varias aplicaciones y utilizar el mismo recurso o partes del mismo. Un ejemplo es cuando las aplicaciones y los entornos de cálculo tienen que vivir en la misma red corporativa. Otro escenario es que los registros de seguridad se recopilan en el almacenamiento central. En una arquitectura de microservicio, requiere que configuremos los servicios para acceder y utilizar recursos externos. A su vez, los recursos compartidos deben autorizar el acceso, y la red entre ellos está configurada para dar soporte a dicha colaboración, pero no más.
Algunos casos de uso típicos de uso compartido de recursos son:
- Gestión central de la infraestructura relacionada con la seguridad. Supervise la seguridad desde una cuenta dedicada y agregue registros de seguridad en un único lugar. Gestionar todas las claves de cifrado en sistemas de gestión de claves centrales (KMS).
- Coordinación de direcciones de red y subredes. Las aplicaciones y los entornos de cálculo deben ajustarse a la misma red y es necesario compartir rangos de direcciones y nombres de dominio.
- Gestión central de recursos para la recuperación tras desastre, incluidos servicios de copia de seguridad como IBM Cloud Backup for Classic. Las aplicaciones y sus servicios pueden estar diseñados para alta disponibilidad, pero es posible que haya recursos adicionales organizados centralmente disponibles para volver al peor de los casos. Esto incluye la retención de varias copias de recursos disponibles en todo el mundo, por ejemplo, almacenadas en grupos de Object Storage replicados.
- Controlar los costes compartiendo servicios más caros siempre que sea posible. No todos los proyectos de desarrollo deben tener todos los servicios desplegados como instancias dedicadas. A menudo, basta con compartir instancias de servicio-dentro de cuentas o entre ellas. Incluso para entornos de producción, las instancias de servicio pueden compartirse en función de su factor de coste/valor y viabilidad técnica. Esto se puede organizar restringiendo los servicios disponibles en una cuenta utilizando catálogos privados y restringiendo el catálogo público y, a continuación, proporcionando de forma centralizada instancias de servicios restringidos.
- Gestión central de recursos a nivel corporativo o para una unidad de negocio. Esto podrían ser activos necesarios para plantillas de marca o gestionadas centralmente, imágenes base (máquinas virtuales, contenedores), etc. De nuevo, los catálogos privados y Container Registry son servicios típicos.
- Haga que los recursos escasos estén disponibles para más usuarios. A veces, un tipo de recurso sólo está disponible en cantidad limitada. Al compartir, más aplicaciones pueden beneficiarse de ello. Esto puede requerir una limitación de velocidad.
Uso compartido de recursos de seguridad
A menudo, la seguridad se gestiona a nivel corporativo con las reglas de toda la empresa. Por lo tanto, la aplicación también se gestiona de forma centralizada. Esto sigue siendo cierto con las cargas de trabajo que se mueven a entornos de nube. El uso compartido de recursos está en la base de la gestión centralizada de la seguridad, así como de la evaluación y aplicación de la conformidad.
El diagrama anterior muestra los siguientes escenarios:
- Las instancias de Object Storage y Databases for MongoDB en la Cuenta A y la Cuenta B utilizan claves de cifrado gestionadas en la Cuenta principal en Key Protect.
- Security and Compliance Center en la Cuenta principal controla los recursos de las tres cuentas (consulte las líneas negras anteriores).
- Las instancias de IBM Cloud Activity Tracker Event Routing en Cuenta A y Cuenta B dirigen los registros de auditoría a IBM Cloud Logs en el Cuenta principal (véanse las líneas azules anteriores). El IBM Cloud Logs está configurado para persistir los registros de auditoría para cumplir con los requisitos de análisis y corporativos.
El uso compartido puede ser entre cuentas de un entorno deIBM Cloud Enterprise o sin una organización empresarial formal.
gestión de clave de cifrado
En casi todos los entornos, los datos se almacenan cifrados. De forma predeterminada, el cifrado está gestionado por el proveedor, lo que significa que el proveedor de nube proporciona y mantiene la clave de cifrado. Para aumentar la seguridad, los clientes pueden utilizar sus propias claves utilizando un servicio de gestión de claves (KMS). En IBM Cloud, el KMS puede estar ubicado en la misma cuenta o en otra que el servicio utilizando una clave de cifrado. Esto permite gestionar de forma centralizada las claves de cifrado para todas las cuentas corporativas. De esta forma, es posible supervisar el uso e invalidar las claves de cifrado cuando sea necesario.
Key Protect y Hyper Protect Crypto Services dan soporte a este patrón de despliegue. Puede configurar el acceso a una instancia completa o, para mejorar la seguridad, a conjuntos de claves-una colección de claves individuales. Hyper Protect Crypto Services con Unified Key Orchestrator incluso le permite orquestar claves de cifrado entre almacenes de claves en distintos proveedores de nube.
Security and Compliance Center
Security and Compliance Center presenta la funcionalidad Posture Management. Ayuda a supervisar los entornos desplegados para la seguridad y evaluarlos en relación con los objetivos de conformidad. En una empresa, puede definir ámbitos para supervisar y evaluar varias cuentas o grupos de cuentas desde una instancia central.
IBM Cloud Logs
IBM® Cloud Logs permite gestionar los registros del sistema operativo, los registros de las aplicaciones, los registros de la plataforma y los registros de auditoría, y ofrece funciones de búsqueda y filtrado. El IBM® Cloud Logs Routing se utiliza para enrutar los registros de la plataforma a una instancia IBM Cloud Logs u otras instancias compatibles. Consolidar para analizar en mayor contexto, mejorando así los conocimientos (de seguridad). Configurar para persistir en su propio Object Storage cubos para el almacenamiento a largo plazo. Ver sobre Enrutamiento de Registros que describe los objetivos específicos de inquilinos y cuentas.
IBM Cloud Activity Tracker Event Routing
Todos los servicios IBM Cloud producen eventos para acciones relacionadas con la seguridad. Utilizando IBM Cloud Activity Tracker Event Routing, los registros de seguridad pueden centralizarse en una o varias instancias de IBM Cloud Logs con almacenamiento a largo plazo en Object Storage buckets que usted gestiona. Al agregar todos los registros en una ubicación, los sucesos de seguridad se pueden correlacionar fácilmente y, por lo tanto, aumentar la información sobre las incidencias o incluso permitir una detección temprana.
Uso compartido de recursos de red
El diseño y desarrollo de apps nativas en la nube en un contexto empresarial a menudo implica la coordinación con respecto a recursos de red como rangos de direcciones y subredes, nombres de dominio y direccionamiento de tráfico. Las distintas cuentas y sus aplicaciones y entornos de cálculo deben encajar en la red y su estructura. Esto requiere compartir los recursos de red.
- El servicio Transit Gateway se utiliza para interconectar entornos de VPC e infraestructura clásica en las tres cuentas.
- Cada cuenta tiene una instancia de DNS Services para gestionar nombres de dominio privado. Las instancias están conectadas para compartir zonas DNS.
DNS Services
Puede utilizar DNS Services para resolver direcciones privadas (nombres de dominio) de recursos desplegados en IBM Cloud. Los nombres de dominio no se pueden resolver desde la Internet pública. Una zona DNS es una colección de nombres de dominio y consta de registros de recursos DNS. Las zonas DNS y sus registros pueden ser utilizados por otras cuentas, estableciendo así zonas enlazadas.
Transit Gateway
El servicio Transit Gateway permite establecer conectividad entre entornos IBM Cloud, incluida la infraestructura clásica y las nubes privadas virtuales (VPC). Incluso puede conectar entornos alojados en distintas cuentas. Los datos que fluyen a través de Transit Gateway permanecen dentro de la red privada IBM Cloud y no se exponen a la Internet pública.
Implementación de la compartición de recursos
Como se indica en la introducción, es una práctica común acceder a servicios fuera de la cuenta de una (nube). En función del nivel de integración, existen diferentes formas de autorizar el acceso al servicio e implementar la autenticación. Las opciones disponibles se describen a continuación.
Autenticación con contraseñas o claves de API
Muchos recursos permiten la generación de varias credenciales. Normalmente, constan de una combinación de identidad de usuario (ID) y contraseña o sólo de una única clave de API. A menudo, es posible especificar el conjunto de privilegios para las credenciales, por ejemplo, para permitir el acceso de sólo lectura o el ámbito de lo que se puede acceder, modificar o incluso crear y suprimir. A continuación, las credenciales se importan o configuran para que un servicio o aplicación dependiente acceda a ese recurso. A pesar de que el acceso es posible, la configuración requiere algún trabajo (manual) y en general sólo están acoplados o integrados de forma flexible.
Dentro de IBM Cloud, algunos servicios de cálculo que incluyen Code Engine y Kubernetes Service permiten la creación y configuración automáticas de credenciales, el denominado enlace de servicio.
Autorización de servicio a servicio
Un enfoque integrado más estricto para un servicio que accede a otro es establecer autorizaciones de servicio a servicio(autorizacións2s). Crea una política de IBM Cloud Identity and Access Management (IAM) que autoriza a un servicio de origen a acceder a un servicio de destino. Puesto que la autenticación se realiza identificando el servicio de origen que solicita acceso, no se necesitan credenciales en forma de contraseñas o claves de API. Tanto la autenticación como la autorización se manejan automáticamente debido a la política de IAM creada.
Autorizaciones entre cuentas
IAM da soporte al establecimiento de autorizaciones de servicio a servicio entre un servicio de origen en otra cuenta de IBM Cloud y un destino en la actual. Por lo tanto, permite compartir recursos entre cuentas creando una política de autorización de IAM. Estas políticas se pueden crear de muchas maneras, incluyendo en la consola del navegador tal como se muestra a continuación, utilizando la CLI o ejecutando el código de Terraform.
En los ejemplos siguientes, a una instancia de Object Storage específica de la cuenta de origen se le otorga el rol de Lector para la instancia de Key Protect identificada en la cuenta actual.
A continuación se muestra el código de Terraform para crear un recurso de con la misma política de autorización de IAM:
resource "ibm_iam_authorization_policy" "cross_account_policy" {
source_service_account = data.ibm_iam_account_settings.account_a_settings.account_id
source_service_name = "cloud-object-storage"
source_resource_instance_id = data.ibm_resource_instance.cos_resource_instance.guid
target_service_name = "kms"
target_resource_instance_id = data.ibm_resource_instance.kms_resource_instance.guid
roles = ["Reader"]
description = "read access on Key Protect in Main Account for Account A"
}
Se puede crear la misma política de autorización utilizando la CLI IBM Cloud con el mandato iam service-policy-create:
ibmcloud iam authorization-policy-create cloud-object-storage kms Reader --source-service-account source_account_id --source-service-instance-id cos_instance_id --target-service-instance-id kms_instance_id
La consola, el proveedor de Terraform y la CLI utilizan la API de gestión de políticas de IAM para crear la política.
Como paso siguiente, con la política de autorización en vigor, se podría crear un grupo de almacenamiento cifrado utilizando una clave raíz Key Protect. A continuación se muestra el código de Terraform que utiliza el recurso ibm_cos_bucket. El atributo key_protect contiene el CRN de la clave raíz.
resource "ibm_cos_bucket" "cos_bucket" {
bucket_name = "cos-bucket"
resource_instance_id = data.ibm_resource_instance.cos_resource_instance.id
region_location = var.region
key_protect = data.ibm_kms_key.central_kms_root_key.id
storage_class = "smart"
}
Puede encontrar más ejemplos en el repositorio GitHub cross-account-resource-sharing.
Autorizaciones típicas de servicio a servicio
Una dependencia de un servicio de gestión de claves (KMS) como Key Protect y Hyper Protect Crypto Services es típica de las soluciones basadas en la nube. Una instancia de KMS contiene las claves raíz para el cifrado gestionado por el cliente. La mayoría de los servicios dan soporte a claves de cifrado controladas por el cliente. En lugar de cloud-object-storage (Object Storage) en el ejemplo anterior, muchos otros servicios pueden utilizar una instancia de KMS compartida entre cuentas.
Otros servicios típicos (de destino) para la autorización de servicio a servicio y candidatos para la compartición de recursos incluyen:
- Object Storage: varios servicios requieren o pueden almacenar datos y archivos de registro en un grupo de almacenamiento. Esto incluye el archivado de registros de acceso y datos de supervisión. Otros servicios necesitan acceder a grupos para realizar el análisis de datos. Sin embargo, otra categoría de servicios necesita acceso para suscribirse a notificaciones de cambio para desencadenar la ejecución de acciones.
- Event Notifications: Para enviar información sobre sucesos a los suscriptores, las instancias de servicio deben acceder a una instancia de Event Notifications.
- Secrets Manager: este servicio almacena y proporciona a otros servicios claves de API de IAM, certificados SSL/TLS y otros secretos. Por lo tanto, los servicios dependientes (origen) deben acceder a Secrets Manager.
- Cloud Internet Services (CIS): gestiona nombres de dominio y otros datos de red y, por lo tanto, se pueden utilizar para, por ejemplo, la validación de certificados.
- IBM Cloud Logs Routing and IBM Cloud Activity Tracker Event Routing: needs service access to targets like IBM Cloud Logs.
Tenga en cuenta que la lista anterior no está completa.
Resumen
Acceder a recursos en diferentes cuentas, incluso compartir recursos es una práctica común. Hay varios casos de uso en los que los usuarios se benefician de la compartición de recursos. Fueron discutidos en la visión general. Una combinación de identidad de usuario y contraseña o una clave de API para acceder a un recurso a menudo sirve como autenticación. El acceso se puede limitar a un conjunto de privilegios, por ejemplo, sólo permite el acceso de lectura o algunas otras acciones restringidas. A veces, este tipo de credenciales puede ser creado y gestionado por el recurso de acceso como una aplicación o un entorno de cálculo ("enlace de servicio"). Una integración aún más estrecha que no requiere credenciales es el concepto de autorización de servicio a servicio de IBM Cloud. El recurso de acceso (origen) y el recurso accedido (destino) se identifican mediante sus propiedades (autenticación) y se asigna un rol de acceso (autorización). Tal relación puede incluso establecerse a través de los límites de la cuenta. Esto permite una configuración sencilla, aunque segura, del uso compartido de recursos entre cuentas.
| Servicio | Prestación |
|---|---|
| Seguridad y observabilidad | |
| Security and Compliance Center | Explorar varias cuentas o grupos de cuentas en una empresa |
| IBM Cloud Activity Tracker Event Routing | Dirija sus eventos IBM Cloud Activity Tracker Event Routing a otra cuenta y consolide los datos de eventos |
| IBM Cloud Logs Routing | Enrutar los registros a un destino como IBM Cloud Logs o Event Streams |
| Key Protect | Utilice autorizaciones de servicio a servicio para compartir claves de cifrado. Organice las claves en conjuntos de claves para una gestión más sencilla y una seguridad mejorada. |
| Hyper Protect Crypto Services | Utilice autorizaciones de servicio a servicio para compartir claves de cifrado. Organice las claves en conjuntos de claves para una gestión más sencilla y una seguridad mejorada. |
| Hyper Protect Crypto Services con Unified Key Orchestrator | Conecte la instancia de Hyper Protect Crypto Services a almacenes de claves en IBM Cloud y nubes de terceros. |
| Secrets Manager | Integraciones para Secrets Manager |
| Red | |
| Transit Gateway | Conectar entre cuentas con Transit Gateway |
| DNS Services | Compartir zonas DNS entre cuentas en DNS Services |
| Configuración de cuenta | |
| Catálogo | Restricción de servicios disponibles en una cuenta utilizando catálogos privados y restringiendo el catálogo público |
| Bases de datos | |
| IBM Cloudant | Réplica de datos entre cuentas |
| Cloud Databases | Restaurar copias de seguridad entre cuentas |
Puede encontrar ejemplos de código sobre cómo configurar el uso compartido de recursos para algunos de estos servicios en el repositorio GitHub cross-account-resource-sharing.