เรากำลังสร้างโมเดลการควบคุมการเข้าถึงตามบทบาท ส่วนที่หนึ่ง การเตรียมการ

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

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

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

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

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

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

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

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

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

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

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

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

ปัจจุบันทราบโมเดลการควบคุมการเข้าถึงต่างๆ มากมาย แต่ไม่ได้ปรากฏขึ้นในทันที ให้เราอาศัยผู้ที่มีส่วนสำคัญในการพัฒนาพื้นที่นี้

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

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

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

โครงสร้างแบบอย่างแรกที่อธิบายไว้อย่างชัดเจนถูกเสนอโดยนักวิทยาศาสตร์ชาวอเมริกัน David Ferrailo และ Richard Kuhn จากสถาบันมาตรฐานและเทคโนโลยีแห่งชาติของสหรัฐอเมริกาในปี 1992 จากนั้นคำนี้ก็ปรากฏขึ้นเป็นครั้งแรก RBAC (การควบคุมการเข้าถึงตามบทบาท) การศึกษาและคำอธิบายขององค์ประกอบหลักเหล่านี้ รวมถึงความสัมพันธ์ขององค์ประกอบเหล่านี้ เป็นพื้นฐานของมาตรฐาน INCITS 359-2012 ซึ่งยังคงบังคับใช้อยู่ในปัจจุบัน โดยได้รับการอนุมัติจากคณะกรรมการระหว่างประเทศว่าด้วยมาตรฐานเทคโนโลยีสารสนเทศ (INCITS)

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

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

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

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

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

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

ตอนนี้เรามาพูดถึงขั้นตอนการเตรียมการที่จำเป็นโดยที่เป็นไปไม่ได้เลยที่จะสร้างแบบอย่างการทำงาน

ขั้นตอนที่ 1 สร้างแบบจำลองการทำงาน

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

ขั้นตอนที่ 2 เราตรวจสอบระบบไอทีและจัดทำแผนการจัดลำดับความสำคัญ

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

แล้วคุณจะกำหนดความสำคัญของระบบได้อย่างไร? ตอบคำถามต่อไปนี้กับตัวเอง:

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

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

NB บริษัท ขนาดใหญ่ที่มีกระบวนการด้านไอทีที่พัฒนาแล้วอาจคุ้นเคยกับขั้นตอนการตรวจสอบด้านไอที - การควบคุมทั่วไปด้านไอที (ITGC) ซึ่งช่วยให้คุณสามารถระบุข้อบกพร่องในกระบวนการด้านไอทีและสร้างการควบคุมเพื่อปรับปรุงกระบวนการให้สอดคล้องกับแนวปฏิบัติที่ดีที่สุด (ITIL, COBIT, IT การกำกับดูแล ฯลฯ) การตรวจสอบดังกล่าวช่วยให้ไอทีและธุรกิจเข้าใจซึ่งกันและกันได้ดีขึ้น และพัฒนากลยุทธ์การพัฒนาร่วมกัน วิเคราะห์ความเสี่ยง ปรับต้นทุนให้เหมาะสม และพัฒนาแนวทางการทำงานที่มีประสิทธิภาพมากขึ้น



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

ขั้นตอนที่ 3 สร้างวิธีการ

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

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

ในบริษัททางการเงินของเรา เราพบเอกสารที่ล้าสมัยจำนวนมาก เราต้องนำมาตามกระบวนการใหม่ที่กำลังดำเนินการ

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

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

ขั้นตอนที่ 4 แก้ไขพารามิเตอร์ของโมเดลการควบคุมการเข้าถึงที่มีอยู่

เรากำลังร่างสิ่งที่เรียกว่า "หนังสือเดินทางของระบบ" ในแง่ของการควบคุมการเข้าถึง โดยพื้นฐานแล้ว นี่คือแบบสอบถามเกี่ยวกับระบบข้อมูลเฉพาะซึ่งบันทึกอัลกอริธึมทั้งหมดสำหรับควบคุมการเข้าถึงระบบ บริษัทที่ใช้โซลูชันระดับ IdM อยู่แล้วอาจคุ้นเคยกับแบบสอบถามดังกล่าว เนื่องจากนี่คือจุดเริ่มต้นของการศึกษาระบบ

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

• วิธีการจัดการบัญชี (โดยตรงในฐานข้อมูลหรือผ่านอินเทอร์เฟซซอฟต์แวร์)
• ผู้ใช้เข้าสู่ระบบอย่างไร (โดยใช้บัญชีแยกต่างหากหรือใช้บัญชี AD, LDAP ฯลฯ )
• ระดับการเข้าถึงระบบที่ใช้ (ระดับแอปพลิเคชัน, ระดับระบบ, การใช้ระบบของทรัพยากรไฟล์เครือข่าย)
• คำอธิบายและพารามิเตอร์ของเซิร์ฟเวอร์ที่ระบบทำงาน
• รองรับการดำเนินการจัดการบัญชีใดบ้าง (การบล็อก การเปลี่ยนชื่อ ฯลฯ );
• อัลกอริธึมหรือกฎใดที่ใช้ในการสร้างตัวระบุผู้ใช้ระบบ
• คุณลักษณะใดที่สามารถใช้เพื่อสร้างความเชื่อมโยงกับบันทึกของพนักงานในระบบบุคลากร (ชื่อเต็ม หมายเลขบุคลากร ฯลฯ)
• คุณสมบัติและกฎของบัญชีที่เป็นไปได้ทั้งหมดสำหรับการกรอก
• สิทธิ์การเข้าถึงที่มีอยู่ในระบบ (บทบาท กลุ่ม สิทธิ์แบบอะตอมมิก ฯลฯ มีสิทธิ์แบบซ้อนหรือแบบลำดับชั้น)
• กลไกการแบ่งสิทธิ์การเข้าถึง (ตามตำแหน่ง แผนก ฟังก์ชันการทำงาน ฯลฯ)
• ระบบมีหลักเกณฑ์การแบ่งแยกสิทธิ (SOD – Segregation of Duties) หรือไม่ และมีหลักการทำงานอย่างไร
• วิธีการประมวลผลเหตุการณ์การขาดงาน การโอน การเลิกจ้าง การอัปเดตข้อมูลพนักงาน ฯลฯ ในระบบ

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

ขั้นตอนที่ 5 สร้างคำอธิบายสิทธิ์เชิงธุรกิจ

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

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

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

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

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

ข้อมูลใดบ้างที่ต้องดาวน์โหลด:

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

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

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

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

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

ผู้แต่ง: Lyudmila Sevastyanova ผู้จัดการฝ่ายส่งเสริมการขาย Solar inRights

ที่มา: will.com