Säänneltyä dataa käsittelevä API suojataan mallintamalla, kuka voisi käyttää sitä väärin, tarkistamalla valtuutus jokaiselle objektille ja kentälle, keräämällä ja palauttamalla mahdollisimman vähän tietoja sekä pitämällä salaisuudet ja auditointilokit tiukassa hallinnassa. Käytännössä merkittävimmät heikkoudet ovat aukot valtuutuksessa ja vastaukset, jotka paljastavat liikaa tietoja, eivät rikkinäinen salaus.
Aloita datan uhkamallista, älä sovelluskehyksestä
Ennen työkalujen valintaa kirjaa ylös, mitä API paljastaa ja kuka voisi käyttää sitä väärin. Pankille se tarkoittaa tili- ja tapahtumatietoja; energia- tai verkkoyhtiölle se voi tarkoittaa mittaustietoja, asiakassopimuksia ja verkon käyttötietoja.
Hyödyllinen uhkamalli on lyhyt. Siinä luetellaan arkaluonteiset tiedot, jokainen kutsuja, joka voi päästä niihin käsiksi, toimenpiteet, joita kunkin kutsujan pitäisi voida tehdä, ja se, mitä tapahtuu, jos jokin niistä vaarantuu. Asiakirja ohjaa sitten jokaista alla olevaa kontrollia ja kertoo katselmoijille, mitä testata.
- Mitkä tiedot ovat henkilötietoja, luottamuksellisia tai säänneltyjä ja missä niitä säilytetään.
- Jokainen API:n käyttäjä: sisäiset palvelut, kumppanit, mobiilisovellukset ja ylläpitäjät.
- Mitä kukin käyttäjä saa lukea, muuttaa tai käynnistää.
- Vuotaneen tunnisteen, pahantahtoisen sisäpiiriläisen tai vaarantuneen kumppanijärjestelmän vaikutus.
Tunnista jokainen kutsuja ja valtuuta jokainen objekti
Käytä käyttäjille standardiprotokollaa, kuten OAuth 2.0:aa OpenID Connectin kanssa, ja palvelujen välisiin kutsuihin lyhytikäisiä tunnisteita tai molemminpuolista TLS:ää (mTLS). Vältä pitkäikäisiä jaettuja API-avaimia, koska kukaan ei pysty sanomaan, mikä järjestelmä niitä käytti, eikä niitä voi perua rikkomatta muita.
Tunnistautuminen todistaa vain, kuka kutsuu. OWASP API Security Top 10 -luettelon ensimmäinen kohta on rikkinäinen objektitason valtuutus (broken object level authorization): kelvollinen käyttäjä muuttaa pyynnössä tunnistetta ja lukee jonkun toisen tietueen. Tarkista omistajuus tai asiakaskohtainen rajaus palvelimella jokaiselle objektille, jokaiselle toiminnolle ja jokaiselle arkaluonteiselle kentälle, äläkä koskaan luota asiakkaan lähettämään tunnisteeseen tai rooliin.
Anna jokaiselle asiakasohjelmalle ja palvelulle vain tarvittavat oikeudet
Vähimpien oikeuksien periaate rajaa vahinkoa, kun jokin menee pieleen. Myönnä erilliset tunnukset kullekin käyttäjälle, rajaa tunnisteet tiettyihin toimintoihin ja pidä hallintapäätepisteet erillisellä polulla vahvemmin tarkistuksin.
Sovella samaa sääntöä API:n alapuolella. Mittaustietoja lukevan palvelutilin ei pitäisi pystyä poistamaan niitä, ja raportointityön pitäisi yhdistää tietokantaan pelkin lukuoikeuksin. Tarkista oikeudet aikataulun mukaan, koska kertaluonteista tehtävää varten myönnetty pääsy jää yleensä voimaan ikuisesti.
Kerää vähemmän, palauta vähemmän ja säilytä lyhyemmän aikaa
Tietojen minimointi on sekä GDPR:n periaate että vahva tietoturvakontrolli: tieto, jota et koskaan tallenna, ei voi vuotaa. Kysy jokaisen kentän kohdalla, tarvitseeko palvelu sitä todella, ja jätä pois tai pseudonymisoi se, mitä se ei tarvitse.
Sovella samaa kurinalaisuutta vastauksiin. Määritä eksplisiittiset vastausskeemat sen sijaan, että sarjallistaisit kokonaisia tietokantaobjekteja, peitä tunnisteet, kuten tilinumerot, kun koko arvoa ei tarvita, ja aseta säilytysajat, jotta vanhat tietueet poistetaan. Dokumentoi kunkin käsittelytarkoituksen oikeusperuste ja allekirjoita käsittelijäsopimukset jokaisen tietoja käsittelevän toimittajan kanssa. Tämä on teknistä käytäntöä, ei oikeudellista neuvontaa, joten ota tietosuojavastaavasi tai lakimiehesi mukaan oikeudelliseen arviointiin.
Validoi jokainen syöte ja rajaa, mitä yksi kutsuja voi kuluttaa
Käsittele jokaista pyyntöä vihamielisenä, kunnes se on validoitu. Pakota jokaiselle päätepisteelle skeema, hylkää tuntemattomat kentät ja käytä parametrisoituja kyselyjä, jotta syöte ei koskaan muutu osaksi tietokantakomentoa.
Useat OWASP:n API-riskit johtuvat puuttuvista rajoista eivätkä huonosta koodista. Rajoita pyyntömääriä kutsujakohtaisesti, rajaa sivu- ja sisältökoot ja suojaa arkaluonteiset liiketoimintaprosessit, kuten maksut tai sopimusmuutokset, automatisoidulta väärinkäytöltä. Jos API hakee etä-URL-osoitteita kutsujien puolesta, rajaa sallitut kohteet palvelinpuolen pyyntöväärennösten (SSRF) estämiseksi.
Pidä salaisuudet poissa koodista, konttikuvista ja lokeista
Tietokantasalasanat, allekirjoitusavaimet ja kumppanitunnukset kuuluvat erilliseen salaisuuksien hallintaan, josta ne syötetään ajonaikaisesti ja jossa niitä kierrätetään aikataulun mukaan. Skannaa repositoriot ja konttikuvat salaisuuksien varalta käännösputkessa ja pidä jokaista versionhallintaan päätynyttä salaisuutta vaarantuneena.
Erottele salaisuudet ympäristöittäin, jotta vuotanut testitunnus ei koskaan avaa tuotantoa. Rajaa, kuka voi lukea tuotannon salaisuuksia, ja kirjaa jokainen pääsy niihin.
Kirjaa auditointia varten ja suunnittele vähemmän häiriöitä
Säännellyissä ympäristöissä on jälkikäteen pystyttävä vastaamaan yksinkertaiseen kysymykseen: kuka pääsi mihinkin tietoihin, milloin ja minkä asiakasohjelman kautta. Kirjaa se jokaisesta arkaluonteisesta luvusta ja kirjoituksesta, säilytä lokit paikassa, jossa sovelluksen ylläpitäjät eivät voi muuttaa niitä, ja pidä henkilötiedot poissa lokiviesteistä.
Yhdistä lokitukseen hälytykset epätavallisista kuvioista, kuten asiakasohjelmasta, joka lukee paljon tavallista enemmän tietueita, sekä testattu häiriötilanteiden toimintasuunnitelma. Sopra Sterian kautta kehittäjämme rakensivat turvallisia API:ja arkaluonteiselle verkkoyhtiödatalle sääntelyn rajoissa ja johtivat operatiivista valvontatyökalua, jossa tiukasti noudatetut tietoturvastandardit kulkivat käsi kädessä vähäisempien tuotantohäiriöiden kanssa. SDK Enterprises soveltaa samoja käytäntöjä asiakasprojekteihin tänään.
Tärkeimmät havainnot
- Lyhyen, kirjallisen datan uhkamallin pitää ohjata jokaista API:n tietoturvakontrollia.
- Tarkista valtuutus palvelimella jokaiselle objektille, toiminnolle ja arkaluonteiselle kentälle, ei vain kirjautumisen yhteydessä.
- Vähimpien oikeuksien periaate koskee yhtä lailla tunnisteita, palvelutilejä ja tietokantarooleja.
- Tietojen minimointi pienentää sekä GDPR-riskejä että minkä tahansa tietomurron vaikutusta.
- Auditointilokien on näytettävä, kuka pääsi mihinkin ja milloin, vuotamatta itse henkilötietoja.
UKK
Riittääkö HTTPS API:n suojaamiseen?
Ei. TLS suojaa tiedot siirron aikana, mutta monissa API-tietomurroissa tunnistautuneet kutsujat pääsevät tietoihin, joita heidän ei pitäisi nähdä. Valtuutustarkistukset, syötteiden validointi, pyyntörajoitukset ja auditointilokit tarvitaan edelleen.
Mikä on rikkinäinen objektitason valtuutus?
Se on virhe, jossa API tarkistaa, että kutsuja on kirjautunut, mutta ei sitä, että pyydetty tietue kuuluu hänelle. Kun URL-osoitteen tai pyynnön rungon tunnistetta muutetaan, muiden käyttäjien tiedot paljastuvat. Korjaus on palvelimella tehtävä omistajuuden tai asiakaskohtaisen rajauksen tarkistus jokaiselle objektille.
Määrääkö GDPR tietyistä API-tietoturvakontrolleista?
GDPR edellyttää riskiin nähden asianmukaisia teknisiä ja organisatorisia toimenpiteitä määräämättä tiettyjä työkaluja. Kontrollit, kuten pääsyn rajaaminen, minimointi, pseudonymisointi ja lokitus, ovat yleisiä tapoja täyttää vaatimus, ja oikeudellisten neuvonantajiesi pitäisi vahvistaa, mitä sinun tapaukseesi sovelletaan.