สรุป
ใช่ Postman จัดเก็บคีย์ API และข้อมูลรับรองอื่นๆ เมื่อคุณบันทึกไว้ในตัวแปรสภาพแวดล้อมที่เปิดใช้งานการซิงค์บนคลาวด์ ซึ่งเป็นค่าเริ่มต้น สิ่งนี้ไม่ได้หมายความว่า Postman กำลังใช้คีย์ของคุณในทางที่ผิด แต่หมายความว่าข้อมูลรับรองของคุณมีอยู่บนเซิร์ฟเวอร์ของบุคคลที่สาม การทำความเข้าใจสิ่งนี้ช่วยให้คุณตัดสินใจได้ว่าการตั้งค่าเริ่มต้นของ Postman เหมาะสมกับข้อกำหนดด้านความปลอดภัยของคุณหรือไม่ และเมื่อใดที่เครื่องมือที่เน้นการทำงานในเครื่องอย่าง Apidog เป็นทางเลือกที่ดีกว่า
บทนำ
คำถามที่ว่า “Postman เก็บ API keys ของฉันหรือไม่” มักจะเกิดขึ้นในชุมชนนักพัฒนา ค้นหาใน Reddit’s r/webdev หรือ r/programming แล้วคุณจะพบกระทู้จากนักพัฒนาที่ถามคำถามเดียวกันนี้ ซึ่งมักเกิดจากการตรวจสอบด้านความปลอดภัยที่พบปัญหา หรือจากการสนทนากับทีมรักษาความปลอดภัยของพวกเขา
ความกังวลนี้มีเหตุผล คีย์ API เปรียบเสมือนรหัสผ่านสำหรับบริการของคุณ หากคีย์ API ของตัวประมวลผลการชำระเงินรั่วไหล อาจส่งผลให้เกิดการเรียกเก็บเงินที่เป็นการฉ้อโกงได้ คีย์ของผู้ให้บริการคลาวด์ที่รั่วไหลอาจนำไปสู่การสร้างทรัพยากรโดยไม่ได้รับอนุญาต การรั่วไหลของข้อมูล หรือค่าใช้จ่ายหลายหมื่นดอลลาร์ นักพัฒนาที่จัดเก็บคีย์เหล่านี้ในเครื่องมือพัฒนาของตนกำลังขยายความไว้วางใจไปยังเครื่องมือนั้น
นักพัฒนาส่วนใหญ่ทราบดีว่าไม่ควรคอมมิตคีย์ API ไปยังที่เก็บ GitHub สาธารณะ แต่ความตระหนักเกี่ยวกับเครื่องมือไคลเอ็นต์ API ยังต่ำอยู่ Postman มีผู้ใช้งานมากกว่า 30 ล้านคน ซึ่งหมายความว่านักพัฒนาจำนวนมากกำลังจัดเก็บข้อมูลรับรองในเครื่องมือโดยไม่เข้าใจอย่างถ่องแท้ว่าข้อมูลรับรองเหล่านั้นไปอยู่ที่ใด
บทความนี้จะให้คำตอบที่ตรงไปตรงมาและเป็นเทคนิคเกี่ยวกับคำถามการจัดเก็บคีย์ API และอธิบายสิ่งที่คุณสามารถทำได้เกี่ยวกับเรื่องนี้
คำตอบโดยตรง: ใช่ พร้อมบริบทที่สำคัญ
Postman จัดเก็บคีย์ API ในสถานการณ์ต่อไปนี้:
เมื่อคุณใช้ตัวแปรสภาพแวดล้อม (environment variables) ระบบสภาพแวดล้อมของ Postman เป็นวิธีมาตรฐานในการจัดเก็บข้อมูลรับรองเพื่อใช้ในการร้องขอ หากคุณสร้างตัวแปรสภาพแวดล้อมชื่อ API_KEY ที่มีค่าเป็น sk-abc123... ค่านั้นจะถูกซิงค์ไปยังเซิร์ฟเวอร์คลาวด์ของ Postman เมื่อการซิงค์บนคลาวด์ทำงาน นี่คือพฤติกรรมเริ่มต้น
เมื่อคุณใช้ตัวแปรคอลเลกชัน (collection variables) ตัวแปรที่เก็บในระดับคอลเลกชันจะซิงค์ในลักษณะเดียวกัน
เมื่อคุณใช้ตัวแปรส่วนกลาง (global variables) ตัวแปรส่วนกลางจะซิงค์กับบัญชี Postman ของคุณ
เมื่อข้อมูลรับรองปรากฏในเนื้อหาคำขอ (request bodies) หรือส่วนหัว (headers) หากคุณฮาร์ดโค้ดข้อมูลรับรองในส่วนหัวคำขอ (เช่น Authorization: Bearer sk-abc123...) และบันทึกคอลเลกชัน ค่านั้นจะถูกซิงค์
สิ่งที่ไม่ซิงค์ตามค่าเริ่มต้น: ค่าที่เก็บไว้ใน Postman Vault Vault คือที่เก็บข้อมูลรับรองในเครื่องที่ไม่ได้ซิงค์ไปยังคลาวด์ของ Postman อย่างชัดเจน ซึ่งต้องมีการจัดเก็บข้อมูลรับรองที่นั่นด้วยตนเองแทนที่จะเป็นในตัวแปรสภาพแวดล้อม
“การซิงค์บนคลาวด์” หมายถึงอะไรกันแน่
การซิงค์บนคลาวด์ใน Postman หมายความว่าสำเนาของข้อมูลพื้นที่ทำงานของคุณจะถูกดูแลอย่างต่อเนื่องบนเซิร์ฟเวอร์ของ Postman สิ่งนี้เกิดขึ้นโดยอัตโนมัติในเบื้องหลัง คุณไม่จำเป็นต้องคลิก "บันทึก" หรือ "ซิงค์" ขณะที่คุณทำงาน การเปลี่ยนแปลงจะแพร่กระจายไปยังคลาวด์
วัตถุประสงค์คือการทำงานร่วมกันและความคงทน หากแล็ปท็อปของคุณเสีย งานของคุณจะไม่หายไปเพราะอยู่ในคลาวด์ของ Postman หากคุณเปลี่ยนเครื่อง คอลเลกชันและสภาพแวดล้อมของคุณจะติดตามคุณไปเพราะมีการซิงค์กับบัญชีของคุณ
ผลกระทบด้านความปลอดภัยคือ คีย์ API ของคุณ ซึ่งคุณอาจคิดว่าอยู่ในแอปบนแล็ปท็อปของคุณ แท้จริงแล้วอยู่ในทั้งสองที่: แล็ปท็อปของคุณและคลาวด์ของ Postman
Postman เข้ารหัสข้อมูลนี้ รูปแบบเฉพาะคือการเข้ารหัส AES-256 สำหรับข้อมูลที่จัดเก็บ (data at rest) และ TLS สำหรับข้อมูลที่กำลังส่ง (data in transit) นี่คือการเข้ารหัสมาตรฐานและสมเหตุสมผล คีย์เหล่านี้ไม่ได้อยู่ในรูปแบบข้อความธรรมดาในฐานข้อมูลของ Postman ที่ใดที่หนึ่ง
แต่การเข้ารหัสไม่ได้หมายความว่าไม่สามารถเข้าถึงได้ Postman สามารถเข้าถึงข้อมูลเพื่อให้บริการได้ หากบัญชี Postman ของคุณถูกบุกรุก (ผ่านฟิชชิง, การลองเข้าสู่ระบบด้วยข้อมูลรับรองที่รั่วไหล, หรือการละเมิดข้อมูลที่ Postman) คีย์ API ที่เก็บไว้ของคุณอาจถูกเข้าถึงโดยผู้ที่ได้รับสิทธิ์เข้าถึงนั้น
นโยบายความเป็นส่วนตัวของ Postman ระบุอะไรเกี่ยวกับข้อมูลรับรองของคุณ
นโยบายความเป็นส่วนตัวของ Postman อธิบายว่าพวกเขาเป็นผู้ประมวลผลข้อมูล (data processor) ไม่ใช่ผู้ควบคุมข้อมูล (data controller) สำหรับเนื้อหาในพื้นที่ทำงานของคุณ พวกเขาประมวลผลข้อมูลของคุณเพื่อให้บริการ พวกเขาไม่ได้ขายเนื้อหาในพื้นที่ทำงานของคุณให้กับบุคคลที่สาม
ประเด็นสำคัญจากเอกสารการจัดการข้อมูลของพวกเขา:
การจำกัดวัตถุประสงค์ (Purpose limitation) Postman ระบุว่าพวกเขาใช้เนื้อหาพื้นที่ทำงานเพื่อให้บริการและปรับปรุงบริการ ไม่ใช่เพื่อการตลาดหรือการขายต่อ
ผู้ประมวลผลช่วง (Subprocessors) Postman ใช้บริการของบุคคลที่สามสำหรับโครงสร้างพื้นฐาน การสนับสนุน และการวิเคราะห์ ผู้ประมวลผลช่วงเหล่านี้อาจประมวลผลข้อมูลของคุณเพื่อส่งมอบบริการ Postman เผยแพร่รายชื่อผู้ประมวลผลช่วงในเอกสารประกอบของพวกเขา
คำขอของรัฐบาล (Government requests) ในฐานะบริษัทในสหรัฐอเมริกา Postman อยู่ภายใต้คำขอการบังคับใช้กฎหมายของสหรัฐอเมริกา รวมถึงจดหมายความมั่นคงแห่งชาติ ข้อมูลที่เก็บไว้บนเซิร์ฟเวอร์ในสหรัฐอเมริกาสามารถถูกบังคับโดยกระบวนการทางกฎหมายได้
การแจ้งเตือนการละเมิด (Breach notification) ข้อกำหนดของ Postman รวมถึงข้อกำหนดการแจ้งเตือนการละเมิดความปลอดภัย หากข้อมูลของคุณเกี่ยวข้องกับการละเมิด Postman มีข้อผูกพันตามสัญญาที่จะต้องแจ้งให้คุณทราบ
การลบข้อมูล (Data deletion) เมื่อคุณลบบัญชีของคุณ Postman จะลบข้อมูลของคุณ กำหนดการเก็บสำรองข้อมูลจะแตกต่างกันไป
นี่เป็นนโยบายปกติสำหรับบริษัท SaaS แบบ B2B ซึ่งไม่ได้บ่งบอกถึงเจตนาที่ไม่ดี คำถามคือว่านโยบายความปลอดภัยขององค์กรของคุณอนุญาตให้จัดเก็บข้อมูลรับรอง API กับบริการคลาวด์ของบุคคลที่สามหรือไม่ และคุณได้ตรวจสอบนโยบายนั้นเทียบกับสิ่งที่ Postman ทำจริงหรือไม่
มิติการมองเห็นพื้นที่ทำงาน
นอกเหนือจากการซิงค์บนคลาวด์แล้ว ยังมีมิติที่สองของความเสี่ยงของคีย์ API ของ Postman นั่นคือการมองเห็นพื้นที่ทำงาน (workspace visibility)
พื้นที่ทำงานของ Postman สามารถเป็นสาธารณะ (Public), ทีม (Team) หรือส่วนตัว (Private) พื้นที่ทำงานสาธารณะสามารถเข้าถึงได้โดยทุกคนโดยไม่ต้องมีการรับรองความถูกต้อง สามารถค้นหาได้บนเครือข่าย API สาธารณะของ Postman
ในปี 2023 นักวิจัยของ CloudSEK พบพื้นที่ทำงาน Postman สาธารณะมากกว่า 30,000 แห่งที่มีคีย์ API จริง โทเค็น และข้อมูลรับรองอื่นๆ บริษัทต่างๆ รวมถึง Razorpay และ New Relic มีข้อมูลรับรองที่ละเอียดอ่อนอยู่ในพื้นที่ทำงานสาธารณะ การเปิดเผยนี้ไม่ได้เกิดจากการละเมิดข้อมูล แต่เกิดจากนักพัฒนาตั้งค่าพื้นที่ทำงานเป็นสาธารณะโดยไม่ทราบว่าพื้นที่ทำงานเดียวกันนั้นมีข้อมูลรับรองจริงอยู่ในตัวแปรสภาพแวดล้อม
นี่คือความเสี่ยงที่สองที่แตกต่างกัน แม้ว่าคุณจะไว้วางใจความปลอดภัยบนคลาวด์ของ Postman การตั้งค่าการมองเห็นพื้นที่ทำงานผิดพลาดอาจทำให้ข้อมูลรับรองของคุณรั่วไหลไปทั่วอินเทอร์เน็ตได้
ใครมีความเสี่ยงมากที่สุด
ไม่ใช่ทุกคนที่เผชิญกับความเสี่ยงในระดับเดียวกันจากการจัดการข้อมูลรับรองของ Postman ความเสี่ยงจะสูงขึ้นเมื่อ:
คุณจัดเก็บข้อมูลรับรองการผลิต (production credentials) ใน Postman การทดสอบกับ API การผลิตด้วยคีย์การผลิตหมายความว่าข้อมูลรับรองการผลิตอยู่ในคลาวด์ของ Postman ซึ่งเป็นเรื่องปกติและมีความเสี่ยงอย่างแท้จริง
พื้นที่ทำงานของทีมคุณมีการเข้าถึงที่กว้างขวาง หากทุกคนในบริษัท 50 คนอยู่ในทีม Postman เดียวกันและสามารถเข้าถึงพื้นที่ทำงานทั้งหมดได้ บัญชีเดียวที่ถูกบุกรุกอาจเปิดเผยข้อมูลรับรองทั้งหมด
คุณทำงานในอุตสาหกรรมที่มีการควบคุม องค์กรด้านสุขภาพ การเงิน รัฐบาล และการป้องกันประเทศ มักจะมีกฎที่ชัดเจนว่าข้อมูลบางประเภทสามารถจัดเก็บได้ที่ใด การจัดเก็บคีย์ API ที่อนุญาตให้เข้าถึงระบบที่มีข้อมูล PHI (ข้อมูลสุขภาพส่วนบุคคล) หรือข้อมูลทางการเงินในคลาวด์ของบุคคลที่สามอาจละเมิดกฎเหล่านั้น
คีย์ API ของคุณมีสิทธิ์สูง คีย์แบบอ่านอย่างเดียวสำหรับ API สาธารณะมีความเสี่ยงต่ำ คีย์ผู้ดูแลระบบสำหรับโครงสร้างพื้นฐานคลาวด์หรือตัวประมวลผลการชำระเงินมีความเสี่ยงสูง ผลที่ตามมาของการรั่วไหลจะเพิ่มขึ้นตามระดับสิทธิ์ของคีย์
คุณเป็นผู้รับเหมาหรือที่ปรึกษา การจัดเก็บข้อมูลรับรอง API ของลูกค้าในบัญชี Postman ส่วนตัวของคุณหมายความว่าข้อมูลรับรองของลูกค้ามีอยู่ในเซิร์ฟเวอร์ของบุคคลที่สามที่เชื่อมโยงกับบัญชีส่วนตัวของคุณ หากบัญชีนั้นถูกบุกรุก ความปลอดภัยของลูกค้าก็ตกอยู่ในความเสี่ยง
Postman Vault เปลี่ยนแปลงสถานการณ์อย่างไร
Postman Vault ซึ่งเปิดตัวเพื่อแก้ไขข้อกังวลเหล่านี้ จัดเก็บค่าข้อมูลรับรองในเครื่องบนอุปกรณ์ของคุณ ค่าใน Vault จะไม่ซิงค์กับคลาวด์ของ Postman คุณสามารถอ้างอิงถึงค่าเหล่านั้นในการร้องขอโดยใช้ไวยากรณ์ {{vault:variable_name}}
นี่เป็นการปรับปรุงความปลอดภัยที่มีนัยสำคัญ คีย์ API ที่เก็บไว้ใน Vault จะไม่อยู่บนเซิร์ฟเวอร์ของ Postman
ข้อจำกัด: ต้องมีการเปลี่ยนแปลงพฤติกรรมอย่างจงใจ นักพัฒนาหลายปีมี "ความจำกล้ามเนื้อ" เกี่ยวกับตัวแปรสภาพแวดล้อม Vault กำหนดให้สมาชิกแต่ละคนในทีมต้องตั้งค่า Vault ของตนเองในเครื่อง ซึ่งหมายความว่าข้อมูลรับรองจะไม่ถูกแบ่งปันผ่านคุณสมบัติของทีม Postman คุณต้องมีกลไกการแบ่งปันความลับแยกต่างหากสำหรับการแนะนำสมาชิกทีมใหม่
Vault ยังไม่ได้จัดการข้อมูลรับรองที่ปรากฏโดยตรงในส่วนหัวคำขอหรือเนื้อหา หรือข้อมูลรับรองในตัวแปรคอลเลกชันและตัวแปรส่วนกลาง
เครื่องมือที่เน้นการทำงานในเครื่องและรูปแบบทางเลือก
ความแตกต่างพื้นฐานกับเครื่องมือที่เน้นการทำงานในเครื่องคือค่าเริ่มต้น ใน Postman การซิงค์บนคลาวด์จะเปิดอยู่เว้นแต่คุณจะปิด (และถึงแม้จะปิด ก็ยังต้องใช้ Vault สำหรับข้อมูลรับรองโดยเฉพาะ) ใน Apidog ข้อมูลจะอยู่ในเครื่องเว้นแต่คุณจะเปิดการซิงค์
ตัวแปรสภาพแวดล้อมของ Apidog จะถูกเก็บไว้ในฐานข้อมูล SQLite ในเครื่องบนอุปกรณ์ของคุณ พวกมันจะไม่ซิงค์ไปที่ใดเลยหากไม่มีการกระทำที่ชัดเจนจากคุณ หากคุณไม่เคยเปิดใช้งานการซิงค์กับทีม คีย์ API ของคุณก็จะไม่เคยออกจากอุปกรณ์ของคุณเลย
สำหรับนักพัฒนาที่ต้องการให้เครื่องมือจัดการความลับได้อย่างปลอดภัยโดยไม่ต้องมีการกำหนดค่าใดๆ นี่คือความแตกต่างที่สำคัญ คุณไม่จำเป็นต้องรู้จัก Vault กำหนดค่ามัน และฝึกอบรมทีมทั้งหมดให้ใช้งาน พฤติกรรมที่ปลอดภัยคือพฤติกรรมเริ่มต้น
Bruno ก้าวไปอีกขั้น: มันจัดเก็บทุกอย่างในไฟล์บนระบบไฟล์ของคุณ ไม่มีตัวเลือกคลาวด์แบบ Apidog เลย หากการทำงานในเครื่องเท่านั้นเป็นข้อกำหนดที่เข้มงวด Bruno จะตัดคำถามนี้ออกไปโดยสิ้นเชิง
คำแนะนำที่เป็นประโยชน์
ตรวจสอบสิ่งที่คุณจัดเก็บไว้ตอนนี้ เปิดสภาพแวดล้อม Postman ของคุณและตรวจสอบตัวแปรทั้งหมด มองหาคีย์ API, โทเค็น, รหัสผ่าน และความลับ รู้ว่ามีอะไรอยู่ในคลาวด์ของ Postman บ้าง
ย้ายข้อมูลรับรองไปยัง Postman Vault สำหรับข้อมูลรับรองใดๆ ที่ต้องอยู่ใน Postman ให้ย้ายไปยัง Vault อัปเดตเอกสารของทีมและกระบวนการเริ่มต้นใช้งาน
ใช้คีย์ที่มีขอบเขตและสิทธิ์จำกัดสำหรับการทดสอบ สร้างคีย์ API สำหรับการพัฒนาและการทดสอบโดยเฉพาะ โดยมีสิทธิ์ขั้นต่ำที่จำเป็น หากคีย์ทดสอบรั่วไหล ผลกระทบจะถูกจำกัด อย่าใช้คีย์ผู้ดูแลระบบหรือคีย์การผลิตในเครื่องมือพัฒนา
ตรวจสอบการมองเห็นพื้นที่ทำงาน ตรวจสอบให้แน่ใจว่าไม่มีพื้นที่ทำงานที่มีข้อมูลรับรองถูกตั้งค่าเป็นสาธารณะ ตั้งค่าเป็นส่วนตัวสำหรับพื้นที่ทำงานทั้งหมดเป็นค่าเริ่มต้น
พิจารณารูปแบบภัยคุกคามของคุณ สำหรับโปรเจกต์ส่วนตัวและ API ที่ไม่ละเอียดอ่อน การตั้งค่าปัจจุบันของ Postman อาจจะใช้ได้ สำหรับข้อมูลรับรองการผลิต ข้อมูลที่มีการควบคุม หรือการทำงานกับลูกค้า ขั้นตอนเพิ่มเติมเพื่อให้เกิดความปลอดภัยด้วย Postman อาจจะหลีกเลี่ยงได้ง่ายกว่าโดยการใช้เครื่องมือที่เน้นการทำงานในเครื่อง
คำถามที่พบบ่อย
Postman ขายคีย์ API หรือข้อมูลพื้นที่ทำงานของฉันหรือไม่? ไม่ Postman ระบุนโยบายความเป็นส่วนตัวว่าพวกเขาไม่ได้ขายเนื้อหาพื้นที่ทำงานของผู้ใช้ พวกเขาใช้เพื่อให้บริการและปรับปรุงบริการ
หากบัญชี Postman ของฉันถูกบุกรุก ผู้โจมตีสามารถเข้าถึงคีย์ API ของฉันได้หรือไม่? ได้ หากคีย์เหล่านั้นถูกเก็บไว้ในตัวแปรสภาพแวดล้อมที่ซิงค์กับคลาวด์ นี่คือเหตุผลที่การใช้ Postman Vault สำหรับข้อมูลรับรองและการเปิดใช้งานการยืนยันตัวตนแบบหลายปัจจัย (MFA) ในบัญชี Postman ของคุณมีความสำคัญทั้งคู่
Postman รองรับการยืนยันตัวตนแบบหลายปัจจัยหรือไม่? ได้ Postman รองรับ MFA ผ่านแอป Authenticator การเปิดใช้งาน MFA ช่วยลดความเสี่ยงของการถูกบุกรุกบัญชีได้อย่างมาก
คีย์ API ใน Postman Vault ปลอดภัยหรือไม่? คีย์ที่เก็บไว้ใน Postman Vault จะถูกเก็บไว้ในเครื่องและไม่ซิงค์กับคลาวด์ของ Postman มันปลอดภัยเท่ากับอุปกรณ์ในเครื่องของคุณ หากอุปกรณ์ของคุณถูกบุกรุก เนื้อหาใน Vault ก็สามารถเข้าถึงได้ แต่ Postman หรือผู้ที่บุกรุกบัญชี Postman ของคุณจะไม่สามารถเข้าถึงได้โดยไม่ต้องบุกรุกอุปกรณ์ของคุณด้วย
ฉันควรใช้อะไรถ้าฉันไม่สามารถเก็บคีย์ API ในเครื่องมือคลาวด์ใดๆ ได้? Bruno เป็นตัวเลือกที่จำกัดที่สุด โดยไม่มีส่วนประกอบคลาวด์เลย Apidog ในโหมดท้องถิ่นจะเก็บทุกอย่างไว้ในอุปกรณ์ สำหรับสภาพแวดล้อมทีมที่ไม่มีเครื่องมือคลาวด์เลย Hoppscotch ที่โฮสต์เองหรือ Apidog ที่โฮสต์เองจะช่วยให้คุณทำงานร่วมกันได้โดยไม่ต้องพึ่งพาคลาวด์ของบุคคลที่สาม
ฉันจะลบคีย์ API ของฉันออกจากคลาวด์ของ Postman ได้อย่างไร? ไปที่สภาพแวดล้อม Postman ของคุณ ลบตัวแปรที่มีข้อมูลรับรอง และแทนที่ด้วยการอ้างอิงถึง Vault หากคุณต้องการลบข้อมูลการซิงค์ในอดีต คุณจะต้องลบพื้นที่ทำงานและข้อมูลที่เกี่ยวข้องทั้งหมดจากการตั้งค่าบัญชี Postman ของคุณ
คำตอบสำหรับคำถามที่ว่า “Postman เก็บ API keys ของฉันหรือไม่” คือ ใช่ ภายใต้การตั้งค่าเริ่มต้นและรูปแบบการใช้งานทั่วไป นั่นไม่ได้ทำให้ Postman เป็นผลิตภัณฑ์ที่ไม่ดี แต่หมายความว่าคุณต้องเข้าใจโมเดลข้อมูลก่อนที่จะจัดเก็บข้อมูลรับรองที่ละเอียดอ่อน และใช้ Vault หรือเครื่องมือทางเลือกเมื่อข้อกำหนดด้านความปลอดภัยของคุณต้องการ