ข้อกำหนดในการรักษาความปลอดภัยของข้อมูล

การเตรียมตอบคำถามด้านการรักษาความปลอดภัยข้อมูล

เส้นทางของข้อมูล

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

1. ฝั่งไคลเอ็นต์ - รวมซอฟต์แวร์ไคลเอ็นต์ทั้งหมด เช่น เบราว์เซอร์ อุปกรณ์มือถือ และอุปกรณ์ประเภทอื่นๆ ที่รองรับ
2. ฝั่งเซิร์ฟเวอร์ - รวมเซิร์ฟเวอร์หรือสภาพแวดล้อมระบบคลาวด์ที่เกี่ยวข้องและระบุสิ่งต่อไปนี้
1. ส่วนประกอบซึ่งข้อมูลแพลตฟอร์มมีเงื่อนไขดังนี้
1. เข้าหรือออกจากสภาพแวดล้อมเซิร์ฟเวอร์ (เช่น ตัวดักฟังเว็บและ REST API)
2. ถูกเขียนไปยังพื้นที่จัดเก็บข้อมูลที่ถาวรหรือคงทน เช่น ฐานข้อมูล ดิสก์ หรือไฟล์บันทึก
2. รูปแบบการโฮสต์ดังตัวอย่างต่อไปนี้
1. โฮสต์ด้วยตนเอง - เซิร์ฟเวอร์ขององค์กรที่ทำงานในศูนย์ข้อมูลที่องค์กรเป็นเจ้าของหรือที่มีการใช้ร่วมกัน
2. การให้บริการโครงสร้างพื้นฐาน (Infrastructure as a Service หรือ IaaS) - เช่น AWS EC2, Microsoft Azure IaaS และ Google Compute Engine
3. การให้บริการแพลตฟอร์ม (Platform as a Service หรือ PaaS) - เช่น AWS Elastic Beanstalk, Google App Engine และ Force.com
4. การให้บริการแบ็คเอนต์ (Backend as a Service หรือ BaaS) - เช่น AWS Amplify, Azure Mobile Apps, Firebase และ MongoDB Switch
5. การให้บริการแบบผสมผสาน - การเลือกนำรูปแบบต่างๆ ข้างต้นมาใช้ร่วมกัน

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

1. ตำแหน่งที่โทเค็นการเข้าถึงของ Meta API ถูกสร้างขึ้นและส่ง / จัดเก็บ / ต่ออายุ ทั้งในซอฟต์แวร์ไคลเอ็นต์และเซิร์ฟเวอร์ (หากใช้ได้กับการออกแบบระบบ)
2. วิธีที่คุณดึงข้อมูลแพลตฟอร์มจาก API ของ Meta โดยมุ่งเน้นที่ข้อมูลระบุตัวบุคคล (Personally Identifiable Information หรือ PII) เช่น ชื่อบุคคล, อีเมล, เพศ, วันเกิด และข้อมูลผู้ใช้อื่นๆ
3. วิธีที่คุณใช้ จัดเก็บ และส่งข้อมูลนี้
4. บุคคลที่ 4 ใดๆ ที่ได้รับการส่งข้อมูลแพลตฟอร์ม

การเตรียมหลักฐาน

คุณอาจจำเป็นต้องส่งหลักฐานเพื่อสนับสนุนคำตอบที่เกี่ยวข้องกับมาตรการคุ้มครองการรักษาความปลอดภัยข้อมูลที่คุณดำเนินการ เราขอแนะนำให้คุณอ่านคำแนะนำเกี่ยวกับหลักฐานในเอกสารนี้เพื่อดูตัวอย่างหลักฐานที่ยอมรับได้และเตรียมหลักฐานให้สอดคล้องตามคำแนะนำ เรายอมรับประเภทไฟล์เอกสารทั่วไปพร้อมกับภาพหน้าจอและการบันทึกภาพหน้าจอ โปรดตรวจสอบให้แน่ใจว่าไฟล์ไม่ได้มีการป้องกันด้วยรหัสผ่าน คุณสามารถอัพโหลดไฟล์ได้หลายไฟล์ แต่ละไฟล์ไม่เกิน 2 GB โดยเรายอมรับไฟล์ .xls, .xlsx, .csv, .doc, .docx, .pdf, .txt, .jpeg, .jpg, .png, .ppt, .pptx, .mov, .mp4, .zip และ .zipx

ประเภทของหลักฐาน

สำหรับแอพที่ถูกขอให้อัปโหลดหลักฐานที่เกี่ยวข้องกับมาตรการคุ้มครองการรักษาความปลอดภัยข้อมูล Meta กำหนดให้ต้องใช้เอกสารประกอบสองประเภทที่แตกต่างกัน ดังนี้

1. หลักฐานด้านนโยบายหรือขั้นตอน - เอกสารด้านนโยบายหรือขั้นตอนที่อธิบายแนวทางเกี่ยวกับการรักษาความปลอดภัยข้อมูลสำหรับ [มาตรการคุ้มครองนี้]
2. หลักฐานด้านการดำเนินการ - หลักฐานจากระบบหรือแอพพลิเคชั่น เช่น การกำหนดค่าเครื่องมือหรือการถ่ายภาพหน้าจอ ที่แสดงให้เห็นว่าคุณใช้มาตรการคุ้มครองที่ระบุไว้อย่างไร

หลักฐานด้านนโยบายหรือขั้นตอน

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

หลักฐานด้านการดำเนินการ

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

ความสมบูรณ์ของหลักฐาน

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

1. หลักฐานด้านนโยบายหรือขั้นตอนจะต้องเป็นไปตามหรือเกินกว่าข้อกำหนดของ Meta อย่างชัดเจน
1. Meta จะตรวจสอบหลักฐานด้านนโยบายหรือขั้นตอนที่เพื่อหาข้อความที่สอดคล้องกับข้อกำหนดของ Meta สำหรับมาตรการคุ้มครองที่ระบุ
2. คุณควรใส่คำอธิบายประกอบในเอกสารเพื่อไฮไลท์ส่วนที่เกี่ยวข้อง
3. ตัวอย่างเช่น หากเกี่ยวข้องกับมาตรการคุ้มครองโดยเปิดใช้งานการเข้ารหัส TLS 1.2 ขึ้นไปสำหรับการเชื่อมต่อเครือข่ายทั้งหมดที่มีการส่งข้อมูลแพลตฟอร์ม หลักฐานที่ยอมรับได้จะรวมถึงเอกสารที่ระบุข้อความต่อไปนี้อย่างชัดเจน
1. ข้อมูลแพลตฟอร์มจาก Meta ต้องไม่มีการส่งผ่านเครือข่ายที่ไม่น่าเชื่อถือในรูปแบบที่ไม่ได้เข้ารหัส
2. ตัวดักฟังของเว็บทั้งหมด (เช่น โหลดบาลานเซอร์ที่เชื่อมต่อกับอินเทอร์เน็ต) ที่ได้รับหรือส่งคืนข้อมูลแพลตฟอร์มจะได้รับการกำหนดค่าโดยเปิดใช้งานโปรโตคอล TLS 1.2 เอาไว้
3. ตัวดักฟังของเว็บทั้งหมดที่ได้รับหรือส่งคืนข้อมูลแพลตฟอร์มจะได้รับการกำหนดค่าโดยปิดใช้งานโปรโตคอลต่อไปนี้ SSL v2, SSL v3, TLS 1.0 และ TLS 1.1
2. หลักฐานด้านการดำเนินการจะต้องแสดงตัวอย่างอย่างน้อยหนึ่งรายการสำหรับการดำเนินการของแต่ละนโยบายหรือขั้นตอน
1. คุณจะต้องอัพโหลดเอกสาร ภาพหน้าจอ หรือการกำหนดค่าเครื่องมืออย่างน้อยหนึ่งรายการซึ่งแสดงให้เห็นว่าคุณใช้มาตรการคุ้มครองแต่ละรายการอย่างไร
2. Meta จะตรวจสอบหลักฐานด้านการดำเนินการเพื่อให้แน่ใจว่าสอดคล้องกับหลักฐานด้านนโยบายหรือขั้นตอน
3. ตัวอย่างเช่น หากเกี่ยวข้องกับมาตรการคุ้มครองโดยเปิดใช้งานการเข้ารหัส TLS 1.2 ขึ้นไปสำหรับการเชื่อมต่อเครือข่ายทั้งหมดที่มีการส่งข้อมูลแพลตฟอร์ม หลักฐานที่ยอมรับได้จะรวมถึงรายงานการทดสอบ Qualys SSL สำหรับหนึ่งในโดเมนของเว็บที่กำหนดค่าตามนโยบายหรือขั้นตอนนั้นๆ

ข้อมูลที่มีความละเอียดอ่อนที่คุณควรตัดออกจากหลักฐาน

อย่าส่งหลักฐานที่มีข้อมูลที่มีค่าใดๆ เหล่านี้ในรูปแบบที่อ่านได้ (ไม่ได้ตัดออก) หากคุณใช้โปรแกรมแก้ไขรูปภาพสำหรับภาพหน้าจอ ให้วางกล่องดำทับข้อมูลที่มีค่านั้นๆ หากคุณใช้โปรแกรมแก้ไข PDF ให้ตรวจสอบให้แน่ใจว่าคุณตัดข้อความออกโดยใช้เครื่องมือที่ลบค่านั้นออกจริงๆ ไม่ใช่เพียงเพิ่มเลเยอร์แล้วเก็บข้อความไว้อยู่ (เช่น เครื่องมือลบข้อความในแอพ Preview ของ Apple)

• ข้อมูลสุขภาพ
• ข้อมูลการเงิน
• ที่อยู่ IP
• รหัสผ่าน, ข้อมูลประจำตัว และโทเค็นการเข้าถึง
• คีย์การเข้ารหัส
• ที่อยู่จริง
• ข้อมูลระบุตัวบุคคล (Personally Identifiable Information หรือ PII) เกี่ยวกับบุคคลธรรมดา (ไม่รวมถึงธุรกิจหรือองค์กรธุรกิจอื่นๆ) พนักงานหรือบริษัทในเครืออื่นๆ ที่สามารถระบุตัวบุคคลนั้นได้โดยตรงหรือโดยอ้อม เช่น

  • ชื่อ
  • ที่อยู่อีเมล
  • ID ผู้ใช้
  • วันเกิด
  • ข้อมูลตำแหน่ง
  • ข้อมูลสุขภาพ
  • ข้อมูลระบุตัวตนด้านวัฒนธรรม สังคม การเมือง
  • ข้อมูลที่สามารถระบุตัวบุคคลได้ในบริบทเฉพาะของหลักฐาน
• ขั้นตอนการทำซ้ำโดยละเอียดเพื่อหาช่องโหว่ (เช่น ในรายงานการทดสอบการเจาะระบบ)
• ข้อมูลที่ผู้พัฒนาทราบหรือมีเหตุผลอันควรที่จะทราบนั้นมาจากหรือเกี่ยวกับเด็กอายุต่ำกว่า 13 ปี

การปกป้องข้อมูลแพลตฟอร์มที่จัดเก็บบนฝั่งเซิร์ฟเวอร์ด้วยการเข้ารหัสข้อมูลที่จัดเก็บ

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

เจตนา

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

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

สรุปข้อกำหนด

หากคุณจัดเก็บข้อมูลแพลตฟอร์มบนฝั่งเซิร์ฟเวอร์ ให้ใช้ข้อกำหนดเหล่านี้

• คุณต้องปกป้องข้อมูลดังกล่าวด้วยวิธีดังนี้

  • การเข้ารหัสข้อมูลที่จัดเก็บ หรือ
  • การปกป้องอื่นที่ยอมรับได้ (ดูการปกป้องอื่นที่ยอมรับได้)

• ระดับการเข้ารหัสควรเป็นดังนี้ โดยขึ้นอยู่กับประเภทการเข้ารหัสนั้นๆ

  • ใช้ได้ทั้งการเข้ารหัสระดับแอพพลิเคชั่น (เช่น ซอฟต์แวร์เข้ารหัส/ถอดรหัสคอลัมน์ที่เฉพาะเจาะจงในฐานข้อมูล) หรือเข้ารหัสแบบทั้งดิสก์
  • แม้ว่าเราจะแนะนำให้ใช้การเข้ารหัสที่ได้มาตรฐานอุตสาหกรรม (เช่น AES, BitLocker, Blowfish, TDES, RSA) แต่เราก็ไม่ได้กำหนดอัลกอริทึมหรือความยาวของคีย์ที่เฉพาะเจาะจง

