आपका trading bot एक ही इंटरफ़ेस से काम करता है: exchange API। हर order, हर balance check, हर position query आपके बनाए API credentials से गुज़रता है। अगर ये credentials गलत तरीके से configure किए गए हैं, compromise हो गए हैं, या ठीक से समझे नहीं गए हैं, तो नतीजे unauthorized trades से लेकर पूरे account की निकासी तक हो सकते हैं।
यह गाइड बुनियादी security hygiene (जो हमारी मूलभूत सुरक्षा गाइड में शामिल है) से आगे जाती है और उस operational security framework को गहराई से समझाती है जो पेशेवर bot operators को शौकिया traders से अलग करता है। हम permission architecture, network-level access controls, credential lifecycle management, exchange failure handling, और एक संपूर्ण incident response playbook को कवर करेंगे।
मुख्य बातें
- API keys के चार permission levels होते हैं: read, spot trade, futures trade, और withdrawal। Bot connections के लिए withdrawal कभी भी enable नहीं होना चाहिए।
- IP whitelisting चोरी हुई API keys को बेकार बना देती है। इसे हर exchange पर configure करें: Binance, Bybit, और OKX तीनों इसे support करते हैं।
- हर 90 दिनों में API keys rotate करें, zero-downtime प्रक्रिया अपनाएं: नई key बनाएं → bot अपडेट करें → verify करें → पुरानी key डिलीट करें।
- Subaccount isolation blast radius को सीमित करता है: एक compromised bot केवल उस subaccount की capital को प्रभावित कर सकता है, आपके पूरे portfolio को नहीं।
- जब exchange mid-trade डाउन हो जाता है, तो open orders order book पर बने रहते हैं, और bots को reconnection के बाद state reconcile करनी होती है।
- Rate limit violations (Binance: 1,200/min, Bybit: 120/5sec) के कारण temporary IP bans लग सकती हैं। Bots को proactively requests throttle करनी चाहिए।
API Key Permission Levels: न्यूनतम अनुमति का सिद्धांत
हर प्रमुख exchange API keys के लिए एक granular permission system लागू करता है। सिद्धांत सरल है: bot को जितनी permissions चाहिए, बस उतनी ही दें, उससे ज़्यादा कभी नहीं। हर level क्या नियंत्रित करता है:
Permission Architecture
| Permission Level | क्या अनुमति देता है | Bot को ज़रूरत? | Compromise होने पर जोखिम |
|---|---|---|---|
| Read-Only | Balances, order history, market data देखें | ✅ हमेशा | कम: attacker account data देख सकता है |
| Spot Trade | Spot market/limit orders लगाएं और cancel करें | ✅ Spot bots के लिए | मध्यम: attacker trades execute कर सकता है |
| Futures Trade | Leveraged positions खोलें/बंद करें, margin सेट करें | ✅ Futures bots के लिए | उच्च: leveraged losses संभव |
| Withdrawal | Funds बाहरी wallets में transfer करें | ❌ कभी नहीं | गंभीर: पूर्ण fund loss |
| Internal Transfer | Subaccounts के बीच funds move करें | ⚠️ शायद ही कभी | मध्यम: fund reallocation |
Withdrawal Permission क्यों सबसे खतरनाक है
Withdrawal disabled होने पर, compromised API key से सबसे बुरी स्थिति यह है: attacker खराब trades लगाता है। आपकी capital को नुकसान होता है, लेकिन वह exchange पर रहती है। आप recover कर सकते हैं।
Withdrawal enabled होने पर, सबसे बुरी स्थिति complete loss है। Attacker सेकंडों में आपका account अपने wallet में drain कर लेता है। Crypto transactions irreversible होते हैं। कोई chargeback नहीं, कोई recovery नहीं।
गणित स्पष्ट है। मान लीजिए आपके पास Binance पर $50,000 हैं:
- Withdrawal disabled, key compromise: Attacker बेतरतीब trades लगाता है। वास्तविक नुकसान: $2,000–$10,000 slippage और खराब fills में, इससे पहले कि आप notice करें और key revoke करें। बची हुई capital: $40,000–$48,000।
- Withdrawal enabled, key compromise: Attacker $50,000 अपने wallet में भेज देता है। बची हुई capital: $0।
कोई भी वैध bot platform, Freya Finance सहित, कभी withdrawal permission नहीं मांगता। अगर कोई platform इसकी मांग करता है, तो वह platform या तो अक्षम है या दुर्भावनापूर्ण। तुरंत वहां से दूर हो जाएं।
Exchange-विशिष्ट Permission Setup
Binance: Account → API Management → Create API पर जाएं। "API restrictions" में, केवल "Enable Spot & Margin Trading" चालू करें। "Enable Withdrawals" और "Enable Internal Transfer" unchecked रखें। Futures bots के लिए, "Enable Futures" भी चेक करें।
Bybit: Profile → API Management → Create New Key पर जाएं। Permissions में, केवल Spot के लिए "Read-Write" enable करें (या ज़रूरत होने पर Derivatives)। "Withdraw" toggle OFF ही रहना चाहिए।
OKX: Profile → API Keys → Create API Key पर जाएं। "Permissions" में, केवल "Trade" चुनें। OKX API authentication के लिए एक अतिरिक्त passphrase की आवश्यकता रखता है। इसे अपने password manager में key और secret के साथ स्टोर करें।
IP Whitelisting: Network-Level Access Control
IP whitelisting चोरी हुई API keys के खिलाफ सबसे प्रभावी सुरक्षा है। भले ही कोई attacker आपकी API key और secret हासिल कर ले, वह उनका उपयोग नहीं कर सकता। Exchange किसी भी ऐसे request को reject कर देता है जो whitelisted IP address से नहीं आता।
IP Whitelisting कैसे काम करती है
Your Bot Server (IP: 34.85.123.45) → Exchange API → ✅ Whitelisted → Order Executed
Attacker's Server (IP: 192.168.0.99) → Exchange API → ❌ Not Whitelisted → Request Rejected
Exchange हर API key के लिए IP addresses की एक allow-list रखता है। हर incoming API request का source IP इस list से चेक होता है, कोई भी action process होने से पहले। Non-whitelisted IPs से आने वाले requests authentication error के साथ reject हो जाते हैं, भले ही API key और signature valid हों।
यह क्यों ज़रूरी है
IP whitelisting के बिना, जिसके पास भी आपके API credentials हैं, वह दुनिया में कहीं से भी उनका उपयोग कर सकता है। IP whitelisting के साथ, attacker को आपके bot platform के server infrastructure को भी compromise करना होगा, जो कहीं ज़्यादा मुश्किल target है।
Platform-विशिष्ट Setup
Binance:
- API Management में, अपनी key चुनें और "Edit restrictions" पर क्लिक करें
- "IP access restrictions" में, "Restrict access to trusted IPs only" चुनें
- हर IP address अलग line पर दर्ज करें (Binance प्रति key 30 IPs तक support करता है)
- Save करें और 2FA verification पूरा करें
- नोट: Binance IP whitelist बदलने के बाद 5 मिनट की propagation delay लागू करता है
Bybit:
- API Management में, अपनी API key edit करें
- "IP Access" में, "Modify" पर क्लिक करें
- अपने platform के server IPs दर्ज करें (Bybit 20 IPs तक support करता है)
- IP restrictions के बिना keys Bybit पर 90 दिनों के बाद auto-expire हो जाती हैं
- Save करने के लिए 2FA verification पूरा करें
OKX:
- API management panel में अपनी API key edit करें
- "IP Address" field में IP addresses जोड़ें (OKX 20 IPs तक support करता है)
- OKX whitelisting की दृढ़ता से अनुशंसा करता है; unrestricted keys की rate limits कम होती हैं
- Save करें और 2FA से confirm करें
Freya Finance API key connection flow के दौरान अपने server IP addresses दिखाता है। इन्हें सीधे अपने exchange की IP whitelist में कॉपी करें। अगर platform के IPs बदलते हैं (दुर्लभ, आमतौर पर infrastructure migrations के दौरान), तो आपको नए addresses की notification मिलेगी।
सामान्य IP Whitelisting गलतियाँ
| गलती | परिणाम | समाधान |
|---|---|---|
| Bot server के IP की जगह अपना home IP डालना | Key आपके laptop से काम करती है पर bot से नहीं | Platform के प्रकाशित server IPs उपयोग करें |
0.0.0.0 या broad ranges whitelist करना | कोई असली सुरक्षा नहीं, कहीं से भी accept होता है | केवल specific IPs उपयोग करें |
| Platform migration के बाद अपडेट भूल जाना | Bot चुपचाप trading बंद कर देता है | Connection errors मॉनिटर करें, IPs अपडेट रखें |
| ऐसे VPN IPs जोड़ना जो rotate होते हैं | बीच-बीच में failures | Static IPs या platform के IPs उपयोग करें |
API Key Rotation: 90-दिन का Lifecycle
API keys को passwords की तरह समझना चाहिए: उनकी एक shelf life होती है। जितने लंबे समय तक एक key मौजूद रहती है, उतनी ज़्यादा संभावना है कि वह log files, support tickets, screenshots, या memory dumps के ज़रिए expose हो चुकी हो। पेशेवर operators एक निश्चित schedule पर keys rotate करते हैं।
अनुशंसित Rotation Cadence
| परिदृश्य | Rotation Frequency |
|---|---|
| सामान्य operations | हर 90 दिन |
| किसी भी संदिग्ध compromise के बाद | तुरंत |
| Platform security incident के बाद | तुरंत |
| किसी platform से access revoke करने के बाद | तुरंत |
| टीम सदस्य की विदाई के बाद | तुरंत |
Zero-Downtime Rotation प्रक्रिया
Key rotation से कभी trading में रुकावट नहीं आनी चाहिए। इस क्रम का पालन करें:
Step 1: Exchange पर नई API key बनाएं पुरानी key जैसी ही permissions और IP whitelist settings वाली नई key generate करें। इसे वर्तमान तारीख के साथ label करें (जैसे, "Freya Bot — May 2026")।
Step 2: अपने bot platform पर नई key अपडेट करें अपने bot platform की settings में नई API key और secret दर्ज करें। अधिकांश platforms bots बंद किए बिना credentials update करने की अनुमति देते हैं।
Step 3: Connectivity verify करें पुष्टि करें कि नई key काम कर रही है: जांचें कि platform successful connection दिखा रहा है, balances सही दिख रहे हैं, और एक test trade (अगर संभव हो) execute होता है।
Step 4: Exchange पर पुरानी key डिलीट करें नई key के काम करने की पुष्टि होने के बाद ही, अपने exchange के API management page से पुरानी key डिलीट करें।
Step 5: Rotation को document करें Rotation की तारीख, नई key का label, और successful switchover की पुष्टि record करें।
उस छोटी अवधि में जब पुरानी और नई दोनों keys मौजूद होती हैं (Steps 2–4), दोनों valid होती हैं। Zero-downtime rotation के लिए यह overlap ज़रूरी है और सुरक्षित है क्योंकि पुरानी key कुछ ही मिनटों में डिलीट कर दी जाती है। इस window को जितना संभव हो छोटा रखें।
Subaccount Isolation: Blast Radius को सीमित करना
Exchange subaccounts आपके main account के अंतर्गत अलग-अलग trading accounts होते हैं। हर subaccount का अपना balance, अपनी API keys, और अपनी trading history होती है। Cybersecurity में network segmentation जो करता है, subaccounts exchange में वही करते हैं।
Subaccounts क्यों महत्वपूर्ण हैं
इस परिदृश्य पर विचार करें: आप तीन bots चलाते हैं, एक BTC DCA bot, एक ETH DCA bot, और एक SOL signal bot, सभी आपके main account से जुड़े हैं जिसमें कुल $30,000 की capital है।
Subaccounts के बिना: एक compromised API key $30,000 को expose कर देती है। एक malfunctioning bot तेज़, बेतरतीब trades से पूरा balance drain कर सकता है।
Subaccounts के साथ: हर bot अपने subaccount में $10,000 के साथ operate करता है। एक compromised key केवल $10,000 को expose करती है। एक malfunctioning bot केवल अपनी allocated capital को प्रभावित कर सकता है। बाकी $20,000 अछूते रहते हैं।
Exchange के अनुसार Subaccount Setup
| Feature | Binance | Bybit | OKX |
|---|---|---|---|
| अधिकतम Subaccounts | 200 (VIP पर निर्भर) | 20 (standard) | 5 (standard), VIP के साथ अधिक |
| अलग API Keys | ✅ प्रति subaccount | ✅ प्रति subaccount | ✅ प्रति subaccount |
| अलग Balances | ✅ Isolated | ✅ Isolated | ✅ Isolated |
| Internal Transfer | ✅ Instant, free | ✅ Instant, free | ✅ Instant, free |
| अलग Trading History | ✅ पूर्ण isolation | ✅ पूर्ण isolation | ✅ पूर्ण isolation |
| KYC ज़रूरी | Main account KYC का उपयोग | Main account KYC का उपयोग | Main account KYC का उपयोग |
अनुशंसित Subaccount Architecture
तीन bots में $30,000 के portfolio के लिए:
Main Account (Master)
├── Subaccount A: BTC DCA Bot — $10,000
│ └── API Key A (spot trade + read, IP whitelisted)
├── Subaccount B: ETH Grid Bot — $10,000
│ └── API Key B (spot trade + read, IP whitelisted)
├── Subaccount C: SOL Momentum Bot — $10,000
│ └── API Key C (spot trade + read, IP whitelisted)
└── Reserve: $0 (main में रखा, ज़रूरत के अनुसार transfer)
हर subaccount की अपनी API key, अपनी IP whitelist होती है, और वह केवल अपने funds को access कर सकता है। Main account key, जिसमें कोई trading permissions नहीं हैं, ज़रूरत के अनुसार subaccounts के बीच fund transfers handle करती है।
जब Exchange Mid-Trade डाउन हो जाए
Exchange outages होते हैं। Binance, Bybit, और OKX सभी ने downtime का अनुभव किया है, कभी planned (maintenance), कभी unplanned (DDoS attacks, infrastructure failures, extreme market volatility के कारण load spikes)। आपके bot को इन स्थितियों को सुचारू रूप से handle करना चाहिए।
Outage के दौरान Open Orders
आपके लगाए हुए open limit orders exchange के order book पर बने रहते हैं भले ही API unreachable हो। Matching engine API gateway से अलग होता है। API outage के दौरान भी आपके orders fill हो सकते हैं।
इसका मतलब है: अगर आपने BTC के लिए $99,500 पर limit buy लगाया था और API डाउन हो गया, तो वह order अभी भी active है। अगर BTC $99,500 तक गिरता है, तो आपका order fill होगा भले ही आपका bot exchange से communicate नहीं कर पा रहा हो।
Bot Reconnection और State Reconciliation
जब API वापस ऑनलाइन आता है, तो एक अच्छी तरह से डिज़ाइन किए गए bot को अपनी internal state को exchange की actual state के साथ reconcile करना होता है। इस प्रक्रिया में शामिल है:
- सभी open orders की जांच: कौन से orders अभी भी active हैं, कौन fill हो गए, कौन partially fill हुए, और कौन cancel हो गए
- Internal records से तुलना: Exchange state को bot की expected state से match करें
- Discrepancies resolve करना: Actual fills के आधार पर internal positions अपडेट करें
- Normal operation फिर से शुरू करना: Reconciled state से strategy execution जारी रखें
Freya यह reconciliation आपके लिए automatically handle करता है। अगर आपके bot का exchange से connection टूट कर फिर जुड़ता है, तो Freya आपकी positions को exchange के खिलाफ re-check करता है और outage के दौरान हुई किसी भी drift को ठीक करता है, ताकि आपकी strategy सही state से resume हो।
Partial Fills
Partial fills तब होते हैं जब outage से पहले (या अपर्याप्त liquidity के कारण) आपके order का केवल एक हिस्सा execute होता है। उदाहरण:
- आप $100,000 पर 0.5 BTC का limit buy लगाते हैं ($50,000 order)
- API disconnect होने से पहले 0.3 BTC fill होता है ($30,000)
- जब bot reconnect करता है, तो उसे पता चलता है कि 0.3 BTC position में है और 0.2 BTC अभी भी open है
एक robust bot इसे इस तरह handle करता है:
- Partial fill पहचान कर position size अपडेट करना
- बाकी 0.2 BTC order active रखना है या cancel करना है, यह तय करना
- Actual position size (0.3 BTC, न कि intended 0.5 BTC) के आधार पर take-profit और stop-loss levels adjust करना
Exchange Outage के दौरान आपको क्या करना चाहिए
| स्थिति | कार्रवाई |
|---|---|
| Planned maintenance की घोषणा हो | Maintenance window से पहले bots pause करें; बाद में resume करें |
| Unexpected outage, कोई open positions नहीं | प्रतीक्षा करें, bot automatically reconnect करेगा |
| Unexpected outage, open positions हैं | Exchange status page मॉनिटर करें; panic-trade manually न करें |
| High volatility के दौरान outage | Exchange website (अगर accessible हो) से manual intervention पर विचार करें |
| Extended outage (>1 घंटा) | जब exchange वापस आए तो exchange app/website से positions review करें |
Rate Limiting: Exchange की सीमाओं का सम्मान
Exchanges अपने infrastructure को overload से बचाने के लिए rate limits लागू करते हैं। हर API call, हर order placement, हर balance check, हर market data request, आपके rate limit budget में गिनी जाती है।
Exchange Rate Limits
| Exchange | Request Limit | Window | Violation की सज़ा |
|---|---|---|---|
| Binance | 1,200 requests | प्रति मिनट | Temporary IP ban (2–10 min) |
| Binance (order-specific) | 10 orders/sec, 200,000/day | प्रति account | Order rejection, संभावित ban |
| Bybit | 120 requests | प्रति 5 seconds | Temporary IP ban |
| OKX | 60 requests/sec (endpoint के अनुसार अलग-अलग) | प्रति second | 429 status code, throttling |
Bots Rate Limits को कैसे Manage करते हैं
पेशेवर bots कई rate limit management techniques लागू करते हैं:
Request queuing: API calls तुरंत fire करने के बजाय, requests एक queue में प्रवेश करते हैं जो उन्हें controlled rate पर release करती है। Binance के लिए, इसका मतलब है 1,200/min limit से सुरक्षित दूरी बनाए रखने के लिए प्रति second 20 से अधिक requests नहीं।
Weight-based budgeting: कुछ exchanges (विशेष रूप से Binance) अलग-अलग endpoints को अलग-अलग "weights" assign करते हैं। एक साधारण balance check की cost 1 weight हो सकती है, जबकि एक complex order history query की cost 20। Bots cumulative weight track करते हैं ताकि cap तक न पहुंचें।
Exponential backoff: अगर bot को rate limit error (HTTP 429) मिलता है, तो वह retry करने से पहले progressively लंबा wait करता है: 1 second, फिर 2, फिर 4, फिर 8। यह retries के burst को स्थिति और खराब करने से रोकता है।
WebSocket over REST: Market data के लिए, WebSocket connections REST endpoints की polling से कहीं ज़्यादा efficient हैं। एक single WebSocket connection rate limit budget खर्च किए बिना real-time price updates प्रदान करता है। अच्छी तरह बने bots data के लिए WebSocket और केवल order management के लिए REST उपयोग करते हैं।
एक ही API key पर multiple bots चलाने से rate limit budget सभी bots में share होता है। अगर आप एक key पर 5 bots चला रहे हैं जो प्रत्येक 50 requests/sec बना रहे हैं, तो आप Binance की limit तुरंत hit कर लेंगे। Independent rate limits पाने के लिए प्रति bot अलग API keys (और आदर्श रूप से subaccounts) उपयोग करें।
Exchange Counterparty Risk: FTX का सबक
नवंबर 2022 में, FTX, दुनिया का तीसरा सबसे बड़ा crypto exchange, एक हफ्ते से भी कम समय में ध्वस्त हो गया। $8 billion ग्राहक funds गायब हो गए। जिन users की पूरी trading capital FTX पर थी, उन्होंने सब कुछ खो दिया, चाहे उनकी API keys कितनी भी सुरक्षित हों या उनके bots कितने भी अच्छा perform कर रहे हों।
सबक: अगर exchange खुद fail हो जाए तो आपकी API key security बेमतलब है।
Counterparty Risk के प्रकार
| जोखिम प्रकार | विवरण | ऐतिहासिक उदाहरण |
|---|---|---|
| Insolvency | Exchange के पास deposits कवर करने के लिए पर्याप्त assets नहीं | FTX (2022) |
| Regulatory seizure | सरकार exchange को बंद या freeze करती है | Bitzlato (2023) |
| Hack/breach | Exchange का hot wallet compromise | Mt. Gox (2014), Bitfinex (2016) |
| Withdrawal freeze | संकट के दौरान exchange withdrawals रोक देता है | Market crashes के दौरान कई exchanges |
| Technical failure | लंबा outage जिससे trading losses होते हैं | Extreme volatility के दौरान विभिन्न |
Multi-Exchange Diversification
समाधान सीधा है: अपनी पूरी trading capital कभी एक exchange पर न रखें। 2-3 प्रमुख, स्वतंत्र रूप से संचालित exchanges में बांटें।
$60,000 कुल capital के लिए उदाहरण allocation:
| Exchange | Allocation | चल रहे Bots |
|---|---|---|
| Binance | $25,000 (42%) | BTC DCA, ETH Grid |
| Bybit | $20,000 (33%) | SOL DCA, AVAX Momentum |
| OKX | $15,000 (25%) | BTC Grid, Multi-pair DCA |
अगर कोई एक exchange fail होता है, तो आप अधिकतम 42% capital खोते हैं, दर्दनाक लेकिन संभल सकने लायक। अगर आपकी $60,000 अकेले FTX पर होती, तो आप 100% खो देते।
Counterparty Risk के लिए क्या मॉनिटर करें
- Proof of Reserves रिपोर्ट्स: क्या ये नियमित रूप से प्रकाशित होती हैं? क्या प्रतिष्ठित firms उनका audit करती हैं?
- Withdrawal processing times: Withdrawals में अचानक देरी एक शुरुआती warning sign है
- Social media और news: Exchange executives का असामान्य व्यवहार, अप्रत्याशित corporate changes
- Regulatory developments: मुकदमे, regulatory actions, या प्रमुख बाज़ारों में license रद्दीकरण
- आपकी अपनी withdrawal capability: समय-समय पर withdrawals test करें ताकि आप verify कर सकें कि आपके funds accessible हैं
Exchanges पर केवल अपनी active trading capital रखें। Long-term holdings और reserves self-custody wallets (hardware wallets जैसे Ledger या Trezor) में रखें। एक उचित दिशानिर्देश: किसी भी समय अपने कुल crypto portfolio का 30–40% से अधिक exchanges पर न रखें।
Incident Response Checklist
जब कोई security incident होती है, या जब आपको इसका संदेह भी होता है, तो response की गति नतीजा तय करती है। इस checklist को क्रमवार follow करें:
Step 1: संदिग्ध API Key तुरंत Disable करें
Exchange में सीधे login करें (URL manually type करें, किसी link पर click न करें)। Compromised key को delete या disable करें। इसमें 30 seconds लगते हैं और सभी unauthorized access तुरंत बंद हो जाता है।
Step 2: सभी Open Orders जांचें और Cancel करें
Exchange पर हर open order review करें। जो आपने नहीं लगाया या जो पहचान में न आए, उसे cancel करें। सभी trading pairs जांचें, सिर्फ़ वे नहीं जो आपका bot उपयोग करता है, क्योंकि attacker ऐसे pairs trade कर सकता है जो आप कभी नहीं चुनेंगे।
Step 3: Withdrawal History Verify करें
पिछले 24–48 घंटों की withdrawal history जांचें। Verify करें कि हर withdrawal आपने authorize की थी। अगर unauthorized withdrawals दिखें, तो तुरंत exchange support से संपर्क करें और transaction hashes document करें।
Step 4: अपना Exchange Password बदलें
अपना password एक नए, randomly generated string में reset करें (अपना password manager उपयोग करें)। अगर attacker के पास broader account access था, तो पुराना password compromised है।
Step 5: IP Whitelist के साथ नई API Keys Generate करें
न्यूनतम आवश्यक permissions और strict IP whitelisting के साथ fresh API keys बनाएं। Compromised key की कोई भी setting reuse न करें।
Step 6: Bot Configuration अपडेट करें
अपने bot platform में नए API credentials दर्ज करें। Trading resume करने से पहले connectivity और सही operation verify करें।
Step 7: Access Logs का Audit करें
Review करें:
- अपरिचित IP addresses के लिए Exchange API access logs
- Unauthorized sessions के लिए Exchange login history
- Unauthorized access या forwarding rules के लिए Email account
- Unauthorized configuration changes के लिए Bot platform account
Step 8: Incident की Report करें
Exchange की आधिकारिक security team को अपने findings के साथ संपर्क करें। अगर funds चोरी हुए हैं, तो स्थानीय law enforcement और अपने देश की financial crime authority में report दर्ज करें।
Security Audit Checklist: हर Bot Operator को 10 Items Verify करने चाहिए
यह checklist हर महीने करें। हर item verify करने में एक मिनट से कम लगता है:
| # | Audit Item | Verify कैसे करें | ✅ / ❌ |
|---|---|---|---|
| 1 | सभी API keys पर withdrawal permissions disabled | Exchange API management page | |
| 2 | सभी API keys पर IP whitelisting enabled | Exchange API management page | |
| 3 | Exchange account पर 2FA enabled (authenticator app, SMS नहीं) | Exchange security settings | |
| 4 | Bot platform account पर 2FA enabled | Platform security settings | |
| 5 | API keys पिछले 90 दिनों में rotate हुई | Key creation dates जांचें | |
| 6 | Exchange पर anti-phishing code सेट | Exchange security settings | |
| 7 | कोई अनावश्यक API keys मौजूद नहीं (पुरानी/unused keys deleted) | Exchange API management page | |
| 8 | Subaccount balances intended allocation limits में | Exchange balance overview | |
| 9 | Exchange Proof of Reserves हाल ही में verify हुआ | Exchange transparency page | |
| 10 | Emergency response plan review किया (आप जानते हैं keys कहां revoke करनी हैं) | Mental walkthrough |
हर महीने की पहली तारीख पर इस checklist को करने के लिए calendar reminder सेट करें। इसमें 10 मिनट लगते हैं और यह configuration drift, भूली हुई पुरानी keys, और lapsed security settings को vulnerabilities बनने से पहले पकड़ लेती है।
सब कुछ एक साथ: Defense in Depth
कोई एक सुरक्षा उपाय पर्याप्त नहीं है। पेशेवर bot operators कई defenses layer करते हैं ताकि किसी एक layer की विफलता से breach न हो:
| Defense Layer | किससे बचाता है | Implementation |
|---|---|---|
| Permission scoping (no withdrawal) | Key compromise से कुल fund loss | Exchange API settings |
| IP whitelisting | चोरी हुई keys का remote use | Exchange API settings |
| Key rotation (90-day) | लंबे समय तक key exposure | Scheduled procedure |
| Subaccount isolation | Cross-bot contamination, blast radius | Exchange subaccount setup |
| 2FA (authenticator app) | Password चोरी से account takeover | Exchange + platform settings |
| Anti-phishing code | Email phishing attacks | Exchange security settings |
| Multi-exchange diversification | Exchange insolvency/failure | Portfolio architecture |
| Monthly security audit | Configuration drift, भूली हुई keys | Scheduled review |
हर layer स्वतंत्र है। अगर कोई attacker IP whitelisting bypass कर लेता है (bot server compromise करके), तो उसे अभी भी permission scoping (no withdrawals), subaccount isolation (सीमित capital exposure), और आपकी incident response प्रक्रिया का सामना करना होगा।
अक्सर पूछे जाने वाले प्रश्न
अगर मैं IP whitelisting लगाना भूल जाऊं तो क्या होगा?
IP whitelisting के बिना, आपकी API key दुनिया भर में किसी भी IP address से काम करती है। अगर कोई आपकी key प्राप्त कर लेता है (data breach, accidental exposure, या phishing के ज़रिए), तो वह अपने infrastructure से इसका उपयोग कर सकता है। Bybit पर, IP restrictions के बिना keys 90 दिनों के बाद auto-expire हो जाती हैं, जो एक safety net है। Binance और OKX पर, ये अनिश्चित काल तक active रहती हैं। अभी IP whitelisting जोड़ें; इसमें 2 मिनट लगते हैं।
क्या मैं एक ही API key multiple bots के लिए उपयोग कर सकता हूं?
तकनीकी रूप से हां, लेकिन यह खराब practice है। एक key share करने वाले multiple bots rate limits भी share करते हैं, जिससे rate limit violations trigger करना आसान हो जाता है। इसका यह भी मतलब है कि आप एक bot का access revoke नहीं कर सकते बिना बाकी सभी को प्रभावित किए। प्रति bot एक API key उपयोग करें (आदर्श रूप से अलग subaccounts के साथ)।
मुझे कैसे पता चलेगा कि मेरी API key compromise हुई है?
चेतावनी के संकेतों में शामिल हैं: आपकी history में ऐसे trades जो आपने authorize नहीं किए, अप्रत्याशित balance changes, जब आपके bots idle हों तब rate limit errors (जो बताते हैं कि कोई और आपकी key उपयोग कर रहा है), या अपरिचित IPs से login alerts। अगर इनमें से कुछ भी दिखे, तो तुरंत key delete करें और incident response checklist follow करें।
अगर exchange अपनी IP whitelisting requirements बदल दे तो?
Exchanges कभी-कभार अपने IP whitelisting systems अपडेट करते हैं। आपको आमतौर पर email notification मिलेगी। अगर आपका bot अचानक trades execute करना बंद कर दे, तो जांचें कि exchange ने अपनी API authentication requirements बदली हैं या नहीं। यह दुर्लभ है, क्योंकि प्रमुख exchanges backward compatibility का लक्ष्य रखते हैं, लेकिन मॉनिटर करना उचित है।
क्या मुझे subaccounts उपयोग करने चाहिए अगर मैं सिर्फ़ एक bot चलाता हूं?
हां। Subaccount आपके bot की trading capital और आपके reserve funds के बीच एक स्पष्ट सीमा बनाता है। एक bot के साथ भी, subaccount यह सुनिश्चित करता है कि एक malfunctioning bot (या आपकी strategy में कोई bug) केवल उसे स्पष्ट रूप से allocated capital को ही प्रभावित कर सकता है। इसे setup करने में कोई खर्च नहीं और यह सार्थक सुरक्षा जोड़ता है।
Rate limit violations मेरी trading को कैसे प्रभावित करते हैं?
Rate limit violation का नतीजा API requests की temporary rejection होती है। Ban period (आमतौर पर 2–10 मिनट) के दौरान, आपका bot orders नहीं लगा सकता, balances check नहीं कर सकता, या positions manage नहीं कर सकता। Volatile market में, 5 मिनट के लिए भी locked out होने का मतलब stop-loss trigger या profitable entry miss करना हो सकता है। सही rate limit management वैकल्पिक नहीं है, यह विश्वसनीय bot operation के लिए अनिवार्य है।
क्या multi-exchange diversification जटिलता के लायक है?
बिल्कुल। 2-3 exchanges पर bots manage करने में थोड़ा ज़्यादा प्रशासनिक प्रयास लगता है, लेकिन जोखिम में कमी बहुत बड़ी है। FTX के पतन ने उन traders को बर्बाद कर दिया जिन्होंने अपनी capital एक ही platform पर केंद्रित की थी। Diversification एक ऐसी घटना से बचाता है जिसे कोई भी API key security या IP whitelisting नहीं रोक सकती: exchange का खुद fail होना।