Sichern Sie Ihre Compute Engine, indem Sie projektweite SSH-Schlüssel sperren

Best Practice für den Umgang mit SSH-Schlüsseln in Google Cloud Wenn Sie Compute Engine in Google Cloud verwenden, fragen Sie sich vielleicht, wie Sie SSH-Schlüssel für Ihre virtuellen Maschinen (VMs) am besten handhaben? Wir haben einige Fragen von unseren Kunden erhalten. Es gibt mehrere Möglichkeiten, SSH-Schlüssel in Ihrer Google Cloud-Umgebung zu implementieren und zu speichern, aber Sie fragen sich vielleicht, wie Sie das am besten machen. In diesem Blog stellen wir Ihnen unsere Best Practices für Compute Engine vor.

Die Risiken von projektweiten SSH-Schlüsseln Die projektweiten SSH-Schlüssel sind zwar praktisch für die Verwaltung des Zugriffs auf mehrere Instanzen, bergen jedoch erhebliche Sicherheitsrisiken. Solche Schlüssel ermöglichen den Zugriff auf jede Compute Engine-Instanz innerhalb eines Projekts und stellen damit eine einzige Schwachstelle dar. Im Falle einer Kompromittierung werden alle Instanzen angreifbar, was das Potenzial für weit verbreitete Sicherheitsverletzungen deutlich erhöht.

Plädoyer für instanzspezifische SSH-Schlüssel Um diese Risiken zu minimieren, empfehlen wir dringend die Verwendung instanzspezifischer SSH-Schlüssel. Dieser Ansatz stellt sicher, dass der Zugriff getrennt erfolgt, wodurch die Auswirkungen eines kompromittierten Schlüssels erheblich reduziert werden. Dies erfordert eine Abkehr von projektweiten SSH-Schlüsseln und eine detailliertere, instanzspezifische Verwaltungsstrategie.

Implementierung erweiterter Sicherheitsmaßnahmen Die Sperrung projektweiter SSH-Schlüssel ist für die Erhöhung der Sicherheit unerlässlich. Die Umsetzung dieser Maßnahme hängt davon ab, wie Sie Ihre Compute Engine-Ressourcen verwalten - sei es über die Google Cloud Console, CI/CD-Pipelines oder Terraform. Wir beschreiben einige Möglichkeiten, wie Sie die Sperrung von SSH-Schlüsseln implementieren können, um sicherzustellen, dass Sie Ihre Umgebung unabhängig von der Art der Bereitstellung Ihrer Cloud-Ressourcen effektiv schützen können.

Wichtigste Erkenntnisse

• Vermeiden Sie projektweite SSH-Schlüssel, um Sicherheitslücken zu vermeiden.
• Verwenden Sie instanzspezifische SSH-Schlüssel für eine bessere Kontrolle und ein geringeres Risiko.
• Passen Sie Ihren Ansatz auf der Grundlage Ihrer spezifischen Google Cloud-Bereitstellungsstrategie an.

Die Anwendung dieser Best Practices kann die Sicherheitslage Ihrer Compute Engine-Instanzen erheblich verbessern und Ihnen helfen, den Explosionsradius in Ihrer Google Cloud-Umgebung zu minimieren, wenn ein SSH-Schlüssel kompromittiert wird.

Im Folgenden beschreiben wir zwei Möglichkeiten, projektweite SSH-Schlüssel in Google Cloud zu sperren

1. Blockieren von projektweiten SSH-Schlüsseln über die Google Cloud Console Navigieren Sie zu Sicherheit -> VM-Zugang -> Projektweite SSH-Schlüssel blockieren

Verwenden Sie Terraform, um projektweite ssh-Schlüssel in Ihren zukünftigen Implementierungen zu verhindern Um zu verhindern, dass projektweite ssh-Schlüssel bei zukünftigen Einsätzen verwendet werden, empfehlen wir Ihnen, den Terraform-Code (siehe Beispiel unten) in Ihre Terraform-Vorlage aufzunehmen, damit Ihre Techniker ihn wiederverwenden können.

2. Projektweite SSH-Schlüssel mit Terraform blockieren Der vollständige Terraform-Code ist verfügbar hier auf Jorges Github-Repository.

