शर्तें, वाइल्डकार्ड और नीति चर

कार्रवाई और संसाधन के अलावा, IAM नीतियों को सटीक और गतिशील बनाने के लिए शक्तिशाली साधन देता है: शर्तें, वाइल्डकार्ड और नीति चर। इन पर अधिकार पाने से आप बिल्कुल सही परिस्थितियों में आवश्यक पहुँच ही दे सकते हैं, जो न्यूनतम विशेषाधिकार का सार और परीक्षा का बार-बार आने वाला विषय है।

Condition ब्लॉक में एक या अधिक परीक्षण होते हैं, जो कथन के लागू होने के लिए सभी सही होने चाहिए। प्रत्येक परीक्षण में एक ऑपरेटर, एक शर्त कुंजी और एक मान होता है, जैसे aws:PrincipalTag पर StringEquals। एक ब्लॉक में कई कुंजियाँ AND से जोड़ी जाती हैं; एक कुंजी के कई मान OR से जोड़े जाते हैं।

वैश्विक Condition कुंजियाँ परीक्षा में लगातार दिखाई देती हैं:

• aws:SourceIp — कॉल करने वाले की IP सीमा के आधार पर प्रतिबंध लगाएँ।
• aws:SecureTransport — TLS आवश्यक करें।
• aws:MultiFactorAuthPresent — MFA आवश्यक करें।
• aws:PrincipalOrgID — अपनी संस्था तक सीमित करें।

सेवा-विशिष्ट कुंजियाँ (जैसे s3:prefix) और भी सूक्ष्म नियंत्रण प्रदान करती हैं।

एक सामान्य तरीका यह है कि अनुरोध में TLS का उपयोग न होने पर पहुँच अस्वीकार कर दी जाए। यह बकेट-नीति शर्त किसी भी गैर-HTTPS कॉल को रोकती है और सुनिश्चित करती है कि परिवहन के दौरान डेटा हमेशा एन्क्रिप्टेड रहे। परीक्षा में इसे अक्सर "S3 के लिए परिवहन के दौरान एन्क्रिप्शन आवश्यक करें" के उत्तर के रूप में पूछा जाता है।

ऑपरेटर यह निर्धारित करते हैं कि मानों की तुलना कैसे की जाए: StringEquals, StringLike (वाइल्डकार्ड का समर्थन करता है), IpAddress, DateGreaterThan, Bool और Null आदि। किसी ऑपरेटर में IfExists जोड़ने पर कुंजी अनुपस्थित होने पर भी वह सफल माना जाता है। इच्छित तर्क पाने के लिए सही ऑपरेटर चुनना आवश्यक है।

वाइल्डकार्ड (* किसी भी क्रम के लिए, ? एक वर्ण के लिए) नीतियों को संक्षिप्त बनाते हैं, लेकिन आवश्यकता से अधिक अनुमति दे सकते हैं। s3:Get* सभी पढ़ने-जैसी कार्रवाइयों को शामिल करता है; s3:* S3 की हर चीज़ को शामिल करता है। आवश्यकता पूरी करने वाला सबसे सीमित वाइल्डकार्ड उपयोग करें और जिस नीति की समीक्षा कर रहे हों उसमें व्यापक वाइल्डकार्ड से सावधान रहें।

संसाधन ARN भी वाइल्डकार्ड स्वीकार करते हैं, जैसे arn:aws:s3:::logs/2024/* का उपयोग किसी एक उपसर्ग तक दायरा सीमित करने के लिए किया जा सकता है। इससे हर ऑब्जेक्ट की सूची बनाए बिना नीति किसी फ़ोल्डर या पैटर्न को लक्षित कर सकती है। लेकिन केवल "*" का Resource पूरे खाते तक पहुँच प्रदान करता है, इसलिए हमेशा जाँचें कि इतनी व्यापक पहुँच वास्तव में आवश्यक है या नहीं।

नीति चर ${...} सिंटैक्स का उपयोग करके मूल्यांकन के समय अनुरोध का संदर्भ सम्मिलित करते हैं। सबसे उपयोगी चर ${aws:username} है, जिससे एक नीति प्रत्येक उपयोगकर्ता को केवल अपने संसाधनों तक पहुँच दे सकती है। चर एक ही पुनःप्रयोग योग्य नीति को प्रत्येक प्रधान के लिए अलग ढंग से काम करने देते हैं और न्यूनतम विशेषाधिकार को प्रभावी रूप से विस्तृत करते हैं।

यह कथन प्रत्येक उपयोगकर्ता को केवल अपने उपयोगकर्ता नाम वाले फ़ोल्डर के अंतर्गत मौजूद ऑब्जेक्ट प्रबंधित करने देता है। यह सभी के लिए एक नीति वाले प्रभावी पैटर्न का उदाहरण है।

Attribute-Based Access Control (ABAC) शर्तों में टैग का उपयोग करता है और प्रधान के टैग (aws:PrincipalTag) की तुलना संसाधन के टैग (aws:ResourceTag) से करता है। जब वे मेल खाते हैं, तो पहुँच प्रदान की जाती है। ABAC का विस्तार आसानी से किया जा सकता है: हर प्रोजेक्ट के लिए नई नीति लिखने के बजाय टैग के आधार पर पहुँच दें। यह एक आधुनिक सर्वोत्तम अभ्यास है जिस पर परीक्षा में ज़ोर दिया जाता है।

इन साधनों को सोच-समझकर मिलाएँ: MFA, IP, TLS या संस्था की सदस्यता के आधार पर पहुँच नियंत्रित करने के लिए शर्तों का उपयोग करें; वाइल्डकार्ड का सीमित और संकीर्ण उपयोग करें; विस्तार योग्य, प्रति-प्रधान न्यूनतम विशेषाधिकार के लिए नीति चर और टैग उपयोग करें। साथ मिलकर ये एक अच्छी तरह बनाई गई नीति को अनेक पहचानों और संसाधनों पर सटीक, संदर्भ-जागरूक पहुँच लागू करने देते हैं।

शर्तें aws:SourceIp, aws:SecureTransport, aws:MultiFactorAuthPresent और aws:PrincipalOrgID जैसी संदर्भ कुंजियों के आधार पर कथनों को नियंत्रित करती हैं और StringLike तथा Bool जैसे ऑपरेटरों का उपयोग करती हैं। वाइल्डकार्ड (* और ?) नीतियों को संक्षिप्त रखते हैं, लेकिन आवश्यकता से अधिक अनुमति दे सकते हैं। ${aws:username} जैसे नीति चर और टैग-आधारित ABAC विस्तार योग्य, प्रति-प्रधान न्यूनतम विशेषाधिकार प्रदान करते हैं।