หากผู้พัฒนาไม่ได้จัดเก็บข้อมูลแพลตฟอร์มบนฝั่งเซิร์ฟเวอร์ ข้อกำหนดนี้จะไม่บังคับใช้

กรณีพิเศษ

การจัดเก็บข้อมูลบนฝั่งเซิร์ฟเวอร์โดยใช้ IaaS, การโฮสต์ด้วยตนเอง หรือการโฮสต์แบบผสมผสาน

หากคุณจัดเก็บข้อมูลแพลตฟอร์มโดยใช้การโฮสต์ IaaS (เช่น AWS EC2, Microsoft Azure IaaS และ Google Compute Engine), การโฮสต์ด้วยตนเอง หรือการโฮสต์แบบผสมผสาน คำถามนี้ถือว่าเกี่ยวข้องกับคุณ

การจัดเก็บข้อมูลบนฝั่งเซิร์ฟเวอร์โดยใช้ผลิตภัณฑ์ SaaS, PaaS หรือ BaaS

อย่างไรก็ตาม ยังมีโมเดลโฮสติ้งฝั่งแบ็คเอนด์อื่นๆ ที่เป็นกรณีพิเศษ ได้แก่

หากคุณจัดเก็บข้อมูลแพลตฟอร์มผ่านผลิตภัณฑ์เหล่านี้ (และไม่ใช้ IaaS, การโฮสต์ด้วยตนเอง หรือการโฮสต์แบบผสมผสาน) คำถามนี้ถือว่าไม่เกี่ยวข้องกับคุณ คุณควรอธิบายความสัมพันธ์นี้ในส่วนผู้ให้บริการใน DPA แทน

• BaaS เช่น AWS Amplify, Azure Mobile Apps, Azure Playfab, Google Firebase และ MongoDB Switch
• PaaS เช่น AWS Elastic Beanstalk, Google App Engine, Force.com
• SaaS เช่น MailChimp หรือ Salesforce

การจัดเก็บข้อมูลบนฝั่งเซิร์ฟเวอร์โดยใช้ API ของ Meta

หากคุณจัดเก็บข้อมูลแพลตฟอร์มผ่าน API ของ Meta เท่านั้น ยกตัวอย่างเช่น โดยใช้ player.setDataAsync() ใน SDK เกมทันใจ คำถามนี้ถือว่าไม่เกี่ยวข้องกับคุณ

คำแนะนำด้านหลักฐาน

หากมีการขอให้คุณส่งหลักฐานสำหรับการปกป้องข้อมูล ให้ปฏิบัติตามคำสั่งในส่วนการเตรียมหลักฐาน เพื่อเตรียมหลักฐานเกี่ยวกับนโยบาย/ขั้นตอนและการนำไปปฏิบัติ

ตัวอย่างหลักฐานด้านการดำเนินการ

AWS RDS

AWS RDS - การเข้ารหัสข้อมูลที่จัดเก็บสามารถกำหนดค่าได้ใน AWS RDS ดังนั้นผู้พัฒนาจึงต้องตรวจสอบให้แน่ใจว่าได้ตั้งค่าตัวเลือกการกำหนดค่าให้ใช้การปกป้องนี้

สำหรับอินสแตนซ์ RDS ตัวแทนที่มีข้อมูลแพลตฟอร์ม ให้ใช้เครื่องมือ AWS CLI เพื่อเรียกดูการกำหนดค่า StorageEncrypted ของอินสแตนซ์นั้นๆ

# List RDS instances in default region
$ aws rds describe-db-instances \
  --query 'DBInstances[*].DBInstanceIdentifier'

[
    "database-1",
    "database-2"
]

# For each instance returned, retrieve the storage encrypted config
$ aws rds describe-db-instances \
  --db-instance-identifier database-1 \
  --query 'DBInstances[*].StorageEncrypted'
[
    true
]

$ aws rds describe-db-instances \
  --db-instance-identifier database-2 \
  --query 'DBInstances[*].StorageEncrypted'
[
    true
]

AWS DynamoDB

AWS DynamoDB จะมีการเข้ารหัสข้อมูลที่จัดเก็บเป็นค่าเริ่มต้น คุณสามารถเรียกดูการกำหนดค่าการเข้ารหัสข้อมูลที่จัดเก็บสำหรับตารางโดยใช้คำสั่งเหล่านี้

$ aws dynamodb list-tables --output table

--------------
| ListTables |
+------------+
||TableNames||
|+----------+|
||  Users   ||
|+----------+|


$ aws dynamodb describe-table \
 --table-name Users \
 --query "Table.SSEDescription.Status"

"ENABLED"

AWS DocumentDB

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

$ aws docdb describe-db-clusters --query 'DBClusters[*].DBClusterIdentifier'

[
    "docdb-users"
]

$ aws docdb describe-db-clusters \
  --db-cluster-identifier 'docdb-users' \
  --query 'DBClusters[*].StorageEncrypted'
[
    true
]

AWS S3

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

$ aws s3api list-buckets --output table --query "Buckets[*].Name"

---------------------------------------------
|                ListBuckets                |
+-------------------------------------------+
|  platform.storage                         |
+-------------------------------------------+

$ aws s3api get-bucket-encryption \
  --bucket  platform.storage \
  --query "ServerSideEncryptionConfiguration.Rules[*].ApplyServerSideEncryptionByDefault" \
  --output table
---------------------
|GetBucketEncryption|
+-------------------+
|   SSEAlgorithm    |
+-------------------+
|  AES256           |
+-------------------+

Microsoft Azure

ดูเอกสารประกอบการเข้ารหัสข้อมูลที่จัดเก็บใน Azure ของ Microsoft ที่เกี่ยวข้องกับการใช้บริการขององค์กร

Google Cloud Platform

ดูเอกสารประกอบการเข้ารหัสข้อมูลที่จัดเก็บบน Google Cloud Platform ของ Google

การปกป้องอื่นที่ยอมรับได้

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

1. ความละเอียดอ่อนของข้อมูลแพลตฟอร์ม - การจัดเก็บข้อมูลแพลตฟอร์มบางประเภทจะถือว่ามีความเสี่ยงต่ำหรือสูงกว่าการจัดเก็บข้อมูลประเภทอื่นๆ คุณจะต้องศึกษาว่าคุณลักษณะของผู้ใช้ข้อมูลแพลตฟอร์มที่เฉพาะเจาะจงแบบใดที่จัดเก็บอยู่บนฝั่งเซิร์ฟเวอร์
2. การควบคุมที่ปรับใช้เพื่อลดแนวโน้มที่จะเกิดอันตรายบางประเภท
1. การควบคุมเพื่อป้องกันการบุกรุกเครือข่ายที่มีข้อมูลแพลตฟอร์ม
2. การควบคุมเพื่อป้องกันการบุกรุกแอพ/ระบบที่สามารถเข้าถึงข้อมูลแพลตฟอร์ม
3. การควบคุมเพื่อป้องกันการสูญหายของสื่อที่จัดเก็บข้อมูลในสถานที่จริง (เช่น อุปกรณ์จัดเก็บข้อมูลบนเครือข่ายที่เลิกใช้งานแล้ว) ซึ่งมีข้อมูลแพลตฟอร์มอยู่
4. การควบคุมเพื่อป้องกันการสูญหายของสื่อที่จัดเก็บข้อมูลในสถานที่จริง (เช่น อุปกรณ์จัดเก็บข้อมูลบนเครือข่ายที่เลิกใช้งานแล้ว) ซึ่งมีข้อมูลแพลตฟอร์มอยู่
5. การควบคุมเพื่อป้องกันการเข้าถึงโดยไม่ได้รับอนุญาตซึ่งเข้าถึงสำเนาพื้นที่เก็บข้อมูลที่มีการสำรองข้อมูลแพลตฟอร์มอยู่
3. ความน่าเชื่อถือของหลักฐาน - ตรวจสอบให้มั่นใจว่ามีการประเมินการป้องกันเหล่านี้โดยผู้ตรวจสอบอิสระ เช่น การประเมินอันเป็นส่วนหนึ่งในการตรวจสอบการควบคุมองค์กรบริการประเภท 2 (SOC2)

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

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

เจตนา

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

สรุปข้อกำหนด

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

  • การควบคุมทางเทคนิค - ตัวอย่างของการควบคุมทางเทคนิค ได้แก่ 1) การอนุญาตให้เฉพาะอุปกรณ์ที่มีการจัดการสามารถเชื่อมต่อกับเครือข่ายขององค์กรได้ 2) การใช้การเข้ารหัสดิสก์โดยสมบูรณ์บนอุปกรณ์ที่มีการจัดการ (เช่น BitLocker) 3) การบล็อกไม่ให้อุปกรณ์เก็บข้อมูลแบบเคลื่อนย้ายได้ (เช่น ไดรฟ์ USB) เชื่อมต่อกับอุปกรณ์ที่มีการจัดการ 4) การใช้เทคโนโลยีการป้องกันการสูญหายของข้อมูล (DLP) บนอุปกรณ์ที่มีการจัดการ
  • การควบคุมด้านการบริหารจัดการ - ตัวอย่างของการควบคุมด้านการบริหารจัดการรวมถึงเอกสารนโยบายที่เป็นลายลักษณ์อักษรและการฝึกอบรมประจำปีเกี่ยวกับวิธีที่ยอมรับได้ในการจัดการข้อมูลแพลตฟอร์มบนอุปกรณ์ขององค์กรและอุปกรณ์ส่วนตัว

คำแนะนำด้านหลักฐาน

หากมีการขอให้คุณส่งหลักฐานสำหรับการปกป้องข้อมูล ให้ปฏิบัติตามคำสั่งในส่วนการเตรียมหลักฐาน เพื่อเตรียมหลักฐานเกี่ยวกับนโยบาย/ขั้นตอนและการนำไปปฏิบัติ

คุณสามารถใช้วิธีใดวิธีหนึ่งหรือทั้งสองวิธีต่อไปนี้ ได้แก่ a) การควบคุมทางเทคนิค (เช่น การเข้ารหัสดิสก์) หรือ b) กฎ/นโยบายเพื่อลดความเสี่ยงที่ข้อมูลจะสูญหายสำหรับข้อมูลแพลตฟอร์มที่จัดเก็บไว้บนอุปกรณ์ขององค์กร เช่น แล็ปท็อปและโทรศัพท์มือถือ

การควบคุมทางเทคนิคอาจรวมถึงการดำเนินการต่อไปนี้

• การบล็อกไม่ให้อุปกรณ์ที่ไม่มีการจัดการสามารถเชื่อมต่อกับบริการที่มีความละเอียดอ่อนได้ เช่น เครือข่ายการผลิต
• การใช้การเข้ารหัสดิสก์บนอุปกรณ์ที่มีการจัดการ (เช่น ผ่านทาง BitLocker บน Windows หรือ FileVault บน Mac)
• การบล็อกไม่ให้สามารถใช้อุปกรณ์แบบเคลื่อนย้ายได้ (เช่น ไดรฟ์ USB) บนอุปกรณ์ที่มีการจัดการ
• การใช้ซอฟต์แวร์ DLP บนอุปกรณ์ที่มีการจัดการเพื่อบล็อกการจัดการข้อมูลแพลตฟอร์มอย่างไม่เหมาะสม (เช่น การส่งข้อมูลในไฟล์แนบในอีเมล)

กฎ/นโยบายอาจรวมถึงรายการต่อไปนี้

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

ตัวอย่างหลักฐาน

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

การปกป้องข้อมูลแพลตฟอร์มที่ส่งผ่านเครือข่ายด้วยการเข้ารหัสข้อมูลที่อยู่ระหว่างการถ่ายโอน

