ข้ามไปยังเนื้อหาหลัก
FromNine
เมนู

วิศวกรรม

รากฐานคลาวด์ที่ทำให้การเปิดใช้งานเป็นเรื่องปกติ

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

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

ปรึกษาโครงการของคุณดูสถาปัตยกรรมอ้างอิง
วิศวกรรมคลาวด์และแพลตฟอร์ม: ชั้นความสามารถสี่ชั้นเรียงซ้อนกัน จากบนลงล่าง ได้แก่ ระบบงานของทีมผลิตภัณฑ์ แพลตฟอร์มสำหรับนักพัฒนาภายในองค์กร ไปป์ไลน์การส่งมอบที่ลงนามรับรอง และ landing zone ที่มีระบบยืนยันตัวตน เครือข่าย และนโยบายเป็นฐาน01ระบบงานของทีมผลิตภัณฑ์02แพลตฟอร์มสำหรับนักพัฒนา03ไปป์ไลน์ที่ลงนามรับรอง04Landing zone และนโยบาย
  1. 01Landing zone ที่กำหนดนโยบายเป็นโค้ด และกำหนดที่ตั้งข้อมูลแยกตามระบบงาน
  2. 02Golden path ที่นำบริการใหม่ขึ้นใช้งานจริงได้ด้วยวิธีที่ทำซ้ำได้
  3. 03SLO การกู้คืนที่ผ่านการทดสอบ และต้นทุนต่อผลิตภัณฑ์ ที่ผู้มีอำนาจตัดสินใจมองเห็น

01 ปัญหา

สัญญาณว่ารากฐานกำลังฉุดรั้งคุณ

  1. 01

    สภาพแวดล้อมแต่ละชุดไม่เหมือนกัน

    ระบบทดสอบกับระบบใช้งานจริงต่างกันในจุดที่ไม่มีใครจดไว้ และการแก้ไขด้วยมือผ่านคอนโซลหายไปเมื่อสร้างระบบใหม่ครั้งถัดไป

  2. 02

    การเปิดใช้งานต้องนัดประชุม

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

  3. 03

    ค่าคลาวด์ทำให้ทุกคนประหลาดใจ

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

  4. 04

    ไม่มีใครรู้ว่าการกู้คืนใช้ได้จริงหรือไม่

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

02 สิ่งที่เราส่งมอบ

