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