คำถาม: คุณเปิดใช้งานโปรโตคอลการรักษาความปลอดภัย TLS 1.2 ขึ้นไปสำหรับการเชื่อมต่อเครือข่ายทั้งหมดที่ผ่าน เชื่อมต่อกับ หรือข้ามเครือข่ายสาธารณะที่มีการส่งผ่านข้อมูลแพลตฟอร์มหรือไม่ นอกจากนี้แล้ว คุณรับประกันหรือไม่ว่าไม่เคยมีการส่งข้อมูลแพลตฟอร์มผ่านทางเครือข่ายสาธารณะด้วยรูปแบบที่ไม่ได้เข้ารหัส (เช่น HTTP หรือ FTP) และไม่เคยมีการใช้โปรโตคอลการรักษาความปลอดภัย SSL เวอร์ชั่น 2 และ SSL เวอร์ชั่น 3

เจตนา

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

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

สรุปข้อกำหนด

ไม่ว่าคุณจะประมวลข้อมูลแพลตฟอร์มบนฝั่งเซิร์ฟเวอร์หรือไม่

• ข้อมูลแพลตฟอร์มต้องไม่มีการส่งผ่านเครือข่ายที่ไม่น่าเชื่อถือในรูปแบบที่ไม่ได้เข้ารหัส
• สำหรับตัวดักฟังของเว็บทั้งหมด (เช่น โหลดบาลานเซอร์ที่เชื่อมต่อกับอินเทอร์เน็ต) ที่ได้รับหรือส่งคืนข้อมูลแพลตฟอร์ม คุณต้องดำเนินการต่อไปนี้

  • เปิดใช้งาน TLS 1.2 หรือสูงกว่า
  • ปิดใช้งาน SSL เวอร์ชั่น 2 และ SSL เวอร์ชั่น 3
• คุณสามารถใช้ TLS 1.0 และ TLS 1.1 เพื่อให้ใช้งานร่วมกับอุปกรณ์ไคลเอ็นต์ที่ไม่สามารถใช้ TLS 1.2+ ได้
• Meta ขอแนะนำ แต่ไม่ได้กำหนด ให้ใช้การเข้ารหัสข้อมูลที่อยู่ระหว่างการถ่ายโอนกับการส่งผ่านข้อมูลแพลตฟอร์มที่อยู่ภายในเครือข่ายส่วนตัวทั้งหมด เช่น ภายในระบบคลาวด์ส่วนตัวเสมือน (VPC)

ตารางด้านล่างสรุปนโยบายเกี่ยวกับการเข้ารหัสข้อมูลที่อยู่ระหว่างการถ่ายโอนสำหรับประเภทการส่งผ่านข้อมูลที่แตกต่างกัน

คำแนะนำด้านหลักฐาน

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

• เรียกใช้เครื่องมือทดสอบเซิร์ฟเวอร์ Qualys SSL กับตัวดักฟังเว็บอย่างน้อย 1 ตัวที่ถูกกำหนดค่าให้เหมือนกัน (รวมถึงตัวดังฟังเว็บใดๆ ที่ทำงานบนพอร์ทที่ไม่เป็นไปตามมาตรฐาน)
• ทำเครื่องหมายที่ตัวเลือก “ไม่แสดงผลลัพธ์บนบอร์ด” เพื่อป้องกันไม่ให้มีการเพิ่มผลลัพธ์ไปยังเว็บไซต์ Qualys พิมพ์หน้าผลการทดสอบทั้งหมดเป็น PDF ทำขั้นตอนด้านบนซ้ำสำหรับตัวดักฟังใดๆ ที่คุณส่งผ่านข้อมูลแพลตฟอร์มไปยัง/จากตัวดังฟังที่มีการกำหนดค่า TLS ที่ต่างกัน

ตัวอย่างหลักฐานด้านการดำเนินการ

นี่คือเอาต์พุตตัวอย่างจากเครื่องมือทดสอบเซิร์ฟเวอร์ Qualys SSL โปรดสังเกตคำอธิบายประกอบสีแดงในส่วน “การกำหนดค่า” ซึ่งสรุปว่า SSL/TLS เวอร์ชั่นใดบ้างที่รองรับ หมายเหตุ: ตัวอย่างนี้มีเพียงสองหน้าแรกเท่านั้น แต่คุณควรใส่เอาต์พุตทดสอบเต็มรูปแบบ

การปกป้องอื่นที่ยอมรับได้

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

• การเข้ารหัสข้อมูลเป็นแบบสมมาตรหรือไม่สมมาตร
• อัลกอริทึมการเข้ารหัสข้อมูล (เช่น AES, BitLocker, TDES, RSA)
• ความยาวของคีย์ขั้นต่ำ

ทดสอบแอพและระบบเพื่อตรวจหาช่องโหว่และปัญหาด้านการรักษาความปลอดภัย

คำถาม: คุณทดสอบแอพและระบบเพื่อตรวจหาช่องโหว่และปัญหาด้านการรักษาความปลอดภัยอย่างน้อยทุกๆ 12 เดือนหรือไม่ (ยกตัวอย่างเช่น คุณทำการทดสอบการเจาะระบบด้วยตนเองหรือไม่)

เจตนา

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

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

สรุปข้อกำหนด

บังคับใช้กับผู้พัฒนาทุกคน:

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

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

ข้อกำหนดเพิ่มเติมสำหรับผู้พัฒนาที่ประมวลผลข้อมูลแพลตฟอร์มฝั่งเซิร์ฟเวอร์มีดังนี้

• คุณต้องทดสอบซอฟต์แวร์ฝั่งเซิร์ฟเวอร์อย่างเฉพาะเจาะจงเพื่อหาช่องโหว่ด้านการรักษาความปลอดภัยโดยดำเนินการอย่างใดอย่างหนึ่งต่อไปนี้

  • การทดสอบเจาะแอพ/ระบบ หรือ
  • การสแกนหาช่องโหว่/การวิเคราะห์แบบคงที่ และคุณยังต้องทดสอบการกำหนดค่าระบบคลาวด์เพื่อตรวจหาปัญหาด้านการรักษาความปลอดภัยหากคุณกำลังใช้ผู้ให้บริการโฮสต์ระบบคลาวด์อีกด้วย ข้อกำหนดนี้มีผลบังคับใช้โดยไม่คำนึงถึงแนวทางการโฮสต์ (เช่น BaaS, PaaS, IaaS, แบบโฮสต์ด้วยตนเอง, หรือแบบไฮบริด)

คำแนะนำด้านหลักฐาน

หากมีการขอให้คุณส่งหลักฐานสำหรับการปกป้องข้อมูล ให้ปฏิบัติตามคำสั่งในส่วนการเตรียมหลักฐาน เพื่อเตรียมหลักฐานเกี่ยวกับนโยบาย/ขั้นตอนและการนำไปปฏิบัติ

หากองค์กรประมวลผลข้อมูลแพลตฟอร์มในสภาพแวดล้อมระบบคลาวด์/เซิร์ฟเวอร์ ให้ทำสิ่งต่อไปนี้

• ส่งหลักฐานว่าการทดสอบการเจาะระบบ หรือการดำเนินเครื่องมือ SAST เสร็จสมบูรณ์แล้ว หลักฐานควรประกอบด้วยสิ่งต่อไปนี้

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

• หากทำได้ (กล่าวคือ หากคุณกำลังใช้โฮสต์ระบบคลาวด์ เช่น AWS, GCP, Azure หรือที่คล้ายกัน) ให้ส่งหลักฐานว่ามีการดำเนินการตรวจสอบการกำหนดค่าระบบคลาวด์แล้ว เช่น ผลลัพธ์ของการเรียกใช้ NCC Scout Suite, AWS Config หรือที่คล้ายกัน หากองค์กรไม่ได้ใช้วิธีนี้ ให้รวมเอกสารที่อธิบายว่าทำไมการตรวจสอบการกำหนดค่าระบบคลาวด์จึงไม่อยู่ในขอบเขตของกรณีนี้ไว้ในหลักฐานที่ส่งด้วย
• ลบหรือแก้ไขข้อมูลที่ละเอียดอ่อนอย่างขั้นตอนการถอดแบบช่องโหว่โดยละเอียดออกจากหลักฐานก่อนทำการส่ง

หากองค์กรไม่ประมวลผลข้อมูลแพลตฟอร์มในสภาพแวดล้อมระบบคลาวด์หรือเซิร์ฟเวอร์ ให้ทำสิ่งต่อไปนี้

• ส่งหลักฐานว่าการทดสอบการเจาะระบบ หรือการดำเนินเครื่องมือ SAST เสร็จสมบูรณ์แล้ว หลักฐานควรประกอบด้วยสิ่งต่อไปนี้

  • คำชี้แจงขอบเขตของการทดสอบ
  • วันที่การทดสอบเสร็จสมบูรณ์ โดยวันดังกล่าวควรอยู่ภายใน 12 เดือนที่ผ่านมา
  • ข้อมูลสรุปหรือรายการช่องโหว่ที่ค้นพบระหว่างการทดสอบ ข้อมูลสรุปหรือรายการต้องมีประเภทความรุนแรง (เช่น ร้ายแรง, สูง, กลาง, ต่ำ, เป็นข้อมูลประกอบ) โดยทั่วไป เราจะคาดหวังให้ไม่มีช่องโหว่ที่มีความอันตรายระดับร้ายแรงหรือระดับสูงที่ยังไม่ได้แก้ไข
• ลบหรือแก้ไขข้อมูลที่ละเอียดอ่อนอย่างขั้นตอนการถอดแบบช่องโหว่โดยละเอียดออกจากหลักฐานก่อนทำการส่ง

ตัวอย่างหลักฐาน

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

การวิเคราะห์แบบคงที่ - หากใช้แนวทางอื่น เช่น เครื่องมือ SAST ให้ส่งออกผลลัพธ์ไปยังเอกสารที่มีวันที่เรียกใช้งาน SAST และรายการของสิ่งที่ค้นพบที่มีประเภทของสิ่งที่ค้นพบแต่ละรายการและระดับความรุนแรง/ความวิกฤต

การตรวจสอบการกำหนดค่าระบบคลาวด์

ผู้พัฒนาใช้ NCC Scout Suite โดยใช้ชุดกฎเริ่มต้นสำหรับผู้ให้บริการระบบคลาวด์ของตน (ในกรณีนี้คือ AWS) เพื่อตรวจสอบการกำหนดค่าระบบคลาวด์เพื่อหาช่องโหว่และปัญหาด้านการรักษาความปลอดภัย เครื่องมือจะแสดงผลไฟล์ JSON ที่มีผลลัพธ์ที่ได้อย่างละเอียด ในตัวอย่างนี้ มีการรายงานความรุนแรงของปัญหาจำนวนหนึ่งว่า "อันตราย" ซึ่งผู้พัฒนาจำเป็นต้องตรวจสอบและแก้ไข

$ python3 scout.py aws –-no-browser
2022-08-22 11:39:38 localhost scout[76981] INFO Saving data to scoutsuite-report/scoutsuite-results/scoutsuite_results_aws-043954759379.js

$ cd scoutsuite-report/scoutsuite-results
$ tail -n +2 scoutsuite_results_aws-043954750000.js| jq '. | {last_run}' | pbcopy

