จะรักษาแหล่งเก็บข้อมูลส่วนกลางไว้ที่ไหน?

แนวปฏิบัติที่ดีที่สุดในอุตสาหกรรมเกี่ยวกับความปลอดภัยในการเข้าถึงซอร์สโค้ดคืออะไร ฉันคิดว่าการเชื่อมต่อ SSL ผ่าน apache อนุญาตให้ผ่านเซิร์ฟเวอร์ของเราบนพอร์ตที่ไม่ชัดเจนซึ่งไม่ขัดแย้งกับสิ่งอื่นใด สิ่งที่รบกวนจิตใจฉันคือการจัดเก็บซอร์สโค้ดบนเซิร์ฟเวอร์สาธารณะซึ่งไม่เพียงเข้าถึงได้ผ่าน LAN เท่านั้น นอกจากนี้เซิร์ฟเวอร์นี้มีประโยชน์หลายอย่าง Apache กำลังให้บริการเว็บไซต์ภายใน บริษัท อื่น ๆ อยู่แล้ว ฉันต้องการให้ทุกคนสามารถเข้าถึงซอร์สโค้ดได้จากทุกที่ (บ้านสนามบินหรืออะไรก็ตาม) ตราบใดที่พวกเขามีข้อมูลประจำตัวที่ถูกต้อง ข้อเสนอแนะ?

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

ฉันไม่แน่ใจเหมือนกันว่าทำไมผู้คนถึงคิดว่าวิธี VPN นั้นดีที่สุด ไม่จำเป็นว่าจะปลอดภัยกว่านี้อีกแล้วมีเพียงข้อเสนอเดียวที่ฉันสามารถนึกได้

ตัวอย่างเช่น PPTP เป็นที่รู้จักกันว่ามีความปลอดภัยน้อยกว่าอุดมคติ แต่ฉันเชื่อว่ามันได้รับการปรับปรุงบ้างตั้งแต่เปิดตัวครั้งแรก ... ดังนั้นโปรดระวังโซลูชัน VPN ที่คุณใช้ ฉันจะไปกับ OpenVPN หรือ IPSEC

อย่างไรก็ตามคุณไม่สามารถเอาชนะความสะดวกสบายของ SSL / TLS ได้หากไม่มี VPN (โปรดอ่านเพิ่มเติม) และเพื่อให้ปลอดภัยยิ่งขึ้นคุณสามารถทำใบรับรองเท่านั้น

อย่างไรก็ตามหากคุณคิดว่าคุณอาจเสนอบริการอื่นนอกเหนือจากการควบคุมแหล่งที่มาให้พิจารณาโซลูชัน VPN เพราะคุณจะได้รับบริการอื่น ๆ

ข้อเสียของการใช้ VPN คือพีซีของคุณจะกลายเป็นส่วนหนึ่งของเครือข่ายที่เชื่อมต่อได้อย่างมีประสิทธิภาพ นั่นก็สามารถเป็นข้อได้เปรียบ แต่ถ้าคุณอยู่ห่างจากบ้านเป็นล้านไมล์และการเชื่อมต่อเครือข่ายไปยังฐานบ้านนั้นไม่เร็วเกินไปทุกครั้งที่คุณต้องการทำ diff หรือ check in หรือ out code คุณอาจพบว่าคุณกำลังเชื่อมต่อและยกเลิกการเชื่อมต่อ VPN

ฉันสามารถพูดจากประสบการณ์ส่วนตัวที่นี่เพราะฉันเป็นนักพัฒนาและมันเป็นความเจ็บปวดที่แท้จริงในก้นที่จะทำสิ่งนี้ !!! เป็นการดีที่ทั้งสองตัวเลือกเป็นที่ต้องการ

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

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

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

มาตรฐานอุตสาหกรรมอาจขึ้นอยู่กับอุตสาหกรรมของคุณ (หรือลูกค้าของคุณ) :-)

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

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

ฉันชอบ VPN อีกทางเลือกหนึ่งคืออุโมงค์ SSH ซึ่งฉันคิดว่าในแง่ของการใช้งานจริงนั้นเป็น VPN ประเภทหนึ่งอยู่แล้ว

ทำให้เป็นแบบภายในเท่านั้นและใช้โซลูชัน VPN สำหรับผู้ใช้ระยะไกล / Doh- ซ้ำกัน

หากคุณต้องการเข้าถึงได้จากทุกที่คุณต้องมีเซิร์ฟเวอร์สาธารณะที่ชัดเจนมาก

บนเซิร์ฟเวอร์นั้นคุณต้องการเปิดเผยให้น้อยที่สุดโดยเฉพาะ Mercurial / Subversion และไม่มีอะไรอื่น นี่คือเพื่อป้องกันการละเมิดความปลอดภัยจากการแพร่กระจายจากการควบคุมแหล่งที่มาไปยังส่วนที่เหลือของ บริษัท ของคุณ ด้วยเหตุนี้ฉันจะเห็นด้วยกับ Mattเมื่อเขาบอกว่า VPN อาจเป็นอันตราย: มันให้การเข้าถึงที่กว้างกว่าที่จำเป็น

สำหรับ Mercurial คุณสามารถล็อคสิ่งต่าง ๆ ได้อย่างแน่นหนาโดยใช้hg-sshเพื่อ จำกัด คำสั่งที่มีให้กับลูกค้าที่เชื่อมต่อผ่าน SSH ด้วยการใช้ SSH คุณสามารถเรียกร้องให้ลูกค้าใช้การพิสูจน์ตัวตนด้วยรหัสสาธารณะแทนรหัสผ่านได้อย่างง่ายดาย สิ่งนี้จะช่วยปกป้องเซิร์ฟเวอร์ของคุณจากการโจมตีที่ดุร้าย

แม้ว่ารหัส SSH จะถูกบุกรุก (อาจเป็นเพราะรหัสผ่านที่อ่อนแอและแล็ปท็อปที่จัดเก็บนั้นถูกขโมย) ดังนั้นความเสียหายที่ร้ายแรงที่สุดที่ผู้โจมตีสามารถทำได้คือการเพิ่มประวัติขยะใน Mercurial โปรโตคอลที่ใช้นั้นต่อท้ายเท่านั้นจึงไม่สามารถลบhg pushได้

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