"Ha a db-hez full hozzáfér az API" - mert ennek nem kéne igaznak lennie. Persze ha csinálsz egy full CRUD API-t god joggal, akkor annak pont semmi értelme secu szempontból (más szempontból lehet, de az most irreleváns).
Normál esetben ennek így kéne kinézni:
- Kliens hív 443-at, amit egy határvédelmi eszköz végződtet. Mivel ismert az API tartalma, így lehet szűrni, hogy csak a protokollnak megfelelő dolgot a megengedett értékkészlettel hívja. Ha ezen nem megy át, az alkalmazásszerverig el sem jut. Ha nincs WAF, akkor ezt a validációt az alkalmazásszerveren kell megtenni (ott amúgy is illik, de azért érdemes előtte is megfogni, mert akkor nem a kiszolgáló komponenst terheli egy próbálkozó fals forgalom, plusz azt veri szemmel a SoC, nekik könnyebb WAF logot olvasni mint a fejlesztő által kreált alkalmazás logot.
- Tegyük fel az előző pontot valahogy megugrotta a hacker barátunk, akkor bent ül egy alaklmazás szerveren, ahonnan alapesetben nem kezdeményezhet forgalmat internet felé, csak és kizárólag a DB felé, optimális esetben szintén protokollszűrt módon, ezért marha nehezen jut hozzá a kedvenc szerszámaihoz
- Tegyük fel, valahogy ezt is megoldotta, és az alkalmazás szerveren már tudott privilégium szintet emelni vagy netán root shell-hez jutni, és így megszerezte a connection string-et
- Ekkor egy korlátozott (!) user-rel már hozzáfér a DB-hez, amiben csak és kizárólag az alkalmazásnak feltétlen szükséges dolgokat éri el. Legyen mindent is tudó alkalmazás, azaz mindent tud írni és olvasni. Ekkor el tudja lopni az adatokat, a jelen állapotot el is tudja rontani, de nem tud hozzáférni a WAL-hoz/mentéshez/replikához, így a működés hamar helyreállítható.
Tehát "csak" adatlopásig jut, azt is baromi nehezen, ha elrontott valamit, hamar helyreállítható, kivéve ha az alkalmazásszerver mellett a db is épp tele van ismert kritikus hibákkal, de az meg már az üzemeltetés trehányságára utal, mert annak, hogy két független komponensben egyszerre jelenik meg kritikus zero day, arra extrém pici az esély, legalábbis sokkal kisebb, minthogy évek óta nem patch-elték egyiket sem.
Ráadásul ha az alkalmazásszerver horizontálisan skálázott, állapotmentes, akár "serverless", akkor pláne baromi nehéz dolga van a támadónak, mert minden próbálkozása random példányokon végződik, így nehezen tud lépésről lépésre haladni, mert a már recsegő példány helyett kap újat.
Ha simán csak kint van a DB a neten, akkor az egyetlen lépés, hisz kliens oldalon ott van a hozzáférés, és a full technikai infó a DB típusáról, verziójáról stb. Azaz onnantól csak várni kell a biztonsági híreket, és ha az adott db verzióban megjelenik egy komolyabb hiba, abban a pillanatban mindenestül a támadóé.