Сучасная бяспека праграм — гэта ўжо не толькі ізаляваныя інструменты. Сёння каманды маюць справу з разрозненымі сігналамі, бясконцымі абвесткамі і абмежаванай яснасцю адносна таго, што насамрэч працуе ў іх асяроддзі. Гэтая праблема падштурхнула многія арганізацыі пераасэнсаваць, як механізм кіравання праграмамі, кантэйнер кліента прыкладання, і Application Security Posture Management (ASPM) спалучаюцца разам, каб забяспечыць рэальны кантроль над выкананнем.
ASPM забяспечвае адзіны спосаб разумення рызык ва ўсім кодзе, pipelineі асяроддзе выканання. Аднак адной толькі паставы недастаткова. Каб дзейнічаць у адпаведнасці з гэтай паставай, камандам патрэбен рэальны кантроль выканання. Менавіта тут механізм кіравання праграмамі становіцца крытычна важным, і тут традыцыйныя мадэлі, такія як кліенцкі кантэйнер праграмы, пачынаюць паказваць свае абмежаванні.
Чаму ASPM З'яўляецца адпраўной кропкай для кантролю прыкладанняў
ASPM адказвае на фундаментальнае пытанне: які мой рэальны ўзровень бяспекі ва ўсіх праграмах.
Гэта робіцца шляхам карэляцыі сігналаў з зыходнага кода, залежнасцей, CI/CD pipelineс, інфраструктура і паводзіны пры выкананні. У выніку каманды атрымліваюць уяўленне аб тым, што існуе, як кампаненты звязаны паміж сабой і дзе канцэнтруецца рызыка.
Аднак бачнасць без дзеянняў хутка стварае трэнне. Таму ASPM павінна звязваць паводзіны з правапрымяненнем. Іншымі словамі, як толькі рызыка будзе зразумелая, платформа павінна дапамагчы вырашыць, што павінна быць дазволена выконваць, а што не.
Менавіта тут і ўпісваецца кіраванне праграмамі ASPM.
Што ASPM Вырашае гэтую праблему, якую інструменты бяспекі не могуць
Большасць інструментаў бяспекі былі створаны для адказаў на вузкія пытанні. Статычныя сканеры вывучаюць код. Інструменты залежнасцей аналізуюць бібліятэкі. Рашэнні асяроддзя выканання назіраюць за падзеямі выканання. Кожны з іх працуе ізалявана.
Як вызначана Структура кіравання рызыкамі NIST, эфектыўная бяспекаcisіёны патрабуюць бесперапыннага кантэксту, а не ізаляванага кантролю. Гэта абмежаванне тлумачыць, чаму кропкавыя інструменты з цяжкасцю апісваюць рэальныя рызыкі прыкладання.
Аднак сучасныя рызыкі прыкладанняў не існуюць асобна. Замест гэтага яны ўзнікаюць з узаемадзеяння паміж зменамі кода, залежнасцямі, pipelineі паводзіны падчас выканання. У выніку кропкавыя інструменты часта ствараюць папярэджанні, не тлумачачы рэальнага ўздзеяння.
тут ASPM змяняе мадэль.
ASPM суадносіць сігналы на працягу ўсяго жыццёвага цыклу праграмы. Замест таго, каб ацэньваць асобнае сканаванне або падзею, праграма стварае бесперапыннае ўяўленне пра тое, што існуе, як кампаненты ўзаемазвязаны і як рызыка змяняецца з цягам часу. Такім чынам, каманды могуць зразумець не толькі тое, што адбылося, але і чаму гэта адбылося, і ці сапраўды гэта мае значэнне.
Без ASPMМеханізмы кантролю працуюць без кантэксту. Змена можа выглядаць небяспечнай сама па сабе, хоць цалкам чаканай. У той жа час невялікая мадыфікацыя можа ўнесці рэальную рызыку, калі яна парушае ўсталяваныя шаблоны. Такім чынам, пастава становіцца асновай для значнага кантролю.
Увогуле, ASPM ператварае разрозненыя дадзеныя бяспекі ў структураваную аналітыку. Ён замяняе фрагментаваныя абвесткі разуменнем рызык прыкладанняў, на якія могуць рэагаваць механізмы кантролю.
Што такое механізм кіравання праграмамі
An механізм кіравання праграмамі — гэта механізм, які вырашае, якія праграмы, працэсы або кампаненты могуць выконвацца ў асяроддзі. Замест таго, каб рэагаваць пасля выканання, ён сканцэнтраваны на прадухіленні непажаданага выканання з самага пачатку, што робіць механізм кантролю праграм ключавой часткай праактыўнай бяспекі.
Традыцыйна, механізмы кіравання праграмамі абапіраліся на статычныя белыя спісы. Калі двайковы файл або працэс не быў відавочна ўхвалены, выкананне блакавалася. Спачатку такі падыход зніжаў рызыку ў стабільных і прадказальных сістэмах.
Аднак сучасныя праграмныя асяроддзі пастаянна змяняюцца. Залежнасці абнаўляюцца аўтаматычна, зборкі адбываюцца часта, а нагрузкі кароткачасовыя. У выніку статычныя правілы вельмі хутка губляюць актуальнасць.
У адрозненне ад антывірусных рашэнняў, класічных інструментаў EDR або брандмаўэраў, якія сканцэнтраваны на вядомых пагрозах або сеткавым трафіку, механізм кантролю праграм працуе на іншым узроўні. Ён вырашае, ці павінна выкананне адбывацца ўвогуле. Такім чынам, ён адыгрывае ролю ў прадухіленні, а не ў выяўленні пасля факту.
Што такое кантэйнер кліента прыкладання
An кантэйнер кліента прыкладання забяспечвае кіраванае асяроддзе выканання для кліенцкіх праграм. Яно вырашае такія праблемы, як кіраванне жыццёвым цыклам, канфігурацыя і кантэкст бяспекі.
Простымі словамі, кантэйнер ахінае праграму і прапануе агульныя сэрвісы, таму распрацоўшчыкам не трэба ствараць іх уручную. Гэтая мадэль стала папулярнай у enterprise асяроддзяў, дзе паслядоўнасць і standardпатрабавалася ізацыя.
Сёння кантэйнеры кліентаў прыкладанняў усё яшчэ актуальныя ў пэўных enterprise і састарэлыя сцэнарыі. Аднак яны засяроджваюцца на тым, як працуе праграма, а не на тым, ці павінна яна працаваць. Яны мяркуюць, што праграма і яе кампаненты ўжо давераныя, і ім не хапае бачнасці рызык у ланцужку паставак або нечаканых змен.
Механізм кіравання праграмамі супраць кантэйнера кліента прыкладанняў
Нягледзячы на тое, што назвы гучаць падобна, гэтыя падыходы служаць зусім розным мэтам.
| Aspect | Механізм кіравання праграмамі | Кантэйнер кліента прыкладання |
|---|---|---|
| Асноўнае прызначэнне | Вырашыце, што можна выканаць | Забяспечце кіраванае асяроддзе выканання |
| Момант кантролю | Да і падчас выканання | Падчас выканання |
| бачнасць | Абмежавана ў старых мадэлях | Толькі падчас выканання |
| Правапрымяненне | Кантроль выканання на аснове палітык | Выкананне на ўзроўні платформы |
| Інфармаванасць аб ланцужку паставак | Часта адсутнічае | Не прызначаны для гэтага |
Карацей кажучы, кантэйнер кліента прыкладання кіруе выкананнем пасля таго, як каманды пачнуць давяраць. Механізм кіравання праграмамі вырашае, ці заслугоўвае выкананне даверу ўвогулеАднак без кантэксту паставы многія рухавікі дзейнічаць усляпую і прапусціць рэальную рызыку.
Чаму кантроль старых праграм не працуе без ASPM
Састарэлыя рухавікі кіравання праграмамі мэтавыя асяроддзяў, дзе праграмнае забеспячэнне павольна змянялася, яны Мяркуецца прадказальныя шляхі выканання і лячэнне прыкладанняў, як цалкам зразумела.
Сёння гэтая мадэль ламаецца.
залежнасці ўводзіць праекты аўтаматычна з публічных рэестраў.
каманды штурхаць код змяняецца некалькі разоў на дзень.
Платформы працаваць прыкладання ў эфемерных кантэйнерах.
узломшчыкі хаваць кампаненты ўнутры, якім каманды ўжо давяраюць.
па OWASP, Сучасныя атакі на ланцужкі паставак часта злоўжываюць даверанымі кампанентамі, што робіць статычны кантроль выканання недастатковым сам па сабе. У гэтым кантэксце белыя спісы і фіксаваныя правілы не адлюстроўваюць, як рызыка фактычна трапляе ў праграмы.
У выніку, статычныя белыя спісы амаль адразу губляюць актуальнасцьАкрамя таго, кантроль за старымі сістэмамі не хапае ўсведамлення паставы, гэта не можа растлумачыць чаму адбылася змена або ці адбылася гэтая змена уяўляе рэальную рызыку.
Такім чынам, кантроль прыкладанняў без ASPM становіцца альбо празмерна абмежавальным, альбо небяспечна паблажлівым.
Сучасны кантроль прыкладанняў унутры ASPMАд паставы да выканання
Сучасны кантроль прыкладанняў працуе лепш за ўсё як частка ASPM, а не як самастойны механізм.
Замест таго, каб спадзявацца толькі на статычныя правілы, каманды базавы кантроль decisіёны на сігналы паставы, такія як:
- Як каманды стварылі прыкладанне
- Якія залежнасці каманды ўвялі або змянілі
- Ці паводзіны адхіляецца з папярэдніх версій
- Ці шаблоны выканання нечакана змяніць
У выніку, кантроль прыкладанняў працуе бесперапыннаЗамест таго, каб пытацца толькі «ці павінна гэта працаваць», сістэмы прасіць «Ці адпавядае гэтае пакаранне смерцю вядомай постаці і гісторыі?»
У гэтай мадэлі механізм кіравання праграмамі дзейнічае як узровень правапрымянення рухомы ASPM праніклівасць.
Як дэканструюе кантроль прыкладанняўcisіёны Змяняюцца з ASPM Кантэкст
Кантроль прыкладанняўcisіёны істотна змяніць калі каманды ўжываюць кантэкст паставы.
Без ASPM, рухавікі кіравання праграмамі спадзявацца на статычных правілах. Бінарны файл праходзіць або не праходзіцьПрацэс адпавядае правілу ці неУ выніку, дэcisіёны заставацца бінарным і ігнараваць намер.
з ASPM кантэкст, кантроль становіцца сітуацыйным.
Напрыклад, каманды дазваляць новая залежнасць, калі яна супадае з нядаўняй дзейнасцю распрацоўшчыкаў. Аднак каманды блакаваць тая ж залежнасць, калі яна нечакана з'яўляецца ў стабільным дадатку. Такім чынам, кантроль адаптуецца да кантэксту замест таго, каб прымушаць да фіксаваных здагадак.
Аналагічна, паводзіны выканання, якія выглядае нармальна у адным дадатку сігналы рызыкі у іншым. ASPM забяспечвае гістарычны і рэляцыйны кантэкст, Які дапамагае механізмам кантролю адрозніваць паміж чаканай эвалюцыяй і падазроным адхіленнем.
Замест таго, каб пытацца «ці адпавядае гэта правілу», кантроль прыкладанняў пытаецца «ці мае гэта сэнс, улічваючы тое, што мы ведаем». Такім чынам, правапрымяненне становіцца больш дакладным і менш перашкаджае.
Як Xygeni падключаецца ASPM, Кантроль прыкладанняў і забеспячэнне выканання
Падыходы Xygeni кантроль прыкладанняў як натуральнае працяг ASPM.
Па-першае, Xygeni стварае пазіцыю, адлюстроўваючы праграмы, залежнасці, pipelineі сігналы выканання. Гэта стварае выразнае ўяўленне пра тое, што існуе і як кампаненты звязаны паміж сабой.
Далей Xygeni ўжывае кантроль над праграмамі, выкарыстоўваючы гэтую пазіцыю. Замест статычных белымі спісамі, decisІёны ўлічваюць кантэкст зборкі, паходжанне залежнасцей і гісторыю паводзін.
Важна адзначыць, што гэты падыход не абапіраецца на цяжкія агенты асяроддзя выканання. Логіка кіравання праграмамі інтэгравана непасрэдна ў CI/CD pipelineі працоўныя працэсы бяспекіУ выніку, прымяненне правілаў адбываецца на ранняй стадыі, паслядоўна і без уплыву на прадукцыйнасць.
Нарэшце, пастава, кантроль і забеспячэнне ўтвараюць замкнёны цыкл:
- ASPM вызначае рэальную рызыку
- Кантроль прыкладанняў вырашае, што трэба выконваць
- Прымяняюцца правілы выкананняcisіёны аўтаматычна
Іншымі словамі, Xygeni не блакуе сляпа. Ён выконвае патрабаванні, таму што разумее рызыку.
Напрыклад, новая залежнасць, уведзеная падчас актыўнай распрацоўкі, можа быць дазволена, калі яна адпавядае нядаўняй актыўнасці зборкі і гістарычным заканамернасцям. Аднак тая ж залежнасць, якая нечакана з'яўляецца ў стабільнай службе, можа быць аўтаматычна заблакіравана. Такім чынам, кіраванне праграмамі...cisІёны кіруюцца кантэкстам паставы, а не фіксаванымі здагадкамі.
Распаўсюджаныя памылковыя ўяўленні пра механізмы кіравання праграмамі
Многія каманды ўсё яшчэ лічаць, што кантроль праграм — гэта толькі блакаванне двайковых файлаў. Аднак сучасны кантроль праграм мае больш шырокае прымяненне.
Распаўсюджаныя памылковыя ўяўленні ўключаюць:
- Кантроль праграм замяняе сканаванне ўразлівасцяў
- Статычных белых спісаў дастаткова
- Кантроль мае значэнне толькі падчас выканання
Насамрэч, эфектыўны кантроль прыкладанняў залежыць ад паставы, кантэксту і паводзін з цягам часу. Без ASPM, кантроль застаецца няпоўным.
Заключныя думкі
Кантэйнеры кліентаў прыкладанняў дапамагаюць праграмам працаваць паслядоўна. Рухавікі кіравання праграмамі вырашыць, ці павінна выкананне адбывацца ўвогуле. Аднак у сучасных умовах ні адзін з іх не працуе асобна.
ASPM забяспечвае кантэкст. Кантроль прыкладанняў забяспечвае дэcisіён. Прымусовае выкананне прадугледжвае дзеянне.
Аб'ядноўваючы паставу, кантроль і забеспячэнне выканання, такія платформы, як Xygeni, дазваляюць камандам кантраляваць, што выконваецца, чаму гэта выконваецца і ці варта гэта выконваць наогул. У сучасных умовах кантроль што выконваецца перад выкананнем значна важней, чым сканаванне пасля выканання, асабліва таму, што праграмнае забеспячэнне пастаянна змяняецца.
пра аўтара
аўтар Фаціма Said, менеджэр па кантэнт-маркетынгу, які спецыялізуецца на бяспецы прыкладанняў у Бяспека Xygeni.
Фаціма стварае зручны для распрацоўшчыкаў кантэнт на аснове даследаванняў у AppSec, ASPMі DevSecOps. Яна перакладае складаныя тэхнічныя канцэпцыі ў зразумелыя, практычныя ідэі, якія злучаюць інавацыі ў кібербяспецы з уплывам на бізнес.
