Rad sa DevOps agencijom ne zahteva automatski pun pristup vasoj infrastrukturi.

U Techpipe-u, informacije i pristup prate zadatak. Pocinjemo sa minimalnim materijalom potrebnim da razumemo problem, dizajniramo pilot oko najmanjeg prakticnog otkrivanja informacija i uvodimo pristup infrastrukturi tek kada dogovoreni rezultat to zahteva.

Kontrole na ovoj stranici cine podesivu osnovu. Tacna kombinacija zavisi od vase arhitekture, politika, modela rizika, dostupnih alata i dodeljenih odgovornosti Techpipe-a.

Za potpunu sekvencu angazovanja, pogledajte Kako radimo. Za krace ugovorne i procesne odgovore, pogledajte FAQ.

Pristup je posledica opsega

Opseg treba da odredi pristup — a ne obrnuto.

Pre nego sto zatrazimo pristup infrastrukturi, prvo razmatramo da li se posao moze zavrsiti uz pomoc:

• arhitektonskih dijagrama i dokumentacije;
• odabranih repozitorijuma ili CI/CD konfiguracije;
• sanitizovanih ili sintetickih podataka;
• izvezenih logova, metrika, trace-ova i zapisa o incidentima;
• deljenja ekrana ili sesije koju vodi klijent;
• izolovanog lab, razvojnog ili staging okruzenja;
• ogranicenog pregleda samo za citanje;
• promene koju izvrsi klijent, a pripremi i pregleda Techpipe.

Ovo je posebno korisno tokom pocetne procene i placenog pilota, kada je cilj proceniti inzenjere i model rada bez stvaranja nepotrebnog izlaganja produkcije.

Nijedna faza ne daje automatski neogranicen pristup. Ako se zadatak moze bezbedno zavrsiti sa manje, koristimo manje.

Zivotni ciklus pristupa

Pristup treba da ima jasan cilj, vlasnika, odobrenje, uslov pocetka i uslov zavrsetka.

  flowchart LR
    A["Zahtev<br/>Svrha i opseg"]
    B["Odobrenje<br/>Vlasnik i uslovi"]
    C["Dodela<br/>Imenovan, ogranicen pristup"]
    D["Upotreba i pregled<br/>Evidencija, nadzor, podesavanje"]
    E["Opoziv<br/>Zatvaranje i provera"]

    A --> B
    B --> C
    C --> D
    D --> E

Pre nego sto se pristup dodeli, dogovaramo se o:

• sistemima i okruzenjima koja su u opsegu;
• radnjama koje dodeljeni inzenjeri mogu da izvrse;
• potrebnom nivou dozvole;
• odobrenom putu povezivanja;
• zahtevima za autentifikaciju i uredjaj;
• da li povecane privilegije zahtevaju posebno odobrenje;
• zahtevima za logovanje i dokazivanje;
• uslovima isteka, pregleda i opoziva;
• kontaktima za incidente i eskalaciju.

Poverljivost i NDA

Techpipe moze da potpise NDA pre nego sto se podele osetljive tehnicke ili poslovne informacije.

Poverljivost je podrzana i operativno. NDA ne zamenjuje kontrolu pristupa niti opravdava sire otkrivanje informacija. Cilj nam je da:

• trazimo samo informacije relevantne za dogovoreni posao;
• ogranicimo pristup na dodeljene inzenjere;
• koristimo odobrene kanale za skladistenje i komunikaciju;
• izbegavamo kopiranje produkcionih podataka osim ako zadatak to eksplicitno zahteva;
• koristimo sanitizovane ili sinteticke podatke gde je to prakticno;
• dogovorimo zahteve za cuvanje i brisanje dostavljenih materijala;
• izbegavamo da kredencijale ili tajne smestamo u tikete, chat poruke, dokumente ili izvorni kod.

Svaki regulatorni, geografski, ugovorni ili zahtev vezan za obradu podataka specifican za klijenta treba identifikovati pre deljenja relevantnog materijala.

Osnovni principi pristupa

Nas podrazumevani pristup zasniva se na sledecim principima:

• Najmanje neophodan pristup. Dozvole su ogranicene na zadatak i odgovornost.
• Imenovani identiteti. Svaki dodeljeni inzenjer koristi individualni nalog koji se moze pripisati osobi, gde platforma to podrzava.
• Bez neformalnog deljenja kredencijala. Lozinke, privatni kljucevi, tokeni i kodovi za oporavak ne razmenjuju se u obicnom chatu ili tiketima.
• Razdvajanje okruzenja. Pristup razvoju, staging-u i produkciji moze biti dodeljen nezavisno.
• Posebna eskalacija. Rutinski pristup i privilegovane radnje ne moraju koristiti isti nivo dozvole.
• Vremenska ogranicenja gde je prakticno. Privremeni ili just-in-time pristup je pozeljan za povremeni osetljiv rad.
• Mogucnost revizije. Autentifikacija, privilegovane radnje i promene treba da budu pripisive kroz kontrole dostupne u vasem okruzenju.
• Brz opoziv. Pristup se uklanja kada zadatak, odgovornost, pilot ili ugovor zavrsi.

Pravila povezivanja i koriscenja

Tacna pravila se dogovaraju sa svakim klijentom. Tipican profil pristupa moze zahtevati:

• povezivanje samo preko odobrenog VPN-a, bastion hosta, PAM platforme ili identity-aware proxy-ja;
• individualni nalog zasticen MFA-om;
• koriscenje naloga kojim upravlja klijent umesto zajednickog Techpipe identiteta;
• pristup samo sa odobrenih uredjaja ili izvorskih adresa;
• bez lokalnog preuzimanja produkcionih podataka osim ako je izricito odobreno;
• bez neodobrenog izvoza, prosledjivanja ili zadrzavanja kredencijala;
• promene kroz dogovoreni proces za tikete, pregled, CI/CD i upravljanje promenama;
• rad u okviru dogovorenih prozora za odrzavanje ili procedura za incidente;
• logovanje sesija ili komandi gde je podrzano i odgovarajuce;
• trenutno prijavljivanje sumnje na gubitak kredencijala, neocekivan pristup ili bezbednosni dogadjaj.

Ovi uslovi mogu biti strozi za produkciju, regulisane podatke ili privilegovane uloge nego za dokumentaciju i neprodukcione sisteme.

Visefaktorska autentifikacija (MFA)

MFA treba omoguciti za infrastrukturu, cloud, source control, CI/CD, monitoring, tajne, VPN i administrativni pristup gde god platforma to podrzava.

Preferovani metod prati vasu politiku i mogucnosti platforme. Metodi otporni na phishing, kao sto su bezbednosni kljucevi zasnovani na hardveru ili passkeys, mogu biti obavezni za osetljiv pristup. Vremenski ogranicene jednokratne lozinke mogu se koristiti tamo gde jaci metodi nisu dostupni.

Kodni brojevi za oporavak i fallback metode treba da se tretiraju kao kredencijali. MFA ne treba zaobilaziti deljenjem vec autentifikovanog naloga ili sesije.

Upravljanje identitetom i pristupom (IAM)

IAM mapira identitet inzenjera na posao koji je ovlascen da obavlja.

Prakticno IAM podesavanje treba da favorizuje:

• individualne identitete umesto zajednickih naloga;
• single sign-on ili federaciju gde je to odgovarajuce;
• uloge i grupe umesto jednokratnih direktnih dodela;
• dozvole razdvojene po okruzenju i odgovornosti;
• politike deny by default ili najmanjih privilegija;
• eksplicitno vlasnistvo i odobrenje za osetljive uloge;
• periodican pregled aktivnih identiteta i dozvola;
• brzo onemogucavanje kada inzenjer napusti angazman.

Gde klijent upravlja centralnim identitetima, Techpipe inzenjeri mogu koristiti naloge kojima upravlja klijent i pratiti klijentov proces za dolazak, promenu i odlazak korisnika.

Privilegovani pristup

Privilegovani pristup obuhvata dozvole koje mogu menjati bezbednosne kontrole, produkcionu infrastrukturu, identitet, umrezavanje, podatke, bekapove ili druge kriticne sisteme.

Trajni administratorski pristup nije podrazumevan. U zavisnosti od zadatka, privilegovani rad moze koristiti:

• zasebnu administrativnu ulogu ili nalog;
• odobrenje pre eskalacije;
• pristup ogranicen na specifican sistem ili okruzenje;
• definisan prozor odrzavanja ili incidenta;
• peer review ili odobrenje cetiri oka;
• komande ili promene koje izvodi klijent;
• snimanje sesije i logovanje komandi;
• automatski isteka nakon zavrsetka rada.

