Бид дүрд суурилсан хандалтын хяналтын загварыг бий болгож байна. Нэгдүгээр хэсэг, бэлтгэл

Би одоогоор програм хангамжийн борлуулагч, ялангуяа хандалтын хяналтын шийдэл дээр ажилладаг. Миний "өнгөрсөн амьдралаас" авсан туршлага бол үйлчлүүлэгчийн тал болох санхүүгийн томоохон байгууллагатай холбоотой юм. Тухайн үед манай мэдээллийн аюулгүй байдлын хэлтэс дэх хандалтын хяналтын бүлэг IdM-д маш сайн чадвараараа сайрхаж чадахгүй байв. Компанийн мэдээллийн систем дэх хэрэглэгчийн эрхийг удирдах механизмыг бий болгохын тулд бид маш их зүйлийг сурч мэдсэн.
Бид дүрд суурилсан хандалтын хяналтын загварыг бий болгож байна. Нэгдүгээр хэсэг, бэлтгэл
Хэрэглэгчийн шаргуу туршлагаа борлуулагчийн мэдлэг, чадамжтай хослуулан би чамтай үндсэндээ алхам алхмаар зааварчилгааг хуваалцахыг хүсч байна: томоохон компанид дүрд суурилсан хандалтын хяналтын загварыг хэрхэн бий болгох, үр дүнд нь юу өгөх вэ? . Миний заавар хоёр хэсгээс бүрдэнэ: эхнийх нь загварыг бүтээхэд бэлдэж байна, хоёр дахь нь үнэндээ бүтээх. Энд эхний хэсэг, бэлтгэл хэсэг байна.

NB Үлгэр жишээг бий болгох нь харамсалтай нь үр дүн биш, харин үйл явц юм. Өөрөөр хэлбэл, компанид хандалтын хяналтын экосистемийг бий болгох үйл явцын нэг хэсэг юм. Тиймээс тоглолтонд удаан хугацаанд бэлдээрэй.

Эхлээд үүнийг тодорхойлъё - дүрд суурилсан хандалтын хяналт гэж юу вэ? Танд хэдэн арван, бүр хэдэн зуун мянган ажилтан (аж ахуйн нэгж) бүхий томоохон банк байна гэж бодъё, тэдгээр нь тус бүр нь олон зуун банкны дотоод мэдээллийн системд (объект) хандах эрхтэй байдаг. Одоо объектын тоог субьектуудын тоогоор үржүүлээрэй - энэ нь эхлээд барьж, дараа нь хянах шаардлагатай холболтын хамгийн бага тоо юм. Үүнийг гараар хийх үнэхээр боломжтой юу? Мэдээжийн хэрэг үгүй ​​- энэ асуудлыг шийдэхийн тулд дүрүүдийг бүтээсэн.

Үүрэг гэдэг нь тодорхой ажлын даалгаврыг гүйцэтгэхийн тулд хэрэглэгч эсвэл бүлэг хэрэглэгчдэд шаардлагатай зөвшөөрлийн багц юм. Ажилтан бүр нэг буюу хэд хэдэн үүрэгтэй байж болох ба үүрэг тус бүр нь тухайн үүрэг доторх хэрэглэгчдэд зөвшөөрөгдсөн нэгээс олон зөвшөөрлийг агуулж болно. Үүрэг нь тодорхой албан тушаал, хэлтэс эсвэл ажилчдын функциональ даалгавартай холбоотой байж болно.

Бид дүрд суурилсан хандалтын хяналтын загварыг бий болгож байна. Нэгдүгээр хэсэг, бэлтгэл

Мэдээллийн систем тус бүрийн ажилтны зөвшөөрлөөр дүрүүдийг бий болгодог. Дараа нь систем бүрийн үүргээс дэлхийн бизнесийн үүрэг үүсдэг. Жишээлбэл, "зээлийн менежер" гэсэн бизнесийн үүрэг нь банкны харилцагчийн албанд ашиглагддаг мэдээллийн системд хэд хэдэн тусдаа үүргийг багтаана. Жишээлбэл, банкны үндсэн автоматжуулсан систем, бэлэн мөнгөний модуль, цахим баримт бичгийн удирдлагын систем, үйлчилгээний менежер гэх мэт. Дүрмээр бол бизнесийн үүрэг нь байгууллагын бүтэц, өөрөөр хэлбэл компанийн хэлтэс, тэдгээрийн албан тушаалтай холбоотой байдаг. Глобал үүргийн матриц ийм байдлаар үүсдэг (би доорх хүснэгтэд жишээ өгсөн).

Бид дүрд суурилсан хандалтын хяналтын загварыг бий болгож байна. Нэгдүгээр хэсэг, бэлтгэл

