Auf dieser Seite wird beschrieben, wie Sie Audit-Logs aus Ihrer Google Distributed Cloud-Appliance-Umgebung (GDC) mit Air Gap in Remote-Sicherungsbuckets sichern, um Daten bei Bedarf zu erhalten und wiederherzustellen. Der Prozess umfasst Schritte zum Installieren und Konfigurieren der erforderlichen Komponenten, um den Verlauf der Audit-Logs aus diesen Back-ups wiederherzustellen.
Sicherungen sorgen dafür, dass Audit-Logs auch dann erhalten bleiben, wenn die Originaldaten verloren gehen oder beschädigt werden. So können Sie Anforderungen erfüllen und Informationen im Falle von Systemausfällen oder versehentlichem Löschen wiederherstellen. Wiederhergestellte Audit-Logs bieten Zugriff auf historische Daten, sodass vergangene Ereignisse, Sicherheitsvorfälle und Nutzeraktivitäten analysiert werden können.
Die Implementierung eines Sicherungs- und Wiederherstellungsprozesses für Audit-Logs ist von Vorteil, um die Datenintegrität aufrechtzuerhalten, die Compliance zu gewährleisten und historische Analysen zu ermöglichen.
Hinweise
Sie benötigen Zugriff auf die folgenden Ressourcen:
- Ein Remote-Bucket für Back-ups mit einem Endpunkt, einem geheimen Zugriffsschlüssel und einer Zugriffsschlüssel-ID.
- Ein Zertifikat der Zertifizierungsstelle (CA) für das Speichersystem.
- Einen funktionierenden Kubernetes-Cluster.
Bitten Sie Ihren Projekt-IAM-Administrator, Ihnen eine der folgenden Rollen in Ihrem Projekt-Namespace zuzuweisen, um die Berechtigungen zu erhalten, die Sie zum Verwalten von Back-ups benötigen:
- Audit Logs Platform Restore Bucket Creator
- Betrachter von Audit-Logs-Plattform-Buckets
Je nach erforderlichem Zugriff und den erforderlichen Berechtigungen können Sie Creator- oder Viewer-Rollen für Sicherungsbucket-Ressourcen in Ihrem Projekt-Namespace erhalten. Weitere Informationen zu diesen Rollen finden Sie unter IAM-Berechtigungen vorbereiten.
Umgebungsvariablen festlegen: Legen Sie die folgenden Umgebungsvariablen fest, um die Befehle auf dieser Seite auszuführen:
* The path of the kubeconfig file:
```sh
export KUBECONFIG=KUBECONFIG_PATH
```
Replace `KUBECONFIG_PATH` with the path to the
kubeconfig file for the Management API server.
* Your project namespace:
```sh
export PROJECT_NAMESPACE=PROJECT_NAMESPACE
```
Audit-Logs in einem Backup sichern
Dieser Abschnitt enthält die Schritte zum Erstellen eines Back-ups für Audit-Logs in einem Remote-Bucket.
Bucket-Anmeldedaten festlegen
Sie müssen die Zugriffsanmeldedaten für die folgenden Buckets festlegen:
- Quell-Bucket: Der lokale GDC-Bucket, der die ursprünglichen Audit-Logs enthält, die Sie schützen möchten.
- Ziel-Bucket: Der Remote-Bucket, in dem Sie das Backup für Audit-Logs erstellen möchten.
Legen Sie die Anmeldedaten für beide Buckets fest:
Quell-Bucket
Listen Sie die Buckets in Ihrem Projekt-Namespace vom Management API-Server auf:
kubectl --kubeconfig=${KUBECONFIG} get bucket -n ${PROJECT_NAMESPACE}Das Feld
DESCRIPTIONin der Ausgabe gibt an, welche Buckets Audit-Logs enthalten. Wählen Sie den Bucket aus, der die Logs enthält, die Sie schützen möchten.Legen Sie anhand der Informationen aus der Ausgabe die folgenden Umgebungsvariablen fest:
SRC_BUCKET= BUCKET_NAME SRC_ENDPOINT = ENDPOINT SRC_PATH= FULLY_QUALIFIED_BUCKET_NAMEErsetzen Sie Folgendes:
BUCKET_NAME: DerBUCKET NAME-Wert der Ausgabe.ENDPOINT: DerENDPOINT-Wert der Ausgabe.FULLY_QUALIFIED_BUCKET_NAME: DerFULLY-QUALIFIED-BUCKET-NAME-Wert der Ausgabe.
Rufen Sie den Namen des Bucket-Secrets ab:
kubectl get secret -n PROJECT_NAMESPACE -o json| jq --arg jq_src $SRC_BUCKET '.items[].metadata|select(.annotations."object.gdc.goog/subject"==$jq_src)|.name'Legen Sie die Variable für die Anmeldedaten fest:
SRC_CREDENTIALS="PROJECT_NAMESPACE/SECRET_NAME"Ersetzen Sie
SECRET_NAMEdurch den Secret-Namen, den Sie erhalten haben.Erstellen Sie das CA-Zertifikat-Secret:
kubectl create secret generic -n PROJECT_NAMESPACE audit-log-loki-ca \ --from-literal=ca.crt=CERTIFICATEErsetzen Sie
CERTIFICATEdurch das CA-Zertifikat des Speichersystems.Legen Sie die Variable für das CA-Zertifikat fest:
SRC_CA_CERTIFICATE=PROJECT_NAMESPACE/audit-log-loki-ca
Ziel-Bucket
Legen Sie die folgenden Umgebungsvariablen für den Remote-Ziel-Bucket fest:
DST_ACCESS_KEY_ID= ACCESS_KEY DST_SECRET_ACCESS_KEY= ACCESS_SECRET DST_ENDPOINT= REMOTE_ENDPOINT DST_PATH= REMOTE_BUCKET_NAMEErsetzen Sie Folgendes:
ACCESS_KEY: Der Zugriffsschlüssel des Buckets.ACCESS_SECRET: Das Zugriffs-Secret des Buckets.REMOTE_ENDPOINT: der Endpunkt des Buckets.REMOTE_BUCKET_NAME: der Name des Buckets.
Remote-Bucket-Secret erstellen:
kubectl create secret generic -n PROJECT_NAMESPACE s3-bucket-credentials \ --from-literal=access-key-id=$DST_ACCESS_KEY_ID \ --from-literal=secret-access-key=$DST_SECRET_ACCESS_KEYErsetzen Sie
PROJECT_NAMESPACEdurch den Namespace Ihres Projekts.Legen Sie die Variable für die Anmeldedaten fest:
DST_CREDENTIALS=PROJECT_NAMESPACE/s3-bucket-credentialsErstellen Sie bei Bedarf ein Secret mit dem CA-Zertifikat des Buckets und legen Sie die CA-Zertifikatvariable fest:
kubectl create secret generic -n PROJECT_NAMESPACE s3-bucket-ca \ --from-literal=ca.crt=REMOTE_CERTIFICATEErsetzen Sie
REMOTE_CERTIFICATEdurch das CA-Zertifikat des Ziel-Buckets.Legen Sie die Variable für das CA-Zertifikat fest:
DST_CA_CERTIFICATE=PROJECT_NAMESPACE/s3-bucket-ca
Audit-Logs übertragen
Ihr Infrastrukturbetreiber muss einen Übertragungsjob für Sie erstellen, um Audit-Logs aus dem Quell-Bucket in den Ziel-Bucket für die Sicherung zu exportieren. Bei der IO wird das vorkonfigurierte Dienstkonto audit-log-pa-backup-restore-sa verwendet, um den Übertragungsdienst für vordefinierte Buckets mit Plattform-Audit-Logs zu konfigurieren.
Verwenden Sie den folgenden Job, um Audit-Logs zu übertragen:
apiVersion: batch/v1
kind: Job
metadata:
name: audit-log-transfer-job
namespace: PROJECT_NAMESPACE
spec:
template:
spec:
serviceAccountName: audit-log-pa-backup-restore-sa
containers:
- name: storage-transfer-pod
image: gcr.io/private-cloud-staging/storage-transfer:latest
imagePullPolicy: Always
command:
- /storage-transfer
args:
- '--src_endpoint=$SRC_ENDPOINT
- '--dst_endpoint=$DST_ENDPOINT
- '--src_path=\$SRC_PATH
- '--dst_path=\$DST_PATH
- '--src_credentials=$SRC_CREDENTIALS
- '--dst_credentials=$DST_CREDENTIALS
- '--dst_ca_certificate_reference=$DST_CA_CERTIFICATE # Optional. Based on destination type.
- '--src_ca_certificate_reference=$SRC_CA_CERTIFICATE
- '--src_type=s3'
- '--dst_type=s3'
- '--bandwidth_limit=100M' # Optional of the form '10K', '100M', '1G' bytes per second
restartPolicy: OnFailure # Will restart on failure.
Datenübertragung überwachen: Verwenden Sie dazu den Jobnamen (audit-log-transfer-job) und den Namespace Ihres Projekts.
Der Job wird beendet, wenn alle Daten in den Ziel-Bucket übertragen wurden.
Audit-Logs aus einer Sicherung wiederherstellen
Dieser Abschnitt enthält die Schritte zum Wiederherstellen von Audit-Logs aus einer Sicherung in einem Remote-Bucket.
Bucket für wiederhergestellte Logs erstellen
Erstellen Sie einen Bucket zum Speichern der wiederhergestellten Audit-Logs:
Erstellen Sie den Wiederherstellungs-Bucket:
apiVersion: object.gdc.goog/v1 kind: Bucket metadata: annotations: object.gdc.goog/audit-logs: PA labels: logging.private.gdch.goog/loggingpipeline-name: default name: audit-logs-loki-restore-pa namespace: PROJECT_NAMESPACE spec: bucketPolicy: lockingPolicy: defaultObjectRetentionDays: 1 description: Bucket for storing audit-logs-loki logs restore storageClass: StandardErsetzen Sie
PROJECT_NAMESPACEdurch den Namespace Ihres Projekts.Rufen Sie den Bucket auf:
kubectl get bucket audit-logs-loki-restore-pa -n PROJECT_NAMESPACEDie Erstellung des Buckets kann einige Minuten dauern.
Legen Sie anhand der Informationen aus der Ausgabe die folgenden Umgebungsvariablen fest:
DST_BUCKET= RESTORE_BUCKET_NAME DST_ENDPOINT = RESTORE_ENDPOINT DST_PATH= RESTORE_FULLY_QUALIFIED_BUCKET_NAMEErsetzen Sie Folgendes:
RESTORE_BUCKET_NAME: DerBUCKET NAME-Wert der Ausgabe.RESTORE_ENDPOINT: DerENDPOINT-Wert der Ausgabe.RESTORE_FULLY_QUALIFIED_BUCKET_NAME: DerFULLY-QUALIFIED-BUCKET-NAME-Wert der Ausgabe.
Rufen Sie den Namen des Bucket-Secrets ab:
kubectl get secret -n PROJECT_NAMESPACE -o json| jq --arg jq_src $DST_BUCKET '.items[].metadata|select(.annotations."object.gdc.goog/subject"==$jq_src)|.name'Legen Sie die Variablen für die Anmeldedaten fest:
DST_SECRET_NAME=RESTORE_SECRET_NAME DST_CREDENTIALS="PROJECT_NAMESPACE/RESTORE_SECRET_NAME"Ersetzen Sie
RESTORE_SECRET_NAMEdurch den Secret-Namen, den Sie erhalten haben.Erstellen Sie das CA-Zertifikat-Secret:
kubectl create secret generic -n PROJECT_NAMESPACE audit-log-loki-restore-ca \ --from-literal=ca.crt=CERTIFICATEErsetzen Sie
CERTIFICATEdurch das CA-Zertifikat des Speichersystems.Legen Sie die Variable für das CA-Zertifikat fest:
DST_CA_CERTIFICATE=PROJECT_NAMESPACE/audit-log-loki-restore-ca
Anmeldedaten für Quell-Bucket festlegen
Legen Sie die Anmeldedaten des Buckets fest, der die Sicherung für Audit-Logs enthält:
Legen Sie die folgenden Umgebungsvariablen fest:
SRC_ACCESS_KEY_ID= ACCESS_KEY SRC_SECRET_ACCESS_KEY= ACCESS_SECRET SRC_ENDPOINT= REMOTE_ENDPOINT SRC_PATH= REMOTE_BUCKET_NAMEErsetzen Sie Folgendes:
ACCESS_KEY: Der Zugriffsschlüssel des Sicherungs-Buckets.ACCESS_SECRET: Das Zugriffs-Secret des Sicherungs-Buckets.REMOTE_ENDPOINT: der Endpunkt des Sicherungs-Buckets.REMOTE_BUCKET_NAME: der Name des Sicherungs-Buckets.
Erstellen Sie ein Secret für den Sicherungs-Bucket:
kubectl create secret generic -n PROJECT_NAMESPACE s3-backup-bucket-credentials \ --from-literal=access-key-id=$SRC_ACCESS_KEY_ID \ --from-literal=secret-access-key=$SRC_SECRET_ACCESS_KEYLegen Sie die Variable für die Anmeldedaten fest:
SRC_CREDENTIALS=PROJECT_NAMESPACE/s3-backup-bucket-credentialsErstellen Sie ein Secret mit dem CA-Zertifikat des Buckets:
kubectl create secret generic -n PROJECT_NAMESPACE s3-backup-bucket-ca \ --from-literal=ca.crt=BACKUP_CERTIFICATEErsetzen Sie
BACKUP_CERTIFICATEdurch das CA-Zertifikat des Sicherungs-Buckets.Legen Sie die Variable für das CA-Zertifikat fest:
SRC_CA_CERTIFICATE=PROJECT_NAMESPACE/s3-backup-bucket-ca
Wiederhergestellte Audit-Logs übertragen
Ihr Infrastrukturbetreiber muss einen Übertragungsjob für Sie erstellen, um Audit-Logs aus dem Sicherungs-Bucket in den Wiederherstellungs-Bucket zu übertragen. Bei der IO wird das vorkonfigurierte Dienstkonto audit-log-pa-backup-restore-sa verwendet, um den Übertragungsdienst für vordefinierte Buckets mit Plattform-Audit-Logs zu konfigurieren.
Verwenden Sie den folgenden Job, um Audit-Logs zu übertragen:
apiVersion: batch/v1
kind: Job
metadata:
name: audit-log-restore-job
namespace: PROJECT_NAMESPACE
spec:
template:
spec:
serviceAccountName: audit-log-pa-backup-restore-sa
containers:
- name: storage-transfer-pod
image: gcr.io/private-cloud-staging/storage-transfer:latest
imagePullPolicy: Always
command:
- /storage-transfer
args:
- '--src_endpoint=$SRC_ENDPOINT
- '--dst_endpoint=$DST_ENDPOINT
- '--src_path=\$SRC_PATH
- '--dst_path=\$DST_PATH
- '--src_credentials=$SRC_CREDENTIALS
- '--dst_credentials=$DST_CREDENTIALS
- '--dst_ca_certificate_reference=$DST_CA_CERTIFICATE
- '--src_ca_certificate_reference=$SRC_CA_CERTIFICATE # Optional. Based on destination type
- '--src_type=s3'
- '--dst_type=s3'
- '--bandwidth_limit=100M' # Optional of the form '10K', '100M', '1G' bytes per second
restartPolicy: OnFailure # Will restart on failure.
Datenübertragung überwachen: Verwenden Sie dazu den Jobnamen (audit-log-restore-job) und den Namespace Ihres Projekts.
Der Job wird beendet, wenn alle Daten in den Wiederherstellungs-Bucket übertragen wurden.
Auf wiederhergestellte Logs zugreifen
Stellen Sie eine Loki-Instanz bereit, um mit den bereitgestellten Konfigurations- und Bereitstellungsmanifesten auf die wiederhergestellten Logs zuzugreifen:
Erstellen Sie ein
ConfigMap-Objekt für die Konfiguration der Instanz.Das folgende Beispiel zeigt ein
ConfigMap-Objekt:apiVersion: v1 kind: ConfigMap metadata: name: audit-logs-loki-restore-pa namespace: PROJECT_NAMESPACE data: loki.yaml: |- auth_enabled: true common: ring: kvstore: store: inmemory chunk_store_config: max_look_back_period: 0s compactor: shared_store: s3 working_directory: /data/loki/boltdb-shipper-compactor compaction_interval: 10m retention_enabled: true retention_delete_delay: 2h retention_delete_worker_count: 150 ingester: chunk_target_size: 1572864 chunk_encoding: snappy max_chunk_age: 2h chunk_idle_period: 90m chunk_retain_period: 30s autoforget_unhealthy: true lifecycler: ring: kvstore: store: inmemory replication_factor: 1 heartbeat_timeout: 10m max_transfer_retries: 0 wal: enabled: true flush_on_shutdown: true dir: /wal checkpoint_duration: 1m replay_memory_ceiling: 20GB limits_config: retention_period: 48h enforce_metric_name: false reject_old_samples: false ingestion_rate_mb: 256 ingestion_burst_size_mb: 256 max_streams_per_user: 20000 max_global_streams_per_user: 20000 per_stream_rate_limit: 256MB per_stream_rate_limit_burst: 256MB shard_streams: enabled: false desired_rate: 3MB schema_config: configs: - from: "2020-10-24" index: period: 24h prefix: index_ object_store: s3 schema: v11 store: boltdb-shipper server: http_listen_port: 3100 grpc_server_max_recv_msg_size: 104857600 grpc_server_max_send_msg_size: 104857600 analytics: reporting_enabled: false storage_config: boltdb_shipper: active_index_directory: /data/loki/boltdb-shipper-active cache_location: /data/loki/boltdb-shipper-cache cache_ttl: 24h shared_store: s3 aws: endpoint: $DST_ENDPOINT bucketnames: $DST_PATH access_key_id: ${S3_ACCESS_KEY_ID} secret_access_key: ${S3_SECRET_ACCESS_KEY} s3forcepathstyle: trueStellen Sie die Instanz als
StatefulSet-Objekt mit einemServicefür den Zugriff auf Protokolle bereit.Im Folgenden finden Sie ein Beispiel für
StatefulSet- undService-Objekte:apiVersion: apps/v1 kind: StatefulSet metadata: labels: app: audit-logs-loki-restore-pa logging.private.gdch.goog/loggingpipeline-name: default name: audit-logs-loki-restore-pa namespace: PROJECT_NAMESPACE spec: persistentVolumeClaimRetentionPolicy: whenDeleted: Retain whenScaled: Retain podManagementPolicy: OrderedReady replicas: 1 revisionHistoryLimit: 10 selector: matchLabels: app: audit-logs-loki-restore-pa serviceName: audit-logs-loki-restore-pa template: metadata: labels: app: audit-logs-loki-restore-pa app.kubernetes.io/part-of: audit-logs-loki-restore-pa egress.networking.gke.io/enabled: "true" istio.io/rev: default logging.private.gdch.goog/log-type: audit spec: affinity: nodeAffinity: preferredDuringSchedulingIgnoredDuringExecution: - preference: matchExpressions: - key: node-role.kubernetes.io/control-plane operator: DoesNotExist - key: node-role.kubernetes.io/master operator: DoesNotExist weight: 1 podAntiAffinity: preferredDuringSchedulingIgnoredDuringExecution: - podAffinityTerm: labelSelector: matchExpressions: - key: app operator: In values: - audit-logs-loki-restore-pa topologyKey: kubernetes.io/hostname weight: 100 containers: - args: - -config.file=/etc/loki/loki.yaml - -config.expand-env=true - -target=all env: - name: S3_ACCESS_KEY_ID valueFrom: secretKeyRef: key: access-key-id name: $DST_SECRET_NAME optional: false - name: S3_SECRET_ACCESS_KEY valueFrom: secretKeyRef: key: secret-access-key name: $DST_SECRET_NAME optional: false image: gcr.io/private-cloud-staging/loki:v2.8.4-gke.2 imagePullPolicy: Always livenessProbe: failureThreshold: 3 httpGet: path: /ready port: http-metrics scheme: HTTP initialDelaySeconds: 330 periodSeconds: 10 successThreshold: 1 timeoutSeconds: 1 name: audit-logs-loki-restore-pa ports: - containerPort: 3100 name: http-metrics protocol: TCP - containerPort: 7946 name: gossip-ring protocol: TCP readinessProbe: failureThreshold: 3 httpGet: path: /ready port: http-metrics scheme: HTTP initialDelaySeconds: 45 periodSeconds: 10 successThreshold: 1 timeoutSeconds: 1 resources: limits: ephemeral-storage: 2000Mi memory: 8000Mi requests: cpu: 300m ephemeral-storage: 2000Mi memory: 1000Mi securityContext: readOnlyRootFilesystem: true terminationMessagePath: /dev/termination-log terminationMessagePolicy: File volumeMounts: - mountPath: /etc/loki name: config - mountPath: /data name: loki-storage - mountPath: /tmp name: temp - mountPath: /tmp/loki/rules-temp name: tmprulepath - mountPath: /etc/ssl/certs/storage-cert.crt name: storage-cert subPath: ca.crt - mountPath: /wal name: loki-storage dnsPolicy: ClusterFirst priorityClassName: audit-logs-loki-priority restartPolicy: Always schedulerName: default-scheduler securityContext: fsGroup: 10001 runAsGroup: 10001 runAsUser: 10001 serviceAccount: audit-log-pa-backup-restore-sa serviceAccountName: audit-log-pa-backup-restore-sa terminationGracePeriodSeconds: 4800 volumes: - emptyDir: {} name: temp - configMap: defaultMode: 420 name: audit-logs-loki-restore-pa name: config - emptyDir: {} name: tmprulepath - name: storage-cert secret: defaultMode: 420 secretName: web-tls updateStrategy: type: RollingUpdate volumeClaimTemplates: - apiVersion: v1 kind: PersistentVolumeClaim metadata: creationTimestamp: null name: loki-storage spec: accessModes: - ReadWriteOnce resources: requests: storage: 50Gi storageClassName: standard-rwo volumeMode: Filesystem --- apiVersion: v1 kind: Service metadata: name: audit-logs-loki-restore-pa namespace: PROJECT_NAMESPACE spec: internalTrafficPolicy: Cluster ipFamilies: - IPv4 ipFamilyPolicy: SingleStack ports: - name: http-metrics port: 3100 protocol: TCP targetPort: http-metrics selector: app: audit-logs-loki-restore-pa sessionAffinity: None type: ClusterIP
Wiederhergestellte Logs ansehen
Konfigurieren Sie Grafana, um die wiederhergestellten Audit-Logs aus der Loki-Instanz aufzurufen:
- Öffnen Sie den Grafana-Endpunkt Ihres Projekts. Weitere Informationen finden Sie unter Logs abfragen und ansehen.
- Klicken Sie im Navigationsmenü der Benutzeroberfläche auf Verwaltung > Datenquellen.
- Klicken Sie auf Neue Datenquelle hinzufügen.
- Wählen Sie auf der Seite Datenquelle hinzufügen die Option Loki aus.
- Geben Sie auf der Seite Einstellungen im Feld Name
Audit Logs - Restoreein. Geben Sie im Abschnitt HTTP den folgenden Wert in das Feld URL ein:
http://audit-logs-loki-restore-pa.PROJECT_NAMESPACE.svc:3100Geben Sie im Abschnitt Benutzerdefinierte HTTP-Header die folgenden Werte in die entsprechenden Felder ein:
- Header:
X-Scope-OrgID - Wert:
infra-obs
- Header:
In Abbildung 1 wird Loki als Option auf der Seite Datenquelle hinzufügen angezeigt.
Abbildung 1. Die Seite Datenquelle hinzufügen in der Benutzeroberfläche der Monitoring-Instanz.
Abbildung 2. Die Seite Einstellungen in der Benutzeroberfläche der Monitoring-Instanz.
Die Option Audit Logs - Restore ist jetzt als Datenquelle im Log-Explorer verfügbar.