สิ่งที่เราส่งมอบ

  1. 01 Landing zone และทางเลือกด้านอธิปไตยของข้อมูล

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

    สิ่งที่เราทำ

    • ออกแบบโครงสร้างองค์กร กลุ่มการจัดการ และบัญชี
    • เครือข่ายศูนย์กลาง การควบคุมทราฟฟิกขาออก และการเชื่อมต่อแบบส่วนตัว
    • นโยบายเป็นโค้ดสำหรับที่ตั้งข้อมูล การเข้ารหัส และการติดแท็ก
    • เทียบกับการรับรองที่ลูกค้าในยุโรปของคุณร้องขอ เช่น BSI C5 หรือ SecNumCloud

    สิ่งที่คุณได้รับ

    • Landing zone ที่กำหนดด้วยโค้ดทั้งหมด
    • คลังนโยบายพร้อมกระบวนการขอยกเว้น
    • เอกสารทางเลือกด้านอธิปไตยของข้อมูลตามประเภทระบบงาน

  2. 02 Infrastructure as code และแพลตฟอร์มสำหรับนักพัฒนาภายในองค์กร

    Terraform หรือ OpenTofu และ Bicep สำหรับโครงสร้างพื้นฐาน GitOps สำหรับการติดตั้ง Kubernetes หรือ runtime แบบมีผู้ดูแลในจุดที่เหมาะสม และ golden path ที่ทำให้ทีมเริ่มบริการที่เป็นไปตามข้อกำหนดได้โดยไม่ต้องเปิดคำขอ

    สิ่งที่เราทำ

    • คลังโมดูลสำหรับ infrastructure as code
    • GitOps พร้อมการเลื่อนระดับสภาพแวดล้อม
    • แพลตฟอร์ม Kubernetes หรือทางเลือกแบบมีผู้ดูแล
    • แม่แบบบริการและพอร์ทัลสำหรับนักพัฒนา

    สิ่งที่คุณได้รับ

    • แพลตฟอร์มสำหรับนักพัฒนาภายในองค์กรพร้อม golden path
    • สภาพแวดล้อมแบบบริการตนเอง
    • แผนงานแพลตฟอร์มที่ทีมแพลตฟอร์มเป็นเจ้าของ

  3. 03 ไปป์ไลน์การส่งมอบและความมั่นคงปลอดภัยของห่วงโซ่ซอฟต์แวร์

    ไปป์ไลน์ที่ build ครั้งเดียว ลงนามรับรองชิ้นงาน บันทึกที่มาตามแนวทาง SLSA จัดการข้อมูลลับอย่างถูกต้อง และเลื่อนชิ้นงานเดียวกันจากระบบทดสอบไปสู่ระบบใช้งานจริง

    สิ่งที่เราทำ

    • แม่แบบไปป์ไลน์พร้อมด่านตรวจคุณภาพและความมั่นคงปลอดภัย
    • การลงนามชิ้นงานและการรับรองที่มา
    • การจัดการข้อมูลลับและการหมุนเวียนกุญแจ
    • กฎการเลื่อนระดับและบันทึกการเปลี่ยนแปลง

    สิ่งที่คุณได้รับ

    • แม่แบบไปป์ไลน์ที่นำกลับมาใช้ซ้ำได้
    • ชิ้นงานที่ลงนามแล้วและตรวจสอบที่มาได้
    • หลักฐานการเปิดใช้งานสำหรับการบริหารการเปลี่ยนแปลง

  4. 04 การติดตามระบบและ SRE

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

    สิ่งที่เราทำ

    • กำหนด SLO ร่วมกับเจ้าของบริการ
    • ติดตั้ง OpenTelemetry และแดชบอร์ด
    • แจ้งเตือนตามอาการ ไม่ใช่ตามสาเหตุ
    • การจัดการเหตุการณ์และการทบทวนหลังเกิดเหตุ

    สิ่งที่คุณได้รับ

    • ทะเบียน SLO
    • ชุดเครื่องมือติดตามระบบและแดชบอร์ด
    • คู่มือปฏิบัติงานด้านเหตุการณ์และการรายงาน

  5. 05 FinOps และกำลังประมวลผลสำหรับ AI

    การปันส่วนต้นทุนตามผลิตภัณฑ์และทีม ต้นทุนต่อหน่วย เช่น ต้นทุนต่อธุรกรรม และการวางแผนและควบคุมต้นทุน GPU สำหรับงาน AI

    สิ่งที่เราทำ

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

    สิ่งที่คุณได้รับ

    • แดชบอร์ดต้นทุนสำหรับเจ้าของผลิตภัณฑ์แต่ละราย
    • รายการงานลดต้นทุนพร้อมผู้รับผิดชอบ
    • แผนกำลังประมวลผลสำหรับ AI

  6. 06 การกู้คืนและการย้ายออก

    การสำรองข้อมูลและการกู้คืนระบบจากภัยพิบัติ ที่มีเป้าหมายเวลากู้คืนและจุดกู้คืนชัดเจน ทดสอบตามกำหนด และกลยุทธ์การย้ายออกที่ใช้สิทธิในการเปลี่ยนผู้ให้บริการตาม EU Data Act สำหรับบริการที่อยู่ภายใต้กฎหมายนั้น

    สิ่งที่เราทำ

    • ตกลง RTO และ RPO ของแต่ละบริการ
    • ทดสอบการกู้คืนและการสลับไปยังระบบสำรอง
    • จัดทำแผนผังการพึ่งพาของบริการสำคัญ
    • แผนการย้ายออกและการตรวจความสามารถในการโอนย้ายข้อมูล

    สิ่งที่คุณได้รับ

    • ขั้นตอนการกู้คืนที่ผ่านการทดสอบ
    • รายงานผลการทดสอบการกู้คืน
    • กลยุทธ์การย้ายออกที่จัดทำเป็นเอกสาร

