Tietoturvatarkistuslista tekoälyllä rakennetuille sovelluksille: mitä tarkistaa ennen julkaisua

Ennen kuin oikeat ihmiset käyttävät tekoälyllä rakentamaasi sovellusta, tarkista seitsemän asiaa: jokainen sivu ja API-rajapinta tarkistaa, kuka käyttäjä on ja mitä hän saa tehdä; salaiset avaimet ovat palvelimella, eivät koskaan selaimessa tai chatissa; kaikki syötteet validoidaan palvelimella; jokainen käyttäjä pääsee vain omiin tietueisiinsa; kirjautuminen ja kalliit päätepisteet on rajoitettu kyselymäärillä; riippuvuudet ovat ajan tasalla; ja voit palauttaa datasi, jos jotain menee pieleen. Alla oleva tarkistuslista muuttaa jokaisen niistä konkreettisiksi testeiksi, jotka voit ajaa lukematta koodia.

Tekoälysovellusrakentajat ovat hyviä saamaan ominaisuudet toimimaan. Ne eivät ole automaattisesti huolellisia, koska ”huolellisuutta” ei harvoin ole kehotteessa. Suurin osa alla olevista ongelmista syntyy asioista, joita kukaan ei pyytänyt, joten korjaus on yleensä pyytää niitä.

Näin käytät tarkistuslistaa

Käy se läpi järjestyksessä ja tee jokaiselle kohdalle kaksi asiaa: pyydä tekoälyä varmistamaan, että asia on hoidettu, ja testaa itse. Tekoäly voi kirjoittaa oikeustarkistuksen; vain testi kertoo, että se toimii. Kohdat on merkitty näin:

• Pakollinen — tee tämä ennen kuin kukaan muu käyttää sovellusta.
• Suositeltava — tee tämä ennen kuin sinulla on oikeita käyttäjiä tai oikeaa dataa.
• Myöhemmin — kannattaa tehdä, kun sovellus kasvaa.

Jos sinulla on vain tunti, tee kaikki pakolliset.

1. Todennus: kuka tämä on?

Todennus tarkoittaa sen varmistamista, kuka henkilö on — yleensä kirjautumista. Katso mitä todennus on perusteet ja kirjautumisen lisääminen sovellukseen vaihtoehdot.

• Pakollinen: Jokainen yksityisiä tietoja näyttävä sivu vaatii kirjautumisen. Testi: kirjaudu ulos ja liitä yksityisen sivun URL suoraan selaimeen.
• Pakollinen: Jokainen näiden sivujen takana oleva API-päätepiste vaatii myös kirjautumisen — ei vain sivu. Testi: kirjaudu ulos, avaa selaimen verkkovälilehti ja toista pyyntö, jonka sovellus teki kirjautuneena.
• Pakollinen: Salasanat tallennetaan tiivisteinä hitaalla salasanatiivistysalgoritmilla, ei koskaan selkotekstinä. OWASPin salasanojen tallennusohje suosittelee ensisijaisesti Argon2id:tä, vaihtoehtoina scrypt, bcrypt tai PBKDF2. Kysy: ”Miten salasanat tallennetaan?”
• Suositeltava: Salasanan palautuslinkit vanhenevat ja toimivat vain kerran.
• Suositeltava: Istuntoevästeet on merkitty Secure, HttpOnly ja SameSite -attribuuteilla, ja uloskirjautuminen lopettaa istunnon palvelimella.
• Myöhemmin: Tarjoa kaksivaiheinen todennus tai kirjautuminen palveluntarjoajan kautta, jolla se on käytössä.

Tarkista jokainen API-reitti ja sivu, joka palauttaa käyttäjädataa. Jokaisen pitää hylätä pyynnöt käyttäjiltä, jotka eivät ole kirjautuneet, palvelimella, ei vain sivun koodissa. Listaa tarkistamasi reitit.

2. Valtuutus: mitä heidän saa tehdä?

