ความปลอดภัยของ Exchange API และการลดความเสี่ยง: การปกป้องโครงสร้างพื้นฐานของ Trading Bot

Trading bot ของคุณทำงานผ่านอินเทอร์เฟซเดียว นั่นคือ exchange API ทุกคำสั่งซื้อ ทุกการตรวจสอบยอดคงเหลือ ทุกการสอบถามตำแหน่ง ล้วนไหลผ่าน API credential ที่คุณสร้างขึ้น หากข้อมูลรับรองเหล่านี้ถูกตั้งค่าผิด ถูกขโมย หรือถูกเข้าใจผิด ผลที่ตามมามีตั้งแต่การเทรดที่ไม่ได้รับอนุญาตไปจนถึงการถูกถ่ายเงินออกจากบัญชีทั้งหมด

คู่มือนี้ก้าวข้ามสุขลักษณะความปลอดภัยขั้นพื้นฐาน ( ครอบคลุมใน คู่มือความปลอดภัยพื้นฐานของเรา ) และเจาะลึกเข้าสู่กรอบความปลอดภัยเชิงปฏิบัติการที่แยกผู้ปฏิบัติงานบอทมืออาชีพออกจากมือสมัครเล่น เราครอบคลุมสถาปัตยกรรมสิทธิ์ การควบคุมการเข้าถึงระดับเครือข่าย การจัดการวงจรชีวิตของข้อมูลรับรอง การจัดการความล้มเหลวของ exchange และคู่มือการตอบสนองต่อเหตุการณ์ฉบับสมบูรณ์

ระดับสิทธิ์ของ API Key: หลักการให้สิทธิ์น้อยที่สุด

ทุก exchange รายใหญ่มีระบบสิทธิ์ที่ละเอียดสำหรับ API key หลักการนั้นง่ายมาก: ให้สิทธิ์ที่บอทต้องการอย่างแม่นยำเท่านั้น ไม่ให้มากไปกว่านั้น นี่คือสิ่งที่แต่ละระดับควบคุม

สถาปัตยกรรมสิทธิ์

ทำไมสิทธิ์ Withdrawal จึงเป็น Kill Switch

เมื่อปิด withdrawal ไว้ สถานการณ์เลวร้ายที่สุดจาก API key ที่ถูกขโมยคือสิ่งนี้: ผู้โจมตีวางคำสั่งเทรดที่ไม่ดี เงินทุนของคุณได้รับความเสียหาย แต่ยังคงอยู่บน exchange คุณสามารถกู้คืนได้

เมื่อเปิด withdrawal ไว้ กรณีเลวร้ายที่สุดคือการสูญเสียทั้งหมด ผู้โจมตีถ่ายเงินจากบัญชีของคุณไปยังกระเป๋าของพวกเขาภายในไม่กี่วินาที ธุรกรรมคริปโตไม่สามารถย้อนกลับได้ ไม่มีการคืนเงิน ไม่มีการกู้คืน

คณิตศาสตร์นั้นชัดเจน สมมติว่าคุณมี $50,000 บน Binance:

• ปิด withdrawal, คีย์ถูกขโมย: ผู้โจมตีวางคำสั่งเทรดแบบไม่แน่นอน ความสูญเสียตามจริง: $2,000–$10,000 จาก slippage และการเติมคำสั่งที่ไม่ดีก่อนที่คุณจะสังเกตเห็นและเพิกถอนคีย์ เงินทุนที่เหลือ: $40,000–$48,000
• เปิด withdrawal, คีย์ถูกขโมย: ผู้โจมตีส่ง $50,000 ไปยังกระเป๋าของพวกเขา เงินทุนที่เหลือ: $0

การตั้งค่าสิทธิ์เฉพาะของแต่ละ Exchange

Binance: ไปที่ Account → API Management → Create API ภายใต้ "API restrictions" ให้เปิดใช้งานเฉพาะ "Enable Spot & Margin Trading" ปล่อยให้ "Enable Withdrawals" และ "Enable Internal Transfer" ไม่ถูกเลือก สำหรับบอท futures ให้เลือก "Enable Futures" ด้วย

