รายการตรวจสอบความปลอดภัยที่สำคัญสำหรับการระบุผู้ใช้

บทนำ#

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

การตรวจสอบชื่อผู้ใช้และรหัสผ่านอาจดูเหมือนเป็นวิธีที่ง่ายที่สุด แต่ยังมีประเด็นอื่น ๆ อีกมากมายที่ต้องพิจารณา มาเริ่มกันเลย!

โครงสร้างพื้นฐาน#

บังคับใช้ HTTPS#

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

การตั้งค่า HTTPS อาจดูท้าทาย แต่มีเครื่องมือและบริการมากมายที่สามารถช่วยคุณได้:

• หากคุณโฮสต์เซิร์ฟเอง Let's Encrypt ให้ใบรับรอง SSL/TLS ฟรีที่สามารถใช้เพื่อเปิดใช้งาน HTTPS บนเว็บไซต์ของคุณ
• หากคุณใช้ผู้ให้บริการคลาวด์ เช่น AWS, Azure หรือ Google Cloud คุณสามารถใช้บริการที่มีการจัดการของพวกเขาในการตั้งค่า HTTPS

อย่าอนุญาตให้เข้าถึงฐานข้อมูลสาธารณะ จำกัดเฉพาะแหล่งที่เชื่อถือเท่านั้น#

แม้ว่ามันอาจจะดูพื้นฐานเช่นกัน มีการละเมิดความปลอดภัยหลายครั้งเนื่องจากการอนุญาตให้เข้าถึงฐานข้อมูลสาธารณะ ดังนั้นจึงคุ้มค่าแก่การพูดถึงที่นี่

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

จัดการโทเค็นส่วนตัวอย่างปลอดภัย#

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

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

เลือกอัลกอริทึมการแฮชรหัสผ่านอย่างชาญฉลาด#

หากคุณมีประสบการณ์กับการแฮชรหัสผ่าน คุณอาจรู้ว่ามีอัลกอริทึมมากมายที่มีอยู่ บางอันไม่ถือว่าปลอดภัยอีกต่อไป เช่น MD5, SHA-1 และ SHA-2

สาเหตุที่พบบ่อยของการไม่ปลอดภัยนี้คือ:

• พวกเขาไม่ได้รับการออกแบบมาโดยเฉพาะสำหรับการแฮชรหัสผ่าน และความเร็วในการคำนวณของพวกมันเร็วเกินไป ทำให้การโจมตีแบบ brute force ง่ายขึ้น
• พวกเขาขาดการใช้ salt ซึ่งทำให้ง่ายต่อการสร้าง rainbow tables สำหรับพวกมัน
• พวกมันยังไวต่อการบุกรุกทำให้แฮกเกอร์สามารถสร้างรหัสผ่านที่แตกต่างกันด้วยค่าแฮชเดียวกัน

อัลกอริทึมการแฮชรหัสผ่านมาตรฐานอุตสาหกรรมเช่น bcrypt และ Argon2 ได้รับการออกแบบมาแก้ปัญหาเหล่านี้ เนื่องจากขอบเขตที่จำกัดของบทความนี้ เราจะไม่ลงรายละเอียดพวกมัน ดู วิวัฒนาการของการแฮชรหัสผ่าน เพื่อเรียนรู้เพิ่มเติม

เรียนรู้และปฏิบัติตามมาตรฐานเปิดอย่างเคร่งครัด#

มาตรฐานเปิดเช่น OAuth 2.0 และ OpenID Connect (OIDC) ให้แนวทางที่ปลอดภัยและมาตรฐานสำหรับการตรวจสอบและอนุญาตของผู้ใช้ พวกเขาได้รับการทดสอบมาแล้วและได้รับการยอมรับจากอุตสาหกรรมอย่างแพร่หลาย

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

เข้ารหัสข้อมูลที่พัก#

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

ตั้งค่ากำแพงไฟร์วอลล์#

