IAM पॉलिसी मूल्यांकन और explicit deny

डेवलपर्स के लिए AWS Security का उपयोग

Rahul Singh

Technical Product Manager

एक पॉलिसी नियमों की सूची होती है

{
  "Effect": "Allow",
  "Action": "s3:GetObject",
  "Resource": "arn:aws:s3:::reports/*",
  "Condition": {
    "Bool": {
      "aws:SecureTransport": "true"
    },
    "IpAddress": {
      "aws:SourceIp": "203.0.113.0/24"
    }
  }
}

एक IAM स्टेटमेंट के तीन फ़ील्ड एक रीढ़ पर ऊपर से नीचे क्रम में, 1 से 3 तक नंबरित: Effect है allow या deny, Action कौन-सा API कॉल है, और Resource वह वस्तु जिस पर यह ARN के द्वारा इंगित करता है.

एक पॉलिसी नियमों की सूची होती है

{
  "Effect": "Allow",
  "Action": "s3:GetObject",
  "Resource": "arn:aws:s3:::reports/*",
  "Condition": {
    "Bool": {
      "aws:SecureTransport": "true"
    },
    "IpAddress": {
      "aws:SourceIp": "203.0.113.0/24"
    }
  }
}

एक IAM स्टेटमेंट के चार फ़ील्ड एक रीढ़ पर ऊपर से नीचे क्रम में, 1 से 4 तक नंबरित: Effect है allow या deny, Action कौन-सा API कॉल है, Resource वह चीज़ है जिस पर यह ARN से इशारा करता है, और Condition वे परिस्थितियाँ जो पूरी होनी चाहिएँ. अंतिम पंक्ति: चार फ़ील्ड, एक नियम.

तीन फ़ील्ड पूछते हैं, एक फ़ील्ड उत्तर देता है

प्रश्न

Action: क्या यही कॉल है
Resource: क्या यही लक्ष्य है
Condition: क्या परिस्थितियाँ मेल खाती हैं

उत्तर

Effect: allow या deny

एक IAM स्टेटमेंट के चार फ़ील्ड ऊर्ध्वाधर: Action, Resource और Condition एक ब्रैकेट में समूहित, लेबल "The question"; और Effect दूसरे ब्रैकेट में, लेबल "The answer".

नियम एक से अधिक जगहों से आते हैं

एक रोल से जुड़ा पॉलिसी डॉक्यूमेंट, रोल से बकेट की ओर जाता हुआ तीर.

आइडेंटिटी-आधारित

रोल से जुड़ी होती है
यह रोल क्या कर सकता है

नियम एक से अधिक जगहों से आते हैं

एक रोल से जुड़ा पॉलिसी डॉक्यूमेंट, रोल से बकेट की ओर जाता हुआ तीर.

एक रिसोर्स से जुड़ा पॉलिसी डॉक्यूमेंट, प्रिंसिपल से बकेट की ओर जाता हुआ तीर.

आइडेंटिटी-आधारित

रोल से जुड़ी होती है
यह रोल क्या कर सकता है

रिसोर्स-आधारित

जिस वस्तु तक पहुँचा जा रहा है, उससे जुड़ी होती है
कौन इस बकेट तक पहुँच सकता है

जब नियम आपस में टकराएँ

{"Effect": "Allow", "Action": "s3:*", "Resource": "*"}
{"Effect": "Deny",  "Action": "s3:DeleteObject", "Resource": "*"}

जब नियम आपस में टकराएँ

{"Effect": "Allow", "Action": "s3:*", "Resource": "*"}
{"Effect": "Deny",  "Action": "s3:DeleteObject", "Resource": "*"}

रिक्वेस्ट: s3:DeleteObject का नतीजा: Denied.

एक explicit deny, कितना भी व्यापक allow हो, उस पर भारी पड़ता है

एक allow और एक deny स्टेटमेंट एक ही रिक्वेस्ट में मिलते हुए, जहाँ deny वाला मार्ग गाढ़ा खींचा है और परिणाम Denied दिखाया गया है.

मूल्यांकन का क्रम, और implicit deny

IAM पॉलिसी मूल्यांकन का फ्लोचार्ट: एक API रिक्वेस्ट पहले लागू explicit deny देखता है, फिर लागू allow, और दोनों न मिलने पर implicit deny तक पहुँचता है.

Explicit deny: किसी ने मना किया
Allow: किसी ने हाँ कहा, और किसी ने ना नहीं कहा
Implicit deny: किसी ने कुछ नहीं कहा

चार रिक्वेस्ट, तीन नतीजे

{"Effect": "Allow", "Action": "s3:*",
 "Resource": "*"}

{"Effect": "Deny", "Action": "s3:DeleteObject",
 "Resource": "*"}

s3:GetObject → allow: व्यापक allow इसे कवर करता है
s3:DeleteObject → explicit deny: एक स्टेटमेंट ने मना किया
kms:Decrypt, dynamodb:GetItem → implicit deny: इस पॉलिसी में ये सर्विसेज़ कही ही नहीं गईं
KMS एन्क्रिप्शन keys रखता है; DynamoDB एक managed key-value डेटाबेस है

क्यों परमिशन जोड़ना अक्सर विफल होता है

एक ही एरर, दो कारण

Explicit deny

और allow जोड़ने से कुछ नहीं बदलता
उस deny को ढूँढ़ें, फिर उसे सीमित करें या हटाएँ

Implicit deny

एक संकीर्ण allow पर्याप्त है
उसी आइडेंटिटी पर जो कॉल कर रही थी

एक AccessDenied एरर दो कारणों में बँटता हुआ. बाएँ: deny मिला, तो और allows से कुछ नहीं बदलता. दाएँ: कोई allow नहीं मिला, तो कॉल करने वाली आइडेंटिटी पर एक संकीर्ण allow से समाधान.

अभ्यास करते हैं!

डेवलपर्स के लिए AWS Security का उपयोग