AWS - KMS Enum

Support HackTricks

KMS - Key Management Service

AWS Key Management Service (AWS KMS) को एक प्रबंधित सेवा के रूप में प्रस्तुत किया गया है, जो उपयोगकर्ताओं के लिए ग्राहक मास्टर कुंजी (CMKs) बनाने और प्रबंधित करने की प्रक्रिया को सरल बनाता है। ये CMKs उपयोगकर्ता डेटा के एन्क्रिप्शन में महत्वपूर्ण हैं। AWS KMS की एक उल्लेखनीय विशेषता यह है कि CMKs मुख्य रूप से हार्डवेयर सुरक्षा मॉड्यूल (HSMs) द्वारा सुरक्षित होते हैं, जो एन्क्रिप्शन कुंजियों की सुरक्षा को बढ़ाते हैं।

KMS समानांतर क्रिप्टोग्राफी का उपयोग करता है। इसका उपयोग जानकारी को आराम से एन्क्रिप्ट करने के लिए किया जाता है (उदाहरण के लिए, S3 के अंदर)। यदि आपको जानकारी को ट्रांजिट में एन्क्रिप्ट करने की आवश्यकता है, तो आपको कुछ ऐसा उपयोग करना होगा जैसे TLS

KMS एक क्षेत्र विशेष सेवा है।

अमेज़न के प्रशासकों के पास आपकी कुंजियों तक पहुंच नहीं है। वे आपकी कुंजियों को पुनर्प्राप्त नहीं कर सकते और वे आपकी कुंजियों के एन्क्रिप्शन में आपकी मदद नहीं करते। AWS केवल ऑपरेटिंग सिस्टम और इसके अंतर्निहित एप्लिकेशन का प्रबंधन करता है, यह हमारे ऊपर है कि हम अपनी एन्क्रिप्शन कुंजियों का प्रबंधन करें और यह प्रबंधित करें कि उन कुंजियों का उपयोग कैसे किया जाता है।

ग्राहक मास्टर कुंजी (CMK): 4KB तक के आकार के डेटा को एन्क्रिप्ट कर सकती हैं। इनका उपयोग आमतौर पर DEKs (डेटा एन्क्रिप्शन कुंजी) बनाने, एन्क्रिप्ट करने और डिक्रिप्ट करने के लिए किया जाता है। फिर DEKs का उपयोग डेटा को एन्क्रिप्ट करने के लिए किया जाता है।

एक ग्राहक मास्टर कुंजी (CMK) AWS KMS में एक मास्टर कुंजी का तार्किक प्रतिनिधित्व है। मास्टर कुंजी के पहचानकर्ताओं और अन्य मेटाडेटा के अलावा, जिसमें इसकी निर्माण तिथि, विवरण और कुंजी स्थिति शामिल है, एक CMK में वह कुंजी सामग्री होती है जिसका उपयोग डेटा को एन्क्रिप्ट और डिक्रिप्ट करने के लिए किया जाता है। जब आप एक CMK बनाते हैं, तो डिफ़ॉल्ट रूप से, AWS KMS उस CMK के लिए कुंजी सामग्री उत्पन्न करता है। हालाँकि, आप बिना कुंजी सामग्री के CMK बनाने का विकल्प चुन सकते हैं और फिर उस CMK में अपनी स्वयं की कुंजी सामग्री आयात कर सकते हैं।

मास्टर कुंजियों के 2 प्रकार हैं:

  • AWS प्रबंधित CMKs: अन्य सेवाओं द्वारा डेटा को एन्क्रिप्ट करने के लिए उपयोग किया जाता है। इसका उपयोग उस सेवा द्वारा किया जाता है जिसने इसे एक क्षेत्र में बनाया। ये पहली बार तब बनाए जाते हैं जब आप उस सेवा में एन्क्रिप्शन लागू करते हैं। हर 3 साल में घुमाते हैं और इसे बदलना संभव नहीं है।

  • ग्राहक प्रबंधक CMKs: लचीलापन, घुमाव, कॉन्फ़िगर करने योग्य पहुंच और कुंजी नीति। कुंजियों को सक्षम और अक्षम करें।

एनवेलप एन्क्रिप्शन कुंजी प्रबंधन सेवा (KMS) के संदर्भ में: डेटा कुंजी के साथ डेटा को एन्क्रिप्ट करने और फिर मास्टर कुंजी के साथ डेटा कुंजी को एन्क्रिप्ट करने के लिए दो-स्तरीय पदानुक्रम प्रणाली।

