การส่งมอบสิทธิ์เข้าถึงสำหรับการทดสอบความปลอดภัย: ขอบเขต บัญชี และการเพิกถอน
ผู้ทดสอบที่ขอข้อมูลรับรอง VPN ต้องการการส่งมอบที่มีขอบเขตชัดเจน ไม่ใช่บัญชีสำรอง ตรวจสอบการอนุญาต ระบุเป้าหมาย ออกบัญชี แล้วจึงเพิกถอน
ผู้ทดสอบขอที่อยู่เกตเวย์ รายละเอียด DNS ภายใน และข้อมูลรับรอง VPN และคำขอถูกส่งต่อมาถึงคุณในหัวข้อ «ต้องการสิทธิ์เข้าถึง» คำขอเพียงอย่างเดียวไม่ได้บอกคุณว่านี่คือการประเมินภายใน การทดสอบแอปพลิเคชันที่ต้องยืนยันตัวตน หรืองานเว็บไซต์สาธารณะที่ใครบางคนเข้าใจขอบเขตผิด ดำเนินการส่งมอบเป็นลำดับขั้นโดยมีประตูในทุกขั้น และหยุดที่ประตูแรกที่ไม่เปิด ถ้าทำเช่นนั้น คำขอที่คลุมเครือจะกลายเป็นสิ่งที่คุณอนุญาต ส่งมอบ และเพิกถอนได้ในภายหลัง
เริ่มจากการอนุญาต ไม่ใช่ข้อมูลรับรอง
ก่อนที่ที่อยู่ใดจะออกจากกล่องจดหมายของคุณ ให้กำหนดว่าใครเป็นเจ้าของเป้าหมายและใครมีสิทธิ์อนุมัติการทดสอบบนเป้าหมายนั้น ตรวจสอบผู้ทดสอบผ่านผู้ติดต่อของงานที่องค์กรของคุณใช้อยู่ ไม่ใช่ผ่านบุคคลที่ส่งต่ออีเมล ความสัมพันธ์กับลูกค้าไม่ใช่การอนุญาตให้ทดสอบทุกระบบที่เข้าถึงได้จากบัญชี และใบสั่งซื้อไม่ใช่เอกสารขอบเขต
เขียนวัตถุประสงค์ที่อนุมัติเป็นประโยคเดียวและเก็บไว้ข้างการส่งมอบ «ประเมินการยืนยันตัวตนของพอร์ทัลลูกค้า» และ «ประเมินเครือข่ายภายใน» นำไปสู่แพ็กเกจที่ต่างกันโดยสิ้นเชิง และต้องตกลงความแตกต่างก่อนการจัดเตรียม ไม่ใช่หลังมีข้อค้นพบ ประโยคนี้ยังให้สิ่งที่คุณชี้ได้เมื่อคำขอขยายกลางงาน
หากมีผู้ให้บริการโฮสติ้งหรือบุคคลที่สามรายอื่นอยู่ในเส้นทาง ข้อกำหนดของพวกเขามาก่อนความสะดวกของคุณ การทดสอบโครงสร้างพื้นฐานของผู้อื่นโดยไม่ได้รับอนุญาตเป็นปัญหาคนละเรื่องกับการทดสอบแอปพลิเคชันที่ทำงานบนโครงสร้างนั้น
ระบุมุมมองและเป้าหมาย
มุมมองคือคำถามที่การประเมินพยายามตอบ และมันกำหนดแพ็กเกจการเข้าถึงมากกว่าเครื่องมือใด ๆ ที่ผู้ทดสอบวางแผนจะใช้ การทดสอบสาธารณะที่ไม่ต้องยืนยันตัวตนต้องมี URL และช่วงเวลา การทดสอบที่ต้องยืนยันตัวตนต้องมีบัญชีเฉพาะสำหรับบทบาทที่อยู่ในขอบเขต และการประเมินภายในต้องมีจุดเข้าใช้งานที่กำหนดพร้อมช่วงเป้าหมายที่ชัดเจน
| Viewpoint | What you hand over | What it does not authorize |
|---|---|---|
| Public website | Approved URL, TLS hostname, testing window | Internal network entry, adjacent hosts |
| Authenticated app | URL plus per-role test accounts | Other tenants, admin consoles outside scope |
| Private staging | Named private path and test accounts | Production systems behind the same gateway |
| Internal network | Entry point and written target ranges | Anything outside those ranges, including the gateway itself |
จุดที่อุโมงค์เข้าสู่ระบบไม่ใช่ข้อเท็จจริงเดียวกับแอปพลิเคชันที่อยู่ข้างหลัง และไม่ให้สิทธิ์ในการตรวจสอบจุดเข้าใช้งานอย่างแน่นอน ระบุเช่นนี้อย่างชัดเจนในการส่งมอบ เพราะประโยค «คุณให้สิทธิ์ฉันเข้าถึงซับเน็ตนั้น» มาเร็วทันทีที่มีการโต้แย้งข้อค้นพบ รายการเป้าหมายที่เป็นลายลักษณ์อักษรเท่านั้นที่ตัดสินเรื่องนี้ในภายหลัง
ระบุชื่อโฮสต์ TLS พร้อมกับ URL ที่อยู่ IP เปล่า ๆ บังคับให้ผู้ทดสอบเดาชื่อ และชื่อที่เดาได้ทำให้เกิดข้อผิดพลาดของใบรับรองซึ่งถูกรายงานเป็นข้อค้นพบ ไม่ใช่ข้อผิดพลาดในการส่งมอบ
ออกตัวตนเฉพาะพร้อมวันหมดอายุ
จัดเตรียมบัญชีที่มีอยู่เพียงสำหรับงานนี้ อย่าให้ยืมการเข้าสู่ระบบประจำวันของพนักงาน ตั้งค่าการเข้าถึงเครือข่ายและสิทธิ์ของแอปพลิเคชันให้ตรงกับงานที่ตกลง จัดการลงทะเบียนการยืนยันตัวตนผ่านเส้นทางที่รองรับ และ แนบวันหมดอายุพร้อมผู้รับผิดชอบที่มีชื่อชัดเจนในการเพิกถอน. ส่งมอบข้อมูลรับรองผ่านช่องทางที่ปลอดภัยตามที่ตกลง แยกจากเอกสารขอบเขตที่ถูกส่งต่อกันไปมา
sudo useradd -m -e 2026-12-31 tester01 sudo passwd -S tester01 id tester01 lastlog -u tester01
บันทึกว่าใครได้รับอะไรและเมื่อใด บันทึกนั้นคือความแตกต่างระหว่างการส่งมอบที่ควบคุมได้กับรหัสผ่านที่แชร์กันซึ่งไม่มีใครติดตามได้ และเป็นสิ่งแรกที่ทุกคนถามหาหลังเกิดเหตุการณ์ เก็บไว้กับเอกสารขอบเขตแทนที่จะเก็บในเธรดแชท และบันทึกช่องทางส่งมอบไว้ข้างผู้รับ บรรทัดที่มีการประทับเวลาเอาชนะความทรงจำได้ทุกครั้ง
ช่องวันหมดอายุเป็นตาข่ายนิรภัย ไม่ใช่แผนงาน ยังมีคนที่ต้องถอดเส้นทางเครือข่ายและบทบาทของแอปพลิเคชันออกในตอนท้าย เพราะการเข้าสู่ระบบที่หมดอายุบนเครือข่ายที่ยังเข้าถึงได้ไม่ใช่การเข้าถึงที่ถูกเพิกถอน
พิสูจน์ว่าการส่งมอบทำงานก่อนที่หน้าต่างจะเปิด
ทำกระโดดขั้นแรกของผู้ทดสอบด้วยตัวเอง จากตำแหน่งที่ใกล้ที่สุดเท่าที่จะทำได้ แปลงชื่อ ตรวจสอบตัวตนของใบรับรอง และยืนยันว่าเส้นทางไปถึงที่อยู่ที่ตั้งใจ ไม่ใช่ที่อยู่ข้างเคียง
dig +short app.example.com openssl s_client -connect app.example.com:443 -servername app.example.com </dev/null> 2>/dev/null | openssl x509 -noout -subject -dates ip route get 10.60.0.25
หากเส้นทางไปไม่ถึงเป้าหมาย ให้หยุดและปรับการส่งมอบให้สอดคล้อง แทนที่จะปล่อยให้ผู้ทดสอบค้นหาเส้นทางทางเลือก การเข้าถึงที่เกิดขึ้นเฉพาะหน้าเป็นวิธีที่การประเมินขยายตัวออกนอกขอบเขตอย่างเงียบ ๆ และแทบไม่เคยถูกบันทึกไว้ในภายหลัง
ส่งผู้ติดต่อด้านปฏิบัติการ ชั่วโมงที่อนุญาต การกระทำที่ยกเว้น และเงื่อนไขการหยุด พร้อมกับข้อมูลรับรอง ผู้ทดสอบที่ไม่สามารถติดต่อใครได้ตอน 02:00 จะตัดสินใจในสิ่งที่คุณไม่ได้อนุญาต และการตัดสินใจนั้นจะถูกอธิบายในรายงานราวกับว่าอยู่ในขอบเขต
NIST SP 800-115 วางกรอบการประเมินทางเทคนิคเป็นการทดสอบที่วางแผนไว้ตามด้วยการวิเคราะห์และการบรรเทา ซึ่งเป็นรูปแบบที่การส่งมอบนี้ทำตาม ประตูข้างต้นเป็นการตัดสินใจออกแบบเชิงบรรณาธิการสำหรับวิศวกรสนับสนุน ไม่ใช่รายการตรวจสอบที่อ้างจากสิ่งพิมพ์นั้น
ปิดงานด้วยการถอดสิทธิ์เข้าถึง
เพิกถอนตามลำดับย้อนกลับของการจัดเตรียม: บทบาทของแอปพลิเคชัน จากนั้นการเข้าถึงเครือข่าย จากนั้นตัวตนเอง ยืนยันทุกขั้นแทนการถือว่าคอนโซลทำตามที่ปุ่มสัญญา ล็อกบัญชีก่อนจะฆ่าเซสชันของมัน ไม่เช่นนั้นเซสชันก็จะยืนยันตัวตนใหม่ผ่านเส้นทางเดิม จากนั้นตรวจสอบการเชื่อมต่อที่สร้างขึ้นอีกครั้งก่อนจะประกาศว่าปิดแล้ว
sudo passwd -l tester01 sudo pkill -u tester01 ss -tn state established '( sport = :443 )'
จัดการข้อมูลทดสอบที่เก็บไว้ให้เรียบร้อย จากนั้นติดตามการแก้ไขผ่านกระบวนการรายงานที่ตกลงไว้ตั้งแต่ต้น รายงานควรระบุสภาพแวดล้อม ระดับการเข้าถึง ขอบเขต และข้อจำกัด เพราะมันบันทึกข้อค้นพบจากการประเมินครั้งเดียว ไม่ใช่คำประกาศถาวรว่าไซต์ปลอดภัย
เก็บบันทึกการเพิกถอนไว้กับบันทึกการส่งมอบ เมื่อเปิดงานครั้งถัดไป คุณต้องการรู้อย่างแม่นยำว่าครั้งก่อนถอดอะไรออกและใครอนุมัติ แทนการสร้างภาพขึ้นใหม่จากความทรงจำ