90

บทที่ 6. Access Control

การทํา Access Control เปนกระบวนการที่ใชในการปองกันการใชงานทรัพยากรโดยผูท ี่ไมไดรับ

อนุญาต ซึ่งกระบวนการ Access Control นั้นมีการใชงานในหลากหลายรูปแบบซึ่งตัวอยางในชีวติ ประจําวันเรา
จะเห็นไดทั่วไปเชน การใชกญ
ุ แจไขปดลอกประตู ซึ่งมีเพียงเจาของกุญแจเทานัน้ จึงจะสามารถเปดประตูได การ
ตรวจบัตรเขาชมภาพยนตรซึ่งอนุญาตเฉพาะผูที่มีบัตรเทานั้นจึงจะเขาชมภาพยนตรได การใชบัตรผานประตูและ
รหัสเปดประตูเพื่อเขาไปยังหองที่เก็บขอมูลสําคัญในธนาคาร หรือหนวยงานตางๆ และการใช Username และ
Password ในการเขาอาน E-mail ตางๆ ของผูใชงานแตละคนเปนตน

โดยหลักการทํางานของ Access Control มีกระบวนการดําเนินการดังนีค้ ือ

1. กําหนดผูใชงานระบบวามีใครบาง
2. กําหนดคาทรัพยากรที่ตองการควบคุมการใชงานวามีอะไรบาง
3. กําหนดกระบวนการใชงานของผูใชงานระบบวามีอะไรบาง
4. กําหนดการใชงานของผูใชงานแตละคนวาผูใชงานแตละคนสามารถทํางานอะไรไดบา งและใชงาน
ทรัพยากรใดไดบาง

ในการดําเนินการเกี่ยวกับ Access Control จะใช Access Control Matrix ในการสรางกฎหรือ

ความสัมพันธระหวางผูใ ชงานและทรัพยากรในระบบ โดยกระบวนการสราง Access Control Matrix จะเปนการ
สรุปรวมนโยบายการปองกันทรัพยากรตางๆ หรือการกําหนดสิทธิในการเขาใชทรัพยากรตางๆ ไดโดยชัดเจน
91

รูปที่ 32 Access Control Matrix

สําหรับลักษณะของ Access Control Matrix คือตารางที่ประกอบดวยสวน Row ของ Subject และ

Column ของ Object (อาจเปน Subject ดวย) ในตารางแตละชองจะแสดงสิทธิ (Right) การใชงานของ Subject
เมื่อมีการใชทรัพยากรของ Object ยกตัวอยางเชน Access Control Matrix ของโปรแกรมสองโปรแกรมคือ X
และ Y ซึ่งมีการใชงานไฟล F และ G ดังรูป

รูปที่ 33 ตัวอยาง Access Control Matrix ในการใชงานไฟลระบบ

 92

สิทธิในการใชงานทรัพยากรของตัวอยางนีค้ ือการ Read(R) , Write(W) , Execute(X) และ Owner(O)

โดยการใชงานของโปรแกรม P และ Q สามารถใชงานไฟล F และ G รวมถึง การใชงานพื้นที่ตางๆ ในโพรเซส
ของ P และ Q เปนไปดังตาราง

การใชงาน Access Control Matrix นั้นสามารถประยุกตใชกับการควบคุมการใชงานทรัพยากรตางๆ ได

อยางกวางขวาง ไมวาจะเปนการใชงานฐานขอมูล การใชงานเครือขาย การเขาใชงานระบบของผูใชงานแตละ
คน ซึ่งการทํางานแตละรูปแบบถึงแมวาเปนการทํางานทีแ่ ตกตางกัน แตสามารถใชหลักการเดียวกันในการ
ควบคุมการใชงานได

สําหรับกระบวนการกําหนดการใชงานทรัพยากรโดยใช Access Control Matrix นี้มีขอดีคือสามารถ

กําหนดคาตางๆ ใหกับ Subject และ Object ไดอยางครบถวน แตมีเสียเล็กนอยคือถา Subject และ Object มี
จํานวนมาก จะทําใหตารางมีขนาดใหญ การกําหนดคาตางๆ จะทําไดยาก รวมถึงไมสามารถกําหนดคาโดยมีการ
กําหนดเงื่อนไขตางๆ ได เชนการกําหนด Access Control Matrix ในการใชงานแตละชวงเวลา จะไมสามารถใช
Access Control Matrix เพียง Matrix เดียวไดเนื่องจาก Access Control Matrix ไมไดมีรูปแบบหรือพื้นที่ในการ
กําหนดเงื่อนไขตางๆ ได