{
  "last_run": {
    "ruleset_about": "This ruleset consists of numerous rules that are considered standard by NCC Group. The rules enabled range from violations of well-known security best practices to gaps resulting from less-known security implications of provider-specific mechanisms. Additional rules exist, some of them requiring extra-parameters to be configured, and some of them being applicable to a limited number of users.",
    "ruleset_name": "default",
    "run_parameters": {
      "excluded_regions": [],
      "regions": [],
      "services": [],
      "skipped_services": []
    },
    "summary": {
      "acm": {
        "checked_items": 4,
        "flagged_items": 2,
        "max_level": "warning",
        "resources_count": 2,
        "rules_count": 2
      },
      "awslambda": {
        "checked_items": 0,
        "flagged_items": 0,
        "max_level": "warning",
        "resources_count": 0,
        "rules_count": 0
      },
      "cloudformation": {
        "checked_items": 11,
        "flagged_items": 0,
        "max_level": "warning",
        "resources_count": 11,
        "rules_count": 1
      },
      "cloudfront": {
        "checked_items": 0,
        "flagged_items": 0,
        "max_level": "warning",
        "resources_count": 0,
        "rules_count": 3
      },
      "cloudtrail": {
        "checked_items": 153,
        "flagged_items": 4,
        "max_level": "danger",
        "resources_count": 17,
        "rules_count": 9
      },
      "cloudwatch": {
        "checked_items": 2,
        "flagged_items": 0,
        "max_level": "warning",
        "resources_count": 2,
        "rules_count": 1
      },
      "codebuild": {
        "checked_items": 0,
        "flagged_items": 0,
        "max_level": "warning",
        "resources_count": 0,
        "rules_count": 0
      },
      "config": {
        "checked_items": 17,
        "flagged_items": 0,
        "max_level": "warning",
        "resources_count": 1227,
        "rules_count": 1
      },
      "directconnect": {
        "checked_items": 0,
        "flagged_items": 0,
        "max_level": "warning",
        "resources_count": 0,
        "rules_count": 0
      },
      "dynamodb": {
        "checked_items": 0,
        "flagged_items": 0,
        "max_level": "warning",
        "resources_count": 1,
        "rules_count": 0
      },
      "ec2": {
        "checked_items": 760,
        "flagged_items": 108,
        "max_level": "danger",
        "resources_count": 44,
        "rules_count": 28
      },
      "efs": {
        "checked_items": 0,
        "flagged_items": 0,
        "max_level": "warning",
        "resources_count": 0,
        "rules_count": 0
      },
      "elasticache": {
        "checked_items": 0,
        "flagged_items": 0,
        "max_level": "warning",
        "resources_count": 0,
        "rules_count": 0
      },
      "elb": {
        "checked_items": 0,
        "flagged_items": 0,
        "max_level": "warning",
        "resources_count": 0,
        "rules_count": 3
      },
      "elbv2": {
        "checked_items": 42,
        "flagged_items": 4,
        "max_level": "danger",
        "resources_count": 0,
        "rules_count": 5
      },
      "emr": {
        "checked_items": 0,
        "flagged_items": 0,
        "max_level": "warning",
        "resources_count": 0,
        "rules_count": 0
      },
      "iam": {
        "checked_items": 801,
        "flagged_items": 27,
        "max_level": "danger",
        "resources_count": 87,
        "rules_count": 37
      },
      "kms": {
        "checked_items": 15,
        "flagged_items": 0,
        "max_level": "warning",
        "resources_count": 15,
        "rules_count": 1
      },
      "rds": {
        "checked_items": 1,
        "flagged_items": 0,
        "max_level": "warning",
        "resources_count": 27,
        "rules_count": 9
      },
      "redshift": {
        "checked_items": 0,
        "flagged_items": 0,
        "max_level": "warning",
        "resources_count": 0,
        "rules_count": 6
      },
      "route53": {
        "checked_items": 0,
        "flagged_items": 0,
        "max_level": "warning",
        "resources_count": 1,
        "rules_count": 3
      },
      "s3": {
        "checked_items": 121,
        "flagged_items": 34,
        "max_level": "warning",
        "resources_count": 7,
        "rules_count": 18
      },
      "secretsmanager": {
        "checked_items": 0,
        "flagged_items": 0,
        "max_level": "warning",
        "resources_count": 1,
        "rules_count": 0
      },
      "ses": {
        "checked_items": 0,
        "flagged_items": 0,
        "max_level": "warning",
        "resources_count": 0,
        "rules_count": 4
      },
      "sns": {
        "checked_items": 0,
        "flagged_items": 0,
        "max_level": "warning",
        "resources_count": 0,
        "rules_count": 7
      },
      "sqs": {
        "checked_items": 0,
        "flagged_items": 0,
        "max_level": "warning",
        "resources_count": 0,
        "rules_count": 8
      },
      "vpc": {
        "checked_items": 271,
        "flagged_items": 211,
        "max_level": "warning",
        "resources_count": 0,
        "rules_count": 9
      }
    },
    "time": "2022-08-22 11:42:25-0400",
    "version": "5.11.0"
  }
}

อีกแนวทางหนึ่งในการดำเนินการตรวจสอบการกำหนดค่าระบบคลาวด์สำหรับผู้พัฒนาโดยใช้ชุดกฎของ Amazon Web Services

# Show that AWS Foundational Security Best Practices are enabled
$ aws securityhub get-enabled-standards                                                                                                            
{
    "StandardsSubscriptions": [
        {
            "StandardsSubscriptionArn": "arn:aws:securityhub:us-west-1:043954759379:subscription/aws-foundational-security-best-practices/v/1.0.0",
            "StandardsArn": "arn:aws:securityhub:us-west-1::standards/aws-foundational-security-best-practices/v/1.0.0",
            "StandardsStatus": "READY"
        }
    ]
}

# Show that aggregator is configured for a representative region used to process Platform Data
$ aws securityhub list-finding-aggregators

$ aws securityhub get-finding-aggregator --finding-aggregator-arn '{REPLACE-WITH-FINDING-AGGREGATOR-ARN}'


# Demonstrate that the ruleset is running by fetching active findings and counting the number of lines of output
$ aws securityhub get-findings --query 'Findings[?RecordState==`ACTIVE`]' --filters '{"GeneratorId":[{"Value": "aws-foundational-security","Comparison":"PREFIX"}]}' --output text | wc -l                                     

4876
# Demonstrate that there are no active critical severity findings
$ aws securityhub get-findings --query 'Findings[?Severity.Label==`CRITICAL`] | [?RecordState==`ACTIVE`] | [*][Title, GeneratorId]' --filters '{"GeneratorId":[{"Value": "aws-foundational-security","Comparison":"PREFIX"}]}'

[]

การปกป้องอื่นที่ยอมรับได้

หากคุณกำลังดำเนินโปรแกรมเปิดเผยช่องโหว่ (VDP) ที่ใช้งานได้ เช่น การใช้แพลตฟอร์ม BugCrowd หรือ HackerOne คุณสามารถนำเสนอวิธีนี้เป็นการปกป้องอื่นแทนการทดสอบการเจาะระบบหรือการสแกนหาช่องโหว่ ในการนำเสนอ คุณต้องส่งหลักฐานที่ยืนยันเงื่อนไขต่อไปนี้

• ไม่มีการยกเว้นในเรื่องขอบเขตของ VDP ที่เกี่ยวข้องกับวิธีที่คุณประมวลผลข้อมูลแพลตฟอร์ม
• มีการศึกษาและการรายงานช่องโหว่ที่เกิดขึ้นจริงอย่างต่อเนื่องภายใน 12 เดือนที่ผ่านมา โดยทั่วไปจะระบุโดยรายงานช่องโหว่ที่ถูกต้องอย่างน้อย 1 รายการต่อเดือน
• ช่องโหว่ที่ส่งแล้ว (ถูกต้อง) ได้รับการระบุคะแนนความรุนแรง เช่น การใช้ CVSS 3.1
• ช่องโหว่ได้รับการแก้ไขในระยะเวลาที่สมเหตุสมผล โดยทั่วไปจะน้อยกว่า 90 วันหลังจากวันที่ส่ง

ในกรณีนี้ หลักฐานควรมีเอกสารต่อไปนี้

• คำชี้แจงขอบเขตและคำอธิบายว่าขอบเขตดังกล่าวสัมพันธ์กับซอฟต์แวร์ที่ใช้ในการประมวลผลข้อมูลแพลตฟอร์มอย่างไร
• และรายงานการส่งข้อมูลช่องโหว่ที่เกิดขึ้นจริงในโปรแกรมในช่วง 12 เดือนที่ผ่านมา รายงานควรมีชื่อช่องโหว่, วันที่ส่ง, วันที่แก้ไข (หากแก้ไขแล้ว) และหมวดหมู่/คะแนนความรุนแรง

ปกป้องข้อมูลลับของแอพ Meta และโทเค็นการเข้าถึง API

คำถาม: โทเค็นการเข้าถึง API ของ Meta และข้อมูลลับของแอพได้รับการปกป้องในทั้งสองวิธีต่อไปนี้หรือไม่

1. ไม่จัดเก็บโทเค็นการเข้าถึง API ของ Meta ไว้ในอุปกรณ์ไคลเอ็นต์ซึ่งสามารถเข้าถึงได้ภายนอกแอพและผู้ใช้ปัจจุบัน
2. ใช้ Data Vault (เช่น Vault โดย Hashicorp) ที่มีบริการจัดการคีย์ (KMS) แยกต่างหาก หากถูกจัดเก็บไว้ในสภาพแวดล้อมแบบระบบคลาวด์ เซิร์ฟเวอร์ หรือศูนย์ข้อมูล

เจตนา

ข้อมูลลับของแอพและโทเค็นการเข้าถึงเป็นพื้นฐานในการรักษาความปลอดภัยว่า API ของ Meta จะตัดสินใจเกี่ยวกับการดำเนินการที่จะอนุญาตอย่างไร หากบุคคลที่ไม่ได้รับอนุญาตสามารถเข้าถึงข้อมูลประจำตัวเหล่านี้ บุคคลดังกล่าวอาจเรียกใช้ API ของ Meta โดยแอบอ้างตนเป็นผู้พัฒนาตัวจริง แล้วดำเนินการใดๆ ที่เราได้ให้สิทธิ์แก่แอพดังกล่าวไว้ (เช่น การอ่านข้อมูลเกี่ยวกับผู้ใช้ของแอพจาก API ของ Meta)

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

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

สรุปข้อกำหนด

โทเค็นการเข้าถึง

1. บนอุปกรณ์ไคลเอ็นต์ - จะต้องไม่เขียนโทเค็นการเข้าถึงของ Meta ในลักษณะที่ให้ผู้ใช้หรือกระบวนการอื่นอ่านได้
2. ฝั่งเซิร์ฟเวอร์ - หากคุณประมวลผลหรือจัดเก็บโทเค็นการเข้าถึงของ Meta บนฝั่งเซิร์ฟเวอร์ โทเค็นการเข้าถึงเหล่านั้นต้องได้รับการจัดการดังต่อไปนี้
1. ต้องได้รับการปกป้องด้วยการใช้ Data Vault (เช่น Vault โดย Hashicorp) ที่มีบริการจัดการคีย์ (KMS) แยกต่างหาก และที่ซึ่งการเข้าถึงคีย์ถอดรหัสถูกจำกัดเฉพาะแอพพลิเคชั่นนั้นๆ
2. ต้องไม่เขียนลงในไฟล์ลงบันทึก

ข้อมูลลับของแอพ - เงื่อนไขหนึ่งในสองอย่างต่อไปนี้ต้องเป็นจริง

1. คุณไม่เคยเผยแพร่ข้อมูลลับของแอพนอกสภาพแวดล้อมของเซิร์ฟเวอร์ที่มีการรักษาความปลอดภัย (เช่น ไม่เคยมีการส่งข้อมูลลับกลับด้วยการเรียกใช้ผ่านเครือข่ายไปยังเบราว์เซอร์หรือแอพมือถือ และข้อมูลลับดังกล่าวไม่ได้ฝังไว้ในโค้ดซึ่งเผยแพร่ไปยังไคลเอ็นต์สำหรับมือถือหรือแบบเนทีฟ/เดสก์ท็อป)
2. หรือคุณต้องได้กำหนดค่าแอพให้เป็นประเภทเนทีฟ/เดสก์ท็อป เพื่อให้ API ของ Meta ไม่วางใจการเรียกใช้ API ที่มีข้อมูลลับของแอพอีกต่อไป

คำแนะนำด้านหลักฐาน

หากมีการขอให้คุณส่งหลักฐานสำหรับการปกป้องข้อมูล ให้ปฏิบัติตามคำสั่งในส่วนการเตรียมหลักฐาน เพื่อเตรียมหลักฐานเกี่ยวกับนโยบาย/ขั้นตอนและการนำไปปฏิบัติ

รวมเอกสารเกี่ยวกับนโยบายในการปกป้องโทเค็นการเข้าถึง API ของ Meta และข้อมูลลับของแอพ หากแอพประมวลผลโทเค็นการเข้าถึงของ Meta บนฝั่งเซิร์ฟเวอร์ ให้รวมหลักฐานที่แสดงให้เห็นถึงการปกป้องที่คุณใช้ (เช่น การใช้ Data Vault, การแสดงให้เห็นว่าค่าได้รับการจัดเก็บไว้ในรูปแบบที่มีการเข้ารหัส, การกำหนดค่าของแอพที่กำหนดให้ต้องพิสูจน์ข้อมูลลับของแอพ)

