Auf dieser Seite wird beschrieben, wie Sie Audit-Logs aus Ihrer Google Distributed Cloud (GDC) Air Gap-Appliance-Umgebung 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 Prüfprotokolle 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 Verlaufsdaten, 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.
Hinweis
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 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 Backups 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
In diesem Abschnitt wird beschrieben, wie Sie ein Backup für Audit-Logs in einem Remote-Bucket erstellen.
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 mit den Logs aus, 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 (IO) 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.
Secret für den Sicherungs-Bucket erstellen:
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 (IO) muss einen Übertragungsjob für Sie erstellen, um Audit-Logs aus dem Sicherungs-Bucket in den Wiederherstellungs-Bucket wiederherzustellen. 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 auf der Benutzeroberfläche der Monitoring-Instanz.
Die Option Audit Logs - Restore ist jetzt als Datenquelle im Log-Explorer verfügbar.