Az átvétel nem egyszerűen a jelszavak elkérése

Egy meglévő weboldal, webshop, webalkalmazás vagy mobilapp átvételekor a felhasználók azt látják, hogy a rendszer működik. A háttérben azonban lehet hiányos dokumentáció, lejárt csomag, egyetlen emberhez kötött hozzáférés, nem tesztelt mentés vagy olyan egyedi kód, amelyet évek óta senki nem frissített.

Ezért professzionális szolgáltató nem vállalhat felelősen teljes körű üzemeltetési vagy fejlesztési kötelezettséget pusztán egy URL és egy adminjelszó alapján. Először rendszerátvételi auditot kell végezni.

Miért kockázatos egy átvett rendszer?

Az új fejlesztésnél az architektúra és a folyamatok kontrollálhatók. Átvételnél öröklünk minden korábbi döntést:

  • technológiai kompromisszumokat;
  • elmaradt frissítéseket;
  • dokumentálatlan üzleti szabályokat;
  • adatminőségi problémákat;
  • jogosultsági hibákat;
  • külső szolgáltatói függőségeket;
  • ismeretlen szerződéses vagy licencfeltételeket;
  • technikai adósságot.

Ezek egy része csak használat vagy célzott vizsgálat közben derül ki.

1. Üzleti és funkcionális kép

Mielőtt a kódot vizsgáljuk, meg kell érteni:

  • mire használják a rendszert;
  • mely funkciók üzletkritikusak;
  • kik a felhasználók;
  • milyen időszakokban nagy a forgalom;
  • milyen ismert hibák vannak;
  • milyen változtatások várhatók;
  • mi okozna jelentős üzleti kárt.

Egy technikailag apró hiba is lehet P1 prioritású, ha megállítja a rendelést vagy a számlázást.

2. Hozzáférési leltár

Össze kell gyűjteni és tulajdonoshoz rendelni:

  • domainregisztrátor;
  • DNS;
  • tárhely, VPS vagy cloud;
  • forráskód-repository;
  • CI/CD;
  • adatbázis;
  • adminfelületek;
  • e-mail és SMTP;
  • külső API-k;
  • fizetési és számlázási fiókok;
  • App Store és Google Play;
  • analytics és monitoring;
  • backup tárhely;
  • titkok és kulcsok.

A hozzáférést nem közös, névtelen jelszóval érdemes átadni. Személyhez kötött fiók, megfelelő szerepkör és többfaktoros hitelesítés szükséges.

3. Tulajdonjog és szerződéses helyzet

Technikai átvétel előtt tisztázni kell:

  • kié a domain;
  • kié a forráskód;
  • átadható-e a licenc;
  • vannak-e fizetős komponensek;
  • használható-e tovább a design és a média;
  • milyen külső szerződések futnak;
  • van-e megszüntetési vagy átadási kötelezettség.

A fejlesztői hozzáférés nem feltétlenül jelent felhasználási vagy tulajdonjogot.

4. Forráskód és verziókezelés

Ellenőrizendő:

  • teljes-e a repository;
  • egyezik-e az éles rendszerrel;
  • van-e értelmezhető branch- és release-folyamat;
  • rendelkezésre áll-e build-leírás;
  • vannak-e titkok a kódban;
  • milyen a kód szerkezete és olvashatósága;
  • van-e automatikus teszt;
  • mennyi a technikai adósság;
  • mely komponensek elavultak.

Külön kockázat, ha csak az éles szerveren lévő fájlok léteznek, és nincs megbízható verziótörténet.

5. Függőségek és szoftverellátási lánc

A rendszer sok külső csomagra épülhet. Meg kell nézni:

  • mely verziók futnak;
  • támogatottak-e;
  • tartalmaznak-e ismert sérülékenységet;
  • honnan származnak;
  • milyen licencek vonatkoznak rájuk;
  • reprodukálható-e a build;
  • vannak-e egyedi vagy elhagyott forkok.

A modern biztonsági kockázatok között a szoftverellátási lánc kezelése önálló terület, ezért nem elég csak a saját kódot vizsgálni.

6. Adatbázis és adatminőség

