Miért és hogyan kell biztonságosítani az API végpontot?

Hogyan biztosítja az API-ját??


Ez a digitális gazdaság robbanásának kora, és az API-k révén hatalmas adatterheléseket vezetnek be. Üzleti, játék, oktatás, tudomány, művészetek. . . nevezted, minden működik az API-ken. Egy olyan világban, amely olyan alapvetően támaszkodik az API-kra, meglepően kevés a hangsúly a biztonságra.

A fejlesztők számára elegendő a keretrendszer alapértelmezése; vagy ami még rosszabb, ha nem használnak kereteket, azt gondolják, hogy biztonságos gyakorlatokat követnek. A rendszergazdák számára az infrastruktúra vagy a szolgáltató által kínált alapértelmezett biztonság az, amelyre támaszkodnak.

Egyáltalán nem szép látvány, ha kérdezel tőlem.

Forrás: developer.ibm.com

Mondanom sem kell, hogy sok a kockázat, amit csak akkor észlelünk, ha valami igazán szörnyű megtörténik.

De az első dolgok először. ��

Miért biztonságos az API végpontok??

Ennek nem szabad gondolkodnia, igaz? Biztosítanunk kell a végpontokat, mert nos, ez az, amelytől az üzlet függ.

Noha ez önmagában elég erős érv, szeretnék egy kicsit kibővíteni a nézőpontot, és kiemelni más kapcsolódó, de ugyanolyan halálos következményeket..

Üzleti veszteség

Ez a nyilvánvaló. Ha valakinek sikerül megzavarnia az Ön API-végpontjait, mindent egy csikorgó megállít. A biztonsági szabálysértések sok időt vehetnek igénybe a helyreállásból, ami üzleti szempontból öngyilkosságra utal. Noha igaz, hogy a legtöbb vállalkozást valószínűleg nem érinti egy vagy két órás állásidő, néhány esetben ez nem megengedett.

Képzelje el, hogy egy valutacsere néhány percre leáll!

Megfelelőségi kérdések

Ha nem biztosítja az API-kat, akkor súlyos bajokba kerülhet, attól függően, hogy mely földrajzi vagy iparágakkal foglalkozik. Például, ha a bankipart szolgálja (különösen az EU-ban), a nem biztonságos API-kkal történő kiszolgálás felfedezésének költségei hatalmas jogi és megfelelési problémákat okoznak. Olyannyira, hogy akár a vállalkozása vége is helyes lehet.

Hírnév veszteség

A hackelés már önmagában is elég fájdalmas, de ha a hírek megjelennek a nyilvánosságban, akkor márkanevének helyrehozhatatlan vesztesége lesz. Például a Sony-t már néhányszor nagyon rosszul csapkodták be, és a biztonsági körökben a vállalat egy nevetség tárgya fajta.

Még ha ténylegesen sem adatvesztés, sem pénz nem merül fel, sok szerencsét próbál meggyőzni az ügyfelekről. ��

Felfújt infrastrukturális számlák

Amikor az API infrastruktúrán fut, erőforrásokat (főleg sávszélességet, CPU-t és memóriát) fogyaszt. Például, ha az API-t nem megfelelően biztosítják, és a rosszindulatú kívülállók képesek együttműködni vele, lehetséges, hogy arra kényszerítik az API-t, hogy folyamatosan végezzen sok értelmetlen munkát (például nehéz adatbázis-lekérdezések futtatása), amelyek felgyorsíthatják a számláit okokból.

Azokon a platformokon, ahol az erőforrások automatikus méretezése engedélyezve van (mint például az AWS), az eredmények sokkolóak lehetnek (téma nélkül), de ha valaha is belekapaszkodnak egy ilyen levesbe az AWS-n, akkor megértik a helyzetet és haladéktalanul lemondnak a felfújt számla – legalább írásban!).

Csapat morál

Tehát gondolkodhat úgy, hogy a csapat, amely hagyja, hogy ezek a kompromisszumok megtörténjenek, elveszíti az erkölcsöket felettük? Nos, nem egészen. Lehetséges, hogy a kompromisszumok a gyenge infrastruktúra-biztonság miatt következtek be, ami elriasztja a fejlesztőket, vagy fordítva.

Ha ez elég időben megtörténik, akkor olyan kultúrája lesz a kezedben, amelyet bánni fog, hogy hagyja fejlődni.

A versenytárs nyeresége

Tegyük fel, hogy volt egy jogsértés, de tényleges veszteség nem volt. A versenytársak azonban az esemény felhasználásával dobják fel saját API-t, és kijelentik, mennyire biztonságosabb az övék (még ha nem is!). Ismét sok szerencsét próbálunk meggyőzni a piacról. ��

Mindent egybevetve a biztonsági megsértéseknek vannak olyan következményei, amelyek túlmutatnak a pénzvesztésen.