ตัวอย่างหลักฐาน

องค์กรใช้ AWS Secrets Manager เพื่อรักษาความปลอดภัยของการจัดเก็บข้อมูลที่มีความละเอียดอ่อน ซึ่งรวมถึงข้อมูลลับของแอพ Meta

องค์กรได้กำหนดค่าแอพ Meta ของตนให้จำเป็นต้องมีการพิสูจน์ข้อมูลลับของแอพสำหรับการเรียกใช้ API

การปกป้องอื่นที่ยอมรับได้

1. หากคุณไม่ปกป้องโทเค็นการเข้าถึงที่จัดเก็บไว้ในฝั่งเซิร์ฟเวอร์ด้วย Data Vault หรือผ่านการเข้ารหัสระดับแอพ คุณอาจดำเนินการดังต่อไปนี้
1. ปกป้องข้อมูลลับของแอพโดยใช้ Data Vault หรือการเข้ารหัสแอพ โดยคีย์ที่ใช้สามารถเข้าถึงแอพได้เท่านั้น
2. และกำหนดค่าให้แอพกำหนดให้ต้องมีการพิสูจน์ข้อมูลลับของแอพสำหรับการเรียกใช้ API ทั้งหมดไปยัง Meta
2. หากไม่สามารถทำตามแนวทางที่ 1 ได้ (เช่น ไม่สามารถกำหนดให้มีการพิสูจน์ข้อมูลลับของแอพได้ เนื่องจากจะบล็อกการเรียกใช้ API ที่จำเป็นบางอย่าง) Meta จะพิจารณาการควบคุมอื่นๆ ที่คุณมีเพื่อจำกัดความเสี่ยงของการใช้โทเค็นการเข้าถึงโดยไม่ได้รับอนุญาตโดยเปรียบเทียบกับความเสี่ยงของการใช้โทเค็นการเข้าถึงที่เก็บไว้ในทางที่ผิด

มีแผนรับมือกับเหตุการณ์ และทดสอบระบบและกระบวนการรับมือกับเหตุการณ์

คำถาม: คุณทดสอบระบบและกระบวนการที่คุณจะใช้รับมือกับเหตุการณ์เกี่ยวกับการรักษาความปลอดภัย (เช่น การละเมิดข้อมูลหรือการโจมตีทางไซเบอร์) ทุก 12 เดือนเป็นอย่างน้อยหรือไม่

เจตนา

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

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

สรุปข้อกำหนด

ผู้พัฒนาจะต้องมีดังนี้

• แผนรับมือกับเหตุการณ์ที่เป็นไปตามเกณฑ์ขั้นต่ำของ Meta
• เอกสารดังกล่าวจะต้องประกอบไปด้วยหัวข้อดังนี้ (เป็นอย่างน้อย) (1) บทบาทและหน้าที่ (2) การตรวจจับ (3) ขั้นตอนการรับมือตามข้อผูกพันทางกฎหมายที่บังคับใช้ (เช่น การแจ้งเตือนการละเมิดข้อมูลแก่หน่วยงานกำกับดูแลและเจ้าของข้อมูลที่เกี่ยวข้อง) และการฟื้นฟู และ (4) กระบวนการตรวจสอบหลังเกิดเหตุการณ์
• หลักฐานบันทึกว่าแผนดังกล่าวได้รับการทดสอบเมื่อไม่นานมานี้ (ภายในช่วง 12 เดือนที่ผ่านมา) และบุคลากรที่มีรายชื่ออยู่ในแผนได้เข้าร่วมการทดสอบดังกล่าวจริง

คำแนะนำด้านหลักฐาน

ปฏิบัติตามคำแนะนำในส่วนการเตรียมหลักฐาน เพื่อเตรียมหลักฐานเกี่ยวกับนโยบาย/ขั้นตอน และการนำไปปฏิบัติ

• ส่งแผนรับมือกับเหตุการณ์ (เอกสารอย่างน้อย 1 ฉบับ) โดยแผนดังกล่าวควรประกอบด้วยหัวข้อดังนี้: บทบาทและหน้าที่, การตรวจจับ, การรับมือและการฟื้นฟู และการตรวจสอบหลังเกิดเหตุการณ์

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

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

แผนรับมือกับเหตุการณ์

ผู้พัฒนาได้สร้างแผนรับมือกับเหตุการณ์ที่ครอบคลุมตามเทมเพลตนี้ รูปเหล่านี้แสดงเพียงสารบัญเนื้อหา โดยมีลิงก์ไปยังเทมเพลตรูปแบบเต็มที่ด้านล่างด้วย

ดูเทมเพลตแผนรับมือกับเหตุการณ์ของส่วนการโต้ตอบ (รูปแบบไฟล์ docx)

การทดสอบการรับมือกับเหตุการณ์

ผู้พัฒนาได้ทดสอบแผนรับมือกับเหตุการณ์โดยการฝึกซ้อมแบบปากเปล่า และบันทึกผลลัพธ์ตามเทมเพลตนี้

กำหนดให้ต้องมีการยืนยันตัวตนแบบหลายชั้นสำหรับการเข้าถึงจากระยะไกล

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

เจตนา

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

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

สรุปข้อกำหนด

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

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

หากกล่าวถึงโดยเจาะจงแล้ว เครื่องมือต่อไปนี้จำเป็นต้องได้รับการปกป้องด้วย MFA หรือการปกป้องแบบอื่นที่ยอมรับได้

• เครื่องมือสื่อสาร/ทำงานร่วมกัน - เช่น อีเมลธุรกิจหรือ Slack
• คลังโค้ด - เช่น GitHub หรือเครื่องมืออื่นที่ใช้ติดตามการแก้ไขโค้ด/การกำหนดค่าของแอพ/ระบบ
• และเครื่องมือต่อไปนี้ หากคุณประมวลข้อมูลแพลตฟอร์มบนฝั่งเซิร์ฟเวอร์

  • เครื่องมือปรับใช้ซอฟต์แวร์ - เครื่องมือสำหรับปรับใช้โค้ดในสภาพแวดล้อมของระบบคลาวด์/เซิร์ฟเวอร์ เช่น Jenkins หรือเครื่องมือการผสานการทำงานต่อเนื่อง/การปรับใช้ต่อเนื่อง (CI/CD) อื่นๆ
  • เครื่องมือบริหารจัดการ - พอร์ทัลหรือสิทธิ์เข้าถึงอื่นๆ ที่ใช้เพื่อจัดการ/เฝ้าสังเกตสภาพแวดล้อมระบบคลาวด์หรือเซิร์ฟเวอร์
  • สิทธิ์เข้าถึงเซิร์ฟเวอร์จากระยะไกล - SSH, เครื่องมือควบคุมเดสก์ท็อปจากระยะไกล หรือเครื่องมือที่คล้ายคลึงกันซึ่งใช้สำหรับเข้าสู่ระบบเซิร์ฟเวอร์ที่ทำงานบนฝั่งเซิร์ฟเวอร์

สำหรับการนำ MFA ไปใช้ ให้ปฏิบัติดังนี้

• แนะนำให้ใช้แอพหรือฮาร์ดแวร์สำหรับยืนยันตัวตน (เช่น YubiKey) แทนการส่งรหัสผ่าน SMS
• แต่องค์กรสามารถใช้การปรับใช้ MFA ใดๆ ก็ได้

คำแนะนำด้านหลักฐาน

หากมีการขอให้คุณส่งหลักฐานสำหรับการปกป้องข้อมูล ให้ปฏิบัติตามคำสั่งในส่วนการเตรียมหลักฐาน เพื่อเตรียมหลักฐานเกี่ยวกับนโยบาย/ขั้นตอนและการนำไปปฏิบัติ

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

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

ตัวอย่างหลักฐาน

AzureAD

องค์กรใช้ AzureAD เป็นโซลูชันการลงชื่อเข้าใช้ครั้งเดียว นโยบายนี้กำหนดให้ต้องมีการยืนยันตัวตนแบบหลายชั้น

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

Okta

กฎข้อนี้กำหนดให้ต้องมี MFA สำหรับการเข้าสู่ระบบทั้งหมด

AWS IAM

นี่คือตัวอย่างของนโยบาย AWS IAM ที่อนุญาตให้มีการกำหนดค่า MFA แต่สั่งห้ามการดำเนินการอื่นๆ หากไม่มี MFA

GitHub

องค์กรได้กำหนดค่าการยืนยันตัวตน GitHub เพื่อกำหนดให้ใช้ MFA สำหรับทุกคนในองค์กร

การปกป้องอื่นที่ยอมรับได้

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

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

มีระบบสำหรับการดูแลจัดการบัญชีผู้ใช้

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

เจตนา

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

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

  • (1) เพื่อป้องกันไม่ให้บุคคลดังกล่าว (หรืออดีตพนักงาน) เข้าถึงข้อมูล และ
  • (2) เพื่อลดความเป็นไปได้ที่บุคคลที่ไม่ได้รับอนุญาตจะสามารถใช้บัญชีดังกล่าวโดยไม่มีใครสังเกต ตัวอย่างเช่น ผู้ไม่ประสงค์ดีอาจใช้หลักวิศวกรรมสังคมให้ฝ่ายช่วยเหลือด้านไอทีรีเซ็ตรหัสผ่านของบัญชีดังกล่าว หากบัญชีนี้เป็นของพนักงานปัจจุบัน พนักงานคนดังกล่าวอาจรายงานว่าตนไม่สามารถเข้าสู่ระบบได้ แต่หากบัญชียังเปิดใช้งานอยู่ทั้งๆ ที่เป็นของพนักงานที่ลาออกไปแล้ว โอกาสที่จะมีใครสังเกตเห็นก็ย่อมน้อยลง
• เมื่อรู้เช่นนี้แล้ว องค์กรต่างๆ จึงต้องมีกระบวนวิธีในการจัดการบัญชี มอบสิทธิ์การอนุญาตหรือสิทธิ์การใช้งาน และเพิกถอนสิทธิ์เข้าถึงเมื่อไม่จำเป็นต้องใช้แล้ว

สรุปข้อกำหนด

• คุณต้องมีเครื่องมือหรือกระบวนการสำหรับจัดการบัญชีของเครื่องมือ/ระบบ/แอพแต่ละรายการ ดังนี้

  • เครื่องมือ/ระบบ/แอพที่ใช้ติดต่อสื่อสารกับผู้อื่น เช่น Slack หรืออีเมลธุรกิจ
  • เครื่องมือ/ระบบ/แอพที่ใช้ส่งมอบซอฟต์แวร์ เช่น คลังเก็บรหัส และ
  • ดูแลและใช้งานระบบ (ตามที่เกี่ยวข้องกับการประมวลผลข้อมูลแพลตฟอร์ม)
• คุณต้องตรวจสอบการมอบสิทธิ์เข้าถึงเป็นประจำ (ไม่น้อยกว่าหนึ่งครั้งในทุกๆ 12 เดือน) และมีกระบวนการเพิกถอนสิทธิ์เข้าถึงในกรณีต่อไปนี้ (1) เมื่อสิทธิ์ดังกล่าวไม่จำเป็นต้องใช้แล้ว และ (2) ไม่มีการใช้งานแล้ว
• นอกจากนี้ คุณยังต้องมีกระบวนการในการเพิกถอนสิทธิ์เข้าถึงเครื่องมือเหล่านี้ทันทีเมื่อมีบุคคลออกจากองค์กรอีกด้วย
• Meta ไม่ได้กำหนด

  • ว่าต้องใช้เครื่องมือใดโดยเฉพาะ โดยผู้พัฒนาสามารถใช้ผลิตภัณฑ์ไดเรกทอรีอย่าง Google Cloud Identity หรือ Microsoft Azure Active Directory, ผลิตภัณฑ์ระบบคลาวด์อย่างการจัดการข้อมูลระบุตัวตนและสิทธิ์เข้าถึงของ AWS (IAM) หรือใช้ใช้สเปรดชีตที่ได้รับการอัพเดตเป็นประจำ
  • ว่าต้องมีเครื่องมือรวมเพียงอย่างเดียวในการจัดการบัญชีสำหรับสิทธิ์เข้าถึงประเภทต่างๆ เหล่านี้

