क्या production backups के लिए अलग backup credentials चाहिए?

Backup तभी recovery copy है जब production को नुकसान पहुँचाने वाली घटना उस कॉपी को भी न मिटा सके। Automated job के पीछे मौजूद credentials देखने तक यह बात साफ़ लगती है। कई setups में एक ही token live data पढ़ता है, backup लिखता है, पुराने backups की सूची बनाता है, retention के लिए उन्हें हटाता है, destination बदलता है और restore शुरू करता है। यही token किसी autonomous agent को दे दें, तो एक गलत या compromised API call production outage को recovery failure में बदल सकती है।

इसका समाधान clever भाषा में लिखी गई बड़ी permission policy नहीं है। Live data और recovery data के लिए अलग action boundaries बनाएँ। Production चलाने वाला credential recovery copies को न हटा सके। Backup लिखने वाला credential उसकी retention न बदल सके। Restore के लिए अपनी मंज़ूरी होनी चाहिए, क्योंकि इससे संवेदनशील data active environment में वापस जाता है। हर boundary ऐसी हो कि गलत request का असर होने से पहले ही वह fail हो जाए।

यह design problem है, vendor problem नहीं। यही तरीका object storage, managed backup vault, snapshots, physical appliance या दूसरे cloud account में रखी copies पर लागू होता है। Storage immutability महत्वपूर्ण है। अलग administration भी महत्वपूर्ण है। लेकिन अगर agent की सामान्य working identity उनके आसपास के destructive controls अब भी चला सकती है, तो इनमें से कोई भी control पर्याप्त नहीं है।

अगर एक identity copy मिटा सकती है, तो वह सचमुच अलग नहीं है

Recovery copy को production की अपेक्षित failure modes से बचना चाहिए, जिसमें privileged credential का दुरुपयोग भी शामिल है। अगर वही agent identity delete production database और delete recovery vault दोनों चला सकती है, तो आपके पास isolated recovery नहीं, केवल duplicate data है।

Teams अक्सर production और backups के लिए अलग buckets, folders, regions या resource names इस्तेमाल करके इसे separation कहते हैं। यह storage layout है, access separation नहीं। Broad access वाला एक principal कुछ requests में इन सभी सीमाओं को पार कर सकता है।

जाँच आसान है: production agent को उपलब्ध credential लें और देखें कि वह किसी दूसरे व्यक्ति, identity या physically अलग control plane के बिना क्या कर सकता है। अगर वह इनमें से कुछ भी कर सकता है, तो recovery पर उसका प्रभाव बहुत अधिक है:

• Recovery point या object version को स्थायी रूप से हटाना।
• Retention घटाना, retention bypass करना या hold हटाना।
• Replication बंद करना या future copies को दूसरी जगह भेजना।
• Encryption access बदलना, जिससे restoration विफल हो जाए।
• Backup vault, project, account या storage container हटाना।

मुश्किल यह है कि agent को backups हटाने का स्पष्ट निर्देश कभी मिला ही न हो। Model बहुत व्यापक cleanup command चुन सकता है। Tool wrapper किसी सामान्य लगने वाली operation को destructive endpoint से जोड़ सकता है। Compromised repository agent को पहले से मौजूद credentials इस्तेमाल करने के लिए उकसा सकती है। सुरक्षा तब भी काम करनी चाहिए जब request गलत हो, केवल तब नहीं जब prompt समझदारी भरा हो।

यहाँ दो अलग blast radii नियंत्रित करने हैं। पहला है data plane damage, जिसमें agent business data बदलता या हटाता है। दूसरा है recovery plane damage, जिसमें agent copies मिटाता है, उन तक पहुँचने का रास्ता बंद करता है या उन्हें decrypt करना असंभव बनाता है। अधिकांश teams पहले पर मेहनत करती हैं और दूसरे को उसी administrator role से जोड़ देती हैं।