Bevált gyakorlatok az API végpontok biztosításához

Szerencsére vannak olyan könnyen megvalósítható és jól érthető gyakorlatok, amelyeket alkalmazhat az API végpontjaihoz azok biztosítása érdekében. Íme, amit a legtöbb biztonsági szakértő javasol.

A HTTPS mindig

Ha az API végpontjai lehetővé teszik az API fogyasztóinak, hogy beszéljenek a http vagy más nem biztonságos protokollok segítségével, akkor nagy kockázatot jelent ezekre. A jelszavak, titkos kulcsok és hitelkártya-információk bármilyen módon könnyen ellophatók ember-közép támadás vagy a packet sniffer eszköz egyszerű szövegként képes őket olvasni.

Tehát mindig a https-et tegye elérhetővé. Bármennyire is tűnik egy végpont, a http-en keresztüli csatlakozásnak nem is szabadnak lennie. A TLS tanúsítvány nem kerül sokba, akár 20 USD-t is megvásárolhat SSL áruház.

Egyirányú jelszó-kivonás

A jelszavakat soha nem szabad szöveges formában tárolni, mivel biztonsági megsértés esetén az összes felhasználói fiók veszélybe kerül. Ugyanakkor a szimmetrikus titkosítást szigorúan kerülni kell, mivel minden ötletes és kitartó támadó képes lesz megtörni őket..

Az egyetlen javasolt lehetőség aszimmetrikus (vagy „egyirányú”) titkosítási algoritmusok a jelszavak tárolására. Ily módon sem a támadó, sem a vállalaton belüli fejlesztő vagy rendszergazda nem fogja elolvasni az ügyféljelszavakat.

Erős hitelesítés

Most szinte minden API rendelkezik bizonyos hitelesítési formákkal, de véleményem szerint az OAuth2 rendszer működik a legjobban. Más hitelesítési módszerekkel ellentétben a fiókot erőforrásokra osztja, és csak korlátozott hozzáférést tesz lehetővé az auth token hordozó számára.

Ugyanakkor egy másik nagyon jó gyakorlat, amely szerint a tokeneket minden, mondjuk, 24 óránként lejárnak, és így azokat fel kell frissíteni. Ilyen módon még a tokened kiszivároghat, van esély arra, hogy a 24 órás határidő csökkenti a jogsértés hatását.

Alkalmazzon sebességkorlátozót

Hacsak nincs olyan API, amelyet percenként emberek milliói használnak, nagyon jó ötlet érvényesíteni azt a korlátot, amelyen az ügyfél egy adott időablakban hívhat az API-hoz..

Ez elsősorban a botok elrettentésére irányul, amelyek minden másodpercben több száz egyidejű kérést küldhetnek, és az API-t jó ok nélkül fel tudják használni a rendszer erőforrásait. Az összes webfejlesztési keret sebességkorlátozó köztes szoftverrel rendelkezik (és ha nem, meglehetősen könnyű azt hozzáadni egy könyvtáron keresztül), amely körülbelül egy percet igényel a beállításhoz.

Érvényesítse a bemenetet

Úgy hangzik, mint egy lelkiismeretes, de meg fog lepődni, hogy hány API tartozik ehhez. A bemenet érvényesítése nemcsak azt jelenti, hogy ellenőrizzük, hogy a bejövő adatok helyes formátumban vannak-e, hanem azt is, hogy nem lehet meglepetés. Egy egyszerű példa az SQL befecskendezés, amely megsemmisítheti az adatbázisokat, ha engedi, hogy a lekérdezési karakterláncok kevés ellenőrzéssel vagy egyáltalán ne menjenek végbe.

Egy másik példa a POST kérés méretének érvényesítése és a megfelelő hibakód és üzenet visszaadása az ügyfélnek. A nevetségesen nagy bemenetek elfogadása és elemzése csak az API felrobbantására szolgál.

Ha szükséges, hajtsa végre az IP-cím szűrését

Ha B2B szolgáltatásokat vesz igénybe, és az API-kat a meghatározott helyekből származó vállalkozások használják, fontoljon meg egy további biztonsági réteg hozzáadását, amely korlátozza az Ön API-jához hozzáférő IP-címet. Minden új hely és új ügyfél esetében az IP-címet ellenőrizni kell a beérkező kérés alapján.

Igen, ártalmatlanul növeli a fedélzeten tartózkodást, de a végeredmény sokkal szigorúbb a biztonságnál, mint az egyébként elérhető.

Eszközök az API-védelem fokozására

Van-e olyan eszköz, amely elősegítheti a sérülékenység vizsgálatát, vagy még jobb, ha az első védelmi vonalat kínálja az API-k védelme érdekében?

