แนวทางปฏิบัติที่ดีที่สุดในการรักษาความปลอดภัยส่วนผู้ดูแลระบบของเว็บไซต์คืออะไร [ปิด]

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

แน่นอนว่ามีสิ่งที่ชัดเจนเช่นการใช้ SSL และการบันทึกการเข้าถึงทั้งหมด แต่ฉันสงสัยว่าขั้นตอนพื้นฐานเหล่านี้อยู่ที่ใดที่ผู้คนพิจารณาว่าจะตั้งค่าแถบ

ตัวอย่างเช่น:

• คุณอาศัยกลไกการตรวจสอบสิทธิ์แบบเดียวกับที่คุณใช้สำหรับผู้ใช้ทั่วไปหรือไม่? ถ้าไม่ได้อะไร?
• คุณเรียกใช้ส่วนผู้ดูแลระบบใน "โดเมนแอปพลิเคชัน" เดียวกันหรือไม่
• คุณต้องทำขั้นตอนใดบ้างเพื่อทำให้ส่วนผู้ดูแลระบบไม่ถูกค้นพบ (หรือคุณปฏิเสธสิ่งที่ 'ปิดบัง' ทั้งหมด)

จนถึงตอนนี้คำแนะนำจากผู้ตอบ ได้แก่ :