Арилжааны бүтэц дэх албан тушаал бүрийн ажилтнуудад шаардлагатай бүх эрхийг хангаж, 100% үлгэр дууриал бий болгох нь ердөө л боломжгүй гэдгийг тэмдэглэх нь зүйтэй. Тийм ээ, энэ шаардлагагүй. Эцсийн эцэст, үлгэр дуурайл нь тогтмол өөрчлөгдөж чадахгүй, учир нь энэ нь байнга өөрчлөгдөж байдаг орчноос хамаардаг. Байгууллагын бүтэц, үйл ажиллагааны өөрчлөлтөд нөлөөлж буй компанийн бизнесийн үйл ажиллагааны өөрчлөлтөөс. Мөн нөөц бололцоогоо бүрэн хангаагүй, ажлын байрны тодорхойлолтыг дагаж мөрдөөгүй, аюулгүй байдлын зардлаар ашиг олох хүсэл, бусад олон хүчин зүйлээс үүдэлтэй. Иймд тухайн албан тушаалд томилогдоход шаардлагатай үндсэн эрхийн хэрэглэгчийн хэрэгцээний 80 хүртэлх хувийг хангаж чадах үлгэр дуурайллыг бий болгох шаардлагатай байна. Тэд шаардлагатай бол үлдсэн 20% -ийг дараа нь тусдаа програм дээр хүсч болно.

Мэдээжийн хэрэг, та: "100% үлгэр дуурайлал гэж байдаггүй гэж үү?" Яагаад, жишээлбэл, байнга өөрчлөгддөггүй ашгийн бус бүтцэд - зарим судалгааны хүрээлэнд ийм зүйл тохиолддог. Эсвэл аюулгүй байдлыг нэгдүгээрт тавьдаг өндөр түвшний хамгаалалттай цэрэг-аж үйлдвэрийн цогцолборын байгууллагуудад. Энэ нь арилжааны бүтцэд тохиолддог боловч тусдаа хэлтсийн хүрээнд явагддаг бөгөөд ажил нь нэлээд статик, урьдчилан таамаглах боломжтой үйл явц юм.

Дүрд суурилсан удирдлагын гол давуу тал нь эрх олгох ажлыг хялбарчлах явдал юм, учир нь үүргийн тоо нь мэдээллийн системийн хэрэглэгчдийн тооноос хамаагүй бага байдаг. Мөн энэ нь аль ч салбарт үнэн юм.

Жижиглэн худалдааны компанийг авч үзье: энэ нь олон мянган борлуулагчдыг ажиллуулдаг, гэхдээ тэд N системд ижил эрхтэй бөгөөд зөвхөн нэг л үүрэг тэдэнд бий болно. Компанид шинэ худалдагч ирэхэд түүнд шаардлагатай бүх эрх мэдэл аль хэдийн байгаа системд шаардлагатай үүргийг автоматаар хуваарилдаг. Мөн нэг товшилтоор та олон мянган худалдагчийн эрхийг нэг дор өөрчлөх боломжтой, жишээлбэл, тайлан гаргах шинэ сонголтыг нэмж болно. Бүртгэл бүрт шинэ эрх холбож, мянган үйлдэл хийх шаардлагагүй - энэ сонголтыг дүрд нэмэхэд л бүх худалдагчдад нэгэн зэрэг харагдах болно.

Дүрд суурилсан удирдлагын бас нэг давуу тал бол үл нийцэх зөвшөөрөл олгох явдлыг арилгах явдал юм. Өөрөөр хэлбэл, системд тодорхой үүрэг гүйцэтгэдэг ажилтан нэгэн зэрэг өөр үүрэг гүйцэтгэх боломжгүй бөгөөд түүний эрхийг эхнийхтэй нь холбож болохгүй. Үүний тод жишээ бол санхүүгийн гүйлгээг оруулах, хянах чиг үүргийг хослуулахыг хориглосон явдал юм.

Дүрд суурилсан хандалтын хяналт хэрхэн бий болсныг сонирхож буй хэн бүхэн үүнийг хийж чадна
түүх рүү шумбах
Хэрэв бид түүхийг харвал мэдээллийн технологийн нийгэмлэг 70-р зууны XNUMX-аад оны үед хандалтын хяналтын аргуудын талаар анх бодож байжээ. Хэдийгээр тэр үед програмууд маш энгийн байсан ч одоогийнх шиг хүн бүр тэдгээрт хандах хандалтыг хялбархан зохицуулахыг үнэхээр хүсдэг байв. Хэрэглэгчийн эрхийг олгох, өөрчлөх, хянах - зүгээр л тус бүр нь ямар хандалттай болохыг ойлгоход хялбар болгохын тулд. Гэвч тэр үед нэгдсэн стандарт байгаагүй, анхны хандалтын хяналтын системүүд бий болж, компани бүр өөрийн гэсэн санаа, дүрэм журамд тулгуурладаг байсан.

Хандалтыг хянах олон янзын загварууд одоо мэдэгдэж байгаа боловч тэр даруй гарч ирээгүй. Энэ нутгийн хөгжилд томоохон хувь нэмэр оруулсан хүмүүсийн талаар товчхон дурдъя.