ในกรณีของการควบคุมการใชทรัพยากรระบบเครือขาย สามารถใช Access Control Matrix ไดแตโดย

ขอจํากัดของ Access Control Matrix ซึ่งไมสนับสนุนการควบคุมโดยใชตรรกะที่ซับซอนได การควบคุมระบบ
เครือขายจึงตองปรับเปลี่ยนรูปแบบการควบคุม จาก Access Control Matrix ใหอยูในรูปของ Access Control
List ที่มีรูปแบบการควบคุมที่ซับซอนกวาได ยกตัวอยาง Access Control List ที่ใชควบคุมระบบเครือขายใหโดย
ใชตรรกะในการควบคุมที่ซับซอนเชน
router(config)#access-list 110 permit host 161.246.5.10 gt 1024 host –
161.246.4.7 eq 80

router(config)#access-list 110 deny tcp host any any

router(config)#interface fastethernet1

router(config-if)#ip access-group 110 in

93

คําสั่งขางตนเปนคําสั่งที่ใหเครื่องคอมพิวเตอร 161.246.5.10 เทานั้นทีส่ ามารถติดตอกับ Web Server ที่มี

หมายเลขไอพี 161.246.4.7 สําหรับเครื่องอื่น ๆ จะติดตอไมได ซึ่งจะเห็นวาเราสามารถตั้งคาใหกับเราเตอรได
คอนขางหลากหลายเงื่อนไข

ถึงแมวา Access Control List จะรองรับการใชงานในการควบคุมการใชทรัพยากรอยางซับซอนได แตก็

มีรูปแบบที่เปดมาก และไมมีกฎตายตัววาจะตองควบคุม Subject และ Object ใดบาง จึงทําใหเกิดปญหาการตัง้
กฎที่ควบคุมระบบไดไมครบถวนเนื่องจากไมมีรูปแบบควบคุมใหมีรายการของ Subject และ Object อยาง
ครบถวน และอาจเกิดปญหา Rule Conflict ซึ่งมีกฎตั้งแตสองกฎที่ควบคุมการใชทรัพยากรที่ขัดแยงกัน

สําหรับการสราง Access Control ขึ้นมาในระบบอื่นๆ ที่ไมใชใน Network Protocol จําเปนตองมีการ

กําหนดตัวตนของผูใชงานหรือ Identity กอนซึ่งตองอาศัยกระบวนการระบุตัวตนของผูใชงานตางๆ มีการพิสูจน
วาผูใชงานทีใ่ ช Identity นั้นๆ คือเจาของ Identity นั้นๆ จริง แลวจึงมีการกําหนดสิทธิการใชงานใหกับ Identity
นั้นๆ ตามนโยบายที่กําหนด

เขาใจความหมายของ Identification Authentication Authorization

Identification หมายถึงการระบุตัวตนของสิ่งตางๆ ในระบบ จะเปนกระบวนการที่ผูใชงานระบบจะแจง

หลักฐาน(Identity) การมีตัวตนของตัวเอง สําหรับ Identification สําหรับผูใชงานระบบสามารถใชเชนชื่อผูใช
เปนตนซึ่งโดยหลักการของ Identification จะตองการสิ่งของ หรือขอมูลใดๆ ก็ตามทีผ่ ูใชงานคนนัน้ ๆ “เปน
เจาของ” สําหรับคุณสมบัติของ Identity ทีด่ ีควรปลอมแปลงยาก และเปนของบุคคลนั้นๆ เทานั้น

Authentication หมายถึงกระบวนการในการพิสูจนตัวตนวาบุคคลที่ใชงานระบบอยูน นั้ ใชบุคคลคน

นั้นๆ จริงหรือไม เนื่องจากการใชงานระบบตางๆ จะเปนแบบการใชงานระยะไกล ไมสามารถพิสูจนตัวตนได
เนื่องจากไมเห็นหนา ไมทราบลักษณะ แตจะเห็นเพียงขอมูลที่วิ่งผานไปมาเทานั้น ซึง่ หมายถึงการใชงานระบบ
ตางๆ เปนแบบ Logical ทั้งสิ้น กระบวนการ Authentication จึงเปนกระบวนการที่ตรวจสอบวา Logical ที่แทน
บุคคล หรือระบบตางๆ นั้น เปนตัวแทนของบุคคลหรือระบบนั้นๆ จริง กระบวนการในการทํา Authentication
 94

