ISO 27001 A.8.10: Pelaajatietojen turvallinen poistaminen pelistudioissa

Miksi pelaajatietojen poistamatta jättämisestä on tullut strateginen vastuu

Pelaajadatan poistamatta jättäminen ajoissa muuttuu nopeasti studiosi tietoturva-, yksityisyys- ja sääntelyvastuuksi. Kun telemetria, keskustelulokit ja tukihistoriat eivät koskaan katoa, jokainen tietomurto tai tiedustelu vetää mukanaan lisää järjestelmiä, todisteita ja työtä kuin on tarpeen. Käytöstä poistettujen tietojen käsittely hallittuna riskinä auttaa vähentämään tapausten vaikutuksia, yksinkertaistamaan tutkimuksia ja vähentämään sitä, kuinka paljon tietoa voidaan käyttää väärin.

Pelaajatiedot ovat nykyään tulojen, sääntelyn ja maineen risteyksessä, joten hallitsematon säilytys suurentaa hiljaisesti altistumistasi. ISO 27001:2022 -standardin liitteessä A.8.10 todetaan yksiselitteisesti, että tiedot on poistettava, kun niitä ei enää tarvita, tavalla, joka estää palauttamisen ja joka noudattaa lakisääteisiä, sääntelyyn liittyviä, sopimusperusteisia ja sisäisiä vaatimuksia. Tämä sanamuoto kuvaa yhtä paljon yksityisyyden ja tietosuojan odotuksia kuin klassista tietoturvaa.

Useimmat studiot osaavat jo suojata live-järjestelmiä; paljon harvemmat pystyvät osoittamaan luotettavasti, mitä tiedoille tapahtuu, kun niitä "ei enää tarvita". Juuri tämä aukko on A.8.10:n ydin. Siinä pyydetään lopettamaan vanhojen pelaajatietojen ja lokien käsittely harmittomina arkistoina ja aloittamaan niiden käsittely omaisuuksina, jotka on tarkoituksella poistettava käytöstä. Olitpa sitten ottamassa käyttöön ISO 27001 -standardia ensimmäistä kertaa tai vahvistamassa kypsää tietoturvanhallintajärjestelmää, tämä kontrolli on se kohta, jossa säilytysaikataulut kohtaavat todellisen poistamisen.

Tietoja, joita et ole koskaan kerännyt tai poistanut ajoissa, ei voida koskaan varastaa, haastaa oikeuteen tai käyttää sinua vastaan.

Pelaajatietojen hamstraamisen piilokustannukset

Hamstrattuja pelaajatietoja piilee useammassa paikassa kuin useimmat joukkueet odottavat, vanhoista telemetriaputkista unohdettuihin testitietokantoihin. Jokainen ylimääräinen kopio pidentää haavoittuvuuden sädettä, jos joudut tietomurron kohteeksi tai kohtaat kysymyksiä siitä, kuinka kauan tietoja säilytetään, koska sinulla on enemmän järjestelmiä tarkasteltavana ja enemmän todisteita tarkasteltavana kuin suunnittelit.

Jos olet rehellinen siitä, missä pelaajatiedot sijaitsevat, löydät yleensä paljon muutakin kuin tilitaulukoita ja maksutietoja. Tyypillisiä esimerkkejä ovat:

Vanhat telemetriaputket, jotka vastaanottavat edelleen tapahtumia, vaikka koontinäyttöjä ei käytetä.
Vanhat kaatumisvedokset, joissa on raa'at laitetunnisteet ja pinonjäljitykset.
Chat-arkistot säilytetään "varmuuden vuoksi" moderointia varten, mutta niitä ei koskaan tarkisteta.
Kopiot tuotantotietokannoista testiympäristöissä ja hiekkalaatikoissa.

Jokainen näistä kopioista laajentaa laajuutta, jos jokin menee pieleen. Jos hyökkääjä päätyy analytiikkaklusteriisi tai sääntelyviranomainen kysyy alaikäisten tietojen säilytyksestä, et voi vain osoittaa pääasialliseen tilisi tietokantaan ja todeta, että asia on ohi. Sinun on otettava huomioon kaikki ne paikat, joihin tiedot ovat kulkeutuneet vuosien julkaisujen, päivitysten ja kokeilujen aikana.

Kyse ei ole pelkästään turvallisuudesta. Liiallinen säilytys myös heikentää sitä minimoinnista kertomaasi minimoinnista kertomaa tarinaa, jota kerrotaan yksityisyydensuojan vaikutustenarvioinneissa, kumppanikyselyissä ja alustakatsauksissa. Jos käytännöissä sanotaan, että lokeja säilytetään vuoden ajan, mutta järjestelmät säilyttävät niitä hiljaa viisi, sinulla on uskottavuusongelma jo ennen kuin mitään menee pieleen. Tiimeille, jotka virallistavat tietoturvanhallintajärjestelmäänsä, tämän luettelon näkyväksi tekeminen on usein suurin yksittäinen askel riskien vähentämisessä.

Kuinka poistamattomat lokit pahentavat tapauksia

Poistamattomat lokit hidastavat tapauksia, tekevät niistä kalliimpia ja vaikeampia selittää niitä, koska ne laajentavat mahdollisesti paljastuneen tiedon määrää ja lisäävät vaikutusten selvittämiseen tarvittavaa työtä. Kun säilytystä ei ole jaoteltu tarkoituksen mukaan, päädyt säilyttämään paljon arkaluonteisempia tietoja paljon pidempään kuin riski todellisuudessa oikeuttaa.

Kun reagoit tietomurtoon, kaksi asiaa on välittömästi tärkeitä: kuinka nopeasti pystyt selvittämään, mitä tietomurto paljastui, ja kuinka luottavaisesti pystyt selittämään tämän laajuuden johtajille, kumppaneille ja sääntelyviranomaisille. Pitkäikäiset, huonosti hallinnoidut lokit ja telemetriatiedot ovat molempien tavoitteiden vastaisia, koska ne sekoittavat rutiinijälkiä erittäin arkaluonteisiin tietoihin ja säilyttävät kaiken vuosia.

On hyödyllistä erottaa hallussasi olevat erityyppiset lokit toisistaan:

Toimintalokit: – suorituskyvyn, vakauden ja virheenkorjauksen osalta.
Tietoturvalokit: – pääsynvalvontaan, poikkeavuuksien havaitsemiseen ja tapahtumiin reagointiin.
Petos- ja huijauslokit: – pitkän aikavälin kaava-analyysiä ja valvontaa varten.

Tietoturva-, huijauksenesto- ja petostiimit puolustavat usein pitkiä säilytysaikoja, ja joissakin tapauksissa he ovat oikeassa. Ongelmana on, että säilytys on harvoin segmentoitua. Rutiininomaisia todennuslokeja ja erittäin arkaluonteisia petosringi-indikaattoreita käsitellään lopulta samalla tavalla, ja molempia säilytetään loputtomiin.

Käytännössä tämä tarkoittaa, että rikosteknisten tiimien on penkottava läpi valtavia tietomääriä ymmärtääkseen, mihin on koskettu, lakitiimien on harkittava, voidaanko erittäin vanhoja tietoja nyt paljastaa, ja operatiivisten tiimien on selviydyttävä paisuneiden lokivarastojen suorituskykyvaikutuksista. ISO 27001 A.8.10 -standardi pakottaa kurinalaisuuteen tässä hajanaisessa järjestelmässä selkeiden rajoitusten, automaation ja valvonnan avulla.

Miksi pelistudiot ovat ainutlaatuisen alttiita

Pelistudiot ovat epätavallisen alttiita tälle, koska ne keräävät syvällistä käyttäytymisdataa ihmisten pelaamisesta, kuluttamisesta ja vuorovaikutuksesta, usein myös alaikäisten ja haavoittuvien pelaajien osalta. Kun näitä tietoja säilytetään pidempään kuin on tarpeen, niistä tulee arkaluontoinen vastuu hyödyllisen omaisuuden sijaan, ja ne vaikeuttavat huomattavasti minkä tahansa tapauksen tai kritiikin hallintaa.

Peliyritykset keräävät kuluttajateollisuuden rikkainta käyttäytymisdataa. Usein seuraatte paitsi kulutus- ja kirjautumistapahtumia, myös sekunti sekunnilta tapahtuvaa pelaamista, chattia, sosiaalisia kaavioita, laiteprofiileja, sijaintivihjeitä ja huijausvastaisia signaaleja. Saatatte myös käsitellä alaikäisten, itsensä peliestojen asettaneiden pelaajien tai tiukkojen yksityisyyssääntöjen omaavien alueiden henkilöiden tietoja.

Kaikki tämä tekee poistamattomista tiedoista arkaluonteisempia:

Otteluhistoriat ja keskustelulokit voivat paljastaa pelikuvioita, ihmissuhteita ja joissakin tapauksissa terveydellisiä tai taloudellisia ongelmia.
Loot boxien ja mikromaksujen rahaksi muuttamisdata on lähellä kuluttajansuojaa koskevia keskusteluja.
Huijauksen ja petosten vastaiset järjestelmät voivat päätellä tai tallentaa arkaluonteisia riskiprofiileja yksilöistä.

Tarkastellaan yksinkertaista esimerkkiä alaikäisistä. Teini-ikäinen pelaa vanhempien suostumuksella, juttelee koulusta ja perheestä, käyttää rahaa vanhempien kortilla ja sulkee sitten tilinsä. Vuosia myöhemmin, jos yksityiskohtaiset ottelu- ja keskustelulokit ovat edelleen olemassa, sinulla on tarpeetonta ja erittäin arkaluontoista käyttäytymishistoriaa joltakulta aikuiselta ilman selkeää tarkoitusta. Sama pätee itsensä sulkemiin tai haavoittuviin pelaajiin, joiden tietoja sinulla on velvollisuus käsitellä huolellisesti.

Kun nämä tiedot säilyvät pitkään sen jälkeen, kun niitä tarvitaan, niihin liittyy tarpeeton yksityisyys- ja maineriski. A.8.10-standardin noudattaminen antaa sinulle mahdollisuuden pienentää tätä riskiä hallitusti sen sijaan, että odottaisit tietomurtoa, valitusta tai sääntelyviranomaisen pakottavan asian esiin. ISMS.online-alustan kaltainen alusta voi auttaa sinua näkemään tämän kuvan selkeästi kokoamalla käytännöt, tietovarastot ja kontrollit yhteen näkymään, jotta voit päättää, minkä todella on säilytettävä, mikä tulisi anonymisoida ja mikä lopulta poistaa, ja sitten näyttää tilintarkastajille, miten näitä päätöksiä pannaan täytäntöön.

Varaa demo

Mitä ISO 27001:2022 A.8.10 todella vaatii pelistudioilta

ISO 27001:2022 -standardin liite A.8.10 edellyttää, että käsittelet poistamista normaalina osana pelaajatietojen elinkaarta, ei jälkikäteen harkittuna. Päätät, milloin kutakin tietotyyppiä ei enää tarvita, valitset sopivan poisto- tai anonymisointimenetelmän ja todistat sitten, että kyseiset menetelmät todella toimivat tietoja säilyttävissä järjestelmissä.

Paperilla A.8.10 näyttää lyhyeltä, mutta sillä on syvällisiä seurauksia. Se edellyttää tiedon poistamista, kun sitä ei enää tarvita, tavalla, joka estää palauttamisen ja joka on linjassa lakien, säännösten, sopimusten ja sisäisten vaatimusten kanssa. Pelialan yritykselle tämä tarkoittaa poistamisen suunnittelua sisäänrakennettuna toimintona, ei kertaluonteisena skriptinä, joka tehdään, kun joku muistaa sen.

