पहचान, संसाधन, और बाउंड्री

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

Rahul Singh

Technical Product Manager

कौन-सी पॉलिसी प्रभारी है?

वह एडिट जो कुछ नहीं बदलता

अध्याय एक: स्पष्ट डिनाई, या कोई अलाउ नहीं
यहाँ: तीसरा कारण

एक रिक्वेस्ट तीन पॉलिसी जाँच की स्टैक से मिलती है, जहाँ निर्णय की जगह प्रश्नचिन्ह है.

कौन-सी पॉलिसी प्रभारी है?

अधिकतम तीन लेयर

कॉलर पर आइडेंटिटी पॉलिसी
संसाधन पर रिसोर्स पॉलिसी
ऊपर बाउंड्री, सिर्फ घटाती है

अपने अकाउंट में, किसी एक का अलाउ काफी है

किसी भी लेयर ने डिनाई किया तो डिनाई

एक रिक्वेस्ट ऊपर से नीचे क्रम में तीन चेक से गुजरती है: आइडेंटिटी पॉलिसी, रिसोर्स पॉलिसी, और परमिशन बाउंड्री, फिर अलाउ रिजल्ट तक पहुँचती है.

पॉलिसी दो जगह रह सकती है

आइडेंटिटी-बेस्ड पॉलिसी

कॉलर पर अटैच्ड
वह आइडेंटिटी क्या कर सकती है
एक पास जो आप पहनते हैं

ऊपर एक रोल में आइडेंटिटी-बेस्ड पॉलिसी है, नीचे उसी रिक्वेस्ट के रिसोर्स पक्ष के लिए जगह है.

पॉलिसी दो जगह रह सकती है

आइडेंटिटी-बेस्ड पॉलिसी

कॉलर पर अटैच्ड
वह आइडेंटिटी क्या कर सकती है
एक पास जो आप पहनते हैं

रिसोर्स-बेस्ड पॉलिसी

संसाधन पर अटैच्ड
कौन उसे एक्सेस कर सकता है
क्रॉस-अकाउंट कॉलर्स के लिए जरूरी

ऊपर एक रोल में आइडेंटिटी-बेस्ड पॉलिसी है और नीचे एक S3 बकेट में रिसोर्स-बेस्ड पॉलिसी, और एक रिक्वेस्ट दोनों के बीच नीचे जाती है.

आपके लिए मैनेज्ड, या आपके द्वारा

आइडेंटिटी-बेस्ड पॉलिसी के दो प्रकार

AWS managed: AWS के स्वामित्व वाली
Customer managed: आपके स्वामित्व वाली

दो स्टैक्ड कार्ड तुलना करते हैं: AWS managed पॉलिसी, AWS के स्वामित्व में और डिफ़ॉल्ट रूप से व्यापक, बनाम customer managed पॉलिसी, आपके स्वामित्व में और टास्क तक सीमित.

आपके लिए मैनेज्ड, या आपके द्वारा

आइडेंटिटी-बेस्ड पॉलिसी के दो प्रकार

AWS managed: AWS के स्वामित्व वाली
Customer managed: आपके स्वामित्व वाली

सुविधा या प्रिसीजन

AWS managed: तेज़ी से बढ़ें
Customer managed: न्यूनतम विशेषाधिकार

बाउंड्री पॉलिसी के ग्रांट पर कैप लगाती है

अकाउंट यह क्यों जोड़ता है

डेवलपर्स रोल बनाते हैं, कोई एस्केलेट नहीं करता

Permissions boundary

पॉलिसी जो देती है, उस पर सीलिंग
Effective: दोनों से अलाउ हो

आइडेंटिटी पॉलिसी से मिली तीन परमिशन एक परमिशन बाउंड्री में जाती हैं जो सिर्फ S3 एक्शन अलाउ करती है; `iam:CreateUser` रुक जाती है और बाकी दो effective परमिशन में जारी रहती हैं.

बाउंड्री पॉलिसी के ग्रांट पर कैप लगाती है

अकाउंट यह क्यों जोड़ता है

डेवलपर्स रोल बनाते हैं, कोई एस्केलेट नहीं करता

Permissions boundary

पॉलिसी जो देती है, उस पर सीलिंग
Effective: दोनों से अलाउ हो

iam:CreateUser से कुछ क्यों नहीं बदला

केवल घटाती है, कभी ग्रांट नहीं करती

बाउंड्री पॉलिसी के ग्रांट पर कैप लगाती है

अकाउंट यह क्यों जोड़ता है

डेवलपर्स रोल बनाते हैं, कोई एסקेलेट नहीं करता

Permissions boundary

पॉलिसी जो देती है, उस पर सीलिंग
Effective: दोनों से अलाउ हो

iam:CreateUser से कुछ क्यों नहीं बदला

केवल घटाती है, कभी ग्रांट नहीं करती

Session policy: एक AssumeRole सेशन

कंडीशन अलाउ को सीमित करती है

कंडीशन की

अलाउ को रिक्वेस्ट के संदर्भ तक सीमित करता है
aws:SourceIp: किस नेटवर्क से आया

S3 ऑब्जेक्ट पढ़ने का एक अलाउ, एक कंडीशन बैंड से गुजरता है जिसमें सोर्स नेटवर्क की और कॉलर टैग की सूचीबद्ध हैं, फिर संदर्भ मैच होने पर अलाउ पथ में, और नहीं होने पर डिनाई पथ में बँटता है.

कंडीशन अलाउ को सीमित करती है

कंडीशन की

अलाउ को रिक्वेस्ट के संदर्भ तक सीमित करता है
aws:SourceIp: किस नेटवर्क से आया
aws:PrincipalTag: कॉलर पर लगा टैग

ABAC: attribute-based access control

एक पॉलिसी, कई प्रिंसिपल्स

एक टेबल, एक समय में एक टेनेंट

एक साझा टेबल

DynamoDB, प्रति टेनेंट एक partition key
अपने आप में आइसोलेशन नहीं

टेनेंट A कॉलर एक लीडिंग कीज़ कंडीशन से गुजरकर साझा DynamoDB टेबल में जाता है, जहाँ टेनेंट A की रोज़ मिलती हैं और टेनेंट B व C की रोज़ ब्लॉक होती हैं.

एक टेबल, एक समय में एक टेनेंट

"Condition": {
  "ForAllValues:StringEquals": {
    "dynamodb:LeadingKeys": ["${aws:PrincipalTag/tenant}"]
  }
}

एक साझा टेबल

DynamoDB, प्रति टेनेंट एक partition key
अपने आप में आइसोलेशन नहीं

एक कंडीशन इसे सीमित करती है

ForAllValues: दिए गए हर key का मैच होना जरूरी

एक टेबल, एक समय में एक टेनेंट

"Action": ["dynamodb:Query", "dynamodb:GetItem", "dynamodb:Scan"],
"Condition": {
  "ForAllValues:StringEquals": {
    "dynamodb:LeadingKeys": ["${aws:PrincipalTag/tenant}"]
  }
}

एक साझा टेबल

DynamoDB, प्रति टेनेंट एक partition key
अपने आप में आइसोलेशन नहीं

एक कंडीशन इसे सीमित करती है

ForAllValues: दिए गए हर key का मैच होना जरूरी

जो गैप बचता है: हर रिक्वेस्ट partition नहीं बताती

dynamodb:Scan कोई key नहीं देती, इसलिए कुछ फेल नहीं हो सकता

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

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