Egy szabályozott adatokat kezelő API-t úgy tehet biztonságossá, hogy modellezi, ki élhet vissza vele, minden objektumnál és mezőnél ellenőrzi a jogosultságot, a lehető legkevesebb adatot gyűjti be és adja vissza, a titkos adatokat és az auditnaplókat pedig szigorú ellenőrzés alatt tartja. A gyakorlatban nem a feltört titkosítás a legfontosabb gyengeség, hanem a jogosultságkezelés hiányosságai és a túl sok adatot kiadó válaszok.
Az adatokra készítsen fenyegetésmodellt, ne a keretrendszerre
Mielőtt eszközöket választana, írja le, mit tesz elérhetővé az API, és ki élhet vissza vele. Egy banknál ez számla- és tranzakciós adatokat jelent; egy energetikai vagy közműcégnél mérési adatokat, ügyfélszerződéseket és a hálózatból származó üzemi mérési értékeket.
Egy hasznos fenyegetésmodell rövid. Felsorolja az érzékeny adatokat, minden hívót, amely hozzájuk férhet, azokat a műveleteket, amelyeket az egyes hívóknak végezniük szabad, és azt, mi történik, ha valamelyikük kompromittálódik. Ez a dokumentum vezérli az alábbi kontrollokat, és megmondja az ellenőrzőknek, mit teszteljenek.
- Mely adatok személyesek, bizalmasak vagy szabályozottak, és hol tárolják őket.
- Az API minden felhasználója: belső szolgáltatások, partnerek, mobilalkalmazások és adminisztrátorok.
- Mit olvashat, módosíthat vagy indíthat el mindegyik felhasználó.
- Egy kiszivárgott token, egy rosszindulatú belső munkatárs vagy egy kompromittált partnerrendszer hatása.
Hitelesítsen minden hívót, aztán minden objektumra ellenőrizze a jogosultságot
Felhasználóknál használjon szabványos protokollt, például OAuth 2.0-t OpenID Connecttel, szolgáltatások közötti hívásoknál pedig rövid életű tokeneket vagy kölcsönös TLS-t (mTLS). Kerülje a hosszú életű, közösen használt API-kulcsokat, mert senki sem tudja megmondani, melyik rendszer használta őket, és nem lehet visszavonni őket úgy, hogy más rendszerek ne sérüljenek.
A hitelesítés csak azt bizonyítja, ki a hívó. Az OWASP API Security Top 10 első tétele a hibás objektumszintű jogosultságkezelés (broken object level authorization): egy érvényes felhasználó megváltoztat egy azonosítót a kérésben, és elolvassa valaki más rekordját. Minden objektumnál, minden funkciónál és minden érzékeny mezőnél a szerveren ellenőrizze a tulajdonjogot vagy a bérlői hovatartozást, és soha ne bízzon meg a kliens által küldött azonosítóban vagy szerepkörben.
Minden kliens és szolgáltatás csak a feltétlenül szükséges jogosultságot kapja
A legkisebb jogosultság elve korlátozza a kárt, ha valami mégis elromlik. Adjon ki külön hitelesítő adatokat minden API-felhasználónak, a tokeneket korlátozza konkrét műveletekre, az adminisztratív végpontokat pedig tartsa külön útvonalon, szigorúbb ellenőrzéssel.
Ugyanezt a szabályt alkalmazza az API alatt is. A mérési adatokat olvasó szolgáltatásfiók ne tudja törölni őket, egy riportkészítő feladat pedig csak olvasási joggal rendelkező adatbázis-szerepkörrel csatlakozzon. A jogosultságokat rendszeres időközönként vizsgálja felül, mert az egyszeri feladatra adott hozzáférés hajlamos örökre megmaradni.
Gyűjtsön kevesebbet, adjon vissza kevesebbet, és tárolja rövidebb ideig
Az adattakarékosság egyszerre GDPR-elv és erős biztonsági kontroll: amit soha nem tárol, az nem is szivároghat ki. Minden mezőnél kérdezze meg, valóban szüksége van-e rá a szolgáltatásnak, és amire nincs, azt hagyja el vagy álnevesítse.
Ugyanezt a fegyelmet alkalmazza a válaszokra is. Teljes adatbázis-objektumok szerializálása helyett határozzon meg explicit válaszsémákat, maszkolja az olyan azonosítókat, mint a számlaszámok, ahol nincs szükség a teljes értékre, és állítson be megőrzési időket, hogy a régi rekordok törlődjenek. Dokumentálja az egyes adatkezelési célok jogalapját, és kössön adatfeldolgozói szerződést minden szolgáltatóval, amely kezeli az adatokat. Ez fejlesztési gyakorlat, nem jogi tanácsadás, ezért a jogi értékeléshez vonja be az adatvédelmi tisztviselőjét vagy jogi tanácsadóját.
Validáljon minden bemenetet, és korlátozza, mennyit használhat fel egy hívó
Minden kérést tekintsen ellenségesnek, amíg nem validálta. Minden végponthoz kényszerítsen ki sémát, utasítsa el az ismeretlen mezőket, és használjon paraméterezett lekérdezéseket, hogy a bemenet soha ne váljon egy adatbázis-parancs részévé.
Több OWASP API-kockázat nem rossz kódból, hanem hiányzó korlátokból fakad. Korlátozza a kérések számát kliensenként, szabjon felső határt az oldal- és az adatcsomagméretnek, és védje az érzékeny üzleti folyamatokat, például a fizetést vagy a szerződésmódosítást az automatizált visszaélések ellen. Ha az API a hívók nevében távoli URL-eket kér le, korlátozza a célpontokat, hogy megelőzze a szerveroldali kéréshamisítást (SSRF).
Tartsa távol a titkos adatokat a kódtól, a konténerképektől és a naplóktól
Az adatbázis-jelszavak, az aláírókulcsok és a partnerek hitelesítő adatai egy dedikált titokkezelőbe valók, ahonnan futásidőben kerülnek be, és ütemezetten cserélik őket. A build pipeline-ban vizsgálja át a repositorykat és a konténerképeket titkos adatok után kutatva, és minden titkot, amely a verziókezelőbe került, tekintsen kompromittáltnak.
Környezetenként válassza szét a titkokat, hogy egy kiszivárgott teszthitelesítő adat soha ne nyissa meg az éles környezetet. Korlátozza, ki olvashatja a titkokat az éles környezetben, és naplózzon minden hozzáférést.
Naplózzon az audithoz, és tervezzen kevesebb incidensre
A szabályozott környezeteknek utólag egy egyszerű kérdésre kell válaszolniuk: ki, mikor, melyik kliensen keresztül fért hozzá mely adatokhoz. Ezt rögzítse minden érzékeny olvasásnál és írásnál, a naplókat olyan helyen tárolja, ahol az alkalmazás üzemeltetői nem módosíthatják őket, és a naplóüzenetekbe ne kerüljön személyes adat.
A naplózás mellé társítson riasztásokat a szokatlan mintázatokra, például ha egy kliens a szokásosnál jóval több rekordot olvas, valamint egy tesztelt incidenskezelési tervet. A Sopra Steria révén mérnökeink biztonságos API-kat építettek érzékeny közműadatokhoz, szabályozási korlátok között, és egy üzemi felügyeleti eszköz fejlesztését vezették, ahol a kikényszerített biztonsági szabványok kevesebb éles incidenssel jártak együtt. Az SDK Enterprises ma ugyanezeket a gyakorlatokat alkalmazza az ügyfélprojektekben.
A legfontosabbak
- Az API minden biztonsági kontrollját egy rövid, írásos, az adatokra vonatkozó fenyegetésmodell vezérelje.
- A jogosultságot a szerveren ellenőrizze minden objektumnál, funkciónál és érzékeny mezőnél, ne csak bejelentkezéskor.
- A legkisebb jogosultság elve egyaránt vonatkozik a tokenekre, a szolgáltatásfiókokra és az adatbázis-szerepkörökre.
- Az adattakarékosság csökkenti a GDPR-kockázatot és bármely incidens hatását is.
- Az auditnaplóknak meg kell mutatniuk, ki mihez és mikor fért hozzá, anélkül hogy maguk személyes adatokat szivárogtatnának ki.
GYIK
Elég a HTTPS egy API védelméhez?
Nem. A TLS az átvitel közbeni adatokat védi, de sok API-incidensben hitelesített hívók férnek hozzá olyan adatokhoz, amelyeket nem láthatnának. A jogosultság-ellenőrzésekre, a bemenetek validálására, a kéréskorlátozásra és az auditnaplózásra továbbra is szükség van.
Mi az a hibás objektumszintű jogosultságkezelés?
Olyan hiba, amikor az API ellenőrzi, hogy a hívó be van-e jelentkezve, de azt nem, hogy a kért rekord hozzá tartozik-e. Ha valaki megváltoztat egy azonosítót az URL-ben vagy a kérés törzsében, más felhasználók adatai válnak láthatóvá. A megoldás egy tulajdonjog- vagy bérlőellenőrzés a szerveren minden objektumnál.
Előír-e a GDPR konkrét API-biztonsági kontrollokat?
A GDPR a kockázatnak megfelelő technikai és szervezési intézkedéseket követel meg, konkrét eszközök előírása nélkül. Az olyan kontrollok, mint a hozzáférés korlátozása, az adattakarékosság, az álnevesítés és a naplózás, gyakori módjai a követelmény teljesítésének, és jogi tanácsadóinak kell megerősíteniük, mi vonatkozik az Ön esetére.