Käytännössä sinua pyydetään päättämään, milloin kutakin pelaajatietojen ja lokien tyyppiä ei enää tarvita, valitsemaan riskiin nähden asianmukaiset poisto- tai anonymisointimenetelmät ja pystymään osoittamaan, että kyseiset menetelmät todella toimivat. A.8.10 toimii rinnakkain liitteen A.5.32 kanssa, joka koskee tietojen säilyttämistä, ja kohdan 6 mukaisen riskienhallintaprosessin kanssa: päätät, mitä säilytät, kuinka kauan ja mitä uhkia turvallinen poistaminen auttaa sinua hallitsemaan.

Liitteen A.8.10 selkokielinen näkymä

Voit ymmärtää kohdan A.8.10 käsittelemällä sitä viitenä yksinkertaisena kysymyksenä datastasi ja päätöksistäsi. Nämä kysymykset eivät koske tiettyjen tuotteiden kuvailua, vaan niiden tarkoituksena on selittää yksinkertaisesti, mitä säilytät, miksi säilytät sen ja mitä teet, kun sitä ei enää tarvita.

Voit ajatella A.8.10:tä viiden kysymyksen varaan:

Mistä tiedoista sinä puhut?
Ei pelkästään "henkilötietoja" yksityisyyden suojan kannalta, vaan kaikki järjestelmissä, laitteissa tai medioissa olevat tiedot: tilitaulukot, pelitapahtumat, petoslokit, telemetria, varmuuskopiot, viennit ja paljon muuta.
Milloin sitä ei enää tarvita?
Tässä kohtaa A.8.10 kohtaa A.5.32:n säilytyksen ja lakisääteisten velvoitteidesi osalta. Ilmaisun "ei enää tarvita" on perustuttava tarkoitukseen ja lakiin, ei pelkästään mukavuuteen.
Miten poistat tai anonymisoit sen?
Loogiset poistot, kryptografinen pyyhkiminen, tallennustilan puhdistaminen, yhdistäminen ja anonymisointi voivat kaikki olla päteviä, mutta ne on valittava harkitusti.
Kuka on vastuussa?
Käytäntöjen ja menettelytapojen on määriteltävä vastuu sääntöjen määrittelystä, poistomekanismien käytöstä ja niiden toimivuuden tarkistamisesta.
Miten todistat sen?
Tarvitset todisteita: konfiguraatiota, lokeja, tikettejä ja sisäisen tarkastuksen tuloksia, jotka osoittavat, että poistamista tai anonymisointia todella tapahtuu.

Tästä näkökulmasta katsottuna A.8.10 ei ole niinkään "teknologia"-kontrolli vaan pikemminkin silta tiedonhallinnan – eli sen, mitä säilytät ja miksi – ja teknisen toteutuksen – eli sen, miten saat tiedot katoamaan tai niistä tulee vaarattomia – välillä.

Miten A.8.10 sopii tietoturvanhallintajärjestelmääsi

A.8.10 toimii vain, jos se on integroitu muuhun tietoturvallisuuden hallintajärjestelmäänne. Se perustuu riskinarviointeihinne ja säilytyspäätöksiinne, ja se tarjoaa konkreettisia kontrollikeinoja, joihin voitte viitata kuvaillessanne, miten vähennätte tapausten, auditointien ja tietosuojavalitusten vaikutusta.

Jos sinulla on jo tietoturvallisuuden hallintajärjestelmä, A.8.10:n ei tulisi toimia erillään muista. Se liittyy seuraaviin:

A.5.32 – Säilytys: , jossa sanotaan, että sinun on määriteltävä, kuinka kauan tietoja säilytetään. A.8.10 on suoritusosa: mitä tapahtuu kyseisen ajan kuluttua.
6 § – Riskien käsittely: jossa päätät, mitä uhkia vähennetään turvallisen poistamisen, anonymisoinnin tai minimoinnin avulla.
Kirjauksen ja valvonnan hallinta: koska lokien säilytyssääntöjen ja poistotöiden on oltava linjassa tietoturva-, petos- ja yksityisyysvaatimusten kanssa.
Pilvi- ja toimittajien hallinta: koska poistokerroksesi on katettava infrastruktuuri ja palvelut, joita et suoranaisesti hallinnoi.
Pääsyoikeuksien hallinta ja salaus: koska tehokas poistaminen on helpompaa, jos arkaluontoiset tiedot on eroteltu ja salattu hyvin hallinnoiduilla avaimilla.

Kun dokumentoit kontrollisi, on hyödyllistä osoittaa tämä yhteys nimenomaisesti: esimerkiksi viittaamalla säilytyssääntöihin poistomenettelyissäsi ja kirjaamalla riskienhallintasuunnitelmaasi, miten A.8.10 lieventää tiettyjä uhkia, kuten tiedon remanenssia tai liiallista säilytystä.

Poiston huomiotta jättämisen ja A.8.10:n mukaisen yhdenmukaistamisen välinen ero on usein räikeä:

Ilman säilytys- ja poistokuria	Yhdenmukainen A.8.10:n kanssa
Tapahtuman laajuutta on vaikea määritellä	Laajuus perustuu tunnettuihin, kartoitettuihin tietovarastoihin
Tarkastukset ovat reaktiivisia ja tuskallisia	Tarkastukset noudattavat dokumentoitua elinkaarta
Yksityisyyskerros tuntuu epäjohdonmukaiselta	Säilytyssäännöt ja järjestelmän toiminta vastaavat selvästi toisiaan
Pelaajien ja kumppaneiden luottamus on hauras	Voit osoittaa minimointi- ja säilytysrajoitukset

Tietoturvallisuuden hallintajärjestelmäalusta, kuten ISMS.online, helpottaa näitä yhteyksiä antamalla sinun yhdistää käytännöt, riskit, kontrollit ja todisteet, jotta tilintarkastaja – ja oma johtosi – voivat seurata suoraa linjaa yleisen tason vaatimuksista järjestelmiesi konkreettisiin toimiin.

Mitä tilintarkastajat oikeastaan etsivät

Tilintarkastajat eivät välitä pelkästään käytäntölauseesta, vaan siitä, miten suunnittelet, toteutat ja käytät poistomenettelyä, koska heidän on luotettava siihen, että vakuuttelusi vastaavat todellisuutta. He haluavat nähdä, että säilytyssäännöt ovat olemassa, niitä teknisesti valvotaan ja että niitä valvotaan, jos jokin epäonnistuu, jotta he voivat luottaa pelaajatietoja ja lokeja koskeviin lausuntoihisi.

Tilintarkastajat eivät koskaan tyydy yhteen lauseeseen, jossa sanotaan "poistamme tiedot, kun niitä ei enää tarvita". He etsivät tyypillisesti kolmenlaisia todisteita:

Suunnittelu: – dokumentoidut käytännöt, standardit ja menettelytavat, jotka määrittelevät säilytysajat, poistomenetelmät ja vastuut eri tietotyypeille.
toteutus: – järjestelmäkokoonpanot, automaatiotyöt ja prosessien artefaktit, kuten ajoitetut tehtävät, objektisäilön elinkaarisäännöt tai tietokantarutiinit, jotka vastaavat dokumenttien lupauksia.
Käyttö ja valvonta: – lokit, tiketit ja sisäiset tarkastustarkastukset, jotka osoittavat, että poisto tai anonymisointi on todella tapahtunut, että virheet havaitaan ja korjataan ja että poikkeukset kirjataan ja tarkistetaan.

Pelaajatietojen ja lokien osalta tämä voi tarkoittaa seuraavien tietojen näyttämistä:

Tärkeimpien tietoluokkien säilytys- ja poistomatriisi.
Pelaajien poistopyyntöjen käsittelymenettely.
Näytöt tai viennit tietokannasta, lokitietojärjestelmistä ja tallennusjärjestelmistä, joissa säilytys ja poisto on määritetty.
Näyte poistolokeista ja sisäisen tarkastuksen löydöksistä.

Jos pystyt vastaamaan yksinkertaisiin kysymyksiin, kuten "mistä voisin tarkistaa, että yli 18 kuukautta vanhat keskustelulokit poistetaan tai anonymisoidaan?", vaivattomasti, olet jo pitkällä A.8.10-vaatimuksen täyttämisessä ja seuraavan auditointisi tekemisessä paljon kivuliaammaksi.

ISMS.online antaa sinulle 81 %:n etumatkan heti sisäänkirjautumisestasi lähtien.

ISO 27001 helposti

Olemme tehneet kovan työn puolestasi ja antavat sinulle 81 % etumatkan kirjautuessasi sisään. Sinun tarvitsee vain täyttää tyhjät kohdat.

Aloita

”Oikeudesta tulla unohdetuksi” säilytysaikatauluihin: A.8.10:n yhdenmukaistaminen GDPR:n ja globaalin yksityisyydensuojan kanssa

Tietojen turvallinen poistaminen ei ole pelkästään turvallisuuskysymys, vaan se on myös tapa, jolla osoitat toimijoille ja sääntelyviranomaisille, että kunnioitat yksityisyyden suojaa. Tietosuojalait, kuten yleinen tietosuoja-asetus, edellyttävät, että minimoit hallussasi olevan tiedon, poistat tarpeettomat tiedot ja kunnioitat oikeuksia, kuten tietojen minimointia, tallennusrajoituksia ja oikeutta tietojen poistamiseen. Nämä periaatteet ovat läheisessä linjassa A.8.10:n kanssa, joka antaa sinulle käytännölliset ja operatiiviset keinot näiden odotusten täytäntöönpanemiseksi todellisissa järjestelmissä.

Sinun ei tarvitse olla yksityisyydensuojajuristi suunnitellaksesi hyviä poistomenetelmiä, mutta sinun on ymmärrettävä, miten lakisääteiset velvollisuudet heijastuvat säilytyssääntöihin ja tekniseen toimintaan järjestelmissäsi.

Keskeiset yksityisyyden suojan periaatteet, joiden pohjalta sinun on rakennettava

Kolme laajalti tunnettua ajatusta määräävät, kuinka kauan pelaajatietoja voi säilyttää ja mitä niillä on tehtävä. Ne esiintyvät monissa yksityisyydensuojaa koskevissa kehyksissä ja ovat yleisiä viitekohtia sääntelyviranomaisille, kun ne arvioivat käytäntöjäsi.

Nuo kolme ajatusta ovat:

Tietojen minimointi: – kerää ja käsittele vain se, mikä on riittävää, olennaista ja välttämätöntä käyttötarkoituksiisi nähden. Jos et todellakaan tarvitse yksityiskohtaista telemetriaa pelaajatasolla, harkitse sen sijaan koostettua raportointia.
Tallennusrajoitus: – säilyttää henkilötietoja tunnistettavassa muodossa vain niin kauan kuin on tarpeen kyseisten tarkoitusten kannalta. ”Saatamme tarvita niitä jonain päivänä” ei ole laillinen tarkoitus.
Poistamisoikeus: – monissa olosuhteissa pelaajat voivat pyytää sinua poistamaan henkilötietonsa, erityisesti silloin, kun he peruuttavat suostumuksensa tai kun alkuperäinen tarkoitus ei enää ole voimassa.

Peliyritykselle nämä periaatteet soveltuvat:

Tili- ja profiilitiedot.
Maksu- ja tapahtumatiedot.
Chat- ja sosiaalisen median tiedot.
Telemetria ja analytiikka.
Huijaus- ja petostentorjuntalokit.
Tukipyynnöt ja kiistahistoriat.

Jokainen näistä luokista vaatii nimenomaisia päätöksiä: kuinka kauan säilytät tunnistettavia tietoja, milloin siirryt anonymisoituihin tai koottuihin lomakkeisiin ja miten noudatat päteviä poistopyyntöjä. Vero- ja kirjanpitolait kulkevat usein näiden yksityisyyden suojaa koskevien periaatteiden rinnalla ja voivat ohittaa pelaajan tiettyjen tietojen poistopyynnön, joten sinun on kyettävä selittämään nämä vuorovaikutukset selkeästi.

Nämä tiedot ovat yleisiä eivätkä ne ole oikeudellista neuvontaa. Sinun tulee aina hankkia erityisiä oikeudellisia ohjeita lainkäyttöalueesi ja tuotevalikoimasi mukaan.

Periaatteiden ja oikeuksien muuttaminen konkreettisiksi säilytyssäännöiksi

Abstraktien yksityisyydensuojaoikeuksien muuttaminen selkeiksi säännöiksi on olennaista, jos haluat insinöörien ja operatiivisten tiimien toimivan johdonmukaisesti. Heidän on tiedettävä kunkin tietoluokan osalta, mikä on niiden tarkoitus, kuinka kauan niitä säilytetään ja mitä tapahtuu säilytysajan päättyessä, jotta he voivat toteuttaa oikeat toimintatavat.

Tietosuoja- ja tietoturvatiimit ovat usein yhtä mieltä periaatteista, mutta kitkaa ilmenee, kun insinöörit kysyvät yksityiskohtia. He tarvitsevat lukuja ja käyttäytymismalleja, eivät abstrakteja lauseita. Käytännöllinen lähestymistapa on laatia säilytys- ja poistoaikataulu, joka listaa kullekin pelaajatietojen luokalle seuraavat tiedot:

Tarkoitus: – miksi pidät sitä hallussasi, kuten pelin toimittaminen, petosten estäminen tai verolainsäädännön noudattaminen.
Oikeusperuste tai velvoite: – suostumus, sopimus, oikeutettu etu, lakisääteinen vaatimus.
Normaali säilytysaika: – kuinka kauan säilytät tunnistettavia tietoja normaalioloissa.
poikkeukset: – tilanteet, joissa sinun on säilytettävä tietoja pidempään, kuten avoimet riidat tai oikeudelliset säilytysvaatimukset.
Lopputila: – poistatko, anonymisoitko vai kokoatko tiedot kauden lopussa.
Poistomenetelmä: – käyttämäsi tekninen lähestymistapa, kuten rivien poistaminen, avainten tuhoaminen tai anonymisointi.

Kun pelaaja vetoaa oikeuteensa tietojen poistamiseen, voit perustella asian systemaattisesti:

Mitä luokkia pyyntö kattaa?
Onko olemassa lakisääteisiä velvoitteita, jotka edellyttävät sinua pitämään joitakin tietoja, esimerkiksi vero- tai rahanpesun vastaisia sääntöjä?
Missä järjestelmissä asiaankuuluvat tiedot sijaitsevat?
Mitä teknisiä toimintoja käytätte poistaaksenne tai anonymisoidaksenne tiedot, jos se on sallittua?

ISO 27001 -dokumentaatiosi ja yksityisyydensuojaa koskevien vaikutustenarviointiesi tulisi viitata samaan aikatauluun, jotta et yritä ylläpitää rinnakkaisia sääntöjä, jotka väistämättä ajautuvat pois tolaltaan ja joita on vaikeampi puolustaa.

Hankalien kategorioiden käsittely: petokset, alaikäiset ja riidat

Vaikeimmat kysymykset liittyvät yrityksen ja muiden toimijoiden suojaamiseen käyttämiisi tietoihin, koska nämä luokat herättävät yksityisyyteen ja oikeudenmukaisuuteen liittyviä kysymyksiä, vaikka ne oikeuttavatkin pidemmän säilytyksen. Saatat tarvita pidennettyä säilytystä petosten ja huijauksen estämiseksi tai oikeudellisten vaatimusten puolustamiseksi, mutta haluat myös minimoida yksilöistä säilyttämäsi tiedot ajan mittaan.

Joitakin vaikeimpia kysymyksiä liittyy dataan, jota käytät yrityksesi ja muiden toimijoiden suojaamiseen:

Petos- ja huijauslokit: – saatat tarvita pidempää säilytysaikaa havaitaksesi kaavoja ja puolustaaksesi pelin eheyttä.
Maksu- ja verotiedot: – Rahoituslait usein edellyttävät tiettyjen asiakirjojen säilyttämistä tietyn määrän vuosia.
Riitautus- ja tukilokit: – saatat tarvita tietoja, kunnes oikeudellisten vaatimusten vanhentumisajat ovat umpeutuneet.
Alaikäisten tiedot ja itsensä pelikieltoon asettaneet pelaajat: – sinulla voi olla lisävelvoitteita haavoittuvien ryhmien suojelemiseksi tai tiettyjen käsittelytapojen rajoittamiseksi.

Järkevä toimintatapa on asettaa näille tapauksille selkeät ja dokumentoidut säännöt sen sijaan, että sallittaisiin ad hoc -päätöksiä. Tämän jälkeen voidaan suunnitella toimenpiteitä, jotka tunnustavat sekä suojaavan tarkoituksen että yksityisyyden suojaamiseen liittyvän riskin.

Vaihe 1 – Kirjaa jännitys

Kirjoita ylös, miksi tarvitset pidennettyä säilyvyyttä tietyillä alueilla, mukaan lukien viittaukset lakiin, sääntelyyn tai alustaan liittyviin odotuksiin, jotta kompromissi on läpinäkyvä.

Vaihe 2 – Erottele riskialttiit tiedot

Säilytä riskialttiita lokeja ja profiileja selkeissä, rajoitetuissa paikoissa, joissa on vahvat käyttöoikeuksien hallintajärjestelmät ja selkeät säilytyssäännöt, jotta ne eivät sulaudu yleisiin järjestelmiin.

Vaihe 3 – Vähennä tunnistettavuutta ajan myötä

Siirry täysistä tunnisteista pseudonyymeihin ja pseudonyymeistä koostettuun tai täysin anonymisoituun dataan niin pian kuin se on käytännössä mahdollista, kuitenkin samalla täyttäen suojelutarpeesi.

Vaihe 4 – Tarkista pidennetty säilytysaika säännöllisesti

Sisällytä näiden erityistapausten säännöllinen tarkastelu hallintoon, jotta "väliaikainen" säilytys ei muutu pysyväksi laiminlyönnin tai sopimattomuuden vuoksi.

Konkreettiset esimerkit helpottavat näiden ideoiden toteuttamista. Petoslokeja voitaisiin tallentaa erilliseen tietokantaan, jossa tietyn iän jälkeen säilytetään vain tiivistettyjä tunnisteita, jolloin petosmallit pysyvät näkyvissä, mutta ihmiset altistuvat vähemmän petoksille. Maksutiedot voitaisiin jakaa siten, että vain verosääntöjen edellyttämät vähimmäistapahtumaviitteet ja summat säilytetään rahoitusjärjestelmässä erillään peliprofiileista. Alaikäisten ja itsensä poissulkemien pelaajien tilit voitaisiin merkitä, jotta joitakin turvallisuuteen liittyviä tietoja säilytetään määrätyn ajan, kun taas markkinoinnin telemetria- ja profilointitiedot katkaistaan paljon aikaisemmin.

A.8.10 ei syrjäytä lakisääteisiä velvollisuuksiasi, eikä yksityisyydensuojalaki estä sinua säilyttämästä tietoja, joita todella tarvitset oikeudelliseen puolustukseen tai vaatimustenmukaisuuteen. Ydin on, että pidempi säilytysaika on perusteltava, dokumentoitava ja teknisesti valvottava, eikä sitä pidä vain olettaa, jotta sääntelyviranomaiset ja toimijat voivat nähdä, että toimit oikeudenmukaisesti.

Pelaajatietojen ja lokin elinkaaren yhdistäminen A.8.10:een

Jotta A.8.10 toimisi käytännössä, sinun on ajateltava elinkaaren näkökulmasta. Pelaajatiedot eivät vain ilmesty ja katoa; ne siirtyvät kokoelmasta aktiiviseen käyttöön ja sitten eri tallennuskerroksiin ennen lopullista poistamista tai anonymisointia, ja A.8.10 liittää hallintakeinoja matkan jokaiseen vaiheeseen. Turvallinen poistaminen helpottuu paljon, kun tiedät jokaisessa vaiheessa, missä tiedot sijaitsevat ja mitä pitäisi tehdä seuraavaksi, ja kun kaikki tietoturvan, yksityisyyden, suunnittelun ja LiveOpsin edustajat jakavat saman kartan.

Monilla studioilla on epävirallisia ajatusmalleja tästä työnkulusta, mutta harvat ovat piirtäneet sen tavalla, johon eri tiimit voivat luottaa suunnitellessaan järjestelmiä, ominaisuuksia ja operatiivisia prosesseja.

Visuaalinen: yksinkertainen elinkaarikaavio kokoelmasta → aktiivinen käyttö → lämmin arkistointi → kylmä arkistointi → poistaminen/anonymisointi.

Tyypillinen elinkaari nykyaikaisissa peleissä

Useimmat nykyaikaiset pelipinot noudattavat samanlaista kaavaa, vaikka niiden nimet eroaisivatkin toisistaan. Pelaajat luovat tapahtumia, sinä käsittelet näitä tapahtumia kokemusten toimittamiseksi ja sitten siirrät vanhempaa dataa hitaasti kylmempiin, halvempiin tai rajoitetumpiin säilöihin. Poisto- ja anonymisointipäätökset toimivat vain, jos ne kunnioittavat tätä todellista datavirtaa sen sijaan, että teeskentelisivät kaiken datan olevan yhdessä siistissä tietokannassa.

Vaikka jokainen nimike on erilainen, pääpiirteittäin vaiheet ovat tuttuja:

Keräys ja nauttiminen: – pelaajat rekisteröityvät, tunnistautuvat, pelaavat otteluita, keskustelevat, käyttävät rahaa ja sinä syötät tapahtumia taustajärjestelmiin, lokeihin ja analytiikkaan.
Aktiivinen käyttö: – dataa käytetään pelin toimittamiseen, LiveOpsin suorittamiseen, matchmakingin mahdollistamiseen, varastojen hallintaan ja asiakastuen tarjoamiseen.
Lämmin arkistointi: – vanhemmat tiedot siirtyvät halvempaan tallennustilaan tai alemman prioriteetin taulukoihin, mutta ne pysyvät tunnistettavina jonkin aikaa, esimerkiksi tilin palauttamista tai pidempikestoisia tutkimuksia varten.
Kylmä arkistointi: – tietoja säilytetään vain velvoitteita, kuten vero-, sääntely- tai vakavien petosten tutkintaa, varten, usein rajoitetummin järjestelmissä.
Poisto tai anonymisointi: – tiedot poistetaan tai muutetaan siten, että ne eivät enää liity tunnistettavaan pelaajaan.