Эхний бөгөөд магадгүй хамгийн энгийн загвар Үзэмжийн (сонгомол) хандалтын хяналт (DAC - дурын хандалтын хяналт). Энэ загвар нь хандалтын үйл явцад оролцогч бүх хүмүүсийн эрхийг хуваалцах гэсэн үг юм. Хэрэглэгч бүр тодорхой объект эсвэл үйлдэлд хандах эрхтэй. Үндсэндээ энд эрхийн субъектуудын багц нь объектын багцтай тохирч байна. Энэ загвар нь хэтэрхий уян хатан, хадгалахад хэцүү байсан нь тогтоогдсон: хандалтын жагсаалтууд нь эцэстээ асар том болж, хянахад хэцүү болдог.

Хоёр дахь загвар нь Заавал нэвтрэх хяналт (MAC - Mandatory access control). Энэ загварын дагуу хэрэглэгч бүр өгөгдлийн нууцлалын тодорхой түвшинд олгогдсон хандалтын дагуу объект руу нэвтрэх эрхийг авдаг. Үүний дагуу объектуудыг нууцлалын түвшингээр нь ангилах ёстой. Эхний уян хатан загвараас ялгаатай нь энэ загвар нь эсрэгээрээ хэтэрхий хатуу, хязгаарлагдмал болсон. Компани нь олон төрлийн мэдээллийн нөөцтэй бол түүнийг ашиглах нь зөвтгөгддөггүй: янз бүрийн нөөцөд хандах хандалтыг ялгахын тулд та давхцахгүй олон ангиллыг нэвтрүүлэх шаардлагатай болно.

Эдгээр хоёр аргын илэрхий төгс бус байдлаас шалтгаалан мэдээллийн технологийн нийгэмлэг нь байгууллагын хандалтын хяналтын янз бүрийн бодлогыг дэмжихийн тулд илүү уян хатан, нэгэн зэрэг түгээмэл байдаг загваруудыг үргэлжлүүлэн хөгжүүлсээр байна. Тэгээд тэр гарч ирэв Гурав дахь дүрд суурилсан хандалтын хяналтын загвар! Энэ арга нь хамгийн ирээдүйтэй болох нь батлагдсан, учир нь энэ нь зөвхөн хэрэглэгчийн таних эрхийг баталгаажуулахаас гадна түүний систем дэх үйл ажиллагааны функцийг шаарддаг.

Анхны тодорхой тайлбарласан үлгэр жишээ бүтцийг 1992 онд АНУ-ын Үндэсний Стандарт, Технологийн Хүрээлэнгээс Америкийн эрдэмтэн Дэвид Феррайло, Ричард Кун нар санал болгосон. Дараа нь энэ нэр томъёо анх гарч ирэв RBAC (Үүрэгт суурилсан хандалтын хяналт). Эдгээр судалгаа, үндсэн бүрэлдэхүүн хэсгүүдийн тодорхойлолт, тэдгээрийн хоорондын хамаарал нь Олон улсын Мэдээллийн Технологийн Стандартын Хорооноос (INCITS) батлагдсан INCITS 359-2012 стандартын үндэс болсон бөгөөд өнөөг хүртэл хүчинтэй байна.

Стандартад үүрэг гэдэг нь "Үүрэгт томилогдсон хэрэглэгчдэд олгогдсон эрх мэдэл, хариуцлагын талаархи зарим холбогдох семантик бүхий байгууллагын нөхцөл дэх ажлын чиг үүрэг" гэж тодорхойлсон. Энэхүү баримт бичиг нь RBAC-ийн үндсэн элементүүд болох хэрэглэгчид, сесс, үүрэг, зөвшөөрөл, үйл ажиллагаа, объект, түүнчлэн тэдгээрийн хоорондын харилцаа холбоо, харилцан холболтыг тогтоодог.

Энэхүү стандарт нь үлгэр дуурайлал бий болгоход шаардлагатай хамгийн бага бүтцийг бий болгодог - эрхийг үүрэг болгон нэгтгэж, дараа нь эдгээр дүрээр дамжуулан хэрэглэгчдэд хандах боломжийг олгодог. Объект, үйлдлээс дүр бүтээх механизмыг тодорхойлж, үүргийн шатлал, эрх мэдлийн өв залгамжлалыг тодорхойлсон. Эцсийн эцэст аливаа компанид компанийн бүх ажилчдад шаардлагатай үндсэн эрх мэдлийг нэгтгэсэн үүрэг байдаг. Энэ нь имэйл, EDMS, корпорацийн портал гэх мэт хандалт байж болно. Эдгээр зөвшөөрлийг "ажилтан" гэж нэрлэдэг нэг ерөнхий дүрд багтааж болох бөгөөд дээд түвшний үүрэг болгонд бүх үндсэн эрхийг дахин дахин жагсаах шаардлагагүй болно. "Ажилтны" үүргийн удамшлын шинж чанарыг зүгээр л зааж өгөхөд хангалттай.