ऐसा अक्सर सुविधा के कारण होता है। Retention cleanup के लिए expired backups हटाने की permission चाहिए, इसलिए backup job को broad delete rights मिल जाते हैं। Restore test के लिए privileged role चाहिए, इसलिए वही integration उसे भी पा लेती है। Engineer CI में एक ही secret चाहता है, इसलिए role में हर permission जुड़ जाती है। हर shortcut समझ में आता है। साथ मिलकर वे routine automation credential को recovery की आखिरी सुरक्षा पर अधिकार दे देते हैं।

Backup लिखना और उसकी lifetime संभालना अलग काम हैं

Backup writer को सीमित और दोहराए जा सकने वाले path की आवश्यकता होती है। Retention administrator को copies बदलने या हटाने का अधिकार चाहिए। Recovery operator को चुनी हुई copy पढ़कर उसे controlled target में लाने का अधिकार चाहिए। इन सबको एक job मानने से backup identity खतरनाक बनती है।

एक उपयोगी विभाजन चार action classes में है:

1. Capture नामित production source को पढ़ता है और नया recovery artifact बनाता है।
2. Deposit उस artifact को आवश्यक retention attributes के साथ एक निर्धारित destination पर लिखता है।
3. Recover चुने हुए artifact को पढ़ता है और उसे केवल अनुमत target पर restore करता है।
4. Administer retention, holds, vault settings, replication, encryption access या deletion rules बदलता है।

Capture और deposit अक्सर बिना निगरानी के चल सकते हैं। Recover के लिए आमतौर पर नई मंज़ूरी चाहिए, क्योंकि यह बड़ी मात्रा में संवेदनशील जानकारी को नए runtime में पहुँचा सकता है। Administration को agent के सामान्य path से पूरी तरह बाहर रखें, केवल संकीर्ण और अलग से स्वीकृत emergency procedures को छोड़कर।

Cleanup को capture न समझें। Automated expiration उपयोगी है, लेकिन इसका मतलब यह नहीं कि writer के पास स्थायी deletion authority हो। Lifecycle rules को recovery system या अलग retention role के अधीन रखना बेहतर है। अगर platform writer को अपने पुराने copies हटाने के लिए मजबूर करता है, तो उसे केवल छोटी, dedicated staging area में सीमित permission दें। पूरी हो चुकी copies को protected destination पर replicate करें, जहाँ writer उन्हें हटा या बदल न सके।

यह अंतर एक परिचित failure पकड़ता है। Database agent हर घंटे export चलाता है। उसकी role recovery/incoming/ में लिख सकती है, prefix की सूची बना सकती है और पुरानी files हटा सकती है। महीनों बाद storage team destination को recovery/ कर देती है। पुरानी prefix सीमा हट जाती है और agent को current recovery data पर delete rights मिल जाते हैं। Job अब भी green रिपोर्ट करती है। समस्या तभी दिखती है जब किसी को copy चाहिए होती है।

Permissions में intent साफ़ दिखाने वाले अलग names इस्तेमाल करें। backup-writer, backup-retention-admin और restore-operator, backup-service नाम की एकल role से अधिक स्पष्ट हैं। साफ़ names access लागू नहीं करते, लेकिन review को बिना सोचे पास करना कठिन बना देते हैं।

अलग credentials को अलग authorities तक पहुँचना चाहिए

एक ही broad administrator role के लिए दो API keys बना देने से कोई वास्तविक लाभ नहीं होता। Separate credentials तभी उपयोगी हैं जब वे ऐसी authorities तक ले जाएँ जिन्हें attacker, broken script या agent एक ही जगह समेट न सके।

छोटे access map से शुरुआत करें। हर source, destination, credential और destructive operation लिखें। केवल storage path नहीं, cloud account या subscription भी शामिल करें। Map को उन सवालों का जवाब देना चाहिए जिन्हें application diagrams अक्सर छोड़ देते हैं:

• Copy कौन-सी identity बनाती है?
• Scheduled expiry से पहले existing copy कौन हटा सकता है?
• Retention कौन घटा सकता है या bypass चला सकता है?
• Replication, vault lock या restore के लिए आवश्यक encryption keys कौन बदल सकता है?
• Data को production तक पहुँचने वाले network में कौन restore कर सकता है?

