Developer Mac गुम हो जाए तो सुरक्षित response कैसे दें

गुम हुआ developer Mac सबसे पहले credential incident है और उसके बाद hardware incident। Laptop बिना छुए वापस मिल सकता है। वह unlocked या offline हो सकता है, या किसी और के हाथ में हो सकता है, जबकि उसके browser sessions, SSH material, cloud CLI cache, local repositories और agent processes अब भी authority रखते हों।

सबसे खराब response certainty का इंतजार करना है। ऐसी certainty शायद ही कभी मिलती है। पहले ऐसे containment से शुरुआत करें जिसे जरूरत पड़ने पर वापस लिया जा सके। शोर पैदा करने वाले बदलावों से context मिटने से पहले evidence सुरक्षित करें, फिर उन credentials को बदलें जिनसे कोई घुसपैठिया अपना access बढ़ा सकता है। हर service का password घबराकर बदलने के बजाय शांत और क्रमबद्ध प्रक्रिया अपनाएं।

Containment साबित होने तक इसे active access मानें

मानकर चलें कि missing Mac authenticated requests भेज सकता है, जब तक आप जरूरी रास्ते बंद न कर दें। यह धारणा किसी पर आरोप नहीं लगाती और न breach की भविष्यवाणी करती है। यह उस आम गलती से बचाती है जिसमें device recovery ticket को access-control event नहीं माना जाता।

तुरंत चार समय लिख लें: Mac आखिरी बार physically कब देखा गया, आखिरी बार कब locked होने की पुष्टि थी, user ने आखिरी बार sensitive work कब किया और loss की report कब हुई। यही समय review window तय करेंगे। लोग meeting rooms में खोजते रहें और आपकी याददाश्त कई घंटे तक बदलती रहे, ऐसा न होने दें।

आखिरी सुरक्षित समय पर क्या खुला था, उसे दर्ज करें। खास जानकारी लिखें: production host से जुड़ा terminal, deployment code बदलने वाला agent run, cloud console का browser tab, local port forward, history में credentials वाली repository या migration के लिए unlocked password manager। «Backend पर काम कर रहा था» जैसी बात responder के लिए लगभग बेकार है।

काम बांटने से पहले स्थिति को वर्गीकृत करें:

• Machine locked था और नियंत्रित office में खोया।
• Machine unlocked था या lock state का पता नहीं है।
• Machine public transit, hotel या किसी अन्य uncontrolled जगह पर गायब हुआ।
• Machine को active production access या autonomous agent process मिला हुआ था।
• Machine किसी administrator, release engineer या organization account के owner का था।

Disk encryption और hardware-protected secret store वाला locked machine, unlocked machine से बेहतर स्थिति है। फिर भी revocation छोड़ने का कारण नहीं है। Device protection storage से extraction को सीमित करता है। यह unlocked रहने के दौरान किए गए actions को वापस नहीं कर सकता, remote sessions को invalidate नहीं कर सकता और यह नहीं बता सकता कि lock होने से पहले किसी ने machine इस्तेमाल किया या नहीं।

एक incident owner को फैसले लेने और एक recorder को timeline संभालने की जिम्मेदारी दें। छोटी team में दोनों भूमिकाएं एक ही व्यक्ति निभा सकता है। Recorder account, credential class, action, time, operator और evidence location लिखे। पहले घंटे में spreadsheet ठीक है। Reaction emoji वाला chat thread incident record नहीं है।

Missing Mac का आखिरी network address सुरक्षित होने का प्रमाण न मानें। Network location पुरानी, proxied या shared हो सकती है। Suspected finder को उन accounts से call, message या alert न भेजें जो machine पर खुले हो सकते हैं। अलग channel इस्तेमाल करें।

Investigation नष्ट किए बिना device को contain करें

Remote lock और remote erase उचित actions हैं, लेकिन containment केवल इन्हीं तक सीमित नहीं है। जैसे ही report किए गए facts इसका आधार दें, device-management service या operating system की device-finding service से इन्हें जारी करें। Request का समय और delivery confirmation दर्ज करें।

Remote command तभी execute होगा जब device service तक पहुंचेगा। Mac offline हो तो command pending रह सकती है। कोई व्यक्ति उसे offline रख सकता है, इसलिए command लंबे समय तक execute न हो। इसी कारण credential revocation को wipe confirmation का इंतजार नहीं करना चाहिए।