Bybit: ไปที่ Profile → API Management → Create New Key ภายใต้สิทธิ์ ให้เปิดใช้งาน "Read-Write" สำหรับ Spot เท่านั้น (หรือ Derivatives หากจำเป็น) ปุ่มสลับ "Withdraw" ต้องคงอยู่ในสถานะ OFF

OKX: ไปที่ Profile → API Keys → Create API Key ภายใต้ "Permissions" ให้เลือก "Trade" เท่านั้น OKX ต้องการ passphrase เพิ่มเติมสำหรับการยืนยันตัวตน API — เก็บสิ่งนี้ไว้ใน password manager ของคุณพร้อมกับคีย์และ secret

IP Whitelist: การควบคุมการเข้าถึงระดับเครือข่าย

IP whitelist เป็นการป้องกัน API key ที่ถูกขโมยที่มีประสิทธิภาพที่สุดเพียงหนึ่งเดียว แม้ผู้โจมตีจะได้ API key และ secret ของคุณ พวกเขาก็ไม่สามารถใช้ได้ — exchange ปฏิเสธคำขอใดๆ ที่ไม่ได้มาจาก IP address ที่อยู่ใน whitelist

IP Whitelist ทำงานอย่างไร

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 จะรักษารายการอนุญาตของ IP address สำหรับแต่ละ API key คำขอ API ขาเข้าทุกรายการจะมีการตรวจสอบ source IP กับรายการนี้ก่อนที่จะประมวลผลการกระทำใดๆ คำขอจาก IP ที่ไม่ได้อยู่ใน whitelist จะถูกปฏิเสธด้วยข้อผิดพลาดการยืนยันตัวตน ไม่ว่า API key และลายเซ็นจะถูกต้องหรือไม่ก็ตาม

ทำไมจึงต่อรองไม่ได้

หากไม่มี IP whitelist ใครก็ตามที่ได้ข้อมูล API ของคุณสามารถใช้ได้จากที่ใดก็ได้ทั่วโลก ด้วย IP whitelist ผู้โจมตีจะต้องเจาะระบบโครงสร้างพื้นฐานเซิร์ฟเวอร์ของแพลตฟอร์มบอทของคุณเพิ่มเติมด้วย — เป้าหมายที่ยากกว่าอย่างมาก

การตั้งค่าเฉพาะของแต่ละแพลตฟอร์ม

Binance:

1. ใน API Management ให้เลือกคีย์ของคุณแล้วคลิก "Edit restrictions"
2. ภายใต้ "IP access restrictions" ให้เลือก "Restrict access to trusted IPs only"
3. ป้อน IP address แต่ละรายการในบรรทัดแยกกัน (Binance รองรับสูงสุด 30 IP ต่อคีย์)
4. บันทึกและดำเนินการยืนยัน 2FA ให้เสร็จสมบูรณ์
5. หมายเหตุ: Binance บังคับใช้ความล่าช้าในการแพร่กระจาย 5 นาทีหลังจากการเปลี่ยนแปลง IP whitelist

Bybit:

1. ใน API Management ให้แก้ไข API key ของคุณ
2. ภายใต้ "IP Access" ให้คลิก "Modify"
3. ป้อน IP เซิร์ฟเวอร์ของแพลตฟอร์มของคุณ (Bybit รองรับสูงสุด 20 IP)
4. คีย์ที่ไม่มีการจำกัด IP จะหมดอายุอัตโนมัติหลังจาก 90 วันบน Bybit
5. ดำเนินการยืนยัน 2FA ให้เสร็จสมบูรณ์เพื่อบันทึก

OKX:

1. แก้ไข API key ของคุณในแผง API management
2. เพิ่ม IP address ในช่อง "IP Address" (OKX รองรับสูงสุด 20 IP)
3. OKX แนะนำอย่างยิ่งให้ทำ whitelist — คีย์ที่ไม่ถูกจำกัดมี rate limit ที่ต่ำกว่า
4. บันทึกและยืนยันด้วย 2FA

ข้อผิดพลาดที่พบบ่อยเกี่ยวกับ IP Whitelist