अगर तीन या अधिक सवालों का उत्तर वही service identity है, तो और automation जोड़ने से पहले actions अलग करें।

व्यावहारिक न्यूनतम design ऐसा दिख सकता है:

Identities शुरुआत में एक ही provider में रह सकती हैं, लेकिन उनकी roles, credentials और approval paths अलग होने चाहिए। बेहतर separation में protected destination दूसरे account में होता है, जिसे अलग administrative group नियंत्रित करता है। और मजबूत separation के लिए independent identity provider या ऐसा recovery environment रखें जिसे production administrators चुपचाप बदल न सकें। Perfect account structure की प्रतीक्षा में पहला split न टालें।

अगर production super-admin जब चाहे recovery administrator role ले सकता है, तो अलग account भी विफल हो जाता है। छोटे संगठन के पास कोई दूसरा विकल्प न हो तो यह स्वीकार्य हो सकता है, लेकिन इसे सही नाम दें: यह convention पर आधारित administrative separation है। यह उस boundary से कमजोर है जिसमें अलग व्यक्ति, hardware factor या external approval की आवश्यकता हो।

Immutability deletion के एक प्रकार को रोकती है, हर recovery failure को नहीं

Immutable storage retention period के दौरान existing copies को बदलने या हटाने से बचाती है। इससे यह साबित नहीं होता कि नई copies लगातार पहुँच रही हैं, उनमें सही data है, encryption keys उपलब्ध रहेंगी या operator उन्हें restore कर सकेगा। यह महत्वपूर्ण control है, लेकिन पूरी recovery plan का भार अकेले नहीं उठा सकता।

CISA की StopRansomware guidance संगठनों से backups को offline रखने और backup data को encrypted तथा immutable रखने को कहती है। यह सलाह सही है, क्योंकि attackers production तक पहुँचने के बाद अक्सर backup systems को भी निशाना बनाते हैं। इसका अर्थ यह नहीं समझना चाहिए कि application चलाने वाली automation में vault administrator credential भी रख दिया जाए।

Amazon S3 Object Lock यह अंतर साफ़ दिखाता है। Compliance mode में protected object version को retention date से पहले कोई user, account root user भी, overwrite या delete नहीं कर सकता। Governance mode में s3:BypassGovernanceRetention वाला caller स्पष्ट bypass request करके protection को override कर सकता है। Amazon के documentation में यह भी बताया गया है कि permission वाले caller के लिए console यह bypass header अपने-आप जोड़ देता है।

Governance mode उपयोगी है, खासकर जब आप यह समझ रहे हों कि कौन-सी retention अवधि वहन कर सकते हैं। लेकिन यदि agent credential के पास bypass authority है, तो यह hard boundary नहीं है। किसी cleanup task की failure रोकने के लिए agent को s3:BypassGovernanceRetention न दें। Lifecycle design ठीक करें।

Compliance retention की एक कीमत है: गलत retention period data को अपेक्षा से अधिक समय तक रख सकती है और उसे छोटा नहीं किया जा सकता। इसका निर्णय सोच-समझकर लें। Retention length recovery requirements, कानूनी दायित्वों, data sensitivity, cost और intrusion पता चलने में लगने वाले समय से तय करें। किसी दूसरी team से copy की गई blanket setting plan नहीं होती।

Versioned object storage में एक और trap है। Simple delete request पुराने object version को स्थायी रूप से हटाने के बजाय delete marker बना सकती है। इससे latest view देखने वाले operator को restore टूटा हुआ लग सकता है, जबकि protected version अभी मौजूद हो। आपकी recovery procedure में यह बताया जाना चाहिए कि आवश्यक version को कैसे पहचाना और वापस लिया जाए। Incident के दौरान जिसे कोई ढूँढ न सके, वह undeletable object भी केवल आधा सुरक्षित है।

Destructive backup controls को अलग मंज़ूरी के पीछे रखें