Hitni pristup, ako je potreban, treba da ima sopstvenu proceduru aktivacije, obavestavanja, pregleda i rotacije kredencijala.

Just-in-time pristup

Just-in-time (JIT) pristup dodeljuje dozvole samo kada su potrebne i uklanja ih nakon definisanog perioda.

JIT je koristan za:

• povremenu dijagnostiku produkcije;
• zakazano odrzavanje;
• migracije i objave;
• odgovor na incident;
• privremeni pristup osetljivim logovima, podacima ili administrativnim funkcijama.

JIT tok moze ukljucivati tiket ili zahtev, odobrenje od strane vlasnika klijenta, automatsku aktivaciju uloge, kratak rok vazenja, dodatni MFA, logovanje aktivnosti i pregled nakon pristupa.

Gde automatizovani JIT alati nisu dostupni, isti princip moze se sprovesti kroz dokumentovan manuelni postupak dodele i opoziva.

VPN

VPN moze ograniciti pristup infrastrukturi na odobreni mrezeni put i poznate identitete ili uredjaje.

Kada se koristi VPN pristup, dogovaramo se o:

• tome da li je pristup vezan za korisnika, uredjaj ili oboje;
• zahtevima za MFA i sertifikat;
• dozvoljenim mrezama, rutama, portovima i okruzenjima;
• ocekivanjima za split-tunnel ili full-tunnel;
• ogranicenjima po izvorskoj adresi i uredjaju;
• logovanju, isteku i opozivu;
• da li VPN daje samo mreznu dostupnost ili i autorizaciju za pojedinacne servise.

VPN konekcija nije zamena za IAM. Dostizanje mreze ne treba automatski da dodeli sire dozvole unutar nje.

Bastion hostovi

Bastion host pruza kontrolisanu ulaznu tacku za administrativni pristup inace privatnim sistemima.

Klijentski bastion moze da sprovodi:

• imenovane naloge i MFA;
• ogranicenja po izvoru;
• kratkotrajne SSH sertifikate ili kljuceve;
• pristup samo odobrenim ciljnim sistemima;
• centralno logovanje sesija i komandi;
• onemogucen direktan pristup privatnim hostovima;
• posebne dozvole za staging i produkciju;
• trenutni opoziv na ulaznoj tacki.

Kredencijali koji se koriste van bastiona treba da ostanu ograniceni na ciljne sisteme. Bastion treba da smanji i zabelezi put pristupa, a ne da postane izvor zajednickih trajnih kredencijala.

Upravljanje privilegovanim pristupom (PAM)

Gde je PAM platforma dostupna, Techpipe moze koristiti klijentov uspostavljen tok za privilegovane sesije.

PAM moze obezbediti:

• preuzimanje naloga ili pokretanje sesije na osnovu odobrenja;
• automatsko ubacivanje kredencijala bez otkrivanja tajne;
• privremene privilegovane naloge ili uloge;
• snimanje sesije i audit komandi;
• rotaciju kredencijala nakon upotrebe;
• ogranicenja po korisniku, sistemu, vremenu i svrsi;
• hitne ili break-glass tokove.

PAM zahtevi treba da budu definisani pre pilota ako pilot zahteva privilegovan pristup, jer dodela i odobrenja mogu uticati na raspored.

Upravljanje tajnama

Kredencijali i tajne treba da se skladiste i dostavljaju kroz odobreni mehanizam za upravljanje tajnama, a ne da budu ugradjeni u izvorni kod, CI/CD promenljive kopirane izmedju projekata, dokumente ili chat poruke.

U zavisnosti od okruzenja, ovo moze ukljucivati:

• centralni secrets manager ili vault;
• cloud-native skladista tajni;
• workload identity umesto statickih kredencijala;
• kratkotrajne tokene, sertifikate ili SSH kredencijale;
• ogranicene service account naloge;
• automatsku rotaciju;
• odvojene tajne za okruzenja i servise;
• revizijom pracen pristup osetljivim vrednostima.

Techpipe treba da primi samo tajne potrebne za dodeljeni zadatak. Kad god je moguce, sistemi treba direktno da ubacuju kredencijale kako bi inzenjeri mogli da koriste ovlascenu funkciju bez pregleda ili kopiranja same tajne.