การหมุนเวียน API Key: วงจรชีวิต 90 วัน

ควรปฏิบัติต่อ API key เหมือนรหัสผ่าน: พวกมันมีอายุการใช้งาน ยิ่งคีย์มีอยู่นานเท่าใด ความน่าจะเป็นที่มันจะถูกเปิดเผยผ่านไฟล์ log, ใบสนับสนุน, ภาพหน้าจอ หรือ memory dump ก็ยิ่งสูงขึ้น ผู้ปฏิบัติงานมืออาชีพหมุนเวียนคีย์ตามตารางเวลาที่กำหนดไว้

ความถี่ในการหมุนเวียนที่แนะนำ

ขั้นตอนการหมุนเวียนแบบไม่มี Downtime

การหมุนเวียนคีย์ไม่ควรทำให้การเทรดหยุดชะงัก ทำตามลำดับนี้:

ขั้นตอนที่ 1: สร้าง API key ใหม่บน exchange สร้างคีย์ใหม่ที่มีสิทธิ์และการตั้งค่า IP whitelist เหมือนกับคีย์เก่า ติดป้ายกำกับด้วยวันที่ปัจจุบัน (เช่น "Freya Bot — May 2026")

ขั้นตอนที่ 2: อัปเดตแพลตฟอร์มบอทของคุณด้วยคีย์ใหม่ ป้อน API key และ secret ใหม่ในการตั้งค่าของแพลตฟอร์มบอทของคุณ แพลตฟอร์มส่วนใหญ่อนุญาตให้อัปเดตข้อมูลรับรองได้โดยไม่ต้องหยุดบอท

ขั้นตอนที่ 3: ตรวจสอบการเชื่อมต่อ ยืนยันว่าคีย์ใหม่ทำงานได้: ตรวจสอบว่าแพลตฟอร์มแสดงการเชื่อมต่อที่สำเร็จ ยอดคงเหลือแสดงอย่างถูกต้อง และการเทรดทดสอบ (หากทำได้) ดำเนินการ

ขั้นตอนที่ 4: ลบคีย์เก่าบน exchange หลังจากตรวจสอบว่าคีย์ใหม่ทำงานได้แล้วเท่านั้น จึงลบคีย์เก่าออกจากหน้า API management ของ exchange ของคุณ

ขั้นตอนที่ 5: บันทึกการหมุนเวียน บันทึกวันที่หมุนเวียน ป้ายกำกับคีย์ใหม่ และการยืนยันการเปลี่ยนที่สำเร็จ

การแยก Subaccount: การจำกัดรัศมีความเสียหาย

Subaccount ของ exchange เป็นบัญชีเทรดแยกต่างหากภายใต้บัญชีหลักของคุณ แต่ละ subaccount มียอดคงเหลือของตัวเอง มี API key ของตัวเอง และมีประวัติการเทรดของตัวเอง พวกมันเทียบเท่ากับ network segmentation ในด้าน cybersecurity บน exchange

ทำไม Subaccount จึงสำคัญ

ลองพิจารณาสถานการณ์นี้: คุณรันบอทสามตัว — บอท BTC DCA, บอท ETH Grid และบอท SOL momentum — ทั้งหมดเชื่อมต่อกับบัญชีหลักของคุณที่มีเงินทุนรวม $30,000

โดยไม่มี subaccount: API key ที่ถูกขโมยหนึ่งคีย์เปิดเผย $30,000 บอทที่ทำงานผิดปกติสามารถถ่ายยอดคงเหลือทั้งหมดผ่านการเทรดที่รวดเร็วและไม่แน่นอน

ด้วย subaccount: แต่ละบอทดำเนินการใน subaccount ของตัวเองด้วย $10,000 คีย์ที่ถูกขโมยเปิดเผยเพียง $10,000 บอทที่ทำงานผิดปกติส่งผลกระทบได้เฉพาะเงินทุนที่จัดสรรให้ อีก $20,000 แตะต้องไม่ได้

การตั้งค่า Subaccount แยกตาม Exchange

สถาปัตยกรรม Subaccount ที่แนะนำ

