Infrastructure as Code: Terraform ile Güvenli Altyapı Yönetimi

Infrastructure as Code (IaC), altyapının elle tıklanarak değil, versiyon kontrollü kod olarak tanımlanmasını sağlayarak tutarlılık ve tekrarlanabilirlik getirir. Ancak bu güç, yanlış kullanıldığında güvenlik açısından ciddi riskler doğurur; çünkü Terraform gibi araçlar artık yalnızca sunucu değil, IAM rolleri, ağ kuralları ve şifreleme anahtarları gibi güvenliğin doğrudan temelini oluşturan bileşenleri de yönetmektedir.

State Dosyasının Gizli Tehlikesi

Terraform, altyapının mevcut durumunu terraform.tfstate adlı bir dosyada JSON formatında tutar. Bu dosya genellikle fark edilmeyen ama kritik bir gerçeği barındırır: oluşturulan kaynakların bazı özellikleri (örneğin bir RDS veritabanının ilk parolası, bir sertifikanın özel anahtarı) düz metin olarak state içine yazılabilir. Bu dosyanın yerel diskte tutulması veya bir Git deposuna commit edilmesi, ciddi bir sızıntı riskidir.

Doğru Yaklaşım: Remote State ve Kilitleme

terraform {
  backend "s3" {
    bucket         = "sirket-terraform-state"
    key            = "prod/network/terraform.tfstate"
    region         = "eu-central-1"
    encrypt        = true
    dynamodb_table = "terraform-state-lock"
  }
}

Bu yapılandırmada üç kritik önlem birlikte çalışır: encrypt = true state dosyasının depoda şifreli tutulmasını sağlar; dynamodb_table parametresi, aynı anda birden fazla mühendisin aynı altyapıyı eş zamanlı değiştirmesini engelleyen dağıtık bir kilitleme mekanizması kurar (state locking); bucket düzeyinde erişim politikaları da yalnızca CI/CD servis rolüne ve yetkili mühendislere okuma-yazma izni vermelidir. Kilitleme olmadan iki paralel terraform apply çalışması, state dosyasını bozarak altyapının gerçek durumla tutarsız hale gelmesine yol açabilir.

En Az Ayrıcalık: Terraform'un Kendi Kimliği

Terraform'u çalıştıran CI/CD servis hesabının izinleri genellikle ihtiyaçtan çok daha geniş tutulur ("nasıl olsa her şeyi yönetmesi gerekiyor" varsayımıyla). Oysa doğru pratik, her Terraform çalışma alanı (workspace) için ayrı, dar kapsamlı bir IAM rolü tanımlamaktır:

data "aws_iam_policy_document" "terraform_network" {
  statement {
    effect    = "Allow"
    actions   = [
      "ec2:Describe*",
      "ec2:CreateVpc",
      "ec2:CreateSubnet",
      "ec2:CreateSecurityGroup"
    ]
    resources = ["*"]
  }
}

Burada network modülünü çalıştıran role yalnızca ağ kaynaklarıyla ilgili eylemler tanımlanmıştır; aynı role veritabanı veya IAM kullanıcı yönetimi yetkisi verilmemiştir. Bu ayrım, bir CI job'ının ele geçirilmesi durumunda saldırganın hareket alanını (blast radius) sınırlar.

Hassas Değişkenleri Koddan Ayırmak

Parola, API anahtarı gibi değerler .tfvars dosyalarına veya doğrudan HCL koduna asla yazılmamalı; bunun yerine HashiCorp Vault, AWS Secrets Manager gibi bir sır yönetim servisinden çalışma zamanında (runtime) okunmalıdır:

data "aws_secretsmanager_secret_version" "db_password" {
  secret_id = "prod/db/password"
}

resource "aws_db_instance" "main" {
  password = data.aws_secretsmanager_secret_version.db_password.secret_string
}

Kod olarak tanımlanan altyapı, kodun kendisi kadar güvenli olabilir; state dosyası bu kodun çalışan gerçekliğidir ve aynı titizlikle korunmalıdır.

Özetle Terraform ile güvenli altyapı yönetimi; şifreli ve kilitli remote state, dar kapsamlı IAM rolleri ve harici sır yönetimi olmak üzere üç sac ayağı üzerine kuruludur. Bu ayaklardan biri eksik bırakıldığında, IaC'nin getirdiği tekrarlanabilirlik avantajı aynı zamanda hataların da hızla ve tutarlı biçimde çoğalmasına hizmet eder.