เมื่อวันที่ 20 พฤษภาคม 2026 GitHub ยืนยันว่าผู้โจมตีได้ขโมยข้อมูลจากพื้นที่เก็บโค้ดภายในประมาณ 3,800 แห่ง จุดเริ่มต้นไม่ใช่ช่องโหว่ Zero-day ในเซิร์ฟเวอร์ของ GitHub แต่เป็นส่วนขยาย (extension) ของ VS Code ที่ถูกฝังมัลแวร์และติดตั้งอยู่บนแล็ปท็อปของพนักงานเพียงคนเดียว เมื่อส่วนขยายนั้นทำงานโดยมีสิทธิ์การเข้าถึงไฟล์ระบบเดียวกับนักพัฒนา มันก็สามารถอ่านทุกสิ่งทุกอย่างที่เข้าถึงได้: โค้ดต้นฉบับ, ไฟล์การกำหนดค่า, และข้อมูลรับรองใดๆ ที่อยู่ในพื้นที่ทำงาน หากคุณต้องการปกป้อง API keys จากการโจมตีประเภทเดียวกัน บทเรียนนี้อาจไม่สบายใจแต่เรียบง่าย จุดอ่อนที่สุดนั้นไม่ใช่ระบบคลาวด์ แต่เป็นเครื่องของนักพัฒนาและเครื่องมือที่ทำงานอยู่บนนั้น
สรุป
เพื่อป้องกัน API keys จากส่วนขยาย IDE ที่ถูกบุกรุก หรือจาก repository ที่ข้อมูลรั่วไหล ให้หยุดเก็บข้อมูลรับรองที่ใช้งานจริงในที่ที่เครื่องมือสำหรับนักพัฒนาสามารถอ่านได้ เก็บความลับออกจากโค้ดต้นฉบับและออกจากไฟล์ .env ที่ถูก commit ถือว่า .gitignore เป็นเพียงความสะดวกสบาย ไม่ใช่การควบคุมความปลอดภัย กำหนดขอบเขตของแต่ละ key ให้กับสภาพแวดล้อมเดียว ใช้ข้อมูลรับรองที่มีอายุสั้นและมีสิทธิ์น้อยที่สุด และทำการหมุนเวียน (rotate) ตามกำหนดเวลา เครื่องมืออย่าง Apidog ช่วยได้โดยการเก็บข้อมูลรับรอง API ไว้ในตัวแปรสภาพแวดล้อมที่มีค่าเฉพาะเครื่อง (local-only values) แทนที่จะเป็นไฟล์ข้อความธรรมดาที่กระจัดกระจายอยู่ทั่ว repository และ workspace ของคุณ
ทำไมการละเมิดของ GitHub จึงเป็นสัญญาณเตือนสำหรับนักพัฒนาทุกคน
เหตุการณ์ของ GitHub ดูเหมือนการโจมตีแบบ supply-chain ตามตำรา กลุ่มภัยคุกคามที่ถูกติดตามในชื่อ TeamPCP มีประวัติการฝังโทรจันในแพ็กเกจต่างๆ ทั่วทั้งระบบนิเวศของ npm, PyPI และ PHP ครั้งนี้ payload ที่เป็นอันตรายมาพร้อมกับส่วนขยายของ VS Code ตามรายงานของ TechCrunch ผู้โจมตีได้ขโมยข้อมูลจาก repository ภายในประมาณ 3,800 แห่ง และกำลังขายชุดข้อมูลนี้ในราคามากกว่า 50,000 ดอลลาร์ในฟอรัมใต้ดิน GitHub ระบุว่าไม่มีหลักฐานที่แสดงว่าข้อมูลลูกค้าที่จัดเก็บไว้นอก repository ภายในเหล่านั้นได้รับผลกระทบ และการสอบสวนยังคงดำเนินต่อไป
นี่คือส่วนที่ควรทำให้คุณหยุดคิด ส่วนขยายของ VS Code เป็นเพียงโค้ด เมื่อคุณติดตั้ง ส่วนขยายนั้นจะทำงานภายในกระบวนการของโปรแกรมแก้ไขโดยมีสิทธิ์ผู้ใช้ของคุณ มันสามารถแสดงรายการไฟล์ เปิดไฟล์ และอ่านเนื้อหาได้ มันสามารถเฝ้าระวังการเปลี่ยนแปลงไฟล์ได้ มันสามารถส่งคำขอเครือข่ายออกไปภายนอกได้ สิ่งเหล่านี้ไม่ใช่ช่องโหว่; เป็นรูปแบบการทำงานของส่วนขยายตามที่ออกแบบไว้ ส่วนขยายส่วนใหญ่ต้องการการเข้าถึงไฟล์เพื่อทำงาน ปัญหาคือส่วนขยายที่เป็นอันตรายหรือถูกบุกรุกใช้การเข้าถึงแบบเดียวกันเพื่อเก็บเกี่ยวทุกสิ่งที่พบ
มันพบอะไรบ้าง? ในโปรเจกต์ทั่วไป มันพบมากมาย ไฟล์ .env ที่ root ของ repo ไฟล์ config/secrets.yml โทเค็นที่ฮาร์ดโค้ดไว้ในสคริปต์ทดสอบด่วนที่คุณตั้งใจจะลบ ข้อมูลรับรอง AWS ใน ~/.aws/credentials ไฟล์ .npmrc ที่มีโทเค็นการยืนยันตัวตน SSH keys กลุ่ม TeamPCP เป็นผู้กระทำรายเดียวกับเบื้องหลังแคมเปญ npm worm “Mini Shai-Hulud” ซึ่งเก็บเกี่ยวข้อมูลรับรองของนักพัฒนา, CI/CD, คลาวด์ และเครื่องมือ AI จากเครื่องที่ติดมัลแวร์ รูปแบบสอดคล้องกัน: ทำให้โค้ดทำงานบนเครื่องของนักพัฒนา จากนั้นขูดหาอะไรก็ตามที่ดูเหมือนข้อมูลรับรอง
นี่ไม่ใช่เรื่องใหม่ในแง่ของประเภท เพียงแต่เป็นเรื่องใหม่ในแง่ของรายละเอียด เราเคยเขียนเกี่ยวกับรูปแบบการเปิดเผยข้อมูลที่คล้ายกันในการวิเคราะห์บทเรียนด้านความปลอดภัยของ API จาก กรณี Vercel ถูกโจมตี และกลไกของ supply-chain ก็สอดคล้องกับสิ่งที่เราครอบคลุมใน คู่มือความปลอดภัยของ npm supply chain เหตุการณ์ GitHub เป็นเรื่องเดียวกันแต่มีชื่อที่ใหญ่กว่า ดังนั้นคำถามที่ควรค่าแก่การถามในวันนี้คือ: หากส่วนขยายที่เป็นอันตรายทำงานในโปรแกรมแก้ไขของคุณตอนนี้ มันจะขโมยอะไรไปได้บ้าง?
คีย์ที่ฮาร์ดโค้ดและไฟล์ .env ที่ถูก commit เป็นความรับผิดชอบที่คงอยู่
การรั่วไหลของข้อมูลรับรองส่วนใหญ่ไม่ได้ซับซ้อนมากนัก เกิดจากนักพัฒนาวางคีย์ลงในโค้ด “ชั่วคราว” แล้วลืม หรือไฟล์ .env หลุดเข้าไปในการ commit ทั้งสองอย่างสร้างภาระผูกพันที่คงอยู่ใน repository ของคุณอย่างไม่มีกำหนด
คีย์ที่ฮาร์ดโค้ดเป็นความผิดที่เห็นได้ชัดเจน คุณเคยเห็นโค้ดแบบนี้:
import requests
# Quick test of the payments endpoint
STRIPE_KEY = "sk_live_51Qk2mNExampleKeyDoNotShipThis"
response = requests.post(
"https://api.stripe.com/v1/charges",
auth=(STRIPE_KEY, ""),
data={"amount": 2000, "currency": "usd", "source": "tok_visa"},
)
print(response.json())
คีย์ sk_live_ นั้นตอนนี้เป็นส่วนหนึ่งของไฟล์แล้ว มันอยู่ในไดเรกทอรีการทำงานของคุณที่ส่วนขยายใดๆ ก็สามารถอ่านได้ หากไฟล์นั้นถูก commit คีย์นั้นก็จะอยู่ในประวัติ Git ของคุณตลอดไป แม้ว่าคุณจะลบบรรทัดนั้นในการ commit ครั้งถัดไปก็ตาม ใครก็ตามที่ clone repo หรือเครื่องมือใดๆ ที่สแกน repo ก็จะได้รับคีย์นั้น
ไฟล์ .env ควรจะเป็นทางแก้ไข แนวคิดนี้ถูกต้อง: เก็บความลับออกจากโค้ด โหลดความลับเหล่านั้นเมื่อรันไทม์ ไฟล์ .env ที่ถูกต้องจะมีลักษณะดังนี้:
# .env (loaded at runtime, never meant to ship)
DATABASE_URL=postgres://app_user:Zk7%2BqN9wLx@db.internal:5432/payments
STRIPE_SECRET_KEY=sk_live_51Qk2mNExampleKeyDoNotShipThis
OPENAI_API_KEY=sk-proj-aB3dEf9hKlMnOpQrStUvWxYz1234567890
AWS_ACCESS_KEY_ID=AKIA4EXAMPLE7QRSTUVW
AWS_SECRET_ACCESS_KEY=wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY
JWT_SIGNING_SECRET=8f2a91c4e7b6d3508f2a91c4e7b6d350
นี่ดีกว่าการฮาร์ดโค้ด แต่สังเกตดูว่ามีอะไรที่ไม่ได้เปลี่ยนไป ไฟล์นั้นยังคงอยู่ในพื้นที่ทำงานของคุณ ในรูปแบบข้อความธรรมดา ซึ่งสามารถอ่านได้โดยทุกกระบวนการที่โปรแกรมแก้ไขทำงาน ส่วนขยายที่เป็นอันตรายไม่สนใจว่าความลับของคุณจะอยู่ใน app.py หรือใน .env ทั้งสองเป็นไฟล์ ทั้งสองอยู่ห่างจากการอ่านด้วย fs.readFileSync เพียงคำสั่งเดียว รูปแบบ .env แก้ปัญหา “ความลับในประวัติ Git” ได้ก็ต่อเมื่อไฟล์นั้นไม่เคยถูก commit และมันไม่ได้ช่วยอะไรเลยสำหรับปัญหา “เครื่องมือภายในเครื่องที่ถูกบุกรุก”
ไฟล์ .env ที่ถูก commit เป็นผลลัพธ์ที่แย่ที่สุด มันพบได้บ่อยอย่างน่าตกใจ นักพัฒนาเพิ่มไฟล์ .env เข้าไปในโปรเจกต์ เขียนคีย์จริงลงไป แล้วลืมที่จะไม่สนใจมันก่อนการ commit ครั้งแรก หรือเพื่อนร่วมทีม clone repo, เห็นไฟล์ .env.example, คัดลอกไปที่ .env, กรอกคีย์การผลิตลงไป และคำสั่ง git add . ในภายหลังก็รวมมันเข้ามา ตอนนี้ข้อมูลรับรองการผลิตอยู่ในประวัติที่ใช้ร่วมกันของ repository ที่อาจเป็นสาธารณะ อาจถูกมิเรอร์ หรืออาจจบลงด้วยการถูกละเมิดเช่นเดียวกับ GitHub เราจะลงรายละเอียดเพิ่มเติมเกี่ยวกับมุมมองการรั่วไหลของ repo ในบทความเสริมของเราเกี่ยวกับ เอกสาร API และความปลอดภัยของ Git repository
.gitignore ไม่ใช่การควบคุมความปลอดภัย
ส่วนนี้สมควรมีหัวข้อแยกต่างหากเพราะความเข้าใจผิดนี้แพร่หลายมาก การเพิ่ม .env ไปยัง .gitignore ให้ความรู้สึกเหมือนการล็อคประตู แต่มันไม่ใช่ มันเป็นแค่โพสต์อิทที่บอกว่า “โปรดอย่าหยิบสิ่งนี้ขึ้นมา”
นี่คือสิ่งที่ .gitignore ทำจริงๆ มันบอก Git ให้ข้ามไฟล์ที่ไม่ได้ถูกติดตามซึ่งตรงกับรูปแบบเมื่อคุณรัน git add นั่นคือขอบเขตทั้งหมด มันมีข้อผิดพลาดสามประการที่สำคัญต่อความปลอดภัย:
- **มันไม่ได้ทำอะไรกับไฟล์ที่ถูกติดตามอยู่แล้ว** หากไฟล์
.envถูก commit ไปแล้วครั้งหนึ่ง ก่อนที่คุณจะเพิ่มกฎการไม่สนใจ Git จะยังคงติดตามไฟล์นั้น กฎการไม่สนใจจะถูกละเลยอย่างเงียบๆ คุณต้องรันgit rm --cached .envและ commit การลบนั้น และความลับก็ยังคงอยู่ในทุก commit ในอดีต - **มันไม่ได้ทำอะไรกับไฟล์บนดิสก์**
.gitignoreเป็นคำสั่งของ Git ไฟล์.envยังคงอยู่ในไดเรกทอรีการทำงานของคุณในรูปแบบข้อความธรรมดา ส่วนขยาย VS Code ที่เป็นอันตรายจะอ่านจากระบบไฟล์ ไม่ใช่จาก Git index กฎการไม่สนใจของคุณมองไม่เห็นมัน นี่คือโหมดความล้มเหลวที่สำคัญที่สุดสำหรับการโจมตีสไตล์ GitHub - **มันห่างจากการถูกข้ามได้เพียงแค่ความผิดพลาดเดียว**
git add -f .envจะละเว้นกฎการไม่สนใจ การเพิ่มไฟล์ผ่าน UI การควบคุมแหล่งที่มาของโปรแกรมแก้ไขก็เช่นกัน รวมถึง.gitignoreที่แตกต่างกันใน subdirectory ที่ไม่ได้ทำซ้ำรูปแบบ
คุณสามารถยืนยันประเด็นแรกได้ด้วยตนเอง หากคุณสงสัยว่าความลับเคยถูก commit คำสั่งนี้จะแสดงให้คุณเห็น:
# List every commit that ever touched the file, even if it is "ignored" now
git log --all --full-history --oneline -- .env
# See the actual secret values that are still in history
git log -p --all -- .env | grep -iE "key|secret|token|password"
หากผลลัพธ์นั้นแสดงอะไรก็ตาม ข้อมูลรับรองนั้นถือว่าถูกบุกรุกทันทีที่ repo ถูกเปิดเผย การแก้ไขไม่ใช่การมีกฎการไม่สนใจที่ดีขึ้น การแก้ไขคือการหมุนเวียน key และลบไฟล์ออกจากประวัติด้วยเครื่องมืออย่าง git filter-repo การแก้ไขที่ลึกซึ้งกว่าคือการตรวจสอบให้แน่ใจว่าข้อมูลรับรองที่ใช้งานจริงไม่เคยอยู่ในไฟล์ตั้งแต่แรก
.gitignore ยังคงคุ้มค่าที่จะใช้ มันช่วยจับความผิดพลาดที่ไม่ได้ตั้งใจและทำให้ diffs ของคุณสะอาดตา แต่อย่าเข้าใจผิดว่ามันเป็นขอบเขตที่ผู้โจมตีจะเคารพ มันคือสุขอนามัย ไม่ใช่การป้องกัน
กำหนดขอบเขต, แยก, ลดอายุ, หมุนเวียน: สี่นิสัยที่ช่วยลดรัศมีของความเสียหาย
คุณไม่สามารถรับประกันได้ว่าข้อมูลรับรองจะไม่รั่วไหล คุณสามารถรับประกันได้ว่าข้อมูลรับรองที่รั่วไหลนั้นแทบจะไม่มีค่า สี่นิสัยนี้ช่วยทำงานส่วนใหญ่
กำหนดขอบเขตความลับตามสภาพแวดล้อม
คีย์ที่รั่วไหลควรปลดล็อกสิ่งเดียว ไม่ใช่ทรัพย์สินทั้งหมดของคุณ ความล้มเหลวในการกำหนดขอบเขตที่พบบ่อยที่สุดคือการใช้ API key เดียวกันในการพัฒนา, staging และ production เพียงเพราะมันง่ายกว่า เมื่อคีย์นั้นรั่วไหล ทุกสภาพแวดล้อมก็จะล่มพร้อมกันทั้งหมด
ให้แต่ละสภาพแวดล้อมมีข้อมูลรับรองของตนเอง เครื่องของคุณใช้คีย์สำหรับการพัฒนาที่เข้าถึงโปรเจกต์ sandbox และข้อมูลทดสอบ สภาพแวดล้อม staging ใช้คีย์สำหรับ staging สภาพแวดล้อม production ใช้คีย์สำหรับ production ที่มีอยู่ในที่เดียวเท่านั้นและไม่เคยถูกคัดลอกไปยังแล็ปท็อป หากคีย์สำหรับการพัฒนารั่วไหลผ่านส่วนขยายที่ถูกบุกรุก ผู้โจมตีจะเข้าถึง sandbox ที่มีลูกค้าปลอม นั่นเป็นเพียงความรำคาญ ไม่ใช่เหตุการณ์สำคัญ
แยกสภาพแวดล้อมอย่างเหมาะสม
การแยกสภาพแวดล้อมเป็นมากกว่าแค่ค่าคีย์สามค่าที่แตกต่างกัน มันหมายความว่าสภาพแวดล้อมเหล่านั้นไม่สามารถเข้าถึงกันได้ ฐานข้อมูลสำหรับการพัฒนาเป็นฐานข้อมูลที่แตกต่างออกไป ไม่ใช่ read replica ของ production ผู้ให้บริการชำระเงินของ staging อยู่ในโหมดทดสอบ ดังนั้นคีย์ staging ที่รั่วไหลจึงไม่สามารถเรียกเก็บเงินจริงได้ เครื่องมือและมนุษย์ไม่ควรสามารถชี้การกำหนดค่า “dev” ไปยังข้อมูล production ได้ด้วยการเปลี่ยนตัวแปรเดียว
เมื่อการแยกเป็นจริง คำถามที่ว่า “คีย์นี้มาจากสภาพแวดล้อมใด?” ก็จะมีคำตอบที่ชัดเจน และคำตอบนั้นจะบอกคุณได้อย่างแม่นยำว่าการรั่วไหลนั้นเลวร้ายแค่ไหน
ใช้คีย์ที่มีสิทธิ์น้อยที่สุดและมีอายุสั้น
คุณสมบัติสองประการที่กำหนดว่าคีย์ที่ถูกขโมยจะสร้างความเสียหายได้มากน้อยเพียงใด
**สิทธิ์.** คีย์ควรมีชุดสิทธิ์ที่แคบที่สุดเท่าที่งานของมันต้องการ การสร้าง frontend ที่อ่านแคตตาล็อกสินค้าสาธารณะต้องใช้คีย์แบบอ่านอย่างเดียวที่จำกัดขอบเขตไว้ที่ทรัพยากรนั้น มันไม่ต้องการสิทธิ์ในการเขียน ไม่ต้องการสิทธิ์การเข้าถึงการเรียกเก็บเงิน และแน่นอนว่าไม่ต้องการสิทธิ์ผู้ดูแลระบบ ผู้ให้บริการ API ส่วนใหญ่รองรับคีย์ที่กำหนดขอบเขตหรือโทเค็นแบบละเอียด โทเค็นการเข้าถึงส่วนบุคคลแบบละเอียดของ GitHub เองก็เป็นแบบจำลองที่ดี หากคุณกำลังพิจารณารูปแบบโทเค็น การเปรียบเทียบ API keys กับ OAuth ของเราจะอธิบายว่าเมื่อใดที่โทเค็น OAuth ที่มีอายุสั้นสามารถเอาชนะคีย์แบบคงที่ได้อย่างสิ้นเชิง
**อายุการใช้งาน.** คีย์ที่หมดอายุภายในหนึ่งชั่วโมงเป็นรางวัลที่ไม่มีค่า เมื่อผู้โจมตีซื้อชุดข้อมูลที่ถูกขโมยและเริ่มพยายามใช้คีย์ของคุณ คีย์นั้นก็หมดอายุแล้ว คีย์แบบคงที่ที่มีอายุการใช้งานตลอดไปนั้นตรงกันข้าม: มันจะทำงานจนกว่าจะมีคนสังเกตเห็น ซึ่งมักจะใช้เวลาหลายเดือน ควรเลือกใช้โทเค็นที่มีอายุสั้นที่ออกให้ตามความต้องการ ในกรณีที่ไม่สามารถหลีกเลี่ยงคีย์ที่มีอายุการใช้งานยาวนานได้ ให้ตั้งค่าการหมดอายุที่สั้นที่สุดเท่าที่เวิร์กโฟลว์จะยอมรับได้
หมุนเวียนตามกำหนดเวลา ไม่ใช่ตามความตื่นตระหนก
การหมุนเวียนคือการเปลี่ยนค่าของข้อมูลรับรองเพื่อให้ค่าเก่าไม่สามารถใช้งานได้อีกต่อไป ทีมส่วนใหญ่จะหมุนเวียนก็ต่อเมื่อเกิดการละเมิดข้อมูลแล้วเท่านั้น โดยทำอย่างเร่งรีบและภายใต้ความกดดัน นั่นเป็นเวลาที่แย่ที่สุดที่จะได้รู้ว่ากระบวนการหมุนเวียนของคุณไม่ได้ถูกบันทึกไว้
ให้หมุนเวียนตามปฏิทินแทน กำหนดช่วงเวลาสำหรับแต่ละประเภทข้อมูลรับรอง; คีย์การผลิตที่มีสิทธิ์สูงรายเดือน คีย์ที่มีความเสี่ยงต่ำกว่ารายไตรมาส การหมุนเวียนตามปกติมีประโยชน์สองประการ มันจำกัดอายุการใช้งานของข้อมูลที่รั่วไหลที่คุณยังไม่ได้ตรวจพบ เนื่องจากคีย์ที่ถูกขโมยในวันนี้จะหยุดทำงานในรอบถัดไป และมันทำให้กลไกการอัปเดตค่าในทุกสภาพแวดล้อมที่ใช้งาน ถูกฝึกฝนและเป็นเรื่องปกติ เมื่อเกิดเหตุการณ์จริง การหมุนเวียนก็จะเป็นปุ่มที่คุณเคยกดมาแล้วห้าสิบครั้ง ไม่ใช่การซ้อมหนีไฟ สำหรับข้อมูลเพิ่มเติม โปรดดูสรุป เครื่องมือจัดการ API key ของเรา
เก็บข้อมูลรับรองไว้ในตัวแปรสภาพแวดล้อมของ Apidog ไม่ใช่ปล่อยทิ้งไว้ในพื้นที่ทำงานของคุณ
นี่คือกรอบความคิดที่ตรงไปตรงมา Apidog มาพร้อมกับส่วนขยาย VS Code และ MCP server ของตัวเอง ประเด็นไม่ได้อยู่ที่ “เครื่องมือของเราปลอดภัยจากการโจมตีประเภทเดียวกับที่ GitHub โดน” ไม่มีเครื่องมือฝั่งไคลเอ็นต์ใดที่ปลอดภัย ประเด็นอยู่ที่ว่าความลับของคุณถูกเก็บไว้ที่ใด และจะถูกเปิดเผยมากน้อยเพียงใดเมื่อมีสิ่งผิดปกติเกิดขึ้นกับเครื่องของคุณ
ลองคิดถึงสถานการณ์จริง คุณกำลังสร้างและทดสอบ API ตลอดทั้งวัน คุณต้องการ bearer token, API key, connection string ของฐานข้อมูล การดำเนินการเริ่มต้นคือการนำข้อมูลเหล่านี้ไปใส่ในไฟล์ .env หรือสคริปต์เพื่อให้ไคลเอ็นต์ของคุณสามารถใช้งานได้ ซึ่งจะทำให้ข้อมูลรับรองที่ใช้งานจริงอยู่ในไฟล์ข้อความธรรมดาในพื้นที่ทำงาน ซึ่งเป็นจุดที่ส่วนขยายที่เป็นอันตรายจะขูดข้อมูล ระบบสภาพแวดล้อมของ Apidog จะเปลี่ยนตำแหน่งที่ค่าเหล่านั้นอยู่
ตัวแปรสภาพแวดล้อมแทนไฟล์ข้อความธรรมดา
ใน Apidog คุณจะจัดเก็บข้อมูลรับรองเป็น ตัวแปรสภาพแวดล้อม แทนที่จะเป็นข้อความที่กระจัดกระจายอยู่ใน repo ของคุณ คำขอจะอ้างอิงตัวแปรด้วยชื่อ เช่น {{access_token}} ในส่วนหัว Authorization และ Apidog จะแปลงค่าเมื่อส่งคำขอ ส่วนหัวในการกำหนดคำขอของคุณจะอ่านว่า Bearer {{access_token}} ไม่ใช่ Bearer sk-proj-aB3dEf... ความลับที่แท้จริงไม่ได้อยู่ในไฟล์ .env ที่ root ของโปรเจกต์ที่รอการอ่าน
นี่เป็นสิ่งสำคัญด้วยเหตุผลเดียวกับที่ .env ดีกว่าการฮาร์ดโค้ด แต่ก้าวไปอีกขั้นหนึ่ง ข้อมูลรับรองไม่ได้เป็นบรรทัดข้อความธรรมดาในไฟล์ที่อยู่ถัดจากซอร์สโค้ดของคุณอีกต่อไป แต่เป็นค่าที่ถูกจัดการภายในไคลเอ็นต์ API ซึ่งถูกอ้างอิงโดยอ้อม
ค่าเฉพาะเครื่อง (local values) เก็บความลับไว้บนเครื่องของคุณ
Apidog กำหนดความแตกต่างระหว่างค่าสองประเภทสำหรับแต่ละตัวแปรอย่างชัดเจน มีค่าที่ใช้ร่วมกัน หรือค่าเริ่มต้น ที่ซิงค์ไปยังเซิร์ฟเวอร์ของ Apidog และมองเห็นได้โดยทีมของคุณ และมีค่าเฉพาะเครื่อง หรือค่าปัจจุบัน ที่อยู่บนเครื่องของคุณและไม่เคยถูกอัปโหลด คำแนะนำอย่างเป็นทางการระบุชัดเจน: ใส่ข้อมูลที่ละเอียดอ่อน เช่น โทเค็นและรหัสผ่านไว้ในค่าเฉพาะเครื่อง (local value) เพื่อไม่ให้ข้อมูลเหล่านั้นออกจากไคลเอ็นต์ของคุณ
ผลในทางปฏิบัติคือเพื่อนร่วมทีมที่ clone โครงสร้างโปรเจกต์จะได้รับชื่อและรูปแบบตัวแปร เช่น access_token, db_password และอื่นๆ แต่ไม่ใช่ความลับจริงของคุณ นักพัฒนาแต่ละคนจะกรอกค่าเฉพาะเครื่องของตนเอง โทเค็นการผลิตที่ใช้งานจริงของใครก็จะไม่ถูกส่งไปพร้อมกับข้อมูลโปรเจกต์ที่ซิงค์ และไม่มีไฟล์คีย์จริงที่ใช้ร่วมกันเพื่อที่จะรั่วไหล
การจัดการสภาพแวดล้อมและการแยกสภาพแวดล้อม
การ จัดการสภาพแวดล้อม ของ Apidog สร้างขึ้นจากแนวคิดการกำหนดขอบเขตจากส่วนที่แล้ว คุณกำหนดสภาพแวดล้อมที่แยกต่างหาก ได้แก่ Development, Staging, Production และแต่ละสภาพแวดล้อมมี URL พื้นฐานของตนเองและชุดค่าตัวแปรของตนเอง ตัวแปรถูกกำหนดขอบเขตตามสภาพแวดล้อม: เฉพาะค่าของสภาพแวดล้อมที่ใช้งานอยู่เท่านั้นที่มีผล และการสลับสภาพแวดล้อมจะเปลี่ยนชุดข้อมูลรับรองทั้งหมดในคราวเดียว
สิ่งนี้ทำให้คุณมีการแยกสภาพแวดล้อมโดยโครงสร้าง ตัวแปร payment_api_key ของคุณจะเก็บคีย์ sandbox ภายใต้ Development และคีย์ production ภายใต้ Production คุณไม่จำเป็นต้องแก้ไขคำขอเพื่อสลับไปมาระหว่างกัน; คุณเพียงแค่เปลี่ยนสภาพแวดล้อม เนื่องจากค่าต่างๆ ถูกผูกไว้กับสภาพแวดล้อม ข้อมูลรับรองสำหรับการพัฒนาจึงไม่สามารถไปปรากฏในการเรียกใช้ production โดยไม่ได้ตั้งใจ และความลับของการผลิตก็ไม่จำเป็นต้องมีอยู่ในสภาพแวดล้อมการพัฒนาในเครื่องของคุณเลย สภาพแวดล้อมการพัฒนาที่รั่วไหลจะเปิดเผยค่าของการพัฒนาเท่านั้น ส่วน production จะยังคงไม่ได้รับผลกระทบ
สำหรับทีมที่ต้องการขอบเขตที่แข็งแกร่ง: vault secrets
หากทีมของคุณต้องการให้ความลับของการผลิตไม่สัมผัสกับไคลเอ็นต์ API เลย แผน Enterprise ของ Apidog จะเพิ่ม คุณสมบัติ Vault Secret ที่ดึงความลับโดยตรงจาก HashiCorp Vault, Azure Key Vault หรือ AWS Secrets Manager Apidog จัดเก็บเฉพาะพาธของ vault และข้อมูลเมตาเท่านั้น ค่าความลับจริงจะถูกดึงเมื่อมีการร้องขอ ถูกเข้ารหัสในไคลเอ็นต์ในเครื่อง และไม่เคยถูกแชร์กับเพื่อนร่วมทีมผ่านโปรเจกต์ ที่อยู่ของข้อมูลรับรองยังคงเป็นตัวจัดการความลับโดยเฉพาะ ซึ่งเป็นที่ที่ข้อมูลรับรองการผลิตควรจะอยู่
หากต้องการลองใช้งานเวิร์กโฟลว์ตัวแปรสภาพแวดล้อม โปรด ดาวน์โหลด Apidog, สร้างโปรเจกต์, เปิด Environment Management, และเพิ่มข้อมูลรับรองของคุณเป็นตัวแปรสภาพแวดล้อมที่มีค่าเฉพาะเครื่อง (local-only values) ใช้เวลาเพียงไม่กี่นาที และจะช่วยนำความลับที่ใช้งานจริงออกจากไฟล์ข้อความธรรมดาที่ส่วนขยายสามารถอ่านได้
คำเตือนที่ตรงไปตรงมา การย้ายความลับเข้าสู่ Apidog จะช่วยลดจำนวนข้อมูลรับรองในรูปแบบข้อความธรรมดาที่อยู่ใน repo และพื้นที่ทำงานของคุณ มันไม่ได้ทำให้เครื่องของคุณปลอดภัยจากการถูกเครื่องมือที่ถูกบุกรุกโจมตีได้ การป้องกันเชิงลึกยังคงใช้ได้: ตรวจสอบส่วนขยายที่คุณติดตั้ง รักษาสิทธิ์ของคีย์การผลิตให้น้อยที่สุดและมีอายุสั้น และหมุนเวียนตามกำหนดเวลา Apidog จัดการส่วน “ที่อยู่ของข้อมูลรับรอง” ส่วนที่เหลือยังคงเป็นหน้าที่ของคุณ
บทสรุป
การละเมิดของ GitHub เป็นสัญญาณที่ชัดเจน ผู้โจมตีได้ค้นพบว่าเครื่องของนักพัฒนา ซึ่งมีเครื่องมือที่เชื่อถือได้และไฟล์การกำหนดค่าแบบข้อความธรรมดา เป็นเป้าหมายที่อ่อนแอกว่าเซิร์ฟเวอร์ production ใดๆ คุณไม่สามารถทำให้เครื่องนั้นปลอดภัยได้อย่างสมบูรณ์ แต่คุณสามารถทำให้แน่ใจได้ว่าส่วนขยาย IDE ที่ถูกบุกรุกหรือ repository ที่รั่วไหลจะมอบข้อมูลให้ผู้โจมตีน้อยที่สุด
เริ่มต้นด้วยการตรวจสอบหนึ่งครั้ง เปิด repo ที่คุณทำงานบ่อยที่สุดและค้นหาคำว่า key, secret, token และ password ตรวจสอบว่า .env อยู่ในประวัติ Git ของคุณหรือไม่ สิ่งใดก็ตามที่คุณพบ ให้ถือว่ามันถูกเปิดเผย: หมุนเวียนมัน จากนั้นย้ายค่าที่ใช้งานจริงไปยังที่ที่เครื่องมือที่ไม่เกี่ยวข้องไม่สามารถอ่านได้ ดาวน์โหลด Apidog และใส่ชุดข้อมูลรับรอง API ชุดถัดไปของคุณในตัวแปรสภาพแวดล้อมแทนที่จะเป็นไฟล์ข้อความธรรมดา สำหรับบริบทที่กว้างขึ้น บทความเสริมของเราเกี่ยวกับ เครื่องมือ API แบบ self-hosted หลังจากการละเมิดของ GitHub และ เครื่องมือจัดการ API key เป็นบทความที่ควรค่าแก่การอ่านต่อไป
คำถามที่พบบ่อย
ส่วนขยาย VS Code สามารถอ่านไฟล์ .env และ API key ของฉันได้จริงหรือ?
ใช่ ส่วนขยาย VS Code ทำงานภายในกระบวนการของโปรแกรมแก้ไขโดยใช้สิทธิ์การเข้าถึงไฟล์ของบัญชีผู้ใช้ของคุณ มันสามารถแสดงรายการไดเรกทอรี เปิดไฟล์ และอ่านเนื้อหาของไฟล์เหล่านั้นได้ รวมถึงไฟล์ .env, ไฟล์การกำหนดค่า และไฟล์ข้อมูลรับรองเช่น ~/.aws/credentials นี่คือพฤติกรรมการทำงานปกติของส่วนขยาย เนื่องจากส่วนขยายจำนวนมากจำเป็นต้องเข้าถึงไฟล์อย่างถูกต้องตามกฎหมาย ความเสี่ยงคือส่วนขยายที่เป็นอันตรายหรือถูกบุกรุกใช้การเข้าถึงแบบเดียวกันเพื่อรวบรวมความลับ นั่นคือกลไกเบื้องหลังการละเมิด GitHub เมื่อเดือนพฤษภาคม 2026
การเพิ่ม .env ไปยัง .gitignore เพียงพอที่จะปกป้อง API key หรือไม่?
ไม่ การเพิ่ม .env ไปยัง .gitignore ทำได้เพียงบอก Git ให้ข้ามไฟล์ที่ไม่ได้ถูกติดตามในระหว่างคำสั่ง git add เท่านั้น มันไม่ได้ทำอะไรกับไฟล์ที่ถูก commit ไปแล้วก่อนที่จะมีกฎนี้ และความลับก็จะยังคงอยู่ในประวัติ Git ไม่ว่าจะอย่างไรก็ตาม นอกจากนี้ มันไม่ได้ทำอะไรกับไฟล์บนดิสก์เลย: ไฟล์ .env ยังคงอยู่ในพื้นที่ทำงานของคุณในรูปแบบข้อความธรรมดา ซึ่งสามารถอ่านได้ทั้งหมดโดยเครื่องมือหรือส่วนขยายใดๆ ในเครื่อง ถือว่า .gitignore เป็นเพียงวิธีป้องกันความผิดพลาดที่ไม่ได้ตั้งใจ ไม่ใช่ขอบเขตความปลอดภัย
ฉันควรทำอย่างไรหากพบ API key ในประวัติ Git ของฉัน?
ให้ถือว่ามันถูกบุกรุกทันที แม้ว่า repo จะเป็นส่วนตัวก็ตาม อันดับแรกให้หมุนเวียน key เพื่อให้ค่าที่ถูกเปิดเผยหยุดทำงาน จากนั้นลบไฟล์ออกจากประวัติโดยใช้เครื่องมืออย่าง git filter-repo และ force-push ประวัติที่ถูกล้างแล้วหลังจากประสานงานกับทีมของคุณ สุดท้าย ย้ายข้อมูลรับรองที่ใช้งานจริงออกจากไฟล์ข้อความธรรมดาใดๆ เพื่อป้องกันไม่ให้การรั่วไหลแบบเดียวกันเกิดขึ้นอีก โปรดดูคู่มือ เครื่องมือจัดการ API key ของเราสำหรับแนวปฏิบัติที่ต่อเนื่อง
การเก็บ API key ไว้ใน Apidog ช่วยลดการเปิดเผยข้อมูลของฉันได้อย่างไร?
Apidog ช่วยให้คุณจัดเก็บข้อมูลรับรองเป็นตัวแปรสภาพแวดล้อมและอ้างอิงข้อมูลเหล่านั้นด้วยชื่อในคำขอ ดังนั้นความลับที่แท้จริงจึงไม่ได้อยู่ในไฟล์ .env แบบข้อความธรรมดาใน repo ของคุณ ตัวแปรแต่ละตัวรองรับค่าเฉพาะเครื่อง (local-only value) ที่อยู่บนเครื่องของคุณและไม่ซิงค์ไปยังเซิร์ฟเวอร์หรือเพื่อนร่วมทีม ซึ่งเป็นที่ที่เอกสารแนะนำให้เก็บโทเค็นและรหัสผ่าน ตัวแปรที่กำหนดขอบเขตตามสภาพแวดล้อมยังช่วยแยกข้อมูลรับรองสำหรับการพัฒนาและการผลิตออกจากกัน มันช่วยลดจำนวนความลับที่ใช้งานจริงที่อยู่ในไฟล์ที่เครื่องมือสามารถขูดข้อมูลได้; มันไม่ได้ทำให้เครื่องของคุณปลอดภัยจากการถูกเครื่องมือที่ถูกบุกรุกโจมตี
Apidog มีส่วนขยาย VS Code ด้วยหรือไม่ และนั่นเป็นความเสี่ยงหรือไม่?
ใช่ Apidog มาพร้อมกับส่วนขยาย VS Code และ MCP server ประเด็นของบทความนี้ไม่ใช่ว่าเครื่องมือใดๆ จะปลอดภัยจากการโจมตีแบบ supply-chain; ไม่มีเครื่องมือฝั่งไคลเอ็นต์ใดที่ปลอดภัย ประเด็นอยู่ที่ว่าความลับของคุณถูกเก็บไว้ที่ใด การเก็บข้อมูลรับรองไว้ในตัวแปรสภาพแวดล้อมที่มีค่าเฉพาะเครื่อง (local-only values) หรือในการรวมระบบ vault หมายความว่าจะมีคีย์แบบข้อความธรรมดาที่ถูกเปิดเผยน้อยลง หากเครื่องมือใดๆ บนเครื่องของคุณ รวมถึงส่วนขยายของ Apidog เองถูกบุกรุก การป้องกันเชิงลึก การตรวจสอบส่วนขยาย สิทธิ์ที่น้อยที่สุด และการหมุนเวียนยังคงใช้ได้
ความแตกต่างระหว่างการกำหนดขอบเขตและการหมุนเวียน API key คืออะไร?
การกำหนดขอบเขต (scoping) จะจำกัดว่า key สามารถทำอะไรได้บ้างและใช้ได้ที่ไหน: คีย์สำหรับการพัฒนาจะเข้าถึงได้เฉพาะ sandbox เท่านั้น และคีย์แบบอ่านอย่างเดียวไม่สามารถเขียนได้ การหมุนเวียน (rotation) คือการเปลี่ยนค่าของ key ตามกำหนดเวลาเพื่อให้ค่าเก่าหยุดทำงาน การกำหนดขอบเขตจะลดความเสียหายที่ key ที่รั่วไหลสามารถก่อให้เกิดได้; การหมุนเวียนจะลดช่วงเวลาที่ key ที่รั่วไหลยังคงมีประโยชน์ คุณต้องการทั้งสองอย่าง เมื่อใช้ร่วมกัน key ที่ถูกขโมยจะปลดล็อกได้น้อยและหมดอายุในไม่ช้า
ฉันควรหมุนเวียน API key บ่อยแค่ไหน?
ให้หมุนเวียนตามกำหนดเวลาที่แน่นอน แทนที่จะรอจนเกิดเหตุการณ์เท่านั้น เกณฑ์ที่สมเหตุสมผลคือรายเดือนสำหรับข้อมูลรับรองการผลิตที่มีสิทธิ์สูง และรายไตรมาสสำหรับคีย์ที่มีความเสี่ยงต่ำกว่า โดยปรับตามความทนทานต่อความเสี่ยงและกฎการปฏิบัติตามข้อกำหนด การหมุนเวียนตามกำหนดเวลาจะจำกัดอายุการใช้งานของข้อมูลที่รั่วไหลที่คุณยังไม่ได้ตรวจพบ และทำให้กระบวนการหมุนเวียนได้รับการฝึกฝนมาอย่างดี ดังนั้นเหตุการณ์จริงจึงเป็นเรื่องปกติไม่ใช่การเร่งรีบ
API key สำหรับ production ควรอยู่ในแล็ปท็อปของนักพัฒนาหรือไม่?
ในอุดมคติแล้ว ไม่ควร ข้อมูลรับรองสำหรับการผลิตควรอยู่ในสถานที่ที่น้อยที่สุดเท่าที่จะเป็นไปได้ โดยปกติจะเป็น secrets manager เฉพาะและ runtime ของ production และไม่ควรคัดลอกไปยังเครื่องของนักพัฒนา นักพัฒนาควรทำงานกับข้อมูลรับรองสำหรับการพัฒนาหรือ staging ที่กำหนดขอบเขตไปยังข้อมูลที่ไม่ใช่ production หากแล็ปท็อปถูกบุกรุก ผู้โจมตีจะเข้าถึง sandbox ไม่ใช่ระบบลูกค้าที่ใช้งานจริง การแยกสภาพแวดล้อมและการรวมระบบ vault ของ Apidog สนับสนุนสิ่งนี้โดยการเก็บค่า production ออกจากสภาพแวดล้อมการพัฒนาในเครื่อง