เก็บคีย์ลงนามของ CA ใน OpenVPN ไว้บอก /etc/openvpn

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

สิ่งที่อยู่ในพื้นที่ทำงานของ CA

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

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

ใบรับรองสาธารณะของ CA ต่างออกไป มันมีไว้เพื่อแจกจ่าย และเป็นสิ่งที่ไคลเอนต์กับเซิร์ฟเวอร์ใช้ตรวจสอบกันและกัน

สิ่งที่เดมอนอ่านตอนเริ่มทำงาน

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

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

systemctl show -p User -p Group -p ReadOnlyPaths [email protected]
stat -c '%a %U:%G' /etc/openvpn/server/server.key
runuser -u openvpn -- test -r /etc/openvpn/server/server.key; echo $?

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

เส้นทางความล้มเหลวสองทางควรแยกจากกันก่อนจะเปลี่ยนสิทธิ์ใด ๆ ความล้มเหลวในการลงนามชี้ไปที่ไดเรกทอรี PKI สิทธิ์การค้นหาในไดเรกทอรีแม่ และบัญชีที่รันผู้ออก ความล้มเหลวในการเริ่มทำงานชี้ไปที่ยูนิต ไดเรกทอรีทำงานของมัน และเส้นทางที่ระบุในไฟล์ตั้งค่าของเซิร์ฟเวอร์ การทำให้ต้นไม้ทั้งต้นอ่านได้สำหรับทุกคนไม่ได้แก้ทั้งสองอย่าง และยังลบเส้นแบ่งที่ทั้งสองฝ่ายต้องพึ่งพา

ทำไมการคัดลอกคีย์ CA ไปยังเซิร์ฟเวอร์จึงล้มเหลวในภายหลัง

สำเนามักเริ่มจากการแก้จุดบกพร่อง บางคนต้องการต่ออายุไคลเอนต์บนโฮสต์ VPN คีย์ CA จึงไปอยู่ใน /etc/openvpn และการต่ออายุก็สำเร็จ งานตรงหน้าสำเร็จ แต่เส้นแบ่งหายไป

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

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

บัญชี ไดเรกทอรี และข้อมูลสำรอง

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

หลังการเพิกถอน ให้อัปเดตไฟล์ CRL ที่ไฟล์ตั้งค่าของเซิร์ฟเวอร์ระบุ แล้วโหลดบริการใหม่เพื่อให้การเชื่อมต่อใหม่อ่านมัน เอกสาร Easy-RSA ครอบคลุมโครงสร้างพื้นที่ทำงานและขั้นตอนการลงนาม กฎความเป็นเจ้าของรอบ ๆ ยังคงเป็นการตัดสินใจเกี่ยวกับโฮสต์ของคุณ ยืนยันว่าบริการโหลดอะไรด้วย openssl crl -in /etc/openvpn/crl.pem -noout -lastupdate -nextupdate แทนที่จะถือว่าการโหลดใหม่รับมันไปแล้ว

การทดสอบที่พิสูจน์การแยก

ตรวจกรณีลบ ไม่ใช่แค่กรณีที่ทำงานได้ ลงนามใบรับรองจากบัญชีผู้ออกตามที่ออกแบบไว้ แล้วยืนยันว่าบัญชีเดียวกันไม่สามารถเริ่มบริการหรืออ่านคีย์ส่วนตัวของเซิร์ฟเวอร์ได้ จากนั้นยืนยันว่าบัญชีของเดมอนอ่านคีย์ส่วนตัวของ CA ไม่ได้

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