SaaS security के लिए Cloud Policy as Code
Cloud guardrails को tested policy-as-code, चरणबद्ध enforcement, सीमित exceptions और provider-specific controls के साथ लागू करें।
इस मार्गदर्शिका में
Cloud security में Policy as Code का क्या अर्थ है?
Policy as code का अर्थ है security या governance rule को ऐसे format में लिखना जिसे tool लगातार एक ही तरह evaluate कर सके। SaaS team pull request में infrastructure बदलाव जाँच सकती है, cloud organization स्तर पर guardrails लगा सकती है और deployed resources में violation देख सकती है। ये आपस में जुड़े पर अलग controls हैं: Terraform check प्रस्तावित code देखता है, cloud policy service provider resources या requests evaluate करती है, और identity permissions तय करती हैं कि कौन बदलाव कर सकता है।
एक स्पष्ट जोखिम और test होने वाला rule चुनें
Approved regions, चुने storage में encryption, जरूरी owner labels या public admin endpoint पर रोक जैसे requirement से शुरू करें। Resource scope, अपेक्षित परिणाम, गंभीरता और सुरक्षित सुधार लिखें। केवल ‘सब सुरक्षित रखो’ जैसा अस्पष्ट rule न बनाएँ; engineer को पता होना चाहिए कौन-सी property fail हुई और उसे कैसे ठीक करना है।
निर्णय के अनुसार सही enforcement layer चुनें
OPA एक सामान्य policy engine है जो CI/CD, Kubernetes या services में structured input evaluate कर सकता है। Azure Policy resource state देखकर deny, audit या remediation जैसे effects लागू करती है। Google Organization Policy hierarchy के जरिए resources पर constraints लगाती है। AWS SCP member accounts में identities की अधिकतम permissions तय करती है, लेकिन permission grant नहीं करती। Rule को दूसरे provider में ले जाने से पहले उसके व्यवहार को समझें।
Policy को लागू करने वाले tool से अलग version करें
Policy source, tests, owner और approval को reviewed repository में रखें। Reusable policy निर्णय और समझने योग्य कारण दे; अलग control point उसे enforce करे। इससे pull request में प्रस्ताव और बाद में deployed state को जाँचना संभव है, बिना failed check को cloud permission समझे।
| जोखिम और अपेक्षित परिणाम | Resource scope और exceptions | Test cases | शुरुआती effect और owner | Enforcement और review date |
|---|---|---|---|---|
| बिना मंजूरी public storage | ||||
| Service owner label गायब | ||||
| Sensitive data unencrypted |
Cloud policy guardrails सुरक्षित रूप से कैसे लागू करें?
Policy को सही और गलत दोनों examples से test करें
समर्थित resource versions, वैध exceptions, missing values और सीमा-स्थितियों के examples बनाएँ। CI में tests चलाएँ और service owner के साथ false positive तथा छूटे जोखिम देखें। Production का policy engine और schema version pin करें ताकि tool upgrade से evaluation चुपचाप न बदले।
Critical deployment रोकने से पहले audit mode अपनाएँ
देखें कौन-से resources और क्यों deny होते; report सही owner तक भेजें और enforcement से पहले वैध gaps ठीक करें। पहले test folder या account जैसे सीमित scope पर चलाएँ। Provider का व्यवहार अलग है: कुछ create/update के समय और कुछ मौजूदा state को तय अंतराल पर भी evaluate करते हैं।
Exception को सीमित, दर्ज और समयबद्ध रखें
प्रभावित resource या scope, business कारण, compensating control, approver, owner और expiry दर्ज करें। Renewal से पहले समीक्षा करें और भविष्य के violations छिपाने वाला organization-wide exclusion न बनाएँ। AWS SCP में inheritance तथा management-account व्यवहार test करें; दूसरे providers के scope और exemption नियम भी अलग से जाँचें।
Policy as Code को समय के साथ कैसे चलाएँ?
Engineer को सुधार का स्पष्ट संदेश दें
Resource, violated rule, जोखिम, सही state, policy owner और मंजूर exception path दिखाएँ। सुरक्षित हो तो example patch या remediation runbook दें। सटीक error message release के दबाव में wildcard exception लगाने या control बंद करने की संभावना घटाता है।
Policy evaluation और policy बदलाव दोनों monitor करें
Evaluation error, छूटा coverage, assignment में अनपेक्षित बदलाव और guardrail हटाने के प्रयास पर alert दें। देखें कि policy कौन edit कर सकता, scope बदल सकता, exemption मंजूर कर सकता या नया rule deploy कर सकता है। जाँच के लिए policy system और infrastructure के audit logs सुरक्षित रखें।
Provider, platform या service बदलने पर फिर test करें
नया resource type, API version, deployment path या exception rule की visibility बदल सकता है। बड़े cloud बदलाव के बाद review करें और proposed deployment तथा मौजूदा resource, दोनों पर control test करें। Preventative policy के साथ posture monitoring रखें, क्योंकि कोई एक engine हर identity path या application behavior नहीं देखता।
Cloud Policy as Code के सवाल
क्या Policy as Code Terraform security checks की जगह लेती है?
नहीं। Infrastructure code checks deployment से पहले गलती पकड़ सकती हैं, जबकि provider policy और runtime monitoring दूसरे चरणों तथा मौजूदा resources पर नजर रखते हैं। स्पष्ट owner वाले कई layers अपनाएँ; एक scan को deployed cloud की पूरी सुरक्षा का प्रमाण न मानें।
क्या एक ही policy हर cloud provider में बिना बदलाव चलेगी?
आम तौर पर नहीं। सुरक्षा का उद्देश्य समान हो सकता है, लेकिन resource model, policy language, लागू होने का समय, hierarchy और exceptions अलग हैं। Requirement समान रखें, फिर हर platform के लिए provider-specific rule लागू और test करें।
क्या AWS Service Control Policy permission देती है?
नहीं। SCP organization के member accounts में identity की अधिकतम permission तय करती है। Access देने के लिए IAM या resource policy फिर भी चाहिए। SCP ऐसी कार्रवाई रोक भी सकती है जिसके लिए user को अलग policy से permission मिली हो।
क्या हर policy violation पर deployment रोकना चाहिए?
नहीं। जिस उच्च-प्रभाव और भरोसेमंद जोखिम का tested remediation हो, उसे block करें। कम निश्चित rule को पहले audit mode में चलाकर असर मापें, फिर समझ आने पर enforcement करें। Release के अपवाद सीमित, मंजूर और expiry वाले हों।
संबंधित व्यावहारिक मार्गदर्शिकाएँ
संबंधित मुद्दों की मार्गदर्शिकाएँ
स्रोत और प्रकाशन रिकॉर्ड
27 सितंबर 2026 को तैयार मसौदा; engineering, security और संपादकीय समीक्षा बाकी है · स्रोत जाँचे गए .