03 สถาปัตยกรรม

ตัวอย่างสถาปัตยกรรมอ้างอิง

โค้ดเข้ามาทางซ้าย และระบบงานที่ทำงานอยู่ออกไปทางขวา ระหว่างทาง ไปป์ไลน์ลงนามรับรองสิ่งที่ build ที่เก็บชิ้นงานรับเฉพาะชิ้นงานที่ลงนามแล้ว และตัวควบคุม GitOps เลื่อนชิ้นงานผ่านสภาพแวดล้อมต่าง ๆ ภายใต้นโยบาย

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

ชั้นในแผนภาพ

การส่งมอบ
ที่เก็บโค้ด ไปป์ไลน์ ชิ้นงานที่ลงนามแล้ว และการเลื่อนระดับด้วย GitOps
แพลตฟอร์ม
แพลตฟอร์มสำหรับนักพัฒนา นโยบายเป็นโค้ด และ runtime ที่ทีมผลิตภัณฑ์ติดตั้งระบบลงไป
ชั้น landing zone
โครงสร้างองค์กร ระบบยืนยันตัวตน เครือข่าย กุญแจ การกู้คืน และการควบคุมด้าน FinOps
การดูแลระบบ
ข้อมูลการทำงานของระบบ SLO งบความผิดพลาด และการรับมือเหตุการณ์ครอบคลุมทุกส่วน
ตัวอย่างประกอบ

  1. การส่งมอบ

    • ที่เก็บโค้ดและ IaC
    • Build ลงนาม รับรอง
    • ที่เก็บชิ้นงานที่ลงนามแล้ว
    • การเลื่อนระดับด้วย GitOps

  2. แพลตฟอร์ม

    • แพลตฟอร์มนักพัฒนาและ golden path
    • นโยบายเป็นโค้ด
    • Kubernetes และบริการแบบมีผู้ดูแล
    • ระบบงานของทีมผลิตภัณฑ์

  3. ชั้น landing zone

    • โครงสร้างการจัดการ
    • ตัวตนและสิทธิ์การเข้าถึง
    • เครือข่ายศูนย์กลางและทราฟฟิกขาออก
    • กุญแจและข้อมูลลับ
    • สำรองและกู้คืนข้อมูล
    • การปันส่วนต้นทุน

  4. การดูแลระบบ

    • OpenTelemetry, SLO งบความผิดพลาด และการรับมือเหตุการณ์
การส่งมอบที่ลงนามรับรองบน landing zone ที่กำกับด้วยนโยบาย

ตัวอย่างสถาปัตยกรรม ไม่ใช่ระบบของลูกค้า

อ่านแผนภาพในรูปแบบข้อความ

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

แพลตฟอร์มสำหรับนักพัฒนาภายในองค์กรให้ golden path ไปสู่ไปป์ไลน์ นโยบายเป็นโค้ดจำกัดการทำงานของตัวควบคุม GitOps แพลตฟอร์ม runtime ที่มี Kubernetes และบริการแบบมีผู้ดูแลรองรับระบบงาน และกุญแจที่ลูกค้าจัดการเองป้อนเข้าสู่ชั้นนโยบาย

Landing zone ด้านล่างประกอบด้วยโครงสร้างการจัดการ ระบบยืนยันตัวตนและสิทธิ์การเข้าถึง เครือข่ายศูนย์กลาง กุญแจ การสำรองและกู้คืนข้อมูล และการควบคุมด้าน FinOps การติดตามระบบพร้อม SLO และการรับมือเหตุการณ์ครอบคลุมทั้งแพลตฟอร์ม

04 ข้อพิจารณาและข้อจำกัด

