คำแปลนี้สร้างโดยเครื่องและอยู่ระหว่างการตรวจสอบ เปลี่ยนเป็นภาษาอังกฤษ
แดชบอร์ด

ขั้นตอนการผสานระบบ

จากสัญญาณสู่การตัดสินใจ เส้นทางที่กระชับซึ่งพาคุณจาก script tag ไปสู่การตัดสินใจที่ให้คะแนนความเสี่ยงแล้วและปกป้องได้ที่โค้ดของคุณนำไปใช้ได้

หน้า landing แสดงสี่ node — Browser, Result, Score, Decision หน้านี้คือแต่ละ node โดยละเอียด ตั้งแต่ต้นจนจบ

01. Browser

เพิ่ม script วาง collector ที่เบาของเราลงในเว็บไซต์ของคุณ มันอ่านลักษณะเบราว์เซอร์หลายสิบอย่าง — ทั้งหมดอยู่บนอุปกรณ์ ไม่มีสิ่งที่เป็นข้อมูลส่วนตัวเลย

collector รันทั้งหมดบนอุปกรณ์ โหลดในพื้นหลังและไม่ทำให้หน้าของคุณช้าในการใช้งาน การโหลดครั้งแรกเล็ก และการวัดที่หนักจะรันเฉพาะเมื่อหน้าเว็บขอคะแนนจริงๆ

สิ่งที่ script ทำ

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

สิ่งที่ script ไม่ทำ

  • ไม่อ่านข้อมูลส่วนตัวของเว็บไซต์ที่ไม่เกี่ยวข้อง
  • ไม่ขออีเมล ชื่อ หรือข้อมูลส่วนตัวใดๆ
  • ไม่ส่ง analytics beacon traffic ทางเครือข่ายเพียงอย่างเดียวคือผลลัพธ์ที่ปิดผนึก
  • ไม่ติดตามข้ามเว็บไซต์ ผลลัพธ์ถูกจำกัดขอบเขตไว้กับเว็บไซต์ที่ออก

02. Result

ผลลัพธ์ที่ปิดผนึกคือหน่วยของความไว้วางใจระหว่างเบราว์เซอร์และเซิร์ฟเวอร์

สิ่งที่มันคือ

  • แพ็คเกจขนาดกะทัดรัดที่ลงนามด้วย cryptography — ขนาดไม่กี่กิโลไบต์
  • โปรไฟล์เต็มถูกบรรจุอยู่ภายใน ดังนั้นเซิร์ฟเวอร์ไม่จำเป็นต้องเก็บข้อมูลอีกครั้ง
  • signing key หมุนเวียนตามกำหนดเวลา
  • สามารถเปิดในเครื่องได้ — คุณสามารถอ่านมันเองเพื่อดูว่ามีการเก็บอะไรไปบ้าง

ทำไมต้องใช้ผลลัพธ์ที่ปิดผนึกแทน session lookup

ผลลัพธ์ที่ปิดผนึกมีข้อดีสามประการเหนือการ lookup session ID:

  1. ไม่มี lookup เพิ่มเติมระหว่างการยืนยัน การยืนยันเป็นการตรวจสอบรวดเร็ว ไม่ใช่ network round-trip ดังนั้นจึงรวดเร็วแม้ภายใต้ load
  2. ไม่สามารถ replay ได้ ผลลัพธ์แต่ละชุดผูกกับคำขอเดียวและช่วงเวลาหนึ่ง ผลลัพธ์ที่เก่าหรือคัดลอกมาจะยืนยันไม่ผ่าน
  3. เป็นแบบ self-contained หากคุณต้องการสืบสวนเซสชันที่ถูก flag โปรไฟล์ทั้งหมดอยู่ในผลลัพธ์ตรงนั้น — ไม่จำเป็นต้อง query Noxtica เพื่อขอเส้นทาง

03. Score

วิเคราะห์และให้คะแนน บริการที่เรา host รวมโปรไฟล์กับ network context เพื่อตรวจจับบอท headless automation และรูปแบบที่น่าสงสัยแบบเรียลไทม์

เมื่อเซิร์ฟเวอร์ของคุณยืนยันผลลัพธ์ Noxtica จะ:

  1. ยืนยันว่าการปิดผนึกสมบูรณ์และแท้จริง
  2. อ่านโปรไฟล์ภายในนั้น
  3. เพิ่ม network context ที่ได้จาก edge — ประเภทเครือข่าย ประเทศ ว่าดูเหมือน datacenter หรือไม่ — ไม่เคยใช้ที่อยู่ดิบ
  4. รันหมวดหมู่การตรวจจับหกประการเทียบกับโปรไฟล์
  5. คำนวณระดับความเสี่ยงที่ calibrated และค่า confidence
  6. ส่งคืนระดับความเสี่ยง ค่า confidence และเหตุผลเบื้องหลังคะแนน