Бид дүрд суурилсан хандалтын хяналтын загварыг бий болгож байна. Нэгдүгээр хэсэг, бэлтгэл

Хожим нь стандартыг байнга өөрчлөгдөж буй орчинтой холбоотой шинэ хандалтын шинж чанаруудаар нэмж оруулсан. Статик болон динамик хязгаарлалтыг нэвтрүүлэх чадварыг нэмсэн. Статик нь дүрүүдийг нэгтгэх боломжгүй гэсэн үг юм (дээр дурдсан үйлдлүүдийн ижил оролт, хяналт). Динамик хязгаарлалтыг параметрүүдийг өөрчлөх замаар тодорхойлж болно, жишээлбэл, цаг (ажлын / ажлын бус цаг эсвэл өдөр), байршил (оффис / гэр) гэх мэт.

Үүнийг тусад нь дурдах нь зүйтэй шинж чанарт суурилсан хандалтын хяналт (ABAC - Attribute-based access control). Энэ арга нь атрибут хуваалцах дүрмийг ашиглан хандалт олгоход суурилдаг. Энэ загварыг тусад нь ашиглаж болох боловч ихэнхдээ энэ нь сонгодог үлгэр жишээг идэвхтэй нөхдөг: хэрэглэгчдийн шинж чанар, нөөц, төхөөрөмж, түүнчлэн цаг хугацаа, байршлыг тодорхой үүрэгт нэмж болно. Энэ нь танд цөөн үүрэг ашиглах, нэмэлт хязгаарлалтуудыг нэвтрүүлэх, хандалтыг аль болох бага болгох, улмаар аюулгүй байдлыг сайжруулах боломжийг олгоно.

Жишээлбэл, нягтлан бодогч тодорхой бүс нутагт ажилладаг бол данс руу нэвтрэхийг зөвшөөрч болно. Дараа нь мэргэжилтний байршлыг тодорхой лавлагааны утгатай харьцуулна. Эсвэл хэрэглэгч зөвшөөрөгдсөн төхөөрөмжүүдийн жагсаалтад орсон төхөөрөмжөөс нэвтэрсэн тохиолдолд л та бүртгэлд хандах эрхийг өгч болно. Үлгэр дуурайл болох сайн нэмэлт, гэхдээ олон дүрэм, зөвшөөрөл, хязгаарлалтын хүснэгтийг бий болгох шаардлагатай тул бие даан ашиглах нь ховор.

ABAC-ийг ашигласан жишээг “өнгөрсөн амьдралаас” хэлье. Манай банк хэд хэдэн салбартай байсан. Эдгээр салбар дахь үйлчлүүлэгчдийн оффисын ажилтнууд яг ижил үйлдлүүдийг хийдэг байсан боловч үндсэн системд зөвхөн бүс нутагтаа данстай ажиллах ёстой байв. Нэгдүгээрт, бид бүс бүрт тусдаа үүрэг үүсгэж эхэлсэн - давтагдах функцтэй, гэхдээ өөр өөр бүртгэлд хандах боломжтой ийм олон дүрүүд байсан! Дараа нь хэрэглэгчийн байршлын атрибутыг ашиглаж, үүнийг шалгахын тулд тодорхой хүрээний бүртгэлтэй холбосноор бид систем дэх үүргийн тоог эрс багасгасан. Үүний үр дүнд банкны бусад бүх нутаг дэвсгэрийн хэлтэст тохирох албан тушаалд хувилсан нэг салбарт үүрэг үлдсэн.

Одоо шаардлагатай бэлтгэлийн алхмуудын талаар ярилцъя, үүнгүйгээр ажлын үлгэр дуурайллыг бий болгох боломжгүй юм.

Алхам 1. Функциональ загварыг бий болгох

Та хэлтэс, албан тушаал бүрийн функцийг нарийвчлан тодорхойлсон дээд түвшний баримт бичиг болох функциональ загварыг бий болгохоос эхлэх хэрэгтэй. Дүрмээр бол мэдээллийг янз бүрийн баримт бичгээс оруулдаг: ажлын байрны тодорхойлолт, бие даасан нэгжийн дүрэм журам - хэлтэс, хэлтэс, хэлтэс. Функциональ загварыг сонирхсон бүх хэлтэс (бизнес, дотоод хяналт, аюулгүй байдал) -тай тохиролцож, компанийн удирдлагаар баталгаажуулсан байх ёстой. Энэ баримт бичиг юунд зориулагдсан бэ? Тиймээс үлгэр дуурайл нь түүнд хандаж болно. Жишээлбэл, та ажилчдын одоо байгаа эрхүүд дээр тулгуурлан үлгэр жишээг бий болгох гэж байна - системээс буулгаж, "нийтлэг хэсэг болгон бууруулсан". Дараа нь системийн бизнес эрхлэгчтэй хүлээн авсан үүргүүдийн талаар тохиролцохдоо та функциональ загварын тодорхой цэгийг анхаарч үзэх боломжтой бөгөөд үүний үндсэн дээр энэ эсвэл өөр эрх үүрэгт багтсан болно.