Tämä elinkaari koskee paitsi tilitaulukoita myös havainnoitavuus- ja tietoturvalokeja, telemetriaa ja datajärviä, huijauksenesto- ja riskien pisteytysjärjestelmiä, tuki- ja moderointityökaluja sekä kolmansien osapuolten integraatioita ja vientiä. Mitä selkeämmin pystyt osoittamaan, mitkä järjestelmät ja tietojoukot sijaitsevat missäkin vaiheessa, sitä helpompaa on määrittää A.8.10-kontrollit ja selittää ne tilintarkastajalle tai skeptiselle sidosryhmälle.

A.8.10-ohjaimien liittäminen jokaiseen vaiheeseen

A.8.10:n liittäminen elinkaareen tarkoittaa sen määrittämistä, minkä on oltava totta joka kerta, kun data ylittää rajan, koska riski muuttuu näissä rajoissa. Keräät uutta dataa, siirrät sen uuteen säilöön tai päätät, ettei sitä enää tarvita, ja jokainen siirtymä on tilaisuus valvoa datan poistamista, minimointia tai anonymisointia.

Yksi hyödyllinen tapa ajatella tätä on käsitellä A.8.10:tä tarkistuslistana, joka aktivoituu jokaisen vaiheen rajalla.

Kun data siirtyy kokoelma aktiiviseen käyttöön:

Tarkista, mitä keräät

Varmista, että kentät rajoittuvat pelattavuuden, toimintojen ja velvoitteiden kannalta välttämättömiin tietoihin, eivätkä ainoastaan kaikkeen, mitä voit tallentaa mielenkiinnon vuoksi.

Erota tunnisteet sisällöstä

Rakenna skeemoja siten, että pelaajatunnisteet voidaan poistaa tai vaihtaa tuhoamatta kaikkea hyödyllistä analyyttistä sisältöä tai liiketoiminnan mittareita.

Kun data siirtyy aktiivinen käyttö arkistoinnin lämmittämiseen:

Vahvista säilytysliipaisin

Aseta selkeä aika tai tapahtuma, jonka jälkeen tiedot siirtyvät pois aktiivisista säilöistä, ja dokumentoi, miten kyseinen käynnistin toteutetaan asiaankuuluvissa myyntiputkissa tai palveluissa.

Rajoita pääsyä ja säädä hallintalaitteita

Rajoita arkistoitujen tietojen käyttöoikeuksia ja määritä säilytysrajoitukset aikataulusi mukaisesti, jotta vanhemmat tiedot eivät kerry hiljaisesti.

Kun data siirtyy lämmintä kylmään arkistointiin:

Perustele, mikä jää jäljelle

Varmista, että kylmäsäilytykseen siirretään vain todella lakiin, sääntelyyn tai turvallisuuteen liittyvistä syistä tarvittavat tiedot ja että tämä perustelu dokumentoidaan.

Käytä vahvempia suojatoimia

Käytä tiukempia käyttöoikeuksien valvontaa, valvontaa ja tarvittaessa salausta kylmäarkistoissa, jotta vähemmän käytetyistä tiedoista ei tule helppoa kohdetta.

Kun data siirtyy kylmäarkistointi poistoon tai anonymisointiin asti:

Automatisoi lopputila

Määrittele automatisoitu työ tai prosessi, joka poistaa tai anonymisoi tiedot säilytysajan päättyessä sen sijaan, että luottaisi tilapäisiin puhdistuksiin.

Kerää todisteita ja epäonnistumisia

Kirjaa onnistuneet ajokerrat ja poikkeukset, jotta voit todistaa ohjauksen toimivuuden, tutkia vikoja ja tarkentaa lähestymistapaasi ajan myötä.

Jokaisella rajalla sinun pitäisi pystyä vastaamaan kysymykseen: ”Jos sanomme, että data siirtyy tähän vaiheeseen X:n jälkeen, mistä tiedämme, että se todella siirtyi, ja mitä sitten tapahtuu?” Näistä vastauksista tulee A.8.10-kontrolliesi selkäranka ja ne auttavat sinua osoittamaan sääntelyviranomaisille ja kumppaneille, että otat koko elinkaaren vakavasti.

Sisältää varmuuskopiot, testidatan ja pimeät nurkat

Varmuuskopiot, testiympäristöt ja viennit jäävät usein päivittäisen elinkaaren ulkopuolelle, mutta ne sisältävät suuria määriä pelaajatietoja, jotka voivat hiljaisesti heikentää poistotarjontaa. Sinun ei tarvitse toistaa kaikkia varmuuskopiointisuunnitelmiasi tässä, mutta sinun on tuotava nämä alueet samalle kartalle ja sitten luotettava teknisiin standardeihisi kattamaan, miten poisto todellisuudessa tapahtuu.

On helppo keskittyä ensisijaisiin järjestelmiin ja unohtaa, missä tiedot viipyvät. Varmuuskopioilla ja replikoilla on oma suunnitelmansa. Jos käytät pitkäikäisiä varmuuskopioita, et ehkä pysty poistamaan yksittäisten pelaajien tietoja kirurgisesti. Tässä tapauksessa sinun tulisi:

Salaa varmuuskopiot vahvoilla ja hyvin hallituilla avaimilla.
Aseta säilytysajat ja varmista, että vanhentuneet tiedot poistetaan.
Varmista, että vanhat varmuuskopiot ovat vanhentuneita tai palautettavissa olevia esimerkiksi tuhoamalla avain tai puhdistamalla tallennusväline.

Testi- ja lavastusympäristöt voivat sisältää suuria määriä tuotantodataa. Jos syötät niihin reaaliaikaisia tietueita, niiden on oltava elinkaari- ja poistosääntöjesi mukaisia tai sinun on anonymisoitava tiedot ennen käyttöä, jotta kehittäjät voivat työskennellä realististen mutta ei-tunnistettavien tietojen kanssa.

Vientejä ja raportteja – csv-tiedostoja, dataotteita ja kuvakaappauksia, joita käytetään analysointiin tai raportointiin – on joko hallittava tai vältettävä. Jos viennit ovat välttämättömiä, tallenna ne valvottuihin paikkoihin, joissa on selkeät säilytyssäännöt, ja suosi keskitettyä raportointia tai koontinäyttöjä aina kun mahdollista.

Yksinkertainen taulukko voi auttaa, ja siinä on sarakkeita, kuten ”Tallennus tai järjestelmä”, ”Elinkaaren vaihe” ja ”Säilytys- ja poistokäyttäytyminen”, ja enintään kourallinen rivejä otsikkoa kohden. Kun tämä vastaavuus on luotu, työkalut ja alustat voidaan mukauttaa siihen. Integroitu tietoturvallisuuden hallintaratkaisu, kuten ISMS.online, tarjoaa sinulle yhden paikan, johon voit tallentaa elinkaaren, siihen viittaavat käytännöt ja niiden noudattamista osoittavat todisteet, joten voit hallita pimeitä nurkkia yhtä harkitusti kuin ensisijaisia järjestelmiä.

Ota käyttöön, laajenna ja skaalaa vaatimustenmukaisuus ilman sotkua. Io antaa sinulle joustavuutta ja luottamusta kasvaa turvallisesti.

Varaa esittelysi

Tekniset mallit turvalliseen poistamiseen tietokannoista, lokeista, varmuuskopioista ja telemetriasta

Turvallinen poistaminen toimii vain, jos pohjana oleva arkkitehtuuri tekee siitä käytännöllisen ja turvallisen tiimiesi käyttöön. Tarvitset pienen joukon vakiomalleja, jotka insinöörit ymmärtävät, joiden käyttö on edullista ja joita tilintarkastajat voivat seurata, jotta et keksi poistamista uudelleen jokaiselle pelille ja palvelulle.

Parhaatkaan käytännöt eivät merkitse paljoa, jos arkkitehtuurisi tekee poistamisesta vaikeaa tai vaarallista. Hyvä uutinen on, että on olemassa toistettavia malleja, joita voit soveltaa monissa teknologioissa. Tavoitteena ei ole täydellisyys heti alusta alkaen, vaan pieni joukko vakiolähestymistapoja, jotka insinöörit ymmärtävät, jotka skaalautuvat pinon mukana ja joita auditoijat voivat seurata.

Keskeinen suunnittelutavoite on tehdä poistamisesta turvallisempaa ja halvempaa kuin ongelman sivuuttaminen. Tämä tarkoittaa tyypillisesti poistamisen suunnittelua skeema- ja putkitasolla sen sijaan, että sitä yritettäisiin asentaa myöhemmin.

Turvallinen poisto tuotantotietokannoissa ja -palveluissa

Turvallinen poistaminen reaaliaikaisissa tietokannoissa tarkoittaa pelaajatietojen poistamista tai tunnistamattomaksi tekemistä pelin toiminnallisuutta häiritsemättä, samalla varmistaen, että tiedot eivät jää hiljaa unohdettuihin taulukoihin. Voit valita useista päämalleista, ja sinun tulisi standardoida ne, jotka vastaavat riskinottohalukkuuttasi ja toiminnan kypsyyttäsi.

Pelaajatilejä, profiileja, tavaraluetteloita ja muita keskeisiä tietoja sisältävien tietokantojen osalta on useita vaihtoehtoja:

Fyysisen rivin poisto: – suoraviivaiset poistotoimenpiteet asianmukaisella ketjutuksella, joita seuraavat ylläpitotehtävät, kuten imurointi tai tiivistäminen varaston vapauttamiseksi tarvittaessa.
Pehmeä poisto ja säännöllinen pakotettu poisto: – tietueiden merkitseminen poistetuiksi lyhyeksi ajaksi tilin palauttamisen tai käyttöturvallisuuden tukemiseksi ja sen jälkeen pysyvä poistaminen määritetyn aikavälin kuluttua.
Osiointi ajan tai vuokralaisen mukaan: – taulukoiden tai kokoelmien jäsentäminen siten, että suuria määriä vanhentunutta dataa voidaan poistaa tai arkistoida irtotavarana.

Valitsetpa minkä tahansa mallin, sinun tulisi:

Erota tunnisteet vähemmän arkaluontoisesta sisällöstä aina kun mahdollista, jotta pienen liitostaulukon poistaminen voi tehokkaasti anonymisoida suuria pelidatamääriä.
Varmista, että sovelluslogiikka ei "herää" poistettuja tietoja välimuisteista, hakuindekseistä tai johdetuista säilöistä.
Toteuta idempotentteja poistorutiineja, jotta epäonnistuneen työn uudelleenyritys ei riko eheyttä eikä jätä osittaista tilaa.
Testaa kaskadipoiston ja viite-eheyden toimintaa perusteellisesti muissa kuin tuotantoympäristöissä, jotta varovaiset tietokannan ylläpitäjät voivat nähdä vaikutukset ennen kuin käsittelet reaaliaikaista dataa.

Dokumentoi nämä mallit osaksi A.8.10:n teknisiä standardeja ja linkitä ne takaisin aikataulusi säilytyssääntöihin. Tällä tavoin insinöörit tietävät, mitä mallia käyttää ja miten sen toimivuus todistetaan, kun uusi peli tai ominaisuus julkaistaan.

Säilytysherkkien lokien ja telemetrian suunnittelu

Lokit ja telemetria ovat välttämättömiä pelien suorittamiselle ja parantamiselle, mutta ne ovat myös yksi meluisimmista henkilötietojen lähteistä ja yleinen liiallisen säilytyksen lähde, joka hiljaisesti lisää riskiäsi. Tavoitteena ei ole lopettaa lokien kirjaamista tai sammuttaa järjestelmiä, vaan tallentaa vain tarvitsemasi tiedot, säilyttää niitä niin kauan kuin niistä on hyötyä, ja sitten joko poistaa ne tai poistaa suorat linkit yksilöihin. Säilytys ja poisto on suunniteltu alusta alkaen.

