SaaS infrastructure के लिए Terraform security checklist
Protected state, secret handling, reviewed plans, trusted modules, सीमित CI access और drift checks से Terraform तथा infrastructure as code सुरक्षित करें।
इस मार्गदर्शिका में
Infrastructure as code security क्या है?
Infrastructure as code (IaC) security में cloud resources के साथ उन्हें बनाने वाले code, credentials, plans, state files और automation की सुरक्षा शामिल है। Terraform इस्तेमाल करने वाली SaaS team को secrets source control से बाहर रखने, production बदलाव review करने, apply अधिकार सीमित करने और deployed resources में drift जाँचने चाहिए। Scanner कुछ जोखिम ढूँढ़ सकता है, लेकिन वह मानवीय समीक्षा या परीक्षण की गई change प्रक्रिया का विकल्प नहीं है।
Terraform state और saved plans को sensitive data मानें
State और plan files में resource विवरण और secret values हो सकती हैं। `terraform.tfstate`, उसकी backup files, saved plans, संवेदनशील variable files या local Terraform directory को commit न करें। ऐसा remote backend चुनें जो access control, encryption, audit records और state locking देता हो; उसकी recovery प्रक्रिया भी जाँचें।
Infrastructure code और secret values अलग रखें
Credentials को `.tf` files, pull requests, command arguments या test fixtures में hard-code न करें। Terraform का `sensitive` marker कुछ output छिपाता है, पर value को state में सहेजे जाने से अपने आप नहीं रोकता। Ephemeral या write-only सुविधा तभी लें जब आपके Terraform और provider version में उपलब्ध हो, और source secret को स्वीकृत secrets system में रखें।
सुरक्षा की सीमा साफ़ तौर पर दर्ज करें
लिखें कि code किन accounts, projects, regions, networks, data stores और production services में बदलाव कर सकता है। स्वीकृत public entry points और exceptions के साथ जोखिम स्वीकार करने वाले owner का नाम भी रखें। स्पष्ट सीमा reviewer को production से पहले public database, बहुत व्यापक role या गलत environment connection पहचानने में मदद करती है।
| बदलाव या workspace | Sensitive values और state | प्रस्तावित access या exposure | Reviewer और test evidence | Apply owner और rollback |
|---|---|---|---|---|
| Production network change | ||||
| नया storage या database | ||||
| CI provider या module update |
Apply से पहले Terraform workflow कैसे सुरक्षित करें?
Protected pull request में source, dependency और plan जाँचें
Formatting और configuration validate करें, provider तथा module source review करें और proposed plan में public exposure, व्यापक privilege, unencrypted storage तथा policy violation ढूँढ़ें। Dependencies को reviewed versions पर pin करें और plan को नियंत्रित access के साथ रखें। Static scan साफ़ आना उपयोगी evidence है, सुरक्षित design का प्रमाण नहीं।
Dedicated और short-lived deployment identity इस्तेमाल करें
Automation identity को उसके environment और deployment role के लिए जरूरी cloud permissions ही दें। Long-lived access keys के बजाय federation या platform की workload identity लें। CI workflow, secrets, runners और approvals सुरक्षित रखें; भरोसेमंद pipeline code बदल पाने वाला हमलावर उसी deployment अधिकार तक पहुँच सकता है।
असरदार production बदलाव के लिए दूसरे व्यक्ति की समीक्षा लें
Reviewer को readable plan, प्रभावित environment, replace या delete होने वाले resources, security exceptions और संभावित ग्राहक असर दिखाएँ। Public exposure, identity boundary या data deletion वाले बदलाव के लिए स्पष्ट approval लें। Apply केवल reviewed plan से करें या यह साबित करें कि लागू हुआ plan स्वीकृत plan से मेल खाता है।
SaaS team Terraform state को कैसे बचाए और drift कैसे पहचाने?
State access उन्हीं लोगों और automation तक सीमित रखें जिन्हें इसकी जरूरत है
State infrastructure संबंध और values उजागर कर सकती है, इसलिए backend credential साझा करने के बजाय workspace और role के अनुसार access दें। Backend encryption और access logs चालू करें, backups सुरक्षित रखें और restore प्रक्रिया जाँचें। किसी को repository से हटाने भर से पुराने state versions या plan artifacts का access नहीं हटता।
Reviewed workflow के बाहर हुए बदलाव पहचानें
Provider configuration history, policy checks या drift review से deployed resources की तुलना स्वीकृत baseline से करें। पता करें बदलाव मंजूर था, emergency fix था, provider default बदला था या untracked resource बना था। Production बदलाव का owner और असर समझे बिना उसे अपने आप overwrite न करें।
Credential leak या unsafe deployment के लिए सुरक्षित प्रतिक्रिया तय रखें
Exposed credential revoke या rotate करें और जाँचें कि state, logs, plans, caches तथा backups में भी value तो नहीं है। Access history देखें। Unsafe बदलाव पर service को स्थिर करें और जरूरी evidence बचाएँ; फिर reviewed change से सुधार करें। घटना का कारण दर्ज कर ऐसा control जोड़ें जो अगली बार यह रास्ता पहले पकड़ सके।
Terraform और infrastructure as code security FAQs
क्या `sensitive = true` secret को Terraform state से बाहर रखता है?
नहीं। HashiCorp के अनुसार यह कुछ output छिपाता है, जबकि value state और plan files में रह सकती है। जहाँ उपलब्ध हो, persistence रोकने वाली supported सुविधा अपनाएँ और backend को sensitive data की तरह सुरक्षित रखें।
क्या IaC scanner अकेले production बदलाव को approve कर सकता है?
नहीं। Scanner patterns और policy violation दिखा सकता है, पर context, provider behavior, runtime exposure और business exceptions छूट सकते हैं। असरदार बदलाव लागू करने से पहले plan, trust boundary, evidence और rollback path review करें।
क्या Terraform lock files commit करनी चाहिए?
`.terraform.lock.hcl` commit करें ताकि चुने गए provider versions और checksums review तथा consistent रहें। State, local working directory और saved plans को version control से बाहर रखें और provider upgrade को code change की तरह जाँचें।
अगर cloud console का बदलाव Terraform drift बनाए तो क्या करें?
किसने और क्यों बदलाव किया, change record और deployment history जाँचें। Emergency बदलाव जो service को सुरक्षित रखता है उसे तुरंत न हटाएँ। Live resource और repository की तुलना करें और सही owner के साथ reviewed प्रक्रिया में code तथा state सुधारें या असर जाँचने के बाद revert करें।
संबंधित व्यावहारिक मार्गदर्शिकाएँ
संबंधित मुद्दों की मार्गदर्शिकाएँ
स्रोत और प्रकाशन रिकॉर्ड
Draft prepared 27 September 2026; engineering, security and editorial review pending · स्रोत जाँचे गए .