Бидэнд 2 код анализатор, 4 динамик туршилтын хэрэгсэл, өөрсдийн гар урлал, 250 скрипт байсан. Энэ бүхэн одоогийн үйл явцад хэрэгтэй биш, гэхдээ DevSecOps-ийг хэрэгжүүлж эхэлмэгц та эцсээ хүртэл явах хэрэгтэй.
. Дүр бүтээгчид: Жастин Ройланд, Дэн Хармон.
SecDevOps гэж юу вэ? DevSecOps-ийн талаар юу хэлэх вэ? Ялгаа нь юу вэ? Хэрэглээний аюулгүй байдал - энэ юу вэ? Яагаад сонгодог арга барил ажиллахгүй байна вэ? Энэ бүх асуултын хариултыг мэддэг Юрий Шабалин нь Сэлэм загасны аюулгүй байдал. Юрий бүх зүйлд нарийвчлан хариулж, програмын аюулгүй байдлын сонгодог загвараас DevSecOps процесс руу шилжихэд тулгарч буй асуудлуудад дүн шинжилгээ хийх болно: аюулгүй хөгжүүлэлтийн процессыг DevOps процесст хэрхэн зөв оруулах, юуг ч эвдэхгүй байх, үндсэн үе шатуудыг хэрхэн даван туулах вэ? Аюулгүй байдлын туршилт, ямар хэрэгслийг ашиглаж болох, тэдгээр нь юугаараа ялгаатай, бэрхшээлээс зайлсхийхийн тулд тэдгээрийг хэрхэн зөв тохируулах талаар.
Илтгэгчийн тухай: Юрий Шабалин - Тус компанид Аюулгүй байдлын ерөнхий архитектор Swordfish аюулгүй байдал. SSDL-ийн хэрэгжилтийг хариуцаж, хэрэглээний шинжилгээний хэрэгслүүдийг нэгдсэн хөгжүүлэлт, туршилтын экосистемд нэгтгэх үүрэгтэй. Мэдээллийн аюулгүй байдлын чиглэлээр 7 жил ажилласан туршлагатай. Альфа-Банк, Сбербанк, Позитив Технологи зэрэг программ хангамж хөгжүүлж, үйлчилгээ үзүүлдэг компаниудад ажиллаж байсан. ZerONights, PHDays, RISSPA, OWASP зэрэг олон улсын бага хуралд илтгэгч.
Хэрэглээний аюулгүй байдал: энэ юуны тухай вэ?
Програмын аюулгүй байдал - Энэ бол програмын аюулгүй байдлыг хариуцдаг хамгаалалтын хэсэг юм. Энэ нь дэд бүтэц, сүлжээний аюулгүй байдалд хамаарахгүй, харин бидний бичсэн зүйл, хөгжүүлэгчид юун дээр ажилладаг зэрэгт хамаарахгүй - эдгээр нь програмын дутагдал, сул тал юм.
Чиглэл - Аюулгүй байдлын хөгжлийн амьдралын мөчлөг - Майкрософт компани боловсруулсан. Диаграмм нь SDLC-ийн каноник загварыг харуулсан бөгөөд гол үүрэг нь шаардлагаас эхлээд гаргах, үйлдвэрлэх хүртэлх хөгжлийн үе шат бүрт аюулгүй байдлын оролцоо юм. Майкрософт энэ салбарт хэтэрхий олон алдаа байгааг, үүнээс илүү олон алдаа байгааг ойлгож, энэ талаар ямар нэг зүйл хийх шаардлагатай байгааг мэдээд тэд энэ аргыг санал болгосноор энэ нь каноник болсон.
Хэрэглээний аюулгүй байдал ба SSDL нь нийтлэг итгэдэг шиг эмзэг байдлыг илрүүлэхэд чиглэгддэггүй, гэхдээ тэдгээрээс урьдчилан сэргийлэхэд чиглэгддэг. Цаг хугацаа өнгөрөхөд Microsoft-ын каноник арга барилыг сайжруулж, хөгжүүлж, илүү гүн гүнзгий, нарийвчилсан шумбалт болгон нэвтрүүлсэн.
Каноник SDLC нь OpenSAMM, BSIMM, OWASP гэсэн янз бүрийн арга зүйд маш нарийн байдаг. Арга зүй нь өөр боловч ерөнхийдөө ижил төстэй байдаг.
Төлөвшсөн үеийн аюулгүй байдлын загвар
Надад хамгийн их таалагддаг BSIMM - . Аргачлалын үндэс нь Хэрэглээний аюулгүй байдлын үйл явцыг засаглал, тагнуул, SSDL холбоо барих цэгүүд болон байршуулалт гэсэн 4 домэйнд хуваах явдал юм. Домэйн бүр 12 үйл ажиллагаа хэлбэрээр илэрхийлэгддэг 112 дадлагатай.
112 үйл ажиллагаа тус бүртэй Төлөвшлийн 3 түвшин: анхан, дунд, гүнзгий шат. Та бүх 12 дадлыг хэсэг тус бүрээр нь судалж, өөрт чухал зүйлүүдийг сонгож, тэдгээрийг хэрхэн хэрэгжүүлэхээ олж мэдээд аажмаар статик болон динамик кодын дүн шинжилгээ хийх эсвэл кодын хянан үзэх зэрэг элементүүдийг нэмж болно. Сонгосон үйл ажиллагааны хэрэгжилтийн нэг хэсэг болгон төлөвлөгөөгөө бичиж, түүний дагуу тайван ажиллана.
Яагаад DevSecOps
DevOps бол аюулгүй байдлыг харгалзан үзэх ёстой ерөнхий, том процесс юм.
Эхлээд аюулгүй байдлын шалгалтыг хамарсан. Практикт аюулгүй байдлын багуудын тоо одоогийнхоос хамаагүй цөөхөн байсан бөгөөд тэд үйл явцад оролцогч биш, харин түүнд шаардлага тавьж, бүтээгдэхүүнийхээ чанарыг гаргасны эцэст шалгадаг хяналт, хяналтын байгууллагын үүрэг гүйцэтгэдэг байв. Энэ бол хамгаалалтын багууд бүтээн байгуулалтаас хананы ард байсан бөгөөд үйл явцад оролцоогүй сонгодог арга юм.
Хамгийн гол асуудал бол мэдээллийн аюулгүй байдал хөгжлөөс тусдаа байгаа явдал юм. Ихэнхдээ энэ нь мэдээллийн аюулгүй байдлын нэг төрлийн хэлхээ бөгөөд үүнд 2-3 том, үнэтэй хэрэгсэл байдаг. Зургаан сар тутамд нэг удаа шалгах шаардлагатай эх код эсвэл программ нь ирдэг бөгөөд жилд нэг удаа гаргадаг . Энэ бүхэн нь уг салбарыг гаргах огноо хойшлогдож, хөгжүүлэгч автоматжуулсан хэрэгслээс асар олон тооны эмзэг байдалд өртөхөд хүргэдэг. Энэ бүгдийг задлах, засварлах боломжгүй, учир нь өмнөх зургаан сарын үр дүн нь цэгцлэгдээгүй, харин энд шинэ багц байна.
Манай компанийн ажлын явцад бид бүх салбар, салбарын аюулгүй байдал нэгэн дугуйн дээр хөгжлийг гүйцэж, эргэх цаг болсныг ойлгож байгааг бид харж байна. . DevSecOps парадигм нь agile хөгжүүлэлтийн арга зүй, хэрэгжилт, дэмжлэг, хувилбар болон давталт бүрт оролцоход төгс нийцдэг.
DevSecOps руу шилжих
Аюулгүй байдлын хөгжлийн амьдралын мөчлөгийн хамгийн чухал үг бол "процесс". Та багаж хэрэгсэл худалдаж авах талаар бодохоосоо өмнө үүнийг ойлгох хэрэгтэй.
DevOps процесст зүгээр л хэрэгслүүдийг оруулах нь хангалтгүй - процессын оролцогчдын хоорондын харилцаа холбоо, ойлголт чухал.
Хүмүүс илүү чухал болохоос хэрэгсэл биш.
Ихэнхдээ аюулгүй хөгжүүлэлтийн үйл явцыг төлөвлөх нь багажийг сонгох, худалдан авахаас эхэлж, тухайн хэрэгслийг одоогийн үйл явцад нэгтгэх оролдлогогоор төгсдөг бөгөөд энэ нь оролдлого хэвээр үлддэг. Энэ нь харамсалтай үр дагаварт хүргэдэг, учир нь бүх хэрэгсэл нь өөрийн онцлог шинж чанар, хязгаарлалттай байдаг.
Аюулгүй байдлын хэлтэс нь өргөн боломж бүхий сайн, үнэтэй хэрэгслийг сонгож, түүнийг үйл явцад нэгтгэхийн тулд хөгжүүлэгчид дээр ирдэг нийтлэг тохиолдол юм. Гэхдээ энэ нь ажиллахгүй байна - үйл явц нь аль хэдийн худалдаж авсан хэрэгслийн хязгаарлалт нь одоогийн парадигмд тохирохгүй байхаар зохион байгуулагдсан.
Юуны өмнө та ямар үр дүнд хүрэхийг хүсч байгаагаа, мөн үйл явц ямар байхыг тайлбарла. Энэ нь үйл явц дахь багаж хэрэгсэл, аюулгүй байдлын үүргийг ойлгоход тусална.
Аль хэдийн ашиглагдаж байгаа зүйлээс эхэл
Үнэтэй хэрэгсэл худалдаж авахаасаа өмнө өөрт байгаа зүйлээ хараарай. Компани бүр хөгжүүлэхэд аюулгүй байдлын шаардлага тавьдаг, шалгалтууд, шалгалтууд байдаг - яагаад энэ бүгдийг хүн бүрт ойлгомжтой, тохиромжтой хэлбэр болгон хувиргаж болохгүй гэж?
Ихэвчлэн шаардлага нь тавиур дээр хэвтэж буй цаасан Талмуд юм. Бид нэг компанид ирж үйл явцтай танилцаж, программ хангамжийн аюулгүй байдлын шаардлагыг харахыг хүссэн тохиолдол гарсан. Үүнийг шийдсэн мэргэжилтэн удаан хугацааны туршид дараахь зүйлийг хайж байсан.
-Одоо тэмдэглэлийн хаа нэгтээ энэ баримт бичиг байгаа зам байсан.
Үүний үр дүнд бид долоо хоногийн дараа баримт бичгийг хүлээн авсан.
Шаардлага, шалгалт болон бусад зүйлсийн хувьд жишээ нь: Баярлалаа - энэ нь хүн бүрт тохиромжтой.
Өөрт байгаа зүйлээ дахин форматлаж, эхлүүлэхийн тулд ашиглах нь илүү хялбар байдаг.
Хамгаалалтын аваргуудыг ашигла
Ерөнхийдөө 100-200 хөгжүүлэгчтэй дундаж компанид хэд хэдэн функцийг гүйцэтгэдэг аюулгүй байдлын нэг мэргэжилтэн байдаг бөгөөд бүх зүйлийг шалгах цаг зав байдаггүй. Тэр чадах чинээгээрээ оролдсон ч тэр ганцаараа хөгжүүлэлтийн үүсгэсэн бүх кодыг шалгахгүй. Ийм тохиолдлын хувьд үзэл баримтлал боловсруулсан - .
Аюулгүй байдлын аваргууд нь таны бүтээгдэхүүний аюулгүй байдлыг сонирхож буй хөгжүүлэлтийн багийн хүмүүс юм.
Аюулгүй байдлын аварга бол хөгжүүлэлтийн багт орох цэг бөгөөд аюулгүй байдлын сайн мэдээг түгээгч нэг хэсэг юм.
Ихэвчлэн хамгаалалтын мэргэжилтэн хөгжүүлэлтийн баг дээр ирээд кодонд алдаа гарсныг зааж өгөхөд тэрээр гайхсан хариултыг авдаг.
- Харин чи хэн бэ? Би чамайг анх удаа харж байна. Надад бүх зүйл сайхан байна - ахлах найз маань кодыг шалгахдаа надад "хэрэглээ" өгсөн тул бид цааш явна!
Энэ бол ердийн нөхцөл байдал, учир нь хөгжүүлэгч нь ажил дээрээ байнга харилцаж, кодыг хянаж байдаг ахмад настнууд эсвэл зүгээр л багийн найзуудад илүү их итгэдэг. Хэрэв хамгаалалтын ажилтны оронд Аюулгүй байдлын аварга алдаа, үр дагаврыг зааж өгвөл түүний үг илүү жинтэй байх болно.
Түүнчлэн хөгжүүлэгчид өөрсдийн кодыг ямар ч аюулгүй байдлын мэргэжилтнүүдээс илүү сайн мэддэг. Статик шинжилгээний хэрэгсэлд дор хаяж 5 төсөлтэй хүний хувьд бүх нарийн ширийн зүйлийг санах нь ихэвчлэн хэцүү байдаг. Аюулгүй байдлын аваргууд бүтээгдэхүүнээ мэддэг: юу нь юутай харьцаж, юуг хамгийн түрүүнд анхаарч үзэх нь илүү үр дүнтэй байдаг.
Тиймээс Аюулгүй байдлын аваргуудыг хэрэгжүүлж, хамгаалалтын багийнхаа нөлөөг өргөжүүлэх талаар бодож үзээрэй. Энэ нь аваргын хувьд ч ашигтай: шинэ чиглэлээр мэргэшүүлэх, техникийн алсын хараагаа өргөжүүлэх, техник, менежмент, манлайллын ур чадварыг дээшлүүлэх, зах зээлийн үнэ цэнийг нэмэгдүүлэх. Энэ бол нийгмийн инженерчлэлийн зарим нэг хэсэг, таны хөгжлийн баг дахь "нүд" юм.
Туршилтын үе шатууд
Хүчин чармайлтын 20% нь үр дүнгийн 80% өгдөг гэж хэлдэг. Энэ 20% нь автоматжуулж болох, хийх ёстой хэрэглээний шинжилгээний практикууд юм. Ийм үйл ажиллагааны жишээ бол статик шинжилгээ юм. SAST, динамик шинжилгээ - DAST и Нээлттэй эхийн хяналт. Үйл ажиллагаа, багаж хэрэгслийн талаар, тэдгээрийг үйл явцад нэвтрүүлэхэд ихэвчлэн ямар онцлог шинж чанаруудтай тулгардаг, үүнийг хэрхэн зөв хийх талаар би танд илүү дэлгэрэнгүй ярих болно.
Хэрэгслийн гол бэрхшээлүүд
Би бүх хэрэгсэлд хамааралтай, анхаарал хандуулах шаардлагатай асуудлуудыг тодруулах болно. Цаашид давтахгүйн тулд би тэдгээрийг илүү нарийвчлан шинжлэх болно.
Шинжилгээний урт хугацаа. Хэрэв амлалт өгснөөс хойш бүх туршилт, угсралтад 30 минут шаардлагатай бол мэдээллийн аюулгүй байдлын шалгалт нэг өдөр болно. Тиймээс хэн ч үйл явцыг удаашруулахгүй. Энэ онцлогийг харгалзан үзээд дүгнэлт гарга.
Өндөр түвшний худал сөрөг эсвэл худал эерэг. Бүх бүтээгдэхүүн өөр өөр, бүгд өөр өөр хүрээ, өөрийн кодчилолын хэв маягийг ашигладаг. Өөр өөр кодын бааз, технологид хэрэгслүүд нь худал сөрөг, худал эерэг гэсэн янз бүрийн түвшнийг харуулж болно. Тэгэхээр яг юу байгааг хараарай таны компаниуд болон төлөө чиний програмууд нь сайн, найдвартай үр дүнг харуулах болно.
Одоо байгаа хэрэгслүүдтэй нэгдмэл байхгүй. Хэрэгслийг аль хэдийн ашигласан зүйлтэйгээ нэгтгэх үүднээс хараарай. Жишээлбэл, хэрэв танд Jenkins эсвэл TeamCity байгаа бол ашигладаггүй GitLab CI-тэй биш, харин энэ программ хангамжтай хэрэгслүүдийг нэгтгэсэн эсэхийг шалгаарай.
Тохируулгын дутагдал эсвэл хэт нарийн төвөгтэй байдал. Хэрэв хэрэгсэлд API байхгүй бол яагаад хэрэгтэй байна вэ? Интерфэйс дээр хийж болох бүх зүйл API-ээр дамжуулан боломжтой байх ёстой. Хамгийн тохиромжтой нь хэрэгсэл нь чекийг тохируулах чадвартай байх ёстой.
Бүтээгдэхүүн хөгжүүлэх замын зураг байхгүй. Хөгжил зогсохгүй, бид үргэлж шинэ хүрээ, функцуудыг ашиглаж, хуучин кодыг шинэ хэл рүү дахин бичиж байна. Бидний худалдаж авсан хэрэгсэл нь шинэ хүрээ, технологийг дэмжинэ гэдэгт итгэлтэй байхыг хүсч байна. Тиймээс бүтээгдэхүүн нь жинхэнэ бөгөөд зөв гэдгийг мэдэх нь чухал юм хөгжил.
Процессийн онцлогууд
Хэрэгслийн онцлогоос гадна хөгжлийн үйл явцын онцлогийг анхаарч үзээрэй. Жишээлбэл, хөгжилд саад учруулах нь нийтлэг алдаа юм. Өөр ямар онцлогийг анхаарч үзэх, хамгаалалтын баг юуг анхаарах ёстойг харцгаая.
Хөгжүүлэх, гаргах эцсийн хугацааг алдахгүйн тулд үүсгээрэй өөр өөр дүрэм мөн өөр таглааг харуулах - эмзэг байдал байгаа тохиолдолд барилгын үйл явцыг зогсоох шалгуурууд - өөр өөр орчинд зориулагдсан. Жишээлбэл, одоогийн салбар нь хөгжлийн стенд эсвэл УАТ руу явдаг гэдгийг бид ойлгож байгаа бөгөөд энэ нь бид зогсоод байдаггүй гэсэн үг юм:
"Энд танд эмзэг байгаа тул та цааш хаашаа ч явахгүй!"
Энэ үед хөгжүүлэгчдэд анхаарах шаардлагатай аюулгүй байдлын асуудлууд байгааг хэлэх нь чухал юм.
Эмзэг байдал байгаа нь цаашдын туршилтанд саад болохгүй: гарын авлага, нэгтгэх эсвэл гарын авлага. Нөгөө талаас, бид ямар нэгэн байдлаар бүтээгдэхүүний аюулгүй байдлыг нэмэгдүүлэх хэрэгтэй бөгөөд ингэснээр хөгжүүлэгчид аюулгүй гэж үзсэн зүйлээ үл тоомсорлохгүй байх ёстой. Тиймээс, заримдаа бид үүнийг хийдэг: стенд дээр, үүнийг хөгжлийн орчинд нэвтрүүлэх үед бид зөвхөн хөгжлийг мэдэгддэг.
- Залуус аа, та нарт асуудал тулгараад байгаа тул анхаарлаа хандуулаарай.
UAT үе шатанд бид эмзэг байдлын талаар дахин сэрэмжлүүлэг үзүүлж, суллах үе шатанд бид дараахь зүйлийг хэлдэг.
- Залуус аа, бид та нарт хэд хэдэн удаа анхааруулсан, та юу ч хийгээгүй - бид чамайг үүн дээр гаргахгүй.
Хэрэв бид код, динамикийн талаар ярих юм бол зөвхөн энэ функцэд саяхан бичигдсэн функцууд болон кодын эмзэг байдлыг харуулж, анхааруулах шаардлагатай. Хэрэв хөгжүүлэгч товчлуурыг 3 пикселээр хөдөлгөхөд бид түүнд SQL тарилга байгаа тул яаралтай засах шаардлагатай гэж хэлвэл энэ нь буруу юм. Зөвхөн одоо бичигдсэн зүйл болон өргөдөлд ирэх өөрчлөлтийг хараарай.
Бидэнд тодорхой үйл ажиллагааны доголдол байгаа гэж бодъё - програм ажиллахгүй байх ёстой: мөнгө шилжүүлэхгүй, товчлуур дээр дарахад дараагийн хуудас руу шилжихгүй, эсвэл бүтээгдэхүүн ачаалахгүй байна. Аюулгүй байдлын согогууд - эдгээр нь ижил согогууд боловч хэрэглээний үйл ажиллагааны хувьд биш, харин аюулгүй байдлын хувьд.
Програм хангамжийн чанарын асуудал бүр аюулгүй байдлын асуудал биш юм. Гэхдээ аюулгүй байдлын бүх асуудал програм хангамжийн чанартай холбоотой байдаг. Шериф Мансур, Экспедиа.
Бүх эмзэг байдал нь ижил согогтой тул тэдгээр нь хөгжлийн бүх согогтой ижил газарт байрлах ёстой. Тиймээс хэн ч уншдаггүй тайлан, аймшигтай PDF файлуудыг мартаж болохгүй.
Би хөгжлийн компанид ажиллаж байхдаа статик шинжилгээний хэрэгслүүдээс тайлан хүлээн авсан. Би онгойлгоод, айж, кофе чанаж, 350 хуудсыг гүйлгэж, хаагаад ажлаа үргэлжлүүлэв. Том мэдээллүүд бол үхсэн мэдээ юм. Ихэвчлэн тэд хаашаа ч явдаггүй, үсэг устгагдсан, мартагдсан, алдагдсан, эсвэл бизнес эрсдэлийг хүлээн зөвшөөрсөн гэж хэлдэг.
Юу хийх вэ? Бид зүгээр л олсон батлагдсан согогуудыг хөгжүүлэхэд тохиромжтой хэлбэр болгон хувиргадаг, жишээлбэл, Жира дахь хоцрогдолд оруулдаг. Бид согогийг эрэмбэлж, үйл ажиллагааны доголдол, туршилтын согогуудын хамт тэргүүлэх дарааллаар нь арилгадаг.
Статик шинжилгээ - SAST
Энэ бол эмзэг байдлын кодын шинжилгээ юм., гэхдээ энэ нь SonarQube-тэй адил биш юм. Бид зөвхөн загвар, хэв маягийг шалгадаггүй. Шинжилгээнд хэд хэдэн аргыг ашигладаг: эмзэг байдлын модны дагуу, дагуу , тохиргооны файлуудад дүн шинжилгээ хийх замаар. Энэ бол кодтой холбоотой бүх зүйл юм.
Аргын давуу тал: хөгжлийн эхний шатанд кодын эмзэг байдлыг тодорхойлоххараахан зогсоол болон бэлэн багаж байхгүй үед, мөн нэмэлт скан хийх чадвар: өөрчлөгдсөн кодын хэсэг, зөвхөн бидний хийж байгаа функцийг сканнердах нь скан хийх хугацааг багасгадаг.
Минусы - энэ нь шаардлагатай хэлийг дэмжихгүй байгаа явдал юм.
Шаардлагатай интеграци, хэрэгсэлд байх ёстой, миний субъектив бодлоор:
- Интеграцийн хэрэгсэл: Женкинс, TeamCity болон Gitlab CI.
- Хөгжлийн орчин: Intellij IDEA, Visual Studio. Хөгжүүлэгчийн хувьд цээжлэх шаардлагатай байгаа ойлгомжгүй интерфэйсийг чиглүүлэх биш, харин ажлын байран дээрээ олсон бүх шаардлагатай интеграци, эмзэг байдлыг өөрийн хөгжлийн орчинд харах нь илүү тохиромжтой.
- Кодын шалгалт: SonarQube болон гарын авлагын хяналт.
- Согог илрүүлэгч: Жира, Бугзилла.
Зураг дээр статик анализын шилдэг төлөөлөгчдийг харуулав.
Хэрэгсэл нь чухал биш, харин үйл явц нь чухал учраас үйл явцыг шалгахад тохиромжтой Нээлттэй эхийн шийдлүүд байдаг.
SAST Open Source нь асар олон тооны эмзэг байдал эсвэл нарийн төвөгтэй DataFlows-ийг олохгүй, гэхдээ тэдгээрийг процесс үүсгэх үед ашиглах боломжтой бөгөөд ашиглах ёстой. Эдгээр нь үйл явц хэрхэн бүтээгдэх, алдаануудад хэн хариу өгөх, хэн мэдээлэх, хэн мэдээлэхийг ойлгоход тусалдаг. Хэрэв та кодын аюулгүй байдлыг хангах эхний үе шатыг хэрэгжүүлэхийг хүсвэл Нээлттэй эхийн шийдлүүдийг ашиглаарай.
Хэрэв та аяллынхаа эхэнд байгаа бөгөөд юу ч байхгүй: CI, Женкинс, TeamCity байхгүй бол үүнийг хэрхэн нэгтгэх вэ? Процесст нэгтгэх талаар авч үзье.
CVS түвшний интеграци
Хэрэв танд Bitbucket эсвэл GitLab байгаа бол та түвшинд нэгтгэх боломжтой .
Үйл явдлын дагуу - хүсэлтийг татах, гүйцэтгэх. Та кодыг сканнердах ба бүтээх төлөв нь аюулгүй байдлын шалгалтад тэнцсэн эсвэл амжилтгүй болсон эсэхийг харуулдаг.
Санал хүсэлт. Мэдээжийн хэрэг, санал хүсэлт үргэлж шаардлагатай байдаг. Хэрэв та зүгээр л хажуу талд нь хамгаалалт хийсэн бол хайрцагт хийж, энэ талаар хэнд ч хэлээгүй, дараа нь сарын сүүлээр олон тооны алдаа гаргасан бол энэ нь буруу бөгөөд сайн биш юм.
Код хянах системтэй нэгтгэх
Нэгэн удаа бид хэд хэдэн чухал төслүүдэд техникийн AppSec хэрэглэгчийн хувьд анхдагч хянагчаар ажилласан. Шинэ кодонд алдаа илэрсэн эсвэл ямар ч алдаа байхгүй эсэхээс хамаарч хянагч татах хүсэлтийн статусыг "хүлээн авах" эсвэл "ажил хэрэгтэй" гэж тохируулна - эсвэл бүх зүйл хэвийн байна, эсвэл яг юуг сайжруулах шаардлагатай байгаа холбоосууд байна. сайжруулах шаардлагатай байна. Үйлдвэрлэлд орж буй хувилбартай нэгтгэхийн тулд мэдээллийн аюулгүй байдлын шалгалтад тэнцээгүй тохиолдолд нэгтгэх хоригийг идэвхжүүлсэн. Бид үүнийг гарын авлагын кодын шалгалтанд оруулсан бөгөөд бусад оролцогчид энэ процессын аюулгүй байдлын статусыг харсан.
SonarQube-тэй нэгтгэх
Олон кодын чанарын хувьд. Энд ч мөн адил - та зөвхөн SAST хэрэгслүүдэд ижил хаалгыг хийж болно. Ижил интерфейс, ижил чанарын хаалга байх болно, зөвхөн үүнийг дуудах болно хамгаалалтын хаалга. Мөн түүнчлэн, хэрэв танд SonarQube ашиглан үйл явц байгаа бол тэнд бүх зүйлийг хялбархан нэгтгэж болно.
CI түвшинд нэгтгэх
Энд бүх зүйл маш энгийн:
- Автомат тесттэй ижил түвшинд байна, нэгжийн туршилтууд.
- Хөгжлийн үе шатаар хуваах: хөгжүүлэлт, туршилт, бүтээгдэхүүн. Өөр өөр дүрмийн багц эсвэл бүтэлгүйтлийн өөр нөхцөл байж болно: угсралтыг зогсоо, угсралтыг бүү зогсоо.
- Синхрон/асинхрон хөөргөх. Аюулгүй байдлын туршилтууд дуусахыг хүлээж байна уу үгүй юу. Өөрөөр хэлбэл, бид зүгээр л эхлүүлээд цаашаа явж, дараа нь бүх зүйл сайн эсвэл муу гэсэн статусыг авдаг.
Энэ бүхэн төгс ягаан ертөнцөд байдаг. Бодит амьдрал дээр тийм зүйл байхгүй, гэхдээ бид зүтгэдэг. Аюулгүй байдлын шалгалтын үр дүн нь нэгжийн туршилтын үр дүнтэй төстэй байх ёстой.
Жишээлбэл, бид том төсөл авч, одоо үүнийг SAST - OK ашиглан сканнердах болно гэж шийдсэн. Бид энэ төслийг SAST руу түлхэж, энэ нь бидэнд 20 эмзэг байдлыг өгсөн бөгөөд хүчтэй шийдвэрээр бид бүх зүйл сайхан байна гэж шийдсэн. 000 сул тал бол бидний техникийн өр юм. Бид өрийг хайрцагт хийж, аажмаар арилгаж, мөрдөгчийг согогтой болгохын тулд алдаануудыг нэмнэ. Компани хөлсөлж, бүх зүйлийг өөрсдөө хийцгээе, эсвэл Аюулгүй байдлын аваргууд бидэнд тусалъя - тэгвэл техникийн өр багасах болно.
Мөн шинэ кодын шинээр гарч ирж буй бүх эмзэг байдлыг нэгж эсвэл автомат туршилтын алдаатай адил арилгах ёстой. Харьцангуй, чуулган эхэлсэн, бид үүнийг ажиллуулж, хоёр туршилт, хоёр аюулгүй байдлын туршилт амжилтгүй болсон. За - бид явлаа, юу болсныг харлаа, нэг зүйлийг зассан, өөр нэг зүйлийг зассан, дараагийн удаа ажиллуулсан - бүх зүйл зүгээр байсан, ямар ч шинэ сул тал гарч ирээгүй, ямар ч туршилт амжилтгүй болсон. Хэрэв энэ ажил илүү гүнзгий бөгөөд та үүнийг сайн ойлгох шаардлагатай бол, эсвэл эмзэг байдлыг засах нь бүрээсний доор байгаа бүх давхаргад нөлөөлдөг: согог илрүүлэгч дээр алдаа нэмэгдсэн тул үүнийг эрэмбэлэн засаж залруулна. Харамсалтай нь дэлхий төгс биш бөгөөд туршилтууд заримдаа бүтэлгүйтдэг.
Аюулгүй байдлын хаалганы жишээ бол код дахь эмзэг байдлын тоо, тоогоор чанарын хаалганы аналог юм.
Бид SonarQube-тэй нэгтгэдэг - залгаасыг суулгасан, бүх зүйл маш тохиромжтой, сайхан байна.
Хөгжлийн орчинтой нэгтгэх
Интеграцийн сонголтууд:
- Үйлдэл хийхээсээ өмнө хөгжүүлэлтийн орчноос скан хийж байна.
- Үр дүнг харах.
- Үр дүнгийн шинжилгээ.
- Сервертэй синхрончлол.
Серверээс илэрц хүлээн авах нь иймэрхүү харагдаж байна.
Манай хөгжлийн орчинд Скан хийх явцад ийм эмзэг байдал илэрсэн тухай танд мэдэгдэх нэмэлт зүйл гарч ирнэ. Та кодыг нэн даруй засварлаж, зөвлөмжийг үзэх боломжтой . Энэ бүхэн хөгжүүлэгчийн ажлын байранд байрладаг бөгөөд энэ нь маш тохиромжтой - бусад холбоосыг дагаж, нэмэлт зүйл хайх шаардлагагүй.
Нээлттэй эх
Энэ бол миний хамгийн дуртай сэдэв. Хүн бүр Нээлттэй эхийн номын санг ашигладаг - бүх зүйл аль хэдийн хэрэгжсэн бэлэн номын санг авч байхад яагаад олон таяг, унадаг дугуй бичих хэрэгтэй вэ?
Мэдээжийн хэрэг, энэ нь үнэн, гэхдээ номын санг хүмүүс бас бичдэг, тэдгээрт тодорхой эрсдэлүүд багтдаг бөгөөд үе үе эсвэл байнга мэдээлж байдаг эмзэг талууд байдаг. Тиймээс, програмын аюулгүй байдлын дараагийн алхам байдаг - энэ бол Нээлттэй эхийн бүрэлдэхүүн хэсгүүдийн дүн шинжилгээ юм.
Нээлттэй эхийн шинжилгээ - OSA
Энэхүү хэрэгсэл нь гурван том үе шатыг агуулдаг.
Номын сангаас сул талыг хайж байна. Жишээлбэл, уг хэрэгсэл нь бид ямар нэгэн номын сан ашиглаж байгааг мэддэг эсвэл номын сангийн энэ хувилбартай холбоотой алдаа хянагчдад зарим нэг сул тал бий. Та үүнийг ашиглахыг оролдох үед уг хэрэгсэл нь номын сан эмзэг байгааг анхааруулж, сул талгүй өөр хувилбарыг ашиглахыг танд зөвлөж байна.
Лицензийн цэвэр байдлын шинжилгээ. Энэ нь одоогоор тийм ч түгээмэл биш байгаа ч хэрэв та гадаадад ажилладаг бол ашиглах, өөрчлөх боломжгүй нээлттэй эхийн бүрэлдэхүүнийг ашигласны төлөө хааяа татвар авах боломжтой. Тусгай зөвшөөрөлтэй номын сангийн бодлогын дагуу бид үүнийг хийх боломжгүй. Эсвэл хэрэв бид үүнийг өөрчилсөн, ашиглавал кодоо байршуулах ёстой. Мэдээжийн хэрэг, хэн ч бүтээгдэхүүнийхээ кодыг нийтлэхийг хүсэхгүй байгаа ч та үүнээс өөрийгөө хамгаалах боломжтой.
Үйлдвэрлэлийн орчинд ашиглагдаж буй бүрэлдэхүүн хэсгүүдийн шинжилгээ. Бид эцэст нь хөгжүүлэлтийг дуусгаж, микро үйлчилгээнийхээ хамгийн сүүлийн хувилбарыг гаргасан гэсэн таамаглалтай нөхцөл байдлыг төсөөлөөд үз дээ. Тэр тэнд гайхалтай амьдардаг - долоо хоног, сар, жил. Бид үүнийг цуглуулдаггүй, аюулгүй байдлын шалгалт хийдэггүй, бүх зүйл зүгээр юм шиг байна. Гэвч гэнэт гарснаас хойш хоёр долоо хоногийн дараа үйлдвэрлэлийн орчинд бидний энэ бүтээн байгуулалтад ашигладаг Нээлттэй эхийн бүрэлдэхүүн хэсэгт чухал эмзэг байдал гарч ирэв. Хэрэв бид хаана, юу ашиглаж байгаагаа тэмдэглээгүй бол энэ эмзэг байдлыг олж харахгүй. Зарим хэрэгслүүд нь одоогоор салбарт ашиглагдаж байгаа номын сангуудын эмзэг байдлыг хянах чадвартай байдаг. Энэ нь маш ашигтай юм.
Онцлог шинжүүд:
- Хөгжлийн янз бүрийн үе шатанд өөр өөр бодлого.
- Аж үйлдвэрийн орчинд бүрэлдэхүүн хэсгүүдийг хянах.
- Байгууллага доторх номын сангуудад хяналт тавих.
- Төрөл бүрийн бүтээх систем, хэлийг дэмжих.
- Docker зургийн дүн шинжилгээ.
Нээлттэй эх сурвалжийн шинжилгээ хийдэг салбарын удирдагчдын цөөн хэдэн жишээ.
Үнэгүй цорын ганц нь энэ юм OWASP-аас. Та үүнийг эхний үе шатанд асааж, хэрхэн ажилладаг, юуг дэмждэгийг харах боломжтой. Үндсэндээ эдгээр нь бүгд үүлэн бүтээгдэхүүн юм уу, эсвэл газар дээр нь байдаг, гэхдээ тэдгээрийн суурийн ард интернетэд илгээгдсэн хэвээр байна. Тэд таны номын сангууд биш, харин хэш эсвэл өөрсдийн тооцоолсон утгууд, хурууны хээгээ сервер рүү илгээж, эмзэг байдлын талаарх мэдээллийг авдаг.
Процессын нэгдэл
Номын сангийн периметрийн хяналт, эдгээрийг гадны эх сурвалжаас татаж авдаг. Бид гадаад болон дотоод хадгалах сантай. Жишээлбэл, Event Central нь Nexus-ийг ажиллуулдаг бөгөөд бид "чухал" эсвэл "өндөр" статустай нөөцийн санд ямар ч эмзэг байдал байхгүй байхыг хүсч байна. Та Nexus Firewall Lifecycle хэрэгслийг ашиглан прокси хийх тохиргоог хийж болно, ингэснээр ийм эмзэг байдлыг таслан зогсоож, дотоод репозитор руу орохгүй.
CI-д нэгтгэх. Автотест, нэгжийн туршилт, хөгжлийн үе шатуудад хуваахтай ижил түвшинд: dev, test, prod. Үе шат бүрт та ямар ч номын санг татаж авах, юу ч ашиглаж болно, гэхдээ хэрэв "чухал" статустай хэцүү зүйл байвал үйлдвэрлэлд гаргах шатандаа хөгжүүлэгчдийн анхаарлыг татах нь зүйтэй болов уу.
Олдворуудтай нэгтгэх: Nexus болон JFrog.
Хөгжлийн орчинд нэгтгэх. Таны сонгосон хэрэгслүүд нь хөгжүүлэлтийн орчинтой уялдаа холбоотой байх ёстой. Хөгжүүлэгч нь CVS-д орохоосоо өмнө ажлын байрнаасаа сканнердсан үр дүнд хандах эсвэл кодыг өөрөө сканнердаж, эмзэг байдлыг шалгах чадвартай байх ёстой.
CD нэгтгэх. Энэ бол миний маш их таалагдсан, миний аль хэдийн ярьсан гайхалтай шинж чанар юм - үйлдвэрлэлийн орчинд шинэ эмзэг байдал үүсэхийг хянах. Энэ нь иймэрхүү зүйл ажилладаг.
Бидэнд байгаа Нийтийн бүрэлдэхүүн хэсгүүдийн агуулахууд - гаднах зарим хэрэгсэл, манай дотоод хадгалах газар. Бид үүнийг зөвхөн итгэмжлэгдсэн бүрэлдэхүүн хэсгүүдийг агуулсан байхыг хүсч байна. Хүсэлтийг прокси хийхдээ татаж авсан номын санд сул тал байхгүй эсэхийг шалгадаг. Хэрэв энэ нь бидний тогтоосон тодорхой бодлогод нийцэж, хөгжүүлэлттэй заавал уялддаг бол бид үүнийг байршуулахгүй бөгөөд өөр хувилбарыг ашиглахыг сануулдаг. Үүний дагуу, хэрэв номын санд үнэхээр шүүмжлэлтэй, муу зүйл байвал хөгжүүлэгч нь суулгах шатанд номын санг хүлээн авахгүй - түүнд илүү өндөр эсвэл доод хувилбарыг ашиглахыг зөвшөөрнө үү.
- Барилга барихдаа бид хэн ч муу зүйл гулсаагүй, бүх эд анги нь аюулгүй, флаш диск дээр хэн ч аюултай зүйл авчираагүй эсэхийг шалгадаг.
- Бид репозиторт зөвхөн итгэмжлэгдсэн бүрэлдэхүүн хэсгүүдтэй.
- Байршуулахдаа бид багцыг дахин нэг удаа шалгана: war, jar, DL эсвэл Docker image нь бодлогод нийцэж байгаа эсэхийг шалгана.
- Салбар руу орохдоо бид үйлдвэрлэлийн орчинд юу болж байгааг хянадаг: чухал эмзэг байдал гарч ирдэг эсвэл харагдахгүй байна.
Динамик шинжилгээ - DAST
Динамик шинжилгээний хэрэгслүүд нь өмнө нь хэлж байсан бүх зүйлээс эрс ялгаатай. Энэ нь хэрэглэгчийн програмтай хийсэн ажлыг дуурайлган хийсэн нэг хэлбэр юм. Хэрэв энэ нь вэб програм бол бид үйлчлүүлэгчийн ажлыг дуурайлган хүсэлт илгээж, урд талын товчлуурууд дээр дарж, маягтаас хиймэл өгөгдөл илгээдэг: хашилт, хаалт, өөр өөр кодчилол дахь тэмдэгтүүд, програм хэрхэн ажиллаж, боловсруулагдаж байгааг харах. гадаад өгөгдөл.
Үүнтэй ижил систем нь Нээлттэй эхийн загварын сул талыг шалгах боломжийг танд олгоно. DAST нь бидний аль Нээлттэй эх сурвалжийг ашиглаж байгааг мэдэхгүй тул зүгээр л "хортой" хэв маягийг шидэж, серверийн хариултыг шинжилдэг:
-Тийм ээ, энд цуваа тайлах асуудал байна, гэхдээ энд биш.
Үүнд маш том эрсдэл бий, учир нь хэрэв та энэ аюулгүй байдлын тестийг шалгагч нартай ажилладаг вандан дээр хийвэл таагүй зүйл тохиолдож болно.
- Програмын серверийн сүлжээнд өндөр ачаалал.
- Интеграци байхгүй.
- Шинжилсэн програмын тохиргоог өөрчлөх чадвар.
- Шаардлагатай технологийн дэмжлэг байхгүй.
- Тохируулахад бэрхшээлтэй.
Бид эцэст нь AppScan-г эхлүүлэхэд ийм нөхцөл байдалтай тулгарсан: бид програм руу нэвтрэх гэж удаан хугацаанд оролдсон, 3 бүртгэлтэй болж, баяртай байсан - эцэст нь бид бүгдийг шалгах болно! Бид сканнердсан бөгөөд AppScan-ийн хийсэн хамгийн эхний зүйл бол админ самбар руу орж, бүх товчлууруудыг цоолж, мэдээллийн талыг сольж, дараа нь серверийг бүрэн устгасан. - хүсэлтүүд. Туршилттай хөгжүүлэлт нь:
- Залуус аа, та нар намайг тоглож байна уу?! Бид танд данс өгсөн, та нар зогсоол тавьсан!
Болзошгүй эрсдэлийг анхаарч үзээрэй. Хамгийн тохиромжтой нь мэдээллийн аюулгүй байдлыг турших тусдаа стенд бэлтгэж, бусад орчноос ямар нэгэн байдлаар тусгаарлагдсан байх ба админ самбарыг нөхцөлт байдлаар шалгаарай. Энэ бол бидний одоо авч үзэхгүй байгаа хүчин чармайлтын үлдсэн хувь хэмжээ юм.
Та үүнийг ачааллын туршилтын аналог болгон ашиглаж болно гэдгийг анхаарч үзэх нь зүйтэй. Эхний шатанд та 10-15 утастай динамик сканнерыг асааж, юу болохыг харж болно, гэхдээ практикээс харахад сайн зүйл байдаггүй.
Бидний ихэвчлэн ашигладаг цөөн хэдэн нөөц.
Онцлох нь зүйтэй аюулгүй байдлын ямар ч мэргэжлийн хувьд "Швейцарь хутга" юм. Хүн бүр үүнийг ашигладаг бөгөөд энэ нь маш тохиромжтой. Одоо аж ахуйн нэгжийн хувилбарын шинэ демо хувилбар гарлаа. Хэрэв өмнө нь энэ нь залгаастай бие даасан хэрэгсэл байсан бол одоо хөгжүүлэгчид эцэст нь хэд хэдэн агентуудыг удирдах боломжтой том сервер хийж байна. Энэ сайхан байна, би үүнийг туршиж үзэхийг зөвлөж байна.
Процессын нэгдэл
Интеграци нь маш сайн бөгөөд энгийн байдлаар явагддаг: амжилттай суулгасны дараа сканнердаж эхэлнэ стенд болон амжилттай нэгтгэх туршилтын дараа сканнердах.
Хэрэв интеграцууд ажиллахгүй эсвэл бүдүүвч, хуурамч функцүүд байгаа бол энэ нь утгагүй бөгөөд ашиггүй болно - бид ямар загвар илгээсэн ч сервер ижил байдлаар хариу үйлдэл үзүүлэх болно.
- Хамгийн тохиромжтой нь тусдаа туршилтын тавиур.
- Туршилт хийхийн өмнө нэвтрэх дарааллыг бичнэ үү.
- Удирдлагын системийг турших нь зөвхөн гарын авлага юм.
үйл явц
Үйл явцын талаар ерөнхийд нь бага зэрэг ерөнхийдөө, ялангуяа хэрэгсэл бүрийн ажлын талаар. Бүх програмууд өөр өөр байдаг - нэг нь динамик анализ, нөгөө нь статик анализ, гурав дахь нь OpenSource шинжилгээ, пентест эсвэл өөр ямар нэг зүйл, жишээ нь: .
Аливаа үйл явц нь хяналт шаарддаг.
Процесс хэрхэн ажилладаг, түүнийг хаана сайжруулж болохыг ойлгохын тулд үйлдвэрлэлийн хэмжүүр, багаж хэрэгслийн хэмжүүр, согог хянагч гэх мэт өөрийн гараар хийж болох бүх зүйлээс хэмжүүр цуглуулах хэрэгтэй.
Аливаа мэдээлэл тустай. Энэ эсвэл өөр хэрэгслийг хаана илүү сайн ашиглах, үйл явц нь ялангуяа уналтанд орохыг өөр өөр өнцгөөс харах шаардлагатай. Хугацаа дээр тулгуурлан үйл явцыг хаана сайжруулахыг харахын тулд хөгжлийн хариу өгөх хугацааг харах нь зүйтэй болов уу. Өгөгдөл их байх тусам дээд түвшнээс эхлээд процесс бүрийн нарийвчилсан мэдээлэл хүртэл илүү олон хэсгүүдийг барьж болно.
Бүх статик болон динамик анализаторууд өөрсдийн API, өөрийн эхлүүлэх арга, зарчимтай байдаг тул зарим нь төлөвлөгчтэй, бусад нь байдаггүй - бид хэрэгсэл бичиж байна. AppSec найруулагч, энэ нь танд бүтээгдэхүүнээс бүх процесст нэг нэвтрэх цэг үүсгэж, нэг цэгээс удирдах боломжийг олгодог.
Менежерүүд, хөгжүүлэгчид болон аюулгүй байдлын инженерүүд юу ажиллаж байгааг харах, скан хийх, тохируулах, сканнердах үр дүнг хүлээн авах, шаардлага илгээх боломжтой нэг нэвтрэх цэгтэй. Бид бичиг цаасны ажлаасаа холдож, хөгжилд ашигладаг бүх зүйлийг хүнийхээр хөрвүүлэхийг хичээж байна - статус ба хэмжигдэхүүнтэй нийлсэн байдал, Жира дахь согогууд эсвэл янз бүрийн согог хянагчууд эсвэл CI дахь синхрон/асинхрон процесст нэгтгэх хуудаснууд. /CD.
Түлхүүр Takeaways
Багаж хэрэгсэл нь гол зүйл биш юм. Эхлээд процессыг бодож үзээрэй - дараа нь багаж хэрэгслийг хэрэгжүүлээрэй. Хэрэгслүүд нь сайн боловч үнэтэй байдаг тул та процессоос эхэлж, хөгжил, аюулгүй байдлын хооронд харилцаа холбоо, ойлголтыг бий болгож чадна. Аюулгүй байдлын үүднээс бүгдийг “зогсоох” шаардлагагүй, хөгжлийн талаас нь харвал ямар нэгэн өндөр мега супер шүүмжлэл байгаа бол түүнийг арилгах, асуудалд нүдээ аниад хэрэггүй.
Бүтээгдэхүүний чанар - нийтлэг зорилго аюулгүй байдал, хөгжил хоёулаа. Бид нэг зүйлийг хийдэг, бид бүх зүйл зөв ажиллаж, нэр хүндийн эрсдэл, санхүүгийн алдагдалгүй байхыг хичээдэг. Ийм учраас бид харилцаа холбоог сайжруулах, бүтээгдэхүүний чанарыг сайжруулахын тулд DevSecOps, SecDevOps хандлагыг сурталчилж байна.
Танд байгаа зүйлээс эхэл: шаардлага, архитектур, хэсэгчилсэн шалгалт, сургалт, удирдамж. Бүх практикийг бүх төслүүдэд нэн даруй хэрэглэх шаардлагагүй - давталттай хөдөл. Нэг стандарт байдаггүй - туршилт мөн янз бүрийн арга, шийдлийг туршиж үзээрэй.
Мэдээллийн аюулгүй байдлын доголдол, үйл ажиллагааны доголдол хоёрын хооронд ижил шинж тэмдэг байдаг.
Бүх зүйлийг автоматжуулахтэр хөдөлдөг. Юу ч хөдөлдөггүй, хөдөлгөж, автоматжуул. Хэрэв ямар нэг зүйл гараар хийгдсэн бол энэ нь үйл явцын сайн хэсэг биш юм. Магадгүй үүнийг хянаж, автоматжуулах нь зүйтэй болов уу.
Хэрэв IS багийн хэмжээ бага бол - Аюулгүй байдлын аваргуудыг ашиглах.
Магадгүй миний ярьсан зүйл танд тохирохгүй байж магадгүй бөгөөд та өөрийн гэсэн зүйлийг гаргаж ирэх болно - энэ нь сайн хэрэг. Гэхдээ өөрийн үйл явцын шаардлагад тулгуурлан багаж хэрэгслийг сонгох. Энэ хэрэгсэл муу, энэ нь сайн гэж олон нийт юу гэж ярьж байгааг битгий хараарай. Магадгүй таны бүтээгдэхүүний хувьд эсрэгээрээ байх болно.
Багаж хэрэгсэлд тавигдах шаардлага.
- Доод түвшний худал эерэг.
- Хангалттай дүн шинжилгээ хийх хугацаа.
- Ашиглахад хялбар.
- Интеграцийн хүртээмж.
- Бүтээгдэхүүн хөгжүүлэх замын зураглалыг ойлгох.
- Хэрэгслийг тохируулах боломж.
Юригийн илтгэл DevOpsConf 2018-ийн шилдэг илтгэлүүдийн нэгээр шалгарлаа. Илүү сонирхолтой санаа, практик тохиолдлуудтай танилцахыг хүсвэл 27-р сарын 28, XNUMX-нд Сколковод ирээрэй. дотор . Хэрэв та туршлагаа хуваалцахад бэлэн байгаа бол илүү дээр юм 21-р сарын XNUMX хүртэл тайлан.
Эх сурвалж: www.habr.com