ไดแก การพิสจู นหลักฐานทีบ่ ุคคลนั้นๆ นํามาเสนอเพื่อบงบอกวาคนๆ นั้นเปนคนๆ นั้นจริงๆ เชน Username

และ Password

Authorization หมายถึงการพิสูจนสิทธิวาบุคคลที่ผานกระบวนการ Authentication นั้นมีสิทธิในการใช

งานระบบหรือทรัพยากรใดไดบาง จะเปนกระบวนการทีเ่ กี่ยวของกับการการตั้งคาของสิทธิตางๆ ของผูใชงาน
ในระบบ เพื่อใหการดําเนินการตางๆ ถูกตองตาม Role ของระบบที่ไดกําหนดไวลว งหนา

ทั้ง Identification, Authentication และ Authorization มีสวนเกี่ยวของในการควบคุมการเขาถึง

ทรัพยากรโดยในการเขาใชงานระบบผูใชงานจะแสดง Identity ของตนเองเพื่อ Authentication และระบบจะทํา
การ Authorization เมื่อมีการใชงานทรัพยากรใดๆ ในระบบ

Identity

โปรแกรมหรือระบบตางๆ มักมีการทํางานโดยมีรายการของผูใชงานระบบซึ่งมักจะประกอบดวยรายละเอียด
ตางๆ ดังตอไปนี้

• Username / User ID
• Credential (Password, Certificate, และอื่น)
• Directory Attribute (Name , E-Mail , Phone , Address, และอื่นๆ)
• Organization
• Group
• Application Right
• Policy

สําหรับขอมูลตางๆ ของผูใชงานนี้ระบบจําเปนตองมีการจัดเก็บเพื่อใชในระบบ Authentication โดย

กระบวนการ Authentication คือการที่ผูใชงานระบบพิสูจน Identity ของตัวเองโดยใช Credential ซึ่ง Credential
95

ที่นิยมใชกันมากที่สุดคือการใช Username รวมกับรหัสผาน ภายหลังจากผานกระบวนการ Authentication แลว

ระบบหรือโปรแกรมนั้นๆ จะทําการ Authorization โดยดึงขอมูล Identity และขอมูลอื่นๆ ที่เกี่ยวของเพื่อ
ตัดสินใจวาผูใชงานนั้นจะสามารถใชงานระบบหรือโปรแกรมนั้นๆ ไดหรือไม ซึ่งกระบวนการ Authorization นี้
สามารถดําเนินการไดโดยใชขอมูล Group , Membership , Organization และ Application Right

Identity Management

ในกระบวนการ Authentication และ Authorization ของระบบหรือโปรแกรมตางๆ จําเปนตองมีการดึง

ขอมูล Identity ตางๆ ของผูใชงานระบบ นัน่ หมายความวาโปรแกรมหรือระบบตางๆ จะตองดึงขอมูลจาก
แหลงขอมูลใดก็ตามในระบบ ซึ่งอาจเปนฐานขอมูลผูใชงานของโปรแกรมนั้นๆ ในกรณีที่มีการเก็บ Identity
ของผูใชงานระบบถูกเก็บอยูใ นฐานขอมูลยอยตางๆ หลากหลายแหลง จะทําใหการบริหารจัดการทําไดยากมาก
ขึ้น โดยปญหาสําคัญที่จะเกิดขึ้นเมื่อมีการบริหารจัดการฐานขอมูลผูใชงานที่กระจายตัวกันคือเมื่อมีการ
เปลี่ยนแปลงขอมูลจากจุดใดจุดหนึ่งตองมีการ update ที่ฐานขอมูลอื่นๆ ดวย จากปญหาดังกลาวจึงทําใหมีการใช
งานโปรแกรมจําพวก Identity Management โดยโปรแกรมจําพวก Identity Management นี้จะสรางสภาวะที่
โปรแกรมตางๆ สามารถดึงขอมูลผูใชงานเสมือนกับเปนฐานขอมูลผูใชงานของตนเองได ทําใหโปรแกรมหรือ
ระบบตางๆ สามารถทํางานไดเหมือนเดิม หรือในบางกรณีที่โปรแกรมนั้นๆ จําเปนตองใชฐานขอมูลของ
โปรแกรมเทานั้น Identity Managent จะทําการ Update ฐานขอมูลของโปรแกรมนัน้ ๆ อัตโนมัติหากมีการ
เปลี่ยนแปลงขอมูลบางอยางในระบบที่เกี่ยวของกับโปรแกรม นอกจากนี้ Identity Management จะมีกลไกที่เอื้อ
สําหรับการบริหารจัดการผูใชงานในระบบตางๆ แบบควบคุมจากศูนยกลางได โดยเปาหมายของโปรแกรม
Identity Management คือตองการใหผูใชงานสามารถใชรหัสผานเดียวกันในระบบหรือโปรแกรมตางๆ
 96