Valtuutus on kirjautumisen jälkeinen vaihe: päätetään, mitä tämä tietty käyttäjä saa nähdä ja muuttaa. Tässä tekoälyllä tehdyillä sovelluksilla on useimmin vakavia aukkoja, koska sovellus näyttää oikealta — jokaisen käyttäjän kojelauta näyttää vain hänen omat tietonsa — mutta palvelin antaa kenen tahansa tiedot, jos niitä pyydetään suoraan.

• Pakollinen: Jokainen luku-, päivitys- ja poistotoiminto tarkistaa palvelimella, että tietue kuuluu nykyiselle käyttäjälle (tai hänen tiimilleen).
• Pakollinen: Testaa: luo kaksi tiliä, A ja B. Avaa A:na yksi A:n tietueista ja merkitse ylös tunniste URL-osoitteesta tai verkkopyynnöstä. Kirjaudu B:nä ja pyydä sama tunniste. B:n pitää saada virhe, ei A:n tietoja.
• Pakollinen: Ylläpitosivut ja ylläpidon API-päätepisteet tarkistavat käyttäjän roolin palvelimella. Ylläpitolinkin piilottaminen ei ole suojaa.
• Pakollinen: Käyttäjät eivät voi muuttaa omaa roolia, hintaa, saldoa tai omistajakenttiä muokkaamalla pyyntöä. Testi: katso verkkovälilehdeltä, mitä profiilin päivitys lähettää. Jos mukana on kenttiä kuten role tai isAdmin, pyydä tekoälyä jättämään ne huomiotta asiakaspuolelta.
• Suositeltava: URL-osoitteiden tunnisteet ovat vaikeasti arvattavia (satunnaisia tunnisteita eikä 1, 2, 3). Tämä ei korvaa oikeustarkistuksia, mutta rajoittaa vahinkoa, jos sellainen puuttuu.

Jokaisen päätepisteen, joka lukee tai muuttaa tietuetta, pitää tarkistaa palvelimella, että kirjautunut käyttäjä omistaa sen tai saa käyttää sitä. Palauta 404, jos ei. Näytä sitten, miten testaisit tämän kahdella tilillä.

3. Rivitason käyttöoikeudet tietokannassa

”Rivitason käyttöoikeus” tarkoittaa, että taulukon jokainen rivi (yksi varaus, yksi lasku) näkyy vain niille käyttäjille, joihin se kuuluu. Siihen on kaksi yleistä tapaa:

Molemmat voi tehdä hyvin. Oleellista on:

• Pakollinen: Jos selain puhuu suoraan tietokannan kanssa (jotkin hostatut tietokantapalvelut sallivat tämän), rivitason säännöt on kytketty päälle jokaiselle taulukolle. Ilman niitä kuka tahansa julkisen avaimen kanssa voi lukea koko taulukon.
• Pakollinen: Kyselyt suodattavat nykyisen käyttäjän tai tiimin mukaan, eivät selaimen lähettämän tunnisteen mukaan.
• Suositeltava: Jaetulla datalla (tiimin projekteilla) on selkeä sääntö siitä, kuka kuuluu tiimiin, ja se on pakotettu yhdessä paikassa.

4. Salaisuudet ja API-avaimet

API-avain on palvelun salasana. Stripe, sähköposti- ja tekoälypalvelut käyttävät kaikki niitä. Taustatietoa saat kohdasta mitä ympäristömuuttujat ja salaisuudet ovat.

• Pakollinen: Avaimet tallennetaan projektin ympäristömuuttujiin tai salaisuuksiin, eikä niitä kirjoiteta koodiin.
• Pakollinen: Avaimia, joilla voi käyttää rahaa tai lukea yksityistä dataa, käytetään vain palvelimella. Testi: avaa live-sivustosi, katso sivun lähdekoodi ja JavaScript-tiedostot kehittäjätyökaluilla ja etsi avaimen alkua (esimerkiksi sk_). Sitä ei saa näkyä.
• Pakollinen: Avaimia ei ole koskaan liitetty chatiin, julkiseen repositorioon tai kuvakaappaukseen. Jos on, kierrätä avain: luo uusi palveluntarjoajalla ja poista vanha.
• Suositeltava: Käytä rajoitettuja tai rajattuja avaimia, kun palveluntarjoaja tarjoaa niitä. Stripe suosittelee esimerkiksi rajoitettuja avaimia, joilla on vain integraation tarvitsemat oikeudet.
• Suositeltava: Testi- ja live-avaimet ovat erillään, ja live-sovellus käyttää live-avaimia vasta kun olet valmis.