สำหรับพอร์ตโฟลิโอ $30,000 กระจายไปยังบอทสามตัว:

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 (held in main, transferred as needed)

แต่ละ subaccount มี API key ของตัวเอง มี IP whitelist ของตัวเอง และสามารถเข้าถึงได้เฉพาะเงินทุนของตัวเอง คีย์ของบัญชีหลัก — ซึ่งไม่มีสิทธิ์เทรด — จัดการการโอนเงินระหว่าง subaccount ตามที่จำเป็น

เมื่อ Exchange ล่มกลางการเทรด

การหยุดทำงานของ exchange เกิดขึ้นได้ Binance, Bybit และ OKX ล้วนเคยประสบ downtime — บางครั้งวางแผนไว้ (การบำรุงรักษา) บางครั้งไม่ได้วางแผน (การโจมตี DDoS, ความล้มเหลวของโครงสร้างพื้นฐาน, ความผันผวนของตลาดที่รุนแรงทำให้เกิดภาระงานพุ่งสูง) บอทของคุณต้องจัดการสิ่งเหล่านี้อย่างนุ่มนวล

คำสั่งซื้อที่เปิดอยู่ในระหว่างการหยุดทำงาน

คำสั่ง limit ที่เปิดอยู่ที่คุณวางไว้ คงอยู่บน order book ของ exchange แม้เมื่อ API ไม่สามารถเข้าถึงได้ matching engine แยกออกจาก API gateway คำสั่งของคุณสามารถดำเนินการเติมต่อไปได้ในระหว่างที่ API หยุดทำงาน

นี่หมายความว่า: หากคุณมีคำสั่ง limit buy ที่ $99,500 สำหรับ BTC และ API ล่ม คำสั่งนั้นยังคงทำงานอยู่ หาก BTC ลดลงเหลือ $99,500 คุณจะได้รับการเติมแม้ว่าบอทของคุณจะไม่สามารถสื่อสารกับ exchange ได้

การเชื่อมต่อบอทใหม่และการกระทบยอดสถานะ

เมื่อ API กลับมาออนไลน์ บอทที่ออกแบบมาอย่างดีต้องกระทบยอดสถานะภายในของมันกับสถานะจริงของ exchange กระบวนการนี้เกี่ยวข้องกับ:

1. สอบถามคำสั่งซื้อที่เปิดอยู่ทั้งหมด — ตรวจสอบว่าคำสั่งใดยังคงทำงานอยู่ คำสั่งใดถูกเติมแล้ว คำสั่งใดถูกเติมบางส่วน และคำสั่งใดถูกยกเลิก
2. เปรียบเทียบกับบันทึกภายใน — จับคู่สถานะของ exchange กับสิ่งที่บอทคาดหวัง
3. แก้ไขความไม่สอดคล้อง — อัปเดตตำแหน่งภายในตามการเติมจริง
4. กลับสู่การดำเนินงานปกติ — ดำเนินการกลยุทธ์ต่อจากสถานะที่กระทบยอดแล้ว

การเติมบางส่วน

การเติมบางส่วนเกิดขึ้นเมื่อมีเพียงส่วนหนึ่งของคำสั่งของคุณที่ดำเนินการก่อนการหยุดทำงาน (หรือเนื่องจาก liquidity ไม่เพียงพอ) ตัวอย่าง:

• คุณวางคำสั่ง limit buy สำหรับ 0.5 BTC ที่ $100,000 (คำสั่ง $50,000)
• 0.3 BTC ถูกเติมก่อนที่ API จะหลุดการเชื่อมต่อ ($30,000)
• เมื่อบอทเชื่อมต่อใหม่ มันพบ 0.3 BTC ในตำแหน่งและ 0.2 BTC ที่ยังคงเปิดอยู่

บอทที่แข็งแกร่งจัดการสิ่งนี้โดย:

• รับรู้การเติมบางส่วนและอัปเดตขนาดตำแหน่ง
• ตัดสินใจว่าจะคงคำสั่ง 0.2 BTC ที่เหลือไว้ให้ทำงานอยู่หรือยกเลิก
• ปรับระดับ take-profit และ stop-loss ตามขนาดตำแหน่งจริง (0.3 BTC ไม่ใช่ 0.5 BTC ที่ตั้งใจไว้)