คำแนะนำด้านหลักฐาน

ปฏิบัติตามคำแนะนำในส่วนการเตรียมหลักฐาน เพื่อเตรียมหลักฐานเกี่ยวกับนโยบาย/ขั้นตอน และการนำไปปฏิบัติ

• นโยบาย/ขั้นตอน - จัดเตรียมเอกสารนโยบายและเอกสารขั้นตอนที่ครอบคลุมหลักปฏิบัติในการจัดการบัญชี เราคาดหวังว่าเอกสารนี้จะมีขั้นตอนสำหรับการสร้างบัญชี, การมอบสิทธิ์การอนุญาต, ความซับซ้อนของรหัสผ่านขั้นต่ำ, นโยบายการล็อกบัญชี, นโยบาย MFA, ขั้นตอนการรีเซ็ตบัญชี และกระบวนการสำหรับการเพิกถอนสิทธิ์เข้าถึงหลังจากไม่มีการใช้งานเป็นระยะเวลาหนึ่งและเมื่อมีคนออกจากองค์กร (เช่น เมื่อพนักงานลาออกหรือเลิกจ้าง)
• หลักฐานการนำไปปฏิบัติ - จัดเตรียมหลักฐานจากเครื่องมือหรือกระบวนการต่อไปนี้อย่างน้อยหนึ่งอย่างที่เตรียมไว้จัดการบัญชี (หรือระบุไว้ว่าไม่เกี่ยวข้องกับสภาพแวดล้อม) (1) อีเมลธุรกิจและเครื่องมือที่ใช้ในการทำงานร่วมกัน (2) คลังเก็บโค้ด (3) เครื่องมือปรับใช้ระบบคลาวด์/เซิร์ฟเวอร์ (4) พอร์ทัลการบริหารจัดการคลาวด์/เซิร์ฟเวอร์ (5) การเข้าสู่ระบบจากระยะไกลบนระบบคลาวด์/เซิร์ฟเวอร์ (เช่น SSH หรือเดสก์ท็อประยะไกล) สำหรับเครื่องมือหรือกระบวนการเฉพาะที่เป็นตัวแทน ให้ระบุหลักฐานที่แสดงให้เห็นถึงสิ่งต่อไปนี้

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

ตัวอย่างหลักฐาน

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

ตัวอย่างการนำไปปฏิบัติ - สิทธิ์เข้าถึงถูกเพิกถอนสำหรับบุคลากรที่ลาออก

ผู้พัฒนาใช้ Workday เป็นแหล่งที่มาที่เชื่อถือได้สำหรับข้อมูลทรัพยากรมนุษย์ (HR) รวมถึงสถานะการจ้างงานปัจจุบัน ผู้พัฒนาคนนี้ใช้ Google Cloud Identity เป็นผู้ให้บริการข้อมูลระบุตัวตน (IdP) ของตนสำหรับการจัดการบัญชีผู้ใช้และการมอบสิทธิ์เข้าถึงระบบข้อมูลและเครื่องมือ

ผู้พัฒนาส่งหลักฐานว่าได้เพิกถอนสิทธิ์เข้าถึงสำหรับบุคลากรที่ลาออกไปแล้วโดยการส่งรายงานที่แสดงให้เห็นว่ามีการเรียกใช้รายงานการกระทบยอดล่าสุด (เช่น ภายใน 12 เดือนที่ผ่านมา) ซึ่งแสดงให้เห็นว่าไม่มีบัญชีผู้ใช้ที่ใช้งานอยู่ใน Google Cloud Identity สำหรับผู้ที่ไม่ใช่พนักงานที่ทำงานอยู่ตามรายงาน Workday ของพนักงานปัจจุบัน

ตัวอย่างการนำไปปฏิบัติ - สิทธิ์เข้าถึงถูกเพิกถอนเมื่อไม่ใช้งานอีกต่อไป

ผู้พัฒนาใช้ Google Cloud Identity เป็นผู้ให้บริการข้อมูลระบุตัวตน (IdP) ของตนสำหรับการจัดการบัญชีผู้ใช้และการมอบสิทธิ์เข้าถึงระบบข้อมูลและเครื่องมือ

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

ตัวอย่างการนำไปปฏิบัติ - GitHub (คลังเก็บรหัส)

ผู้พัฒนาใช้เครื่องมือ Single Sign On (SSO) สำหรับการจัดการข้อมูลระบุตัวตนและการมอบสิทธิ์เข้าถึงระบบข้อมูลและเครื่องมือ ผู้พัฒนาได้กำหนดค่า GitHub เพื่อกำหนดให้มีการยืนยันตัวตน SSO

อัพเดตซอฟต์แวร์ให้เป็นเวอร์ชั่นล่าสุดอยู่เสมอ

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

เจตนา

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

• ผู้พัฒนาแอพใช้ซอฟต์แวร์ของบุคคลที่สามหลากหลายรายการเพื่อเรียกใช้แอพ/ระบบที่ประมวลผลข้อมูลแพลตฟอร์ม
• ตัวอย่างเช่น ผู้พัฒนาจะใช้เครื่องมือเหล่านี้บางรายการหรือทั้งหมด

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

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

สรุปข้อกำหนด

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

1. ไลบรารี, SDK, แพ็คเกจ, คอนเทนเนอร์แอพ และระบบปฏิบัติการที่ใช้ในสภาพแวดล้อมระบบคลาวด์หรือเซิร์ฟเวอร์
2. ไลบรารี, SDK, แพ็คเกจที่ใช้ในอุปกรณ์ไคลเอ็นต์ เช่น ภายในแอพมือถือ
3. ระบบปฏิบัติการและแอพพลิเคชั่นที่สมาชิกขององค์กรใช้ในการสร้างและดำเนินงานแอพ/ระบบของตน เช่น ระบบปฏิบัติการและเบราว์เซอร์ที่ทำงานในแล็ปท็อปของพนักงาน

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

แผนผังด้านล่างแสดงให้เห็นตำแหน่งที่อาจจำเป็นต้องดำเนินการแพตช์สำหรับสถาปัตยกรรมประเภทต่างๆ

คำแนะนำด้านหลักฐาน

หากมีการขอให้คุณส่งหลักฐานสำหรับการปกป้องข้อมูล ให้ปฏิบัติตามคำสั่งในส่วนการเตรียมหลักฐาน เพื่อเตรียมหลักฐานเกี่ยวกับนโยบาย/ขั้นตอนและการนำไปปฏิบัติ

เริ่มต้นโดยการระบุประเภทซอฟต์แวร์ในสภาพแวดล้อมที่อยู่ในขอบเขต เช่น ไลบรารี, SDK, แพ็คเกจ, อิมเมจของแมชชีนเสมือน, คอนเทนเนอร์แอพ รวมถึงระบบปฏิบัติการ เบราว์เซอร์ และแอพพลิเคชั่นอื่นๆ ที่พนักงาน/ผู้มีส่วนร่วมใช้

คุณอาจมีเครื่องมืออย่างน้อยหนึ่งรายการที่คุณใช้ดำเนินกิจกรรมต่อไปนี้

• รายการ - เอกสารผ่านภาพหน้าจอ หรือเอกสารที่เครื่องมือหรือกระบวนการที่โดยหลักแล้วจะแสดงรายการไลบรารี, แพ็คเกจ, SDK, คอนเทนเนอร์, เซิร์ฟเวอร์แอพ และระบบปฏิบัติการที่อยู่ในขอบเขตซึ่งจำเป็นต้องดำเนินการแพตช์ โดยจำเป็นต้องมีรายการสำหรับตัวแทนของประเภทซอฟต์แวร์ (เช่น แอพระบบคลาวด์ แอพไคลเอ็นต์ อุปกรณ์ของพนักงาน)
• การระบุแพตช์ที่พร้อมใช้งานสำหรับซอฟต์แวร์ที่พร้อมใช้งาน - จำเป็นต้องมีเครื่องมือหรือกระบวนการในการระบุแพตช์การรักษาความปลอดภัยที่มีอยู่ซึ่งเกี่ยวข้องกับรายการ
• การจัดลำดับความสำคัญ - จำเป็นต้องมีเครื่องมือหรือกระบวนการ (เช่น ทิกเก็ต Jira, ประเด็นปัญหา GitHub, สเปรดชีตสำหรับการติดตาม) เพื่อใช้ในการกำหนดลำดับความสำคัญให้แก่แพตช์ที่เกี่ยวข้อง

  • การแพตช์
  • เอกสารผ่านภาพหน้าจอ หรือเอกสารที่แสดงให้เห็นว่าหลังจากที่ได้ระบุและจัดลำดับความสำคัญของแพตช์ที่เกี่ยวข้องแล้ว ก็ได้มีการส่งแพตช์ดังกล่าวไปยังปลายทางที่หลากหลาย
• ระบุนโยบายว่าด้วยเวลาในการแก้ไขและการใช้ซอฟต์แวร์ช่วงระยะสุดท้าย (End of Life หรือ EOL)

ตัวอย่างหลักฐาน

Snyk สำหรับแอพ NodeJS - ผู้พัฒนาใช้อินเทอร์เฟซบรรทัดคำสั่ง (CLI) ของ Synk ในการระบุการขึ้นต่อกันแบบแพ็คเกจของบุคคลที่สามซึ่งมีช่องโหว่ด้านการรักษาความปลอดภัยที่ทราบและในการจัดลำดับความสำคัญตามความรุนแรงของช่องโหว่ดังกล่าว

การตรวจสอบ NPM

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

Trivy

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

บริการอัพเดตเซิร์ฟเวอร์ Windows (WSUS)

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

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

เจตนา

หากไม่มีไฟล์บันทึกที่เชื่อถือได้ ผู้พัฒนาจะตรวจจับการเข้าถึงข้อมูลแพลตฟอร์มโดยไม่ได้รับอนุญาตได้ยาก

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

สรุปข้อกำหนด

หากคุณประมวลผลข้อมูลแพลตฟอร์มฝั่งเซิร์ฟเวอร์ ภายในสภาพแวดล้อมนั้น คุณควรปฏิบัติดังนี้

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

คำแนะนำด้านหลักฐาน

หากคุณถูกขอให้อัพโหลดหลักฐาน หลักฐานดังกล่าวควรแสดงให้เห็นสิ่งต่อไปนี้

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

ตรวจสอบการถ่ายโอนข้อมูลแพลตฟอร์มและจุดหลักๆ ที่ข้อมูลแพลตฟอร์มอาจออกไปจากระบบ (เช่น บุคคลที่สาม ตำแหน่งข้อมูลสาธารณะ)

เจตนา

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

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

สรุปข้อกำหนด

หากคุณประมวลผลข้อมูลแพลตฟอร์มฝั่งเซิร์ฟเวอร์ คุณควรดำเนินการดังนี้ภายในสภาพแวดล้อมแบบเซิร์ฟเวอร์ดังกล่าว

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

คำแนะนำด้านหลักฐาน

หากมีการขอให้คุณส่งหลักฐานสำหรับการปกป้องข้อมูล ให้ปฏิบัติตามคำสั่งในส่วนการเตรียมหลักฐาน เพื่อเตรียมหลักฐานเกี่ยวกับนโยบาย/ขั้นตอนและการนำไปปฏิบัติ

คุณจะต้องให้หลักฐานเพื่อยืนยันในเรื่องต่อไปนี้

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

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

เจตนา

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

สรุปข้อกำหนด

หากคุณประมวลผลข้อมูลแพลตฟอร์มฝั่งเซิร์ฟเวอร์ คุณควรดำเนินการดังนี้ภายในสภาพแวดล้อมแบบเซิร์ฟเวอร์ดังกล่าว

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

คำแนะนำด้านหลักฐาน

โดยปกติแล้ว ผู้พัฒนาจะใช้เครื่องมือข้อมูลด้านการรักษาความปลอดภัยและการจัดการกิจกรรม (SIEM) สำหรับวัตถุประสงค์นี้ ตัวอย่างเช่น

• McAfee Enterprise Security Manager
• SolarWinds Security Event Manager
• Splunk Enterprise Security
• Sumo Logic

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