Hyödyllisiä periaatteita ovat:

Luokittele lokit käyttötarkoituksen mukaan: – turvallisuus, petokset, pelianalytiikka ja kaatumisdiagnostiikka voivat kukin oikeuttaa erilaiset säilytysajat.
Vältä enempää kuin on tarpeen kirjaamista: – älä sisällytä kokonaisia tunnisteita tai hyötykuormia, jos tiivisteet, tokenit tai koostetut mittarit riittäisivät.
Käytä sisäänrakennettuja säilytysasetuksia: – useimmat lokikirjaus- ja telemetria-alustat mahdollistavat aikaperusteisen säilytyksen ja automaattisen poiston asettamisen; määritä nämä aikataulusi mukaisesti.
Harkitse anonymisointia: – vanhempien, vain koosteanalyysissä käytettyjen tietojen tunnisteet korvataan tokeneilla tai poistetaan kokonaan tietyn ajan kuluttua.

Käytännössä tämä voi tarkoittaa yksityiskohtaisten tietoturvalokien pitämistä tietyn ajanjakson ajan, jonka jälkeen säilytetään vain karkeampia koosteita trendianalyysiä varten, tai pelaajatasolla yksityiskohtaisten pelitapahtumien säilyttämistä lyhyen aikaa ominaisuuksien hienosäätöä varten, minkä jälkeen ne kootaan anonymisoituihin ryhmiin. Keskeistä on, että nämä käyttäytymismallit konfiguroidaan keskitetysti ja ne voidaan todistaa, eikä niitä jätetä yksittäisten tiimien päätettävissä olevaksi.

Varmuuskopiot, arkistot ja kryptografinen poisto

Varmuuskopiot ja arkistot on rakennettu tietojen säilyttämistä varten, joten turvallinen poistaminen tarkoittaa tässä kokonaisten varmuuskopiosarjojen hallintaa yksittäisten pelaajien poistamisen sijaan, samalla kun annetaan uskottava kuva siitä, mitä tapahtuu, kun säilytysaika vanhenee. Käytännössä vanhentuneisiin tietoihin ei enää päästä käsiksi salauksen, aikarajoitetun säilytyksen ja avainten tai tallennusvälineiden hallitun tuhoamisen avulla.

Varmuuskopiot ovat erityinen haaste, koska ne on suunniteltu erityisesti tietojen säilyttämistä varten, ja usein suurissa, läpinäkymättömissä möykkyissä. Harvoin on mahdollista poistaa yhden pelaajan tietoja vuosikymmenen ajalta tehdyistä täydellisistä varmuuskopioista. Sen sijaan poistamista hallitaan varmuuskopiojoukkojen tasolla.

Käytännön vaiheisiin kuuluvat:

Varmuuskopioiden ja arkistojen salaaminen: vahvoilla avaimilla, joita hallitaan erillään datasta.
Varmuuskopioiden säilytysaikojen määrittäminen: jotka vastaavat riskinottohalukkuuttasi ja lakisääteisiä velvoitteitasi, ja vältä varmuuskopioiden pitämistä loputtomiin.
Varmista, että vanhoja varmuuskopioita ei voi palauttaa: tuhoamalla asiaankuuluvat avaimet tai tallennusvälineet hallitusti ja dokumentoidusti säilytysajan päätyttyä.
Vältä varmuuskopioiden käyttämistä arkistoina: säilyttämällä pitkäaikaisia tietoja tarkoitukseen rakennetuissa, käyttöoikeutta valvotuissa varastoissa, joissa on selkeät säilytysohjeet yleisten varmuuskopioiden sijaan.

Kryptografinen pyyhkiminen – datan tekeminen lukukelvottomaksi poistamalla tai peruuttamalla avaimet – on usein ainoa käytännöllinen tapa täyttää A.8.10-vaatimus laajamittaisissa varmuuskopioissa ja hajautetuissa objektisäilöissä. Se riippuu vankasta avaintenhallinnasta; jos avaimia käytetään uudelleen useissa tietojoukoissa tai ne on suojattu huonosti, takuusi ovat heikompia. Huolellisesti toteutettuna kryptografinen pyyhkiminen kuitenkin mahdollistaa toiminnallisen joustavuuden yhdistämisen vahvoihin takeisiin siitä, että vanhentuneet tiedot ovat todella poissa, mikä suojaa sekä pelaajia että studiotasi häiriötilanteissa.

Hallinto, roolit ja poikkeukset: poistamisen toimivuuden varmistaminen live-peliliiketoiminnassa

Turvallinen poisto toimii vain silloin, kun kaikki tietävät kuka päättää mistäkin, kuka tekee työn ja miten poikkeuksia käsitellään, koska muuten vanhat pelaajatiedot kasaantuvat hiljaa vaikeiden keskustelujen lykkäämisen myötä. Selkeä hallinto muuttaa A.8.10:n sivuprojektista normaaliksi osaksi pelien ja palveluiden toimintaa.

Poisto ei ole yhden tiimin tehtävä. Tietoturva ei voi tehdä sitä yksin, suunnittelu ei voi tehdä sitä yksin, eikä yksityisyys tai LiveOpskaan voi. Jotta A.8.10 toimisi ilman jatkuvaa kitkaa, tarvitaan selkeä hallintotapa: kuka tekee mitkäkin päätökset, kuka toteuttaa ne, kuka tarkistaa niiden toimivuuden ja miten poikkeuksia käsitellään.

Ilman tätä selkeyttä poistamisesta tulee sarja epämukavia keskusteluja ja pysähtyneitä tikettejä, mikä puolestaan rohkaisee ihmisiä välttämään aiheen esiin ottamista ollenkaan. Tiimeille, jotka ovat vasta aloittamassa ISO 27001 -matkaansa, näiden vastuiden kirjaaminen paperille varhaisessa vaiheessa estää yhtä tai kahta ihmistä omaksumasta kaikkea työtä hiljaa.

Määritellään kuka omistaa mitä

Säilytys- ja poistopäätösten omistajuuden määrittely välttää sekaannusta ja syyttelyä, koska kaikki näkevät, kuka on vastuussa ja kuka on vastuussa. Yksinkertainen RACI-matriisi, joka nimeää vastuuhenkilöt, vastuuhenkilöt, konsultoitavat ja tiedotettavat henkilöt, tekee selväksi, kenen on allekirjoitettava säännöt ja kenen on pidettävä tekniset tarkastukset toiminnassa.

Yksinkertainen RACI-matriisi (vastuullinen, tilivelvollisuus, konsultointi ja tieto) poistoa varten voi poistaa paljon sekaannusta. Tyypillisiä kaavoja ovat:

Tietoturva tai tietoturvajohtajan toiminto: – vastuussa A.8.10:n toteuttamisesta osana tietoturvan hallintajärjestelmää; konsultoitu riskien vaikutuksista.
Tietosuoja tai tietosuojavastaava: – vastuussa siitä, että säilyttäminen ja poistaminen ovat lakien ja pelaajan oikeuksien mukaisia.
Data- ja alustasuunnittelu: – vastaa teknisen poiston tai anonymisoinnin toteuttamisesta ja toiminnasta.
LiveOps ja tuote: – konsultoitu säilytyksen ja poistamisen vaikutuksesta pelien toimintaan ja analytiikkaan.
Pelaajien tuki ja yhteisötiimit: – vastaa pelaajiin kohdistuvasta viestinnästä ja monimutkaisten tapausten käsittelystä.

Kun näistä rooleista on sovittu, voit sisällyttää ne käytäntöjen omistajuusosioihin, muutoshallinnan työnkulkuihin sekä uusien järjestelmien ja toimittajien perehdytyksiin. Tällä tavoin, kun joku kysyy "kuka päättää, kuinka kauan keskustelulokia säilytetään?", vastaus on muu kuin "se riippuu siitä, kenen kanssa keskustelet", ja poistopäätökset voivat edetä samaan tahtiin kuin pelin kehitys.

Poikkeusten suunnittelu menettämättä hallintaa

Lähes jokainen studio tarvitsee poikkeuksia vakiomuotoisiin säilytyssääntöihinsä petos-, turvallisuus- tai oikeudellisista syistä, mutta vaarana on, että näistä poikkeuksista tulee pysyviä tavan vuoksi. Kevyt mutta kurinalainen poikkeusprosessi antaa sinun säilyttää tärkeitä tietoja tarvittaessa, esimerkiksi vilppitutkimusten tai sääntelyyn liittyvien tiedustelujen aikana, vaarantamatta hiljaisesti koko poistostrategiaasi.

Lähes jokainen studio tarvitsee poikkeuksia vakiomuotoisiin säilytyssääntöihinsä. Petokset, vilppi, vakavat turvallisuusongelmat ja viranomaistutkimukset edellyttävät joskus tietojen säilyttämistä tavallista pidempään. Riskinä on, että poikkeukset kasaantuvat epävirallisesti eikä kukaan koskaan tarkastele niitä uudelleen.

Vankka lähestymistapa on:

Vaadi dokumentoitu perustelu kaikille pidennettyille säilytysajoille, mukaan lukien tarvittaessa laki- tai sääntelyviittaukset.
Aseta kullekin poikkeukselle tarkistuspäivämäärä tai -ehto, kuten ”kunnes tutkinta X päättyy plus kaksi vuotta”.
Rajoita pitkäaikaissäilytysvaraston käyttöoikeus pienimpään mahdolliseen ryhmään, joka sitä todella tarvitsee.
Tarkastele avoimia poikkeuksia säännöllisessä hallintofoorumissa ja sulje ne, kun niitä ei enää tarvita.

Hyvä poikkeusrekisteri voisi näyttää tältä: ”Petostapaus F-123 – säilytä asiaankuuluvat tapahtuma-, laite- ja verkkolokit 31. joulukuuta 2028 asti; omistaja: petostentorjuntapäällikkö; tarkastus riskikomiteassa neljännesvuosittain.” Tämä tarkkuustaso pitää kaikki linjassa ja antaa selkeän auditointipolun, joka tukee sekä ISO 27001 -auditointeja että viranomaisvalvontaa.

Etulinjan tiimien kouluttaminen ja LiveOpsin yhdenmukaistaminen

Tukitiimit kääntävät poistokäytäntösi pelaajille suunnatuiksi lupauksiksi, joten jos tuki- ja yhteisötiimit kuvaavat "tilin poistamista" eri tavalla kuin järjestelmiesi toimintatapa, se aiheuttaa sekä luottamus- että vaatimustenmukaisuusongelmia. Koulutuksen, skriptien ja LiveOps-suunnittelun yhdenmukaistaminen A.8.10-kontrollien kanssa estää nämä aukot.

Pelaajat, vanhemmat ja jopa kumppanit ovat usein ensin yhteydessä etulinjan tiimien, kuten tuen, yhteisömanagerien ja LiveOpsin, kanssa. Jos nämä tiimit eivät pysty selittämään selkeästi, mitä "tilin poistaminen" tarkoittaa, tai mikä pahempaa, lupaavat asioita, jotka eivät teknisesti pidä paikkaansa, syntyy sekä luottamus- että vaatimustenmukaisuusongelmia.

Sinun tulisi siksi:

Anna yksinkertaisia selityksiä ja sisäisiä usein kysyttyjä kysymyksiä, jotka kuvaavat selkeästi, mitä poistetaan, mitä voidaan säilyttää oikeudellisista syistä ja millä aikaväleillä.
Kouluta henkilökuntaa tunnistamaan, milloin pyyntö voi aiheuttaa oikeudellisia pidätyksiä tai monimutkaisia poikkeuksia, ja miten asia voidaan siirtää asianmukaisesti eteenpäin.
Yhdenmukaista LiveOps-suunnittelu tulevien säilytys- tai poistomuutosten kanssa, jotta telemetria- tai segmentointistrategiat voidaan mukauttaa ajoissa.

Kun kaikki ymmärtävät, että turvallinen tietojen poisto on olemassa pelaajien ja studion suojelemiseksi, ei hyvien ideoiden estämiseksi, tuotteen ja vaatimustenmukaisuuden välillä on vähemmän viime hetken kiistoja – ja suunnittelussa on enemmän harkittuja ratkaisuja, jotka tukevat molempia. Tämä puolestaan vähentää tapaturmakustannuksia, rajoittaa sääntelyyn altistumista ja rakentaa pitkäaikaista pelaajien luottamusta.

ISMS.online tukee yli 100 standardia ja sääntöä, mikä tarjoaa sinulle yhden alustan kaikkiin vaatimustenmukaisuustarpeisiisi.

Varaa esittelysi

Pilvi, toimittajat ja jaettu vastuu poistosta

Nykyaikaiset pelit ovat vahvasti riippuvaisia pilvi- ja ohjelmistopalveluntarjoajista, mutta olet silti vastuussa siitä, miten pelaajatietoja tallennetaan ja poistetaan omassa alustassasi. A.8.10:n on siksi ulotuttava omien järjestelmiesi ulkopuolelle sopimuksiin, kokoonpanoihin ja toimittajan riskinarviointeihin, jotta tietoja ei säilytetä pidempään kuin on tarpeen vain siksi, että ne sijaitsevat jonkun toisen alustalla.

Hyvin pieni osa nykyaikaisesta peliohjelmistosta sijaitsee yksinomaan omassa datakeskuksessasi. Identiteetti, maksut, analytiikka, markkinointi, yhteisö, tuki ja jopa ydinjärjestelmät voivat kaikki olla riippuvaisia pilvi- ja ohjelmistopalveluiden tarjoajista. ISO 27001 A.8.10 -standardi on edelleen voimassa; se tarkoittaa vain, että poistokerros on ulotettava myös näihin tarjoajiin.

Et voi vain luottaa siihen, että "toimittaja hoitaa sen". Sinun on ymmärrettävä, dokumentoitava ja tarvittaessa sopimuksella määriteltävä, kuka poistaa mitä, missä ja milloin. Tämä on erityisen tärkeää silloin, kun palveluntarjoajat viittaavat omiin sertifiointeihinsa; yhden kehyksen noudattaminen ei takaa, että heidän säilytysaikataulunsa vastaavat sinun aikataulujasi tai että he tukevat sinun poistoaikataulujasi.

Jaetun vastuun mallin ymmärtäminen

Jaetun vastuun mallin ymmärtäminen auttaa sinua näkemään, mitä poistovipuja sinä hallitset ja mitkä ovat palveluntarjoajan vastuulla, jotta voit suunnitella realistisia hallintakeinoja oletusten sijaan. Sinä päätät, mitä pelaajatietoja palveluun syötetään, kuinka kauan niitä säilytetään ja milloin pyydät poistoa, kun taas palveluntarjoaja vastaa siitä, miten sen oma infrastruktuuri tyhjennetään tai kierrätetään.

Pilvipalveluntarjoajat puhuvat usein jaetusta vastuusta: he suojaavat infrastruktuurin, sinä suojaat sen käytön. Poiston osalta tämä jakautuu usein karkeasti seuraavasti:

Infrastruktuuri palveluna: – sinä hallitset käyttöjärjestelmiä, tietokantoja ja sovellustietoja; palveluntarjoaja hallitsee fyysisiä tallennusvälineitä ja matalan tason puhdistusta.
Palveluna tarjottava alusta: – hallitset tietojasi ja määrityksiäsi hallittujen palveluiden sisällä; palveluntarjoaja hoitaa varmuuskopiot ja taustalla olevat järjestelmät.
Ohjelmisto palveluna: – tyypillisesti sinä hallitset kokoonpanoa ja käyttötapoja; toimittaja hallitsee lähes kaikkea muuta.

Jokaisen merkittävän palvelun osalta sinun tulisi pystyä vastaamaan seuraaviin kysymyksiin:

Mitä tietoja pelaajistasi täällä tallennetaan?
Kuka voi määrittää säilytyksen ja poiston?
Mitä tiedoille tapahtuu, kun poistat tilin tai tietueen?
Miten palveluntarjoaja käsittelee varmuuskopiot ja sopimuksen päättyessä tapahtuvan tietojen palauttamisen tai tuhoamisen?

Näiden vastausten dokumentointi on osa sekä A.8.10:tä että muita ISO 27001 -standardin mukaisia pilvipalveluiden käyttöön liittyviä kontrolleja, ja se antaa selkeämmän pohjan toimittajan valinnalle ja neuvotteluille.

Poiston sopimukseen tekeminen

Poisto on paljon luotettavampaa, kun se on kirjattu sopimuksiin kuin epävirallisesti käsitelty, koska silloin sinulla on selkeä perusta odotustesi esittämiselle. Tietojenkäsittelysopimuksissasi ja tietoturva-aikatauluissasi tulisi määritellä säilytysrajat, poistopyyntöjen tuki ja se, miten tietoja käsitellään asiakassuhteen päättyessä.

Käytännöt ja hyvät aikomukset eivät riitä, kun muut organisaatiot säilyttävät tietojasi. Sopimuksissasi, tietojenkäsittelysopimuksissasi ja tietoturva-aikatauluissasi tulisi käsitellä seuraavia asioita:

Tietojen enimmäissäilytysajat sen jälkeen, kun ne ovat poistuneet järjestelmistäsi.
Velvollisuus avustaa pelaajien poistopyyntöjen kanssa sovitussa aikataulussa.
Miten varmuuskopioita, lokeja ja arkistoja käsitellään säilytysajan päättyessä tai sopimuksen päättyessä.
Mitä todisteita palveluntarjoaja antaa sinulle, kuten poistolokeja tai varmenteita, ja missä olosuhteissa.

Sinun tulisi myös varmistaa, että toimittajan riskinarvioinneissasi käsitellään nimenomaisesti tietojen poistamista. Jos palveluntarjoaja ei pysty kuvaamaan omia tietojen elinkaarensa ja poistokäytäntöjään tai jos se luottaa yksinomaan yleisiin sertifikaatteihin ilman säilytystietoja, se on tärkeä merkki siitä, että niitä on syytä käsitellä varoen tai neuvotella tiukempia ehtoja. Alan odotukset suosivat yhä enemmän selkeitä, kirjallisia poistositoumuksia sopimuksissa.

Kolmansien osapuolten viennin hallinta

Kolmannen osapuolen viennit luovat usein hallitsemattomia kopioita pelaajatiedoista, jotka lipsahtavat normaalin hallinnan ulkopuolelle ja voivat hiljaisesti heikentää jopa hyvin suunniteltua poistostrategiaa. Kojelaudat, CSV-viennit ja synkronoidut tietojoukot ovat käteviä, mutta jos niille ei anneta selkeitä säilytyssääntöjä, ne voivat jäädä huomaamatta vuosiksi.

Vaikka ydinpalvelut toimisivat hyvin, dataa voi vuotaa hallitsemattomiin paikkoihin seuraavien kautta:

Manuaaliset viennit kojelaudoista laskentataulukoihin.
Tietojen synkronointi liiketoimintatiedon hallintatyökaluihin.
Liitteet ja tiedostot tiketöinti- tai yhteistyöjärjestelmissä.

Nämä kopiot on helppo unohtaa ja vaikea poistaa kohdennetusti. Riskin vähentämiseksi:

Minimoi ad hoc -viennit mahdollisuuksien mukaan ja suosi paikallisia analytiikkatyökaluja.
Jos vienti on välttämätöntä, säilytä ne valvotuissa paikoissa, joissa on säilytysrajoitukset.
Sisällytä nämä mallit elinkaarikartoitukseen ja henkilöstön koulutukseen, jotta ne eivät jää huomaamatta.

Monissa studioissa pelkkä riskin tiedostaminen tiimeille ja paremman vaihtoehdon – kuten keskitettyjen raporttien tai koontinäyttöjen – tarjoaminen vähentää ongelmaa merkittävästi. Tämä puolestaan pienentää mahdollisuutta, että tutkinnassa tai tietomurrossa paljastuu tietoja, joiden olemassaolosta kukaan ei tiennyt.

Varaa esittely ISMS.onlinesta jo tänään

ISMS.online auttaa sinua muuttamaan ISO 27001 A.8.10 -standardin epämääräisestä poistosäännöstä selkeäksi ja auditoitavaksi joukoksi valvontakeinoja, jotka vähentävät poistamattomien pelaajatietojen ja säilytysherkkien lokien aiheuttamia riskejä kaikissa nimikkeissäsi ja palveluissasi. Keskittämällä käytäntösi, tietovarastosi, säilytysaikataulusi, tekniset standardisi ja todisteet alusta antaa sinulle yhden ja luotettavan kuvan siitä, miten tietoja hallitaan eri studioiden ja toimittajien välillä.

Näe A.8.10-kerroksesi yhdessä paikassa

Kun hallitset ISO 27001 -työtäsi erillisessä ympäristössä, kuten ISMS.online-palvelussa, saat käyttöösi useita etuja:

Säilytys- ja poistomatriisisi ovat rinnakkain riskinarviointien ja sovellettavuuslausuntojen kanssa, joten voit osoittaa tarkalleen, miten A.8.10 ja A.5.32 toimivat yhdessä tunnistettujen riskien lieventämiseksi.
Elinkaarikaavioista, järjestelmäluetteloista ja toimittajatiedoista tulee eläviä artefakteja, jotka päivittyvät pelien ja pelipinon kehittyessä sen sijaan, että ne olisivat lukittuina unohdettuihin diaesityksiin.
Poistojen todisteet – konfiguraatiovienneistä sisäisiin auditointimuistiinpanoihin – voidaan linkittää suoraan niiden tukemiin kontrolleihin, mikä tekee auditoinneista vähemmän viime hetken hässäkkää.

Tiimeille, jotka koordinoivat tietoturvan, yksityisyyden, datan, suunnittelun ja LiveOpsin osa-alueita, tämä yhteinen näkemys muuttaa epämääräisen idean poistamisesta konkreettiseksi ja seurattavaksi työohjelmaksi. Se antaa myös vähemmän kokeneille studioille rakenteen, jota he voivat seurata virallistaessaan valvontaa ensimmäistä kertaa. Tietoturvan hallintajärjestelmä voi myös säilyttää elinkaarikartat, säilytysaikataulut ja toimittajatiedot yhdessä paikassa, joten sinun ei tarvitse yrittää koota A.8.10-kerrosta hajallaan olevista dokumenteista ja yksittäisistä muistoista.

Seuraavat vaiheet studiollesi

Jos tunnistat oman ympäristösi yllä kuvatuista haasteista, lyhyt, keskittynyt keskustelu voi riittää näkemään, mitä voisi tehdä paremmin. Voit valita esimerkiksi:

