Прашајте го било кој облак инженер колку апликации работат низ нивната средина, и ќе добиете број на топка. Прашајте повторно пет минути подоцна, и тие може да го удвојат. Тешко е да се поверува, но меѓу пренасочувањата на цевките на CI / CD, работните оптоварувања на зомбита, наследни апликации во мрачни агли на инфраструктурата и премногу даватели на идентитет (IdPs) за да се бројат, лесно е да се изгуби трага. Кога не знаете што работи, не можете да го управувате и да го заштитите. Сиромашни апликации без МФА, апликации кои сè уште се потпираат на наследна аутентификација, или работни оптоварувања редиспонирани од страна на застарен скрипт се лесна плен за лошите актери. Имам усогласеност Имам усогласеност Со сè друго станува континуирано - од интеграција до распоредување - откривањето треба да биде исто така. Проблемот со фрагментацијата Во типично претпријатие денес, апликациите се распоредуваат низ AWS, Azure, GCP, а можеби и приватниот облак или два. Користејќи ја Google Cloud Platform (GCP) како пример, апликацијата може да се имплементира на повеќе начини. Имате опции кои вклучуваат App Engine, Cloud Run, Compute Engine, Google Kubernetes Engine и Apigee Gateway. Други облачни платформи како Azure и Amazon Web Services, исто така, имаат многу опции за имплементација за работното оптоварување на апликациите. Некои се слични, како Kubernetes поддршка, но други технологии би можеле да бидат единствени за таа облачна платформа. Дури и инфраструктурата како код (IaC), како што е Terraform, не секогаш ја фаќа целата слика, особено кога програмерите ги заобиколуваат шаблоните за рачно распоредување или забораваат да ги ажурираат ознаките. Се разбира, постои слична дистрибуција за системите за идентитет кои го контролираат пристапот до овие апликациски средини.Предприятијата можат да имаат мешавина од Okta, Microsoft Entra ID и Amazon Cognito, како и на локално ниво Active Directory или наследни производи за управување со веб пристап, наследни инстанции на SiteMinder и на локално ниво Active Directory, често коегзистираат. Фрагментиран идентитет Апликациите може да се автентифицираат против различни IdPs во зависност од тоа кога и каде се распоредени. На пример, тимот може да го избере Okta за внатрешни апликации, додека системите кои се насочени кон клиентите се потпираат на Microsoft Или со познавање. Влезете ID Влезете ID Резултатот е широк спектар на овластувања, политики и пристап модели кои го прават речиси невозможно да се ревидира конзистентно. Ова ниво на Тоа е сигурно непријатно, но уште полошо, тоа е опасно. Напаѓачите не треба да ги компромитираат вашите крунски накити; тие само треба да ја најдат таа незаштитена врата. Фрагментација на идентитетот Фрагментација на идентитетот Зошто традиционалните ревизии не го намалуваат Еден пример за модел на ревизија вклучува воведување на консултантска фирма за Големите Четири, спроведување на ревизија, генерирање на извештај и нарекување на денот. CI / CD цевки може да редиплоираат деактивирани апликации. Тимот за развој може да создаде нешто ново без да ја информира безбедноста. Или, уште полошо, спиечка апликација со лабава политика на SiteMinder сè уште може да дозволи некој со @company.com е-пошта да оди право во. Што е уште потешко, овие ревизии по природа се тесни во опсег. Тие фаќаат моментална слика на систем кој постојано се менува. Секое значајно откритие е силоирано до луѓето вклучени во процесот на ревизија и често се чува во статични документи кои никој не ги повтори до следниот круг. Нема континуитет, нема автоматизација и нема гаранција дека податоците остануваат точни понатаму од денот кога биле собрани. Долари и чувство за безбедност Не заборавајте за трошоците. Овие проценки често бараат недели напор и стотици илјади долари. Резултатот е убава презентација, со графикони и куршуми кои изгледаат одлично во советодавна соба. Но, каква вредност им носат на инженерот кој се обидува да следи кој IdP го регулира пристапот до контејнеризирана апликација која работи на заборавен GCP кластер? Во меѓувреме, напаѓачите не чекаат за вашиот следен циклус на ревизија. Тие ја скенираат вашата површина на напад, барајќи крајни точки кои вашиот табела не ги фати. Како изгледа континуираното откривање? Многу тимови за безбедност се заглавени да играат blindfolded whack-a-mole со видливост на апликацијата. Тие откриваат една сенка апликација само за да најдат уште три скриени во пукнатините. Проблемот не е поради мрзеливост или недостаток на алатки, тоа е дека животната средина постојано се менува. Меѓу тимовите за развој се врти нови услуги, CI / CD цевки редиспонирање на старите, и инфраструктурата се развива во текот на неделата, одржување на статичен инвентар е невозможно. Тоа е причината зошто постојаното откривање скали. Тоа ја менува видливоста од нешто што го правите еднаш на четвртина на нешто што го градите во ткаенината на вашите операции. Еве што значи тоа: ** Cloud-native скенирање: ** Повик до API на различни облачни платформи (GCP, Azure, AWS) за да ги наведете распоредувањата на услугите: App Engine, ECS, Lambda, Cloud Run, итн. Мапирање на секоја апликација до нејзиниот IdP, проверете го спроведувањето на МФА и каталогот за аутентификација (SAML, OIDC, LDAP, header-based, итн.). Identity correlation Зафатете ги апликациите кои повторно се појавуваат откако ќе бидат оневозможени затоа што цевката не го доби мемоарот. CI/CD monitoring Применувајте метаподатоци за да ги организирате според опсегот на усогласеност (на пример, PCI апликации), одделот или чувствителноста на податоците. Tagging and classification Континуираното откривање обезбедува поврзувачко ткиво помеѓу вашата инфраструктура и вашата архитектура на идентитет. Таа го поставува сцената за управување со безбедносната позиција во реално време, проактивно усогласување и ефикасен одговор на инциденти.Без неа, следното прекршување поврзано со апликацијата можеби не доаѓа од софистициран експлоит, туку наместо тоа, нешто што вашиот тим дури и не знаел дека работи. Наместо периодични вежби за пожар, континуираното откривање ја третира видливоста на апликациите како жив процес. Реалниот случај на употреба: претпоставката за 2,500 против 4,500 апликации Во една компанија од Fortune 500, на ново назначен CTO му беше поставено наизглед едноставно прашање: "Колку апликации има во вашата средина?" „2,500“, таа одговори самоуверено, а потоа престана. „Чекај, само што купивме друга компанија од иста големина. Одговорот не дојде од систем на записи. Тоа беше претпоставка, врз основа на пресметка на купување и груба претпоставка за паритет. Не постоеше инвентар на апликации за да се консултира, немаше табла за да се потврди вкупниот износ - само математика зад покривот. И ова не беше млад ИТ аналитичар. Ова беше врвен извршен директор кој беше поставен фундаментално прашање за дигиталниот отпечаток на организацијата. Сценариите како ова зборуваат затоа што го нагласуваат отсуството на сигурен, постојано ажуриран регистар на апликации.Без него, компаниите се принудени да се потпираат на меморија, рачни листови и племенско знаење - сето тоа не успева во динамични, облак-базирани средини. Ако тимот за управување не може да го квантификува бројот на апликации во игра, како може да биде сигурен дека тие апликации се безбедни, усогласени и правилно управувани? Зошто инженерите и IAM тимовите треба да се грижат? Ако управувате со IAM, а апликацијата сеуште користи основна аутентификација без МФА, тоа е до вас, без разлика дали сте знаеле за апликацијата или не. И ако сте одговорни за одржување на работите во согласност, тој шестмесечен табела нема да ве заштити кога ревизор бара актуелни детали за пристап и аутентификација. 
 
 
 
 Знаете што е таму Знаете кој има пристап Знаете дали е безбедно И можете да го докажете тоа. Начинот на кој треба да се одржи чекор со светот на промените Откривањето оди подалеку од составувањето на листата и игра критична улога во откривањето на скриените ризици. Темни агли на облакот каде што наследни апликации, погрешно конфигурирани услуги или неовластени распоредувања се уште можат да работат тивко и незабележано. Пропуштените системи можат да станат вектори за напад, обврски за усогласеност или извори на неочекувани трошоци.Континуираното откривање го затвора лакот, давајќи им на тимовите за безбедност и идентитет мапа во реално време на нивната апликациска пејзаж - што работи, како е обезбедено и кој има пристап - за да можат да преземат одлучителни акции пред да се ескалираат проблемите. (Како што е забележано, Гери Гебел е професионално поврзан со компанија која работи во просторот за управување со идентитетот и безбедноста.

This writer has a vested interest be it monetary, business, or otherwise, with 1 or more of the products or companies mentioned within.

The is an opinion piece based on the author’s POV and does not necessarily reflect the views of HackerNoon.

This story contains new, firsthand information uncovered by the writer.

Sign up for Orchestration Kitchen workshops

Ова аудио е произведено на оригиналниот јазик на приказната!

Премногу долго; Да чита

Make resilience your competitive advantage

Cloud Sprawl е реална. Континуирано откривање е вашата најдобра одбрана

About Author

КОМЕНТАРИ

ВИСЕТЕ ТАГОВИ

ОВОЈ СТАТИЈА БЕШЕ ПРЕТСТАВЕН ВО

Related Stories

Light-Mode

Classic

Newspaper

Dark-Mode

Neon Noir

Minty

HN StartUps