Osa avaimista on suunniteltu julkisiksi — Stripen julkaisuavain (pk_…) tai karttakartta-avain, joka on rajattu domainiisi. Sääntö koskee avaimia, jotka antavat valtaa, ei jokaista merkkijonoa, joka näyttää avaimelta.

5. Syötteiden validointi

Mikä tahansa käyttäjän lähettämä — lomakekentät, tiedostolataukset, URL-parametrit — voi olla mitä tahansa, ei vain sitä, mitä lomakkeesi sallii.

• Pakollinen: Validointi tehdään palvelimella, ei vain selaimessa. Selaimen tarkistukset ovat mukavuutta varten; kuka tahansa voi ohittaa ne.
• Pakollinen: Tietokantakyselyt käyttävät parametreja, eivät käyttäjän syötteistä yhteen liimattua tekstiä (tämä estää SQL-injektion). Pyydä tekoälyä vahvistamaan tämä.
• Pakollinen: Käyttäjän kirjoittama teksti näytetään tekstinä, ei suoritettuna HTML:nä. Testi: kirjoita nimeksi <b>hello</b>. Näet tagit, et lihavoitua tekstiä.
• Suositeltava: Tiedostolataukset tarkistavat tyypin ja koon, eivätkä ladatut tiedostot ole saatavilla sovelluksesi pääverkkotunnuksesta ajettavina sivuina.
• Suositeltava: Käyttäjille näytettävät virheet ovat yksinkertaisia (”Jotain meni pieleen”); yksityiskohtaiset virheet menevät vain palvelimen lokeihin.
• Suositeltava: Palveluiden, kuten Stripen, webhookit tarkistavat palveluntarjoajan allekirjoituksen ennen toimintaa. Katso mikä webhook on.

Lisää palvelinpuolen validointi jokaiseen lomakkeeseen ja API-päätepisteeseen: pakolliset kentät, pituudet, muodot ja sallitut arvot. Hylkää muu selkeällä viestillä. Älä näytä käyttäjille sisäisiä virhetietoja.

6. Kyselyrajat ja väärinkäyttö

Kyselyraja rajoittaa, kuinka monta pyyntöä jokin voi tehdä tietyssä ajassa. Ilman niitä kuka tahansa voi arvata salasanoja koko päivän, täyttää rekisteröintilomakkeesi tai kasvattaa laskuasi maksullisessa API:ssa.

• Pakollinen: Kirjautuminen, rekisteröityminen ja salasanan palautus on rajoitettu kyselymäärällä IP-osoitetta ja tiliä kohden.
• Pakollinen: Kaikki, mikä maksaa sinulle per kutsu — tekoälymallipyynnöt, tekstiviestit, sähköposti — on rajattu käyttäjäkohtaisesti ja vaatii kirjautumisen.
• Suositeltava: Julkisissa lomakkeissa (yhteydenotto, odotuslista) on roskapostisuojaus: kyselyraja, piilotettu huijauskenttä tai CAPTCHA.
• Suositeltava: Aseta kulutusrajat tai hälytykset maksullisille palveluntarjoajille, jotta bugi tai hyökkääjä ei voi tuottaa rajatonta laskua.

7. Riippuvuudet

Sovellukset rakentuvat avoimen lähdekoodin paketeista, ja paketeissa on joskus tunnettuja haavoittuvuuksia.

• Suositeltava: Pyydä tekoälyä tarkistamaan tunnetut haavoittuvuudet (JavaScript-projekteissa npm audit tai pakettienhallintasi vastine) ja päivittämään kohteet, joihin ne vaikuttavat.
• Suositeltava: Poista paketit, joita sovellus ei enää käytä.
• Suositeltava: Ole varovainen paketeista, joilla on hyvin vähän käyttäjiä tai joiden nimet näyttävät suosittujen kirjoitusvirheiltä.
• Myöhemmin: Tarkista kerran kuukaudessa tai parin kuukauden välein, tai ota automaattiset hälytykset käyttöön, jos koodisi on GitHubissa.

