กลับไปที่บล็อก
มุมมองอุตสาหกรรม
มุ่งเน้นไปที่บุคลิกที่เหมาะสม
พฤศจิกายน 10, 2022
โดย Jim Beno - Director of User Experience, Skyhigh Security
ในฐานะ บริษัท รักษาความปลอดภัยผู้ใช้ผลิตภัณฑ์ของเรามักจะทํางานในองค์กรความปลอดภัยของข้อมูล แต่เราพบว่า Security Service Edge คุณลักษณะ (SSE) กําหนดเป้าหมายผู้ใช้นอกทีมรักษาความปลอดภัย: ส่วนใหญ่อยู่ในเทคโนโลยีสารสนเทศ (IT) แต่ยังรวมถึงวิศวกรรม / การดําเนินงาน คนเหล่านี้คือคนที่พัฒนาและปรับใช้แอปพลิเคชันในระบบคลาวด์ควบคุมการเข้าถึงและรับรองประสิทธิภาพของเครือข่าย
มีเวิร์กโฟลว์ SSE หลักอย่างน้อยสี่รายการหรือคุณลักษณะที่กําหนดเป้าหมายบทบาทภายนอกองค์กรความปลอดภัย:
- การให้สิทธิ์การเข้าถึงแอปพลิเคชัน - เนื่องจาก บริษัท ต่างๆเปลี่ยนโครงสร้างพื้นฐานเป็นระบบคลาวด์สาธารณะมากขึ้นพวกเขาจําเป็นต้องควบคุมการเข้าถึงแอปพลิเคชันที่โฮสต์อยู่ที่นั่น ของเรา Zero Trust Network Access โซลูชัน (ZTNA) ให้ความสามารถนี้ การจัดการนโยบายการเข้าถึงเหล่านี้และการตอบสนองต่อคําขอเข้าถึงของพนักงานไม่ใช่งานของ Security Operations Center (SOC) นี่เป็นความรับผิดชอบของ IT และ IT Help Desk
- การจัดการนโยบายไฟร์วอลล์ - ด้วยโครงสร้างพื้นฐานทั้งหมดนี้ในระบบคลาวด์สาธารณะเพื่อความปลอดภัย บริษัท ต่างๆจําเป็นต้องควบคุมการเข้าถึงไม่เพียง แต่โดยระบุว่า" ใคร" สามารถใช้แอปพลิเคชันเหล่านี้ได้ แต่ยังรวมถึง "อย่างไร" -
- การตรวจสอบประสบการณ์ดิจิทัล – ด้วยที่ตั้งสํานักงานทั่วโลกและผู้คนจํานวนมากทํางานจากที่บ้าน จึงหลีกเลี่ยงไม่ได้ที่พนักงานบางคนจะมีปัญหาในการเข้าถึงแอปพลิเคชันหรือบริการ การระบุขอบเขตและแหล่งที่มาของปัญหาเหล่านี้อาจเป็นฝันร้าย เมื่อมีสายเรียกเข้า IT Help Desk ทีมรักษาความปลอดภัยจะไม่รับโทรศัพท์
- แก้ไขการกําหนดค่าและช่องโหว่ที่ไม่ถูกต้อง – ภายในไอทีและวิศวกรรม ทีมต่างๆ อาจสร้างแอปพลิเคชันบน Amazon Web Services (AWS), Google Cloud Platform (GCP) หรือ Microsoft Azure งานของเราคือการช่วยให้ บริษัท ต่างๆรักษาความปลอดภัยแอปพลิเคชันเหล่านี้ไม่ว่าจะเป็นสถาปนิกไอทีที่รับผิดชอบโครงสร้างพื้นฐานระบบคลาวด์เจ้าของบัญชีที่พัฒนาและกําหนดค่าแอปพลิเคชันหรือบุคลากร DevOps / DevSecOps ที่ปรับใช้ หากเราตรวจพบช่องโหว่หรือการกําหนดค่าผิดพลาดทีมรักษาความปลอดภัยไม่มี "กุญแจสู่ปราสาท" เพื่อแก้ไข - เราต้องได้รับปัญหาต่อหน้าเจ้าของไอทีหรือวิศวกรรมที่สามารถทําการเปลี่ยนแปลงได้
การสร้างบุคลิก
ที่ Skyhigh Securityเรามีนักวิจัยผู้ใช้โดยเฉพาะซึ่งมีหน้าที่ทําความเข้าใจลูกค้าและสร้างข้อมูลเชิงลึกที่แจ้งความต้องการและการออกแบบผลิตภัณฑ์ สําหรับความสามารถของผลิตภัณฑ์ใหม่แต่ละรายการเราต้องแน่ใจว่าเรากําลังกําหนดเป้าหมายผู้ใช้ที่เหมาะสมและเรียนรู้ทุกสิ่งที่เราสามารถทําได้เกี่ยวกับพวกเขา: อะไรเป็นแรงจูงใจให้พวกเขา พวกเขาทํางานอะไร? พวกเขาใช้แอปพลิเคชันหรือระบบใด พวกเขาทํางานร่วมกับผู้อื่นได้อย่างไร? อะไรคือจุดปวดอันดับต้น ๆ ของพวกเขา?
เราเริ่มต้นด้วยการถามคําถามเหล่านี้กับสมาชิกในทีมภายในในการจัดการผลิตภัณฑ์และการขาย เรามักจะจัดเซสชันการทํางานและบันทึกความรู้โดยรวมของเราบนไวท์บอร์ดเสมือนจริง เมื่อเรารู้ว่าควรกําหนดเป้าหมายบทบาทงานใดเราจะสัมภาษณ์ลูกค้าและสังเกตวิธีการทํางาน หลังจากเซสชันเหล่านี้สองสามเซสชันธีมทั่วไปบางอย่างจะเริ่มปรากฏขึ้น จากนั้นเราจะสังเคราะห์ข้อมูลเชิงลึกทั้งหมดโดยการสร้างตัวละครสมมติ – "บุคลิก" – ที่กลายเป็นจุดโฟกัสสําหรับการเขียนกรณีการใช้งานและการออกแบบ
แนะนํา Fred และ Kawika
เมื่อเร็ว ๆ นี้นักวิจัยของเราได้ตรวจสอบบุคคลใหม่สองคนที่รับผิดชอบในการตรวจสอบประสบการณ์ดิจิทัลและนโยบายไฟร์วอลล์: "Fred" ที่ทํางานใน IT Help Desk และ "Kawika" ผู้ดูแลระบบเครือข่าย นี่คือข้อมูลเชิงลึกบางส่วนที่เราได้เรียนรู้จากคู่หูแบบไดนามิกนี้:
- Kawika รับผิดชอบประสิทธิภาพของเครือข่าย เมื่อทุกอย่างทํางาน ชีวิตก็ดี เขาต้องทิ้งทุกอย่างและลงมือทํา เพื่อหลีกเลี่ยงปัญหานี้เขาต้องการตรวจสอบแอปพลิเคชันที่สําคัญบนเครือข่ายในเชิงรุก - เขาไม่สามารถรอให้ตั๋วปัญหาจํานวนมากเข้ามา
- เช่นเดียวกับ SOC ไอทีมีระดับที่แตกต่างกันเพื่อจัดการกับปัญหาการสนับสนุน เมื่อพนักงานพบปัญหาในการเข้าถึงแอปพลิเคชัน พวกเขาจะเปิดตั๋วที่จัดการโดยแผนกช่วยเหลือด้านไอที ซึ่งหมายความว่าเฟร็ดจะเป็นคนแรกในแถวเพื่อตรวจสอบปัญหา เขามีคู่มือเพื่อแนะนําเขาตลอดการแก้ไขปัญหา หากดูเหมือนว่าเป็นปัญหาเครือข่ายเขาจะส่งต่อไปยังทีมเครือข่าย ตอนนี้ถึงตาของกาวีก้าแล้ว
- การวินิจฉัยปัญหาเครือข่ายไม่ใช่เรื่องง่าย สถาปัตยกรรมเครือข่ายมีความซับซ้อน เมื่อเข้าถึงบริการคลาวด์การรับส่งข้อมูลจากอุปกรณ์ของพนักงานจะเดินทางผ่านเครือข่ายต่างๆ มากมาย มีตัวแปรมากมายที่อาจส่งผลต่อประสิทธิภาพการทํางาน และเงื่อนไขสามารถเปลี่ยนแปลงได้ตลอดเวลา ในการตรวจสอบปัญหาเหล่านี้ Kawika ต้องใช้เครื่องมือและคอนโซลมากมายเพื่อให้ได้ข้อมูลที่เขาต้องการ
แผ่นข้อมูล Persona สําหรับ Kawika ผู้ดูแลระบบเครือข่าย
หลีกเลี่ยงความคลุมเครือ
ข้อมูลเชิงลึกทั้งหมดนี้สรุปไว้ในเอกสารข้อมูลหน้าเดียวที่เราสร้างขึ้นสําหรับ Fred, Kawika และเพื่อนร่วมงานของพวกเขา นอกจากนี้เรายังจัดการฝึกอบรมเพื่อแนะนําบุคลิกให้กับทีมข้ามสายงาน เมื่อเราได้ยินผู้จัดการผลิตภัณฑ์และวิศวกรอ้างอิงบุคลิกตามชื่อเรารู้ว่าเราได้ทํางานของเราแล้ว!
ทุกขั้นตอนการออกแบบ UX ใน Figma เริ่มต้นด้วยอาร์ตบอร์ดที่แสดงบุคลิกเป้าหมายและกรณีการใช้งาน วิธีนี้ทําให้ทุกคนเข้าใจตรงกัน และเราหลีกเลี่ยงการอ้างอิงถึง "ผู้ดูแลระบบ" หรือ "สถาปนิกด้านความปลอดภัย" ที่ไม่ชัดเจน หากเรากําลังตรวจสอบการออกแบบและมีคนตั้งคําถามกับบุคลิกเป้าหมาย นั่นก็เยี่ยมมาก! เรายินดีต้อนรับการสนทนานั้น อันที่จริง นั่นคือวิธีที่ Fred และ Kawika เกิดขึ้น
ไม่มีอะไรเลวร้ายไปกว่าการออกแบบและสร้างคุณลักษณะใหม่เพียงเพื่อค้นหาหลังจากเปิดตัวว่าสมมติฐานของคุณเกี่ยวกับผู้ใช้เป้าหมายนั้นผิด อาจมีนัยสําคัญต่อเวิร์กโฟลว์และต้องมีการยกเครื่องใหม่ทั้งหมด จะดีกว่ามากที่จะลงทุนในการวิจัยผู้ใช้เพียงเล็กน้อยล่วงหน้าเพื่อตรวจสอบสมมติฐานของคุณและตรวจสอบให้แน่ใจว่าคุณบรรลุเป้าหมาย
กลับไปที่บล็อก