ข้อพิจารณาทางวิศวกรรมและข้อจำกัด

  • อธิปไตยของข้อมูลมีหลายระดับ

    วิธีที่เราจัดการ

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

    ข้อจำกัดและเงื่อนไข

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

  • แพลตฟอร์มต้องมีเจ้าของผลิตภัณฑ์

    วิธีที่เราจัดการ

    เราดูแลแพลตฟอร์มภายในองค์กรเหมือนผลิตภัณฑ์ที่มีผู้ใช้งาน แผนงาน และวงจรรับความคิดเห็น และช่วยคุณจัดตั้งทีมที่ดูแลแพลตฟอร์มนั้น

    ข้อจำกัดและเงื่อนไข

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

  • กฎระเบียบกำหนดรูปแบบการดูแลระบบ

    วิธีที่เราจัดการ

    การจัดประเภทเหตุการณ์ กรอบเวลาการรายงาน และการเก็บหลักฐาน ถูกฝังไว้ในกระบวนการรับมือเหตุการณ์ในกรณีที่ NIS2 หรือ DORA ใช้บังคับกับคุณหรือกับลูกค้าในยุโรปของคุณ และสำหรับข้อมูลส่วนบุคคลภายใต้ PDPA กระบวนการเดียวกันรองรับการแจ้งเหตุการละเมิดต่อสำนักงานคณะกรรมการคุ้มครองข้อมูลส่วนบุคคลโดยไม่ชักช้า และหากทำได้ภายใน 72 ชั่วโมงนับแต่ทราบเหตุ

    ข้อจำกัดและเงื่อนไข

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

  • การควบคุมต้นทุนเป็นความรับผิดชอบร่วมกัน

    วิธีที่เราจัดการ

    เราทำให้เห็นต้นทุนของแต่ละผลิตภัณฑ์ และเพิ่มกลไกควบคุม เช่น งบประมาณ โควตา และการปิดสภาพแวดล้อมที่ไม่ได้ใช้งานตามเวลา

    ข้อจำกัดและเงื่อนไข

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

05 วิธีการทำงาน

วิธีการทำงานของเรา

วางรากฐานก่อน แล้วให้ทีมแรกใช้ golden path จากนั้นจึงขยายไปทุกทีม

  1. 01

    ประเมินและจัดประเภท

    ระบบงาน ความอ่อนไหวของข้อมูล ต้นทุนปัจจุบัน และการควบคุมที่ผู้ตรวจสอบของคุณคาดหวัง

    ผลลัพธ์การจัดประเภทระบบงานและทางเลือกเป้าหมาย

  2. 02

    สร้าง landing zone

    ทุกอย่างเป็นโค้ด ทบทวนร่วมกับฝ่ายความมั่นคงปลอดภัย และมีกระบวนการขอยกเว้น

    ผลลัพธ์Landing zone ที่ใช้งานจริง

  3. 03

    เริ่มกับทีมนำร่อง

    ทีมผลิตภัณฑ์หนึ่งทีมย้ายมาใช้ golden path และอุปสรรคที่ทีมเจอเป็นตัวกำหนดรูปแบบของแพลตฟอร์ม

    ผลลัพธ์บริการแรกบนแพลตฟอร์ม

  4. 04

    ขยายผลและส่งมอบ

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

    ผลลัพธ์แผนงานแพลตฟอร์มและรายงานการทดสอบการกู้คืน

06 การควบคุมโดยมนุษย์

จุดที่คนยังเป็นผู้ควบคุม

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

  • การเปลี่ยนแปลงระบบใช้งานจริงตรวจสอบย้อนกลับได้

    การเปลี่ยนแปลงทุกครั้งในระบบใช้งานจริงมาจาก commit ที่ผ่านการทบทวน จึงมีบันทึกเสมอว่าใครเปลี่ยนอะไรและใครอนุมัติ

  • การเข้าถึงฉุกเฉินเกิดขึ้นน้อยและมีบันทึก

    การเข้าถึงฉุกเฉินมีเวลาจำกัด ต้องระบุเหตุผล และทบทวนภายหลัง

  • ข้อยกเว้นด้านนโยบายมีเจ้าของ

    เมื่อระบบงานต้องการข้อยกเว้นจากกลไกควบคุม เจ้าของความเสี่ยงที่ระบุชื่อเป็นผู้อนุมัติ พร้อมวันหมดอายุ

  • เจ้าของบริการเป็นผู้กำหนดเป้าหมาย

    เป้าหมายการกู้คืนและระดับบริการตกลงกับเจ้าของงานของแต่ละบริการ ไม่ได้กำหนดโดยทีมแพลตฟอร์มเพียงฝ่ายเดียว

