RDS ส่วนตัวจาก EC2: VPC เดียวกัน, peering หรืออย่างอื่น?

แล็ปท็อปของนักพัฒนาซอฟต์แวร์เข้าถึงอินสแตนซ์ RDS ส่วนตัวผ่าน VPN ของพนักงาน แต่แอปพลิเคชันบน EC2 เชื่อมต่อไม่ได้เลย นี่ไม่ใช่การติดตั้งที่พัง แล็ปท็อปมีอุโมงค์ที่อินสแตนซ์ EC2 ไม่เคยได้รับสืบทอด และ «ส่วนตัว» ใน RDS หมายความว่าฐานข้อมูลไม่มีปลายทางสาธารณะ ไม่ใช่หมายความว่าผู้ใช้ VPN ที่เป็นมนุษย์เป็นผู้เรียกที่ได้รับอนุญาตเพียงรายเดียว แอปพลิเคชันต้องการเส้นทางที่ได้รับอนุญาตของตัวเอง ความสัมพันธ์ของตัวเองกับกลุ่มความปลอดภัย และตัวตนของตัวเองในฐานข้อมูล และลำดับที่คุณเลือกสามสิ่งนี้ช่วยประหยัดการดีบักส่วนใหญ่ ตัดสินใจเส้นทางก่อน จากนั้นจึงกำหนดสิทธิ์ แล้วตรวจสอบจากสภาพแวดล้อมที่ติดตั้งไว้แทนที่จะตรวจสอบจากโต๊ะทำงานของคุณ

VPN ของแล็ปท็อปไม่ใช่เส้นทางของแอปพลิเคชัน

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

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

การตัดสินใจ 1: VPC เดียวกัน เส้นทางตรง

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

aws ec2 authorize-security-group-ingress --group-id sg-0db123   --protocol tcp --port 5432 --source-group sg-0app456

aws rds describe-db-instances --db-instance-identifier prod-db   --query 'DBInstances[0].{Endpoint:Endpoint.Address,Port:Endpoint.Port,Public:PubliclyAccessible,Groups:VpcSecurityGroups}'

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

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

การตัดสินใจ 2: VPC อื่นหรือบัญชีอื่น

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

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

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

การตัดสินใจ 3: ฐานข้อมูลยอมรับตัวตนใด

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

ใช้ชื่อปลายทาง RDS ในการกำหนดค่าของแอปพลิเคชันแทนที่อยู่ที่จับได้จากการค้นหาครั้งเดียว การสลับเมื่อล้มเหลวของ Multi-AZ เปลี่ยนที่อยู่เบื้องหลังชื่อนั้น และแอปพลิเคชันที่ปักหมุดกับ IP จะล้มเหลวในขณะที่ต้องการมันพอดี เปิดการตรวจสอบ TLS ของเอนจินไว้แทนที่จะปิดเพื่อให้ข้อผิดพลาดหายไป เพราะความล้มเหลวในการตรวจสอบบอกอะไรบางอย่างเกี่ยวกับปลายทางที่คุณเข้าถึง

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

ตรวจสอบจากสภาพแวดล้อมที่ติดตั้งไว้

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

psql "host=prod-db.abc123.eu-west-1.rds.amazonaws.com port=5432 dbname=app sslmode=verify-full" -c 'select 1'

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