Directories และ LDAP

ในการทํางานของ Identity Management จําเปนอยางยิ่งที่จะตองสรางฐานขอมูลผูใชงานกลางขึ้น เพื่อ

ใชในการ Update ฐานขอมูลผูใชงานของแตละระบบหรือแตละโปรแกรม ฐานขอมูลผูใชงานกลางนี้จะเก็บ
ขอมูลของผูใชงานในระบบทั้งหมด ซึ่งฐานขอมูลนี้มักเรียกกันในชื่อ “Directory” ซึ่ง Directory นี้จะสามารถ
เขาถึงไดโดยใช LDAP (Lightweight Directory Access Protocol) ซึ่งเปนมาตรฐานกลางในการเขาถึง Directory
ตางๆ และสามารถ Query , Read และ Update ไดโดยผานโพรโตคอลนี้

Directory จะมีการทํางานในฐานะฐานขอมูลผูใชงานกลางในองคกร ระบบและโปรแกรมตางๆ

สามารถดึงขอมูลของ Identity ตางๆ จาก Directory ในบางระบบหรือโปรแกรมจึงออกแบบมาใหรองรับการใช
งาน Directory โดยไมมีฐานขอมูลผูใชงานของระบบหรือโปรแกรมนัน้ ๆ ซึ่งแนวโนมของระบบหรือโปรแกรม
จะเปนไปในแนวทางนี้ ขณะเดียวกันถึงแมวา LDAP จะเปนโพรโตคอลมาตรฐานในการเขาถึง Directory แตก็
ไมมีมาตรฐานใดที่กําหนดวาโครงสรางขอมูลที่เก็บอยูใน Direcoty ควรมีลักษณะอยางไร โดยทั่วไป ในการ
ออกแบบโครงสรางขอมูลตางๆ ที่เก็บอยูใน Directory นั้น จะขึ้นอยูกับความตองการของระบบหรือโปรแกรม
ตางๆ และ ความตองการขอมูลของบุคลากรตางๆ ในองคกรดวย

การ Log On เพื่อเขาสูระบบ

สําหรับกระบวนการ Log On เพื่อเขาสูระบบนั้น ระบบสามารถทําไดโดยการแสดงหนาตางสําหรับ

กรอก Username และ Password หากตรวจสอบแลวขอมูลทั้งสองตรงกันกับขอมูลทีเ่ ก็บใน Directory หรือ
ฐานขอมูลผูใชงานของระบบแลว แสดงวาผูใชงานนั้นเปนผูใชงานในระบบจริง และสิ้นสุดกระบวนการ
Authentication เพื่อเพิ่มความปลอดภัยในการใชงานระบบจึงมักมีการกําหนดนโยบายเกีย่ วกับการ Log On เชน

• กําหนดใหผใู ชงานตองมีการเปลี่ยนรหัสผานเมื่อทําการ Log On ครั้งถัดไป

• กําหนดใหมีวนั หมดอายุของรหัสผาน
• กําหนดระยะเวลาการใชงานของรหัสผาน
97

• กําหนดความซับซอนของรหัสผาน
• กําหนดใหมีการจัดเก็บประวัติของรหัสผานเพื่อไมใหมกี ารตั้งรหัสผานซ้ํากับที่เคยใชงาน
• กําหนดกระบวนการ Logout

