การเลือกหลักฐาน HTTP: บันทึกเกตเวย์หรือบันทึกแอป

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

ตั้งชื่อคำถามก่อนแหล่งข้อมูล

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

เขียนคำถามเป็นประโยคเดียวและเก็บไว้ข้างแผนการเก็บข้อมูล นี่คือการควบคุมขอบเขตเดียวที่เชื่อถือได้

สิ่งที่เกตเวย์แสดงได้และแสดงไม่ได้

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

conntrack -L -d 203.0.113.10 | head
tcpdump -ni vpn0 -c 20 'tcp port 443'

รายการ conntrack แสดงโฟลว์และการแปล และการเก็บระยะสั้นแสดงแพ็กเก็ตโดยไม่มีเนื้อหาแอปที่อ่านได้ เท่านี้พอตอบว่าทราฟฟิกไหลหรือไม่ มากน้อยเพียงใด และระหว่างปลายทางใด รายการนี้ไม่ใช่รายการ URL และพร็อกซี CONNECT ทั่วไปส่งต่อการแลกเปลี่ยนที่เข้ารหัสโดยไม่ยุติ TLS ของแอป เมื่อมีคนสัญญาเส้นทางคำขอจากตำแหน่งนั้น ให้ถามว่าองค์ประกอบใดถอดรหัสและภายใต้ความเชื่อใจของใคร

บันทึกแอปตอบคำถามเรื่องคำขอส่วนใหญ่

สำหรับแอปที่คุณดำเนินการ การบันทึกที่รองรับของแอปเองมักตอบคำถามระดับคำขอโดยไม่ถอดรหัสการเชื่อมต่อของผู้อื่น

curl -sS -o /dev/null -w "%{http_code} %{time_total}\n" https://app.example.com/health
tail -n 5 /var/log/nginx/access.log

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

การดักจับเป็นการออกแบบความเชื่อใจแยกต่างหาก

หากจำเป็นต้องตรวจสอบระดับข้อความจริง ๆ การดักจับ TLS จะสร้างปลายทางที่เชื่อถือได้ใหม่และข้อตกลงความเชื่อใจของไคลเอนต์ที่ต้องแจกจ่ายและบำรุงรักษา แอปที่ปักหมุดใบรับรองจะเสียหาย และผู้ดำเนินการถือกุญแจส่วนตัวซึ่งการป้องกันมีความสำคัญเท่ากุญแจเซิร์ฟเวอร์ใด ๆ การทำให้การเก็บข้อมูลทำงานโดยทำให้การตรวจสอบใบรับรองอ่อนแอลง หรือโดยแก้ไขแอปที่ปักหมุดใบรับรองของตน เป็นการแลกมาตรการความปลอดภัยกับบันทึกหนึ่งบรรทัด ควรเลือกการออกแบบการตรวจสอบที่มีเอกสารและมีการจัดการการแจกจ่ายความเชื่อใจอยู่แล้ว และเก็บกุญแจส่วนตัวของหน่วยงานไว้นอกทุกสิ่งที่แชร์

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