อภิธานศัพท์

A

บุคคลที่สาม - ในศัพท์เฉพาะทางด้านการจัดการความเสี่ยง บุคคลที่สามหมายถึงผู้พัฒนาบนแพลตฟอร์มของ Meta (บุคคลที่หนึ่งคือ Meta, บุคคลที่สองคือผู้คนที่ใช้ผลิตภัณฑ์ของ Meta)

บุคคลที่สี่ - ในศัพท์เฉพาะทางด้านการจัดการความเสี่ยง บุคคลที่สี่หมายถึงบริษัทที่ผู้พัฒนาพึ่งพาในการให้บริการต่อตน ซึ่งเป็นบริการที่ช่วยให้สามารถดำเนินธุรกิจของตนได้ (บุคคลที่หนึ่งคือ Meta, บุคคลที่สองคือผู้ใช้ของ Meta และบุคคลที่สามคือผู้พัฒนาบนแพลตฟอร์มของ Meta) โทเค็นการเข้าถึง - ข้อมูลประจำตัว เช่น รหัสผ่านที่ช่วยให้ซอฟต์แวร์สามารถเรียกใช้ API ในการดำเนินการบางอย่าง (เช่น การอ่านข้อมูลจากโปรไฟล์ของผู้ใช้)

Amazon Web Services (AWS) - ชุดบริการประมวลผลระบบคลาวด์ของ Amazon

ID ในแอพ (ASID) - ตัวระบุแบบไม่ซ้ำกันที่ Meta สร้างขึ้นเมื่อบุคคลเลือกที่จะใช้แอพ โดย ASID จะช่วยเพิ่มความเป็นส่วนตัวให้กับผู้ใช้ด้วยการทำให้ชุดข้อมูลเชื่อมโยงผู้ใช้ในแอพต่างๆ เข้าด้วยกันได้ยากยิ่งขึ้น เนื่องจากผู้ใช้หนึ่งรายที่ใช้แอพสองแอพจะมี ASID ที่ไม่เหมือนกันในแต่ละแอพ

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

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

คอนเทนเนอร์ของแอพพลิเคชั่น - คอนเทนเนอร์จะรวมโค้ดของซอฟต์แวร์และการขึ้นต่อกันที่เกี่ยวข้องไว้เป็นแพ็คเกจ เพื่อให้แอพสามารถทำงานบนเซิร์ฟเวอร์ประเภทต่างๆ ได้ (เช่น เซิร์ฟเวอร์ที่ใช้ระบบปฏิบัติการที่แตกต่างกันอย่างเซิร์ฟเวอร์ Linux หรือ Windows) ผู้พัฒนาจะสร้างอิมเมจของคอนเทนเนอร์ที่รวมแอพของตนไว้เป็นแพ็คเกจ เอนจินหรือรันไทม์ของคอนเทนเนอร์สำหรับแอพพลิเคชั่นจะโฮสต์ (เรียกใช้) อิมเมจของคอนเทนเนอร์

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

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

การพิสูจน์ข้อมูลลับของแอพ - การรักษาความปลอดภัยในอีกระดับสำหรับการเรียกใช้ API ไปยัง Meta โดยที่ผู้พัฒนาจะสร้างพารามิเตอร์ (การพิสูจน์ข้อมูลลับของแอพ) ที่แสดงให้เห็นว่าตนครอบครองข้อมูลลับของแอพ การพิสูจน์ข้อมูลลับของแอพเป็นผลลัพธ์จากฟังก์ชั่นการแฮช (หรือเรียกอีกอย่างว่าฟังก์ชั่นทางเดียว) ที่ใช้ข้อมูลลับของแอพและโทเค็นการเข้าถึง การกำหนดค่าแอพให้ต้องใช้การพิสูจน์ข้อมูลลับของแอพในระหว่างการเรียกใช้ API กราฟจะลดอันตรายที่อาจเกิดขึ้นจากการละเมิดโทเค็นการเข้าถึงของผู้ใช้ เนื่องจากโทเค็นการเข้าถึงเหล่านี้จะไม่สามารถใช้งานได้หากไม่มีพารามิเตอร์การพิสูจน์ข้อมูลลับของแอพเพิ่มเติม

B

การให้บริการแบ็คเอนด์ (BaaS) - รูปแบบการประมวลผลระบบคลาวด์ที่ให้บริการชุดความสามารถฝั่งเซิร์ฟเวอร์แก่ผู้พัฒนาแอพ เพื่อให้ผู้พัฒนาสามารถมุ่งสร้างฟรอนต์เอนด์ได้ (กล่าวคือ ส่วนของแอพที่ผู้ใช้โต้ตอบด้วย) โซลูชั่น BaaS คล้ายคลึงกันกับ PaaS อีกทั้งยังเพิ่มบริการต่างๆ อย่างการยืนยันตัวตนของผู้ใช้และการแจ้งเตือนแบบพุชบนมือถือ ตัวอย่างของผลิตภัณฑ์ BaaS ยอดนิยมบางส่วน ได้แก่ AWS Amplify, Azure Mobile Apps, Firebase และ MongoDB Switch

C

ข้อความรหัส - คำที่มีความหมายพ้องกับ “ข้อมูลที่เข้ารหัส” โดยที่ข้อความรหัสเป็นชื่อสำหรับข้อมูลที่ผ่านการทำให้ไม่สามารถอ่านได้ผ่านอัลกอริธึมการเข้ารหัส ข้อความที่มีลักษณะตรงข้ามกับข้อความรหัสคือข้อความธรรมดา

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

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

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

การควบคุมเพื่อชดเชย - การควบคุมด้านการรักษาความปลอดภัยที่แตกต่างจากชุดข้อกำหนดพื้นฐานบางประการแต่มีวัตถุประสงค์เพื่อให้การป้องกันความเสี่ยงในระดับที่เทียบเท่ากัน

D

ฐานข้อมูล - ซอฟต์แวร์ที่ช่วยให้สามารถจัดเก็บ อ่าน อัพเดต และลบข้อมูลใดๆ ก็ตามได้ ฐานข้อมูลสามารถทำงานบนไคลเอ็นต์และบนเซิร์ฟเวอร์ องค์กรที่ผสานการทำงานกับแพลตฟอร์มของ Meta มักจะจัดเก็บข้อมูลที่ตนดึงจาก API กราฟไว้ในฐานข้อมูลที่ทำงานบนฝั่งเซิร์ฟเวอร์

การถอดรหัส - กระบวนการแปลงข้อมูลที่เข้ารหัสให้กลับสู่รูปแบบต้นฉบับ กล่าวคือ การถอดรหัสจะเปลี่ยนข้อความรหัสเป็นข้อความธรรมดา

E

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

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

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

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

G

Google Cloud Platform (GCP) - ชุดบริการประมวลผลระบบคลาวด์ของ Google API กราฟ - วิธีหลักที่แอพใช้อ่านและเขียนไปยังกราฟสังคมของ Meta โดยที่ SDK และผลิตภัณฑ์ในเครือ Meta ทั้งหมดจะโต้ตอบกับ API ในทางใดทางหนึ่ง

H

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

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

I

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

การจัดการข้อมูลระบุตัวตนและสิทธิ์การเข้าถึง (IAM) - หมายถึงหมวดหมู่ของเครื่องมือและกระบวนการที่ใช้ในการจัดการบัญชีและให้สิทธิ์การเข้าถึงระบบ

การให้บริการโครงสร้างพื้นฐาน (IaaS) - การประมวลผลระบบคลาวด์ที่ช่วยให้ลูกค้าสามารถกำหนดค่าการประมวลผล พื้นที่จัดเก็บข้อมูล และบริการระบบเครือข่าย โดยที่ไม่ต้องรับผิดต่อสินทรัพย์ทางกายภาพด้วยตนเอง (เช่น การจัดการศูนย์ข้อมูลที่เต็มไปด้วยเซิร์ฟเวอร์ อุปกรณ์เครือข่าย และอาร์เรย์จัดเก็บข้อมูล) Iaas ช่วยให้องค์กรสามารถควบคุมการกำหนดค่าสินทรัพย์ระบบคลาวด์ของตนได้มากกว่าเมื่อเทียบกับ Paas แต่การจัดการสินทรัพย์ดังกล่าวจะมีความซับซ้อนมากกว่า ตัวอย่างของผลิตภัณฑ์ IaaS ยอดนิยมบางส่วน ได้แก่ AWS EC2, Microsoft Azure IaaS และ Google Compute Engine

L

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

M

ไคลเอ็นต์สำหรับมือถือหรือแอพมือถือ - แอพที่บุคคลติดตั้งลงบนโทรศัพท์หรือแท็บเล็ตจาก App Store บนมือถือ (เช่น App Store ของ iOS หรือ Google Play Store) การที่ไคลเอ็นต์สำหรับมือถือจะสื่อสารกับ REST API ขององค์กรบนอินเทอร์เน็ตถือเป็นเรื่องปกติ อีกทั้งยังอาจสื่อสารกับฝ่ายอื่นๆ ด้วย (เช่น สื่อสารไปยัง API กราฟ ผ่าน Facebook SDK สำหรับ Android)

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

N

ซอฟต์แวร์เนทีฟ - แอพที่มีการดาวน์โหลดและติดตั้งลงบนแล็ปท็อปหรืออุปกรณ์มือถือนั้นเรียกว่า ซอฟต์แวร์เนทีฟ (เช่น แอพ Facebook สำหรับ iOS) ในทางตรงกันข้าม แอพที่ทำงานในเบราว์เซอร์จะเรียกว่า เว็บแอพ (เช่น การเปิด Facebook โดยใช้เบราว์เซอร์ Chrome)

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

การสแกนเครือข่าย - กระบวนการจัดการความเสี่ยงที่ใช้ซอฟต์แวร์เพื่อดำเนินการต่อไปนี้ ได้แก่ (1) ระบุเซิร์ฟเวอร์ที่กำลังใช้งานบนเครือข่ายที่จะตอบสนองต่อการสื่อสารระยะไกล จากนั้น (2) ตรวจสอบว่าเซิร์ฟเวอร์เหล่านั้นกำลังใช้งานซอฟต์แวร์รุ่นเก่าอันเป็นที่ทราบดีว่ามีความเสี่ยงต่ออันตรายด้านการรักษาความปลอดภัยอย่างน้อยหนึ่งจุดหรือไม่ ตัวอย่างเช่น องค์กรอาจสแกนเครือข่ายเป็นระยะๆ เพื่อให้แน่ใจว่าไม่มีพอร์ตที่เปิดอยู่โดยไม่คาดคิดในขอบเขตเครือข่ายของตน

ตัวจัดการแพ็คเกจโหนด (NPM) - เครื่องมือที่ผู้พัฒนา JavaScript ใช้เพื่อเร่งกระบวนการพัฒนาโดยการอนุญาตให้สามารถรวมแพ็คเกจที่สร้างไว้ล่วงหน้าในแอพหรือระบบของผู้พัฒนา โดย NPM ประกอบไปด้วยฟีเจอร์ในการตรวจสอบชุดแพ็คเกจที่แอพใช้งานและในการระบุแพ็คเกจที่มีช่องโหว่ด้านการรักษาความปลอดภัยที่ทราบ

O

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

ระบบปฏิบัติการ - ซอฟต์แวร์ที่ทำงานบนคอมพิวเตอร์หรืออุปกรณ์มือถือที่ช่วยให้แอพพลิเคชั่นสามารถทำงานและใช้หน่วยประมวลผล หน่วยความจำ พื้นที่จัดเก็บข้อมูล และทรัพยากรเครือข่ายของคอมพิวเตอร์เครื่องดังกล่าวได้ ตัวอย่างเช่น Windows ของ Microsoft, macOS หรือ iOS ของ Apple และ Linux

สมาชิกขององค์กร - บุคคลที่มีบทบาทและความรับผิดชอบภายในองค์กร เช่น พนักงาน ผู้รับเหมา พนักงานชั่วคราว พนักงานฝึกหัด และอาสาสมัคร

อุปกรณ์ขององค์กร - คอมพิวเตอร์หรืออุปกรณ์มือถือที่สมาชิกขององค์กรใช้ในบริบทของการทำงานให้กับองค์กร

P

