รูปแบบการให้สิทธิ์: RBAC, MAC และ DAC
เปรียบเทียบรูปแบบการควบคุมการเข้าถึงตามบทบาท แบบบังคับ และแบบใช้ดุลยพินิจ พร้อมเรียนรู้ว่าแต่ละรูปแบบเหมาะสมเมื่อใดในบริบทขององค์กรธุรกิจและหน่วยงานรัฐ
รูปแบบการให้สิทธิ์: RBAC, MAC และ DAC เป็นบทเรียน Security+ Academy ฟรีบน CoddyKit นี่คือบทเรียนที่ 3 จากทั้งหมด 4 บทเรียน คุณสามารถอ่านบทเรียนทั้งหมดด้านล่างฟรี — จากนั้นลองปฏิบัติด้วยตัวคุณเองในเบราว์เซอร์พร้อมตัวแก้ไขโค้ดในตัวและติวเตอร์ AI ตลอด 24/7 บทเรียนนี้เป็นส่วนหนึ่งของเส้นทางการเรียน Security+ Academy และความก้าวหน้าของคุณจะซิงค์ข้ามเว็บและแอป CoddyKit คอร์ส Security+ Academy มีบทเรียนทั้งหมด 4 บทเรียน
ภาพรวมแบบจำลองการควบคุมการเข้าถึง
แบบจำลองการควบคุมการเข้าถึงกำหนดกฎและนโยบายที่ควบคุมว่าสิ่งใด (ผู้ใช้ กระบวนการ) สามารถเข้าถึงวัตถุใด (ไฟล์ ระบบ ข้อมูล) ได้ แบบจำลองที่เลือกจะกำหนดว่าใครสามารถมอบสิทธิ์การเข้าถึง วิธีการกำหนดสิทธิ์ และวิธีบังคับใช้นโยบาย การสอบ Security+ ครอบคลุมแบบจำลองหลักสี่แบบ ได้แก่ การควบคุมการเข้าถึงตามดุลยพินิจ (DAC) การควบคุมการเข้าถึงแบบบังคับ (MAC) การควบคุมการเข้าถึงตามบทบาท (RBAC) และ การควบคุมการเข้าถึงตามกฎ การเข้าใจจุดแข็งและกรณีการใช้งานที่เหมาะสมของแต่ละแบบจำลองเป็นสิ่งสำคัญต่อการออกแบบระบบการให้สิทธิ์ที่มีประสิทธิภาพ
การควบคุมการเข้าถึงตามดุลยพินิจ (DAC)
ใน การควบคุมการเข้าถึงตามดุลยพินิจ (DAC) เจ้าของทรัพยากรมีดุลยพินิจว่าจะให้ใครเข้าถึงทรัพยากรของตน และสามารถมอบหรือเพิกถอนการเข้าถึงของผู้ใช้อื่นได้ ส่วนที่เรียกว่า 'ตามดุลยพินิจ' หมายถึงเจ้าของเป็นผู้ตัดสินใจ ระบบมีหน้าที่บังคับใช้การตัดสินใจนั้น แต่ไม่ได้เป็นผู้กำหนดเอง แบบจำลองนี้ใช้ในสภาพแวดล้อมคอมพิวเตอร์ส่วนบุคคลส่วนใหญ่ (สิทธิ์ของไฟล์ Windows NTFS และสิทธิ์ของไฟล์ Linux/Unix) ข้อจำกัดด้านความปลอดภัยของ DAC คือ ต้องอาศัยเจ้าของทรัพยากรทุกคนตัดสินใจเรื่องการเข้าถึงอย่างถูกต้อง ผู้ใช้ที่ได้รับสิทธิ์เข้าถึงไฟล์สามารถมอบสิทธิ์นั้นให้ผู้อื่นได้โดยไม่ต้องผ่านผู้ดูแลระบบ ซึ่งอาจทำให้ข้อมูลอ่อนไหวแพร่ไปไกลกว่ากลุ่มเป้าหมายที่ตั้งใจไว้
# DAC example: Linux file permissions (owner controls access)
# Create a file and check default permissions
touch confidential_data.txt
ls -la confidential_data.txt
# -rw-rw-r-- 1 alice users (owner=alice, can read/write; group can read/write; others read)
# Owner (Alice) discretionarily removes all access for others
chmod 600 confidential_data.txt
# -rw------- 1 alice users (only Alice can read/write)
# Alice grants read to a specific user via ACL
setfacl -m u:bob:r confidential_data.txtความเสี่ยงของ DAC: ปัญหาผู้ช่วยที่สับสน
DAC มีความเสี่ยงด้านความปลอดภัยโดยธรรมชาติสองประการ การเข้าถึงแบบส่งต่อ: ผู้ใช้ A มอบสิทธิ์ให้ผู้ใช้ B และผู้ใช้ B มอบสิทธิ์ให้ผู้ใช้ C ทำให้เจ้าของเดิมอาจไม่รู้ด้วยซ้ำว่า C เข้าถึงทรัพยากรของตนได้ ปัญหาผู้ช่วยที่สับสน: โปรแกรมที่มีสิทธิ์สูงซึ่งทำงานแทนผู้ใช้ที่มีสิทธิ์ต่ำกว่า อาจใช้สิทธิ์ของตนโดยไม่ตั้งใจในลักษณะที่ผู้ใช้ไม่สามารถทำได้โดยตรง ในสภาพแวดล้อม DAC บัญชีที่ถูกบุกรุกเพียงบัญชีเดียวอาจเข้าถึงทรัพยากรทั้งหมดที่ผู้ใช้บัญชีนั้นได้รับสิทธิ์ และอาจมอบสิทธิ์ให้ผู้อื่นก่อนตรวจพบการบุกรุก DAC สะดวกต่อการใช้งาน แต่สร้างความท้าทายต่อการจำกัดข้อมูลอย่างเข้มงวด
การควบคุมการเข้าถึงแบบบังคับ (MAC)
ใน การควบคุมการเข้าถึงแบบบังคับ (MAC) ระบบปฏิบัติการจะบังคับใช้นโยบายการเข้าถึงตาม ป้ายกำกับความปลอดภัยที่กำหนดให้ทั้งสิ่ง (ผู้ใช้) และวัตถุ (ข้อมูล) ผู้ใช้ไม่สามารถละเว้นหรือเปลี่ยนนโยบายเหล่านี้ได้ มีเพียงผู้ดูแลระบบหรือผู้กำหนดนโยบายความปลอดภัยเท่านั้นที่แก้ไขได้ MAC ใช้ในสภาพแวดล้อมรัฐบาลและทหารที่มีข้อมูลลับ ซึ่งต้องแบ่งข้อมูลออกจากกันอย่างเข้มงวด ผู้ใช้ที่มีระดับการอนุญาต 'ลับ' ไม่สามารถเข้าถึงข้อมูลที่ติดป้ายกำกับว่า 'ลับที่สุด' ได้ แม้เจ้าของข้อมูลต้องการมอบสิทธิ์ให้ก็ตาม แบบจำลอง Bell-LaPadula (ห้ามอ่านข้อมูลระดับสูงกว่า ห้ามเขียนข้อมูลระดับต่ำกว่า) และแบบจำลอง Biba (ห้ามเขียนข้อมูลระดับสูงกว่า ห้ามอ่านข้อมูลระดับต่ำกว่า) เป็นการนำ MAC ไปใช้ในรูปแบบที่เป็นทางการ
# SELinux is a MAC implementation for Linux
# Check SELinux mode and policy
getenforce # Enforcing / Permissive / Disabled
sestatus # Detailed SELinux status
# View SELinux security context labels on files
ls -Z /etc/passwd
# system_u:object_r:passwd_file_t:s0 /etc/passwd
# Security context: user:role:type:level
# A process can only access files where its type has explicit permission
sudo ausearch -m avc -ts recent # View MAC policy denialsแบบจำลอง MAC ของ Bell-LaPadula และ Biba
แบบจำลอง MAC อย่างเป็นทางการสองแบบเข้ารหัสวัตถุประสงค์ด้านความปลอดภัยให้อยู่ในรูปกฎทางคณิตศาสตร์ Bell-LaPadula มุ่งเน้นที่ การรักษาความลับ: สิ่งไม่สามารถอ่านข้อมูลที่อยู่เหนือระดับการจัดชั้นของตนได้ (ห้ามอ่านข้อมูลระดับสูงกว่า) และไม่สามารถเขียนข้อมูลไปยังระดับการจัดชั้นที่ต่ำกว่าได้ (ห้ามเขียนข้อมูลระดับต่ำกว่า) วิธีนี้ป้องกันไม่ให้ข้อมูลอ่อนไหวไหลไปยังผู้ใช้ที่ไม่ได้รับอนุญาต Biba มุ่งเน้นที่ ความถูกต้องครบถ้วน: สิ่งไม่สามารถเขียนไปยังระดับความถูกต้องครบถ้วนที่สูงกว่าได้ (ห้ามเขียนข้อมูลระดับสูงกว่า) และไม่สามารถอ่านจากระดับที่ต่ำกว่าได้ (ห้ามอ่านข้อมูลระดับต่ำกว่า) Biba ป้องกันไม่ให้ข้อมูลที่มีความถูกต้องครบถ้วนสูงถูกปนเปื้อนด้วยข้อมูลนำเข้าที่มีความถูกต้องครบถ้วนต่ำ ระบบ MAC จริง (เช่น SELinux) ผสานองค์ประกอบของทั้งสองแบบจำลองเข้าด้วยกัน
การควบคุมการเข้าถึงตามบทบาท (RBAC)
การควบคุมการเข้าถึงตามบทบาท (RBAC)กำหนดสิทธิ์ให้กับ บทบาท แทนการกำหนดโดยตรงให้ผู้ใช้แต่ละราย จากนั้นจึงกำหนดผู้ใช้ให้กับบทบาท วิธีนี้ช่วยแก้ปัญหาการกำหนดสิทธิ์รายบุคคลในระบบขนาดใหญ่ บทบาททั่วไปในสภาพแวดล้อมองค์กร ได้แก่ ผู้ดูแลระบบ ผู้ตรวจสอบ นักพัฒนา ผู้จัดการฝ่ายบุคคล และ นักวิเคราะห์การเงิน เมื่อพนักงานใหม่เข้าร่วมองค์กร พนักงานจะถูกเพิ่มเข้าไปในบทบาทที่เหมาะสมและได้รับสิทธิ์ทั้งหมดที่บทบาทนั้นต้องใช้ทันที เมื่อพนักงานเปลี่ยนตำแหน่ง บทบาทจะเปลี่ยนและสิทธิ์จะปรับโดยอัตโนมัติ RBAC เป็นแบบจำลองหลักในระบบ IAM ขององค์กร
# RBAC example (database permissions)
# Create roles and assign permissions
CREATE ROLE readonly_analyst;
GRANT SELECT ON ALL TABLES IN SCHEMA public TO readonly_analyst;
CREATE ROLE data_engineer;
GRANT SELECT, INSERT, UPDATE ON customer_data TO data_engineer;
# Assign users to roles
GRANT readonly_analyst TO alice;
GRANT data_engineer TO bob;
# When Alice is promoted: revoke old role, grant new one
REVOKE readonly_analyst FROM alice;
GRANT data_engineer TO alice;ประโยชน์ของ RBAC: ความสามารถในการขยายระบบและการแบ่งแยกหน้าที่
ข้อได้เปรียบหลักของ RBAC คือ ความสามารถในการขยายการดูแลระบบ การแก้ไขสิทธิ์ของบทบาทจะส่งผลต่อผู้ใช้ทุกคนในบทบาทนั้นทันที ไม่จำเป็นต้องอัปเดตระเบียนผู้ใช้แต่ละรายในระบบหลายร้อยระบบ RBAC ยังรองรับ การแบ่งแยกหน้าที่ได้โดยธรรมชาติ ด้วยการทำให้แน่ใจว่าไม่มีบทบาทใดมีสิทธิ์ที่ขัดแย้งกัน (เช่น บทบาทที่สามารถทั้งสร้างและอนุมัติธุรกรรมทางการเงิน) RBAC ยังช่วยให้การปฏิบัติตามข้อกำหนดง่ายขึ้น เพราะผู้ตรวจสอบสามารถตรวจสอบบทบาทและสิทธิ์ของบทบาท แทนการตรวจสอบการกำหนดสิทธิ์ของผู้ใช้หลายพันราย ข้อจำกัดคือการเพิ่มจำนวนบทบาทมากเกินไป องค์กรอาจสร้างบทบาทที่ละเอียดเฉพาะทางมากเกินไปจนเกิดความซับซ้อนในการจัดการ และบั่นทอนประโยชน์ด้านความสามารถในการขยายระบบ
การควบคุมการเข้าถึงตามกฎ
การควบคุมการเข้าถึงตามกฎ (อย่าสับสนกับ RBAC) จะอนุญาตหรือปฏิเสธการเข้าถึงตามชุดของ กฎแบบมีเงื่อนไข แทนที่จะพิจารณาจากข้อมูลระบุตัวตนหรือบทบาทเพียงอย่างเดียว กฎไฟร์วอลล์เป็นตัวอย่างคลาสสิก: 'อนุญาต TCP จาก 192.168.1.0/24 ไปยังปลายทางใดก็ได้ที่พอร์ต 443 ปฏิเสธการรับส่งข้อมูลอื่นทั้งหมด' ระบบจะประเมินการเข้าถึงตามกฎเรียงลำดับไปจนกว่าจะพบรายการที่ตรงกัน โดยทั่วไปการควบคุมตามกฎจะใช้ร่วมกับแบบจำลองอื่น MAC ใช้ป้ายกำกับความปลอดภัยเป็นกฎ และ การควบคุมการเข้าถึงตามแอตทริบิวต์ (ABAC)จะขยายตรรกะแบบใช้กฎให้ประเมินแอตทริบิวต์หลายรายการพร้อมกัน (แผนกของผู้ใช้ ประเภทอุปกรณ์ ช่วงเวลาของวัน การจัดชั้นทรัพยากร) เพื่อการตัดสินใจที่ละเอียดแม่นยำ
# Rule-based access control: iptables firewall rules
# Rules are evaluated in order; first match wins
# Allow established/related connections
iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
# Allow specific source IP to SSH
iptables -A INPUT -s 10.0.0.100 -p tcp --dport 22 -j ACCEPT
# Allow HTTPS from anywhere
iptables -A INPUT -p tcp --dport 443 -j ACCEPT
# Default deny all other inbound
iptables -A INPUT -j DROPการควบคุมการเข้าถึงตามแอตทริบิวต์ (ABAC)
ABAC (การควบคุมการเข้าถึงตามแอตทริบิวต์) เป็นแบบจำลองการควบคุมการเข้าถึงที่ยืดหยุ่นและละเอียดแม่นยำที่สุด การตัดสินใจเรื่องการเข้าถึงจะประเมินแอตทริบิวต์หลายรายการพร้อมกัน ได้แก่ แอตทริบิวต์ของสิ่ง (แผนกของผู้ใช้ ระดับการอนุญาต ตำแหน่งที่ตั้ง) แอตทริบิวต์ของวัตถุ (การจัดชั้นข้อมูล แผนกของเจ้าของ ป้ายกำกับระยะเวลาเก็บรักษา) แอตทริบิวต์ของสภาพแวดล้อม (ช่วงเวลาของวัน ประเภทอุปกรณ์ ตำแหน่งที่ตั้งเครือข่าย) และ แอตทริบิวต์ของการกระทำ (อ่าน เขียน ลบ) นโยบายอาจระบุว่า 'อนุญาตการเข้าถึงหาก user.department = Finance AND resource.classification = Internal AND device.type = corporate AND time.hour BETWEEN 8 AND 18' ABAC ช่วยให้ตัดสินใจตามนโยบายแบบไม่ไว้วางใจสิ่งใดโดยอัตโนมัติ และนำไปใช้ในผลิตภัณฑ์อย่าง XACML รวมถึงกลไกนโยบาย IAM บนคลาวด์
การเลือกแบบจำลองที่เหมาะสม
แบบจำลองการควบคุมการเข้าถึงที่เหมาะสมขึ้นอยู่กับข้อกำหนดด้านความปลอดภัยและบริบทขององค์กร DAC: เหมาะกับการประมวลผลส่วนบุคคลและทีมขนาดเล็กที่ให้ความสำคัญกับความสะดวกมากกว่าการควบคุมที่เข้มงวด MAC: จำเป็นสำหรับสภาพแวดล้อมรัฐบาลหรือทหารที่มีข้อมูลลับและต้องแบ่งข้อมูลออกจากกันอย่างเข้มงวด RBAC: เหมาะอย่างยิ่งสำหรับองค์กรที่ต้องการความสามารถในการขยายการดูแลระบบ และบทบาทสอดคล้องกับหน้าที่งานอย่างชัดเจน ABAC: เหมาะกับสภาพแวดล้อมคลาวด์และสถาปัตยกรรมแบบไม่ไว้วางใจสิ่งใดโดยอัตโนมัติ ซึ่งต้องใช้นโยบายที่รับรู้บริบทและละเอียดแม่นยำ ในทางปฏิบัติ องค์กรส่วนใหญ่ใช้หลายแบบร่วมกัน โดยมี RBAC เป็นพื้นฐานและใช้ ABAC สำหรับการตัดสินใจเรื่องการเข้าถึงที่ขึ้นอยู่กับบริบท
รายการควบคุมการเข้าถึง (ACL)
ไม่ว่าจะใช้แบบจำลองการควบคุมการเข้าถึงแบบใด รายการควบคุมการเข้าถึง (ACL) ก็เป็นกลไกการนำไปใช้งานทางเทคนิคที่พบได้บ่อยที่สุด ACL ที่เชื่อมโยงกับทรัพยากรจะระบุว่า Subject ใดสามารถดำเนินการใดได้บ้าง ACL ของระบบไฟล์ (Windows NTFS, Linux POSIX ACL) ควบคุมการเข้าถึงไฟล์และไดเรกทอรี ACL ของ Network ควบคุมการไหลของการรับส่งข้อมูลที่ระดับเราเตอร์หรือ Network บนคลาวด์ ACL ของฐานข้อมูล ควบคุมการเข้าถึงในระดับตารางและแถว ACL สามารถนำแบบจำลองใด ๆ ที่กล่าวถึงไปใช้งานได้ เช่น ACL ของไฟล์จะใช้ DAC เมื่อเจ้าของเป็นผู้ควบคุม ACL นั้น ACL ของระบบรักษาความปลอดภัยจะใช้ MAC เมื่อป้ายกำกับเป็นตัวกำหนดรายการ และ ACL ของ Application จะใช้ RBAC เมื่อรายการอ้างอิงถึงบทบาท
# Windows NTFS ACL example using icacls
# View current ACL on a folder
icacls 'C:\Sensitive\HR_Data'
# BUILTIN\Administrators:(OI)(CI)(F) <- Full control
# CONTOSO\HR_Team:(OI)(CI)(RX) <- Read and Execute
# Grant specific permissions to HR Managers group
icacls 'C:\Sensitive\HR_Data' /grant 'CONTOSO\HR_Managers:(OI)(CI)(M)'
# (OI)=Object Inherit, (CI)=Container Inherit, (M)=Modify
# Remove access for a former contractor
icacls 'C:\Sensitive\HR_Data' /remove 'CONTOSO\contractors'ตรวจสอบความเข้าใจอย่างรวดเร็ว
ทดสอบความเข้าใจแนวคิด CompTIA Security+ (SY0-701) จากบทเรียนนี้
สรุปบทเรียน
ในบทเรียนนี้ คุณได้เรียนรู้ว่า DAC ให้เจ้าของทรัพยากรควบคุมการเข้าถึงได้ (ยืดหยุ่นแต่มีความเสี่ยง) MAC ใช้ป้ายกำกับความปลอดภัยที่ระบบเป็นผู้บังคับใช้ (เข้มงวดและใช้ในสภาพแวดล้อมที่มีการจัดชั้นความลับ) RBAC กำหนดสิทธิ์ให้กับบทบาทเพื่อรองรับการขยายตัวขององค์กร และ ABAC ประเมิน Attribute หลายรายการเพื่อใช้ตัดสินใจแบบ zero-trust ที่ละเอียดในระดับสูง บทถัดไปเราจะศึกษาเรื่อง Federated Identity: SAML, OAuth และ OpenID Connect
คำถามที่พบบ่อย
บทเรียน “รูปแบบการให้สิทธิ์: RBAC, MAC และ DAC” ฟรีหรือไม่
ใช่ — ข้อความเต็มของ “รูปแบบการให้สิทธิ์: RBAC, MAC และ DAC” ฟรีให้อ่านที่นี่บนเว็บ เพื่อปฏิบัติแบบโต้ตอบ (ตัวแก้ไขโค้ดในตัวและติวเตอร์ AI ตลอด 24/7) และปลดล็อคส่วนที่เหลือของคอร์ส Security+ Academy ให้อัปเกรดเป็น CoddyKit PRO คอร์ส Security+ Academy มีบทเรียนทั้งหมด 4 บทเรียน
คุณจะเรียนรู้อะไรในบทเรียน “รูปแบบการให้สิทธิ์: RBAC, MAC และ DAC”
เปรียบเทียบรูปแบบการควบคุมการเข้าถึงตามบทบาท แบบบังคับ และแบบใช้ดุลยพินิจ พร้อมเรียนรู้ว่าแต่ละรูปแบบเหมาะสมเมื่อใดในบริบทขององค์กรธุรกิจและหน่วยงานรัฐ คุณปฏิบัติ Security+ Academy ด้วยโค้ดที่ใช้งานได้จริงที่คุณเรียกใช้โดยตรงในเบราว์เซอร์ และติวเตอร์ AI ตลอด 24/7 ตอบคำถามของคุณขณะที่คุณไปผ่านบทเรียน
คุณต้องมีประสบการณ์ก่อนที่จะเริ่มเรียน Security+ Academy หรือไม่
ไม่จำเป็นต้องมีประสบการณ์มาก่อน Security+ Academy บน CoddyKit ออกแบบมาสำหรับผู้เริ่มต้นไปจนถึงผู้เรียนขั้นสูง คุณสามารถเริ่มต้นที่นี่หรือเริ่มจากตัวแรกและเรียนด้วยความเร็วของคุณเอง นี่คือบทเรียนที่ 3 จากทั้งหมด 4 บทเรียน
บทเรียน “รูปแบบการให้สิทธิ์: RBAC, MAC และ DAC” ใช้เวลานานแค่ไหน
บทเรียน CoddyKit ส่วนใหญ่ใช้เวลาประมาณ 5–10 นาที แต่ละบทเรียนจึงสั้นและเป็นแบบโต้ตอบ คุณสามารถก้าวหน้าอย่างต่อเนื่องและกลับมาเรียนต่อจากตรงที่เพิ่งหยุดบนเว็บและแอปได้เลย
ฉันเขียนและรันโค้ดในบทเรียน Security+ Academy นี้ได้ไหม
ได้ บทเรียน Security+ Academy ทุกบทมีตัวแก้ไขโค้ดในตัว คุณจึงเขียนและรันโค้ดจริงได้เลยในเบราว์เซอร์ และได้รับข้อเสนอแนะจาก AI ในทันที — ไม่ต้องติดตั้งในเครื่องของคุณ
บทเรียนทั้งหมดในหลักสูตรนี้
- นโยบายรหัสผ่านและการยืนยันตัวตนหลายปัจจัย
- ชีวมาตรและการยืนยันตัวตนด้วยโทเค็น
- รูปแบบการให้สิทธิ์: RBAC, MAC และ DAC
- อัตลักษณ์แบบสหพันธ์: SAML, OAuth และ OpenID Connect