SSH access gateway สำหรับเซิร์ฟเวอร์จำนวนมาก


12

การจัดการเซิร์ฟเวอร์หลายเครื่องเกิน 90 ในปัจจุบันด้วย 3 devops ผ่าน Ansible ทั้งหมดใช้งานได้ดี แต่มีปัญหาด้านความปลอดภัยที่ใหญ่มากในขณะนี้ devop แต่ละตัวใช้คีย์ ssh ในเครื่องของตนเองเพื่อเข้าถึงเซิร์ฟเวอร์โดยตรง อุปกรณ์ devop แต่ละตัวใช้แล็ปท็อปและแล็ปท็อปแต่ละเครื่องอาจถูกบุกรุกดังนั้นการเปิดเครือข่ายทั้งหมดของเซิร์ฟเวอร์ที่ใช้ในการโจมตี

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

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

ป้อนคำอธิบายรูปภาพที่นี่

นี่เป็นตรรกะที่ดีหรือไม่? มีใครเห็นวิธีแก้ปัญหาเพื่อป้องกันปัญหานี้อยู่แล้ว?


1
ได้เวลาย้ายไปที่ AWX / Tower แล้ว
Michael Hampton

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

2
คำตอบคือฟรี IPA
Jacob Evans

คำตอบ:


22

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

นี่คือวิธีการมาตรฐาน


2
ดียิ่งขึ้น: ทำสิ่งที่ @Sven พูด แต่เพิ่ม 2FA ที่ jump host เพราะคุณเพิ่งเชื่อมต่อโดยตรงจากแล็ปท็อปเมื่อคุณต้องการด้วยตนเองใช่ไหม มีสิ่งใดที่ทำงานอัตโนมัติจากเซิร์ฟเวอร์ภายในโฮสต์กระโดดหรือไม่
Adam

1
หากคุณมีผู้ออกใบรับรองท้องถิ่น (ผู้ใต้บังคับบัญชาหรือแยก) คุณสามารถใช้ใบรับรองเหล่านั้นกับ SSH เพื่อให้คุณสามารถทำให้ใบรับรองที่ถูกบุกรุกที่เชื่อนั้นเป็นอันตรายจากส่วนกลาง
Randall

11

วิศวกรไม่ควรเรียกใช้ ansible โดยตรงจากแล็ปท็อปของพวกเขายกเว้นกรณีนี้เป็นสภาพแวดล้อม dev / test

ให้มีเซิร์ฟเวอร์ส่วนกลางที่ดึง runbooks ออกจาก git แทน สิ่งนี้ทำให้สามารถควบคุมเพิ่มเติมได้ (สี่ตา, การตรวจสอบโค้ด)

รวมสิ่งนี้กับป้อมปราการหรือกระโดดข้ามโฮสต์เพื่อ จำกัด การเข้าถึงเพิ่มเติม


1
อันที่จริงนี่เป็นปัญหาที่ AWX (หรือ Tower เวอร์ชั่นเชิงพาณิชย์) แก้ไขได้
Michael Hampton

1

Netflix ใช้การตั้งค่าของคุณและปล่อยซอฟต์แวร์ฟรีบางอย่างเพื่อช่วยสถานการณ์ดังกล่าว

ดูวิดีโอนี้https://www.oreilly.com/learning/how-netflix-gives-all-its-engineers-ssh-accessหรืองานนำเสนอนี้ที่https://speakerdeck.com/rlewis/how-netflix-gives- all- ของมัน - วิศวกร -ssh-access-to-instance-running-in-productionกับจุดหลัก:

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

ซอฟต์แวร์ของพวกเขามีให้ที่นี่: https://github.com/Netflix/bless

สิ่งที่น่าสนใจนำไปสู่สิ่งที่แม้ว่าคุณจะไม่ได้ใช้โซลูชั่นทั้งหมด:

  • พวกเขาใช้ใบรับรอง SSH แทนการใช้กุญแจ คุณสามารถใส่ meta-data ได้มากขึ้นในใบรับรองดังนั้นจึงทำให้มีข้อ จำกัด มากมายตามข้อกำหนดและยังช่วยให้การตรวจสอบง่ายขึ้น
  • ใช้ระยะสั้นมาก (เช่น 5 นาที) ความถูกต้องของใบรับรอง (เซสชัน SSH ยังคงเปิดอยู่แม้หลังจากใบรับรองหมดอายุ)
  • การใช้ 2FA เพื่อทำให้การเขียนสคริปต์ทำได้ยากและบังคับให้ผู้พัฒนาค้นหาโซลูชันอื่น ๆ
  • submodule เฉพาะนอกโครงสร้างพื้นฐานของพวกเขาและรักษาความปลอดภัยอย่างถูกต้องผ่านกลไกความปลอดภัยที่นำเสนอโดยคลาวด์ที่มันทำงานจัดการการสร้างใบรับรองแบบไดนามิกเพื่อให้นักพัฒนาแต่ละคนสามารถเข้าถึงโฮสต์ใด ๆ

1

OneIdentity (ex-Balabit) SPSคือสิ่งที่คุณต้องการในสถานการณ์นี้ ด้วยอุปกรณ์นี้คุณสามารถจัดการข้อมูลประจำตัวของผู้ใช้บนพื้นเครื่องติดตามพฤติกรรมของผู้ใช้ตรวจสอบและแจ้งเตือนและทำดัชนีสิ่งที่ผู้ใช้ทำเพื่อรีวิวในภายหลัง


0

คำแนะนำของฉันคือไม่อนุญาตให้เข้าถึง SSH จากเครื่องผู้ใช้

แต่คุณควร

  1. โฮสต์ playbooks ใน Git
  2. เปลี่ยน "เซิร์ฟเวอร์การเข้าถึง" เป็นเซิร์ฟเวอร์เจนกินส์
  3. ให้สิทธิ์การเข้าถึงเจนกินส์ที่จำเป็นเฉพาะกับผู้ใช้งาน
  4. ดำเนินการ Ansible เล่นกับเจนกินส์มากกว่างานสร้างผ่าน HTTP
  5. เป็นมาตรการรักษาความปลอดภัยเพิ่มเติมให้ปิดการใช้งาน Jenkins CLI หากจำเป็น

รูปแบบการดำเนินการตัวอย่าง

  1. ปลั๊กอินที่ต้องใช้ Jenkins Ansible: https://wiki.jenkins.io/display/JENKINS/Ansible+Plugin

หรือ

  1. เชลล์คลาสสิก - ดำเนินการประเภทของงาน เพิ่มขั้นตอนการสร้างของคุณด้วยตนเองรวมถึงการชำระเงิน git

หากคุณถูก จำกัด ด้วยทรัพยากรของเซิร์ฟเวอร์เซิร์ฟเวอร์ Jenkins เดียวกันสามารถโฮสต์ Git (scm-manager) ได้เช่นกันแม้ว่าจะมีความเสี่ยงด้านความปลอดภัยเพิ่มเติมหากหนึ่งในนักพัฒนาเครื่องติดไวรัส คุณอาจสามารถบรรเทาปัญหานี้ได้โดยยกเลิกการเชื่อมต่อเซิร์ฟเวอร์ Jenkins จากอินเทอร์เน็ตและแก้ไขการพึ่งพา Ansible ในเครื่อง

โดยการใช้ไซต์ของเรา หมายความว่าคุณได้อ่านและทำความเข้าใจนโยบายคุกกี้และนโยบายความเป็นส่วนตัวของเราแล้ว
Licensed under cc by-sa 3.0 with attribution required.