8. Varmuuskopiot ja palautus

Tietoturvaan kuuluu kyky palautua virheistä — omistasi, tekoälyn tai hyökkääjän.

• Pakollinen: Tiedä, missä datasi sijaitsee ja onko siitä varmuuskopio. Älä oleta; tarkista palveluntarjoajan dokumentaatiosta.
• Suositeltava: Pidä omaa säännöllistä vientiä tärkeistä tiedoista (esimerkiksi CSV-vientiominaisuus tai tietokantavedos) tallennettuna erilliseen paikkaan.
• Suositeltava: Pidä koodisi versionhallinnassa, jotta mikä tahansa versio voidaan palauttaa.
• Suositeltava: Tuhoavat toiminnot (tilin poisto, projektin poisto) pyytävät vahvistuksen, ja harkitse ”pehmeää poistoa”, jonka voi perua tietyn ajan.
• Myöhemmin: Testaa palautus oikeasti kerran. Varmuuskopio, jota et ole koskaan palauttanut, on toivo, ei suunnitelma.

9. Ennen julkaisua

• Pakollinen: Live-sivusto käyttää HTTPS:ää kaikkialla.
• Pakollinen: Kehityksen esimerkkidata, testitilit ja virheenjäljityssivut on poistettu.
• Suositeltava: Tietosuojaselosteessa kerrotaan, mitä dataa keräät ja miksi — monissa maissa vaaditaan, jos keräät henkilötietoja. Älä väitä sertifiointeja (SOC 2, HIPAA), joita sinulla ei ole.
• Suositeltava: Sinulla on tapa, jolla sinuun voi ottaa yhteyttä tietoturvaongelmista, ja tiedät, miten vaihdat jokaisen avaimen nopeasti.

Laajempaan julkaisua edeltävään tarkistukseen tietoturvan lisäksi katso kuinka viet tekoälyprototyypin tuotantoon.

Milloin tarvitset ammattilaisen arvion

Tarkistuslista löytää yleisimmät virheet; se ei korvaa asiantuntijaa. Harkitse maksettua arviota, jos käsittelet korttinumeroita itse sen sijaan, että käyttäisit hostattua maksusivua, säilytät terveys-, talous- tai lastentietoja, myyt yrityksille, jotka vaativat tietoturvakyselyjä, tai vuoto aiheuttaisi sinulle vakavaa vahinkoa. Se, että koodisi on vietävissä, helpottaa tällaista arviota huomattavasti.

Tietoturva rakentaessa Mythexillä

Mythexissä ei ole tietoturvaskannauspaneelia, joten yllä oleva tarkistuslista on prosessi, jota kannattaa noudattaa. Muutama asia auttaa:

• Projektin salaisuudet. Tallenna avaimet projektiasetuksiin → Salaisuudet tai agentin chatissa näyttämän salaisuuskortin kautta, jotta ne pysyvät poissa koodistasi ja viesteistäsi. Kun vaihdat salaisuuden live-sovellukselle, julkaise uudelleen.
• Suunnittelu- ja Kysy-tilat. Pyydä agenttia tarkistamaan oikeudet muokkaamatta mitään: ”Kysy-tilassa listaa jokainen API-reitti ja sen oikeustarkistus.”
• /test saa agentin klikkaamaan esikatselusi läpi käyttäjänä — hyödyllinen kohdan 2 kahden tilin testiin.
• Tarkistuspisteet antavat sinun palauttaa muutoksen, joka rikkoi jotain.

Katso Tietoturva rakentamillesi sovelluksille ja Ympäristömuuttujat ja salaisuudet dokumentaatiosta. Jos lisäät seuraavaksi käyttäjätilit, lue kuinka lisäät kirjautumisen sovellukseesi.

Kysymykset