สิ่งที่คุณควรทำในระหว่างที่ Exchange หยุดทำงาน

Rate Limiting: การเคารพขอบเขตของ Exchange

Exchange บังคับใช้ rate limit เพื่อปกป้องโครงสร้างพื้นฐานของพวกเขาจากการถูกใช้งานมากเกินไป ทุกการเรียก API — ทุกการวางคำสั่ง ทุกการตรวจสอบยอดคงเหลือ ทุกคำขอข้อมูลตลาด — นับรวมเข้าในงบประมาณ rate limit ของคุณ

Rate Limit ของ Exchange

บอทจัดการ Rate Limit อย่างไร

บอทมืออาชีพใช้เทคนิคการจัดการ rate limit หลายอย่าง:

การจัดคิวคำขอ: แทนที่จะยิงการเรียก API ทันที คำขอจะเข้าสู่คิวที่ปล่อยออกมาในอัตราที่ควบคุมได้ สำหรับ Binance นั่นหมายถึงไม่เกิน 20 คำขอต่อวินาที เพื่อให้อยู่ต่ำกว่าขีดจำกัด 1,200/นาทีอย่างปลอดภัย

การจัดงบประมาณตามน้ำหนัก: Exchange บางแห่ง (โดยเฉพาะ Binance) กำหนด "น้ำหนัก" ที่แตกต่างกันให้กับ endpoint ที่แตกต่างกัน การตรวจสอบยอดคงเหลืออย่างง่ายอาจมีต้นทุน 1 น้ำหนัก ในขณะที่การสอบถามประวัติคำสั่งที่ซับซ้อนมีต้นทุน 20 บอทติดตามน้ำหนักสะสมเพื่อหลีกเลี่ยงการชนเพดาน

Exponential backoff: หากบอทได้รับข้อผิดพลาด rate limit (HTTP 429) มันจะรอนานขึ้นเรื่อยๆ ก่อนที่จะลองใหม่: 1 วินาที จากนั้น 2 จากนั้น 4 จากนั้น 8 สิ่งนี้ป้องกันไม่ให้การลองใหม่จำนวนมากทำให้สถานการณ์แย่ลง

WebSocket แทน REST: สำหรับข้อมูลตลาด การเชื่อมต่อ WebSocket มีประสิทธิภาพมากกว่าการ polling endpoint REST อย่างมาก การเชื่อมต่อ WebSocket เดียวให้การอัปเดตราคาแบบเรียลไทม์โดยไม่บริโภคงบประมาณ rate limit บอทที่สร้างมาดีใช้ WebSocket สำหรับข้อมูลและใช้ REST เฉพาะสำหรับการจัดการคำสั่งเท่านั้น

ความเสี่ยงของคู่สัญญา Exchange: บทเรียนจาก FTX

ในเดือนพฤศจิกายน 2022 FTX — exchange คริปโตที่ใหญ่เป็นอันดับสามของโลก — ล่มสลายในเวลาไม่ถึงหนึ่งสัปดาห์ เงินทุนของลูกค้ามูลค่า 8 พันล้านดอลลาร์หายวับไป ผู้ใช้ที่นำเงินทุนการเทรดทั้งหมดไว้บน FTX สูญเสียทุกอย่าง ไม่ว่า API key ของพวกเขาจะปลอดภัยเพียงใดหรือบอทของพวกเขาจะทำงานได้ดีเพียงใดก็ตาม

บทเรียน: ความปลอดภัยของ API key ของคุณไม่มีความหมายหาก exchange เองล้มเหลว

ประเภทของความเสี่ยงคู่สัญญา

การกระจายความเสี่ยงหลาย Exchange

การลดความเสี่ยงนั้นตรงไปตรงมา: อย่าเก็บเงินทุนการเทรดทั้งหมดของคุณไว้บน exchange เดียว กระจายไปยัง exchange รายใหญ่ที่ดำเนินงานอย่างเป็นอิสระ 2–3 แห่ง