resource "google_compute_instance" "awesomename" {
  name                      = var.compute_engine_instance_name
  zone                      = var.gcp_zone_primary
  machine_type              = "e2-highmem-8"
  tags                      = ["http", "https", "ping"]
  project                   = var.gcp_project_id
  can_ip_forward            = false
  allow_stopping_for_update = true

  #Primary local VPC network (NIC0)
  network_interface {
    network    = google_compute_network.vpc_network.id
    network_ip = google_compute_address.private_static_ip.address
    subnetwork = var.local_vpc_awesomename_subnet_name

    access_config {
      nat_ip = google_compute_address.public_static_ip.address
    }
  }

  boot_disk {
    initialize_params {
      image = "debian-12-bookworm-v2024021"
      type  = "pd-ssd"
      size  = "30"
    }
  }

  shielded_instance_config {
    enable_secure_boot          = true
    enable_vtpm                 = true
    enable_integrity_monitoring = true
  }

  #Define API scopes for GCE Service Account.
  service_account {
    email  = google_service_account.awesomename-sa-ce-env.email
    scopes = var.sa-ce-scopes
  }

  metadata = {
    block-project-ssh-keys = true
    enable-os-login        = true
    serial-port-enable     = false
  }
}

Verbessern Sie die Sicherheit in Ihrer CI/CD-Pipeline: Scannen für Compliance Die Integration von Sicherheitsmaßnahmen direkt in Ihre CI/CD-Pipeline ist ein proaktiver Schritt, um sicherzustellen, dass Ihre Infrastruktur als Code (IaC) den Best Practices entspricht. Eine wichtige Maßnahme ist das Scannen Ihres Terraform-Plans, um zu überprüfen, ob der Metadatenwert block-project-ssh-keys ist eingestellt auf trueund verhindert somit die Verwendung von projektweiten SSH-Schlüsseln.

Einsatz von Sicherheitsscannern Tools wie Snyk und tfsec von Aqua Security spielen bei diesem Prozess eine entscheidende Rolle. Diese Scanner lassen sich in Ihre CI/CD-Pipeline integrieren, um alle Pull-Anfragen automatisch auf die Einhaltung der von Ihnen festgelegten Sicherheitsrichtlinien zu überprüfen. Wenn eine Terraform-Konfiguration nicht den erforderlichen Standards entspricht, können diese Tools den Bereitstellungsprozess anhalten und sicherstellen, dass nur sichere Konfigurationen angewendet werden.

Fortgeschrittene Schritte: Einschränkungen der Organisationspolitik implementieren Über das Scannen und Blockieren in der CI/CD-Pipeline hinaus gibt es eine Möglichkeit, Ihre Sicherheitslage weiter zu verbessern. Wenn Sie bereits mit den Organisationsrichtlinieneinschränkungen von Google Cloud vertraut sind, sind Sie gut aufgestellt, um die benutzerdefinierten Organisationsrichtlinieneinschränkungen zu erkunden. Diese ermöglichen eine detailliertere Kontrolle über Ihre Cloud-Ressourcen, so dass Sie bestimmte Sicherheitspraktiken in Ihrem Unternehmen effektiv durchsetzen können.

Zu berücksichtigende Maßnahmen

1. Integrieren Sie Sicherheits-Scan-Tools: Konfigurieren Sie Tools wie Snyk oder tfsec von Aqua Security in Ihrer CI/CD-Pipeline, um automatisch nach nicht konformen Terraform-Konfigurationen zu suchen und entsprechende Warnungen auszusprechen.
2. Überprüfen und aktualisieren Sie Ihre CI/CD-Praktiken: Stellen Sie sicher, dass Ihre Pipeline so eingerichtet ist, dass der block-project-ssh-keys Metadatenwert durchgesetzt wird und Ihre Bereitstellungen von Anfang an gesichert sind.
3. Erkunden Sie Custom Org Policy Constraints: Untersuchen Sie, wie Custom Org Policy Constraints eine zusätzliche Sicherheitsebene bieten können, die eine maßgeschneiderte Kontrolle über Ihre Cloud-Umgebung ermöglicht.

Wenn Sie diese Sicherheitsprüfungen in Ihre CI/CD-Pipeline einbetten und die breitere Anwendung von Organisationsrichtlinieneinschränkungen in Betracht ziehen, können Sie Ihren Schutz vor dem Missbrauch von projektweiten SSH-Schlüsseln erheblich verbessern, was zu einer sichereren Cloud-Infrastruktur führt.

OS Login Die Evaluierung der OS Login-Funktion, insbesondere mit Zwei-Faktor-Authentifizierung (2FA), für Ihre Compute Engine Instanzen könnte von Vorteil sein. Wir planen, in Zukunft einen Blogbeitrag zu veröffentlichen, in dem wir Ihnen zeigen, wie Sie das Beste aus OS Login herausholen können.

Beginnen Sie noch heute mit der Sperrung von projektweiten SSH-Schlüsseln Wenn Sie Fragen zu diesem oder anderen Themen zu Google Cloud haben, können Sie sich gerne an Jorge oder Lars wenden. Wir sind immer bereit, unsere Gedanken und Erfahrungen zu teilen!