07 เทคโนโลยี

เทคโนโลยีที่เราใช้

คลาวด์
  • Microsoft Azure
  • Amazon Web Services
  • Google Cloud
  • บริการคลาวด์ภายใต้การควบคุมของยุโรป
โครงสร้างพื้นฐานและการส่งมอบ
  • Terraform และ OpenTofu
  • Bicep
  • Argo CD และ Flux
  • GitHub Actions, GitLab CI และ Azure DevOps
รันไทม์
  • Kubernetes และบริการ Kubernetes แบบมีผู้ดูแล
  • แพลตฟอร์ม serverless และคอนเทนเนอร์
  • Service mesh ในจุดที่คุ้มค่า
  • กลุ่มโหนด GPU สำหรับงาน AI
การดูแลระบบ
  • OpenTelemetry
  • Prometheus และ Grafana
  • การติดตามระบบแบบ cloud-native
  • เครื่องมือบังคับใช้นโยบาย เช่น OPA

การระบุชื่อเทคโนโลยีเป็นการบอกประสบการณ์ด้านวิศวกรรมของเรา ไม่ได้หมายความว่าเราเป็นพันธมิตรหรือได้รับการรับรองจากเจ้าของเทคโนโลยีนั้น

08 ตัวอย่าง

ตัวอย่างประกอบ

ตัวอย่างประกอบ

Landing zone ร่วมสำหรับผู้ให้บริการซอฟต์แวร์ที่ลูกค้าในยุโรปขอหลักฐานตาม NIS2

01สถานการณ์
ตัวอย่าง: ผู้ให้บริการซอฟต์แวร์ขนาดกลางในประเทศไทยดูแลบัญชีคลาวด์แยกกันสำหรับลูกค้าในประเทศและลูกค้าในยุโรป โดยใช้การควบคุมต่างกัน ลูกค้าในยุโรปส่งแบบสอบถามด้านความมั่นคงปลอดภัยและกำหนดกรอบเวลาแจ้งเหตุไว้ในสัญญา และไม่มีใครแสดงสถานะความมั่นคงปลอดภัยทั้งหมดได้ในภาพเดียว
02ระบบที่เราจะสร้าง
Landing zone เดียวที่เขียนเป็นโค้ด มีชุดนโยบายแยกตามกลุ่มลูกค้า การบันทึกล็อกร่วมกัน และกระบวนการรับมือเหตุการณ์ที่จัดประเภทและส่งรายงานตามสัญญาของลูกค้าแต่ละรายและตาม PDPA
03จุดที่คนเป็นผู้ตัดสินใจ
เจ้าหน้าที่ความมั่นคงปลอดภัยของแต่ละกลุ่มลูกค้าอนุมัติข้อยกเว้นด้านนโยบายสำหรับระบบงานของตน และผู้บริหารด้านความมั่นคงปลอดภัยสารสนเทศเป็นเจ้าของมาตรฐานพื้นฐานร่วม
04สิ่งที่เราจะวัดผล
เวลาจากการตรวจพบเหตุถึงการจัดประเภท สัดส่วนระบบงานที่อยู่ภายใต้นโยบาย และจำนวนการทดสอบการกู้คืนที่ผ่านในแต่ละไตรมาส

09 มุมมองรายอุตสาหกรรม