หมวดหมู่ที่ป้อนเข้าสู่คะแนน

  • Automation และบอท — ลายเซ็น headless และเบราว์เซอร์อัตโนมัติ
  • การแก้ไข Fingerprint — drawing test ที่ปลอม พฤติกรรมเบราว์เซอร์ที่ถูกจัดการ เครื่องมือ anti-fingerprint แบบก้าวร้าว
  • การใช้โครงสร้างพื้นฐานในทางที่ผิด — traffic ของ datacenter proxies ที่ไม่ระบุตัวตน พฤติกรรม network ที่ล้าสมัย
  • การจัดการเบราว์เซอร์เน้นความเป็นส่วนตัว — เบราว์เซอร์เน้นความเป็นส่วนตัวที่รับรู้ calibrated อย่างผ่อนปรน
  • การตรวจสอบฮาร์ดแวร์ — ลายเซ็น graphics และอุปกรณ์ สัญญาณ emulator
  • ความผิดปกติเชิงพฤติกรรม — timing การป้อนข้อมูล รูปแบบหลัง challenge รูปทรงโดยรวมของการโต้ตอบ

แต่ละหมวดหมู่มีส่วนร่วมด้วยหลักฐานของตัวเอง หมวดหมู่เหล่านั้นรวมกันเป็น risk tier สุดท้ายด้วย weighting ที่มีเอกสารประกอบ

ความเร็ว

การยืนยันโดยทั่วไปตอบกลับในไม่กี่มิลลิวินาทีและรวดเร็วแม้ภายใต้ load เพราะภาพเต็มรูปแบบบรรจุอยู่ในผลลัพธ์ — ไม่มี lookup เพิ่มเติมระหว่างที่คำขอกำลังดำเนินการ

04. Decision

สังเกตและลงมือ ใช้ backoffice เพื่อสำรวจโปรไฟล์ วิเคราะห์แนวโน้ม และลงมือทำตามคะแนนความเสี่ยงและข้อมูลเชิงลึกด้านพฤติกรรม

การตัดสินใจเป็นของคุณ ระดับความเสี่ยงคือสิ่งที่โค้ดของคุณใช้งาน threshold ที่คุณลงมือทำถูกตั้งค่าต่อ route

นโยบายสี่การกระทำมาตรฐาน

ทีมส่วนใหญ่ลงมือทำตามระดับความเสี่ยงในสี่ band ที่เรียบง่าย:

  • Critical — block พร้อม logging วงจรบัญชีปลอมและกลุ่ม automation เหล่านี้ไม่คุ้มกับต้นทุนของการ challenge
  • High (พร้อม confidence ที่แน่นหนา) — step up แทนที่จะบล็อก เพิ่ม second factor หรือการยืนยันเพิ่มเติม ลูกค้าจริงผ่าน บอทไม่ผ่าน
  • Medium — observe บันทึกเซสชันและนำเสนอใน dashboard แต่ไม่เพิ่มแรงเสียดทาน
  • Low หรือ minimal — allow นี่คือ traffic ส่วนใหญ่

policy ทั้งหมดโดยปกติมีเพียง 10 ถึง 20 บรรทัดของโค้ดของคุณเอง

ที่ที่การตัดสินใจอยู่

  • ระดับความเสี่ยงอยู่ในโค้ดแอปพลิเคชันของคุณ คุณเขียน policy และมันสั้น
  • เส้นทาง audit อยู่ใน operator console — ทุกการยืนยัน ทุกการตัดสินใจ ทุกการกระทำของผู้ปฏิบัติงาน
  • threshold ปรับได้จาก dashboard โดยไม่ต้อง deploy ต่อเว็บไซต์และต่อ route

เวลาแบบ end-to-end

ผู้ใช้ไม่ต้องรอ Noxtica เลย script โหลดในพื้นหลัง การเก็บข้อมูลรันเฉพาะเมื่อหน้าเว็บขอคะแนน และการปิดผนึกผลลัพธ์แทบจะทันที การรอที่มีนัยสำคัญเพียงอย่างเดียวคือ network hop ปกติไปยัง backend ของคุณเอง — และการยืนยันจากฝั่งเราเร็วพอที่จะหายไปในระดับ noise

อ่านเพิ่มเติม