Device administrator से कहें कि retention बदलने या बाद में होने वाले wipe के कारण records गायब होने से पहले उपलब्ध management records जुटा ले। उपयोगी fields में device serial या inventory ID, assigned user, last check-in time, operating system version, last reported IP address, organization द्वारा दर्ज किया गया हो तो FileVault escrow status और remote lock या erase request की स्थिति शामिल हैं। Tooling जो देता है वही इकट्ठा करें। Missing fields से साफ-सुथरी कहानी न गढ़ें।

अगर missing Mac में personal Apple Account इस्तेमाल हुआ था, तो owner incident lead की मौजूदगी में device finding संभाले। उनसे personal account credentials बताने को न कहें। Organization को केवल यह पुष्टि चाहिए कि lock या erase request भेजी गई, unrelated personal data तक access नहीं।

दूसरे systems से local work context सुरक्षित रखें। Provider अनुमति दे तो device का VPN या zero-trust device posture disable करें। Certificate हो तो revoke करें। Network access देने वाले endpoint-management groups से device हटाएं। उस endpoint से जुड़े remote desktop और device-sync privileges disable करें।

यही समय machine से जुड़े unattended work को suspend करने का भी है। Powered-off laptop पर scheduled local job नहीं चल सकती, लेकिन उससे शुरू हुआ remote agent, cloud development environment, CI runner या browser automation स्वतंत्र रूप से चलता रह सकता है। यह मानने से पहले कि missing Mac उसे नियंत्रित कर रहा है, execution location पहचानें।

«बस user का main password बदल दें» वाली सलाह आसान लगती है, पर कमजोर है। Password बदलना मदद कर सकता है, खासकर अगर किसी ने password देख लिया हो। फिर भी personal access tokens, OAuth grants, SSH keys, browser sessions, CLI refresh tokens और service-specific credentials अक्सर सक्रिय रहते हैं। Password reset व्यापक containment plan का केवल एक task है।

अगली call से पहले live agent authority रद्द करें

External actions तक पहुंच रखने वाले coding agent को interactive terminal जितनी ही urgency दें। अगर उसका process live है, session authorized है और machine network तक पहुंच सकता है, तो वह API call या SSH खोल सकता है। Gateway पर और हर उस remote service पर agent की authority रोकें जिसने उसके credentials स्वीकार किए।

पहले हर उस run की पहचान करें जो missing Mac से शुरू हुआ हो सकता है। उसकी process identity, session start और end time, assigned credentials, target systems और आखिरी completed action दर्ज करें। Agent host में session list हो तो प्रभावित sessions को expire होने का इंतजार न करके revoke करें। Missing machine के runs अलग न कर सकें तो उस user के सभी sessions revoke करें और बाद में नए बनाएं।

Sallyport का Sessions journal agent run को तुरंत revoke कर सकता है, जबकि Activity journal app के जरिए की गई individual calls दर्ज करता है। Device-loss response में दोनों records इस्तेमाल करें: एक बताता है कि कौन सा run रोकना है, दूसरा बताता है कि रोकने से पहले run ने क्या करने की कोशिश की।

Agent name को trustworthy identity न समझें। Process label या terminal title में «Claude Code» लिखा होना यह साबित नहीं करता कि कौन सा executable चला, किसने sign किया या attacker ने copied process शुरू किया। Proper approval record में calling process की code-signing authority होनी चाहिए। इस identity को session के साथ दर्ज करें और known-good development setup से मिलाएं।

Gateway future calls रोक सकता है, लेकिन API तक पहुंच चुकी request वापस नहीं ले सकता। अगर agent ने deployment token बनाया, user जोड़ा, repository setting बदली या data upload किया है, तो उस service की सीधे जांच करें। Agent journal आपको lead देता है। Action सफल हुआ या नहीं, इसका authority destination service ही है।

MCP server के जरिए जुड़ने वाले agents के लिए प्रभावित workstation identity पर connection path revoke या disable करें। फिर source repositories, shell profiles, project directories और managed configuration में रखी agent configuration देखें। पुराने tokens हटाने, command hooks की समीक्षा करने और यह जांचने से पहले कि configuration personal या production accounts की ओर तो नहीं जाती, उसे replacement Mac पर restore न करें।

Per-call approval का यहां खास लाभ है। Credential इस्तेमाल होते समय human decision जरूरी होने से user के device से दूर जाने के बाद नुकसान घट सकता है। फिर भी laptop गुम होने के बाद revocation की जगह यह पर्याप्त नहीं है। Running session को मिला approval उस process के लिए valid रह सकता है, और पहले इस्तेमाल किया गया external token copy हो सकता है या उसकी अपनी lifetime हो सकती है।