ตัวอย่างการจัดสรรสำหรับเงินทุนรวม $60,000:

หาก exchange ใด exchange หนึ่งล้มเหลว คุณจะสูญเสียเงินทุนมากที่สุด 42% — เจ็บปวดแต่ยังเอาตัวรอดได้ หากคุณมี $60,000 บน FTX เพียงแห่งเดียว คุณจะสูญเสีย 100%

สิ่งที่ต้องตรวจสอบสำหรับความเสี่ยงคู่สัญญา

• รายงาน Proof of Reserves — มีการเผยแพร่อย่างสม่ำเสมอหรือไม่ ได้รับการตรวจสอบโดยบริษัทที่มีชื่อเสียงหรือไม่
• เวลาในการประมวลผล withdrawal — ความล่าช้าที่เกิดขึ้นอย่างกะทันหันในการ withdrawal เป็นสัญญาณเตือนแต่เนิ่นๆ
• โซเชียลมีเดียและข่าว — ผู้บริหารของ exchange มีพฤติกรรมแปลกๆ, การเปลี่ยนแปลงองค์กรที่ผิดปกติ
• พัฒนาการด้านกฎระเบียบ — คดีความ, การดำเนินการของหน่วยงานกำกับดูแล หรือการเพิกถอนใบอนุญาตในตลาดสำคัญ
• ความสามารถในการ withdrawal ของคุณเอง — ทดสอบ withdrawal เป็นระยะเพื่อยืนยันว่าคุณสามารถเข้าถึงเงินทุนของคุณได้

รายการตรวจสอบการตอบสนองต่อเหตุการณ์

เมื่อเหตุการณ์ความปลอดภัยเกิดขึ้น — หรือแม้เมื่อคุณสงสัยว่าเกิดขึ้น — ความเร็วในการตอบสนองเป็นตัวกำหนดผลลัพธ์ ทำตามรายการตรวจสอบนี้ตามลำดับ:

ขั้นตอนที่ 1: ปิดใช้งาน API Key ที่ต้องสงสัยทันที

ล็อกอินเข้า exchange โดยตรง (พิมพ์ URL ด้วยตนเอง อย่าคลิกลิงก์ใดๆ) ลบหรือปิดใช้งานคีย์ที่ถูกขโมย สิ่งนี้ใช้เวลา 30 วินาทีและตัดการเข้าถึงที่ไม่ได้รับอนุญาตทั้งหมดทันที

ขั้นตอนที่ 2: ตรวจสอบและยกเลิกคำสั่งซื้อที่เปิดอยู่ทั้งหมด

ตรวจทานคำสั่งซื้อที่เปิดอยู่ทุกรายการบน exchange ยกเลิกสิ่งใดก็ตามที่คุณไม่ได้วางหรือไม่รู้จัก ตรวจสอบคู่เทรดทั้งหมด ไม่ใช่แค่คู่ที่บอทของคุณใช้ — ผู้โจมตีอาจเทรดคู่ที่คุณจะไม่มีวันเลือก

ขั้นตอนที่ 3: ตรวจสอบประวัติ Withdrawal

ตรวจสอบประวัติ withdrawal 24–48 ชั่วโมงล่าสุด ยืนยันว่าทุกการ withdrawal ได้รับอนุญาตจากคุณ หากคุณเห็น withdrawal ที่ไม่ได้รับอนุญาต ให้ติดต่อฝ่ายสนับสนุนของ exchange ทันทีและบันทึก transaction hash

ขั้นตอนที่ 4: เปลี่ยนรหัสผ่าน Exchange ของคุณ

รีเซ็ตรหัสผ่านของคุณเป็นสตริงที่สร้างขึ้นแบบสุ่มใหม่ (ใช้ password manager ของคุณ) หากผู้โจมตีมีการเข้าถึงบัญชีที่กว้างขึ้น รหัสผ่านเก่าก็ถูกขโมยแล้ว

ขั้นตอนที่ 5: สร้าง API Key ใหม่ด้วย IP Whitelist