Svaki kredencijal otkriven tokom otklanjanja problema ili ukljucen u preneti materijal treba smatrati kompromitovanim i rotirati.

Promene u produkciji

Pristup produkciji i dozvola za promenu produkcije su odvojene odluke.

Pre produkcionih promena, dogovaramo se o primenljivom procesu, koji moze ukljucivati:

• odobren tiket ili zahtev za promenu;
• pregled koda i Infrastructure as Code;
• automatizovanu validaciju i CI/CD implementaciju;
• prozor odrzavanja;
• proveru bekapa ili oporavka;
• korake za rollback i uslove za zaustavljanje;
• pracenje tokom i nakon promene;
• odobrenje klijenta za akcije velikog uticaja;
• dokumentovan rezultat i eventualni naknadni rad.

Tokom incidenta, dogovoreni hitni proces moze skraciti normalan put, ali akcija, odluka i ishod i dalje treba naknadno da budu dokumentovani.

Logovanje, pregled i prijavljivanje incidenata

Gde vaši alati to podrzavaju, pristup i znacajne akcije treba da budu pripisive pojedinacnom identitetu i cuvane u skladu sa vasom politikom.

Relevantni dokazi mogu ukljucivati:

• autentifikacione dogadjaje identitetskog provajdera;
• cloud, Kubernetes, operativni sistem, bazu podataka, VPN, bastion i PAM logove;
• istoriju source control i CI/CD;
• odobrenja tiketa i zapise o promenama;
• dogadjaje pristupa secrets manager-u.

Ako dodeljeni inzenjer otkrije neocekivane dozvole, sumnju na izlaganje kredencijala, neovlascenu aktivnost ili drugi bezbednosni problem, rad koji utice na relevantni sistem treba po mogucstvu pauzirati kada je to bezbedno i dogovoreni kontakt klijenta treba odmah obavestiti.

Putanja incidenta, vreme odziva, cuvanje dokaza, ovlascenje za izolaciju i komunikacione odgovornosti treba da budu dogovoreni pre pocetka rada visokog rizika ili managed-service rada.

Opoziv i offboarding

Uklanjanje pristupa je deo angazmana, a ne naknadna misao.

Kada pilot zavrsi, inzenjer napusti angazman, odgovornosti se promene ili ugovor bude zavrsen, checklist za offboarding moze ukljucivati:

• onemogucavanje naloga kojima upravlja klijent;
• uklanjanje IAM uloga i clanstva u grupama;
• prekid aktivnih sesija;
• opoziv VPN, bastion, PAM i JIT dozvola;
• opoziv tokena, sertifikata, SSH kljuceva i API kredencijala;
• rotaciju deljenih ili potencijalno izlozenih tajni;
• uklanjanje pristupa repozitorijumima, CI/CD-u, monitoringu i dokumentaciji;
• potvrdu primopredaje i postupanja sa zadrzanim materijalima klijenta.

Klijent ostaje u kontroli sistema u svom vlasnistvu i moze opozvati pristup u bilo kom trenutku.

Podeljena odgovornost

Bezbednosne odgovornosti zavise od modela angazovanja i moraju biti eksplicitne.

Pre pocetka rada, obe strane treba da razumeju:

• koje sisteme Techpipe upravlja, menja, posmatra ili o njima savetuje;
• koje odluke zahtevaju odobrenje klijenta;
• ko je vlasnik dodele i opoziva identiteta;
• ko upravlja bekapima, oporavkom, zakrpama, sertifikatima, tajnama i monitoringom;
• ko objavljuje i koordinise incident;
• koja pokrivenost i ciljevi odziva vaze;
• sta ostaje iskljucivo odgovornost klijenta.

Techpipe-ov pristup ne prenosi vlasnistvo nad bezbednosnim programom klijenta, obavezama uskladjenosti ili poslovnim odlukama, osim ako specificna odgovornost nije izricito ukljucena u ugovor.

Definisite profil pristupa za vas pilot

Recite nam koji problem zelite da testirate, koje informacije mozete da podelite i koja ogranicenja pristupa vaze. Identifikovacemo pilot scenario koji koristi najmanje prakticno otkrivanje informacija i upoznati vas sa inzenjerima predlozenim za rad.

Zahtevajte pocetnu procenu