Алхам 2. Бид мэдээллийн технологийн системд аудит хийж, тэргүүлэх чиглэлийн төлөвлөгөө гаргадаг

Хоёрдахь шатанд та мэдээллийн технологийн системд хандах хандалтыг хэрхэн зохион байгуулж байгааг ойлгохын тулд аудит хийх хэрэгтэй. Жишээлбэл, манай санхүүгийн компани хэдэн зуун мэдээллийн системийг ажиллуулдаг. Бүх системүүд дүрд суурилсан удирдлагын зарим үндсэн суурьтай байсан, ихэнх нь зарим үүрэг гүйцэтгэдэг байсан ч ихэнхдээ цаасан дээр эсвэл системийн лавлах дээр байдаг - тэдгээр нь удаан хугацааны туршид хуучирсан бөгөөд хэрэглэгчийн бодит хүсэлт дээр үндэслэн тэдгээрт хандах эрхийг олгосон. Мэдээжийн хэрэг, нэг дор хэдэн зуун системд үлгэр дууриал бий болгох боломжгүй, та хаа нэгтээ эхлэх хэрэгтэй. Бид хандалтын хяналтын үйл явцын төлөвшлийн түвшинг тодорхойлохын тулд гүнзгий дүн шинжилгээ хийсэн. Шинжилгээний явцад мэдээллийн системийг эрэмбэлэх шалгуурыг боловсруулсан - чухал байдал, бэлэн байдал, ашиглалтаас гаргах төлөвлөгөө гэх мэт. Тэдгээрийн тусламжтайгаар бид эдгээр системүүдэд үлгэр дуурайллыг бий болгох/шинэчлэх ажлыг зохион байгуулсан. Дараа нь бид хандалтын менежментийг автоматжуулахын тулд Identity Management шийдэлтэй нэгтгэх төлөвлөгөөнд үлгэр дууриалал оруулсан.

Тэгэхээр системийн шүүмжлэлийг хэрхэн тодорхойлох вэ? Дараах асуултуудад өөртөө хариулна уу.

  • Систем нь компанийн үндсэн үйл ажиллагаанаас хамаардаг үйл ажиллагааны процессуудтай холбоотой юу?
  • Системийн доголдол нь компанийн хөрөнгийн бүрэн бүтэн байдалд нөлөөлөх үү?
  • Тасалдлын дараа үйл ажиллагааг сэргээх боломжгүй байгаа системийн зөвшөөрөгдөх хамгийн дээд хугацаа хэд вэ?
  • Систем дэх мэдээллийн бүрэн бүтэн байдлыг зөрчих нь санхүүгийн болон нэр хүндийн хувьд эргэлт буцалтгүй үр дагаварт хүргэж болох уу?
  • Луйврын шүүмжлэл. Хэрэв зохих хяналтгүй бол функциональ байдал нь дотоод/гадны залилан мэхлэх үйлдэлд хүргэж болзошгүй;
  • Эдгээр системд тавигдах хууль эрх зүйн шаардлага, дотоод дүрэм, журам юу вэ? Зохицуулагчдаас зөрчил гаргасан тохиолдолд торгууль ногдуулах уу?

Манай санхүүгийн компанид ийм шалгалт хийсэн. Удирдлага нь хамгийн түрүүнд тэргүүлэх жагсаалтад орсон мэдээллийн системд байгаа одоо байгаа хэрэглэгчид болон эрхийг шалгах зорилгоор Хандалтын эрхийн хяналтын аудитын журмыг боловсруулсан. Аюулгүй байдлын хэлтсийг энэ үйл явцын эзэнээр томилсон. Гэхдээ компанид нэвтрэх эрхийн талаар бүрэн дүр зургийг олж авахын тулд мэдээллийн технологийн болон бизнесийн хэлтсүүдийг үйл явцад татан оролцуулах шаардлагатай байв. Эндээс маргаан, үл ойлголцол, заримдаа бүр хорлон сүйтгэх ажиллагаа эхэлсэн: хэн ч одоогийн үүрэг хариуцлагаасаа салж, эхлээд харахад үл ойлгогдох үйл ажиллагаанд оролцохыг хүсдэггүй.

NB Мэдээллийн технологийн процессыг хөгжүүлсэн томоохон компаниуд мэдээллийн технологийн аудитын горимыг мэддэг байх - IT ерөнхий хяналт (ITGC) нь мэдээллийн технологийн үйл явц дахь дутагдлыг олж илрүүлэх, үйл явцыг шилдэг туршлагын дагуу (ITIL, COBIT, IT) сайжруулах хяналтыг бий болгох боломжийг олгодог. Засаглал гэх мэт) Ийм аудит нь МТ болон бизнест бие биенээ илүү сайн ойлгож, хамтарсан хөгжлийн стратеги боловсруулах, эрсдэлд дүн шинжилгээ хийх, зардлыг оновчтой болгох, ажлын үр дүнтэй арга барилыг боловсруулах боломжийг олгодог.