Routine backup creation उबाऊ होनी चाहिए। नए agent session को backup writer credential इस्तेमाल करने की मंज़ूरी चाहिए हो सकती है, लेकिन capture और deposit calls को human attention नहीं माँगनी चाहिए, यदि वे अपने source और destination तक सीमित हों। लोग दोहराए जाने वाले prompts को पढ़े बिना approve करना जल्दी सीख लेते हैं।

Destructive या irreversible actions के साथ अलग व्यवहार करें। Recovery copy हटाना, retention घटाना, replication destination बदलना, vault lock बंद करना, decryption material export करना या production तक पहुँचने वाले environment में restore करना, इन सबको नई और specific approval पर रोकना चाहिए। Approval में plain language में action, credential, target और प्रभाव बताया जाए।

खराब approval: Allow backup operation?

उपयोगी approval: क्या backup-retention-admin को archive-vault से 14 expired recovery points हटाने दें? Immutable retention के अंतर्गत न आने वाली copies के लिए यह कार्रवाई वापस नहीं ली जा सकती।

शब्द महत्वपूर्ण हैं, क्योंकि reviewer ऐसी request को अस्वीकार कर सकता है जो technically authorized हो लेकिन operationally गलत हो। Production agent अचानक recovery vault बदलने की request करे, तो किसी को IAM action name समझने से पहले ही यह असामान्य दिखना चाहिए।

Approval permissions का विकल्प नहीं है। Reviewer गलत request approve कर सकता है, खासकर रात 2 बजे जब incident ने screen को alerts से भर दिया हो। Permission boundary को normal writer के लिए खतरनाक actions unavailable बनाने चाहिए। Approval उन थोड़ी कार्रवाइयों को नियंत्रित करती है जिन्हें जानबूझकर संभव रखा गया है।

जब coding agent को backup API call करनी हो या SSH-based backup task चलाना हो, Sallyport इसी pattern में काम करता है: credential app के vault में रखें, सामान्य session को केवल writer credential इस्तेमाल करने दें और recovery administration credentials के हर उपयोग पर approval रखें। Agent को secret नहीं, action का result मिलता है।

यह व्यवस्था लंबे समय तक चलने वाले agents की practical समस्या भी संभालती है। किसी process को एक बार approve करके यह न मानें कि उसके हर future action पर वही भरोसा लागू होगा। नए process को अपना session बनाना चाहिए। Process को routine backup access पहले से मिली हो, तब भी sensitive credential के लिए हर call पर अपनी consent आवश्यक होनी चाहिए।

Policy fragment गलत call को असंभव बनाए

Permission reviews तब अधिक स्पष्ट होते हैं जब आप उस request को test करते हैं जिसे कभी सफल नहीं होना चाहिए। नीचे दिया गया उदाहरण S3-style deposit role दिखाता है। यह assigned prefix के नीचे केवल नया object रख सकती है। इसमें DeleteObject, retention bypass, bucket-policy authority या archive पढ़ने की permission नहीं है।

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "WriteNewRecoveryArtifacts",
      "Effect": "Allow",
      "Action": ["s3:PutObject"],
      "Resource": "arn:aws:s3:::recovery-archive-prod/incoming/database/*"
    },
    {
      "Sid": "DenyRecoveryAdministration",
      "Effect": "Deny",
      "Action": [
        "s3:DeleteObject",
        "s3:DeleteObjectVersion",
        "s3:BypassGovernanceRetention",
        "s3:PutObjectRetention",
        "s3:PutObjectLegalHold",
        "s3:PutBucketPolicy",
        "s3:DeleteBucket"
      ],
      "Resource": "*"
    }
  ]
}

यह policy को आँख बंद करके paste करने का उदाहरण नहीं है। Real deployment में encryption headers, multipart upload actions, bucket restriction या replication service के लिए अलग role की आवश्यकता हो सकती है। बात यह है कि इसे पढ़ने वाला कोई व्यक्ति यह न सोचे कि यह identity recovery artifact हटा सकती है या नहीं। उत्तर साफ़ दिखना चाहिए।

हर permission change के बाद negative test चलाएँ। Deposit credential active होने पर delete ऐसी failure दे जो logs में दर्ज हो सके:

