ISMS अनुपालन के दौरान शुरू हुई AWS Access Key की सफ़ाई: Role-आधारित authentication पर स्विच करने की यात्रा

यह लेख उस अनुभव का सार है जिसमें ISMS पोस्ट-ऑडिट की तैयारी के दौरान AWS अकाउंट में जमा Access Key की जाँच करते हुए Role-आधारित authentication पर स्विच किया गया।

परिचय की पृष्ठभूमि

• IAM console में देखने पर Access Key कई जगहों (CI/CD, deployment scripts, local development आदि) में फैली हुई थीं, और यह ट्रैक करना मुश्किल था कि वे कहाँ और कैसे इस्तेमाल हो रही हैं
• Access Key बिना expiry के बनी रहती हैं, और चोरी हो जाने पर दिए गए permissions वैसे के वैसे उजागर हो जाते हैं, इसलिए जोखिम बहुत बड़ा था
• AWS भी long-term credentials (Access Key) की जगह temporary credentials (role/STS) के उपयोग की सिफारिश करता है

समस्या

• keys जगह-जगह कॉपी होकर इस्तेमाल हो रही थीं, इसलिए “अगर यह key चोरी हो जाए तो असर कहाँ तक जाएगा?” इस सवाल का जवाब देना मुश्किल था
• rotation करने के लिए बिखरी हुई settings को एक साथ बदलना पड़ता था, और एक IAM User में कई उद्देश्यों के permissions एकत्र होने से least privilege लागू करना कठिन था
• उस समय CI/CD के लिए बने एक IAM User में ECR/S3/SSM/ECS deployment permissions आदि एक साथ केंद्रित थे

अपनाया गया तरीका (सार)

• Assume Role: ज़रूरत के समय किसी दूसरे Role के permissions को अस्थायी रूप से उधार लेकर इस्तेमाल करने का तरीका
• OIDC Web Identity: GitHub Actions/EKS(=IRSA) की तरह external system ID के आधार पर Role जारी करने का तरीका
• Instance Profile: EC2/Lambda आदि पर Role सीधे अटैच करके अपने-आप permissions दिलाने का तरीका

वास्तविक migration प्रक्रिया

• चरण 1: broad policy लगी हुई IAM User permissions को उपयोग के आधार पर अलग-अलग Role में विभाजित किया गया (ECR push/pull, ECS deployment, S3 cache आदि)
• चरण 2: GitHub Actions पर OIDC लागू किया गया (Identity Provider registration → Trust Policy conditions से repo scope सीमित करना → workflow में configure-aws-credentials का उपयोग)

प्रभाव

• code/secrets से Access Key हट गईं; temporary token आधारित संरचना होने से चोरी हो जाने पर भी expiry के कारण नुकसान की सीमा सीमित रहती है
• key rotation का बोझ खत्म हो गया, और workflow/कार्य-आधारित permissions tracking अधिक स्पष्ट हो गई

ध्यान देने योग्य बातें

• Trust Policy conditions को बहुत व्यापक न रखें; उन्हें न्यूनतम सीमा तक सीमित करें (org/repo, और संभव हो तो branch तक)
• मौजूदा Access Key को तुरंत delete न करें; migration के बाद कुछ समय तक disable/verification अवधि रखने के बाद ही हटाएँ