Бид дүрд суурилсан хандалтын хяналтын загварыг бий болгож байна. Нэгдүгээр хэсэг, бэлтгэл

Аудитын нэг чиглэл нь мэдээллийн системд логик болон физик хандалтын параметрүүдийг тодорхойлох явдал юм. Бид олж авсан өгөгдлийг үлгэр дууриал болгоход цаашид ашиглах үндэс болгон авсан. Энэхүү аудитын үр дүнд бид мэдээллийн технологийн системийн бүртгэлтэй болж, тэдгээрийн техникийн үзүүлэлтүүдийг тодорхойлж, тодорхойлолтыг өгсөн. Нэмж дурдахад, систем бүрийн хувьд хэний ашиг сонирхолд нийцүүлэн ажиллаж байсан бизнесийн чиглэлээс эзэмшигчийг тодорхойлсон: энэ систем нь үйлчилж буй бизнесийн үйл явцыг хариуцдаг хүн юм. Мөн мэдээллийн технологийн үйлчилгээний менежерийг томилсон бөгөөд тодорхой IS-ийн бизнесийн хэрэгцээг техникийн хэрэгжилтийг хариуцдаг. Компанийн хувьд хамгийн чухал системүүд, тэдгээрийн техникийн үзүүлэлтүүд, ашиглалтад оруулах, ашиглалтаас гаргах хугацаа гэх мэтийг бүртгэсэн бөгөөд эдгээр үзүүлэлтүүд нь үлгэр дууриал бий болгоход бэлтгэх явцад маш их тус болсон.

Алхам 3 Арга зүй зохиох

Аливаа бизнесийн амжилтын үндэс нь зөв арга юм. Тиймээс бид үлгэр дуурайлал бий болгох, аудит хийх аль алинд нь хэлтэс хоорондын харилцан үйлчлэлийг тодорхойлсон аргачлалыг бий болгох, компанийн дүрэм журамд хариуцлагыг тогтоох гэх мэтийг бий болгох хэрэгтэй.
Эхлээд та нэвтрэх эрх, эрх олгох журмыг тогтоосон бүх баримт бичгийг шалгах хэрэгтэй. Сайн арга замаар, үйл явцыг хэд хэдэн түвшинд баримтжуулсан байх ёстой:

  • компанийн ерөнхий шаардлага;
  • мэдээллийн аюулгүй байдлын чиглэлээр тавигдах шаардлага (байгууллагын үйл ажиллагааны чиглэлээс хамаарч);
  • технологийн процесст тавигдах шаардлага (заавар, хандалтын матриц, заавар, тохиргооны шаардлага).

Манай санхүүгийн компанид бид олон тооны хуучирсан баримт бичгүүдийг олж илрүүлсэн тул тэдгээрийг хэрэгжүүлж буй шинэ үйл явцын дагуу авчрах шаардлагатай болсон.

Удирдлагын тушаалаар аюулгүй байдал, мэдээллийн технологи, бизнес, дотоод хяналтын төлөөллийг багтаасан ажлын хэсэг байгуулсан. Уг тушаалд бүлгийг байгуулах зорилго, үйл ажиллагааны чиглэл, оршин тогтнох хугацаа, аль аль талаас нь хариуцах хүмүүсийг тодорхойлсон. Нэмж дурдахад бид аудитын арга зүй, үлгэр дууриал бий болгох журмыг боловсруулсан: тэдгээрийг тухайн бүс нутгийн бүх хариуцлагатай төлөөлөгчид тохиролцож, компанийн удирдлага баталсан.

Ажил гүйцэтгэх журам, эцсийн хугацаа, үүрэг хариуцлага гэх мэтийг тодорхойлсон баримт бичиг. - Эхэндээ хүн болгонд мэдэгдэхгүй нандин зорилгодоо хүрэх замд "бид яагаад үүнийг хийж байна, яагаад бидэнд хэрэгтэй байна вэ гэх мэт асуултууд хэнд ч гарахгүй байх баталгаа." мөн "үсрэх" эсвэл үйл явцыг удаашруулах боломж байхгүй болно.

Бид дүрд суурилсан хандалтын хяналтын загварыг бий болгож байна. Нэгдүгээр хэсэг, бэлтгэл

Алхам 4. Одоо байгаа хандалтын хяналтын загварын параметрүүдийг засах