สร้าง API key ใหม่ด้วยสิทธิ์ขั้นต่ำที่จำเป็นและ IP whitelist ที่เข้มงวด อย่านำการตั้งค่าใดๆ จากคีย์ที่ถูกขโมยมาใช้ซ้ำ

ขั้นตอนที่ 6: อัปเดตการตั้งค่าบอท

ป้อนข้อมูลรับรอง API ใหม่ในแพลตฟอร์มบอทของคุณ ตรวจสอบการเชื่อมต่อและการทำงานที่ถูกต้องก่อนกลับมาเทรดต่อ

ขั้นตอนที่ 7: ตรวจสอบ Access Log

ตรวจทาน:

• log การเข้าถึง API ของ exchange เพื่อหา IP address ที่ไม่คุ้นเคย
• ประวัติการล็อกอินของ exchange เพื่อหาเซสชันที่ไม่ได้รับอนุญาต
• บัญชีอีเมลเพื่อหาการเข้าถึงหรือกฎการส่งต่อที่ไม่ได้รับอนุญาต
• บัญชีแพลตฟอร์มบอทเพื่อหาการเปลี่ยนแปลงการตั้งค่าที่ไม่ได้รับอนุญาต

ขั้นตอนที่ 8: รายงานเหตุการณ์

ติดต่อทีมความปลอดภัยอย่างเป็นทางการของ exchange พร้อมสิ่งที่คุณค้นพบ หากเงินทุนถูกขโมย ให้แจ้งความกับหน่วยงานบังคับใช้กฎหมายในพื้นที่และหน่วยงานปราบปรามอาชญากรรมทางการเงินของประเทศคุณ

รายการตรวจสอบการตรวจสอบความปลอดภัย: 10 รายการที่ผู้ปฏิบัติงานบอททุกคนต้องยืนยัน

ทำตามรายการตรวจสอบนี้ทุกเดือน แต่ละรายการใช้เวลายืนยันไม่ถึงหนึ่งนาที:

รวมทุกอย่างเข้าด้วยกัน: Defense in Depth

ไม่มีมาตรการความปลอดภัยเดียวที่เพียงพอ ผู้ปฏิบัติงานบอทมืออาชีพจัดวางการป้องกันหลายชั้นเพื่อให้ความล้มเหลวของชั้นใดชั้นหนึ่งไม่ส่งผลให้เกิดการละเมิด:

แต่ละชั้นเป็นอิสระต่อกัน หากผู้โจมตีข้าม IP whitelist ได้ (โดยการเจาะเซิร์ฟเวอร์บอท) พวกเขายังคงต้องเผชิญกับการจำกัดขอบเขตสิทธิ์ (ไม่มี withdrawal), การแยก subaccount (การเปิดเผยเงินทุนที่จำกัด) และขั้นตอนการตอบสนองต่อเหตุการณ์ของคุณ

คำถามที่พบบ่อย

จะเกิดอะไรขึ้นหากฉันลืมเพิ่ม IP whitelist?

หากไม่มี IP whitelist API key ของคุณทำงานจาก IP address ใดก็ได้ทั่วโลก หากมีคนได้คีย์ของคุณ (ผ่านการละเมิดข้อมูล, การเปิดเผยโดยไม่ตั้งใจ หรือ phishing) พวกเขาสามารถใช้จากโครงสร้างพื้นฐานของพวกเขาเองได้ บน Bybit คีย์ที่ไม่มีการจำกัด IP จะหมดอายุอัตโนมัติหลังจาก 90 วัน — เป็นตาข่ายนิรภัย บน Binance และ OKX คีย์จะยังคงทำงานอยู่อย่างไม่มีกำหนด เพิ่ม IP whitelist ตอนนี้; ใช้เวลา 2 นาที

ฉันสามารถใช้ API key เดียวกันสำหรับบอทหลายตัวได้หรือไม่?

ในทางเทคนิคได้ แต่เป็นวิธีปฏิบัติที่ไม่ดี บอทหลายตัวที่ใช้คีย์เดียวกันจะแบ่งปัน rate limit ทำให้ง่ายต่อการกระตุ้นการละเมิด rate limit นอกจากนี้ยังหมายความว่าคุณไม่สามารถเพิกถอนการเข้าถึงสำหรับบอทตัวหนึ่งโดยไม่ส่งผลกระทบต่อบอททั้งหมด ใช้ API key หนึ่งคีย์ต่อบอท (ในอุดมคติคือใช้ subaccount แยกต่างหาก)