Käy läpi yhden pelin pelaajatietojen elinkaari ja katso, missä nykyiset poisto- ja säilytysasetukset ovat puutteellisia.
Tarkista, miten olemassa olevaa ISO 27001 -dokumentaatiotasi voitaisiin käyttää uudelleen ja vahvistaa siten, että se kattaisi kohdan A.8.10 perusteellisemmin.
Tutki, miten työnkulut, tehtävien määritykset ja koontinäytöt voisivat pitää eri tiimit ajan tasalla siitä, kenen tehtävät ja milloin, jotta poistaminen pysyisi aikataulussa.

Varaa demo ISMS.online-palvelun kautta, niin näet, kuinka kaikki liitteen A.8.10 liikkuvat osat – lakisääteisistä säilytysrajoista ja elinkaarikartoituksesta teknisiin poistomalleihin ja auditointitodisteisiin – voidaan yhdistää yhdeksi ja hallittavaksi järjestelmäksi. Tämä puolestaan antaa sinulle mahdollisuuden kunnioittaa pelaajien tietoja, vähentää tapausten vaikutusta, tyydyttää auditoijia ja sääntelyviranomaisia sekä jatkaa loistavien pelien toimittamista luottavaisin mielin.

Varaa demo

Usein Kysytyt Kysymykset

Miten pelistudion tulisi miettiä uudelleen pelaajatietojen poistamista standardin ISO 27001 A.8.10 mukaisesti?

Pelaajatietojen poistamista tulisi käsitellä suunniteltu, todistettu vaihe elinkaaressa, ei tilapäinen palvelus, jonka teet tukipyyntöjen kautta.

Miten A.8.10 muuttaa arkipäivän oletuksia "poistosta"?

Standardin ISO 27001 A.8.10 mukaan "poistamme tilit pelaajien pyynnöstä" on ehdoton minimi, ei toimintamalli. Lauseke edellyttää, että:

Käsittele jokaista pelaajatietojen luokkaa (tilit, maksut, chat, telemetria, huijauksenesto, tuki) yhtenä hallinnoitu omaisuus jolla on tarkoitus, omistaja ja määritelty lopputila.
Päätä etukäteen, milloin kukin kategoria siirtyy pois aktiivinen käyttö (tarvitaan pelin suorittamiseen tai suojaamiseen) perusteltu säilytys (verotus, riidat, petokset, turvallisuus) ja lopulta poistaminen tai anonymisointi.
Muuta nuo päätökset toistettavia teknisiä mallejaKorjatut pehmeän poiston aikaikkunat, ajoitetut pakolliset poistot, anonymisointityöt ja elinkaarisäännöt tallennus- ja lokialustoilla.
kaapata todisteita siitä, että nämä mallit toimivattyölokit, muutostietueet, konfiguraatioviennit ja näytetarkistukset, joita tietoturvajärjestelmäsi voi säilyttää A.8.10-kontrollin rinnalla.

Todellinen siirtymä tapahtuu improvisaatiosta ennustettavuusStudio, joka tietää tarkalleen, missä tunnistettavia toimijoita on enää olemassa, missä on jäljellä vain anonymisoituja ryhmiä ja mikä on kokonaan vanhentunut, sen räjähdyssäde on pienempi, kun jokin menee pieleen, ja se selittää itseään auditoijille tai alustoille siistimmin.

Miten tietoturvan hallintajärjestelmä tekee tästä ajattelutavasta käytännöllistä?

Tietoturvallisuuden hallintajärjestelmä tarjoaa sinulle yhden linkkipisteen politiikka, riski ja toteutus:

Pidät tietoluokkien luettelot, säilytyssäännöt ja poistostandardit yhdessä työtilassa.
Jokainen A.8.10-kohtainen kontrolli liittyy tiettyihin riskeihin, järjestelmiin ja toimintatapoihin sen sijaan, että se olisi abstrakti sanamuoto.
Sisäiset auditoinnit, muutosten hyväksynnät ja tapausten tarkastelut voivat kaikki viitata samoihin artefakteihin, joten poistamisesta tulee miten rakennat ja käytät pelejä, ei kertaluonteinen siivous ennen sertifiointia.

Kun pystyt rauhallisesti ohjaamaan tilintarkastajan läpi riskirekisteristä → säilytyssäännöistä → teknisistä kaavoista → todisteista, studiosi näyttää ymmärtävän pitkäaikaisen pelaajien luottamuksen, ei vain lyhytaikaisen ominaisuuksien toimituksen. Tietoturvan hallintajärjestelmä, kuten ISMS.online, helpottaa tätä läpikäyntiä huomattavasti pitämällä kontrollit, tiedot ja vastuut tiiviisti yhteydessä toisiinsa ja aina ajan tasalla.

Miten voimme suunnitella pelaajatietojen säilytysaikatauluja, jotka suojaavat petoksia, turvallisuutta ja analytiikka-arvoa?

Suunnittelet asiakaspysyvyyden miksi kuulut kuhunkin kategoriaan ja mikä laki tai sopimus sen sallii, ei sen tietokannan tai kojelaudan ympärille, joka tuntuu tärkeimmältä.

Miten rakennamme asiakaspysyvyyttä mittaavan matriisin, joka toimii koko pelialan laajuisesti?

Useimmat studiot hyötyvät yhdestä retentiomatriisi joka kattaa kaikki pelaajatietotyypit:

Tili ja identiteetti (kirjautumistiedot, yhteystiedot, ikärajat)
Maksut ja laskutustiedot
Keskustelu ja sosiaalinen vuorovaikutus
Tietoturva- ja infrastruktuurilokit
Huijauksen ja petosten estämiseen tarkoitetut indikaattorit
Pelin telemetria ja käyttökokemusanalytiikka
Tuki- ja yhteisötiketit

Jokaiselle riville merkitset neljä asiaa:

Tarkoitus: – miksi keräät sitä (pelin pyörittäminen, pelaajien laskuttaminen, turvallisuuden ylläpitäminen, petosten torjunta, suunnittelun parantaminen).
Oikeudellinen/sopimusperusteinen: – kuluttajansuojalainsäädäntö, verosäännöt, PCI DSS, alustaehdot, yksityisyydensuojalainsäädäntö ja niin edelleen.
Minimisäilytys: – mitä sinun on säilytettävä pysyäksesi vaatimusten mukaisena (esimerkiksi verotiedot tai takaisinperintäikkunat).
Tunnistettavan tiedon enimmäissäilytysaika: – hetki, jolloin poistat tai anonymisoit yksilöitä, vaikka säilyttäisitkin koostetut mallit.

Petokset ja turvallisuus ovat seikkoja, joissa tiimit usein sortuvat "pidä kaikki ikuisesti" -ajatteluun. A.8.10 ei estä pidempiä käyttöikkunoita, jos riski todella oikeuttaa ne, mutta se edellyttää, että:

Anna nuo kategoriat selkeät, perustellut kestot (esimerkiksi riita-ajanjakso plus määritelty puskuri).
Erota raa'at, tunnistettavat tiedot muista johdetut signaalit (riskipisteet, tiivistetyt tunnisteet, anonymisoidut kohortit), joten voit säilyttää signaaleja pidempään kuin henkilöllisyyttä.
Käsittele epätavallisia tutkimuksia aikarajoitetut poikkeukset, joista jokaisesta on merkitty omistaja ja tarkistuspäivämäärä, ilmoittamattomien pysyvien poikkeusten sijaan.

Analytiikan puolella useimmat suunnittelupäätökset riippuvat kaavoja tiettyjen pelaajien sijaanSen avulla voit lyhentää täyden tarkkuuden telemetriatietojen säilytysaikaa ja siirtää vanhempia tietoja koostetut tai anonymisoidut katselukerrat että tuote- ja datatiimit voivat edelleen tehdä kyselyitä. Se myös pakottaa sinut tuomaan viennit (BI-otteet, CSV-vedokset, hiekkalaatikkodatajoukot) samaan elinkaareen sen sijaan, että ne jätettäisiin näkymättömiksi pitkäaikaisiksi kopioiksi.

Missä näiden sääntöjen tulisi sijaita, jotta ne pysyisivät todellisina?

Säilytyssäännöt rappeutuvat nopeasti, jos ne piiloutuvat sähköpostiketjuihin tai erillisiin laskentataulukoihin. Kun hallitset niitä tietoturvajärjestelmässä:

Tietosuoja, tietoturva, analytiikka ja suunnittelu voivat kaikki vahvistaa yksittäinen, jaettu matriisi.
Arvioinnit voidaan kytkeä riskirekisteriin ja johdon arviointisykliin.
Todisteet, kuten kokoonpanonäyttökuvat, käytäntöjen vahvistukset ja pistokokeen tulokset, sijaitsevat sääntöjen vieressä, joten voit näyttää auditoijille sekä päätös ja miten se toimii käytännössä.

Jos haluat muuttaa A.8.10:n huolenaiheesta suunnittelutyökaluksi, matriisin keskittäminen alustalle, kuten ISMS.online, tekee suuren eron. Saat yhden näkymän säilytykseen, joka on linjassa ISO 27001 -standardin, tietosuojavelvoitteiden ja live-ops-todellisuuden kanssa.

Mitä turvallinen poisto oikeastaan tarkoittaa pelitietokantojen, lokien, telemetrian ja varmuuskopioiden osalta?

Turvallinen poistaminen tarkoittaa, että kun tiedot saavuttavat määritellyn käyttöikänsä lopun, ne poistetaan. ei enää käytännössä korjattavissa kohtuullisella vaivalla, live-järjestelmissä, analytiikkapinoissa ja varmuuskopioissa.

Miten meidän tulisi käsitellä reaaliaikaisia palveluita ja tietokantoja?

Ydinpalveluissa, jotka sisältävät tilejä, oikeuksia, inventaarioita ja vastaavia pelaajatietoja, turvallinen poistaminen yhdistää yleensä seuraavat:

Sovellustason toiminnot: , kuten rivitason tietueiden poistaminen tai anonymisointi, kun säilytyssääntö täyttyy tai poistopyyntö on validoitu.
Aikaan perustuva osiointi: , joten kokonaisia taulukon osioita tai sirpaleita (esimerkiksi kuukauden tai vuodenajan mukaan) voidaan poistaa, jolloin vältetään kalliit rivi riviltä tehtävät siivoukset.
Rutiininomainen varaston ylläpito – tiivistäminen tai imurointi – jotta "poistetut" tiedot eivät jää loputtomiin varaamattomaan tilaan.

Avain on ilmaista nämä seuraavasti talon kuviot, ei yksittäisten kehittäjien valintoja. Yksinkertainen sisäinen standardi, kuten ”tilit käyttävät mallia A; tapahtumahistoria käyttää mallia B; varastot käyttävät mallia C”, tekee käyttäytymisestä ennustettavaa eri nimikkeiden välillä ja paljon helpompaa dokumentoida A.8.10:n mukaisesti.

Entä lokit, telemetria ja pitkäaikainen tallennus?

Lokivirrat ja telemetria sisältävät usein rikkaampi pelaajakonteksti kuin ensisijainen pelitietokanta. Näissä järjestelmissä turvallinen poisto perustuu vahvasti kokoonpanoon:

Sisäänrakennettu säilytys- ja rotaatiosäätimet lokikirjaus- ja havainnointityökaluissa, jotka on viritetty eri tavoin pelattavuuden, suorituskyvyn ja tietoturvan osalta.
Varhainen minimointi – tunnisteiden hajauttaminen, katkaiseminen tai tokenisointi lähellä lähdettä – jotta jokainen lokirivi ei paljasta koko identiteettiä, jota seuraa anonymisointi tai alasotanta datan vanhetessa.
Elinkaarisäännöt objektitallennuksessa tai datajärvissä, jotka vanhenevat tai arkistoivat tietojoukkoja ja koordinoivat niitä avaintenhallinta, jolloin voit poistaa salausavaimet käytöstä, kun tietojen pitäisi käytännössä kadota.

Varmuuskopioiden fyysinen pyyhkiminen ei ole enää realistista. Monet kokeneet studiot käyttävät... kryptografinen poisto Sen sijaan: salaa erilliset tietojoukot rajatuilla avaimilla ja käsittele ajoitettua avainten käytöstä poistamista poistotapahtumana. Yhdessä elinkaarikäytäntöjen ja avaintenhallintalokien kanssa tilintarkastajat ja sääntelyviranomaiset hyväksyvät tämän laajalti käytännöllisenä tapana lopettaa luettavan historian säilyttäminen.

Toimivuustesti on yksinkertainen: jokaiselle pelaajatietojen päävarastolle voit vastata kolmeen kysymykseen – Mitä tapahtuu, kun säilytys päättyy, kuka sen käynnistää ja miten se todistetaanTietoturvajärjestelmä, kuten ISMS.online, auttaa pitämään vastaukset johdonmukaisina ja todisteina eri tietokannoissa, lokialustoilla ja varmuuskopiointijärjestelmissä.

Kuinka pelistudio voi kartoittaa pelaajatietojen elinkaaren niin, että ISO 27001 A.8.10 on järkevä kaikille?

Kartoitat elinkaaren, jotta ihmiset näkevät A.8.10:n yhtenä jaettu kuva pelaajatietojen virrasta, ei standardin kappaleena.

Miltä käytännönläheisen elinkaarikartan tulisi näyttää?

Yhden lippulaivajulkaisun kohdalla elinkaarikartta, joka todella auttaa ihmisiä, voisi:

Aloita siitä, mistä tiedot näkyvät: tilin luominen, kirjautuminen, ostot, pelitapahtumat, chat, huijaustutkimukset, tukiyhteystiedot, markkinoinnin aloituspisteet.
Näytä, mihin data päätyy seuraavaksi: tilipalvelu, matchmaking, huijauksen esto, telemetrian kerääjät, tietovarasto, lokialustat, CRM ja yhteisötyökalut.
Erottaa aktiiviset järjestelmät, lämmin säilytys, arkisto ja poisto/anonymisointi Tasot.
Merkitse tapahtumat, jotka käynnistävät säilytyskellot (viimeisin toiminto, tilauksen päättyminen, takaisinveloitusikkunan päättyminen) ja prosessit tai työt jotka toimivat, kun nuo pisteet saavutetaan.
Sisällytä vähemmän ilmeisiä varjopuolia: tuotantoympäristöistä täytetyt testiympäristöt, datatieteen hiekkalaatikot, CSV-viennit ja paikalliset kehittäjäkopiot.

Kun näkymä on luotu yhdelle pelille, voit standardoida mallin ja soveltaa sitä muihin peleihin sen sijaan, että suunnittelisit säilytysprosessin alusta alkaen joka kerta. Uusien järjestelmien tai toimittajien on sitten ilmoitettava missä kohtaa elinkaarta ne sijaitsevat ja miten he kunnioittavat samoja siirtymiä.

Miten tämä liittyy takaisin A.8.10:aan ja tietoturvanhallintajärjestelmääsi?

Tietoturvajärjestelmässäsi viitatun elinkaaren artefaktin avulla voit:

Linkitä A.8.10 suoraan kohteeseen nimetyt siirtymäpisteet: milloin tiedot poistuvat aktiivisesta käytöstä, milloin ajastimet käynnistyvät ja milloin poisto tai anonymisointi sovelletaan.
Määritä vastuut jokaisessa vaiheessa, jotta on selkeää, kuka määrittää säilytyksen, kuka suorittaa työtehtäviä ja kuka tarkistaa todisteet.
Käytä karttaa uudelleen suunnittelukatselmukset, muutosten hyväksynnät ja toimittaja-arvioinnit, joten tietoturva-, yksityisyys- ja suunnittelutiimit argumentoivat samasta kaaviosta kilpailevien oletusten sijaan.

ISMS.online-järjestelmän avulla tuon kartan, sitä tukevien sääntöjen ja niihin liittyvien menettelytapojen säilyttäminen tarkoittaa, että elinkaariajattelusta tulee osa normaalia hallintoasi. Johdon katselmuksissa ja sisäisissä auditoinneissa voidaan kysyä "missä kohtaa elinkaarta tämä data oli?" tapahtumien jälkeen, ja juuri siksi A.8.10 alkaa tuntua osana hyvää pelisuunnittelua pelkän valintaruudun sijaan.

Kenen tulisi omistaa säilytys- ja poistopäätökset live-pelialan toiminnassa, ja miten estämme poikkeusten leviämisen?

Säilytyksestä ja poistamisesta tulee luotettavia, kun ne on selkeä omistajuus, yksinkertainen päätöksentekoprosessi ja poikkeusten näkyvä seuranta.

Miten roolit jaetaan ilman byrokratian kasvua?

Käytännössä useimmat live-studiot käyttävät kevyttä RACI-tyylistä splittiä:

Turvallisuus- tai CISO-toiminto on vastuussa A.8.10:n täyttämiseksi eri nimikkeiden ja jaettujen palvelujen osalta.
Tietosuojaan tai lakiin liittyvä toiminto on vastuullinen sen varmistamiseksi, että säilytys ja poistaminen ovat lain, alustan velvoitteiden ja pelaajille antamasi ohjeiden mukaisia.
Data- ja alustakehitystiimit ovat vastuullinen poisto- ja anonymisointimallien toteuttamiseen ja käyttämiseen koodissa, infrastruktuurissa ja dataputkissa.
LiveOps, tuote ja analytiikka ovat Kuulemisen kohteena jotta säilytysajat eivät hiljaisesti heikennä petosten torjuntaa, kokeilujen suunnittelua tai pelaajakokemusta.
Tuki- ja yhteisötiimit ovat vastuullinen pelaajien pyyntöjen käsittelyyn, odotusten hallintaan ja epätavallisten tapausten merkitsemiseen, jotka saattavat johtaa tilapäisiin jatkosopimuksiin.

Estääksesi poikkeuksia hitaasti heikentämästä malliasi, lisäät kevyen hallintosilmukan uuden komitean sijaan:

Kaikista pidennettyistä säilytysajoista, jotka johtuvat tutkinnasta, petostapauksista tai turvallisuussyistä, ilmoitetaan syy, omistaja ja tarkistuspäivämäärä.
Näitä tietoja tarkastellaan samaan tahtiin kuin muita riski- ja vaatimustenmukaisuusaiheita – esimerkiksi neljännesvuosittaisissa tietoturvan hallintajärjestelmien (ISMS) tarkasteluissa.
Pieni joukko A.8.10-mittareita – kuten poistopyyntöjen ajallaan suorittaminen, lukumäärä myöhästyneet poikkeuksetja järjestelmistä puuttuu edelleen määriteltyjä sääntöjä – näkyy säännöllisessä raportoinnissa.

Kun hallitset tätä tietoturvanhallintajärjestelmässä, kuten ISMS.onlinessa, samat työnkulut, jotka käsittelevät tapauksia, muutoksia ja riskejä, voivat sisältää säilytys- ja poistopäätöksiä. Näin pelaajatietojen käsittely pysyy linjassa sen kanssa, mitä kerrot pelaajille, kumppaneille ja sääntelyviranomaisille, jopa silloin, kun studio on käynnistystilassa tai sammutustoiminnassa.

Miten pilvipalvelut ja toimittajat muuttavat lähestymistapaamme A.8.10:een, ja mitä meidän tulisi sisällyttää sopimuksiin ja kokoonpanoihin?

Pilvi- ja SaaS-palvelut muuttuvat missä ja miten pelaajatietoja tallennetaan ja poistetaan, mutta ne eivät muuta todellisuutta, että studiosi on edelleen vastuussa sen päättämiseksi, mitä tietoja säilytetään, kuinka kauan ja milloin ne on poistettava tai anonymisoitava.

Mitä meidän tulisi tallentaa jokaisesta pelaajadataan liittyvästä palvelusta?

Jokaisen pelaajatunnisteita tai käyttäytymistietoja hallussaan pitävän palveluntarjoajan osalta ISMS-tietueissasi tulee olla seuraavat tiedot:

Joka pelaajatietojen luokat se tallentaa (tunnukset, yhteystiedot, maksutokenit, keskustelulokit, telemetria, tukitiedot) ja mille nimikkeille, alueille tai alustoille.
Joka säilytys- ja poistovaihtoehdot Voit hallita: lokien säilytysliukusäätimiä, objektitallennuksen elinkaarisääntöjä, sisäänrakennettuja poistotyökaluja ja tilin sulkemistoimintoja.
Miten poisto käytännössä käynnistyy – konfiguroinnin, ajoitettujen prosessien, API-kutsujen tai tukipyyntöjen perusteella – ja mitä se tarkoittaa varmuuskopiot, kopiot ja analytiikkaviennit.
Mitä näyttö Voit kerätä ja säilyttää: konfiguraatiovientejä, tarkastuslokeja, SOC 2- tai ISO 27001 -raportteja, toimittajien lausuntoja varmuuskopioiden käsittelystä ja sopimuksen päättymisen jälkeisestä tallennusvälineiden puhdistamisesta.

Nuo yksityiskohdat muokkaavat kahta keskeistä esinettä:

Sisäinen elinkaari- ja säilytysmatriisi, jossa kolmannen osapuolen tallennustilat näkyvät yrityksen sisäisten tietokantojen ja lokialustojen rinnalla.
Sinun sopimukset ja tietojenkäsittelysopimukset, jonka tulisi asettaa odotukset maksimaaliselle säilytykselle, poistotuelle, varmuuskopioiden käsittelylle ja toiminnalle lopetuksen tai siirron yhteydessä.

Toimittajan riskinarvioinneissa tietojen poistamista ja säilyttämistä tulisi käsitellä samalla tasolla kuin salausta ja käyttöoikeuksien hallintaa. Jos palveluntarjoaja ei pysty noudattamaan pelaajatiedoille määrittelemääsi elinkaarta, siitä tulee tietoinen riskinotto tietoturva- ja yksityisyysliidienne kannalta eikä vahingossa tapahtuva vaarantuminen julkaisupaineen alla.

Kun hallitset näitä odotuksia, konfiguraatioita ja todisteita ISMS.online-palvelun sisällä, ylläpidät johdonmukaista A.8.10-tasoa, vaikka toimittajavalikoimasi kehittyisi. Voit näyttää, mitkä palvelut säilyttävät mitäkin pelaajatietojen luokkia, kuinka kauan ne säilyttävät niitä, miten poistaminen tai anonymisointi käynnistetään ja mihin tallennetaan todisteita siitä, että se tapahtuu – juuri sitä selkeyttä, jota alustat, sääntelyviranomaiset ja pelaajat etsivät päättäessään, luottavatko he pelistudioon pitkällä aikavälillä.

ISO 27001 A.8.10 – Pelaajatietojen ja säilytysarkaluonteisten lokien turvallinen poistaminen