การใช้ sudo จากเจนกินส์นั้นแย่หรือไม่?


11

ฉันใช้ปลั๊กอินเผยแพร่ผ่าน SSHเพื่อปรับใช้แอพของฉันจากJenkinsสภาพแวดล้อมที่แตกต่างกัน งานปรับใช้บางอย่างทำหน้าที่เตรียมสภาพแวดล้อมและสิ่งต่าง ๆ เช่นหยุดและเริ่มบริการระบบเซิร์ฟเวอร์ของแอพใหม่ sudoบางส่วนของคำสั่งดังกล่าวจำเป็นต้องมี

ฉันแค่อยากรู้ว่ามันอาจเป็นวิธีปฏิบัติด้านความปลอดภัยที่ไม่ดีหรือไม่ที่ต้องใช้ sudo ในการเผยแพร่ทางไกล เราควรเปลี่ยนนโยบายความปลอดภัยของโฮสต์เป้าหมายเพื่อให้สามารถใช้ฟังก์ชั่นที่ต้องการโดยไม่ต้อง sudo ได้หรือไม่?

คำตอบ:


6

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

  • การตรวจสอบบัญชี เมื่อคุณ sudo ระบบจะบันทึกว่าใครเป็นคน sudoed และคำสั่งที่พวกเขาวิ่ง นี่เป็นการเพิ่มข้อตกลงเป็นอย่างมากเมื่อคุณต้องการย้อนกลับไปและคิดว่าเกิดอะไรขึ้น - เพื่อกำหนดความผิด, จับกิจกรรมที่เลวร้ายหรือเพื่อวัตถุประสงค์ในการแก้ไขปัญหา (เกิดอะไรขึ้นในคืนก่อนเวลา 19.00 น.

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

  • การทำให้แข็ง เป็นไปได้ที่จะปิดการใช้งานรูท เช่นเดียวกับในทุกเจตนาและวัตถุประสงค์มันไม่มีอยู่และมีประโยชน์ / ใช้งานได้ในโหมดผู้ใช้คนเดียว - ต้องรีบูตเซิร์ฟเวอร์ (และเหตุผลเดียวที่อนุญาตให้มีการกู้คืนรหัสผ่าน) sudo suไม่ทำงานอีกต่อไป สิ่งนี้ทำได้โดยการตั้งค่าเชลล์ของรูทเป็น / bin / nologin ซึ่งเป็นวิธีที่ดีในการป้องกันช่องโหว่การเลื่อนระดับรูทจำนวนมาก แน่นอนว่าคุณใช้สัญลักษณ์แสดงหัวข้อย่อยด้านบนอย่างถูกต้อง (และคุณยังสามารถให้สิทธิ์ผู้ดูแลระบบแก่ผู้ใช้ที่เฉพาะเจาะจง แต่สิ่งนี้จะบั่นทอนความปลอดภัยของคุณ)

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

ในระยะสั้นความปลอดภัยมีความซับซ้อน แต่ sudo เป็นเครื่องมือที่ยอดเยี่ยมในการสร้างสภาพแวดล้อมที่ปลอดภัยและผู้คนจำนวนมากควรใช้มันอย่างเต็มที่


7

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

มีสิ่งอื่น ๆ ที่คุณสามารถทำได้เพื่อให้ปลอดภัยยิ่งขึ้นแม้ว่า:

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

ที่จริงแล้วฉันเพิ่งกำหนดค่างาน SSH ของฉันและมันไม่ต้องการที่จะทำงานsudo: "sudo: ขอโทษคุณต้องมี tty ในการเรียกใช้ sudo"
amphibient

1
คุณอาจต้องให้ตัวเลือก หรือโน้มน้าวให้ sudo ไม่ต้องใช้มันเหมือนunix.stackexchange.com/questions/122616/…ssh-t
ลูกไก่

ฉันจะจัดหาตัวเลือกให้ SSH เมื่อมันถูกเรียกจากเจนกินส์ได้อย่างไร
สัตว์สะเทินน้ำสะเทินบก

ฉันไม่แน่ใจเกี่ยวกับเรื่องนี้ คุณลองปรับเปลี่ยนsudoตามที่ลิงค์แสดงหรือไม่
ลูกไก่

1
ฉันจัดการเพื่อเปิดใช้งาน sudo จาก Jenkins โดยเปลี่ยน sudoers บนรีโมทโฮสต์ (เป้าหมาย SSH) เพื่อไม่ต้องการ tty (ใส่ความเห็นDefaults requiretty)
amphibient
โดยการใช้ไซต์ของเรา หมายความว่าคุณได้อ่านและทำความเข้าใจนโยบายคุกกี้และนโยบายความเป็นส่วนตัวของเราแล้ว
Licensed under cc by-sa 3.0 with attribution required.