कुंजी नीतियाँ

ये निर्धारित करती हैं कि KMS में कुंजी का उपयोग और पहुंच कौन कर सकता है

डिफ़ॉल्ट रूप से:

  • यह KMS कुंजी के मालिक AWS खाते को KMS कुंजी तक पूर्ण पहुंच देता है

अन्य AWS संसाधन नीतियों के विपरीत, AWS KMS कुंजी नीति स्वचालित रूप से खाते या इसके किसी भी उपयोगकर्ता को अनुमति नहीं देती है। खाता प्रशासकों को अनुमति देने के लिए, कुंजी नीति में एक स्पष्ट कथन शामिल होना चाहिए जो इस अनुमति को प्रदान करता है, जैसे कि यह।

  • बिना खाते को अनुमति दिए ("AWS": "arn:aws:iam::111122223333:root") IAM अनुमतियाँ काम नहीं करेंगी।

  • यह IAM नीतियों का उपयोग करने के लिए खाते को KMS कुंजी तक पहुंच की अनुमति देता है, इसके अलावा कुंजी नीति के।

इस अनुमति के बिना, कुंजी तक पहुंच की अनुमति देने वाली IAM नीतियाँ अप्रभावी हैं, हालाँकि कुंजी तक पहुंच को अस्वीकार करने वाली IAM नीतियाँ अभी भी प्रभावी हैं।

  • यह कुंजी के अप्रबंधनीय होने के जोखिम को कम करता है खाते के प्रशासकों, जिसमें खाता रूट उपयोगकर्ता शामिल है, को पहुंच नियंत्रण अनुमति देकर, जिसे हटाया नहीं जा सकता।

डिफ़ॉल्ट नीति उदाहरण:

{
"Sid": "Enable IAM policies",
"Effect": "Allow",
"Principal": {
"AWS": "arn:aws:iam::111122223333:root"
},
"Action": "kms:*",
"Resource": "*"
}

यदि खाता अनुमति दी गई है ("arn:aws:iam::111122223333:root"), तो खाते से एक प्रिंसिपल को KMS कुंजी का उपयोग करने के लिए IAM अनुमतियों की आवश्यकता होगी। हालाँकि, यदि किसी भूमिका का ARN उदाहरण के लिए विशेष रूप से अनुमति दी गई है कुंजी नीति में, तो उस भूमिका को IAM अनुमतियों की आवश्यकता नहीं है।

नीति विवरण

नीति के गुण:

  • JSON आधारित दस्तावेज़

  • संसाधन --> प्रभावित संसाधन (हो सकता है "*")

  • क्रिया --> kms:Encrypt, kms:Decrypt, kms:CreateGrant ... (अनुमतियाँ)

  • प्रभाव --> अनुमति/अस्वीकृति

  • प्रिंसिपल --> प्रभावित arn

  • शर्तें (वैकल्पिक) --> अनुमतियाँ देने के लिए शर्त

अनुदान:

  • अपने अनुमतियों को आपके AWS खाते के भीतर किसी अन्य AWS प्रिंसिपल को सौंपने की अनुमति देता है। आपको उन्हें AWS KMS APIs का उपयोग करके बनाना होगा। इसमें CMK पहचानकर्ता, अनुदान प्राप्त करने वाला प्रिंसिपल और आवश्यक संचालन का स्तर (Decrypt, Encrypt, GenerateDataKey...) निर्दिष्ट किया जा सकता है।

  • अनुदान बनाने के बाद एक GrantToken और एक GrantID जारी किया जाता है।

पहुँच:

  • कुंजी नीति के माध्यम से -- यदि यह मौजूद है, तो यह IAM नीति पर प्राथमिकता लेता है।

  • IAM नीति के माध्यम से

  • अनुदानों के माध्यम से

कुंजी प्रशासक

डिफ़ॉल्ट रूप से कुंजी प्रशासक:

  • KMS प्रबंधित करने के लिए पहुँच रखते हैं लेकिन डेटा को एन्क्रिप्ट या डिक्रिप्ट नहीं कर सकते।

  • केवल IAM उपयोगकर्ताओं और भूमिकाओं को कुंजी प्रशासकों की सूची में जोड़ा जा सकता है (समूह नहीं)।

  • यदि बाहरी CMK का उपयोग किया जाता है, तो कुंजी प्रशासकों को कुंजी सामग्री आयात करने की अनुमति होती है।

