Бізде 2 код анализаторы, 4 динамикалық тестілеу құралы, өз қолөнеріміз және 250 сценарий болды. Мұның бәрі ағымдағы процесте қажет емес, бірақ DevSecOps енгізуді бастағаннан кейін, сіз соңына дейін баруыңыз керек.
. Кейіпкерлерді жасаушылар: Джастин Ройланд және Дэн Хармон.
SecDevOps дегеніміз не? DevSecOps туралы не деуге болады? Қандай айырмашылықтар бар? Қолданба қауіпсіздігі - бұл не туралы? Неліктен классикалық әдіс енді жұмыс істемейді? Осы сұрақтардың барлығының жауабын біледі Юрий Шабалин -дан Swordfish қауіпсіздік. Юрий барлығына егжей-тегжейлі жауап береді және классикалық қолданбалы қауіпсіздік моделінен DevSecOps процесіне көшу мәселелерін талдайды: қауіпсіз әзірлеу процесін DevOps процесіне біріктіруге қалай дұрыс қарау керек және ештеңені бұзбау, негізгі кезеңдерден қалай өту керек қауіпсіздік сынағы, қандай құралдарды қолдануға болады және олар немен ерекшеленеді және қателерді болдырмау үшін оларды қалай дұрыс конфигурациялау керек.
Спикер туралы: Юрий Шабалин - Компанияның бас қауіпсіздік сәулетшісі Swordfish қауіпсіздік. SSDL енгізуге, қолданбаларды талдау құралдарын біртұтас өңдеу және тестілеу экожүйесіне жалпы интеграциялауға жауапты. Ақпараттық қауіпсіздік саласында 7 жыл тәжірибесі. «Альфа-Банк», «Сбербанк» және «Позитивті технологиялар» компанияларында жұмыс істеді, олар бағдарламалық қамтамасыз етуді әзірлеп, қызмет көрсетеді. ZerONights, PHDays, RISSPA, OWASP халықаралық конференцияларында спикер.
Қолданба қауіпсіздігі: бұл не туралы?
Қолданбалы қауіпсіздік - Бұл қолданба қауіпсіздігіне жауап беретін қауіпсіздік бөлімі. Бұл инфрақұрылымға немесе желі қауіпсіздігіне емес, біз жазған нәрселерге және әзірлеушілер немен жұмыс істейтініне қатысты - бұл қолданбаның кемшіліктері мен осалдықтары.
Тағайындалған орын - Қауіпсіздікті дамытудың өмірлік циклі - Microsoft әзірлеген. Диаграмма канондық SDLC моделін көрсетеді, оның негізгі міндеті талаптардан бастап шығаруға және өндіруге дейінгі дамудың әрбір кезеңінде қауіпсіздіктің қатысуы болып табылады. Майкрософт салада тым көп қателер бар екенін түсінді, олардың көп екенін және бұл туралы бірдеңе істеу керек екенін түсінді және олар канондық сипатқа ие болған осы тәсілді ұсынды.
Қолданба қауіпсіздігі және SSDL әдетте сенетіндей осалдықтарды анықтауға емес, олардың пайда болуын болдырмауға бағытталған. Уақыт өте келе Майкрософттың канондық тәсілі жетілдірілді, дамыды және тереңірек, егжей-тегжейлі сүңгуірге енгізілді.
Канондық SDLC әртүрлі әдістемелерде өте егжей-тегжейлі - OpenSAMM, BSIMM, OWASP. Әдістемелер әртүрлі, бірақ жалпы алғанда ұқсас.
Жетілу моделіндегі құрылыс қауіпсіздігі
Маған бәрінен де ұнайды BSIMM - . Әдістеменің негізі қолданбалы қауіпсіздік процесін 4 доменге бөлу болып табылады: Басқару, Интеллект, SSDL байланыс нүктелері және орналастыру. Әрбір доменде 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-қа баратынын түсінеміз, яғни біз тоқтамай:
«Бұл жерде осалдықтарыңыз бар, сіз бұдан әрі ешқайда кетпейсіз!»
Осы кезде әзірлеушілерге назар аударуды қажет ететін қауіпсіздік мәселелері бар екенін айту маңызды.
Осалдықтардың болуы әрі қарай тестілеуге кедергі болып табылмайды: нұсқаулық, біріктіру немесе нұсқаулық. Екінші жағынан, біз қандай да бір жолмен өнімнің қауіпсіздігін арттыруымыз керек және әзірлеушілер қауіпсіз деп тапқан нәрсені елеусіз қалдырмауымыз керек. Сондықтан, кейде біз мұны істейміз: стендте, ол әзірлеу ортасына шығарылған кезде, біз жай ғана әзірлеуді хабарлаймыз:
- Балалар, сендерде қиыншылықтар бар, соған назар аударыңдар.
UAT кезеңінде біз тағы да осалдықтар туралы ескертулерді көрсетеміз, ал шығару кезеңінде біз айтамыз:
- Балалар, біз сендерге бірнеше рет ескерттік, сендер ештеңе істемедіңдер - біз сендерді мұнымен жібермейміз.
Егер код пен динамика туралы айтатын болсақ, онда тек осы мүмкіндікте жазылған мүмкіндіктер мен кодтардың осалдықтарын көрсету және ескерту керек. Егер әзірлеуші түймені 3 пиксельге жылжытса және біз оған SQL инъекциясы бар екенін, сондықтан оны тез арада түзету керек екенін айтсақ, бұл дұрыс емес. Қазір не жазылғанын және қосымшаға келетін өзгерісті ғана қараңыз.
Бізде белгілі бір функционалдық ақау бар делік - қолданба жұмыс істемеуі керек: ақша аударылмайды, түймені басқан кезде келесі бетке өтпейді немесе өнім жүктелмейді. Қауіпсіздік ақаулары - бұл бірдей ақаулар, бірақ қолданба жұмысы тұрғысынан емес, қауіпсіздікте.
Бағдарламалық құрал сапасының барлық мәселелері қауіпсіздік мәселесі емес. Бірақ барлық қауіпсіздік мәселелері бағдарламалық қамтамасыз ету сапасына байланысты. Шериф Мансур, Expedia.
Барлық осалдықтар бірдей ақаулар болғандықтан, олар барлық даму ақаулары сияқты бір жерде орналасуы керек. Ешкім оқымайтын есептер мен қорқынышты PDF файлдарын ұмытыңыз.
Мен әзірлеуші компанияда жұмыс істеген кезде статикалық талдау құралдарынан есеп алдым. Мен оны аштым, шошып кеттім, кофе дайындадым, 350 бетті парақтап, жауып, жұмысты жалғастырдым. Үлкен есептер - өлі есептер. Әдетте олар ешқайда кетпейді, әріптер жойылады, ұмытылады, жоғалады немесе бизнес тәуекелдерді қабылдайтынын айтады.
Не істеу? Біз жай ғана табылған расталған ақауларды әзірлеуге ыңғайлы пішінге түрлендіреміз, мысалы, біз оларды Jira-да артта қалдырамыз. Біз ақауларға басымдық береміз және оларды функционалдық ақаулармен және сынақ ақауларымен бірге басымдық ретімен жоямыз.
Статикалық талдау - SAST
Бұл осалдықтарға арналған код талдауы., бірақ бұл SonarQube сияқты емес. Біз тек үлгілер мен стильдерді тексеріп қана қоймаймыз. Талдау кезінде бірқатар тәсілдер қолданылады: осалдықтар ағашына сәйкес, сәйкес , конфигурация файлдарын талдау арқылы. Мұның бәрі кодтың өзіне қатысты.
Тәсілдің оң жақтары: дамудың бастапқы кезеңінде кодтағы осалдықтарды анықтауәлі стендтер немесе дайын құралдар болмаған кезде, және қосымша сканерлеу мүмкіндігі: өзгертілген код бөлімін сканерлеу және сканерлеу уақытын қысқартатын қазір істеп жатқан мүмкіндікті ғана.
Минусы - бұл қажетті тілдерді қолдаудың жоқтығы.
Қажетті интеграциялар, құралдарда болуы керек, менің субъективті пікірім бойынша:
- Интеграция құралы: Дженкинс, 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 000 осалдық - бұл біздің техникалық қарызымыз. Біз қарызды қорапқа саламыз, біз оны ақырындап тазалаймыз және ақаулық трекерлерге қателерді қосамыз. Келіңіздер, компанияны жалдаймыз, бәрін өзіміз жасайық немесе Қауіпсіздік чемпиондары бізге көмектессін - және техникалық қарыз азаяды.
Жаңа кодтағы барлық жаңадан пайда болған осалдықтар бірліктегі немесе автотесттердегі қателер сияқты жойылуы керек. Салыстырмалы түрде айтатын болсақ, жиналыс басталды, біз оны өткіздік, екі сынақ және екі қауіпсіздік сынағы сәтсіз аяқталды. Жарайды - біз бардық, не болғанын қарадық, бір нәрсені түзеттік, екіншісін түзеттік, келесі жолы іске қостық - бәрі жақсы болды, жаңа осалдықтар пайда болған жоқ, сынақтар сәтсіз аяқталды. Егер бұл тапсырма тереңірек болса және оны жақсы түсіну қажет болса немесе осалдықтарды түзету сорғыштың астындағы үлкен қабаттарға әсер етсе: ақауларды бақылау құралына қате қосылды, оған басымдық беріледі және түзетіледі. Өкінішке орай, әлем мінсіз емес және сынақтар кейде сәтсіздікке ұшырайды.
Қауіпсіздік қақпасының мысалы кодтағы осалдықтардың болуы мен саны бойынша сапа қақпасының аналогы болып табылады.
Біз SonarQube-пен біріктіреміз - плагин орнатылған, бәрі өте ыңғайлы және керемет.
Даму ортасымен интеграция
Интеграция опциялары:
- Орындаудан бұрын әзірлеу ортасынан сканерлеуді іске қосу.
- Нәтижелерді көру.
- Нәтижелерді талдау.
- Сервермен синхрондау.
Бұл серверден нәтижелерді алу сияқты көрінеді.
Біздің даму ортамызда сканерлеу кезінде осындай осалдықтардың анықталғаны туралы хабарлайтын қосымша элемент жай ғана пайда болады. Кодты бірден өңдеуге, ұсыныстарды қарауға және . Мұның бәрі әзірлеушінің жұмыс орнында орналасқан, бұл өте ыңғайлы - басқа сілтемелерді орындап, қосымша нәрсені қараудың қажеті жоқ.
Ашық кілт
Бұл менің сүйікті тақырыбым. Барлығы ашық бастапқы кодты кітапханаларды пайдаланады - бәрі қазірдің өзінде іске асырылған дайын кітапхананы ала алатын болсаңыз, неліктен көптеген балдақтар мен велосипедтер жазу керек?
Әрине, бұл дұрыс, бірақ кітапханаларды да адамдар жазады, оларда белгілі бір қауіптер бар, сонымен қатар мезгіл-мезгіл немесе үнемі хабарланып отыратын осалдықтар бар. Сондықтан, Бағдарлама қауіпсіздігінің келесі қадамы бар - бұл Open Source компоненттерін талдау.
Ашық бастапқы талдау – OSA
Құрал үш үлкен кезеңді қамтиды.
Кітапханалардағы осалдықтарды іздеу. Мысалы, құрал біздің кейбір кітапхананы пайдаланып жатқанымызды біледі немесе кітапхананың осы нұсқасына қатысты қателерді бақылаушыларда осалдықтар бар. Сіз оны пайдалануға тырысқанда, құрал кітапхананың осал екендігі туралы ескерту береді және осалдықтары жоқ басқа нұсқаны пайдалануды ұсынады.
Лицензияның тазалығын талдау. Бұл әзірше бұл жерде танымал емес, бірақ егер сіз шетелде жұмыс істесеңіз, онда мезгіл-мезгіл пайдалануға немесе өзгертуге болмайтын ашық бастапқы компонентті пайдаланғаны үшін салық алуға болады. Лицензияланған кітапхананың саясатына сәйкес, біз мұны істей алмаймыз. Немесе, егер біз оны өзгертіп, қолданатын болсақ, кодымызды жариялауымыз керек. Әрине, ешкім өз өнімдерінің кодын жариялағысы келмейді, бірақ сіз өзіңізді одан қорғай аласыз.
Өндірістік ортада қолданылатын компоненттерді талдау. Біз әзірлеуді аяқтадық және микросервисіміздің соңғы шығарылымын шығардық деген гипотетикалық жағдайды елестетіп көрейік. Ол онда керемет өмір сүреді - бір апта, бір ай, бір жыл. Біз оны жинамаймыз, қауіпсіздікті тексермейміз, бәрі жақсы сияқты. Бірақ кенеттен, шығарылғаннан кейін екі аптадан кейін біз өнеркәсіптік ортада осы құрылымда қолданатын Open Source компонентінде маңызды осалдық пайда болады. Егер біз нені және қайда пайдаланатынымызды жазбасақ, біз бұл осалдықты көрмейміз. Кейбір құралдардың қазіргі уақытта салада қолданылатын кітапханалардағы осалдықтарды бақылау мүмкіндігі бар. Бұл өте пайдалы.
Ерекшеліктер:
- Дамудың әртүрлі кезеңдері үшін әртүрлі саясаттар.
- Өнеркәсіптік ортадағы компоненттерді бақылау.
- Ұйым ішіндегі кітапханаларды бақылау.
- Әр түрлі құрастыру жүйелері мен тілдерін қолдау.
- Docker кескіндерін талдау.
Open Source талдауымен айналысатын сала көшбасшыларының бірнеше мысалдары.
Жалғыз тегін бұл OWASP. Сіз оны бірінші кезеңде қосып, оның қалай жұмыс істейтінін және нені қолдайтынын көре аласыз. Негізінде, бұл барлық бұлтты өнімдер немесе жергілікті, бірақ олардың базасында олар әлі де Интернетке жіберіледі. Олар сіздің кітапханаларыңызды емес, осалдықтардың бар-жоғы туралы ақпаратты алу үшін өз серверлеріне есептейтін хэштерді немесе өздерінің мәндерін және саусақ іздерін жібереді.
Процесті біріктіру
Кітапханалардың периметрін бақылау, олар сыртқы көздерден жүктеледі. Бізде сыртқы және ішкі репозиторийлер бар. Мысалы, Event Central Nexus жүйесін басқарады және біз репозиторийімізде «сыни» немесе «жоғары» күйі бар осалдықтардың жоқтығына көз жеткізгіміз келеді. Мұндай осалдықтар жойылып, ішкі репозиторийде аяқталмайтындай етіп Nexus брандмауэрінің өмірлік циклі құралы арқылы прокси-серверді конфигурациялауға болады.
CI интеграциясы. Автотесттермен, бірлік сынақтарымен және даму кезеңдерімен бір деңгейде: әзірлеу, сынақ, өнім. Әрбір кезеңде сіз кез келген кітапхананы жүктей аласыз, кез келген нәрсені пайдалана аласыз, бірақ егер «сыни» күйде қиын нәрсе болса, өндіріске шығару кезеңінде әзірлеушілердің назарын аударған жөн.
Артефактілермен интеграция: Nexus және JFrog.
Даму ортасына интеграция. Сіз таңдаған құралдардың әзірлеу орталарымен интеграциясы болуы керек. Әзірлеуші жұмыс орнындағы сканерлеу нәтижелеріне қол жеткізуі немесе CVS-ке кіріспес бұрын кодты өзі сканерлеу және осалдықтарды тексеру мүмкіндігі болуы керек.
CD интеграциясы. Бұл маған өте ұнайтын және мен бұрын айтқан керемет функция - өнеркәсіптік ортада жаңа осалдықтардың пайда болуын бақылау. Бұл осындай нәрсе жұмыс істейді.
Бізде бар Жалпы құрамдас репозитарийлер — кейбір құралдар сыртында және біздің ішкі репозиторийіміз. Біз оның тек сенімді құрамдастарды қамтығанын қалаймыз. Сұрауды прокси арқылы жіберу кезінде жүктеп алынған кітапханада осалдықтардың жоқтығын тексереміз. Егер ол біз орнатқан және әзірлеумен міндетті түрде үйлестіретін белгілі саясаттарға сәйкес келсе, біз оны жүктеп салмаймыз және басқа нұсқаны пайдалануды сұраймыз. Тиісінше, егер кітапханада шынымен маңызды және нашар нәрсе болса, онда әзірлеуші орнату кезеңінде кітапхананы алмайды - оған жоғары немесе төмен нұсқаны пайдалануға рұқсат етіңіз.
- Құрылыс кезінде біз ешкімнің жаман ештеңе сырғып кетпегенін, барлық компоненттердің қауіпсіз екенін және флешкаға ешкім қауіпті ештеңе әкелмегенін тексереміз.
- Репозиторийде тек сенімді құрамдас бөліктер бар.
- Орналастыру кезінде біз пакеттің өзін тағы бір рет тексереміз: соғыс, jar, DL немесе Docker кескіні оның саясатқа сәйкестігіне көз жеткізу үшін.
- Өнеркәсіпке кірген кезде біз өндірістік ортада не болып жатқанын бақылаймыз: маңызды осалдықтар пайда болады немесе пайда болмайды.
Динамикалық талдау - DAST
Динамикалық талдау құралдары бұрын айтылғандардың бәрінен түбегейлі ерекшеленеді. Бұл қолданушының қолданбамен жұмысына еліктеу түрі. Егер бұл веб-қосымша болса, біз клиенттің жұмысын имитациялайтын сұраныстарды жібереміз, алдыңғы жағындағы түймелерді басыңыз, пішіннен жасанды деректерді жібереміз: тырнақшалар, жақшалар, әртүрлі кодтаудағы таңбалар, қолданбаның қалай жұмыс істейтінін және өңделуін көру үшін сыртқы деректер.
Дәл сол жүйе ашық бастапқы кодта үлгінің осалдықтарын тексеруге мүмкіндік береді. DAST қандай Ашық көзді қолданып жатқанымызды білмейтіндіктен, ол жай ғана «зиянды» үлгілерді шығарады және сервер жауаптарын талдайды:
- Иә, бұл жерде сериядан шығару мәселесі бар, бірақ бұл жерде емес.
Бұл жерде үлкен тәуекелдер бар, өйткені егер сіз осы қауіпсіздік сынағын тестерлер жұмыс істейтін стендте өткізсеңіз, жағымсыз жағдайлар орын алуы мүмкін.
- Қолданбалы сервер желісінде жоғары жүктеме.
- Интеграциялар жоқ.
- Талданатын қолданбаның параметрлерін өзгерту мүмкіндігі.
- Қажетті технологияларға қолдау жоқ.
- Орнату қиындығы.
Бізде AppScan іске қосылған кезде жағдай болды: біз қолданбаға қол жеткізуге ұзақ уақыт жұмсадық, 3 тіркелгі алдық және қуандық - біз ақырында бәрін тексереміз! Біз сканерлеуді іске қостық және AppScan жасаған бірінші нәрсе - әкімші панеліне кіріп, барлық түймелерді тесіп, деректердің жартысын өзгертіп, серверді толығымен жою. - сұраныстар. Тестілеу арқылы әзірлеу былай деді:
-Балалар, мені қалжыңдап тұрсыңдар ма?! Біз сізге есеп бердік, ал сіз стенд орнаттыңыз!
Ықтимал тәуекелдерді қарастырыңыз. Ең дұрысы, ақпараттық қауіпсіздікті тестілеуге арналған жеке стенд дайындаңыз, ол кем дегенде қандай да бір жолмен қоршаған ортаның қалған бөлігінен оқшауланады және басқару тақтасын шартты түрде тексеріңіз, жақсырақ қолмен режимде. Бұл пентест - біз қазір қарастырмайтын күш-жігердің қалған пайызы.
Мұны жүктеме сынағының аналогы ретінде пайдалануға болатынын ескерген жөн. Бірінші кезеңде сіз 10-15 ағыны бар динамикалық сканерді қосып, не болатынын көре аласыз, бірақ әдетте тәжірибе көрсеткендей, жақсы ештеңе болмайды.
Біз әдетте қолданатын бірнеше ресурстар.
Ерекшелеуге тұрарлық кез келген қауіпсіздік маманы үшін «швейцариялық пышақ» болып табылады. Барлығы оны пайдаланады және бұл өте ыңғайлы. Кәсіпорын басылымының жаңа демо нұсқасы енді шығарылды. Егер бұрын бұл плагиндері бар жеке утилита болса, енді әзірлеушілер ақырында бірнеше агенттерді басқаруға болатын үлкен сервер жасайды. Бұл керемет, мен оны көруге кеңес беремін.
Процесті біріктіру
Интеграция өте жақсы және қарапайым жүреді: сәтті орнатудан кейін сканерлеуді бастаңыз стендке арналған өтінімдер және сәтті интеграциялық сынақтан кейін сканерлеу.
Интеграциялар жұмыс істемесе немесе тұнбалар мен жалған функциялар болса, бұл мағынасыз және пайдасыз - біз қандай үлгіні жіберсек те, сервер бұрынғысынша жауап береді.
- Ең дұрысы, жеке сынақ стенді.
- Тестілеуден бұрын кіру ретін жазыңыз.
- Басқару жүйесін тестілеу тек қолмен жүргізіледі.
процесс
Жалпы процесс туралы және әрбір құралдың жұмысы туралы аздап жалпыланған. Барлық қолданбалар әртүрлі – біреуі динамикалық талдаумен, екіншісі статикалық талдаумен, үшіншісі OpenSource талдауымен, пентесттермен немесе жалпы басқа нәрсемен, мысалы, оқиғалармен жақсы жұмыс істейді. .
Әрбір процесс бақылауды қажет етеді.
Процесс қалай жұмыс істейтінін және оны қай жерде жақсартуға болатынын түсіну үшін өндіріс көрсеткіштерін, құралдардағы көрсеткіштерді және ақауларды бақылау құралдарын қоса алғанда, қолыңызға алуға болатын барлық нәрселерден көрсеткіштерді жинау керек.
Кез келген ақпарат пайдалы. Осы немесе басқа құралды қай жерде жақсырақ пайдаланғанын, процестің нақты төмендейтінін әртүрлі қырынан қарау керек. Уақыт негізінде процесті қай жерде жақсартуға болатынын көру үшін әзірлеуге жауап беру уақыттарын қарастырған жөн. Дерек неғұрлым көп болса, соғұрлым жоғары деңгейден әрбір процестің егжей-тегжейлеріне дейін көбірек бөлімдерді құруға болады.
Барлық статикалық және динамикалық анализаторлардың өздерінің API интерфейстері, іске қосу әдістері, принциптері болғандықтан, кейбіреулерінде жоспарлаушылар бар, басқаларында жоқ - біз құрал жазып жатырмыз. AppSec оркестрі, бұл өнімнен бүкіл процеске бір кіру нүктесін жасауға және оны бір нүктеден басқаруға мүмкіндік береді.
Менеджерлер, әзірлеушілер және қауіпсіздік инженерлері не істеп тұрғанын көре алатын, сканерлеуді конфигурациялай және іске қоса алатын, сканерлеу нәтижелерін ала алатын және талаптарды жіберетін бір кіру нүктесі бар. Біз қағазбастылықтан бас тартуға, барлығын әзірлеуде қолданатын адамға айналдыруға тырысамыз - күй мен метрикамен түйісу беттері, Jira-дағы немесе әртүрлі ақауларды бақылаушылардағы ақаулар немесе CI жүйесіндегі синхронды/асинхронды процеске біріктіру. /CD.
Негізгі тағамдар
Құралдар басты нәрсе емес. Алдымен процесті ойластырыңыз - содан кейін құралдарды іске қосыңыз. Құралдар жақсы, бірақ қымбат, сондықтан сіз процесті бастап, даму мен қауіпсіздік арасында байланыс пен түсіністікті құра аласыз. Қауіпсіздік тұрғысынан барлығын «тоқтату» қажет емес, даму тұрғысынан, егер жоғары мега суперкритикалық нәрсе болса, оны жою керек және мәселеге көз жұмып қарамау керек.
Өнім сапасы - ортақ мақсат қауіпсіздік пен даму. Біз бір нәрсе жасаймыз, біз бәрі дұрыс жұмыс істейтініне және беделге қатысты тәуекелдер мен қаржылық шығындардың болмауына көз жеткізуге тырысамыз. Сондықтан біз байланысты жақсарту және өнім сапасын жақсарту үшін DevSecOps, SecDevOps тәсілін алға жылжытамыз.
Сізде бар нәрседен бастаңыз: талаптар, архитектура, ішінара тексерулер, тренингтер, нұсқаулар. Барлық жобаларға барлық тәжірибелерді дереу қолданудың қажеті жоқ - итеративті қозғалады. Бірыңғай стандарт жоқ - эксперимент және әртүрлі тәсілдер мен шешімдерді қолданып көріңіз.
Ақпараттық қауіпсіздік ақаулары мен функционалдық ақаулар арасында тең белгі бар.
Барлығын автоматтандырыңызбұл қозғалады. Қозғалмайтын нәрсе болса да, оны жылжытыңыз және автоматтандырыңыз. Егер бірдеңе қолмен жасалса, бұл процестің жақсы бөлігі емес. Мүмкін оны қарап шығып, автоматтандыру керек шығар.
АЖ командасының мөлшері аз болса - Қауіпсіздік чемпиондарын пайдаланыңыз.
Мүмкін мен айтқан нәрсе сізге сәйкес келмеуі мүмкін және сіз өзіңізді бір нәрсе ойлап табасыз - бұл жақсы. Бірақ процеске қойылатын талаптар негізінде құралдарды таңдаңыз. Қауымдастық бұл құрал жаман, мынау жақсы деп айтып жатқанына қарамаңыз. Сіздің өніміңіз үшін керісінше болуы мүмкін.
Құралдарға қойылатын талаптар.
- Төмен деңгей Жалған оң.
- Адекватты талдау уақыты.
- Пайдаланудың қарапайымдылығы.
- Интеграциялардың болуы.
- Өнімді дамытудың жол картасын түсіну.
- Құралдарды теңшеу мүмкіндігі.
Юрийдің баяндамасы DevOpsConf 2018 көрмесінде үздіктердің бірі болып таңдалды. Одан да қызықты идеялар мен практикалық істермен танысу үшін 27 және 28 мамырда Сколкового келіңіз. ішінде . Жақсырақ, егер сіз өз тәжірибеңізбен бөлісуге дайын болсаңыз, онда есеп бойынша 21 сәуірге дейін.
Ақпарат көзі: www.habr.com