Kontenübergreifende gemeinsame Nutzung von Ressourcen
Für dieses Lernprogramm können Kosten anfallen. Mit dem Kostenschätzer können Sie eine Kostenschätzung für Ihre voraussichtliche Nutzung generieren.
Dieses Lernprogramm führt Sie durch verschiedene Optionen zur kontenübergreifenden gemeinsamen Nutzung cloudbasierter Ressourcen.
Eine unzählbare Anzahl von Dienstleistungen werden im Internet angeboten. Sie besitzen wahrscheinlich Konten bei vielen Serviceanbietern. Wenn Sie diese Services verwenden möchten, greifen Sie in der Regel mit einer Kombination aus Benutzeridentität (ID) und Kennwort oder durch Bereitstellung eines API-Schlüssels oder Zugriffstokens zu, häufig kombiniert mit zusätzlichen Authentifizierungsebenen (Faktoren). Bei der Erstellung von Cloud-nativen Anwendungen mit einer auf Mikroservices basierenden Architektur können die einzelnen Komponenten dieselben Verfahren verwenden, um für die Zusammenarbeit aufeinander zuzugreifen. Im Idealfall kann die Konfiguration automatisiert werden und der Zugriff auf ein erforderliches Minimum beschränkt werden, um die Sicherheit zu erhöhen.
Wenn der Fokus auf Cloud-Services liegt, kann dies als Connector, Servicebindung oder Service-zu-Service-Autorisierung bezeichnet werden. Eine solche automatisierte Servicebindung ermöglicht eine engere Integration und kombiniert in der Regel Authentifizierung und Autorisierung in einem einzigen, automatisierten Setup. Normalerweise erfordert die Servicebindung, dass sich die Services in demselben Cloudkonto befinden. Diese Gruppierung ist logisch und vereinfacht Entwicklung und Betrieb. Aber manchmal können organisatorische und insbesondere sicherheits-und compliance-bezogene Anforderungen bedeuten, dass einige Services getrennt und in zentralen Konten verwaltet werden. Daher müssen Anwendungen Ressourcen kontenübergreifend gemeinsam nutzen. Die gemeinsame Nutzung kann zwischen Konten in einer IBM Cloud Unternehmensumgebung oder ohne formale Unternehmensorganisation erfolgen.
Dieses Lernprogramm führt Sie durch typische Anwendungsfälle und Vorteile der kontenübergreifenden gemeinsamen Nutzung von Cloudressourcen. Sie lernen, wie diese Szenarios für gemeinsame Nutzung entweder manuell oder vollständig automatisiert mit Terraform implementiert werden.
Ziele
- Die Vorteile der kontenübergreifenden gemeinsamen Nutzung von Ressourcen verstehen
- Informationen zu verschiedenen Verfahren für die kontenübergreifende gemeinsame Nutzung von Ressourcen
Übersicht über die gemeinsame Ressourcennutzung
Es ist nicht ungewöhnlich, dass mehrere Anwendungen auf dieselbe Ressource oder Teile davon zugreifen und diese verwenden. Ein Beispiel ist, wenn Anwendungen und Rechenumgebungen in demselben Unternehmensnetz leben müssen. Ein weiteres Szenario ist, dass Sicherheitsprotokolle im Hauptspeicher erfasst werden. In einer Mikroservice-Architektur müssen Services für den Zugriff auf und die Verwendung externer Ressourcen konfiguriert werden. Im Gegenzug müssen die gemeinsam genutzten Ressourcen den Zugriff autorisieren, und das Netz zwischen ihnen ist so konfiguriert, dass eine solche Zusammenarbeit unterstützt wird, aber nicht mehr.
Einige typische Anwendungsfälle für die gemeinsame Nutzung von Ressourcen sind:
- Zentrale Verwaltung der sicherheitsrelevanten Infrastruktur. Überwachen Sie die Sicherheit von einem dedizierten Konto aus und aggregieren Sie Sicherheitsprotokolle an einer zentralen Stelle. Verwalten Sie alle Verschlüsselungsschlüssel in zentralen Schlüsselmanagementsystemen (KMS).
- Koordination von Netzadressen und Teilnetzen. Anwendungen und Rechenumgebungen müssen in dasselbe Netz passen und die gemeinsame Nutzung von Adressbereichen und Domänennamen erfordern.
- Zentrale Verwaltung von Ressourcen für Disaster-Recovery, einschließlich Sicherungsservices wie IBM Cloud Backup for Classic. Anwendungen und ihre Services können für hohe Verfügbarkeit konzipiert sein, aber es können zusätzliche zentral organisierte Ressourcen verfügbar sein, auf die im schlimmsten Fall zurückgegriffen werden kann. Dazu gehören auch mehrere Ressourcenkopien, die weltweit verfügbar sind, z. B. gespeichert in replizierten Object Storage-Buckets.
- Steuern Sie die Kosten, indem Sie kostenintensive Services gemeinsam nutzen, sofern dies möglich ist. Nicht in jedem Entwicklungsprojekt müssen alle Services als dedizierte Instanzen implementiert sein. Häufig reicht es aus, Serviceinstanzen gemeinsam zu nutzen-innerhalb von Konten oder übergreifend. Auch in Produktionsumgebungen können Serviceinstanzen je nach Kosten-Nutzen-Faktor und technischer Durchführbarkeit gemeinsam genutzt werden. Dies kann organisiert werden, indem die verfügbaren Services in einem Konto durch die Verwendung privater Kataloge und die Beschränkung des öffentlichen Katalogs eingeschränkt werden und dann Instanzen eingeschränkter Services zentral bereitgestellt werden.
- Zentrale Verwaltung von Ressourcen auf Unternehmensebene oder für einen Unternehmensbereich. Dies können Assets sein, die für Branding oder zentral verwaltete Vorlagen, Basisimages (virtuelle Maschinen, Container) usw. benötigt werden. Auch hier sind private Kataloge und die Container Registry typische Services.
- Stellen Sie knappen Ressourcen mehr Benutzern zur Verfügung. Manchmal ist ein Ressourcentyp nur in begrenzter Menge verfügbar. Durch die gemeinsame Nutzung können mehr Anwendungen davon profitieren. Dies kann eine Ratenbegrenzung erfordern.
Gemeinsame Nutzung von Sicherheitsressourcen
Häufig wird die Sicherheit auf Unternehmensebene mit unternehmensweiten Regeln verwaltet. Daher erfolgt die Durchsetzung auch zentral. Dies gilt auch für Workloads, die in Cloudumgebungen verschoben werden. Die gemeinsame Nutzung von Ressourcen ist die Grundlage für die zentrale Verwaltung der Sicherheit sowie für die Bewertung und Durchsetzung der Compliance.
Das obige Diagramm zeigt die folgenden Szenarios:
- Instanzen von Object Storage und Databases for MongoDB in Konto A und Konto B verwenden Verschlüsselungsschlüssel, die im Hauptkonto in Key Protect.
- Security and Compliance Center im Hauptkonto steuert Ressourcen in allen drei Konten (siehe schwarze Linien oben).
- Instanzen von IBM Cloud Activity Tracker Event Routing in Konto A und Konto B leiten Audit-Protokolle an IBM Cloud Logs im Hauptkonto weiter (siehe blaue Linien oben). Das IBM Cloud Logs ist so konfiguriert, dass die Audit-Protokolle aufbewahrt werden, um den Analyse- und Unternehmensanforderungen zu entsprechen.
Die gemeinsame Nutzung kann zwischen Konten in einer IBM Cloud Enterprise-Umgebung oder ohne formale Unternehmensorganisation erfolgen.
Management von Verschlüsselungsschlüsseln
In fast allen Umgebungen werden Daten verschlüsselt gespeichert. Standardmäßig wird die Verschlüsselung vom Provider verwaltet. Dies bedeutet, dass der Verschlüsselungsschlüssel vom Cloud-Provider bereitgestellt und verwaltet wird. Zur Erhöhung der Sicherheit können Kunden ihre eigenen Schlüssel verwenden, indem sie einen Key Management Service (KMS) verwenden. In IBM Cloudkann sich das KMS entweder in demselben oder in einem anderen Konto wie der Service mit einem Verschlüsselungsschlüssel befinden. Dies ermöglicht die zentrale Verwaltung von Verschlüsselungsschlüsseln für alle Unternehmenskonten. Auf diese Weise ist es möglich, die Nutzung zu überwachen und Verschlüsselungsschlüssel bei Bedarf ungültig zu machen.
Key Protect und Hyper Protect Crypto Services unterstützen dieses Implementierungsmuster. Sie können den Zugriff auf eine gesamte Instanz oder für eine erweiterte Sicherheit auf einzelne Schlüsselringe-eine Sammlung von Schlüsseln konfigurieren. Hyper Protect Crypto Services mit Unified Key Orchestrator ermöglicht Ihnen sogar die Orchestrierung von Verschlüsselungsschlüsseln in Keystores verschiedener Cloud-Provider.
Security and Compliance Center
Die Funktion 'Posture Management' von Security and Compliance Center Es unterstützt Sie bei der Überwachung implementierter Umgebungen im Hinblick auf die Sicherheit und deren Bewertung im Hinblick auf Compliance-Ziele. In einem Unternehmen können Sie Bereiche definieren, um mehrere Konten oder Kontogruppen zu überwachen und zu bewerten, und zwar von einer zentralen Instanz aus.
IBM Cloud Logs
{Die Funktion IBM® Cloud Logs ermöglicht die Verwaltung von Betriebssystemprotokollen, Anwendungsprotokollen, Plattformprotokollen und Audit-Protokollen und bietet Such- und Filterfunktionen. Das IBM® Cloud Logs Routing wird verwendet, um die Plattformprotokolle an eine IBM Cloud Logs oder andere unterstützte Instanzen weiterzuleiten. Konsolidierung für die Analyse in einem größeren Zusammenhang und dadurch bessere (Sicherheits-)Erkenntnisse. Konfigurieren Sie die Persistenz in Ihren eigenen Object Storage Buckets für die langfristige Speicherung. Siehe Logs Routing, in dem Tenants und kontospezifische Ziele beschrieben werden.
IBM Cloud Activity Tracker Event Routing
Alle IBM Cloud Dienste erzeugen Ereignisse für sicherheitsrelevante Aktionen. Durch die Verwendung von IBM Cloud Activity Tracker Event Routing können Sicherheitsaufzeichnungen in einer oder wenigen Instanzen von IBM Cloud Logs zentralisiert und langfristig in Object Storage Buckets gespeichert werden, die Sie verwalten. Durch die Aggregation aller Datensätze an einem Standort können Sicherheitsereignisse einfach korreliert werden und so die Einblicke in Vorfälle verbessern oder sogar eine Früherkennung ermöglichen.
Gemeinsame Nutzung von Netzressourcen
Das Entwerfen und Entwickeln von nativen Cloud-Apps in einem Unternehmenskontext beinhaltet häufig die Koordination von Netzressourcen wie Adressbereichen und Teilnetzen, Domänennamen sowie die Weiterleitung von Datenverkehr. Die verschiedenen Konten und ihre Anwendungen und Rechenumgebungen müssen in das Netz und seine Struktur passen. Dies erfordert die gemeinsame Nutzung von Netzressourcen.
- Der Service Transit Gateway wird verwendet, um VPC-Umgebungen und die klassische Infrastruktur über die drei Konten hinweg zu verbinden.
- Jedes Konto verfügt über eine Instanz von DNS Services zum Verwalten privater Domänennamen. Die Instanzen sind verbunden, um DNS-Zonen gemeinsam zu nutzen.
DNS Services
Sie können DNS Services zum Auflösen privater Adressen (Domänennamen) aus Ressourcen verwenden, die in IBM Cloudimplementiert sind. Die Domänennamen können nicht aus dem öffentlichen Internet aufgelöst werden. Eine DNS-Zone ist eine Sammlung von Domänennamen und besteht aus DNS-Ressourcendatensätzen. DNS-Zonen und ihre Datensätze können von anderen Konten verwendet werden, wodurch verknüpfte Zonen erstellt werden.
Transit Gateway
Der Service Transit Gateway ermöglicht das Einrichten der Konnektivität zwischen IBM Cloud-Umgebungen, einschließlich der klassischen Infrastruktur und Virtual Private Clouds (VPC). Sie können sogar Umgebungen verbinden, die in verschiedenen Konten gehostet werden. Daten, die durch das Transit Gateway fließen, verbleiben im privaten Netz von IBM Cloud und sind nicht im öffentlichen Internet zugänglich.
Gemeinsame Nutzung von Ressourcen implementieren
Wie in der Einführung erwähnt, ist es üblich, auf Services außerhalb des einen (Cloud-) Kontos zuzugreifen. Je nach Integrationsstufe gibt es verschiedene Möglichkeiten, den Servicezugriff zu autorisieren und die Authentifizierung zu implementieren. Diese verfügbaren Optionen werden nachfolgend erläutert.
Authentifizierung mit Kennwörtern oder API-Schlüsseln
Viele Ressourcen ermöglichen die Generierung mehrerer Berechtigungsnachweise. Normalerweise bestehen sie entweder aus einer Kombination aus Benutzeridentität (ID) und Kennwort oder nur aus einem einzigen API-Schlüssel. Häufig ist es möglich, die Gruppe von Berechtigungen für die Berechtigungsnachweise anzugeben, z. B. um Lesezugriff oder Bereich zu ermöglichen, auf den zugegriffen werden kann, geändert oder sogar erstellt und gelöscht werden kann. Die Berechtigungsnachweise werden dann für einen abhängigen Service oder eine abhängige Anwendung importiert oder konfiguriert, um auf diese Ressource zuzugreifen. Auch wenn der Zugriff möglich ist, erfordert die Einrichtung einige (manuelle) Arbeiten und insgesamt sind sie nur lose gekoppelt oder integriert.
Einige Rechenservices in IBM Cloud, einschließlich Code Engine und Kubernetes Service, ermöglichen die automatische Erstellung und Konfiguration von Berechtigungsnachweisen, die sogenannte Servicebindung.
Service-zu-Service-Autorisierung
Ein enger integrierter Ansatz für einen Service, der auf einen anderen Service zugreift, ist die Einrichtung von Service-zu-Service-Autorisierungen(s2s-Autorisierung). Sie erstellen eine Richtlinie von IBM Cloud Identity and Access Management (IAM), die einen Quellenservice für den Zugriff auf einen Zielservice berechtigt. Da die Authentifizierung durch Identifizierung des Quellenservice erfolgt, der Zugriff anfordert, sind keine Berechtigungsnachweise in Form von Kennwörtern oder API-Schlüsseln erforderlich. Sowohl die Authentifizierung als auch die Berechtigung werden aufgrund der erstellten IAM-Richtlinie automatisch verarbeitet.
Kontoübergreifende Berechtigungen
IAM unterstützt das Einrichten von Service-zu-Service-Berechtigungen zwischen einem Quellenservice in einem anderen IBM Cloud-Konto und einem Ziel im aktuellen Konto. Daher ermöglicht sie die kontenübergreifende gemeinsame Nutzung von Ressourcen durch Erstellung einer IAM-Berechtigungsrichtlinie. Solche Richtlinien können auf viele Arten erstellt werden, einschließlich in der Browserkonsole (siehe unten), über die Befehlszeilenschnittstelle oder durch Ausführen von Terraform-Code.
In den folgenden Beispielen wird einer bestimmten Object Storage-Instanz im Quellenkonto die Rolle Leseberechtigter für die identifizierte Key Protect-Instanz im aktuellen Konto erteilt.
Im Folgenden wird der Terraform-Code zum Erstellen einer Ressource mit derselben IAM-Berechtigungsrichtliniedargestellt:
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"
}
Dieselbe Berechtigungsrichtlinie kann über die Befehlszeilenschnittstelle IBM Cloud mit dem Befehl iam service-policy-create erstellt werden:
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
Die Konsole, der Terraform-Provider und die Befehlszeilenschnittstelle verwenden alle die IAM-Richtlinienmanagement-API, um die Richtlinie zu erstellen.
Als nächsten Schritt könnte mit der Berechtigungsrichtlinie ein verschlüsseltes Speicherbucket mit einem Key Protect-Rootschlüssel erstellt werden. Im Folgenden wird der Terraform-Code unter Verwendung der Ressource ibm_cos_bucketgezeigt. Das Attribut key_protect enthält den CRN des Rootschlüssels.
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"
}
Weitere Beispiele finden Sie im GitHub-Repository cross-account-resource-sharing.
Typische Service-zu-Service-Autorisierungen
Eine Abhängigkeit von einem Key Management Service (KMS) wie Key Protect und Hyper Protect Crypto Services ist typisch für cloudbasierte Lösungen. Eine KMS-Instanz enthält die Rootschlüssel für die vom Kunden verwaltete Verschlüsselung. Die meisten Services unterstützen vom Kunden gesteuerte Verschlüsselungsschlüssel. Anstelle von cloud-object-storage (Object Storage) im obigen Beispiel können viele andere Services eine KMS-Instanz verwenden, die von mehreren Konten gemeinsam genutzt wird.
Weitere typische (Ziel-) Services für Service-zu-Service-Autorisierung und Kandidaten für die gemeinsame Nutzung von Ressourcen:
- Object Storage: Mehrere Services erfordern oder können Daten und Protokolldateien in einem Speicherbucket speichern. Dies umfasst die Archivierung von Zugriffsprotokollen und Überwachungsdaten. Andere Services müssen auf Buckets zugreifen, um eine Datenanalyse durchzuführen. Eine weitere Kategorie von Services benötigt Zugriff, um Änderungsbenachrichtigungen zu abonnieren, um die Ausführung von Aktionen auszulösen.
- Event Notifications: Um Informationen zu Ereignissen per Push-Operation an Subskribenten zu übertragen, müssen Serviceinstanzen auf eine Event Notifications-Instanz zugreifen.
- Secrets Manager: Dieser Service speichert und stellt anderen Services IAM-API-Schlüsseln, SSL/TLS-Zertifikaten und anderen geheimen Schlüsseln bereit. Daher müssen die abhängigen (Quellen-) Services auf Secrets Managerzugreifen.
- Cloud Internet Services (CIS): Verwaltet Domänennamen und andere Netzdaten und kann daher beispielsweise für die Zertifikatsprüfung verwendet werden.
- IBM Cloud Logs Routing und IBM Cloud Activity Tracker Event Routing: benötigt Dienstzugriff auf Ziele wie IBM Cloud Logs.
Beachten Sie, dass die obige Liste nicht vollständig ist.
Zusammenfassung
Der Zugriff auf Ressourcen in verschiedenen Konten, sogar die gemeinsame Nutzung von Ressourcen ist gängige Praxis. Es gibt mehrere Anwendungsfälle, in denen Benutzer von der gemeinsamen Nutzung von Ressourcen profitieren. Sie wurden in der Übersicht diskutiert. Eine Kombination aus Benutzeridentität und Kennwort oder ein API-Schlüssel für den Zugriff auf eine Ressource dient häufig als Authentifizierung. Der Zugriff kann auf eine Gruppe von Berechtigungen beschränkt werden, z. B. nur Lesezugriff oder andere eingeschränkte Aktionen. Manchmal können diese Typen von Berechtigungsnachweisen von der zugreifenden Ressource wie einer Anwendung oder einer Rechenumgebung ("Servicebindung") erstellt und verwaltet werden. Eine noch engere Integration, die keine Berechtigungsnachweise erfordert, ist das Konzept der IBM Cloud-Service-zu-Service-Autorisierung. Die zugreifende Ressource (Quelle) und die Ressource (Ziel), auf die zugegriffen wird, werden durch ihre Eigenschaften (Authentifizierung) identifiziert und eine Zugriffsrolle wird zugewiesen (Berechtigung). Eine solche Beziehung kann sogar über Kontogrenzen hinweg hergestellt werden. Dies ermöglicht eine einfache Konfiguration, aber dennoch eine sichere kontenübergreifende gemeinsame Nutzung von Ressourcen.
| Service | Funktionalität |
|---|---|
| Sicherheit und Beobachtbarkeit | |
| Security and Compliance Center | Mehrere Konten oder Kontogruppen in einem Unternehmen scannen |
| IBM Cloud Activity Tracker Event Routing | Leiten Sie Ihre IBM Cloud Activity Tracker Event Routing Ereignisse an ein anderes Konto weiter und konsolidieren Sie Ereignisdaten |
| IBM Cloud Logs Routing | Weiterleitung von Protokollen an Ziele wie IBM Cloud Logs oder Event Streams |
| Key Protect | Verwenden Sie Service-to-Service-Berechtigungen, um Verschlüsselungsschlüssel gemeinsam zu nutzen. Organisieren Sie die Schlüssel in Schlüsselringen, um die Verwaltung und die Sicherheit zu vereinfachen. |
| Hyper Protect Crypto Services | Verwenden Sie Service-to-Service-Berechtigungen, um Verschlüsselungsschlüssel gemeinsam zu nutzen. Organisieren Sie die Schlüssel in Schlüsselringen, um die Verwaltung und die Sicherheit zu vereinfachen. |
| Hyper Protect Crypto Services mit Unified Key Orchestrator | Verbinden Sie Ihre Hyper Protect Crypto Services-Instanz mit Keystores in IBM Cloud und Clouds anderer Anbieter. |
| Secrets Manager | Integrationen für Secrets Manager |
| Netz | |
| Transit Gateway | Kontoübergreifende Verbindung mit Transit Gatewayherstellen |
| DNS Services | DNS-Zonen kontenübergreifend in DNS Services |
| Kontoeinstellungen | |
| Katalog | Beschränken verfügbarer Services in einem Konto durch Verwendung von privaten Katalogen und Beschränken des öffentlichen Katalogs |
| Datenbanken | |
| IBM Cloudant | Kontenübergreifende Datenreplikation |
| Cloud Databases | Sicherungen kontenübergreifend wiederherstellen |
Codebeispiele zum Einrichten der gemeinsamen Nutzung von Ressourcen für einige dieser Services finden Sie im GitHub-Repository cross-account-resource-sharing.