Credentials को attacker के संभावित misuse के क्रम में बदलें

Credential rotation privilege escalation के रास्ते बंद करने की क्रमबद्ध प्रक्रिया है। पहले वे credentials बदलें जो और access बना सकते हैं, फिर वे जो केवल low-risk development service पढ़ते हैं। क्रम उलटने पर आप छोटे tokens reset करते रहेंगे और cloud administrator token usable रहेगा।

सबसे पहले identity और control-plane access संभालें: identity provider sessions, organization owner accounts, cloud administrator roles, secrets-manager access, source-control organization administration, deployment-control accounts और device-management administration। अगर एक ही व्यक्ति इन सबका owner है तो containment के बाद यह architectural problem ठीक करनी होगी, लेकिन तत्काल incident पहले संभालें।

इसके बाद code को move करने या workloads execute करने वाले access बदलें: CI credentials, package registry publishing tokens, signing credentials, deployment keys, cloud workload tokens, container registry tokens और bastions या production hosts के लिए इस्तेमाल होने वाली SSH keys। अंत में issue trackers, documentation tools, lower-privilege API tokens और individual service passwords संभालें।

हर credential के लिए यह worksheet भरें। इससे वह आम गलती रुकती है जिसमें secret बदल दिया जाता है, लेकिन उस पर भरोसा करने वाले systems छूट जाते हैं।

Secret overwrite करके उम्मीद न करें कि काम हो गया। Provider अलग revocation देता हो तो पुराने item को revoke करें। Intended workflow चलता रहे, इसके लिए सबसे सीमित scope वाला replacement बनाएं। Authorized consumers update करें। फिर जांचें कि पुराना credential fail होता है। Incident record में credential identifier और time लिखें, secret value कभी नहीं।

Bearer token के लिए validation किसी harmless authenticated endpoint को call करना हो सकता है, जिसे पुराने token को reject और replacement को accept करना चाहिए। SSH के लिए हर authorized path से पुरानी public key हटाएं, फिर उसी key से connection test करें और denial की उम्मीद रखें। OAuth grant के लिए identity provider में grant revoke करें और application के active sessions या token list जांचें।

Command-line test इसे स्पष्ट कर सकता है। Safe endpoint की जगह ऐसा endpoint रखें जो authenticated principal लौटाता हो और command केवल clean machine से चलाएं:

curl -i -H "Authorization: Bearer $OLD_TOKEN" https://api.example.internal/whoami

Revocation के बाद expected result authentication failure होना चाहिए, जैसे HTTP/1.1 401 Unauthorized या provider का documented invalid-token response। 200 का अर्थ है कि पुराना token अब भी काम कर रहा है। «Secret manager में बदल दिया» को proof न मानें, क्योंकि remote service अभी भी पुराने credential को स्वीकार कर सकती है।

SSH पर खास संदेह रखें। Developers अक्सर ~/.ssh/id_ed25519 याद रखते हैं, लेकिन deploy keys, hardware-backed keys, SSH certificates, forwarded agents, source-control providers में registered keys, CI में stored keys और bastions पर copied public keys भूल जाते हैं। खोई हुई disk पर नहीं, access-control side पर search करें। Public key स्वीकार करने वाली हर जगह को अब उसे स्वीकार करना बंद करना होगा।

Loss window से पहले और बाद की activity जांचें

Audit review को यह बताना चाहिए कि access हुआ या नहीं, किस authority का इस्तेमाल हुआ, क्या बदला और क्या उस बदलाव ने वापस आने का नया रास्ता बनाया। Logs में केवल obvious destructive commands देखना पर्याप्त नहीं है, क्योंकि attackers पहले तैयारी करते हैं।

Review window last known safe time से उस समय तक रखें जब हर high-authority credential revoke हो गया। अगर loss से पहले device पर unexplained activity थी तो window को पीछे बढ़ाएं। पुराने sessions या credentials सक्रिय रहने तक इसे आगे बढ़ाते रहें। Incident record में timestamps के लिए एक ही time zone रखें।

पहले identity-provider events देखें। Successful और failed sign-ins, नए MFA methods, recovery changes, OAuth consent, नए application grants, session creation, unusual device registrations और administrator role changes खोजें। Failed sign-in को harmless न मानें, अगर वह successful refreshes या उसी context से बने नए session के बीच दिखता है।