Бид хандалтын хяналтын хувьд "системийн паспорт" гэж нэрлэгдэх зүйлийг боловсруулж байна. Үндсэндээ энэ нь тодорхой мэдээллийн системийн талаархи санал асуулга бөгөөд түүнд хандах хандалтыг хянах бүх алгоритмыг бүртгэдэг. IdM ангиллын шийдлүүдийг аль хэдийн хэрэгжүүлсэн компаниуд ийм асуулгын хуудсыг мэддэг байх, учир нь эндээс системийг судлах ажил эхэлдэг.

Систем болон эзэмшигчдийн талаархи зарим параметрүүдийг мэдээллийн технологийн бүртгэлээс асуулгад оруулсан (2-р алхам, аудитыг үзнэ үү), гэхдээ шинээр нэмж оруулсан болно:

  • акаунтуудыг хэрхэн удирддаг (шууд мэдээллийн санд эсвэл програм хангамжийн интерфейсээр дамжуулан);
  • хэрэглэгчид системд хэрхэн нэвтрэх (тусдаа данс ашиглах эсвэл AD данс, LDAP гэх мэт);
  • системд хандах хандалтын ямар түвшинг ашигладаг (програмын түвшин, системийн түвшин, сүлжээний файлын нөөцийн системийн ашиглалт);
  • систем ажиллаж байгаа серверүүдийн тодорхойлолт ба параметрүүд;
  • дансны удирдлагын ямар үйлдлүүдийг дэмждэг (хаах, нэрийг өөрчлөх гэх мэт);
  • системийн хэрэглэгчийн танигчийг үүсгэхийн тулд ямар алгоритм эсвэл дүрмийг ашигладаг;
  • боловсон хүчний систем дэх ажилтны бүртгэлтэй холбоо тогтооход ямар шинж чанарыг ашиглаж болох вэ (овог нэр, боловсон хүчний дугаар гэх мэт);
  • дансны боломжит бүх шинж чанарууд, тэдгээрийг бөглөх дүрэм;
  • системд ямар хандалтын эрхүүд байдаг вэ (үүрэг, бүлэг, атомын эрх гэх мэт, үүрлэсэн эсвэл шаталсан эрхүүд байгаа эсэх);
  • нэвтрэх эрхийг хуваах механизм (албан тушаал, хэлтэс, үйл ажиллагаа гэх мэт);
  • Системд эрхийг тусгаарлах дүрэм (SOD – Segregation of Duties) байгаа эсэх, тэдгээр нь хэрхэн ажилладаг вэ;
  • Ажилгүй байх, шилжүүлэх, ажлаас халах, ажилтны мэдээллийг шинэчлэх гэх мэт үйл явдлуудыг системд хэрхэн боловсруулдаг.

Хандалтыг хянах үйл явцад оролцдог янз бүрийн параметрүүд болон бусад объектуудыг нарийвчлан харуулсан энэ жагсаалтыг үргэлжлүүлж болно.

Алхам 5. Зөвшөөрлийн бизнест чиглэсэн тайлбарыг үүсгэ

Үлгэр жишээг бий болгоход бидэнд хэрэгтэй өөр нэг баримт бичиг бол мэдээллийн системийн хэрэглэгчдэд олгож болох бүх эрх мэдлийн (эрх) лавлах ном бөгөөд үүний цаана байгаа бизнесийн чиг үүргийн нарийвчилсан тайлбар юм. Ихэнхдээ систем дэх эрх баригчид үсэг, тооноос бүрдсэн тодорхой нэрээр шифрлэгдсэн байдаг бөгөөд бизнесийн ажилтнууд эдгээр тэмдгийн ард юу байгааг олж мэддэггүй. Дараа нь тэд мэдээллийн технологийн үйлчилгээнд очиж, тэнд ... тэд бас ховор хэрэглэгддэг эрхийн тухай асуултанд хариулж чадахгүй. Дараа нь нэмэлт шалгалт хийх шаардлагатай.