aws s3api delete-object \
  --bucket recovery-archive-prod \
  --key incoming/database/2026-07-22/backup.sql.zst

स्वस्थ result कुछ ऐसा होगा:

An error occurred (AccessDenied) when calling the DeleteObject operation:
User is not authorized to perform: s3:DeleteObject on resource:
arn:aws:s3:::recovery-archive-prod/incoming/database/2026-07-22/backup.sql.zst

फिर वह action test करें जो role को करना चाहिए। एक harmless canary artifact upload करें, जाँचें कि उसकी retention settings अपेक्षित हैं और confirm करें कि agent बाद में उन्हें बदल नहीं सकता। Negative test में टिके बिना permission design अभी भी केवल diagram है।

Retention administrator का credential इस writer credential के पास «emergencies के लिए» भी न रखें। Emergencies broad secret इस्तेमाल करने का सबसे अधिक दबाव बनाती हैं। उस credential को अलग store में रखें और अलग approval route या दूसरे operator की आवश्यकता रखें।

Deletion रुकने पर भी recovery data leak हो सकता है

Teams आमतौर पर restore को सुरक्षित दिशा मानती हैं। Backup delete करने से यह सुरक्षित है, लेकिन फिर भी privileged action है। Customer database को किसी ad hoc development environment में restore करने से production secrets, personal data, payment records या internal tokens उजागर हो सकते हैं। Production connectivity वाले network में image restore करने से stale credentials और असुरक्षित services भी आ सकती हैं।

Restore action में recovered system के अनुसार constraints होने चाहिए। कम से कम source recovery point, destination account या project, target network और intended access group तय करें। Platform restore sandbox देता हो तो उसका उपयोग करें। न देता हो तो outbound controls और default रूप से production तक कोई route न रखने वाला restricted destination बनाएँ।

Restore approval को backup approval से अलग रखने का एक और कारण है: recovery operator को protected data पढ़ने की permission चाहिए हो सकती है, जबकि backup writer को नहीं। यह read authority write authority से अधिक संवेदनशील हो सकती है। Export job encrypted data बना सकता है और plaintext देखे बिना काम कर सकता है। Restore job अक्सर plaintext को materialize करती है।

एक अच्छी restore drill केवल यह नहीं पूछती कि «क्या command पूरी हुई?» वह यह भी जाँचती है कि:

• चुना गया timestamp incident scenario से मेल खाता है।
• Intended recovery identity artifact को decrypt कर सकती है।
• Application isolated configuration के साथ शुरू होती है।
• Expected records और schema मौजूद हैं।
• Temporary restored environment को नष्ट किया गया है या अपनी access rules के तहत रखा गया है।

Drills केवल कल की सबसे आसान copy पर न चलाएँ। पुराने recovery points, अलग data sources और ऐसी परिस्थितियाँ चुनें जहाँ object version या encryption key को जानबूझकर चुनना पड़े। कठिन restore ही बताता है कि runbook वास्तविकता लिखती है या नहीं।

Failure path अक्सर harmless request से शुरू होता है

एक coding agent के पास production database और cloud provider CLI का access मान लें। उसे test environment में जमा पुराने exports के बाद storage cost घटाने का request मिलता है। Agent broad storage prefix की सूची बनाता है, बड़ी objects ढूँढता है और deletion command भेज देता है। Engineer का उद्देश्य staging files साफ़ करना था। Wildcard सुविधाजनक होने के कारण credential staging और archive दोनों तक पहुँचता है।

अगर archive ordinary versioning इस्तेमाल करता है, तो command delete markers जोड़ सकती है और current copies को सामान्य listing से गायब कर सकती है। Governance retention होने और credential में bypass authority शामिल होने पर request versions को पूरी तरह हटा सकती है। Compliance retention में delete request विफल होती है, जो ठीक वही failure है जिसकी आपको आवश्यकता है।

अब केवल credential design बदलें। Agent test path के लिए staging-cleaner credential और नई archive writes के लिए deposit-only credential इस्तेमाल कर सकता है। इनमें से कोई भी protected recovery objects को list या delete नहीं कर सकता। Request incident बनने से पहले ही विफल हो जाती है। Recovery administrator बाद में अलग approval के साथ cost issue देख सकता है और तय कर सकता है कि lifecycle rules बदलने की आवश्यकता है या नहीं।