ฉันจะรู้ได้อย่างไรว่า API key ของฉันถูกขโมย?

สัญญาณเตือนรวมถึง: การเทรดที่คุณไม่ได้อนุญาตปรากฏในประวัติของคุณ, การเปลี่ยนแปลงยอดคงเหลือที่ไม่คาดคิด, ข้อผิดพลาด rate limit เมื่อบอทของคุณอยู่เฉยๆ (บ่งชี้ว่ามีคนอื่นใช้คีย์ของคุณ) หรือการแจ้งเตือนการล็อกอินจาก IP ที่ไม่คุ้นเคย หากคุณเห็นสิ่งใดสิ่งหนึ่งเหล่านี้ ให้ลบคีย์ทันทีและทำตามรายการตรวจสอบการตอบสนองต่อเหตุการณ์

จะเกิดอะไรขึ้นหาก exchange เปลี่ยนข้อกำหนด IP whitelist?

Exchange อัปเดตระบบ IP whitelist ของพวกเขาเป็นครั้งคราว โดยทั่วไปคุณจะได้รับการแจ้งเตือนทางอีเมล หากบอทของคุณหยุดดำเนินการเทรดอย่างกะทันหัน ให้ตรวจสอบว่า exchange ได้เปลี่ยนข้อกำหนดการยืนยันตัวตน API หรือไม่ สิ่งนี้เกิดขึ้นได้ยาก — exchange รายใหญ่มุ่งเน้นความเข้ากันได้แบบย้อนหลัง — แต่ก็คุ้มค่าที่จะติดตาม

ฉันควรใช้ subaccount แม้ว่าจะรันบอทเพียงตัวเดียวหรือไม่?

ใช่ Subaccount สร้างขอบเขตที่ชัดเจนระหว่างเงินทุนการเทรดของบอทของคุณกับเงินสำรองของคุณ แม้จะมีบอทเพียงตัวเดียว subaccount ก็รับประกันว่าบอทที่ทำงานผิดปกติ (หรือบั๊กในกลยุทธ์ของคุณ) จะส่งผลกระทบได้เฉพาะเงินทุนที่จัดสรรให้อย่างชัดเจนเท่านั้น การตั้งค่าไม่มีค่าใช้จ่ายและเพิ่มการป้องกันที่มีความหมาย

การละเมิด rate limit ส่งผลต่อการเทรดของฉันอย่างไร?

การละเมิด rate limit ส่งผลให้มีการปฏิเสธคำขอ API ชั่วคราว ในระหว่างช่วงแบน (โดยทั่วไป 2–10 นาที) บอทของคุณไม่สามารถวางคำสั่ง ตรวจสอบยอดคงเหลือ หรือจัดการตำแหน่งได้ ในตลาดที่ผันผวน การถูกล็อกออกแม้เพียง 5 นาทีอาจหมายถึงการพลาดการกระตุ้น stop-loss หรือจุดเข้าที่ทำกำไรได้ การจัดการ rate limit ที่เหมาะสมไม่ใช่ทางเลือก — มันจำเป็นสำหรับการดำเนินงานบอทที่เชื่อถือได้

การกระจายความเสี่ยงหลาย exchange คุ้มค่ากับความซับซ้อนหรือไม่?

แน่นอน การจัดการบอทใน 2–3 exchange ต้องใช้ความพยายามในการบริหารมากขึ้นเล็กน้อย แต่การลดความเสี่ยงนั้นมหาศาล การล่มสลายของ FTX กวาดล้างเทรดเดอร์ที่กระจุกเงินทุนของพวกเขาไว้บนแพลตฟอร์มเดียว การกระจายความเสี่ยงปกป้องจากเหตุการณ์ที่ไม่มีความปลอดภัยของ API key หรือ IP whitelist ใดป้องกันได้: การล้มเหลวของ exchange เอง