Бизнесийн тодорхойлолт аль хэдийн байгаа эсвэл эдгээр эрхийг бүлэг, үүрэг болгон хослуулсан бол сайн. Зарим хэрэглээний хувьд хамгийн сайн туршлага бол хөгжлийн үе шатанд ийм лавлагаа үүсгэх явдал юм. Гэхдээ энэ нь тийм ч их тохиолддоггүй тул бид дахин мэдээллийн технологийн хэлтэст очиж бүх боломжит эрхийн талаар мэдээлэл цуглуулж, тэдгээрийг тайлбарладаг. Бидний гарын авлага эцэст нь дараахь зүйлийг агуулна.

  • эрх бүхий байгууллагын нэр, үүнд нэвтрэх эрх хамаарах объект;
  • объекттой хийхийг зөвшөөрсөн үйлдэл (харах, өөрчлөх гэх мэт, хязгаарлах боломж, жишээлбэл, нутаг дэвсгэрийн хувьд эсвэл үйлчлүүлэгчдийн бүлэг);
  • зөвшөөрлийн код (зөвшөөрлийг ашиглан гүйцэтгэж болох системийн функц/хүсэлтийн код ба нэр);
  • эрх мэдлийн тодорхойлолт (эрх мэдлийг ашиглах үед IS дахь үйл ажиллагааны нарийвчилсан тайлбар, тэдгээрийн үйл явцад үзүүлэх үр дагавар;
  • зөвшөөрлийн төлөв: "Идэвхтэй" (зөвшөөрлийг дор хаяж нэг хэрэглэгчдэд олгосон бол) эсвэл "Идэвхгүй" (зөвшөөрөл ашиглагдаагүй бол).

Алхам 6 Бид системээс хэрэглэгчид болон эрхийн талаарх мэдээллийг татаж аваад боловсон хүчний эх сурвалжтай харьцуулдаг

Бэлтгэл ажлын эцсийн шатанд та бүх хэрэглэгчид болон тэдний одоо байгаа эрхийн талаарх мэдээллийн системээс өгөгдлийг татаж авах хэрэгтэй. Энд хоёр боломжит хувилбар байна. Нэгдүгээрт: Аюулгүй байдлын хэлтэс нь системд шууд нэвтрэх боломжтой бөгөөд холбогдох тайлангуудыг татаж авах боломжтой бөгөөд энэ нь байнга тохиолддоггүй, гэхдээ маш тохиромжтой. Хоёрдугаарт: Бид шаардлагатай форматаар тайлан хүлээн авах хүсэлтийг МТ-д илгээдэг. Туршлагаас харахад МТ-тэй тохиролцож, шаардлагатай өгөгдлийг анх удаа олж авах боломжгүй юм. Мэдээллийг хүссэн хэлбэр, хэлбэрээр хүлээн авах хүртэл хэд хэдэн арга барилыг хийх шаардлагатай.

Ямар өгөгдлийг татаж авах шаардлагатай вэ:

  • Дансны нэр
  • Томилогдсон ажилтны овог нэр
  • Статус (идэвхтэй эсвэл блоклогдсон)
  • Данс үүсгэсэн огноо
  • Хамгийн сүүлд ашигласан огноо
  • Боломжтой эрх/бүлэг/үүргийн жагсаалт

Тиймээс бид бүх хэрэглэгчид болон тэдэнд олгосон бүх эрхийг системээс татаж авсан. Үлгэр жишээг бий болгох ажлыг зөвхөн идэвхтэй хэрэглэгчдэд л хийх тул тэд хаагдсан бүх дансаа нэн даруй хойшлуулав.

Дараа нь, хэрэв танай компани халагдсан ажилчдын хандалтыг хаах автомат хэрэгсэлгүй (энэ нь ихэвчлэн тохиолддог) эсвэл үргэлж зөв ажилладаггүй засварын автоматжуулалттай бол та бүх "үхсэн сүнснүүдийг" тодорхойлох хэрэгтэй. Бид аль хэдийн ажлаас халагдсан, эрх нь ямар нэг шалтгаанаар хаагдаагүй байгаа ажилчдын дансны тухай ярьж байна - тэдгээрийг хаах шаардлагатай байна. Үүнийг хийхийн тулд бид байршуулсан өгөгдлийг боловсон хүчний эх сурвалжтай харьцуулдаг. Ажилтныг буулгах ажлыг боловсон хүчний мэдээллийн санг хөтлөх хэлтсээс урьдчилан авах ёстой.

Эзэмшигч нь боловсон хүчний мэдээллийн санд олдоогүй, хэнд ч хуваарилагдаагүй, өөрөөр хэлбэл эзэнгүй дансуудыг тусад нь хасах шаардлагатай. Энэ жагсаалтыг ашигласнаар бид хамгийн сүүлд ашигласан огноо хэрэгтэй болно: хэрэв энэ нь саяхан бол бид эзэмшигчийг хайх хэрэгтэй болно. Үүнд гадны гэрээлэгчийн дансууд эсвэл хэн нэгэнд хуваарилагдаагүй боловч аливаа үйл явцтай холбоотой үйлчилгээний дансууд багтаж болно. Дансууд хэнийх болохыг мэдэхийн тулд бүх хэлтэст хариу өгөхийг хүссэн захидал илгээж болно. Эзэмшигч олдох үед бид тэдгээрийн талаарх мэдээллийг системд оруулдаг: ийм байдлаар бүх идэвхтэй дансуудыг тодорхойлж, үлдсэнийг нь блоклодог.

Бидний байршуулсан бичлэгүүд шаардлагагүй бүртгэлээс цэвэрлэгдэж, зөвхөн идэвхтэй бүртгэлүүд үлдмэгц бид тодорхой мэдээллийн системд үлгэр дуурайллыг бий болгож эхлэх боломжтой. Гэхдээ би энэ талаар дараагийн өгүүллээр танд хэлэх болно.

Зохиогч: Людмила Севастьянова, Solar inRights сурталчилгааны менежер

Эх сурвалж: www.habr.com

сэтгэгдэл нэмэх