เมื่อผูใชงานเขาใชงานระบบจะมีการตรวจสอบตามนโยบายการรักษาความปลอดภัยดังกลาว ถา
รหัสผานหมดอายุระบบจะดําเนินการใหผใู ชงานเปลี่ยนรหัสผาน ซึ่งรหัสผานใหมทไี่ ดตั้งขึ้นนัน้ จะตองถูก
ตรวจสอบความซับซอนของรหัสผาน และประวัติของรหัสผาน หลังจากการเปลี่ยนรหัสผานเสร็จสมบูรณ จะมี
การ update ขอมูลประวัติของรหัสผาน สําหรับการใชงาน Directory ในการเก็บขอมูลรหัสผาน จะมีการกําหนด
นโยบายเกี่ยวกับรหัสผานไวใน Directory และนําไปใชสําหรับโปรแกรมตางๆ ดวยเพื่อความสะดวกในการ
บริหารจัดการ โดยนโยบายทีก่ ําหนดใน Directory นั้นจะขึ้นอยูกับบริษทั ผูผลิตโปรแกรม Directory Service
นั้นๆ

หากตองการความปลอดภัยมากขึ้นในการ logon เขาสูระบบ ผูดูแลระบบสามารถกําหนดใหผูใชงาน

ระบบตองใชการ logon ดวยกระบวนการอืน่ ๆ เชน Certificate , SecureID , Biometric หรืออุปกรณอนื่ ๆ) ซึ่งการ
ที่จะดําเนินการเชนนี้ได ทุกๆ ระบบที่เกี่ยวของจะตองรองรับกระบวนการ Logon ดวยรูปแบบตางๆ อยางเทา
เทียมกันและควรจะมีกระบวนการ logon ที่ผูใชงานมองเห็นเปนกระบวนการเดียวกัน

การทํา Single Sign On

ในกรณีที่ผูใชงานจําเปนตองเขาใชงานระบบตางๆ มากกวา 1 ระบบ จะเริ่มเกิดความยุงยากสําหรับ

ผูใชงานหากจําเปนตองจําชือ่ ผูใชงานและรหัสผานของระบบตางๆ ที่ตนเองมีสิทธิเขาใชงาน ซึ่งจะนําไปสู
ปญหาการลืมรหัสผาน การตั้งรหัสผานที่คาดเดาไดงายเกินไป หรือการจดรหัสผาน ซึ่งเปนปญหาความปลอดภัย
ในระบบเชนกัน ในสถานการณเชนนี้ผูดแู ลระบบควรตั้งคาระบบใหผูใชงานสามารถใชชื่อผูใชงานและ
 98

รหัสผานเพียงชุดเดียวในหลายๆ ระบบ หรือ Single Sign-On (SSO) โดยกระบวนการของ SSO นั้นจะเปนการ

แยกสวนของ Authentication / Authorization Component ออกจาก Application

สําหรับการสรางระบบ Single Sign-On นั้นสามารถทําไดโดยใชผลิตภัณฑตางๆ ในทองตลาด หรือ

Open Source Project ซึ่งเจาของผลิตภัณฑดาน Identity Management ที่มีขนาดใหญในทองตลาดจะมีฟงกชนั่
การทํา SSO อยูแลว ซึ่งโดยทั่วไป Identity Management และ SSO Component ของผลิตภัณฑเดียวกันจะมีการ
ใชงาน Directory Service รวมกัน ซึ่ง Identity Management จะใหบริการการบูรณาการขอมูลตางๆ ใน
Directory

นอกจากนี้ ผูใชงานระบบอาจจําเปนตองมีการใชงานขอมูลขามองคกร ซึ่งเปนระบบการ

Authentication / Authorization ที่ซับซอนมาก ผูใชงานจากระบบหนึ่งขององคกรหนึ่ง จะสามารถเขาใชงานอีก
ระบบหนึ่งในอีกองคกรหนึง่ ซึ่งในการสรางระบบ SSO ใหสามารถทํา Authentication และ Authentication ขาม
องคกรไดนั้นจําเปนตองมี Federation Service ในแตละระบบแลวสราง Trust System ขึ้นระหวางระบบ ปจจุบัน
มีผลิตภัณฑในทองตลาดที่รองรับมาตรฐานการทํา Federation Service อยูมากมาย แตสามารถจัดกลุมไดเปน 2
กลุมหลักคือ