फिर cloud और infrastructure audit trails में persistence बनाने वाले actions देखें: नई access keys, service principals, API tokens, role assignments, policy changes, firewall changes, compute instance creation, secret reads, snapshot exports और audit-log configuration changes। केवल read permission वाला token भी इतनी configuration उजागर कर सकता है कि ज्यादा शक्तिशाली credential मिल जाए।

Source-control records भी इसी सावधानी के योग्य हैं। Deploy-key additions, personal access token events, SSH key changes, branch-protection edits, webhooks, repository transfers, application installations, release publishing, package publishing और workflow file changes जांचें। बदला हुआ CI workflow future run को चोरी हुए Mac से ज्यादा access दे सकता है।

SSH destinations के लिए authentication logs, उपलब्ध हों तो command logs, supporting evidence के रूप में shell histories, privileged command records और authorized_keys में नई entries देखें। Reported loss time के बाद successful key login की वजह स्पष्ट होनी चाहिए, भले source address परिचित लगे। Corporate VPN egress से बहुत से लोग एक ही address से आते दिख सकते हैं।

Sallyport अपने journals के पीछे write-blind encrypted, hash-chained audit log रखता है। Clean Mac पर उपलब्ध audit material सुरक्षित करें और entries को evidence मानने से पहले offline integrity check चलाएं:

sp audit verify

सफल verification में chain verifies जैसा result आना चाहिए। Failure हो तो प्रभावित files सुरक्षित करें, error दर्ज करें और जांचें कि verification क्यों विफल हुआ। यह command ciphertext पर chain verify करता है और vault key की जरूरत नहीं होती। यह recorded sequence में बदलाव न होने की पुष्टि करता है, हर remote action सफल हुआ था इसकी नहीं।

Raw logs को chat channel में paste करने के बजाय छोटी event table बनाएं। इसमें timestamp, actor या credential ID, source, action, target, result, evidence reference और disposition रखें। Events को expected, suspicious, confirmed harmful या unresolved चिह्नित करें। Unresolved column जरूरी है। Teams अक्सर एक harmless explanation मिलने पर incident बंद कर देती हैं, जबकि कई account changes की जांच बाकी रहती है।

केवल चोरी नहीं, persistence भी खोजें

Developer machine इस्तेमाल कर सकने वाला intruder तुरंत production change करने के बजाय वापस आने का शांत रास्ता चुन सकता है। नए credentials, बदली हुई automation और ऐसे control changes खोजें जो password reset के बाद भी बने रहें।

हर control plane में हाल में बनाए गए access की जांच करें: नए users, API tokens, OAuth applications, SSH public keys, deploy keys, service accounts, personal access tokens, recovery methods, device enrollments और delegated administrative roles। Baseline हो तो उससे तुलना करें। न हो तो service owner से हर recent entry manually validate कराएं, list को normal घोषित न करें।

Code changes में modified CI definitions, build scripts, package publish settings, dependency URLs, webhook endpoints और secret references खोजें। Malicious workflow अक्सर छोटे pull request या routine maintenance जैसे दिखने वाले configuration change में छिपा होता है। Review window में बने merged changes और open branches भी देखें।

Data movement भी जांचें। Artifact downloads, provider logs में उपलब्ध हों तो repository clones, customer systems से exports, object-storage listing और retrieval events और हाल में shared documents देखें। खासकर incident से पहले बनाए गए local clone के लिए perfect visibility नहीं मिल सकती। No export हुआ मान लेने के बजाय यह limitation record में साफ लिखें।

हर anomaly पर overreact न करें। असामान्य समय पर हुआ deploy approved ticket से जुड़ा हो सकता है। Missing laptop से अलग channel का इस्तेमाल करके उस व्यक्ति या automation account से verify करें जिसने action किया। ऐसे account पर confirmation prompt न भेजें जिसका session exposed हो सकता है और उसके reply को proof न मानें।

Persistence मिले तो scope बाहर बढ़ाएं। Bastion पर नई SSH key मिली है तो उसके जरिए reachable हर host जांचें। नई source-control application मिली है तो उसके granted repositories और उसके token इस्तेमाल करने वाले workflows देखें। नया cloud role मिला है तो उसके role assignments और activity जांचें। पहले persistence हटाएं, evidence सुरक्षित करें, फिर उसके द्वारा पढ़े जा सकने वाले हर credential को rotate करें।