यही कारण है कि broad storage credentials दिखने से अधिक खराब होते हैं। Command खुद सामान्य हो सकती है। Destructive outcome ऐसी identity से आता है जो उन boundaries को पार करती है जिनकी task को आवश्यकता ही नहीं थी।

Allowed और denied recovery actions, दोनों का audit record रखें। Denied record साबित करता है कि control ने काम किया। Allowed record बताता है कि किस process ने कौन-सा credential इस्तेमाल किया, किस चीज़ को छुआ और कब। Sallyport में session journal और activity journal ये दोनों स्तर का evidence देते हैं, और sp audit verify vault access के बिना offline hash chain जाँच सकता है। Incident के बाद यह उपयोगी है, क्योंकि «success» कहने वाली backup report suspicious administrative request को समझा नहीं सकती।

Backup reporting में केवल success नहीं, authority भी दिखनी चाहिए

अधिकांश backup dashboards बताते हैं कि job पूरी हुई या नहीं और कितना data copy हुआ। एक दूसरा view जोड़ें: बदलाव किस authority ने किया, कौन-सी operation का प्रयास हुआ और system ने उसे स्वीकार किया या नहीं। जब हर report authorization को केवल green या red job badge में बदल देती है, तब recovery security चुपचाप विफल होती है।

हर backup run के लिए source identifier, destination identifier, artifact version या recovery point ID, credential class, retention state और result दर्ज करें। हर denied action के लिए इतना context रखें कि secrets या sensitive payloads store किए बिना जाँच हो सके। Record से full backup और failed upload, routine lifecycle expiration और manual deletion, तथा blocked destructive call और review की आवश्यकता वाली missing permission में अंतर करना संभव होना चाहिए।

Agent को detailed report देने के लिए recovery storage पर broad read access न दें। कई providers metadata endpoints, inventory reports या narrowly scoped status calls देते हैं। Agent को manifest पढ़ना ही पड़े तो अलग manifest लिखें, जिसमें customer data की catalog के बजाय identifiers, checksums, capture times और retention status हों।

एक उपयोगी weekly review चार सवाल पूछती है:

1. क्या हर अपेक्षित source ने recoverable artifact बनाया?
2. क्या किसी identity ने retention, deletion या replication बदलने का प्रयास किया?
3. क्या current writer credential recovery administration actions तक पहुँच सकता है?
4. क्या restore drill ने साबित किया कि चुनी हुई पुरानी copy application को isolation में शुरू कर सकती है?

अगर team अपने records से इन सवालों का उत्तर नहीं दे सकती, तो backup design काम कर रही है मानने से पहले records सुधारें।

अधिक automation से पहले boundary बनाएँ

अपने agent या CI job के पास पहले से मौजूद credential से शुरुआत करें। Recovery copies हटाने, retention bypass करने, holds बदलने, replication बदलने, vault settings बदलने और recovery account administer करने की उसकी क्षमता हटा दें। फिर ऐसी deposit identity बनाएँ जो केवल वहीं लिख सके जहाँ उसे लिखना चाहिए। यह एक बदलाव गलत instruction से irreversible damage तक जाने वाले सामान्य रास्ते को बंद कर देता है।

इसके बाद lifecycle और retention controls को अलग administrative identity में ले जाएँ। उस recovery window के लिए immutable retention जोड़ें जिसे आपका संगठन निभा सकता है। Restore को constrained destination में रखें और normal runtime के बाहर कहीं भी sensitive data लौटने से पहले specific approval आवश्यक करें। आखिर में ऐसी drill चलाएँ जिसमें expected backup और forbidden deletion, दोनों का प्रयास हो।

आपका backup design agents के लिए तब तैयार है जब agent recovery copy बना सके, लेकिन उसे recovery नष्ट करने का अधिकार न हो। तब तक automation केवल साझा गलती को तेज़ बनाती है।