Kur një integrim hap më shumë se një derë

Sistemet moderne rrallë funksionojnë të izoluara. Një platformë mund të lidhet me email-in, një databazë, një sistem dokumentesh, një shërbim cloud apo një aplikacion të jashtëm.

Këto integrime eliminojnë shumë procese manuale dhe u lejojnë sistemeve të punojnë si një ekosistem i vetëm. Por çdo lidhje krijon edhe një marrëdhënie besimi: Sistemi A merr të drejtën të kryejë veprime brenda Sistemit B.

Kjo e ndryshon mënyrën si duhet menduar siguria. Nuk mjafton të pyesim nëse secili sistem është i mbrojtur më vete. Duhet të dimë edhe çfarë mund të arrijë një sistem përmes lidhjeve që ka me të tjerët.

Një integrim nuk transporton vetëm të dhëna

Marrim një platformë që lidhet me një sistem dokumentesh.

Integrimi mund të ketë të drejtë të lexojë dokumente, të krijojë të reja ose të ndryshojë informacion ekzistues. Një integrim tjetër mund të komunikojë me email-in, ndërsa një tjetër me një databazë ose platformë financiare.

Në secilin rast, lidhja përmban më shumë se një kanal komunikimi. Ajo përmban një nivel aksesi.

Pikërisht këtu lind një pyetje e rëndësishme gjatë projektimit të sistemit: nëse një komponent komprometohet, deri ku mund të shkojë duke përdorur aksesin që sistemi i ka dhënë në mënyrë legjitime?

Ky nuk është vetëm një skenar teorik. Microsoft dokumenton se aplikacionet cloud mund të përdorin connectors që ruajnë autorizime për email, SaaS, databaza dhe shërbime të tjera. Nëse një sulmues merr kontroll mbi burimin që menaxhon connector-in, ai mund ta përdorë atë akses për të kaluar drejt shërbimit të lidhur, pa pasur domosdoshmërisht nevojë të nxjerrë kredencialet origjinale.

Një sistem i besuar mund të bëhet rruga drejt një sistemi tjetër

Kjo krijon një situatë interesante.

Sistemi B mund të jetë i konfiguruar saktë. Kredencialet e përdoruesve mund të jenë të mbrojtura. Autentikimi mund të funksionojë siç duhet.

Megjithatë, nëse Sistemi A ka tashmë një lidhje të autorizuar me të, komprometimi i Sistemit A mund ta ndryshojë të gjithë ekuacionin e sigurisë.

Në cloud security kjo lidhet me konceptin e lateral movement: një pikë hyrëse përdoret për të arritur burime të tjera të lidhura. Microsoft thekson se attack paths në aplikacionet cloud mund të kalojnë nga kodi i aplikacionit te identitetet, connectors, databazat dhe shërbimet e tjera cloud.

Prandaj arkitektura e sigurisë duhet të shohë jo vetëm komponentët, por edhe rrugët që krijohen mes tyre.

Problemi nuk është integrimi. Problemi është sa larg shtrihet aksesi

Një integrim ka nevojë për privilegje që të funksionojë. Por nuk ka arsye të marrë më shumë akses sesa kërkon funksioni i tij.

Nëse një proces duhet vetëm të lexojë një kategori të caktuar dokumentesh, aksesimi i gjithë repository-t krijon një sipërfaqe më të madhe ekspozimi. Nëse një shërbim duhet vetëm të dërgojë informacion, aftësia për ta ndryshuar ose fshirë atë krijon privilegje që procesi nuk i kërkon.

Këtu parimi least privilege bëhet pjesë e vetë projektimit të integrimit: çdo lidhje merr vetëm të drejtat që i duhen për funksionin që kryen.

Ky kontroll po bëhet gjithnjë e më i rëndësishëm ndërsa ekosistemet software lidhen me më shumë aplikacione dhe shërbime. Microsoft, për shembull, ofron tashmë attack-path mapping për aplikacionet OAuth për të identifikuar se si një aplikacion i lidhur mund të krijojë rrugë drejt shërbimeve dhe të dhënave sensitive.

Lidhjet duhet të projektohen me të njëjtën kujdes si vetë sistemet

Kur ndërtohet një platformë e integruar, pyetjet e sigurisë duhet të vazhdojnë përtej “me çfarë sistemi lidhemi?”.

Çfarë të drejtash ka kjo lidhje? Cilat të dhëna mund të lexojë? Çfarë mund të ndryshojë? A mund të përdoret i njëjti autorizim nga një komponent tjetër? Çfarë ndodh nëse integrimi nuk përdoret më? Dhe mbi të gjitha: çfarë sistemi tjetër mund të arrihet prej tij?

Këto pyetje ndihmojnë që një integrim të mos kthehet pa dashje në një urë drejt pjesëve të tjera të ekosistemit.

Raste reale të viteve të fundit kanë treguar pikërisht këtë efekt. Microsoft ka dokumentuar incidente ku OAuth tokens dhe integrime të besuara SaaS janë përdorur për akses të vazhdueshëm në sisteme CRM dhe, në disa raste, për zgjerim drejt platformave të tjera të lidhura.

Siguria e një ekosistemi përcaktohet edhe nga lidhjet mes tij

Në Soft & Solution Group, integrimi nuk trajtohet vetëm si shkëmbim të dhënash mes dy aplikacioneve. Mënyra si sistemet autentikohen, çfarë privilegjesh marrin dhe deri ku mund të arrijë secila lidhje janë pjesë e arkitekturës së integrimit.

Siç shprehet Ermal Beqiri, themelues i Soft & Solution Group:

“Kur lidhim dy sisteme, nuk krijojmë vetëm një rrugë për të dhënat. Krijojmë edhe një marrëdhënie besimi. Arkitektura duhet të përcaktojë qartë deri ku shtrihet ky besim dhe çfarë mund të bëjë secila lidhje.”

Sa më shumë sisteme bashkëpunojnë, aq më shumë lidhjet mes tyre bëhen pjesë e sipërfaqes që duhet mbrojtur.

Sepse një integrim i projektuar mirë nuk përcakton vetëm si hapet një derë, por edhe sa larg mund të shkohet pasi ajo derë është hapur.