Rajapinnan rajoittaminen määritelmässä

[Mygee]

Aika paljon on tullut kommentteja siitä, että rajapintaa pitäisi eri tavoin rajoittaa esim. palvelunestohyökkäyksessä. Avaan keskustelun tästä asiasta täällä. Kommentoikaa tähän, mitä ongelmia tähän liittyy ja ehdottakaa muutoksia rajapinnan sisältöön tähän tyyliin: "tämä teksti" kannattaisi "korvata tällä tekstillä".

[apoikola]

"tämä teksti" kannattaisi "korvata tällä tekstillä" -> roadmap-issuessa #36 ehdotin, että rinnakkain eläisi sekä kommentoitavissa oleva Gdocs-teksti, jonka kommenteista voi linkittää issueihin.

Demonstroidakseni tätä tein tekstinmuokkausehdotuksen rajoittamisasiaan gdocsiin ja linkitin ehdotuksen takaisin tänne.

Ehdotin siis lisättäväksi: Rajapintapalvelun julkisissa käyttöehdoissa voidaan määritellä, millä edellytyksillä (esimerkiksi palvelunestohyökkäysten torjumiseksi) rajapintapalvelun käyttöä voidaan rajoittaa.

[jaakkokorhonen]

Miksei palvelunestohyökkäyksia torjuttaisi palomuurilla? Verkolle hailtallisen liikenteen esmisvelvoite on yleensä sopimuksellisesti muodostunut jo verkkoon liityttäessä. Ei ole mitään syytä nostaa asiaa kuljetuskerrokselta sovelluskerrokselle, mutta voihan IP blokkauksen mainita. Hyvässä palomuurissa on automatisoitu hyökkäyksen tunnistus ja blokkaus.

[Mygee]

Palomuurit ovat vähän heikko tapa yksinään hallita apien käyttöä. Esim. Ip-osoitteita on helppo väärentää ja palomuureja voi kiertää monella eri tavalla. Tietenkin erilainen ip-osoitteiden ja muun liikenteen suodatus voisi olla osa pakettia, mutta ei missään nimessä koko ratkaisu. Case: My data ja sensitiivinen tieto, vaikkapa DNA tai rahaliikenne.

[Mygee]

Tyypillisiä tapoja hallita API:en tietoturvallisuutta:

1. Uhkien tunnistaminen (Denial of Service (DoS), Code/SQL injections and identity spoofing)
2. Ip-osoitteisiin perustuva rajoittaminen, sijaintiin perustuva rajoittaminen, aikaan perustuva rajoittaminen
3. Frontend: OAuth, OpenID, Basic Authorization, API key (lähinnä käytön tilastointitarkoitus).
4. Backend: SAML, LDAP ja XACML