Szerencsére igen. Számos eszköz használható, de vigyázni kell arra, hogy a nap végén egyetlen biztonsági stratégia sem tökéletes. Mindezek ellenére ezek az eszközök sokrétűen növelik az API biztonságát, ezért ajánlottak.

Metasploit

Metasploit egy rendkívül népszerű nyílt forráskódú keret a webalkalmazások és az API-k penetrációs tesztelésére. Beolvashatja az API-t több különböző paraméterre, és teljes körű biztonsági ellenőrzést végezhet a jelenlévő sebezhetőségek különböző szintjein.

Például a Metasploit által végzett biztonsági vizsgálat megmondja, hogy az API-aláírások megadják-e az alapul szolgáló technológiákat és az operációs rendszert, vagy sem; ennek elrejtése gyakran az API-biztonságban elért harc fele.

Noha a nyílt forrású alapkeret általában elegendő, vannak olyan kiváló fizetős termékek, amelyek a Metasploit tetejére épülnek, és érdemes megnézni. A profi terv nagyszerű, ha prémium támogatást szeretne, és mélyrehatóan használja a keretet, de általában nem szükséges, ha a csapata elég tapasztalt.

CloudFlare

Nem csak CDN, hanem CloudFlare rengeteg biztonsági funkciót kínál, mint például a WAF, a sebességkorlátozást, a DDoS védelmet, amelyek nélkülözhetetlenek az API védelmében az online fenyegetésekkel szemben.

Netsparker

Netsparker a „bizonyítékalapú szkennelés” USP-jéhez tartozik. Egyszerűbben fogalmazva: gyakran előfordulhat, hogy a szabálytalan hálózati feltételeket vagy néhány kevésbé ismert API-viselkedést biztonsági réseknek tekintnek, amelyeket később tévesnek találnak.

Ez pazarolja az erőforrásokat, mivel az összes jelentett sebezhetőséget manuálisan újra kell vizsgálni, hogy megbizonyosodjon arról, hogy nem téves pozitívumok. A Netsparker szerint az eszköz elég erős bizonyítékot nyújt a jelentések koncepciójának megkönnyítésére, megszüntetve a talált gyenge linkekkel kapcsolatos kétségeket..

Az olyan cégekkel, mint a Sony, a Religare, a Coca-Cola, a Huawei stb., Amelyek ügyféllistájukon vannak, biztos lehet benne, hogy ezek az emberek jól csinálnak valamit. �� Egyébként ők is hihetetlenek internetes biztonsági blog amit követni kell.

SoapUI Pro

Építette a SmartBear, SoapUI Pro egy intuitív és egyszerű módszer API tesztek létrehozására és pontos, adatvezérelt jelentések beszerzésére. Széles körben integrálódik a CI / CD-csővezetékbe, ügyelve arra, hogy új kódkiegészítések ne veszélyeztessék az API biztonságát.

A SoapUI képes együttműködni a Swagger, OAS és más népszerű API szabványokkal, jelentősen lerövidítve az induláshoz szükséges időt. Az olyan ügyfelekkel, mint a Microsoft, a Cisco, a MasterCard, az Oracle stb., És a tervek évi 659 dollárra kezdődnek, ez méltó eszköz a biztonságosabb API-khoz.

Trustwave

Trustwave a megoldások egy csomagja, amely a biztonsági szkennelés és az edzés köré összpontosul. A szolgáltatás egyedülálló tulajdonsága, hogy nemcsak a fenyegetések pontos felismerését végzi az API-n, hanem segít megérteni, hogyan javíthatja őket..

A Trustwave elvégzi a környezettudatos szkennelést, azaz azt jelenti, hogy ha egy alapul szolgáló operációs rendszert vagy infrastruktúrát észleltek, a szolgáltatás a kapcsolódó ellenőrzések sorozatát végzi annak biztosítása érdekében, hogy az adott platformon rejlő csúnya biztonsági lyukak ne legyenek jelen.

Erős biztonsági kutatókkal is büszkélkedhetnek, akik folyamatosan frissítik a szolgáltatási képességeket. Ha nagy a betartása, akkor a Trustwave jó megoldás.

Ha a számok szerint él, és élvezni szeretné olyan funkciókat, mint a fenyegetésválasz, a kattintások egyszeri kattintással történő újrafuttatása a javítások után és így tovább, akkor ne keresse tovább!

Van nincs hiány a piacon elérhető API biztonsági eszközök, függetlenül attól, hogy nyílt forráskódú, ingyenes vagy kereskedelmi, vagy ezek bármilyen kombinációja. Nyugodtan fedezhessen fel többet, és ha még jobbat is talál, kérjük, írja meg a megjegyzésekbe, és örömmel szerelem! ��

CÍMKÉK:

  • API

Jeffrey Wilson Administrator
Sorry! The Author has not filled his profile.
follow me
    Like this post? Please share to your friends:
    Adblock
    detector
    map