आपने एक Cloud Mess को inherit किया। आप कहाँ शुरू करते हैं?

आपने अभी एक cloud account (या दस) संभाला है जिसे किसी और ने तीन साल पहले बनाया था बिना कोई documentation के, contractors की rotating team के साथ, और एक Slack channel #aws-help जो 2022 से active नहीं रहा है। यह cloud security work में सबसे आम situations में से एक है, और यह uncomfortable है क्योंकि आप कुछ के लिए जिम्मेदार हैं जिसे आप अभी explain नहीं कर सकते।

यहाँ है कि कैसे zero visibility से एक defensible position तक पहुँचें बिना सब कुछ बर्बाद किए।

पहले guessing रोकें और एक inventory लें

आप जो देख नहीं सकते उसे secure नहीं कर सकते। एक भी IAM policy को छुए बिना, एक inventory pass चलाएँ:

• AWS: aws organizations list-accounts से पूरी account structure देखें, फिर Steampipe या AWS Config aggregators से accounts के पार resources को एक queryable view में pull करें।
• Azure: Resource Graph queries (az graph query) subscriptions के पार, क्योंकि Azure का tenant/subscription model sprawl को आसानी से छुपा देता है।
• GCP: gcloud asset search-all-resources organization level पर।

इसे billing data के साथ cross-reference करें। Billing झूठ नहीं बोलती कि क्या चल रहा है, भले ही tags और documentation करते हों। अगर आप किसी service पर spend देखते हैं जिसका कोई onboarding में जिक्र नहीं किया, वह आपकी पहली finding है।

जो टूटा है उसे खोजने से पहले पता करें कि कौन क्या कर सकता है

Misconfigurations सुर्खियाँ लेते हैं, लेकिन identity वह जगह है जहाँ एक inherited environment में असली exposure आमतौर पर रहता है। हर IAM user, role, और service account को pull करें और तीन सवाल पूछें: क्या इसे अभी भी मौजूद होने की जरूरत है, क्या इसके पास access है जिसका यह use नहीं करता, और यह human है या machine।

AWS IAM Access Analyzer चलाएँ या iam-lint-style tooling उपयोग करें जो पिछले 90 दिनों में unused permissions को flag करे। व्यावहार में, inherited accounts के पास लगभग हमेशा कम से कम एक IAM user होता है long-lived access keys के साथ जो माना जाता था कि