‏رمزگذاری فایل State ترافرم: چی رو باید ببندی و کجا

فایل state ترافرم صفت‌ها و متادیتای همهٔ منابع و data sourceهای پیکربندی تو رو نگه می‌داره — و این یعنی پسوردها، رشته‌های اتصال دیتابیس، کلیدهای خصوصی گواهی و چیزهایی از این دست. نویسنده یادآوری می‌کنه ترافرم به‌صورت پیش‌فرض همهٔ این‌ها رو متن ساده ذخیره می‌کنه، پس هر کسی که دسترسی خوندن به اون فایل داشته باشه می‌تونه ببینتشون.

نکتهٔ ظریفی که خیلی‌ها گیر می‌کنن: علامت‌زدن یک متغیر یا خروجی به‌عنوان sensitive فقط جلوی چاپ‌شدنش تو لاگ‌ها رو می‌گیره و هیچ تأثیری روی نحوهٔ ذخیره‌شدنش تو فایل state نداره. حتی داده‌ای که حساس طبقه‌بندی نشده هم چیزیه که ترجیح می‌دی متن ساده پخش نشه، چون state کلی چیز دربارهٔ معماری زیرساختت لو می‌ده.

دو نوع رمزگذاری اینجا مطرحه. در حال انتقال یعنی رمزگذاری فایل موقع جابه‌جایی روی شبکه، مثلاً حین اجرای ترافرم تو پایپ‌لاین CI/CD. در حال سکون یعنی رمزگذاری داده جایی که ذخیره می‌شه، معمولاً بک‌اند state مثل S3 یا Google Cloud Storage.

خبر خوب اینه که اگه از بک‌اند مدیریت‌شده (S3، Azure Storage، GCS) استفاده کنی، رمزگذاری در حال انتقال کاملاً برات مدیریت شده: نه تنظیمی برای فعال‌کردنش هست نه راهی برای خاموش‌کردنش، و هر تعامل با بک‌اند از HTTPS رد می‌شه. رمزگذاری در حال سکون هم همیشه پیش‌فرض روشنه، هرچند می‌تونی تنظیماتش رو عوض کنی — مثلاً S3 رو طوری پیکربندی کنی که از کلید اختصاصی KMS خودت استفاده کنه.

اگه بک‌اند خودمدیریتی داری (Consul، HTTP، Kubernetes، PostgreSQL) خودت مسئولی: باید گواهی‌های TLS رو تنظیم کنی و همهٔ گزینه‌های مربوطه رو فعال کنی. نویسنده تأکید می‌کنه رمزگذاری در حال انتقال باید سرتاسری باشه — حتی داخل شبکهٔ خصوصی خودت هم باید روشن باشه، که همون منطق پشت شبکهٔ zero-trust هست.

مهم‌ترین نکتهٔ مقاله شاید این باشه: ترافرم هیچ پشتیبانی داخلی از رمزگذاری فایل state نداره و کاملاً به رمزگذاری بک‌اند انتخابی‌ت تکیه می‌کنه. اینجاست که OpenTofu متفاوته و رمزگذاری سمت کلاینت داره؛ یعنی state و حتی فایل plan قبل از رسیدن به هر بک‌اندی رمز می‌شن. تنها متد رمزگذاری پشتیبانی‌شده فعلاً AES-GCM هست و چند key provider مختلف داره. پیکربندی‌ش برای یک پروژهٔ تازه این شکلیه:

terraform {
  encryption {
    key_provider "aws_kms" "default" {
      kms_key_id = "e6088080-95d4-4950-95d3-32a08225ee33"
      region     = "eu-north-1"
      key_spec   = "AES_256"
    }
    method "aes_gcm" "default" {
      keys = key_provider.aws_kms.default
    }
    state {
      method = method.aes_gcm.default
    }
  }
}

برای پروژه‌ای که از قبل فایل state رمزنشده داره، باید یک بلاک fallback با متد unencrypted اضافه کنی تا OpenTofu بتونه حین مهاجرت فایل قدیمی رو بخونه؛ بعد از اولین apply می‌شه اون بلاک‌ها رو حذف کرد. نتیجه فایلیه که به‌جای محتوای خوانا، فقط یک فیلد encrypted_data داره.

پنج توصیهٔ پایانی نویسنده هم این‌هان: همیشه هر دو نوع رمزگذاری رو فعال کن؛ دسترسی شبکه به state و کلیدها رو محدود کن و به ترافیک شبکهٔ داخلی هم اعتماد ضمنی نکن؛ اجازهٔ اجرای apply رو با متمرکزکردن عملیات تو پایپ‌لاین محدود کن؛ با ephemeral valueها و اعتبارنامه‌های کوتاه‌عمر اصلاً دادهٔ حساس رو وارد state نکن؛ و در صورت امکان کلید رمزگذاری اختصاصی خودت رو مدیریت کن تا روی نوع الگوریتم، دورهٔ چرخش کلید و سطح دسترسی کنترل داشته باشی.

نکات کلیدی:

• ترافرم state رو متن ساده ذخیره می‌کنه؛ علامت sensitive این رو عوض نمی‌کنه
• بک‌اندهای مدیریت‌شده رمزگذاری در حال انتقال و سکون رو پیش‌فرض دارن
• ترافرم رمزگذاری داخلی نداره؛ OpenTofu رمزگذاری سمت کلاینت با AES-GCM داره
• مهاجرت state رمزنشده به رمزشده با بلاک fallback انجام می‌شه
• بهترین دفاع اینه که دادهٔ حساس اصلاً وارد state نشه