การโจมตี DDoS (Distributed Denial of Service) แม้จะเป็นเรื่องเก่า แต่ยังคงเป็นภัยคุกคามที่มีนัยสำคัญ ตามที่ รายงานภัยคุกคาม DDoS ของ Cloudflare สำหรับ Q4 ปี 2022 การจราจรการโจมตี DDoS ของ HTTP เพิ่มขึ้น 79% ต่อปี แทนที่จะสร้างโซลูชันของตัวเอง ควรตั้งค่ากำแพงไฟร์วอลล์ที่มีการจัดการและใช้เครื่องเตือนภัยเพื่อลดความเสี่ยงนี้

แอปและไคลเอนต์#

ปรับปรุงระดับความปลอดภัยสำหรับไคลเอนต์สาธารณะ#

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

• หากคุณใช้ OAuth 2.0 ใช้ Proof Key for Code Exchange (PKCE) เพื่อป้องกันการโจมตีการสกัดรหัสอนุมัติ
• บังคับใช้ Content Security Policy (CSP) เพื่อลดบางประเภทของการโจมตี รวมถึง Cross-Site Scripting (XSS) และการโจมตีการฉีดข้อมูล

อย่าเชื่อข้อมูลที่ป้อนจากสาธารณะ#

ข้อมูลที่ป้อนจากผู้ใช้อาจเป็นแหล่งที่มาของช่องโหว่ด้านความปลอดภัยที่มักถูกมองข้าม แอปที่ลดลงบางประเภทที่มักถูกมองข้ามคือ Cross-Site Scripting (XSS) และ SQL Injection ตรวจสอบและกรองข้อมูลที่ป้อนจากผู้ใช้ทั้งหมดก่อนใช้งาน

ติดตามกิจกรรม#

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

นำกลไกการตรวจสอบเข้มแข็ง#

นำนำกลไกการตรวจสอบที่แข็งแกร่งเพื่อยืนยันตัวตนของผู้ใช้ ตามที่กล่าวไปแล้ว พิจารณาการใช้โปรโตคอลที่ปลอดภัย เช่น OAuth 2.0 หรือ OpenID Connect สำหรับการตรวจสอบ สำหรับข้อมูลเพิ่มเติม คุณสามารถดูได้ที่ CIAM 101: การตรวจสอบตัวตน, การยอมรับตัวตน, SSO

สร้างการมอบหมายอำนาจที่แข็งแกร่ง (เช่น นำบทบาทเข้ามาควบคุมการเข้าถึง)#

นอกเหนือจากการตรวจสอบแล้ว ควรมีการวางกลไกการมอบสิทธิ์ที่เหมาะสม นำบทบาทเข้ามาควบคุมการเข้าถึง (RBAC) เพื่อให้แน่ใจว่าผู้ใช้มีสิทธิ์เข้าถึงเฉพาะทรัพยากรและการดำเนินการที่ได้รับอนุญาตเท่านั้น สำหรับข้อมูลเพิ่มเติม คุณสามารถดูได้ที่ CIAM 102: การมอบหมายอำนาจ & การควบคุมการเข้าถึงโดยใช้บทบาท

นำการตรวจสอบแบบหลายปัจจัย (MFA)#

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

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

วัฒนธรรม#

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

ให้การศึกษาทีมและผู้ใช้เกี่ยวกับการแอบอ้างและวิศวกรรมสังคม#

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

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

ตั้งค่า DevSecOps#

นอกเหนือจากการตรวจสอบความปลอดภัยด้วยตนเองแล้ว คุณยังสามารถดำเนินการตาม DevSecOps เพื่อทำการตรวจสอบความปลอดภัยโดยอัตโนมัติได้ ตัวอย่างเช่น คุณสามารถตั้งค่า CI/CD pipeline เพื่อรันเครื่องมือวิเคราะห์โค้ดภายในแบบสถิต เช่น CodeQL และรันการทดสอบการเจาะระบบอัตโนมัติด้วยเครื่องมือ เช่น OWASP ZAP

ยอมรับการตั้งค่าที่เข้มงวดที่สุดโดยไม่กระทบต่อประสบการณ์ผู้ใช้#

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

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

บทสรุป#

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