CMKs का रोटेशन

  • जितना अधिक समय एक ही कुंजी को रखा जाता है, उतना अधिक डेटा उस कुंजी के साथ एन्क्रिप्ट किया जाता है, और यदि वह कुंजी भंग हो जाती है, तो डेटा का विस्फोट क्षेत्र उतना ही बड़ा होता है। इसके अलावा, जितना अधिक समय कुंजी सक्रिय रहती है, उसके भंग होने की संभावना बढ़ती है।

  • KMS हर 365 दिनों में ग्राहक कुंजी को घुमाता है (या आप जब चाहें प्रक्रिया को मैन्युअल रूप से कर सकते हैं) और AWS द्वारा प्रबंधित कुंजी हर 3 वर्षों में होती है और इस बार इसे नहीं बदला जा सकता।

  • पुरानी कुंजियाँ रखी जाती हैं ताकि डेटा को डिक्रिप्ट किया जा सके जो रोटेशन से पहले एन्क्रिप्ट किया गया था।

  • एक ब्रेक में, कुंजी को घुमाने से खतरा समाप्त नहीं होगा क्योंकि यह भंग की गई कुंजी के साथ एन्क्रिप्ट किए गए सभी डेटा को डिक्रिप्ट करना संभव होगा। हालाँकि, नया डेटा नई कुंजी के साथ एन्क्रिप्ट किया जाएगा

  • यदि CMK अक्षम या हटाने के लिए लंबित स्थिति में है, तो KMS कुंजी रोटेशन नहीं करेगा जब तक कि CMK को फिर से सक्षम नहीं किया जाता या हटाने को रद्द नहीं किया जाता।

मैन्युअल रोटेशन

  • एक नई CMK बनानी होगी, फिर, एक नई CMK-ID बनाई जाती है, इसलिए आपको कोई भी आवेदन को नए CMK-ID का संदर्भ देने के लिए अपडेट करना होगा।

  • इस प्रक्रिया को आसान बनाने के लिए आप कुंजी-आईडी का संदर्भ देने के लिए उपनामों का उपयोग कर सकते हैं और फिर केवल उस कुंजी को अपडेट करें जिसका उपनाम संदर्भित कर रहा है।

  • आपको पुरानी कुंजियाँ रखनी होंगी ताकि इसके साथ एन्क्रिप्ट की गई पुरानी फ़ाइलों को डिक्रिप्ट किया जा सके।

आप अपने ऑन-प्रिमाइसेस कुंजी अवसंरचना से कुंजियाँ आयात कर सकते हैं।

अन्य प्रासंगिक KMS जानकारी

KMS की कीमत सभी सेवाओं से प्राप्त एन्क्रिप्शन/डिक्रिप्शन अनुरोधों की संख्या के आधार पर होती है।

KMS में पूर्ण ऑडिट और अनुपालन CloudTrail के साथ एकीकरण है; यहीं आप KMS पर किए गए सभी परिवर्तनों का ऑडिट कर सकते हैं।

KMS नीति के साथ आप निम्नलिखित कर सकते हैं:

  • यह सीमित करें कि कौन डेटा कुंजी बना सकता है और कौन सी सेवाएँ इन कुंजियों का उपयोग करने के लिए पहुँच रखती हैं।

  • सिस्टम की पहुँच को केवल एन्क्रिप्ट, केवल डिक्रिप्ट या दोनों तक सीमित करें।

  • यह परिभाषित करें कि सिस्टम को क्षेत्रों के बीच कुंजियों तक पहुँचने की अनुमति दी जाए (हालाँकि यह अनुशंसित नहीं है क्योंकि KMS को होस्ट करने वाले क्षेत्र में विफलता अन्य क्षेत्रों में सिस्टम की उपलब्धता को प्रभावित करेगी)।

आप क्षेत्रों के बीच कुंजियों को समन्वयित या स्थानांतरित/कॉपी नहीं कर सकते; आप केवल क्षेत्र के बीच पहुँच की अनुमति देने के लिए नियम परिभाषित कर सकते हैं।

गणना

aws kms list-keys
aws kms list-key-policies --key-id <id>
aws kms list-grants --key-id <id>
aws kms describe-key --key-id <id>
aws kms get-key-policy --key-id <id> --policy-name <name> # Default policy name is "default"
aws kms describe-custom-key-stores

Privesc

Post Exploitation

Persistence

References

HackTricks का समर्थन करें

Last updated