Backup image से नहीं, clean endpoint से access restore करें

Replacement Mac को नई authority सोच-समझकर दें। Full backup restore करने से source code के साथ पुराने tokens, SSH keys, browser cookies, agent configuration, shell hooks और unknown files भी लौट सकते हैं। Active investigation के दौरान यह सुविधा महंगी पड़ सकती है।

नए Mac को normal device management में enroll करें, operating-system updates लगाएं, disk encryption और screen lock enable करें और approved development tools trusted sources से install करें। Account access की समीक्षा के बाद remote repositories से source code restore करें। जहां संभव हो, local settings को version-controlled और reviewed configuration से फिर बनाएं।

Response के दौरान administrative work के लिए अलग account या browser profile इस्तेमाल करें। Daily development access को अधिक सीमित रखें। इससे नुकसान घटता है, जब development environment में untrusted extension, package script या agent instruction चल जाता है।

नए device के लिए SSH credentials फिर से जारी करें। Infrastructure support करे तो organization-managed SSH certificate या हर machine के लिए अलग key को प्राथमिकता दें। Laptop से laptop तक shared private key ले जाना हर device loss को broad migration बना देता है। Public-key naming conventions में machine और owner की पहचान होने से भविष्य में removal तेज होता है।

Fresh API tokens तभी बनाएं जब किसी tool को सचमुच उनकी जरूरत हो। CI में developer token copy करने के बजाय build system को अपना credential दें। Service support करे तो expiry लगाएं। Token का owner और उसका इस्तेमाल होने वाली जगह दर्ज करें। जिसका owner पता न हो, वह secret बाद में incident problem बन जाएगा।

Agent access सबसे अंत में restore करें। Confirm करें कि कौन सा executable connect करेगा, वह कौन सी code-signing authority पेश करता है, किन channels का इस्तेमाल कर सकता है और कौन से credentials मांग सकता है। संभव हो तो शुरुआत read-only या development credentials से करें। Team schedule से पीछे हो, इसलिए wide approval देने के बजाय पहले actions देखें।

Credentials को agent prompts, configuration text, issue comments या history में आने वाले shell commands में न रखें। Action gateway secret को अपने पास रखे और request करते समय ही inject करे। इससे agent को plaintext credentials नहीं मिलते, लेकिन actions को लापरवाही से authorize करने की जिम्मेदारी खत्म नहीं होती।

पुराने रास्ते सच में fail होने के बाद ही incident बंद करें

Missing-Mac incident तब बंद करें जब lost endpoint के पास meaningful access तक usable route न बचा हो, review window की जांच पूरी हो और replacement setup पुराना exposure फिर न बनाए। Physical Mac मिल जाना पर्याप्त नहीं है। Custody uncertain रही हो तो recovered device को फिर enroll या erase करना पड़ सकता है।

Credential worksheet की हर line जांचें। हर high-authority credential के लिए revocation या rotation result दर्ज होना चाहिए। Device से जुड़े हर active agent session का termination result होना चाहिए। हर suspicious event के लिए explanation, remediation या residual risk स्वीकार करने का documented decision होना चाहिए।

Removed access paths के लिए controlled environment से negative tests चलाएं। Confirm करें कि disabled VPN पुरानी device identity को reject करता है। Revoked SSH keys fail होती हैं। पुराने API tokens fail होते हैं। Former organization sessions administrative pages तक नहीं पहुंच सकते, यदि provider session inspection देता है। ऐसे tests secondary region, भूले हुए bastion या अलग identity tenant में बचे पुराने credentials पकड़ लेते हैं।

Details ताजा रहते हुए छोटा post-incident note लिखें। Timeline, impact, affected credentials, reviewed evidence, किए गए actions, open uncertainties और आगे किए जाने वाले changes शामिल करें। Blame छोड़ दें। अगर response इस बात पर निर्भर था कि एक व्यक्ति को याद था token कहां रखा है, तो process को inventory और ownership चाहिए, lecture नहीं।

व्यावहारिक test सरल है: अगर कोई कल missing Mac को power on करे, तो वह अब भी कौन से actions कर सकता है? तब तक काम करते रहें जब तक ईमानदार जवाब «ऐसा कोई महत्वपूर्ण action नहीं» न हो। यह standard remote-wipe receipt से अधिक सख्त है और यही आपके systems की सुरक्षा करता है।