Fontos kérdések:

  • milyen adatok vannak a rendszerben;
  • van-e dokumentált séma;
  • érvényesülnek-e adatbázis-korlátok;
  • vannak-e duplikált vagy árva rekordok;
  • mekkora az adatállomány;
  • milyen a mentési és visszaállítási folyamat;
  • vannak-e lassú lekérdezések;
  • hogyan történik az adatmegőrzés és törlés;
  • elkülönülnek-e az ügyféladatok.

Adatbázis-módosítás előtt mindig szükséges mentés, migrációs terv és visszaállási lehetőség.

7. Infrastruktúra

Fel kell térképezni:

  • operációs rendszer és támogatottság;
  • webszerver és futtatási környezet;
  • konténerek;
  • hálózati szabályok;
  • TLS és tanúsítványok;
  • erőforrás-használat;
  • logok;
  • háttérfolyamatok és ütemezők;
  • skálázási korlátok;
  • single point of failure elemek;
  • staging környezet.

Ha nincs külön tesztkörnyezet, minden javítás nagyobb kockázatot jelent.

8. Biztonság

A minimum áttekintés általában kiterjed:

  • hitelesítés és jelszópolitika;
  • adminfelületek;
  • szerepkörök és jogosultságok;
  • nyilvános végpontok;
  • titkok és API-kulcsok;
  • feltöltések;
  • naplózás;
  • rate limiting;
  • frissítési állapot;
  • személyes adatokhoz való hozzáférés;
  • incidenskezelési lehetőség.

A részletes penetration test külön scope lehet. Az átvételi audit célja először a legnagyobb működési és biztonsági kockázatok azonosítása.

9. Monitoring, mentés és helyreállítás

Nem elegendő megkérdezni, hogy „van-e backup”. Ellenőrizni kell a tényleges mentési eredményt és lehetőség szerint próba-visszaállítást kell végezni.

Vizsgálandó:

  • uptime monitoring;
  • alkalmazás- és hibalog;
  • erőforrásriasztás;
  • backup gyakoriság és retention;
  • off-site mentés;
  • restore runbook;
  • RPO és RTO elvárás;
  • incidensértesítés.

10. Dokumentáció és tudásátadás

Hasznos dokumentumok:

  • architektúraáttekintés;
  • deploy leírás;
  • környezeti változók;
  • integrációk;
  • adatmodell;
  • adminútmutató;
  • ismert hibák;
  • üzleti szabályok;
  • supporttörténet;
  • kapcsolattartók.

Ha ezek hiányoznak, az audit eredményének része lehet a minimális dokumentáció elkészítése.

A 30/60/90 napos stabilizálási terv

Első 30 nap: kontroll

  • hozzáférések rendezése;
  • kritikus mentés;
  • monitoring;
  • P0/P1 kockázatok;
  • titkok és adminfiókok;
  • dokumentációs minimum.

31-60. nap: stabilitás

  • függőségek és frissítések;
  • staging és release-folyamat;
  • fő tesztek;
  • adatbázis- és teljesítményproblémák;
  • naplózás és riasztás.

61-90. nap: fejleszthetőség

  • technikai adósság roadmap;
  • refaktorálási prioritások;
  • automatizált teszt bővítése;
  • új funkciók biztonságos tervezése;
  • üzemeltetési SLA véglegesítése.

Mikor mondhatja azt egy szolgáltató, hogy nem vállalja át?

Felelős döntés lehet az elutasítás, ha:

  • nincs jogszerű hozzáférés vagy forráskód;
  • az adatbiztonság nem helyreállítható elfogadható keretben;
  • az ügyfél nem engedi a kritikus hibák javítását;
  • nem tisztázható a tulajdonjog;
  • irreális SLA-t várnak szükséges infrastruktúra nélkül;
  • a rendszer teljes újraírása gazdaságosabb, mint a javítás.

A BT Digital megközelítése

Átvételkor először nem ígérünk korlátlan supportot. Rövid audit során feltérképezzük a rendszer állapotát, majd kockázati prioritással adunk stabilizálási tervet.

Az átvétel célja nem az, hogy valaki gyorsan „hozzányúljon” a rendszerhez, hanem hogy a működés, a hozzáférés és a felelősség ismét kontrollálható legyen.