ในอุตสาหกรรมของคุณ

  • ภาครัฐ

    ทางเลือกด้านอธิปไตยตามประเภทข้อมูล การรับรองด้านความมั่นคงปลอดภัยที่หน่วยงานกำหนด และแผนการย้ายออกที่ยังใช้ได้เมื่อมีการประกวดราคาครั้งถัดไป

  • บริการทางการเงิน

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

ประเทศไทย

หลักฐานชุดเดียว สำหรับทุกหน่วยงานกำกับ

ลูกค้าในยุโรปที่อยู่ภายใต้ NIS2 หรือ DORA มักขอหลักฐานด้านความมั่นคงปลอดภัยจากผู้ให้บริการของตน ไม่ว่าผู้ให้บริการจะตั้งอยู่ที่ใด ผู้ให้บริการดิจิทัลบางประเภทที่ไม่ได้ตั้งอยู่ในสหภาพยุโรปแต่ให้บริการที่นั่น เช่น บริการคลาวด์ ศูนย์ข้อมูล และบริการแบบมีผู้ดูแล ต้องแต่งตั้งผู้แทนในประเทศสมาชิกตามมาตรา 26(3) ของ NIS2 ส่วนผู้ให้บริการรายอื่นมักได้รับหน้าที่ตาม NIS2 ผ่านสัญญาของลูกค้า และผู้ให้บริการ ICT ที่ทำงานให้สถาบันการเงินในสหภาพยุโรปได้รับข้อกำหนดตาม DORA ผ่านสัญญาเช่นกัน

ในประเทศไทย PDPA กำหนดให้แจ้งเหตุการละเมิดข้อมูลส่วนบุคคลต่อสำนักงานคณะกรรมการคุ้มครองข้อมูลส่วนบุคคลโดยไม่ชักช้า และหากทำได้ภายใน 72 ชั่วโมงนับแต่ทราบเหตุ ส่วนหน่วยงานโครงสร้างพื้นฐานสำคัญทางสารสนเทศมีหน้าที่ตาม พ.ร.บ.การรักษาความมั่นคงปลอดภัยไซเบอร์ พ.ศ. 2562 โดยมี สกมช. เป็นหน่วยงานรับผิดชอบ

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

คำถามเกี่ยวกับวิศวกรรมคลาวด์และแพลตฟอร์ม

ควรเลือกผู้ให้บริการคลาวด์รายใด

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

จำเป็นต้องใช้ Kubernetes หรือไม่

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

FromNine ดูแลความมั่นคงปลอดภัยอย่างไร

ความมั่นคงปลอดภัยฝังอยู่ใน landing zone และไปป์ไลน์ ได้แก่ การให้สิทธิ์เท่าที่จำเป็น นโยบายเป็นโค้ด ชิ้นงานที่ลงนามแล้ว และข้อมูลลับที่ไม่อยู่ในโค้ดเลย FromNine เองได้รับการรับรอง ISO/IEC 27001 ด้านระบบบริหารจัดการความมั่นคงปลอดภัยสารสนเทศ

ช่วยลดค่าคลาวด์ของเราได้หรือไม่

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

จะหลีกเลี่ยงการผูกติดผู้ให้บริการได้อย่างไร

ด้วยการเลือกอย่างตั้งใจว่าจะพึ่งพาบริการเฉพาะของผู้ให้บริการในจุดใด การเก็บโครงสร้างพื้นฐานไว้เป็นโค้ด และการมีแผนการย้ายออกที่จัดทำเป็นเอกสารและผ่านการทดสอบ สำหรับบริการที่อยู่ภายใต้ EU Data Act กฎหมายนี้เสริมสิทธิในการเปลี่ยนผู้ให้บริการ และแผนการย้ายออกทำให้ใช้สิทธินั้นได้จริง

แสดงการเปิดใช้งานสามครั้งถัดไปของคุณให้เราดู

เราจะบอกว่าอะไรจะทำให้การเปิดใช้งานเหล่านั้นเป็นเรื่องปกติ และรากฐานนั้นจะมีต้นทุนในการสร้างและดูแลเท่าใด

ปรึกษาโครงการของคุณดูบริการด้านสถาปัตยกรรม