• แนะนำการหยุดชั่วคราวฝั่งเซิร์ฟเวอร์เทียมในการตรวจสอบรหัสผ่านของผู้ดูแลระบบแต่ละครั้งเพื่อป้องกันการโจมตีแบบดุร้าย[Developer Art]
• ใช้หน้าการเข้าสู่ระบบแยกกันสำหรับผู้ใช้และผู้ดูแลระบบโดยใช้ตาราง DB เดียวกัน (เพื่อหยุด XSRF และการขโมยเซสชันที่ให้สิทธิ์เข้าถึงพื้นที่ผู้ดูแลระบบ) [Thief Master]
• ลองเพิ่มการตรวจสอบสิทธิ์แบบเนทีฟของเว็บเซิร์ฟเวอร์ในพื้นที่ผู้ดูแลระบบด้วย (เช่นผ่าน. htaccess) [Thief Master]
• พิจารณาบล็อก IP ของผู้ใช้หลังจากพยายามเข้าสู่ระบบของผู้ดูแลระบบที่ล้มเหลวหลายครั้ง[Thief Master]
• เพิ่ม captcha หลังจากพยายามเข้าสู่ระบบของผู้ดูแลระบบที่ล้มเหลว[Thief Master]
• ให้กลไกที่แข็งแกร่งเท่าเทียมกัน (โดยใช้เทคนิคข้างต้น) สำหรับผู้ใช้และผู้ดูแลระบบ (เช่นอย่าปฏิบัติต่อผู้ดูแลระบบเป็นพิเศษ) [Lo'oris]
• พิจารณาการรับรองความถูกต้องระดับที่สอง (เช่นใบรับรองไคลเอ็นต์สมาร์ทการ์ดพื้นที่การ์ด ฯลฯ ) [JoeGeeky]
• อนุญาตให้เข้าถึงจาก IP / โดเมนที่เชื่อถือได้เท่านั้นเพิ่มการตรวจสอบไปยังไปป์ไลน์ HTTP พื้นฐาน (ผ่านเช่น HttpModules) ถ้าเป็นไปได้ [JoeGeeky]
• [ASP.NET] ล็อก IPrincipal & Principal (ทำให้ไม่เปลี่ยนรูปและไม่สามารถระบุได้) [JoeGeeky]
• การยกระดับสิทธิ์ของสหพันธรัฐ - เช่นส่งอีเมลถึงผู้ดูแลระบบรายอื่นเมื่อมีการอัปเกรดสิทธิ์ของผู้ดูแลระบบ [JoeGeeky]
• พิจารณาสิทธิ์โดยละเอียดสำหรับผู้ดูแลระบบ - เช่นแทนที่จะเป็นสิทธิ์ตามบทบาทให้กำหนดสิทธิ์สำหรับการกระทำที่บ่งชี้ต่อผู้ดูแลระบบ[JoeGeeky]
• จำกัด การสร้างผู้ดูแลระบบ - เช่นผู้ดูแลระบบไม่สามารถเปลี่ยนแปลงหรือสร้างบัญชีผู้ดูแลระบบอื่นได้ ใช้ไคลเอนต์ 'superadmin' ที่ล็อกลงสำหรับสิ่งนี้ [JoeGeeky]
• พิจารณาใบรับรอง SSL ฝั่งไคลเอ็นต์หรือคีย์ฟอบประเภท RSA (โทเค็นอิเล็กทรอนิกส์) [Daniel Papasian]
• หากใช้คุกกี้สำหรับการตรวจสอบสิทธิ์ให้ใช้คุกกี้แยกกันสำหรับผู้ดูแลระบบและเพจปกติโดยวางส่วนผู้ดูแลระบบไว้ในโดเมนอื่น [แดเนียลปาปาเซียน]
• หากเป็นไปได้ให้พิจารณาเก็บไซต์ผู้ดูแลระบบไว้ในเครือข่ายย่อยส่วนตัวนอกอินเทอร์เน็ตสาธารณะ [John Hartsock]
• ออกตั๋วการตรวจสอบสิทธิ์ / เซสชันอีกครั้งเมื่อย้ายไปมาระหว่างบริบทการใช้งานของผู้ดูแลระบบ / ปกติของเว็บไซต์[Richard JP Le Guen]

ทั้งหมดนี้เป็นคำตอบที่ดี ... โดยทั่วไปแล้วฉันต้องการเพิ่มเลเยอร์เพิ่มเติมสองสามชั้นสำหรับส่วนการดูแลระบบของฉัน แม้ว่าฉันจะใช้รูปแบบต่างๆในธีม แต่โดยทั่วไปแล้วจะมีอย่างใดอย่างหนึ่งต่อไปนี้:

• การรับรองความถูกต้องระดับที่สอง : อาจรวมถึงใบรับรองไคลเอ็นต์ (เช่นใบรับรอง x509) สมาร์ทการ์ดพื้นที่การ์ด ฯลฯ ...
• ข้อ จำกัด ของโดเมน / IP : ในกรณีนี้เฉพาะไคลเอนต์ที่มาจากโดเมนที่เชื่อถือได้ / ตรวจสอบได้ เช่นเครือข่ายย่อยภายใน ได้รับอนุญาตให้เข้าสู่พื้นที่ผู้ดูแลระบบ ผู้ดูแลระบบระยะไกลมักจะผ่านจุดเข้า VPN ที่เชื่อถือได้ดังนั้นเซสชันของพวกเขาจึงสามารถตรวจสอบได้และมักจะได้รับการปกป้องด้วยคีย์ RSA เช่นกัน หากคุณใช้ ASP.NET คุณสามารถทำการตรวจสอบเหล่านี้ได้อย่างง่ายดายใน HTTP ไปป์ไลน์ผ่านโมดูล HTTP ซึ่งจะป้องกันไม่ให้แอปพลิเคชันของคุณได้รับคำขอใด ๆ หากการตรวจสอบความปลอดภัยไม่เป็นที่พอใจ
• ล็อคการอนุญาตตาม IPrincipal & Principal : การสร้างหลักการที่กำหนดเองเป็นแนวทางปฏิบัติทั่วไปแม้ว่าข้อผิดพลาดทั่วไปจะทำให้แก้ไขได้และ / หรือนับสิทธิ์ได้ แม้ว่าจะไม่ใช่แค่ปัญหาผู้ดูแลระบบ แต่สิ่งสำคัญกว่าเนื่องจากที่นี่เป็นที่ที่ผู้ใช้มีแนวโน้มที่จะมีสิทธิ์ในระดับสูง ตรวจสอบให้แน่ใจว่าไม่เปลี่ยนรูปและไม่สามารถระบุได้ นอกจากนี้ตรวจสอบให้แน่ใจว่าการประเมินทั้งหมดสำหรับการอนุญาตเป็นไปตามหลักการ
• การยกระดับสิทธิ์ของสหพันธรัฐ : เมื่อบัญชีใด ๆ ได้รับสิทธิ์ตามจำนวนที่เลือกผู้ดูแลระบบและเจ้าหน้าที่รักษาความปลอดภัยทั้งหมดจะได้รับแจ้งทางอีเมลทันที สิ่งนี้ทำให้แน่ใจว่าหากผู้โจมตียกระดับสิทธิ์ที่เรารู้ทันที โดยทั่วไปสิทธิ์เหล่านี้เกี่ยวข้องกับสิทธิส่วนบุคคลสิทธิ์ในการดูข้อมูลที่ได้รับการคุ้มครองความเป็นส่วนตัวและ / หรือข้อมูลทางการเงิน (เช่นบัตรเครดิต)
• ออกสิทธิ์เท่าที่จำเป็นแม้แต่กับผู้ดูแลระบบ : สุดท้ายนี้อาจเป็นขั้นสูงสำหรับร้านค้าบางแห่ง สิทธิ์ในการให้สิทธิ์ควรรอบคอบที่สุดเท่าที่จะเป็นไปได้และควรครอบคลุมพฤติกรรมการทำงานที่แท้จริง แนวทาง Role-Based Security (RBS) โดยทั่วไปมักจะมีความคิดแบบกลุ่ม จากมุมมองด้านความปลอดภัยนี่ไม่ใช่รูปแบบที่ดีที่สุด แทนที่จะเป็น " กลุ่ม " เช่น " ตัวจัดการผู้ใช้ " ให้ลองแยกย่อยเพิ่มเติม ( เช่นสร้างผู้ใช้ผู้ใช้ที่ได้รับอนุญาตยกระดับ / เพิกถอนสิทธิ์การเข้าถึง ฯลฯ ...). สิ่งนี้อาจมีค่าใช้จ่ายเพิ่มขึ้นเล็กน้อยในแง่ของการดูแลระบบ แต่จะช่วยให้คุณมีความยืดหยุ่นในการกำหนดสิทธิ์ที่จำเป็นสำหรับกลุ่มผู้ดูแลระบบขนาดใหญ่เท่านั้น หากการเข้าถึงถูกบุกรุกอย่างน้อยก็อาจไม่ได้รับสิทธิ์ทั้งหมด ฉันต้องการรวมสิ่งนี้ไว้ในการอนุญาต Code Access Security (CAS) ที่รองรับโดย. NET และ Java แต่มันเกินขอบเขตของคำตอบนี้ อีกอย่างหนึ่ง ... ในแอปเดียวผู้ดูแลระบบไม่สามารถจัดการเปลี่ยนบัญชีผู้ดูแลระบบอื่น ๆ หรือกำหนดให้ผู้ใช้เป็นผู้ดูแลระบบได้ ซึ่งสามารถทำได้ผ่านไคลเอนต์ที่ถูกล็อกซึ่งมีเพียงไม่กี่คนเท่านั้นที่สามารถเข้าถึงได้

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

นอกจากนี้หากส่วนผู้ดูแลระบบอยู่ในไดเร็กทอรีย่อยที่แยกจากกันการรักษาความปลอดภัยนั้นด้วยการตรวจสอบสิทธิ์ของเว็บเซิร์ฟเวอร์ (.htaccess ใน Apache เป็นต้น) อาจเป็นความคิดที่ดีดังนั้นบางคนต้องใช้ทั้งรหัสผ่านและรหัสผ่านผู้ใช้

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

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

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

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

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

ดังนั้นหากฉันเข้าสู่ระบบให้ทำสิ่งต่างๆของผู้ใช้ตามปกติจากนั้นไปที่หน้าผู้ดูแลระบบสร้างรหัสเซสชันของฉันใหม่ ถ้าฉันออกจากหน้าผู้ดูแลระบบไปยังหน้าผู้ใช้ปกติให้สร้าง ID ของฉันใหม่อีกครั้ง

มีรหัสผ่านผู้ดูแลระบบที่ดี

ไม่ใช่"123456"ลำดับของตัวอักษรตัวเลขและอักขระพิเศษที่มีความยาวเพียงพอกล่าวคือ 15-20 อักขระ ชอบ"ksd83,'|4d#rrpp0%27&lq(go43$sd{3>".

เพิ่มการหยุดชั่วคราวสำหรับการตรวจสอบรหัสผ่านแต่ละครั้งเพื่อป้องกันการโจมตีด้วยกำลังดุร้าย

สิ่งอื่น ๆ ที่ควรพิจารณามีดังนี้

1. ทางเลือกหนึ่งที่ควรพิจารณาโดยเฉพาะอย่างยิ่งหากคุณจัดการคอมพิวเตอร์ของผู้ดูแลระบบหรือมีความสามารถในทางเทคนิคคือการใช้บางอย่างตามใบรับรอง SSL สำหรับการตรวจสอบสิทธิ์ไคลเอ็นต์ RSA keyfobs และสิ่งที่ไม่สามารถใช้เพื่อเพิ่มความปลอดภัย
2. หากคุณใช้คุกกี้เลย - บางทีสำหรับโทเค็นการตรวจสอบสิทธิ์ / เซสชัน - คุณอาจต้องการให้แน่ใจว่าคุกกี้จะถูกส่งไปยังหน้าผู้ดูแลระบบ วิธีนี้ช่วยลดความเสี่ยงที่เกิดขึ้นกับไซต์ของคุณโดยการขโมยคุกกี้โดยการโจมตีชั้น 1/2 หรือ XSS ซึ่งสามารถทำได้อย่างง่ายดายโดยให้ส่วนผู้ดูแลระบบอยู่ในชื่อโฮสต์หรือโดเมนอื่นรวมทั้งตั้งค่าสถานะความปลอดภัยด้วยคุกกี้
3. การ จำกัด ด้วย IP อาจเป็นเรื่องที่ชาญฉลาดเช่นกันและหากคุณมีผู้ใช้ทั่วอินเทอร์เน็ตคุณยังสามารถทำได้หากมี VPN ที่เชื่อถือได้ที่พวกเขาสามารถเข้าร่วมได้

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

วิธีที่เข้มงวดคือการมี "ฟาร์ม" สองแห่งที่แตกต่างกันซึ่งรวมถึงฐานข้อมูลเซิร์ฟเวอร์และทั้งหมดและย้ายข้อมูลจากฟาร์มหนึ่งไปยังอีกฟาร์มหนึ่ง ระบบที่ทันสมัยขนาดใหญ่ส่วนใหญ่ใช้แนวทางนี้ (วิกเน็ตต์ SharePoint ฯลฯ ) โดยปกติจะเรียกว่ามี "ขั้นตอนการแก้ไข" -> "ขั้นตอนการแสดงตัวอย่าง" -> "ขั้นตอนการแสดง" ที่แตกต่างกัน วิธีนี้ช่วยให้คุณจัดการกับเนื้อหา / config ในลักษณะเดียวกับที่คุณปฏิบัติกับโค้ด (dev-> qa-> prod)

หากคุณหวาดระแวงน้อยลงคุณสามารถมีฐานข้อมูลเดียว แต่มีเฉพาะส่วนผู้ดูแลระบบของคุณในเซิร์ฟเวอร์ "การแก้ไข" ฉันหมายถึงมีเพียงสคริปต์ / ไฟล์การแก้ไขที่วางไว้บนเซิร์ฟเวอร์การแก้ไข

ตามปกติแล้วขั้นตอนการแก้ไขควรมีเฉพาะในอินทราเน็ตเฉพาะที่และ / หรือใช้ VPN

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

โปรดทราบว่าสิ่งต่างๆเช่น "มีรหัสผ่านผู้ดูแลระบบที่คาดเดายาก" เป็นสิ่งที่ดี แต่ยังคงปล่อยให้ผู้ดูแลระบบของคุณเปิดรับสิ่งต่างๆ

ขึ้นอยู่กับประเภทของข้อมูลที่คุณต้องการปกป้อง (ข้อกำหนดทางกฎหมายและอื่น ๆ )

• คำแนะนำมากมายเกี่ยวกับการพิสูจน์ตัวตน .. ฉันคิดว่าคุณควรพิจารณาใช้การตรวจสอบสิทธิ์ OpenId / Facebook ในการเข้าสู่ระบบ (พวกเขามักจะใช้ทรัพยากรมากขึ้นในการรักษาความปลอดภัยการตรวจสอบสิทธิ์จากนั้นคุณ)

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

ฉันไม่สังเกตเห็นใครพูดถึงการจัดเก็บ / การตรวจสอบรหัสผ่านผู้ดูแลระบบ โปรดอย่าจัดเก็บ PW เป็นข้อความธรรมดาและไม่ควรแม้แต่สิ่งที่สามารถย้อนกลับได้ - ใช้บางอย่างเช่นแฮช MD5 ที่มีรสเค็มเพื่อที่อย่างน้อยที่สุดหากมีคนดึง "รหัสผ่าน" ที่เก็บไว้ออกมาพวกเขาไม่มี สิ่งที่มีประโยชน์อย่างยิ่งเว้นแต่พวกเขาจะมีโครงการเกลือของคุณด้วย

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

บางทีคุณอาจใส่ส่วนการดูแลระบบไว้ในไดเร็กทอรีขนาดใหญ่เช่น

http://domain.com/sub/sub/sub/sub/sub/index.php

แต่นั่นไม่ใช่เรื่องดีเลยนะฮะ

บางทีคุณอาจรวมสตริงข้อความค้นหาไว้ในโฮมเพจเช่น:

http://domain.com/index.php?display=true

เมื่อเป็นเช่นนั้นฟิลด์ชื่อผู้ใช้และรหัสผ่านจะปรากฏขึ้น