เจาะลึกความปลอดภัยของ Salesforce: อธิบายการยืนยันตัวตนและการอนุญาต
ยินดีต้อนรับสู่จุดเริ่มต้นของการสำรวจความปลอดภัยของ Salesforce อย่างครอบคลุม โดยเริ่มจากองค์ประกอบพื้นฐานของการยืนยันตัวตนและการอนุญาต บทความนี้เป็นบทความแรกในซีรีส์ที่มุ่งคลี่คลายเครือข่ายของกลไกความปลอดภัยของ Salesforce
พื้นฐาน: การยืนยันตัวตนและการอนุญาต
การยืนยันตัวตน (authentication) คือกระบวนการตรวจสอบว่าเอนทิตีหนึ่ง ไม่ว่าจะเป็นผู้ใช้ในเบราว์เซอร์หรือเครื่องที่เข้าถึงระบบ เป็นสิ่งที่มันอ้างว่าเป็นจริง ส่วนการอนุญาต (authorization) กำหนดว่าเอนทิตีที่ยืนยันตัวตนแล้วทำอะไรได้บ้างภายใน Salesforce ทั้งสองอย่างสำคัญยิ่งต่อการทำให้ข้อมูล Salesforce ของคุณปลอดภัย และมีเพียงผู้ใช้และเอนทิตีที่ได้รับอนุญาตเท่านั้นที่เข้าถึงได้
จากเบราว์เซอร์ถึง API: ทำความเข้าใจจุดเข้า
สำหรับทราฟฟิกขาเข้าทั้งหมด Salesforce ทำให้แน่ใจว่าทราฟฟิกขาเข้าทั้งหมดใช้ SSL และ TLS เพื่อการส่งข้อมูลอย่างปลอดภัย (เราจะพูดถึงคำเหล่านี้อย่างละเอียดในบทความถัดไป)
เมื่อนึกภาพว่าข้อมูลเข้าสู่ Salesforce อย่างไร ให้นึกถึงเส้นทางหลักสองเส้น:
- โดยตรงผ่านเบราว์เซอร์โดยผู้ใช้
- ผ่านแอปพลิเคชันไคลเอนต์ API เช่น แอปมือถือหรือเซิร์ฟเวอร์อื่น
ทั้งสองเส้นทางเริ่มการเดินทางด้วยการสื่อสารกับ Salesforce Authentication Server
[caption id="" align=“alignnone” width=“1800”]
ไดอะแกรมแสดงวิธีต่างๆ ที่ระบบภายนอกเข้าถึง Salesforce Core ได้ [/caption]
มาแยกย่อยกันต่อ:
การเข้าถึงผ่านเบราว์เซอร์
สำหรับคนที่ใช้ Salesforce ผ่านเบราว์เซอร์:
[caption id="" align=“alignnone” width=“1840”]
โฟลว์การยืนยันตัวตนผ่านเบราว์เซอร์เข้าสู่ Salesforce [/caption]
- ชั้นความปลอดภัยเพิ่มเติมของการยืนยันตัวตน: การยืนยันตัวตนแบบหลายปัจจัย (MFA) ช่วง IP และใบรับรองฝั่งไคลเอนต์
- ผู้ให้บริการตัวตน: Salesforce ทำหน้าที่เป็นผู้ให้บริการตัวตน (IDP) เพื่อยืนยันความถูกต้องของผู้ใช้ได้ เมื่อยืนยันตัวตนแล้ว เซิร์ฟเวอร์ของ Salesforce จะให้ session token แก่อินสแตนซ์ ORG ของไคลเอนต์นั้น
- IDP บุคคลที่สาม: แทนที่จะเป็น Salesforce IDP บุคคลที่สามที่ตั้งค่าความสัมพันธ์ SSO กับ Salesforce จัดการการยืนยันตัวตนได้ ในกรณีนี้ IDP ส่ง SAML assertion ไปยัง Salesforce ซึ่งจะออก session token เมื่อตรวจสอบแล้ว
หลังจากนั้น กลไกการอนุญาตจะควบคุมการเข้าถึงหน้าเพจและทรัพยากร
การเข้าถึงผ่านไคลเอนต์ API
สำหรับเครื่องที่พยายามเข้าถึง Salesforce:
[caption id="" align=“alignnone” width=“1820”]
กระบวนการของไคลเอนต์ที่ยืนยันตัวตนเข้าสู่ Salesforce API [/caption]
OAuth flow: เครื่องใช้ OAuth flow แบบใดแบบหนึ่งจากหลายแบบเพื่อเข้าถึงได้ ตั้งแต่ web server flow ที่เหมาะกับเว็บเซิร์ฟเวอร์ภายนอก ไปจนถึง client credentials flow และอีกหลายแบบในระหว่างนั้น แต่ละแบบมีลำดับขั้นและจุดประสงค์ของตัวเอง
การสร้างเซสชัน: หลังการยืนยันตัวตน เซิร์ฟเวอร์ยืนยันตัวตนของ Salesforce จะมอบ session token ให้ ทำให้ไคลเอนต์ API เข้าถึงทรัพยากรของ Salesforce ได้
แล้วกฎการอนุญาตก็เข้ามามีบทบาท
สรุป: ทั้งหมดเข้ากันอย่างไร
ไม่ว่าจุดเข้าจะเป็นเบราว์เซอร์หรือไคลเอนต์ API กระบวนการประกอบด้วย:
ความปลอดภัยระดับการส่งข้อมูล: ใช้ TLS และอาจเพิ่มชั้นอย่าง IP whitelisting และใบรับรองฝั่งไคลเอนต์เพื่อความปลอดภัยที่สูงขึ้น
การยืนยันตัวตน: ขั้นนี้ระบุผู้ใช้หรือระบบ เป็นที่ที่องค์ประกอบอย่าง MFA หรือ IDP บุคคลที่สามเข้ามา
การออก session token: เมื่อยืนยันตัวตนแล้ว เอนทิตีจะได้รับ session token ซึ่งทำหน้าที่เหมือนหนังสือเดินทางสู่ทรัพยากรของ Salesforce
การอนุญาต: ด่านสุดท้าย แม้จะมี session token ที่ถูกต้อง ขั้นนี้ก็ตัดสินว่าเอนทิตีเข้าถึงทรัพยากรใดได้
ด้วยความรู้พื้นฐานนี้ เราพร้อมจะลงลึกในรายละเอียดของความปลอดภัย Salesforce ในบทความถัดๆ ไป ติดตามการตรวจสอบแต่ละองค์ประกอบข้างต้นอย่างละเอียดยิ่งขึ้น
ขอบคุณที่อ่าน และหวังว่าคุณจะได้ความรู้จากบทความนี้ ติดตามตอนต่อไปของเราเพื่อมุมมองเพิ่มเติมเรื่องความปลอดภัยของ Salesforce
ติดตามต่อ
เริ่มต้นเส้นทาง Salesforce Identity ของคุณอย่างมั่นใจ! สำหรับมุมมองและเคล็ดลับเพิ่มเติม ติดตามได้ที่ www.SteveTechArc.com และช่อง YouTube @SteveTechArc (opens in a new tab) กดติดตามและเพิ่มความเข้าใจเรื่อง Salesforce Identity ของคุณ
ช่วยเปลี่ยนโลกด้วยการแบ่งปันความรู้ด้านการผสานรวมกับเพื่อนสถาปนิกและผู้ที่อยู่บนเส้นทางสู่การเป็นสถาปนิก!
บทถอดความได้รับความช่วยเหลือจาก AI
STA 3.1