ข้อกำหนดแพลตฟอร์ม 6.a.i - หมายถึงข้อกำหนดแพลตฟอร์มของ Meta ส่วนที่ (6) หัวข้อ (a) ย่อหน้า (i) ซึ่งอธิบายเกี่ยวกับข้อผูกพันของผู้พัฒนาแพลตฟอร์มที่เกี่ยวข้องกับการรักษาความปลอดภัยของข้อมูล

แพ็คเกจ - คำที่มีความหมายพ้องกับคำว่า “ไลบรารี”

แพตช์ - การอัพเดตซอฟต์แวร์ที่แก้ไขช่องโหว่ด้านการรักษาความปลอดภัย แก้ไขจุดบกพร่อง และเพิ่มฟังก์ชั่นการทำงานใหม่ ซอฟต์แวร์ทุกประเภทล้วนต้องดำเนินการแพตช์ ซึ่งรวมถึงระบบปฏิบัติการ คอนเทนเนอร์ ไลบรารี และ SDK

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

ข้อความธรรมดา - คำที่มีความหมายพ้องกับ “ข้อมูลที่ไม่มีการเข้ารหัส” โดยที่ข้อความธรรมดาเป็นชื่อสำหรับข้อมูลที่ไม่มีการป้องกันด้วยการเข้ารหัส การให้บริการแพลตฟอร์ม (PaaS) - แนวทางการประมวลผลระบบคลาวด์ โดยที่ลูกค้านำแอพพลิเคชั่นไปใช้ในแพลตฟอร์มที่มีการจัดการโดยผู้ให้บริการระบบคลาวด์ ลูกค้าสามารถจัดการ PaaS ได้ง่ายกว่าเมื่อเทียบกับ IaaS เนื่องจากผู้โฮสต์ระบบคลาวด์ไม่เพียงจัดการสินทรัพย์ทางกายภาพ (เช่น เซิร์ฟเวอร์ อุปกรณ์พื้นที่จัดเก็บข้อมูล และอุปกรณ์เครือข่าย) เพียงเท่านั้น แต่ยังจัดการระบบปฏิบัติการและคอนเทนเนอร์ของแอพพลิเคชั่นที่แอพของลูกค้าใช้งานอีกด้วย ตัวอย่างของผลิตภัณฑ์ PaaS ยอดนิยมบางส่วน ได้แก่ AWS Elastic Beanstalk, Google App Engine, Force.com

พอร์ต - เมื่อไคลเอ็นต์เชื่อมต่อไปยังเซิร์ฟเวอร์ผ่านอินเทอร์เน็ต ที่อยู่ปลายทางจะมีสองส่วน ได้แก่ (1) ที่อยู่อินเทอร์เน็ตโปรโตคอล (IP) สำหรับเซิร์ฟเวอร์และ (2) หมายเลขพอร์ตที่อยู่บนเซิร์ฟเวอร์ดังกล่าวที่แอพหนึ่งๆ จะตอบสนอง โปรโตคอลทั่วไปจะใช้พอร์ตที่สงวนไว้ (เช่น HTTPS ใช้ 443) แต่ผู้พัฒนาสามารถใช้พอร์ตที่กำหนดเองสำหรับการสื่อสารของเครือข่ายได้ หากต้องการ

R

REST API - รูปแบบที่มีการใช้งานอย่างแพร่หลายในการสร้างบริการที่สามารถเข้าถึงได้ด้วยเว็บ โดยที่ไคลเอนต์และเซิร์ฟเวอร์จะสื่อสารกันโดยใช้โปรโตคอล HTTP ผู้พัฒนาบนแพลตฟอร์มของ Meta อาจโฮสต์ REST API บนโดเมนย่อย เช่น api.example.com โดยที่แอพมือถือของผู้พัฒนาจะส่งและรับข้อมูลแพลตฟอร์มถึง/จากโดเมนย่อยดังกล่าว

S

Secure Shell (SSH) - ระบบการสื่อสารที่ช่วยให้ผู้ดูแลสามารถเข้าสู่ระบบของเซิร์ฟเวอร์และเรียกใช้โปรแกรมบนเซิร์ฟเวอร์ดังกล่าวจากทางไกลได้ โดยถือว่ามีความปลอดภัยเนื่องจากมีการปกป้องการสื่อสารระหว่างไคลเอ็นต์และเซิร์ฟเวอร์จากการสอดแนม ซึ่งต่างจากโปรโตคอลก่อนหน้าอย่าง Telnet ทั้งนี้มีอีกชื่อว่า Secure Socket Shell

Secure Sockets Layer (SSL) - การเข้ารหัสข้อมูลที่อยู่ระหว่างการถ่ายโอนเวอร์ชั่นล้าสมัยและไม่ปลอดภัย เวอร์ชั่นใหม่ที่ปลอดภัยเรียกว่า การรักษาความปลอดภัยในระดับการขนส่ง (TLS)

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

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

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

การลงชื่อเข้าใช้แบบครั้งเดียว (SSO) - การจัดการที่แอพใช้ไดเรกทอรีผู้ใช้ส่วนกลาง (กล่าวคือ IdP) ในการยืนยันตัวตนผู้ใช้ นอกเหนือจากการรวมศูนย์บัญชีผู้ใช้และการบริหารจัดการสิทธิ์การเข้าถึงแอพสำหรับองค์กรแล้ว ผู้ใช้ยังได้รับประโยชน์โดยการมีข้อมูลประจำตัวเพียงชุดเดียว แทนที่จะกำหนดให้ผู้ใช้ต้องเก็บรักษาข้อมูลประจำตัวหลายๆ ชุดที่แตกต่างกันไป (เช่น ชื่อผู้ใช้และรหัสผ่าน) สำหรับแต่ละแอพ

ชุดพัฒนาซอฟต์แวร์ (SDK) - องค์ประกอบพื้นฐานของโค้ดที่ผู้พัฒนาสามารถใช้เพื่อลดความซับซ้อนของกระบวนการพัฒนาได้ตามที่ต้องการ ตัวอย่างเช่น Meta สร้างและบำรุงรักษา SDK ที่ช่วยลดความซับซ้อนของการทำงานกับ API กราฟสำหรับผู้พัฒนา iOS และ Android ซึ่งคล้ายกับไลบรารีในแง่ที่ผู้พัฒนาที่ใช้ SDK ในแอพของตนจำเป็นต้องอัพเดต SDK ให้เป็นเวอร์ชั่นล่าสุดอยู่เสมอเมื่อเวลาผ่านไป

การให้บริการซอฟต์แวร์ (SaaS) - ช่วยให้ลูกค้าสามารถใช้แอพระบบคลาวด์ผ่านทางอินเทอร์เน็ตได้ โดยต่างจาก PaaS หรือ IaaS ในแง่ที่ลูกค้าของแอพ SaaS ไม่ได้นำโค้ดที่กำหนดเองไปใช้หรือมีความรับผิดชอบในการกำหนดค่า อัพเกรด หรือแพตช์แอพ SaaS เนื่องจากการดำเนินการเหล่านี้ทั้งหมดเป็นความรับผิดชอบของผู้ให้บริการซอฟต์แวร์ SaaS ตัวอย่างของผลิตภัณฑ์ SaaS ยอดนิยมบางส่วน ได้แก่ Dopbox, MailChip, Salesforce, Slack

การวิเคราะห์เชิงสถิต - โปรดดู “การทดสอบการรักษาความปลอดภัยของแอพพลิเคชั่นเชิงสถิต”

การทดสอบการรักษาความปลอดภัยของแอพพลิเคชั่นเชิงสถิต (SAST) - แนวทางในการค้นหาช่องโหว่ในซอฟต์แวร์โดยการใช้เครื่องมือเฉพาะทางกับซอร์สโค้ด เครื่องมือ SAST จะระบุช่องโหว่ที่เป็นไปได้ เช่น ช่องโหว่ต่างๆ ที่ระบุอยู่ในรายการของโปรเจ็กต์ OWASP Top 10 จากนั้นผู้พัฒนาจะมีหน้าที่รับผิดชอบในการตรวจสอบผลลัพธ์ที่ค้นพบ แยกผลลัพธ์ที่เป็นช่องโหว่จริงออกจากผลลัพธ์ที่ไม่ใช่ช่องโหว่ และดำเนินการแก้ไขช่องโหว่ในซอฟต์แวร์ โดย SAST เป็นเครื่องมือที่มีประโยชน์เนื่องจากสามารถช่วยให้ผู้พัฒนาค้นหาช่องโหว่ได้ก่อนการนำไปใช้จริง แต่จะมีความแตกต่างจากการทดสอบเจาะระบบเพราะเครื่องมือ SAST จะไม่สามารถค้นหาช่องโหว่ที่เกี่ยวข้องกับการกำหนดค่าการผลิตของแอพได้

T

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

การรักษาความปลอดภัยในระดับการขนส่ง (TLS) - ระบบการเข้ารหัสข้อมูลที่อยู่ระหว่างการโอนย้าย ซึ่งใช้การเข้ารหัสเพื่อปกป้องข้อมูลที่ส่งผ่านเครือข่ายจากการสอดแนมตามเส้นทางของเครือข่าย โดย TLS เป็นเวอร์ชั่นใหม่ที่ปลอดภัยของเทคโนโลยีก่อนหน้าซึ่งล้าสมัยไปแล้วที่เรียกว่า SSL

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

V

แมชชีนเสมือน (VM) - คล้ายคลึงกับคอนเทนเนอร์ของแอพพลิเคชั่นอย่างยิ่ง โดย VM จะทำงานในโฮสต์ที่เรียกว่า “ไฮเปอร์ไวเซอร์” ในขณะที่คอนเทนเนอร์ของแอพพลิเคชั่นจะทำงานอยู่ในเอนจินของคอนเทนเนอร์ ข้อแตกต่างหลักๆ คือ อิมเมจของ VM ประกอบไปด้วยระบบปฏิบัติการ ในขณะที่คอนเทนเนอร์ของแอพพลิเคชั่นไม่มี ทั้ง VM และคอนเทนเนอร์ของแอพพลิเคชั่นจะมีแอพพลิเคชั่นและการขึ้นต่อกัน เช่น ไลบรารี

Virtual Private Cloud (VPC) - คำศัพท์ที่ AWS ใช้เพื่อกล่าวถึงชุดทรัพยากรระบบคลาวด์ที่มีความคล้ายคลึงกับเครือข่ายแบบดั้งเดิมในศูนย์ข้อมูลในยุคก่อนที่จะมีระบบคลาวด์

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

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

การสแกนช่องโหว่ - แนวทางที่ใช้ซอฟต์แวร์เพื่อค้นหาช่องโหว่ในเซิร์ฟเวอร์ เครือข่าย และแอพ เมื่อเทียบกับการทดสอบเจาะระบบ การสแกนช่องโหว่จะมีค่าใช้จ่ายที่ถูกกว่าในการดำเนินงาน ดังนั้นจึงสามารถดำเนินการซ้ำๆ ได้ (เช่น รายเดือน หรือรายไตรมาส) แต่ก็ย่อมเป็นเรื่องปกติที่การทดสอบเจาะระบบจะตรวจพบช่องโหว่ที่การสแกนช่องโหว่ตรวจไม่พบ เนื่องจากผู้ทดสอบเจาะระบบจะมีทักษะในการวิเคราะห์และสัญชาตญาณที่แนวทางซึ่งใช้เพียงระบบอัตโนมัติเลียนแบบได้ยาก โปรดดู “การสแกนเครือข่าย”

W

เว็บแอพ - เว็บแอพเป็นโปรแกรมที่ทำงานในเบราว์เซอร์และประกอบไปด้วยทรัพยากรต่างๆ เช่น เอกสาร HTML, โค้ด JavaScript, วิดีโอและสื่ออื่นๆ รวมถึง CSS สำหรับการออกแบบ เมื่อเทียบกับแอพมือถือที่บุคคลติดตั้งลงบนโทรศัพท์มือถือจาก App Store ผู้คนเพียงเรียกใช้เว็บแอพจากเซิร์ฟเวอร์ทางไกลโดยใช้เบราว์เซอร์ของตน (เช่น www.facebook.com) โดยที่ไม่จำเป็นต้องมีการติดตั้ง