ปกป้องและแยกเวิร์กโหลดที่อ่อนไหวสูงของคุณด้วยเอนคลาฟที่ปลอดภัย
คำแนะนำนี้จะแสดงให้คุณเห็นถึงวิธีที่จะสามารถสร้างสถาปัตยกรรมระบบคลาวด์ที่ครอบคลุมสำหรับเวิร์กโหลดที่ละเอียดอ่อนในด้านความมั่นคงของชาติ กลาโหม และการบังคับใช้กฎหมายของประเทศ ด้วยการใช้สถาปัตยกรรมหลายบัญชีบน AWS คุณสามารถส่งมอบภารกิจของคุณในขณะที่รักษาข้อมูลที่ละเอียดอ่อนและเวิร์กโหลดให้ปลอดภัย คำแนะนำนี้ออกแบบมาเพื่อช่วยให้คุณปฏิบัติตามข้อกำหนดด้านความปลอดภัยและการปฏิบัติตามข้อกำหนดที่เข้มงวดและไม่เหมือนใคร โดยกล่าวถึงการจัดการตัวตนและการเข้าถึงส่วนกลาง การกำกับดูแล การรักษาความปลอดภัยของข้อมูล การทำข้อมูลบันทึกที่ครอบคลุม และการออกแบบเครือข่ายและการแบ่งส่วนตามกรอบความปลอดภัยต่าง ๆ ของสหรัฐอเมริกา
โปรดทราบ: [ข้อสงวนสิทธิ์]
แผนผังสถาปัตยกรรม
-
ภาพรวม
-
บัญชีการจัดการองค์กร
-
บัญชีรักษาความปลอดภัย
-
บัญชีโครงสร้างพื้นฐาน
-
แอปพลิเคชัน ชุมชน ทีม หรือบัญชีกลุ่ม (ละเอียดอ่อน)
-
ภาพรวม
-
แผนผังสถาปัตยกรรมนี้ให้ภาพรวมของวิธีการกำหนดค่าเวิร์กโหลดหลายบัญชีที่ครอบคลุมพร้อมข้อกำหนดด้านความปลอดภัยและการปฏิบัติตามข้อกำหนดที่ไม่ซ้ำกัน สำหรับรายละเอียดเพิ่มเติมเกี่ยวกับวิธีการปรับใช้คำแนะนำนี้ ให้เปิดแท็บอื่น ๆ
คลิกเพื่อขยาย
ขั้นตอนที่ 1
องค์กรใน AWS Organizations ที่มีหลายบัญชี โดยได้รับคำแนะนำจากนโย บายการควบคุมบริการ (SCP): องค์กรจัดกลุ่มบัญชี AWS แยกต่างหากหลายบัญชี ซึ่งควบคุมโดยหน่วยงานลูกค้าเดียว บัญชี AWS แยกต่างหากให้การแยกระนาบควบคุมและระนาบข้อมูลที่แข็งแกร่งระหว่างเวิร์กโหลดหรือสภาพแวดล้อม ราวกับว่าเป็นเจ้าของของโดยลูกค้า AWS ที่แตกต่างกันขั้นตอนที่ 2
บัญชีการจัดการถูกใช้เพื่อสร้างองค์กร จากบัญชีการจัดการขององค์กร คุณสามารถทำสิ่งต่อไปนี้:- สร้างบัญชีในองค์กรและจัดการนโยบายสำหรับหน่วยในองค์กรทั้งหมด (OU)
- นำ OU ต่อไปนี้เข้าร่วมกับองค์กร:
- OU การรักษาความปลอดภัย
- OU โครงสร้างพื้นฐาน
- OU แอปพลิเคชันที่ละเอียดอ่อน
แต่ละ OU จะมีบัญชีสมาชิกอย่างน้อยหนึ่งบัญชีหรือ OU ที่ซ้อนกัน ต่อการออกแบบ
ขั้นตอนที่ 3
OU ของแอปพลิเคชันจะมี OU ที่ซ้อนกันหลายรายการเฉพาะที่มีให้กับการส่งมอบแอปพลิเคชันและการจัดการวงจรชีวิตและจะรวมถึงสิ่งต่อไปนี้:- Dev OU
- Test OU
- Prod OU
- Shared OU
นอกจากนี้ OU ของ Sandbox ยังได้รับการจัดเตรียมไว้เป็นเวิร์กโหลดที่ไม่ละเอียดอ่อน
ขั้นตอนที่ 1
องค์กรใน AWS Organizations ที่มีหลายบัญชี โดยได้รับคำแนะนำจากนโย บายการควบคุมบริการ (SCP): องค์กรจัดกลุ่มบัญชี AWS แยกต่างหากหลายบัญชี ซึ่งควบคุมโดยหน่วยงานลูกค้าเดียว บัญชี AWS แยกต่างหากให้การแยกระนาบควบคุมและระนาบข้อมูลที่แข็งแกร่งระหว่างเวิร์กโหลดหรือสภาพแวดล้อม ราวกับว่าเป็นเจ้าของของโดยลูกค้า AWS ที่แตกต่างกันขั้นตอนที่ 2
บัญชีการจัดการถูกใช้เพื่อสร้างองค์กร จากบัญชีการจัดการขององค์กร คุณสามารถทำสิ่งต่อไปนี้:- สร้างบัญชีในองค์กรและจัดการนโยบายสำหรับหน่วยในองค์กรทั้งหมด (OU)
- นำ OU ต่อไปนี้เข้าร่วมกับองค์กร:
- OU การรักษาความปลอดภัย
- OU โครงสร้างพื้นฐาน
- OU แอปพลิเคชันที่ละเอียดอ่อน
แต่ละ OU จะมีบัญชีสมาชิกอย่างน้อยหนึ่งบัญชีหรือ OU ที่ซ้อนกัน ต่อการออกแบบ
ขั้นตอนที่ 3
OU ของแอปพลิเคชันจะมี OU ที่ซ้อนกันหลายรายการเฉพาะที่มีให้กับการส่งมอบแอปพลิเคชันและการจัดการวงจรชีวิตและจะรวมถึงสิ่งต่อไปนี้:- Dev OU
- Test OU
- Prod OU
- Shared OU
นอกจากนี้ OU ของ Sandbox ยังได้รับการจัดเตรียมไว้เป็นเวิร์กโหลดที่ไม่ละเอียดอ่อน
-
บัญชีการจัดการองค์กร
-
แผนผังสถาปัตยกรรมนี้แสดงให้เห็นว่าองค์กรสามารถจัดกลุ่มบัญชีหลายบัญชีได้อย่างไร ทั้งหมดควบคุมโดยหน่วยงานลูกค้าเดียว ทำตามขั้นตอนในแผนผังสถาปัตยกรรมนี้เพื่อปรับใช้ส่วนของบัญชีการจัดการองค์กรของคำแนะนำนี้
คลิกเพื่อขยาย
ขั้นตอนที่ 1
องค์กรที่มีหลายบัญชี: องค์กรจัดกลุ่มบัญชี AWS แยกต่างหากหลายบัญชี ซึ่งควบคุมโดยหน่วยงานลูกค้าเดียว สิ่งนี้จะรวมการเรียกเก็บเงิน จัดกลุ่มบัญชีโดยใช้ OU และอำนวยความสะดวกในการนำไปใช้จริงกับการควบคุมป้องกันขององค์กรโดยใช้ SCPขั้นตอนที่ 2
การควบคุมความปลอดภัยเชิงป้องกัน: การควบคุมเหล่านี้ ซึ่งดำเนินการโดย SCP ช่วยปกป้องสถาปัตยกรรม ป้องกันการปิดใช้งานกฎควบคุมระบบและบล็อกพฤติกรรมของผู้ใช้ที่ไม่พึงประสงค์ SCP มีกลไกกฎควบคุมระบบที่ใช้หลักในการปฏิเสธการดำเนินงาน API เฉพาะหรือทั้งหมดในระดับบัญชี AWS, OU หรือองค์กร สิ่งเหล่านี้สามารถใช้เพื่อให้แน่ใจว่ามีการปรับใช้เวิร์กโหลดใน AWS Region ที่กำหนดเท่านั้น หรือปฏิเสธการเข้าถึงบริการ AWS ที่เฉพาะเจาะจง
ขั้นตอนที่ 3
ระบบอัตโนมัติ: ระบบอัตโนมัติช่วยให้มั่นใจได้ว่ามีการใช้กฎควบคุมระบบอย่างสม่ำเสมอเมื่อองค์กรเพิ่มบัญชี AWS ใหม่เมื่อมีการนำทีมและเวิร์กโหลดใหม่มาใช้ ช่วยแก้ไขการเปลี่ยนแปลงการปฏิบัติตามกฎระเบียบและให้กฎควบคุมระบบในบัญชีรากขององค์กร
ขั้นตอนที่ 4
การเข้ารหัส: AWS Key Management Service (AWS KMS) ที่มีคีย์ที่จัดการโดยลูกค้าเข้ารหัสข้อมูลที่อยู่ในพื้นที่จัดเก็บโดยใช้การเข้ารหัส FIPS 140-2 ที่ตรวจสอบแล้ว ไม่ว่าจะอยู่ในบัคเก็ต Amazon Simple Storage Service (Amazon S3), โวลุ่มAmazon Elastic Block Store (Amazon EBS), ฐานข้อมูล Amazon Relational Database Service (Amazon RDS), หรือบริการที่เก็บข้อมูล AWS อื่น ๆ ปกป้องข้อมูลที่อยู่ระหว่างการโอนย้ายโดยใช้ TLS 1.2 หรือสูงกว่าขั้นตอนที่ 5
การลงชื่อเข้าใช้ครั้งเดียว: คุณสมบัติหนึ่งของ AWS Identity and Access Management (IAM), IAM Identity Center ถูกใช้เพื่อให้การสันนิษฐานบทบาทใน IAM กับบัญชี AWS ทั่วทั้งองค์กรสำหรับบัญชีที่มีอำนาจดำเนินการที่ได้รับอนุญาต ข้อมูลประจำตัวที่มีอยู่ขององค์กรสามารถหาได้จากที่เก็บข้อมูลประจำตัว Active Directory (AD) ที่มีอยู่ของลูกค้าหรือผู้ให้บริการข้อมูลระบุตัวตน (iDP) ภายนอกรายอื่นAWS อำนวยความสะดวกในการบังคับใช้การรับรองความถูกต้องหลายปัจจัยโดยใช้แอปยืนยันตัวตน คีย์ความปลอดภัย และตัวยืนยันตัวตนในตัว รองรับ WebAuthn, FIDO2 และการยืนยันตัวตนและอุปกรณ์ Universal 2nd Factor (U2F)
ขั้นตอนที่ 1
องค์กรที่มีหลายบัญชี: องค์กรจัดกลุ่มบัญชี AWS แยกต่างหากหลายบัญชี ซึ่งควบคุมโดยหน่วยงานลูกค้าเดียว สิ่งนี้จะรวมการเรียกเก็บเงิน จัดกลุ่มบัญชีโดยใช้ OU และอำนวยความสะดวกในการนำไปใช้จริงกับการควบคุมป้องกันขององค์กรโดยใช้ SCPขั้นตอนที่ 2
การควบคุมความปลอดภัยเชิงป้องกัน: การควบคุมเหล่านี้ ซึ่งดำเนินการโดย SCP ช่วยปกป้องสถาปัตยกรรม ป้องกันการปิดใช้งานกฎควบคุมระบบและบล็อกพฤติกรรมของผู้ใช้ที่ไม่พึงประสงค์ SCP มีกลไกกฎควบคุมระบบที่ใช้หลักในการปฏิเสธการดำเนินงาน API เฉพาะหรือทั้งหมดในระดับบัญชี AWS, OU หรือองค์กร สิ่งเหล่านี้สามารถใช้เพื่อให้แน่ใจว่ามีการปรับใช้เวิร์กโหลดใน AWS Region ที่กำหนดเท่านั้น หรือปฏิเสธการเข้าถึงบริการ AWS ที่เฉพาะเจาะจง
ขั้นตอนที่ 3
ระบบอัตโนมัติ: ระบบอัตโนมัติช่วยให้มั่นใจได้ว่ามีการใช้กฎควบคุมระบบอย่างสม่ำเสมอเมื่อองค์กรเพิ่มบัญชี AWS ใหม่เมื่อมีการนำทีมและเวิร์กโหลดใหม่มาใช้ ช่วยแก้ไขการเปลี่ยนแปลงการปฏิบัติตามกฎระเบียบและให้กฎควบคุมระบบในบัญชีรากขององค์กร
ขั้นตอนที่ 4
การเข้ารหัส: AWS Key Management Service (AWS KMS) ที่มีคีย์ที่จัดการโดยลูกค้าเข้ารหัสข้อมูลที่อยู่ในพื้นที่จัดเก็บโดยใช้การเข้ารหัส FIPS 140-2 ที่ตรวจสอบแล้ว ไม่ว่าจะอยู่ในบัคเก็ต Amazon Simple Storage Service (Amazon S3), โวลุ่มAmazon Elastic Block Store (Amazon EBS), ฐานข้อมูล Amazon Relational Database Service (Amazon RDS), หรือบริการที่เก็บข้อมูล AWS อื่น ๆ ปกป้องข้อมูลที่อยู่ระหว่างการโอนย้ายโดยใช้ TLS 1.2 หรือสูงกว่าขั้นตอนที่ 5
การลงชื่อเข้าใช้ครั้งเดียว: คุณสมบัติหนึ่งของ AWS Identity and Access Management (IAM), IAM Identity Center ถูกใช้เพื่อให้การสันนิษฐานบทบาทใน IAM กับบัญชี AWS ทั่วทั้งองค์กรสำหรับบัญชีที่มีอำนาจดำเนินการที่ได้รับอนุญาต ข้อมูลประจำตัวที่มีอยู่ขององค์กรสามารถหาได้จากที่เก็บข้อมูลประจำตัว Active Directory (AD) ที่มีอยู่ของลูกค้าหรือผู้ให้บริการข้อมูลระบุตัวตน (iDP) ภายนอกรายอื่นAWS อำนวยความสะดวกในการบังคับใช้การรับรองความถูกต้องหลายปัจจัยโดยใช้แอปยืนยันตัวตน คีย์ความปลอดภัย และตัวยืนยันตัวตนในตัว รองรับ WebAuthn, FIDO2 และการยืนยันตัวตนและอุปกรณ์ Universal 2nd Factor (U2F)
-
บัญชีรักษาความปลอดภัย
-
แผนผังสถาปัตยกรรมนี้แสดงวิธีกำหนดค่าการรวบรวมข้อมูลบันทึกที่ครอบคลุมทั่วทั้งบริการและบัญชี AWS โดยส่วนกลาง ทำตามขั้นตอนในแผนผึงสถาปัตยกรรมนี้เพื่อปรับใช้ส่วนบัญชีความปลอดภัยของคำแนะนำนี้
คลิกเพื่อขยาย
ขั้นตอนที่ 1
ข้อมูลบันทึกแบบรวมศูนย์: สถาปัตยกรรมนี้กำหนดการรวบรวมบ้อมูลบันทึกและการรวมศูนย์ที่ครอบคลุมทั่วทั้งบริการและบัญชี AWS ข้อมูลบันทึก AWS CloudTrail ทำงานทั่วทั้งองค์กรเพื่อให้สามารถตรวจสอบระนาบควบคุมได้อย่างเต็มรูปแบบในสภาพแวดล้อมคลาวด์ข้อมูลบันทึก Amazon CloudWatch ซึ่งเป็นบริการข้อมูลบันทึก AWS แบบคลาวด์เนทีฟ ใช้เพื่อบันทึกบันทึกที่หลากหลาย รวมถึงบันทึกระบบปฏิบัติการและแอปพลิเคชัน บันทึกการไหลของ VPC และบันทึกระบบชื่อโดเมน ซึ่งจะถูกรวมศูนย์และใช้ได้กับบุคลากรความปลอดภัยที่กำหนดเท่านั้น
ขั้นตอนที่ 2
การติดตามตรวจความปลอดภัยแบบรวมศูนย์: การเปลี่ยนแปลงการปฏิบัติตามกฎระเบียบและภัยคุกคามด้านความปลอดภัยจะปรากฏขึ้นทั่วองค์กร AWS ของลูกค้าผ่านการนำไปใช้จริงกับระบบควบคุมการตรวจจับความปลอดภัยนหลายประเภทโดยอัตโนมัติ ซึ่งรวมถึงการเปิดใช้งานบริการรักษาความปลอดภัย AWS จำนวนมากในทุกบัญชีในองค์กรบริการรักษาความปลอดภัยเหล่านี้ ได้แก่ Amazon GuardDuty, AWS Security Hub, AWS Config, AWS Firewall Manager, Amazon Macie, IAM Access Analyzer, และการแจ้งเตือน CloudWatch ควรมอบหมายการควบคุมและการมองเห็นในสภาพแวดล้อมหลายบัญชีไปยังบัญชีเครื่องมือรักษาความปลอดภัยส่วนกลางเดียวเพื่อให้สามารถมองเห็นได้ทั่วทั้งองค์กรได้อย่างง่ายดายต่อการค้นพบความปลอดภัยและการเปลี่ยนแปลงการปฏิบัติตามกฎระเบียบ
ขั้นตอนที่ 3
การเข้าถึงและการค้นหาแบบดูอย่างเดียว: บัญชีความปลอดภัยได้รับการเข้าถึงแบบดูอย่างเดียวในองค์กร (รวมถึงการเข้าถึงคอนโซล CloudWatch ของแต่ละบัญชี) เพื่ออำนวยความสะดวกในการตรวจสอบในระหว่างเกิดเหตุการณ์การเข้าถึงแบบดูอย่างเดียวแตกต่างจากการเข้าถึงแบบอ่านอย่างเดียวเนื่องจากไม่ได้ให้การเข้าถึงข้อมูลใด ๆ มีส่วนเสริมเสริมเพื่อใช้ชุดข้อมูลบันทึกแบบรวมศูนย์ที่ครอบคลุมเพื่อให้สามารถค้นหาได้ โดยให้สอดคล้องและแดชบอร์ดพื้นฐาน
ขั้นตอนที่ 1
ข้อมูลบันทึกแบบรวมศูนย์: สถาปัตยกรรมนี้กำหนดการรวบรวมบ้อมูลบันทึกและการรวมศูนย์ที่ครอบคลุมทั่วทั้งบริการและบัญชี AWS ข้อมูลบันทึก AWS CloudTrail ทำงานทั่วทั้งองค์กรเพื่อให้สามารถตรวจสอบระนาบควบคุมได้อย่างเต็มรูปแบบในสภาพแวดล้อมคลาวด์ข้อมูลบันทึก Amazon CloudWatch ซึ่งเป็นบริการข้อมูลบันทึก AWS แบบคลาวด์เนทีฟ ใช้เพื่อบันทึกบันทึกที่หลากหลาย รวมถึงบันทึกระบบปฏิบัติการและแอปพลิเคชัน บันทึกการไหลของ VPC และบันทึกระบบชื่อโดเมน ซึ่งจะถูกรวมศูนย์และใช้ได้กับบุคลากรความปลอดภัยที่กำหนดเท่านั้น
ขั้นตอนที่ 2
การติดตามตรวจความปลอดภัยแบบรวมศูนย์: การเปลี่ยนแปลงการปฏิบัติตามกฎระเบียบและภัยคุกคามด้านความปลอดภัยจะปรากฏขึ้นทั่วองค์กร AWS ของลูกค้าผ่านการนำไปใช้จริงกับระบบควบคุมการตรวจจับความปลอดภัยนหลายประเภทโดยอัตโนมัติ ซึ่งรวมถึงการเปิดใช้งานบริการรักษาความปลอดภัย AWS จำนวนมากในทุกบัญชีในองค์กรบริการรักษาความปลอดภัยเหล่านี้ ได้แก่ Amazon GuardDuty, AWS Security Hub, AWS Config, AWS Firewall Manager, Amazon Macie, IAM Access Analyzer, และการแจ้งเตือน CloudWatch ควรมอบหมายการควบคุมและการมองเห็นในสภาพแวดล้อมหลายบัญชีไปยังบัญชีเครื่องมือรักษาความปลอดภัยส่วนกลางเดียวเพื่อให้สามารถมองเห็นได้ทั่วทั้งองค์กรได้อย่างง่ายดายต่อการค้นพบความปลอดภัยและการเปลี่ยนแปลงการปฏิบัติตามกฎระเบียบ
ขั้นตอนที่ 3
การเข้าถึงและการค้นหาแบบดูอย่างเดียว: บัญชีความปลอดภัยได้รับการเข้าถึงแบบดูอย่างเดียวในองค์กร (รวมถึงการเข้าถึงคอนโซล CloudWatch ของแต่ละบัญชี) เพื่ออำนวยความสะดวกในการตรวจสอบในระหว่างเกิดเหตุการณ์
การเข้าถึงแบบดูอย่างเดียวแตกต่างจากการเข้าถึงแบบอ่านอย่างเดียวเนื่องจากไม่ได้ให้การเข้าถึงข้อมูลใด ๆ มีส่วนเสริมเสริมเพื่อใช้ชุดข้อมูลบันทึกแบบรวมศูนย์ที่ครอบคลุมเพื่อให้สามารถค้นหาได้ โดยให้สอดคล้องและแดชบอร์ดพื้นฐาน
-
บัญชีโครงสร้างพื้นฐาน
-
แผนผังสถาปัตยกรรมนี้แสดงให้เห็นว่าสภาพแวดล้อมเครือข่ายแบบรวมศูนย์และแยกตัวถูกสร้างขึ้นด้วย Virtual Private Clouds (VPC) ได้อย่างไร ทำตามขั้นตอนในแผนผังสถาปัตยกรรมนี้เพื่อปรับใช้ส่วนบัญชีโครงสร้างพื้นฐานของคำแนะนำนี้
คลิกเพื่อขยาย
ขั้นตอนที่ 1
เครือข่ายแบบรวมศูนย์และแยกส่วน: VPC ที่สร้างขึ้นผ่าน Amazon Virtual Private Cloud (Amazon VPC) ใช้เพื่อสร้างการแยกระนาบข้อมูลระหว่างเวิร์กโหลดโดยรวมอยู่ในบัญชีเครือข่ายที่ใช้ร่วมกัน การรวมศูนย์ช่วยอำนวยความสะดวกในการแยกส่วนเครือข่ายที่แข็งแกร่งและการเพิ่มประสิทธิภาพต้นทุนขั้นตอนที่ 2
การเชื่อมต่อที่มีสื่อกลาง: การเชื่อมต่อกับสภาพแวดล้อมในองค์กร การส่งออกทางอินเทอร์เน็ต ทรัพยากรที่ใช้ร่วมกัน และ AWS API ถูกเชื่อมต่อผ่านสื่อกลางที่จุดศูนย์กลางของการเข้าและออกผ่านการใช้ AWS Transit Gateway, AWS Site-to-Site VPN, ไฟร์วอลล์รุ่นต่อไป และ AWS Direct Connect (ในกรณีที่เกี่ยวข้อง)ขั้นตอนที่ 3
ตัวเลือกที่เป็นทางเลือก: สถาปัตยกรรม VPC แบบรวมศูนย์ไม่ได้มีไว้สำหรับลูกค้าทุกคน สำหรับลูกค้าที่กังวลกับการเพิ่มประสิทธิภาพต้นทุนน้อยกว่า มีตัวเลือกสำหรับ VPC ที่ใช้บัญชีท้องถิ่นที่เชื่อมต่อกันผ่าน Transit Gateway ในบัญชีเครือข่ายที่แชร์ส่วนกลาง
ภายใต้ตัวเลือกทั้งสอง สถาปัตยกรรมกำหนดการย้ายตำแหน่งข้อมูล API สาธารณะ AWS ไปยังพื้นที่ที่อยู่ VPC ส่วนตัวของลูกค้า โดยใช้ตำแหน่งข้อมูลแบบรวมศูนย์เพื่อประหยัดต้นทุน
ขั้นตอนที่ 4
การตรวจสอบโครงสร้างพื้นฐานทางเข้าและการออกแบบรวมศูนย์ (IaaS): เป็นเรื่องปกติที่จะเห็นข้อกำหนดการเข้าและการออกแบบรวมศูนย์สำหรับเวิร์กโหลดที่ใช้ IaaS สถาปัตยกรรมนี้มีฟังก์ชันนี้ เพื่อให้ลูกค้าสามารถตัดสินใจได้ว่าบริการตรวจสอบไฟร์วอลล์เข้าและออกของ AWS แบบเนทีฟ เช่น AWS Network Firewall, AWS WAF, หรือ Application Load Balancer ผ่าน Elastic Load Balancing (ELB) โดยเป็นไปตามความต้องการของลูกค้าหากไม่เป็นเช่นั้น ลูกค้าสามารถเพิ่มความสามารถเหล่านั้นด้วยอุปกรณ์ไฟร์วอลล์ของบุคคลที่สาม สถาปัตยกรรมรองรับการเริ่มต้นด้วยไฟร์วอลล์ AWS และเปลี่ยนไปใช้ไฟร์วอลล์ของบุคคลที่สามหรือใช้เทคโนโลยีไฟร์วอลล์เข้าและออก
ขั้นตอนที่ 1
เครือข่ายแบบรวมศูนย์และแยกส่วน: VPC ที่สร้างขึ้นผ่าน Amazon Virtual Private Cloud (Amazon VPC) ใช้เพื่อสร้างการแยกระนาบข้อมูลระหว่างเวิร์กโหลดโดยรวมอยู่ในบัญชีเครือข่ายที่ใช้ร่วมกัน การรวมศูนย์ช่วยอำนวยความสะดวกในการแยกส่วนเครือข่ายที่แข็งแกร่งและการเพิ่มประสิทธิภาพต้นทุนขั้นตอนที่ 2
การเชื่อมต่อที่มีสื่อกลาง: การเชื่อมต่อกับสภาพแวดล้อมในองค์กร การส่งออกทางอินเทอร์เน็ต ทรัพยากรที่ใช้ร่วมกัน และ AWS API ถูกเชื่อมต่อผ่านสื่อกลางที่จุดศูนย์กลางของการเข้าและออกผ่านการใช้ AWS Transit Gateway, AWS Site-to-Site VPN, ไฟร์วอลล์รุ่นต่อไป และ AWS Direct Connect (ในกรณีที่เกี่ยวข้อง)ขั้นตอนที่ 3
ตัวเลือกที่เป็นทางเลือก: สถาปัตยกรรม VPC แบบรวมศูนย์ไม่ได้มีไว้สำหรับลูกค้าทุกคน สำหรับลูกค้าที่กังวลกับการเพิ่มประสิทธิภาพต้นทุนน้อยกว่า มีตัวเลือกสำหรับ VPC ที่ใช้บัญชีท้องถิ่นที่เชื่อมต่อกันผ่าน Transit Gateway ในบัญชีเครือข่ายที่แชร์ส่วนกลาง
ภายใต้ตัวเลือกทั้งสอง สถาปัตยกรรมกำหนดการย้ายตำแหน่งข้อมูล API สาธารณะ AWS ไปยังพื้นที่ที่อยู่ VPC ส่วนตัวของลูกค้า โดยใช้ตำแหน่งข้อมูลแบบรวมศูนย์เพื่อประหยัดต้นทุน
ขั้นตอนที่ 4
การตรวจสอบโครงสร้างพื้นฐานทางเข้าและการออกแบบรวมศูนย์ (IaaS): เป็นเรื่องปกติที่จะเห็นข้อกำหนดการเข้าและการออกแบบรวมศูนย์สำหรับเวิร์กโหลดที่ใช้ IaaS สถาปัตยกรรมนี้มีฟังก์ชันนี้ เพื่อให้ลูกค้าสามารถตัดสินใจได้ว่าบริการตรวจสอบไฟร์วอลล์เข้าและออกของ AWS แบบเนทีฟ เช่น AWS Network Firewall, AWS WAF, หรือ Application Load Balancer ผ่าน Elastic Load Balancing (ELB) โดยเป็นไปตามความต้องการของลูกค้าหากไม่เป็นเช่นั้น ลูกค้าสามารถเพิ่มความสามารถเหล่านั้นด้วยอุปกรณ์ไฟร์วอลล์ของบุคคลที่สาม สถาปัตยกรรมรองรับการเริ่มต้นด้วยไฟร์วอลล์ AWS และเปลี่ยนไปใช้ไฟร์วอลล์ของบุคคลที่สามหรือใช้เทคโนโลยีไฟร์วอลล์เข้าและออก
-
แอปพลิเคชัน ชุมชน ทีม หรือบัญชีกลุ่ม (ละเอียดอ่อน)
-
แผนผังสถาปัตยกรรมนี้แสดงวิธีการกำหนดค่าการแบ่งส่วนและการแยกระหว่างเวิร์กโหลดที่อยู่ในขั้นตอนต่างๆของวงจรชีวิตการพัฒนาซอฟต์แวร์หรือระหว่างบทบาทผู้ดูแลระบบไอทีที่แตกต่างกัน ทำตามขั้นตอนในแผนผังสถาปัตยกรรมนี้เพื่อปรับใช้ส่วนของแอปพลิเคชัน ชุมชน ทีมหรือบัญชีกลุ่มของคำแนะนำนี้
คลิกเพื่อขยาย
ขั้นตอนที่ 1
การแบ่งส่วนและการแยกส่วน: สถาปัตยกรรมไม่ได้เพียงแต่ให้การแบ่งส่วนที่แข็งแกร่งและการแยกส่วนระหว่างเวิร์กโหลดที่อยู่ในขั้นตอนต่างๆของวงจรชีวิตการพัฒนาซอฟต์แวร์หรือระหว่างบทบาทผู้ดูแลระบบไอทีที่แตกต่างกัน (เช่นระหว่างเครือข่าย ไฟร์วอลล์เข้าและออก และเวิร์กโหลด)นอกจากนี้ยังมีสถาปัตยกรรมการแบ่งโซนเครือข่ายที่แข็งแกร่ง โดยแบ่งกลุ่มสิ่งแวดล้อมโดยการรวมทุกอินสแตนซ์หรือส่วนประกอบในไฟร์วอลล์ที่มีสถานะซึ่งบังคับใช้ในฮาร์ดแวร์ของ AWS Nitro System พร้อมกับบริการอย่าง ELB และ AWS WAF
ขั้นตอนที่ 2
การไหลของเครือข่ายทั้งหมดจะถูกบังคับใช้อย่างเข้มงวด โดยป้องกันการเคลื่อนไหวข้างเคียงระหว่างแอปพลิเคชัน ระดับภายในแอปพลิเคชัน และโหนดในระดับของแอปพลิเคชันเว้นแต่จะได้รับอนุญาตอย่างชัดเจน นอกจากนี้ยังป้องกันการกำหนดเส้นทางระหว่าง Dev, Test และ Prod ด้วยคำแนะนำเกี่ยวกับสถาปัตยกรรม CI/CD เพื่อให้ผู้พัฒนามีความคล่องตัวและง่ายต่อการโปรโมตโค้ดระหว่างสภาพแวดล้อมด้วยการอนุมัติที่เหมาะสม
ขั้นตอนที่ 1
การแบ่งส่วนและการแยกส่วน: สถาปัตยกรรมไม่ได้เพียงแต่ให้การแบ่งส่วนที่แข็งแกร่งและการแยกส่วนระหว่างเวิร์กโหลดที่อยู่ในขั้นตอนต่างๆของวงจรชีวิตการพัฒนาซอฟต์แวร์หรือระหว่างบทบาทผู้ดูแลระบบไอทีที่แตกต่างกัน (เช่นระหว่างเครือข่าย ไฟร์วอลล์เข้าและออก และเวิร์กโหลด)นอกจากนี้ยังมีสถาปัตยกรรมการแบ่งโซนเครือข่ายที่แข็งแกร่ง โดยแบ่งกลุ่มสิ่งแวดล้อมโดยการรวมทุกอินสแตนซ์หรือส่วนประกอบในไฟร์วอลล์ที่มีสถานะซึ่งบังคับใช้ในฮาร์ดแวร์ของ AWS Nitro System พร้อมกับบริการอย่าง ELB และ AWS WAF
ขั้นตอนที่ 2
การไหลของเครือข่ายทั้งหมดจะถูกบังคับใช้อย่างเข้มงวด โดยป้องกันการเคลื่อนไหวข้างเคียงระหว่างแอปพลิเคชัน ระดับภายในแอปพลิเคชัน และโหนดในระดับของแอปพลิเคชันเว้นแต่จะได้รับอนุญาตอย่างชัดเจน นอกจากนี้ยังป้องกันการกำหนดเส้นทางระหว่าง Dev, Test และ Prod ด้วยคำแนะนำเกี่ยวกับสถาปัตยกรรม CI/CD เพื่อให้ผู้พัฒนามีความคล่องตัวและง่ายต่อการโปรโมตโค้ดระหว่างสภาพแวดล้อมด้วยการอนุมัติที่เหมาะสม
Well-Architected Pillars
เฟรมเวิร์ก AWS Well-Architected ช่วยให้คุณทำความเข้าใจข้อดีและข้อเสียของการตัดสินใจที่คุณทำเมื่อคุณสร้างระบบของคุณบนคลาวด์ เสาหลักหกประการของเฟรมเวิร์กช่วยให้คุณเรียนรู้แนวทางปฏิบัติที่ดีที่สุดทางสถาปัตยกรรมสำหรับการออกแบบและดำเนินงานระบบที่เชื่อถือได้ ปลอดภัย มีประสิทธิภาพ คุ้มค่า และยั่งยืน การใช้เครื่องมือ AWS Well-Architected Tools ซึ่งมีให้บริการฟรีใน AWS Management Console ช่วยให้คุณสามารถตรวจสอบเวิร์กโหลดของคุณตามแนวทางปฏิบัติที่ดีที่สุดเหล่านี้ โดยการตอบชุดคำถามสำหรับเสาหลักแต่ละประการ
แผนภาพสถาปัตยกรรมด้านบนเป็นตัวอย่างของโซลูชันที่สร้างขึ้นโดยคำนึงถึงแนวทางปฏิบัติที่ดีที่สุดของเฟรมเวิร์ก Well-Architected เพื่อให้เป็น Well-Architected เต็มรูปแบบ คุณควรยึดมั่นในแนวทางปฏิบัติที่ดีที่สุดของ Well-Architected ให้มากที่สุด
-
ความเป็นเลิศด้านการปฏิบัติงานอ่านเอกสารข้อมูลด้านความเป็นเลิศด้านการดำเนินงาน
คำแนะนำนี้ใช้ องค์กร ที่มีสแต็กและการกำหนดค่า AWS CloudFormation เพื่อสร้างรากฐานที่ปลอดภัยสำหรับสภาพแวดล้อม AWS ของคุณ นี่เป็นโซลูชันโครงสร้างพื้นฐานเป็นโค้ด (IaC) ที่ช่วยเร่งการดำเนินการควบคุมความปลอดภัยทางเทคนิคของคุณ กฎ การกำหนดค่า จะแก้ไขเดลต้าการกำหนดค่าใด ๆ ที่กำหนดว่าส่งผลเสียต่อสถาปัตยกรรมที่กำหนด คุณสามารถใช้โครงสร้างพื้นฐานเชิงพาณิชย์ทั่วไปของ AWS สำหรับเวิร์กโหลดที่ละเอียดอ่อนและระบบที่ปลอดภัยโดยอัตโนมัติเพื่อส่งมอบภารกิจให้เร็วขึ้นในขณะที่ปรับปรุงกระบวนการและขั้นตอนของคุณอย่างต่อเนื่อง
-
การรักษาความปลอดภัยอ่านเอกสารไวท์เปเปอร์ด้านความปลอดภัย
คำแนะนำนี้ใช้ องค์กร เพื่ออำนวยความสะดวกในการนำไปใช้จริงของกฎควบคุมระบบขององค์กร เช่น การทำข้อมูลบันทึก API ด้วย CloudTrail. คู่มือนี้ยังให้การควบคุมเชิงป้องกันโดยใช้ AWS SCP ที่กำหนดไว้เป็นกลไกกฎควบคุมระบบซึ่งส่วนใหญ่จะใช้เพื่อปฏิเสธ API เฉพาะหรือทั้งหมดในสภาพแวดล้อมของคุณ (เพื่อให้แน่ใจว่าเวิร์กโหลดถูกนำไปใช้จริงเฉพาะในรีเจี้ยนที่กำหนดเท่านั้น) หรือปฏิเสธการเข้าถึงบริการ AWS ที่เฉพาะเจาะจง ข้อมูลบันทึก CloudTrail และ CloudWatch รองรับการรวบรวมข้อมูลบันทึกที่ครอบคลุมและการรวมศูนย์ที่กำหนดไว้ในบริการและบัญชี AWS ความสามารถด้านความปลอดภัยของ AWS และบริการที่เกี่ยวข้องกับความปลอดภัยมากมายได้รับการกำหนดค่าในรูปแบบที่กำหนดไว้ซึ่งช่วยให้คุณปฏิบัติตามข้อกำหนดด้านความปลอดภัยที่เข้มงวดที่สุดในโลก
-
ความเชื่อถือได้อ่านเอกสารไวท์เปเปอร์ความน่าเชื่อถือ
คำแนะนำนี้ใช้ Availability Zone (AZ) หลายโซน ดังนั้นการสูญเสีย AZ หนึ่งโซนจึงไม่ส่งผลกระทบต่อความพร้อมใช้งานของแอปพลิเคชัน คุณสามารถใช้ CloudFormation เพื่อจัดเตรียมและอัปเดตโครงสร้างพื้นฐานของคุณโดยอัตโนมัติในลักษณะที่ปลอดภัยและควบคุมได้ คำแนะนำนี้ยังให้กฎที่สร้างไว้ล่วงหน้าสำหรับการประเมินการกำหนดค่าทรัพยากร AWS และการเปลี่ยนแปลงการกำหนดค่าภายในสภาพแวดล้อมของคุณ หรือคุณสามารถสร้างกฎที่กำหนดเองใน AWS Lambda เพื่อกำหนดแนวทางปฏิบัติและแนวทางที่ดีที่สุด คุณสามารถปรับขนาดสภาพแวดล้อมของคุณโดยอัตโนมัติเพื่อตอบสนองความต้องการและลดการหยุดชะงัก เช่น การกำหนดค่าผิดพลาดหรือปัญหาเครือข่ายชั่วคราว
-
ประสิทธิภาพการทำงานอ่านเอกสารไวท์เปเปอร์ประสิทธิภาพการทำงาน
คำแนะนำนี้ช่วยลดความยุ่งยากในการจัดการโครงสร้างพื้นฐานระบบคลาวด์โดยใช้ Transit Gateway ซึ่งทำหน้าที่เป็นศูนย์กลางที่เชื่อมต่อ VPC หลายตัวผ่านเกตเวย์เดียว ทำให้การปรับขนาดและบำรุงรักษาสถาปัตยกรรมเครือข่ายทำได้ง่ายขึ้น สิ่งนี้ทำให้สถาปัตยกรรมเครือข่ายของคุณง่ายขึ้นและอำนวยความสะดวกในการกำหนดเส้นทางการรับส่งข้อมูลที่มีประสิทธิภาพระหว่างบัญชี AWS ที่แตกต่างกันภายในองค์กรของคุณ
-
การปรับค่าใช้จ่ายให้เหมาะสมอ่านเอกสารไวท์เปเปอร์การเพิ่มประสิทธิภาพต้นทุน
คำแนะนำนี้ให้ความสามารถในการหลีกเลี่ยงหรือกำจัดค่าใช้จ่ายที่ไม่จำเป็นหรือการใช้ทรัพยากรที่ไม่เหมาะสม องค์กร ให้การรวมศูนย์และการเรียกเก็บเงินแบบรวมซึ่งอำนวยความสะดวกในการแยกการใช้ทรัพยากรและการเพิ่มประสิทธิภาพต้นทุนอย่างเข้มงวด คำแนะนำนี้กำหนดให้ย้ายตำแหน่งข้อมูล API สาธารณะ AWS ไปยังพื้นที่ที่อยู่ VPC ส่วนตัวของคุณ โดยใช้ตำแหน่งข้อมูลแบบรวมศูนย์เพื่อประหยัดค่าใช้จ่าย นอกจากนี้ คุณสามารถใช้ AWS Cost and Usage Reports (AWS CUR) เพื่อติดตามการใช้งาน AWS ของคุณและประมาณค่าใช้จ่าย
-
ความยั่งยืนอ่านเอกสารไวท์เปเปอร์ความยั่งยืน
คำแนะนำนี้ช่วยให้คุณลดปริมาณคาร์บอนฟุตพริ้นท์ที่เกี่ยวข้องกับการจัดการเวิร์กโหลดภายในศูนย์ข้อมูลของคุณเอง โครงสร้างพื้นฐานระดับโลกของ AWS นำเสนอโครงสร้างพื้นฐานที่รองรับ (เช่น พลังงาน การระบายความร้อน และเครือข่าย) อัตราการใช้ประโยชน์ที่สูงกว่า และการรีเฟรชเทคโนโลยีที่เร็วกว่าศูนย์ข้อมูลแบบดั้งเดิม นอกจากนี้ การแบ่งส่วนและการแยกส่วนเวิร์กโหลดจะช่วยให้คุณลดการเคลื่อนไหวของข้อมูลที่ไม่จำเป็นและ Amazon S3 ให้ระดับการจัดเก็บและความสามารถในการย้ายข้อมูลไปยังระดับการจัดเก็บที่มีประสิทธิภาพโดยอัตโนมัติ
การปรับใช้ทรัพยากร
ตัวอย่างโค้ดเป็นจุดเริ่มต้น มีการตรวจสอบความถูกต้องของอุตสาหกรรม มีข้อกำหนดแต่ไม่ชัดเจน และให้ข้อมูลเบื้องต้นเพื่อช่วยคุณในการเริ่มต้น
เนื้อหาที่เกี่ยวข้อง
การกำหนดค่าตัวอย่าง TSE-SE (พร้อมเอนจิ้น LZA อัตโนมัติ)
Trusted Secure Enclaves - Sensitive Edition
ข้อสงวนสิทธิ์
โค้ดตัวอย่าง ไลบรารีซอฟต์แวร์ เครื่องมือบรรทัดคำสั่ง หลักฐานแนวคิด เทมเพลต หรือเทคโนโลยีอื่นๆ ที่เกี่ยวข้อง (รวมถึงสิ่งต่างๆ ที่กล่าวมานี้ที่จัดหาให้โดยบุคลากรของเรา) จะมีให้กับคุณในฐานะของเนื้อหา AWS ภายใต้สัญญาลูกค้าของ AWS หรือข้อตกลงที่เป็นลายลักษณ์อักษรที่เกี่ยวข้องระหว่างคุณและ AWS (อันใดก็ตามที่มีผลบังคับใช้) คุณไม่ควรใช้เนื้อหา AWS นี้ในบัญชีในสภาพแวดล้อมการผลิตของคุณ หรือในข้อมูลการผลิตหรือข้อมูลสำคัญอื่น ๆ คุณรับผิดชอบในการทดสอบ การรักษาความปลอดภัย และการเพิ่มประสิทธิภาพเนื้อหา AWS เช่น โค้ดตัวอย่าง ตามความเหมาะสมสำหรับการใช้งานระดับการผลิต ตามแนวทางปฏิบัติและมาตรฐานการควบคุมคุณภาพเฉพาะของคุณ การนำเนื้อหา AWS ออกใช้งานอาจทำให้มีค่าใช้จ่ายของ AWS สำหรับการสร้างหรือใช้ทรัพยากรที่เรียกเก็บเงินของ AWS เช่น เรียกใช้อินสแตนซ์ Amazon EC2 หรือการใช้ที่เก็บข้อมูล Amazon S3
การอ้างอิงถึงบริการหรือองค์กรของบุคคลที่สามในคำแนะนำนี้ไม่ได้หมายถึงเป็นการรับรองการสนับสนุนหรือความสัมพันธ์ระหว่าง Amazon หรือ AWS และบุคคลที่สาม คำแนะนำจาก AWS เป็นจุดเริ่มต้นทางเทคนิค และคุณสามารถปรับแต่งการผสานรวมกับบริการของบุคคลที่สามเมื่อคุณปรับใช้สถาปัตยกรรม