1. กลุมผลิตภัณฑเกี่ยวกับการจัดการ Identity และ SSO ที่มีการเพิ่มเติมความสามารถการทํา Federation

ในภายหลัง
2. กลุมผลิตภัณฑที่ทํางานเกีย่ วกับการจัดการ Federation Service โดยเฉพาะ

กลุมผลิตภัณฑเกี่ยวกับการจัดการ Identity และ SSO ที่มีการเพิ่มเติมความสามารถ Federation

1. Oracle (Oracle Federated Identity Solution)

2. IBM (IBM Tivoli Federated Identity Manager)
3. Sun ( Sun Java System Federation Manager)
4. CA (Ca eTrust SiteMinder Federation Security Services)
5. HP (HP OpenView Select Federation)
99

โดยผลิตภัณฑทั้งหมดรองรับมาตรฐาน SAML 1.1 และ 2.0 นอกจากนี้ยังสนับสนุน WS-Federation

และ มาตรฐานของ Liberty Alliance เชนกัน สําหรับผลิตภัณฑของ Microsoft นั้นมีการเพิ่ม Active Directory
Federation Services ใน Windows 2003 Server ซึ่งมีการทํางานตามมาตรฐาน WS-* เชน WS-Federation และ
WS-Trust

กลุมผลิตภัณฑที่ทํางานเกี่ยวกับการจัดการ Federation Service โดยเฉพาะ

ยกตัวอยางเชน PingFederation ของ Ping Identity และ Federated Access Manager ของ Symlabs ซึ่ง
สนับสนุนตามมาตรฐาน SAML 1.1 และ 2.0 , WS-Federation สามารถทํางานทั้ง Identity Provider และ Service
Provider

นอกจากนี้ยงั มีผลิตภัณฑชื่อ Ping Trust ของ Ping Identity ที่มีการทํางานตาม WS-Trust เพื่อทํา
security token service

นอกจากผลิตภัณฑที่มีอยูในทองตลาดทั้งสองกลุมแลว ยังมีซอฟตแวรในกลุม Open Source ที่สามารถ

ทํางาน Federation Services ไดแก

1. Shibboleth
2. OpenSAML
3. SourceID toolkits
4. Guanxi
5. OpenSSO

Shibboleth เปนโปรเจคหนึ่งของ Internet2 networking consortium โดยการทํางานของ Shibboleth จะ

สามารถสราง Identity Provider และ Service Provider บนพื้นฐานของมาตรฐาน SAML 1.1 และ 2.0 นอกจากนี้
 100

Shibboleth ยังมีซอฟตแวรเพิม่ เติมสําหรับการทํางานตามมาตรฐาน WS-Federation เพื่อรองรับการทํางาน

รวมกับระบบ Active Diretory Federation Service (ADFS)

OpenSAML เปนโปรเจคหนึ่งของ Internet2 networking consortium ซึ่งมีไลบรารีในภาษา Java และ

C++ เพื่อการสื่อสารในมาตรฐาน SAML 1.1 และ 2.0

SourceID เปนโปรเจคหนึ่งของ Ping Identity ที่ใหบริการการเชื่อมตอตามมาตรฐาน SAML , ID-FF

และ WS-Federation สําหรับ Platform ตางๆ

Guanxi เปนระบบการทํางานที่ใหบริการการเชื่อมตอ SAML สําหรับ Java web application โดยรองรับ

การทํางานเปน Identity Provider และ Service Provider Guanxi ทําให Java web application ตางๆ สามารถ
เชื่อมตอกับ Identity Provider อื่นๆ เชน Shibboleth ไดผาน SAML

OpenSSO เปนผลิตภัณฑทพี่ ัฒนาโดยบริษัท Sun ที่มีการพัฒนาจาก Sun Java System Access Manager
และ Sun Java Federation Manager เพื่อเปนโครงสรางการทํางานที่ทําใหเกิด Federation Service สําหรับ
OpenSSO สามารถทํางานรวมกับ Shibboleth และ ADFS ได

สําหรับกรณีของระบบเครือขาย การควบคุมการเขาถึงระบบจะหมายถึงการคัดกรองขอมูลในเครือขาย
วาขอมูลใดจะสามารถผานเขาระบบได และขอมูลใดไมสามารถผานเขาออกระบบได อุปรณที่ใชในการคัด
กรองขอมูลดังกลาวคือ “Firewall”