Miksi ISO 27001 A.5.13 -standardin mukainen merkintä suojaa arkaluonteisia tietoja pelaamisessa

Piilotettu riski: Merkitsemättömät arkaluonteiset tiedot pelijärjestelmissä

Merkitsemätöntä arkaluonteista dataa virtaa lähes kaikissa peliohjelmistosi osissa, joten ihmiset ja työkalut usein käsittelevät riskialtista tietoa harmittomana. Kun lokeja, vedoksia ja datajoukkoja, jotka sisältävät pelaajien henkilöllisyyksiä, korttitietoja, maksujälkiä tai huijauksenestojärjestelmää, ei ole merkitty selkeästi, insinöörit, tukitiimit ja automatisoidut järjestelmät käsittelevät niitä oletusarvoisesti rutiininomaisena teknisenä kohinana, ja jokapäiväiset päätökset niiden kopioimisesta tai salassa pitämisestä lisäävät altistumistasi. ISO 27001 A.5.13 on standardi, joka pakottaa sinut tekemään tästä arkaluonteisesta datasta näkyvää ja johdonmukaista, jotta voit yhdenmukaistaa käyttöoikeuden, säilytyksen ja valvonnan todellisten riskien kanssa.

Nämä tiedot ovat yleisiä eivätkä ne ole oikeudellisia, sääntelyyn liittyviä tai PCI DSS -neuvoja. Sinun tulee aina tehdä ISO 27001 -, GDPR- tai PCI DSS -standardin noudattamista koskevat päätökset asianmukaisen ammatillisen tuen kanssa, joka on otettu huomioon lainkäyttöalueellasi ja riskiprofiilissasi.

Ihmiset käsittelevät dataa sillä riskitasolla, jonka he näkevät.

Missä arkaluontoiset tiedot todella sijaitsevat pelissä

Nykyaikaisissa peleissä arkaluontoiset tiedot ovat hajallaan eri asiakasohjelmissa, palveluissa ja työkaluissa, jotka ovat kehittyneet kunkin pelin ympärille. Keräät tunnisteita ja laitetietoja asiakasohjelmassa, käsittelet niitä peli- ja matchmaking-palvelimilla, siirrät resursseja sisällönjakeluverkkojen kautta ja peilaat kaiken analytiikka- ja havainnointialustoille, joista tunnisteet usein puuttuvat. Pelaajien henkilöllisyydet, maksujäljet ja käyttäytymissignaalit näkyvät asiakasohjelmissa, palvelimilla, tukityökaluissa ja analytiikka-alustoilla, usein pelien ylläpidon sivutuotteina. Jos haluat A.5.13:n toimivan, sinun on tunnistettava nämä sijainnit, päätettävä, mitkä tietotyypit ovat arkaluonteisia, ja varmistettava, että tunnisteet kulkevat niiden mukana.

Monet arkaluontoisimmista artefakteista ovat toiminnan sivutuotteita. Kaatumisvedokset voivat tallentaa muistialueita, joissa on tokeneita tai tunnistetietoja. Virheenkorjauslokit voivat sisältää sähköpostiosoitteita tai chat-katkelmia. Tukikonsolit ja pelinhallintatyökalut paljastavat täydelliset pelaajahistoriat. Lippuihin liitetyt kuvakaappaukset paljastavat käyttäjätunnuksia, killan tunnisteita tai jopa maksuviitteitä. Jos näitä artefakteja ei ole merkitty selkeästi, ne todennäköisesti kopioidaan, jaetaan tai säilytetään paljon pidempään kuin on turvallista.

Jopa tekninen infrastruktuuri pahentaa ongelmaa. Testausympäristöt käyttävät tuotantodataa realismin saavuttamiseksi, mutta niitä ei yleensä lukita yhtä tiukasti. Koonti- ja käyttöönottoputket siirtävät allekirjoitettuja binäärejä, määritystiedostoja ja avaimia. Versioiden hallintasäilöissä viitataan sisäisiin päätepisteisiin, kokeellisiin ominaisuuksiin ja huijauksenesto-logiikkaan. Ilman selkeitä tunnisteita tiimit käsittelevät näitä sijainteja rutiininomaisina putkitöinä eivätkä rajoitettujen tietojen säilöinä.

Miksi merkitsemätön data on todellinen liiketoimintariski

Merkitsemättömästä arkaluonteisesta tiedosta tulee todellinen liiketoimintariski, koska kenelläkään ei ole selkeää ja täytäntöönpanokelpoista näkemystä siitä, mikä tarvitsee vahvempaa suojaa. Kun tiimit eivät voi välittömästi nähdä, että tietyt lokit, kuvakaappaukset tai testiympäristöt sisältävät pelaaja- tai maksutietoja, he tekevät harkitsemattomia päätöksiä niiden kopioimisesta, jakamisesta tai säilyttämisestä. Nämä valinnat heikentävät jatkuvasti teknisiä valvontatoimia ja pelaajille ja kumppaneille antamiasi lupauksia.

Tämä katkos näkyy nopeasti kolmessa paikassa: häiriöissä, auditoinneissa ja laajennussuunnitelmissa. Häiriöissä tutkijat havaitsevat, että nimeämättömät lokit, kuvakaappaukset tai testiympäristöt sisälsivät juuri niitä tietoja, jotka olivat paljastuneet, jolloin pieni määritysvirheestä tuli ilmoitettava tietomurto. Auditoinneissa ISO 27001 -standardin arvioijat pyytävät esimerkkejä siitä, miten luokituksia sovelletaan järjestelmissä, ei vain käytännöissä, ja paljastavat epäjohdonmukaisia tai puuttuvia tunnisteita. Kun haluat siirtyä uusille markkinoille tai allekirjoittaa suurempia alusta- ja maksusopimuksia, kumppanit esittävät teräviä kysymyksiä siitä, missä arkaluonteiset tiedot sijaitsevat ja miten ne on segmentoitu, eivätkä epämääräiset vastaukset sisäisistä tiedoista enää tyydytä.

Kun tunnisteet puuttuvat, käyttöoikeuksien hallinta, säilytyssäännöt ja salausprofiilit lakkaavat toimimasta tarkoitetulla tavalla. Et voi luotettavasti valvoa tiedonsaantiin liittyviä tarpeita tai lyhyempiä säilytysaikoja rajoitetulle tiedolle, jos järjestelmäsi eivät pysty erottamaan rajoitettua tietoa sisäisestä. A.5.13 paikaa tämän aukon muuttamalla luokittelujärjestelmän teoriasta käytännöksi, jotta sekä ihmiset että työkalut näkevät heti, miten tiettyä tietoa tulisi käsitellä.

Varaa demo

Ominaisuuksien toimittamisesta datanhallintaan: Pelistudioiden uusi todellisuus

Nykyaikaisia pelistudioita arvioidaan nykyään sen perusteella, miten ne hallinnoivat pelaaja- ja maksutietoja, ei pelkästään sen perusteella, kuinka nopeasti ne toimittavat ominaisuuksia. ISO 27001 A.5.13 tekee tästä odotuksesta konkreettisen pyytämällä sinua miettimään, miten merkitset arkaluonteisia tietoja eri järjestelmissä, ei pelkästään sen perusteella, miten suunnittelet mekaniikkoja. Jotta A.5.13:a voidaan soveltaa onnistuneesti, sinun on siirryttävä datan käsittelystä ominaisuuskehityksen lopputuotteena siihen, että sitä käsitellään aktiivisesti pelaajien, kumppaneiden ja sääntelyviranomaisten puolesta. Toimitat edelleen nopeasti, mutta teet harkittuja valintoja siitä, mitä keräät, kuinka arkaluonteista se on ja miten tämä arkaluontoisuus viestitään pinossasi ja näkyy jokapäiväisissä työkaluissa.

Tämä muutos ei ole pelkästään vaatimustenmukaisuuteen liittyvä mieltymys. Sovelluskaupat, alustaoperaattorit, mainostajat ja sääntelyviranomaiset odottavat nyt peliyhtiöiltä, miten ne suojaavat henkilö- ja maksutietoja. Studiot, jotka omaksuvat vastuullisen tietosuojan varhaisessa vaiheessa, ovat paremmassa asemassa vastaamaan turvallisuuskyselyihin, suorittamaan due diligence -tarkastuksia ja vakuuttamaan vanhemmat ja sääntelyviranomaiset siitä, miten ne käsittelevät alaikäisten tietoja.

Ulkoiset odotukset ovat muuttuneet

Ulkoiset odotukset pelien turvallisuudesta ja yksityisyydestä ovat tiukentuneet dramaattisesti, ja monet sääntelyviranomaiset käsittelevät nyt yleisiä pelitietotyyppejä henkilötietoina, kun ne voidaan yhdistää yksilöön. Tämä tarkoittaa, että merkintäpäätöksiäsi tarkastelevat yhä enemmän myös studiosi ulkopuoliset ihmiset, eivät vain sisäiset sidosryhmät. Yksinkertainen luokittelutaulukko käytännöissä ei enää riitä; ulkoiset osapuolet haluavat ymmärtää, miten merkintä toimii todellisissa järjestelmissä.

Useat ryhmät tarkastelevat nyt tarkasti, miten käsittelet ja merkitset tietoja:

Sääntelyviranomaiset: – käsitellä tunnisteita, telemetriaa ja chat-tietoja henkilötietoina, kun ne ovat yhdistettävissä yksilöihin.
Alustan omistajat: – kysyä yksityiskohtaisia kysymyksiä tallennuksesta, segmentoinnista ja tapahtumaprosesseista.
Maksupalveluntarjoajat: – keskittyminen kortinhaltijoiden tietoympäristöihin ja niihin liittyviin lokikirjauskäytäntöihin.
Julkaisukumppanit: – haluavat varmuuden siitä, ettei heidän brändiään sidota huonosti käsiteltyyn tietomurtoon.

Yhdessä nämä sidosryhmät muokkaavat sitä, kuinka uskottavalta etikettitarinasi vaikuttaa, kun selität, missä arkaluonteiset tiedot sijaitsevat ja miten niitä hallitaan.

Konsoli- ja mobiilialustat sisällyttävät yhä useammin yksityiskohtaisia turvallisuus- ja yksityisyyskysymyksiä käyttöönottoon ja sertifiointiin. He haluavat tietää, mihin arkaluonteisia tietoja säilytetään, miten ne segmentoidaan ja miten reagoidaan tapauksiin. Maksupalveluntarjoajat keskittyvät kortinhaltijoiden tietoympäristöihin ja lokitietokäytäntöihin. Suuret julkaisukumppanit haluavat varmuuden siitä, että heidän brändiään ei yhdistetä huonosti käsiteltyyn tietomurtoon, joka johtuu merkitsemättömistä lokeista tai vienneistä.

Kun et pysty osoittamaan, minne arkaluontoinen data virtaa ja miten se on merkitty, kaikki sidosryhmät näkevät sinut riskialttiimpana kumppanina. Yksinkertainen ja hyvin toteutettu merkintäjärjestelmä antaa konkreettisen pohjan: ”Näin luokittelemme ja merkitsemme pelaajatiedot, täällä kukin luokka sijaitsee, ja nämä ovat kunkin merkinnän käynnistämät säätimet”.

Mitä vastuullisuus tarkoittaa studiossasi

Studiosi sisäinen datanhallinta tarkoittaa, että suunnittelet ominaisuudet, tapahtumat ja tukiprosessit alusta alkaen arkaluontoisesti. Tiimit miettivät, mitä he keräävät, millä tunnisteella tietoja tulisi suojata ja kuinka kauan niitä todella tarvitsee säilyttää. Tämän lähestymistavan avulla voit tasapainottaa pelattavuuden, kaupalliset tavoitteet ja sääntelyyn liittyvät velvoitteet turvautumatta epävirallisiin arvioihin tai viime hetken siivouksiin.

Käytännössä vastuullisuus tarkoittaa datavirtojen käsittelyä yhtä harkitusti kuin pelin ominaisuuksia. Tuotetiimit pohtivat, mitä dataa uusi mekaniikka kerää, eivätkä vain sitä, kuinka kiinnostavaa se on. Insinöörit suunnittelevat telemetriaa harkiten siitä, ovatko tunnisteet välttämättömiä ja jos ovat, miten tuloksena olevat tapahtumat tulisi merkitä ja suojata eri ympäristöissäsi.

Live-opsit, A/B-testaus ja nopeat sisällönjulkaisut moninkertaistavat tämän vaikutuksen. Kokeiluihin sisältyy usein rikkaampaa dataa, jolla mitataan asiakaspysyvyyttä, rahaksi muuttumista tai oikeudenmukaisuutta. Ilman tunnisteita kokeelliset datajoukot kertyvät jaettuihin tiloihin, joihin analyytikot tai urakoitsijat voivat päästä laajasti käsiksi. Tunnisteilla voit vaatia, että korkean riskin dataa käsittelevässä kokeessa käytetään rajoitettuja testialueita ja anonymisoituja variantteja aina kun mahdollista.

ISMS.onlinen kaltainen alusta voi tukea tätä kulttuurimuutosta pitämällä luokittelu- ja merkintäsääntösi yhdessä paikassa ja linkittämällä ne riskeihin, kontrolleihin ja resursseihin. Tällä tavoin keskustelut siitä, pitäisikö tämän uuden ominaisuuden kerätä tämä kenttä, perustuvat yhteisiin määritelmiin ja näkyvään riskinottohalukkuuteen yksilöllisten harkintojen sijaan. Insinöörit, tietoturva-, vaatimustenmukaisuus- ja tukitiimit työskentelevät kaikki saman käsikirjan pohjalta sen sijaan, että improvisoisivat omia sääntöjään.

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

Mitä ISO 27001 A.5.13 todella vaatii pelaamisessa

ISO 27001 A.5.13 -standardi edellyttää, että käännät korkean tason luokittelujärjestelmäsi käytännönläheisiksi merkintäsäännöiksi, jotka näkyvät todellisissa järjestelmissä ja artefakteissa. Pelien yhteydessä tämä tarkoittaa siirtymistä "luottamuksellinen"-leimaamisesta dokumentteihin ja sellaisten lokien, vientien, kuvakaappausten, tikettien ja tietovirtojen merkitsemistä, jotka sisältävät pelaaja- tai liiketoimintakriittisiä tietoja. Käytännössä valvonta ei niinkään rajoita monimutkaisten uusien nimikkeiden keksimistä ja enemmän sen todistamista, että luokittelu on näkyvissä kaikkialla, missä sillä on merkitystä. Joten kun sanot käsitteleväsi pelaajatietoja luottamuksellisina tai rajoitettuina, voit näyttää esimerkkejä siitä, kuinka kyseinen nimike näkyy työkaluissasi ja vaikuttaa siihen, miten tietoja käsitellään päivittäin.

Ohjaus selkokielellä

Yksinkertaisesti sanottuna A.5.13 edellyttää, että määrittelet luokittelujärjestelmäsi mukaiset tunnisteet, päätät, mihin niitä sovelletaan, määrität vastuut niiden käytöstä ja pidät niiden soveltamisen yhdenmukaisena ajan kuluessa. Pelialalla tämä tarkoittaa abstraktien tasojen muuttamista näkyviksi merkeiksi tiedoissa, joita ihmiset ja työkalut todella koskettavat, aina koontinäytöistä ja tiketeistä vientiin ja arkistoihin.

Koska vakioteksti on lisensoitu, työskentelet sen tarkoituksen etkä sen tarkkojen sanojen perusteella. Yleisesti ottaen A.5.13 edellyttää sinulta neljää asiaa:

Määrittele tunnisteet. Päätä, miten nykyiset luokittelutasosi esitetään todellisissa tietovaroissa.
Päätä, mihin merkinnät soveltuvat. Valitse, mihin tarroja tarvitaan digitaalisesti, fyysisesti ja järjestelmälähtöihin.
Aseta vastuut ja säännöt. Dokumentoi, kuka lisää otsikot, milloin otsikot voivat muuttua ja miten poikkeukset käsitellään.
Pidä etiketit johdonmukaisina. Noudata sääntöjä johdonmukaisesti ja tarkista niitä ympäristösi ja riskien kehittyessä.

Pelaamisessa "tietoresursseihin" kuuluvat peli- ja alustajärjestelmien data, mutta myös artefaktit, kuten toistotiedostot, moderointiviennit, testikoonnukset ja kehitystyön kojelaudat. Sinun ei tarvitse merkitä kaikkea tyhjentävästi, mutta sinun odotetaan perustelevan, missä merkinnät ovat tarpeen, ja osoittavan, että sääntöjäsi sovelletaan kohtuullisen kurinalaisesti.

Mitä tilintarkastajat odottavat pelialan yritykseltä

Pelialan yrityksen A.5.13-kohtaa arvioivat tilintarkastajat etsivät selkeää rajaa kirjallisen politiikan, merkittyjen esineiden ja todellisten kontrollien välillä. He haluavat nähdä, että merkinnät eivät ole vain nimiä sivulla, vaan näkyviä merkkejä, jotka muuttavat järjestelmien toimintaa ja ihmisten tiedonkäsittelyä. Todisteet ovat tärkeämpiä kuin teoria.

Tyypillisesti he odottavat tarkistavansa tiedonluokittelu- ja merkintäkäytännön, joka kuvaa tasojasi, antaa esimerkkejä ja selittää, miten merkintätapaa käytetään sekä digitaaliseen että fyysiseen tietoon. Tämän jälkeen he tarkastelevat järjestelmiä ja artefakteja. Tämä voi tarkoittaa lokitietojen luokittelukenttien tarkastelua lokitietoalustastasi, tietokantojen varmuuskopioiden nimeämiskäytännön tarkistamista tai pelaajatietoja sisältävien sisäisten asiakirjojen ja tikettien merkitsemisen tarkistamista.

Tilintarkastajat haluavat myös ymmärtää, miten tunnisteet ohjaavat suojauksia. Jos tietojoukko on merkitty rajoitetuksi ja sisältää henkilötietoja, he odottavat tiukempaa käyttöoikeuksien hallintaa, salausta, varmuuskopiointisääntöjä ja säilytysaikoja verrattuna sisäiseen telemetriaan, jossa yksilöitä ei voida tunnistaa. Jos tunnisteet ovat olemassa, mutta mikään ei muutu niiden perusteella, valvonta on teknisesti olemassa, mutta käytännössä heikko. Tavoitteenasi on tehdä tunnisteista sekä näkyviä että merkityksellisiä, jotta tilintarkastaja tai sisäinen tarkastaja voi nähdä yhteyden tunnisteiden ja todellisten suojausten välillä.

Pelaajatietojen pelivalmiin merkintäjärjestelmän suunnittelu

Pelivalmis merkintäjärjestelmä käyttää pientä määrää selkeitä tasoja, jotka kaikki muistavat, ja sitten yhdistää yleiset pelitietotyypit näille tasoille johdonmukaisesti. Et tarvitse monimutkaista taksonomiaa täyttääksesi A.5.13-kohdan. Tarvitset kolme tai neljä hyvin määriteltyä merkintää, ilmeisiä esimerkkejä kullekin ja yhteisen ymmärryksen siitä, että merkintää sovelletaan kaikissa peleissä, palveluissa ja työkaluissa, ei vain dokumentaatiossa. Järjestelmä, joka on riittävän yksinkertainen kehittäjille, analyytikoille ja tukihenkilöstölle muistaa, mutta riittävän tarkka heijastamaan eriasteisia haittoja ja sääntelyvelvollisuuksia, palvelee sinua paremmin kuin täydellinen malli, jota kukaan ei käytä, ja säästää sinulta vuosien ad hoc -päätöksiä myöhemmin, koska uudet pelit ja myyjät voivat kytkeytyä samaan ajatusmalliin sen sijaan, että keksisivät omia lippujaan ja käytäntöjään.

Järjestelmä, joka on riittävän yksinkertainen kehittäjien, analyytikoiden ja tukihenkilöstön muistettavaksi, mutta silti riittävän tarkka heijastamaan eriasteisia haittoja ja sääntelyyn liittyviä velvoitteita, palvelee sinua paremmin kuin täydellinen malli, jota kukaan ei käytä. Tämän suunnittelun huolellinen läpikäyminen kerran säästää sinulta vuosien ad hoc -päätösten tekemisen myöhemmin, koska uudet pelit ja myyjät voivat soveltaa samaa ajatusmallia omien lippujensa ja käytäntöjensä keksimisen sijaan.

Tiimien todellisuudessa käyttämien luokittelutasojen valitseminen

Luokittelutasot toimivat vain, jos ihmiset pystyvät pitämään ne mielessään ja soveltamaan niitä epäröimättä. Useimmille studioille riittää neljä tasoa, kuten julkinen, sisäinen, luottamuksellinen ja rajoitettu. Tärkeintä on sopia, mitä kukin taso tarkoittaa pelaajille suunnatun, operatiivisen ja teknisen datan kannalta, ja sitten antaa konkreettisia esimerkkejä, jotka tiimit tunnistavat omista työkaluistaan ja työnkuluistaan.

Saatat päättää, että Julkinen kattaa tiedot, jotka haluat kaikkien näkevän, kuten markkinointisisällön tai julkaistun API-dokumentaation. Sisäinen voi kattaa etenemissuunnitelmat, ei-arkaluonteiset prosessiasiakirjat ja koostetut tilastot, joita ei voida yhdistää yksilöihin. Luottamuksellinen on yleensä se, missä sijaitsee suurin osa pelaajiin liittyvistä tiedoista: tilitiedot, tavanomaiset velvoitteidesi mukaisesti säilytettävät maksutiedot, käyttäjään takaisin yhdistettävissä olevat käyttäytymistelemetriat ja rutiininomaiset sisäiset suorituskykytiedot.

Rajoitettu taso on varattu tiedoille, jotka voisivat aiheuttaa vakavaa haittaa, jos ne paljastuisivat: kortinhaltijan raakatiedot, jos niitä on olemassa, huijauksenestomallit, salausavaimet, julkaisematon sisältö, jolla on merkittävää kaupallista vaikutusta, ja kaikki tietojen yhdistelmät, jotka voisivat aiheuttaa vakavia turvallisuus- tai sääntelyongelmia. Mitä selkeämmin nämä tasot määritellään, sitä helpompaa tiimien on päättää, miten uudet tietojoukot nimetään ilman, että jokaisesta tapauksesta tarvitsee keskustella erikseen.

Tämän järjestelmän teho tulee siitä, että esimerkkien avulla sovitaan, mikä sisältö missäkin sijaitsee. Jos ”alaikäisten keskusteluja sisältävät keskustelulokit” on selvästi dokumentoitu rajoitetuiksi, kenenkään ei tarvitse improvisoida, kun he näkevät tällaista sisältöä tikettityökalussa tai vientinäytössä. He tietävät jo, että siihen liittyy tiukimmat käsittelyvaatimukset, ja he voivat tarkistaa, mitä se tarkoittaa tallennuksen, saatavuuden ja säilytyksen kannalta.

Pelitietotyyppien yhdistäminen tunnisteisiin

Tyypillisten pelitietotyyppien yhdistäminen otsikoihin muuttaa abstraktin kaavion referenssiksi, jota tiimit voivat käyttää suunnitellessaan ominaisuuksia, valitessaan toimittajia tai reagoidessaan ongelmiin. Yleensä riittää ytimekäs taulukko, joka kattaa tärkeimmät kategoriat. Voit tarkentaa asiaa kertovilla esimerkeillä tarvittaessa, mutta itse yhdistämisen tulisi pysyä tiiviinä ja helposti ymmärrettävänä.

Alla on yksi tapa kartoittaa pelaajiin liittyvät ydintiedot:

Tietoluokka	Tyypillinen sisältö	Oletustunniste
Markkinointisivuston sisältö	Trailerit, blogikirjoitukset, päivitystiedotteet	julkinen
Tili- ja henkilöllisyystiedot	Sähköposti, käyttäjätunnus, alustatunnukset, maa	Luottamuksellinen
Maksutiedot (tokenit, historia)	Tokenisoitujen korttien tiedot, ostohistoria, hyvitykset	Luottamuksellinen
Keskustelu- ja äänilokit	Keskustelut, raportit, moderointimuistiinpanot	rajoitettu
Pelin telemetria (linkitetyt käyttäjät)	Istuntotapahtumat, ostot, laitetunnisteet	Luottamuksellinen

Tämä taulukko auttaa tiimejä näkemään yhdellä silmäyksellä, että useimpia pelaajan tunnistavia tietoja ei tule käsitellä pelkästään sisäisenä tietona, vaikka se tuntuisikin rutiininomaiselta päivittäisessä työssä.

Voit käsitellä erityisen korkean riskin luokkia erikseen tarvittaessa:

Tietoluokka	Tyypillinen sisältö	Oletustunniste
Raaka kortinhaltijan tiedot	Ensisijainen tilinumero, voimassaoloaika, CVV (jos sellainen on)	rajoitettu
Huijauksenesto- tai toistoresurssit	Käyttäytymisjäljet, toistotiedostot, tunnistussignaalit	rajoitettu
Avaimet ja turvaesineet	Salausavaimet, allekirjoitusavaimet, salaisuudet	rajoitettu

Tämä toinen taulukko korostaa, mitkä tietotyypit lähes aina ansaitsevat tiukimman käsittelyn, jotta kukaan ei erehdyksessä luokittele niitä tavallisiksi luottamuksellisiksi tiedoiksi.

Standardi ei vaadi tätä kartoitusta; voit räätälöidä sen peliesi ja riskinottohalukkuutesi mukaan. Tärkeintä on sisäinen johdonmukaisuus ja dokumentointi. Kun otat käyttöön uuden analytiikkapalveluntarjoajan tai rakennat uuden moderointityökalun, käytät samaa viitettä päättääksesi, mitä tunnisteita käytät. Alusta, kuten ISMS.online, voi tallentaa tämän kartoituksen riskirekisterisi ja omaisuusluettelosi rinnalle, mikä helpottaa dokumentaation, tunnisteiden ja kontrollien yhdenmukaistamista ajan kuluessa ja osoittaa tilintarkastajille, miten päätöksesi sopivat yhteen.

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

Varaa esittelysi

Tarrojen siirtäminen asiakkaiden, palvelimien, CDN-verkkojen ja analytiikan välillä

Tunnisteet suojaavat sinua vain, jos ne liikkuvat datan mukana sen virratessa arkkitehtuurisi läpi. Hajautetussa peliympäristössä tämä tarkoittaa herkkyysmerkkien siirtämistä asiakastapahtumista taustapalveluiden, jonojen, datajärvien ja kojelaudan kautta. Tunnisteiden määrittäminen paperille on vain puolet työstä; toinen puoli on näiden tunnisteiden kuljettamista datan mukana hajautetun arkkitehtuurin läpi siten, että kun tieto on luokiteltu ja merkitty keräyksen yhteydessä, kyseinen tunniste säilyy tai muuttuu johdonmukaisesti sen kulkiessa asiakkaiden, taustapalveluiden, tapahtumavirtojen, datajärvien ja kojelaudan läpi. Jos upotat tunnisteet jäsenneltyinä metatietoina ja teet niistä osan automaatiotasi, työkalut voivat valvoa käyttöoikeus-, säilytys- ja peittosääntöjä automaattisesti sen sijaan, että luottaisit ihmisten muistavan ne joka kerta.

Jos arkkitehtuurisi on vahvasti automatisoitu, merkintöjen on oltava osa tätä automaatiota eikä niitä saa jättää manuaalisen arvioinnin varaan. Kun merkinnät ovat osa skeemamääritelmiä, konfiguraationhallintaa ja infrastruktuuria koodina, ne voivat vaikuttaa siihen, kuka voi lukea tietovirtaa, kuinka kauan sitä säilytetään ja voidaanko se viedä, ilman että jonkun tarvitsee rastittaa ruutuja käsin joka kerta.

Tarrat ansaitsevat paikkansa, kun työkalut voivat toimia niiden mukaan kysymättä.

Tunnisteiden suunnittelu ensiluokkaisiksi metatiedoksi

Vankin lähestymistapa on käsitellä otsikoita strukturoituina metatietoina, ei ad-hoc-kommentteina. Otsikoiden käsitteleminen strukturoituina metatietoina epävirallisten kommenttien sijaan on luotettavin tapa saada ne pysymään. Voit lisätä kenttiä, kuten classification, contains_personal_data, contains_payment_data or child_data_possible tapahtuma- ja lokikaavioihisi. Asiakaspuolella, kun lähetät tapahtuman, asetat nämä kentät lähettämäsi tapahtuman tyypin perusteella. Palvelinpuolella palvelut ja suoratoistoprosessorit lukevat ja säilyttävät nämä kentät sen sijaan, että ne poistettaisiin, mikä mahdollistaa alavirran työkalujen ymmärtää arkaluontoisuuden arvailematta ja helpottaa huomattavasti korkean riskin säilöjen etsimistä ja johdonmukaisen valvonnan soveltamista, kun muutat käytäntöä tai reagoit tapahtumaan.

API-rajapinnoissa voit tallentaa otsikoita otsikoissa tai strukturoiduissa kirjekuorissa, jotka käärivät hyötykuormat. Tietokannoissa ja datajärvissä voit tallentaa otsikoita taulukko- tai saraketason metatietoina tai tunnisteina luettelossasi. Viestijonoissa voit käyttää attribuutteja tai otsikoita arkaluontoisuuden seuraamiseen. Olennaista on, että näiden kenttien olemassaolo ja merkitys on standardoitu koko pinossa, joten insinöörien ei tarvitse keksiä niitä uudelleen jokaista järjestelmää varten.

Tällä lähestymistavalla on kolme selkeää etua. Se tarjoaa yhden totuuden lähteen arkaluontoisuudesta, jota analytiikka- ja havainnointityökalut voivat käyttää pääsyn suodattamiseen. Se helpottaa "kaikkien rajoitettua tietoa sisältävien säilöjen" etsimistä riskinarviointeja tai tietoturvaloukkauksiin reagointia suoritettaessa. Se mahdollistaa myös valvonnan määrittämisen – kuten viennin estämisen tai tiukemman salauksen valvomisen – tunnisteiden perusteella yksittäisen järjestelmän kiinteän koodauksen sijaan.

Etenemisen ja tarkistusten automatisointi putkistoissa

Kun tunnisteet ovat metatietoja, voit kutoa ne prosessinosi, jotta uuden koodin ja skeemien on noudatettava niitä. Automaattiset tarkistukset koonti- ja tallennusvaiheessa ovat paljon luotettavampia kuin kehittäjien pyytäminen muistamaan tunnistesäännöt määräaikojen paineessa, ja ne antavat sinulle varhaisen varoituksen, jos jokin asia lipsahtaa läpi ennen kuin se leviää laajalle.

Skeemarekisterisi voi esimerkiksi hylätä kaikki uudet tapahtumatyypit, jotka eivät määritä luokitusta. Jatkuvan integraation prosessisi voi merkitä muutoksia, jotka lisäävät uusia tunnisteita sisältäviä kenttiä, mutta unohtavat päivittää herkkyysmerkinnät. Tietoalustasi voi käyttää luokittelukenttiin perustuvia oletusarvoisia säilytys- ja peittosääntöjä, joten "rajoitetut" tietojoukot saavat automaattisesti tiukemman käsittelyn kuin sisäinen telemetria.

Valvonta ja laaduntarkastukset ovat aivan yhtä tärkeitä. Ajoitetut työt voivat skannata lokeja, objektisäilöjä ja luettelomerkintöjä nimeämättömien tietojoukkojen tai ilmoitettujen tunnisteiden ja havaitun sisällön välisten ristiriitojen varalta. Jos oletettavasti anonymisoitu tietojoukko sisältää edelleen selkeitä tunnisteita, se tulisi merkitä tarkistettavaksi. Kun uusi mikropalvelu alkaa lähettää tapahtumia ilman luokittelumetatietoja, hälytysten tulisi käynnistyä ennen kuin kyseinen kaava juurtuu.

Myös latenssi- ja suorituskykyyn liittyvät huolenaiheet vaativat huomiota. Et halua raskasta merkintälogiikkaa kehysten renderöinnin tai verkkokoodin nopeaan etenemiseen. Sen sijaan useimmat luokittelupäätökset kannattaa siirtää konfigurointiin, koontiaikaan tai tiedonkeruuputkiin. Kevyet metatietokentät ja otsikot lisäävät merkityksettömästi lisäkustannuksia verrattuna hyötykuormien kokoon ja salaukseen, varsinkin kun ne on suunniteltu huolellisesti. Hyödynnä järjestelmä, jossa herkkyys seuraa tietoja automaattisesti, ja valvontaa voidaan säätää ilman sovelluskoodin jatkuvaa muuttamista tai manuaalisten puhdistussprinttien varaamista.

ISO-merkintöjen yhdenmukaistaminen GDPR:n ja PCI DSS:n kanssa pelaajatietojen osalta

Yhtenäinen merkintäjärjestelmä voi tukea ISO 27001 -standardia ja samalla helpottaa GDPR:n ja PCI DSS:n hallintaa pelidatan osalta. Jos käsittelet turvallisuusluokitusta selkärankana ja lisäät sitten yksityisyys- ja maksunäkökohdat, vältät kolmen erillisen järjestelmän käyttämisen, jotka hämmentävät tiimejä. Sen sijaan käytät yhtä sanastoa ja pieniä lippusarjoja kuvaamaan oikeudellisia ominaisuuksia, kuten henkilötietoja tai kortinhaltijatietoja. Tämä yhdenmukaistaminen vähentää päällekkäisyyksiä ja väärinkäsityksiä, koska yhden turvallisuus-, yksityisyys- ja maksujärjestelmän sijaan ylläpidät yhtenäistä sanastoa ja käytät tunnisteita tai attribuutteja ilmaisemaan, onko tieto henkilötietoa, erityistietoluokkaa, kortinhaltijatietoja vai soveltamisalan ulkopuolella olevaa tietoa. Näin laki-, turvallisuus- ja maksutiimit puhuvat kaikki samoista tietojoukoista keskustellessaan riskeistä ja velvoitteista.

Tämä yhdenmukaistaminen vähentää päällekkäisyyksiä ja väärinkäsityksiä. Sen sijaan, että ylläpidettäisiin yhtä järjestelmää tietoturvalle, toista yksityisyydelle ja toista maksuille, ylläpidetään yhtenäistä sanastoa ja käytetään tunnisteita tai attribuutteja ilmaisemaan, onko jokin tieto henkilötietoa, erityistietoluokkaa, kortinhaltijan tietoa vai soveltamisalan ulkopuolella olevaa tietoa. Tällä tavoin laki-, turvallisuus- ja maksutiimisi puhuvat samoista tietojoukoista keskustellessaan riskeistä ja velvoitteista.

GDPR:n tukeminen etiketeillä

GDPR ei käske käyttämään tunnisteita, mutta se edellyttää, että tiedät, mitkä tiedot ovat henkilökohtaisia, mitkä erityisen arkaluonteisia, missä tapahtuu korkean riskin käsittelyä ja miten suojaat niitä. GDPR edellyttää, että tiedät, mitkä tiedot ovat henkilökohtaisia, mitkä korkean riskin ja miten suojaat niitä koko niiden elinkaaren ajan. Tunnisteiden avulla voit koodata tiedot suoraan järjestelmiin merkitsemällä, missä henkilötiedot ja erityisluokkien tiedot sijaitsevat, mikä helpottaa käyttöoikeus-, säilytys- ja oikeuksien suojausprosessien yhdenmukaistamista lakisääteisten velvoitteidesi kanssa sen sijaan, että luotettaisiin sovelluskohtaisiin oletuksiin tai muistiin.

Kun tietojoukko on merkitty henkilötietoja sisältäväksi, käyttöoikeuskäytäntösi, salauksesi, lokinnuksen, säilytyksen ja rekisteröidyn pääsyprosessit voidaan kaikki määrittää vastaavasti. Voit mennä pidemmälle lisäämällä merkintöjä erityisille tietoluokille (harvinaisissa tapauksissa, joissa näitä esiintyy peleissä, kuten terveystiedot tietyissä nimikkeissä), lapsia koskeville tiedoille tai profilointiin käytetyille tiedoille. Näin tietosuojavastaavasi voi osoittaa, että tällaisia tietoja käsitellään erityisen huolellisesti, esimerkiksi rajoittamalla sitä, mitkä tiimit voivat käyttää tietoja, vaatimalla vahvempia perusteluja viennille tai lyhentämällä säilytysaikoja.

Nämä tunnisteet tekevät myös käsittelytoimien tiedoistasi luotettavampia. Kun järjestelmän omistajat linkittävät tietueen tietovarastot tiettyihin luokittelutasoihin ja tietosuojamerkintöihin, sinulla on reaaliaikainen kartta siitä, missä arkaluonteiset henkilötiedot sijaitsevat ja miten niitä käsitellään. Rekisteröidyn tiedonsaantipyynnön tai viranomaistarkastuksen aikana voit hakea näitä tunnisteita sen sijaan, että luottaisit pelkästään epäviralliseen tietoon ympäristöstä tai hauraasta muistista.

PCI DSS:n ja maksuvaatimusten tukeminen

PCI DSS keskittyy kortinhaltijatietoihin, tokeneihin ja kaikkiin ympäristöihin, jotka tallentavat, käsittelevät tai välittävät niitä. Selkeät tunnisteet auttavat ylläpitämään soveltamisalan rajoja erottamalla raakat korttitiedot, tokenisoidut tietueet ja maksuihin liittyvät lokit. Tämä selkeys vähentää mahdollisuutta, että unohtunut lokivirta tai varmuuskopio kulkeutuu huomaamattomasti kortinhaltijatietojen ympäristöön ja tuo mukanaan odottamattomia tarkastus- ja valvontavelvoitteita.

Vaikka luottaisitkin pitkälti kolmannen osapuolen maksupalveluntarjoajiin, saatat silti käsitellä tokeneita, osittaisia korttitietoja tai lokeja, jotka viittaavat tapahtumiin. Jos käsittelet kortinhaltijatietoja suoraan, velvollisuutesi ja tarkastustaakkasi kasvavat merkittävästi. Yhtenäinen merkintäjärjestelmä auttaa sinua seuraamaan näitä rajoja pakottamatta tiimejä opetelemaan PCI-terminologiaa ulkoa.

Voit esimerkiksi päättää, että mikä tahansa taulukko, lokitietovirta tai tiedosto, joka sisältää ensisijaisia tilinumeroita tai niiden täydellisiä PAN-vastineita, luokitellaan rajoitetuksi ja sillä on tunniste contains_cardholder_data lippu. Kootut tai tokenisoidut tietueet, jotka eivät sisällä raakatietoja, saattavat pysyä luottamuksellisina, mutta niillä voi olla erillinen merkintä, joka osoittaa, että ne liittyvät maksuihin, mutta ovat tiukan PCI-soveltamisalan ulkopuolella.

Tämä erottelu helpottaa PCI-laajuuden määrittelyä ja ylläpitoa tavalla, jonka kaikki ymmärtävät sekä turvallisuus-, rahoitus- että suunnitteluosastot. Kortinhaltijatietoja käsitteleviksi merkityistä järjestelmistä tulee osa kortinhaltijatietojen ympäristöä, ja niiden on täytettävä kaikki PCI-vaatimukset. Järjestelmät, jotka käsittelevät vain tokenisoitua tai aggregoitua dataa, voidaan pitää laajuuden ulkopuolella, kunhan ne on eroteltu asianmukaisesti. Kun dokumentoit tämän tietoturvanhallintajärjestelmässäsi ja arkkitehtuurikaavioissasi, voit osoittaa sekä ISO 27001 -auditoijille että PCI-arvioijille, kuinka luokittelu ja merkitseminen tukevat segmentointimenetelmääsi ja vähentävät tarpeetonta altistumista.

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

Varaa esittelysi

Merkintöjen käyttöönotto: Hallinto, työnkulut ja työkalut

A.5.13:n käyttöönotto tarkoittaa merkinnöille selkeiden omistajien antamista, niiden upottamista jokapäiväisiin työnkulkuihin ja niiden toimivuuden mittaamista. Haluat kehittäjien, analyytikoiden, tukihenkilöstön ja tietoturvatiimien näkevän merkinnät osana normaalia käytäntöä, ei erillisenä vaatimustenmukaisuusharjoituksena. Paraskin merkintöjen suunnittelu- ja metatietostrategia epäonnistuu, jos kukaan ei omista niitä tai jos ne pysyvät irrallaan päivittäisestä työstä. Siksi A.5.13:n käyttöönotto tarkoittaa myös selkeiden vastuiden osoittamista, merkintöjen integrointia kehitys- ja operatiivisiin prosesseihin, ihmisten kouluttamista niiden käyttöön ja tehokkuuden seurantaa ajan kuluessa suunnittelu-, operatiivisissa, tuki-, tietoturva- ja vaatimustenmukaisuustiimeissä. Kun vastuut, prosessit ja työkalut on yhdenmukaistettu, voit osoittaa auditoijille ja kumppaneille, että merkinnät ovat elävä järjestelmä eikä staattinen asiakirja.

Tavoitteena on päästä pisteeseen, jossa luokittelu ja merkitseminen ovat yksinkertaisesti osa pelien rakentamista ja pelaamista, eivätkä rinnakkainen vaatimustenmukaisuuden varmistaminen. Kun kehittäjät, analyytikot ja tukihenkilöstö näkevät johdonmukaisesti merkinnät työkaluissaan, ymmärtävät niiden merkityksen ja tietävät, miten niiden perusteella toimia, olet siirtynyt käytännöistä käytäntöihin ja auditointitodisteiden tuottaminen helpottuu huomattavasti.

Hallinto ja omistajuus

Vahva hallintotapa tekee selväksi, kuka asettaa tunnisteiden määritelmät, kuka soveltaa niitä ja kuka tarkistaa, että ne toimivat edelleen pelien kehittyessä. Yleensä tietoturvajohtaja tai CISO vastaa käytännöistä, tietosuojavastaava muokkaa kaikkea henkilötietoihin liittyvää, ja peli-, alusta- ja tukitiimit soveltavat tunnisteita omilla toimialoillaan. Sisäinen tarkastus tai riskienhallintatiimit kyseenalaistavat ja testaavat kokonaiskuvaa, jotta se ei poikkea.

Hallinto alkaa siitä, että päätetään kuka johtaa ja kuka osallistuu. Yleensä tietoturvajohtaja tai CISO vastaa luokittelu- ja merkintäkäytännöistä. Tietosuojavastaavalla on vahva sananvalta aina, kun kyse on henkilötiedoista. Alusta- ja pelitiimit vastaavat merkintäjen lisäämisestä palveluihinsa ja työnkulkuihinsa. Tuki- ja moderointitiimit käsittelevät merkittyjä vientitietoja ja eskaloituja tapauksia. Sisäisen tarkastuksen tai riskienhallinnan tiimit voivat valvoa kattavuutta ja tehokkuutta sekä haastaa heikkoja kohtia.

Voit tiivistää pääroolit seuraavasti:

Turvallisuusjohtajuus: – omistaa järjestelmän ja kokonaisriskinottohalukkuuden.
Tietosuojavastaava: – neuvoo henkilötietojen ja riskialttiiden tietojen käsittelyssä.
Peli- ja alustatiimit: – toteuta tunnisteet koodissa ja työkaluissa.
Tuki ja moderointi: – käsitellä merkittyjä vientitapauksia ja eskaloituja tapauksia.
Sisäinen tarkastus tai riski: – testaa kattavuutta ja haastaa heikkoja kohtia.

Yksinkertainen RACI-matriisi (vastuullinen, tilivelvollinen, konsultoitu, tietoon perustuva) merkintäpäätöksille, käytäntömuutoksille ja poikkeuksille pitää tämän selkeänä. Esimerkiksi alustasuunnittelu voi olla vastuussa luokittelukenttien noudattamisen valvomisesta skeemoissa, kun taas tietoturva pysyy vastuussa koko järjestelmästä. Pelitiimit voivat olla vastuussa telemetriavirtojensa oikeasta merkitsemisestä, merkintämääritelmien konsultoinnista ja käytäntömuutoksista tiedottamisesta. Tukijohto voi olla vastuussa vientien käsittelystä ja sen varmistamisesta, että rajoitettuja artefakteja ei jaeta sattumanvaraisesti.

Työkaluvalintojen tulisi heijastaa tätä hallintaa. ISMS.onlinen kaltainen alusta voi toimia keskeisenä paikkana, jossa käytännöt, nimikkeiden määritelmät, resurssit, riskit ja kontrollit sidotaan yhteen. Kun joku ehdottaa muutosta – kuten uuden nimikkeen käyttöönottoa erityisen arkaluontoiselle pelimekaniikalle – voit tallentaa perustelut, hyväksynnät ja niistä johtuvat päivitykset yhteen auditoitavaan polkuun sen sijaan, että hajauttaisit päätökset keskusteluihin ja wikeihin.

Tarrojen upottaminen työnkulkuihin, koulutukseen ja mittaukseen

Tunnisteiden upottaminen työnkulkuihin tarkoittaa, että luokittelusta kysytään aina, kun uutta dataa luodaan, muutetaan tai julkaistaan, ei vain vuosittaisten tarkistusten yhteydessä. Tarkistuslistojen, mallien ja koulutusmateriaalien tulisi tehdä tunnistepäätöksistä luonnollinen osa suunnittelua, koodin tarkistusta ja julkaisua, jotta tiimien ei tarvitse muistaa sääntöjä alusta alkaen joka kerta tai odottaa asiantuntijan puuttumista asiaan.

Skeematarkistuksen tarkistuslistojen tulisi sisältää kysymyksiä luokittelusta ja yksityisyysmerkinnöistä. Koodin tarkistusmallit voivat muistuttaa kehittäjiä miettimään, lisääkö uusi lokirivi tai tapahtuma tunnisteita, ja asettamaan asianmukaiset tunnisteet. Julkaisunhallintaprosessit voivat edellyttää vahvistusta siitä, että uudet tietovarastot on luokiteltu ja merkitty ennen julkaisua, erityisesti testiympäristöissä, jotka muuten saattaisivat jäädä huomaamatta.

Ihmiset tarvitsevat myös rooliinsa räätälöityä koulutusta. Insinöörien ja analyytikoiden on ymmärrettävä, miten tunnisteita tulkitaan ja käytetään tietovarastoissa, prosessiputkissa ja koontinäytöissä. Tuki- ja moderointitiimit tarvitsevat käytännön ohjausta rajoitettujen vientien käsittelyyn, siihen, missä heidän on sallittua tai kiellettyä jakaa niitä, ja miten epätavallista sisältöä, kuten epäiltyjä erityiskategorian tietoja, voidaan siirtää eteenpäin. Tuote- ja live-ops-päälliköiden tulisi tietää, miten tunnisteet vaikuttavat kokeilujen suunnitteluun, A/B-julkaisuihin ja säilytyspäätöksiin, jotta he eivät vahingossa luo tunnisteettomia ja riskialttiita tietojoukkoja.

Lopuksi, käsittele merkintöjä mittauksena. Hyödyllisiä indikaattoreita ovat tunnettujen tietovarastojen osuus, joihin on käytetty merkintöjä, luvattomien vientien tai virheellisten merkintöjen määrä, korkean riskin luokkien, kuten keskustelulokien tai huijauksenestotietojen, kattavuus sekä poikkeusten trendit. Sisäisissä auditoinneissa ja tapahtumien jälkitarkastuksissa tulisi tarkistaa, olivatko merkinnät käytössä ja auttoivatko vai estivätkö ne reagointia. Näitä tietoja käytetään käytäntöjen päivityksissä, koulutuksessa ja tarvittaessa työkalujen muutoksissa, jotta merkintöjen käytäntösi paranee jokaisen syklin myötä sen sijaan, että se ajautuisi pois tolaltaan.

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

ISMS.online auttaa sinua muuttamaan ISO 27001 A.5.13 -standardin käytännölliseksi ja auditoitavaksi merkintäjärjestelmäksi koko pelipinossasi, jotta voit suojata pelaajia, tyydyttää auditoijien vaatimukset ja pitää etenemissuunnitelmasi liikkeessä. Keskittämällä luokittelujärjestelmäsi, merkintäsäännöt, resurssit, riskit ja kontrollit saat yhden ja yhtenäisen näkymän, jonka voit jakaa luottavaisin mielin insinöörien, auditoijien, kumppaneiden ja alustan omistajien kanssa. Demo on tilaisuutesi nähdä, miten nämä ideat soveltuvat tiettyihin peleihisi, tuotantoputkeesi ja työkaluihisi sen sijaan, että A.5.13-standardia pidettäisiin abstraktina ohjeistuksena. Voit siis tutkia, miten luokittelu, merkintä ja kontrollit yhdistyvät yhdessä paikassa ja päättää, vähentäisikö tämä lähestymistapa tiimeillesi aiheutuvaa kitkaa.

Miltä keskittynyt lentäjä voi näyttää

Kohdennettu pilotti osoittaa, miten nimeäminen todella toimii yhden pelin tai työnkulun kohdalla ennen sen skaalaamista. Rajaamalla toiminnan tiettyyn peliin, prosessiin tai työkalupakkiin voit nopeasti todistaa parempien nimeämisten arvon, löytää aukkoja turvallisesti ja rakentaa malleja, joita muut tiimit voivat kopioida. Tämä lähestymistapa antaa sinulle auditointivalmiita todisteita pysäyttämättä kehitystä koko portfoliossasi.

Hyvä tapa aloittaa on kapea, arvokasta pilottihanketta: esimerkiksi yhden lippulaivapelin pelaajadatan prosessi tai tietty työnkulku, kuten maksut tai tukityökalut. Kartoitetaan tärkeimmät tietovarastot ja -virrat, päätetään, mitä luokittelutasoja ja tietosuoja- tai maksumerkintöjä käytetään, ja määritetään nämä tunnisteet ISMS.online-ympäristössä asiaankuuluvien riskien ja kontrollien ohella, jotta kaikki näkevät saman kuvan.

Sieltä voit tallentaa konkreettisia esimerkkejä: miten tietty lokitietovirta on merkitty ja mitkä tiimit voivat käyttää sitä; miten chat-vienti merkitään rajoitetuksi ja linkitetään tiukempaan säilytykseen; miten telemetriaa ja tunnisteita yhdistävä data Lake -taulukko luokitellaan ja hallitaan. Linkität myös proseduurit, koulutustietueet ja valvontaraportit näihin artefakteihin, jotta kun tilintarkastaja tai kumppani kysyy, miten sovellat A.5.13:a, voit näyttää heille tiettyjä esimerkkejä yleistysten sijaan.

Tällainen pilottihanke ei vaadi jokaisen järjestelmän muuttamista yhdessä yössä. Sen sijaan se antaa realistisen kuvan siitä, miltä tehokas merkintä näyttää omassa ympäristössäsi, korostaa puutteita ja osoittaa arvoa johdolle. Se muuttaa abstraktin ohjeistuksen erityisiksi malleiksi, joita tiimisi voivat kopioida muihin peleihin ja palveluihin, ja antaa tietoturva- ja vaatimustenmukaisuustiimeille todisteita siitä, että merkintä on todellakin ohjauksen lähde.

Miten demo muunnetaan auditoitavaksi evidenssiksi

Demo näyttää, miten ISMS.online yhdistää A.5.13:n muuhun tietoturvallisuuden hallintajärjestelmääsi aina käytännöistä omaisuustietoihin, riskeihin, kontrolleihin ja sisäisiin tarkastuksiin. Voit seurata tunnistetta sen määritelmästä sen merkitsemiin omaisuuseriin, sen lieventämiin riskeihin sekä sitä tukeviin menettelyihin ja koulutukseen. Tämä näkyvyys helpottaa huomattavasti lähestymistapasi selittämistä tilintarkastajille, alustojen omistajille ja julkaisukumppaneille.

Demossa näet, miten luokittelu ja merkintä liittyvät laajempaan ISO 27001 -standardiisi ISMS.online-sivustolla. Voit käydä läpi, miten rajoitetun käytön määritelmän käytäntömuutos ottaa huomioon omaisuusrekistereissä, riskinarvioinneissa ja kontrolleissa. Voit nähdä, miten A.5.13:n sisäinen tarkastus ottaa näytteitä merkittyistä esineistä ja kirjaa havaintonsa. Voit tutkia, miten GDPR- ja PCI DSS -velvoitteesi liittyvät samoihin merkittyihin omaisuuseriin, välttäen päällekkäisyyksiä ja sekaannusta.

Mikä tärkeintä, voit arvioida, miltä tämä tuntuisi tiimeistäsi. Insinöörit, tietoturvahenkilöstö ja vaatimustenmukaisuudesta vastaavat kollegat saavat yhteisen tiedonlähteen rinnakkaisten laskentataulukoiden sijaan. Pelitiimit näkevät yhdellä silmäyksellä, mitkä heidän järjestelmistään käsittelevät rajoitettua dataa ja mitä se tarkoittaa. Tuki- ja live-ops-tiimit saavat selkeämmät ohjeet siitä, milloin he voivat viedä dataa ja milloin heidän on eskaloitava se.

Jos haluat suojata pelaajiesi tietoja, tyydyttää sääntelyviranomaisten ja kumppaneiden vaatimukset ja pitää studiosi liikkeessä nopeasti, selkeään ja johdonmukaiseen A.5.13-merkintään investoiminen on yksi tehokkaimmista toimenpiteistä, joita voit tehdä. Demon varaaminen ISMS.online-sivustolta on yksinkertainen tapa selvittää, miten tämä askel voidaan toteuttaa konkreettisesti peleihisi, arkkitehtuuriisi ja tiimeihisi.

Varaa demo

Usein Kysytyt Kysymykset

Viestisi ”kritiikki”-osio on jo tiivistetty versio luonnoksesta, ja se on erittäin vahva: selkeä, kuulijaystävällinen ja studioiden käyttökelpoinen. Ennen julkaisua on vain muutama pieni ongelma, jotka kannattaa korjata.

Tässä on kevyesti viimeistelty, julkaisuvalmis versio, johon on tehty mikromuokkauksia selkeyden, kieliopin ja johdonmukaisuuden takaamiseksi. Olen säilyttänyt rakenteen ja tyylin ennallaan.

Miten peliyhtiön tulisi tulkita ISO 27001 A.5.13 -standardia päivittäisessä käytännössä?

ISO 27001 A.5.13 -standardi edellyttää, että tiedonluokittelu on näkyvää ja käytettävissä olevaa päivittäisessä työssä, eikä sitä vain kuvata käytäntöasiakirjassa. Pelialan yritykselle tämä tarkoittaa, että "luottamuksellinen" ja "rajoitettu" -luokitukset eivät voi sijaita vain laskentataulukossa; niiden on oltava näkyvissä resursseissa, joita tiimisi käsittelevät päivittäin: lokeissa, vienneissä, kuvakaappauksissa, kaatumisvedoksissa, tietokannoissa, tiketeissä ja analytiikkanäkymissä.

Käytännössä tavoitteena on kolme lopputulosta. Ensinnäkin kaikki voivat tunnistaa pienen joukon luokittelutasoja ja soveltaa niitä johdonmukaisesti todellisiin artefakteihin koko pelipinossasi. Toiseksi nämä tunnisteet näkyvät työkaluissa ja työnkuluissa: rakennusputkista ja hallintakonsoleista datajärviin ja tukialustoihin. Kolmanneksi tunnisteet itse asiassa ohjaavat toimintaa: käyttöoikeudet, säilytys, peittäminen ja vientisäännöt ovat kaikki linjassa käytäntöjesi kanssa.

Tilintarkastaja lukee luokittelukäytäntösi, avaa sitten oikeita järjestelmiä ja kysyy: "Vastaako tämä?". Jos chat on määritelty rajoitetuksi, he odottavat näkevänsä sen heijastuvan skeemoissa, tallennuspaikoissa, tukityökaluissa ja käyttöoikeuksien hallinnassa. Tietoturvallisuuden hallintajärjestelmä (ISMS), kuten ISMS.online, auttaa sitomalla yhteen käytännöt, omaisuusluettelon, tunnisteet ja auditointitodisteet, jotta voit osoittaa, että A.5.13 on voimassa myös toiminnassa, ei vain dokumentaatiossa.

Miltä "riittävän hyvä" näyttää useimmille studioille?

Realistisella toteutuksella on neljä elementtiä:

Yksinkertaiset tasot: jotka mahtuvat yhdelle sivulle ja ovat helppoja muistaa.
Kattavuussäännöt: jotka määrittävät, mitkä pinon osat on merkittävä (pelaajatiedot, maksut, chat, telemetria, koontiversiot, lokit, varmuuskopiot).
Selkeä omistajuus: kuka merkitsee mitä, kuka hyväksyy poikkeukset ja kuka tarkistaa kattavuuden.
Todisteet: että tunnisteita käytetään käyttöoikeuksien hallintaan, säilytykseen ja peittämiseen liittyvissä päätöksissä, eikä niitä liimata vain muutamaan tiedostoon.

Jos pystyt viemään tilintarkastajan käytännön tekstistä esimerkkiin toimivassa järjestelmässä alle minuutissa, olet oikeilla jäljillä.

Miten voimme suunnitella pelaajatietojen merkintäjärjestelmän, jota joukkueet todella käyttävät?

Merkintäjärjestelmä toimii, kun ihmiset muistavat sen ja osaavat soveltaa sitä alle minuutissa. Pelaajatietojen osalta tämä tarkoittaa yleensä neljä tasoa konkreettisin esimerkein sen sijaan, että se olisi fiksu taksonomia, jonka vain kaksi ihmistä ymmärtää.

Yleinen kaava pelaamisessa on:

Julkinen: – sisältöä, jonka olet valmis näyttämään kaikille: markkinointisivut, korjaustiedot, julkiset API-dokumentit.
Sisäinen: – vain sisäiseen käyttöön tarkoitettua tietoa, jolla ei ole suoraa arkaluonteisuutta toimijoille: sisäiset suorituskykyindikaattorit, etenemissuunnitelmat, suunnittelumuistiinpanot.
Salassa pidettävä: – useimmat pelaajaan liittyvät tiedot: tilit, ostohistoria, linkitetty telemetria, normaali tukihistoria.
rajoitettu: – tiedot, jotka voivat aiheuttaa vakavaa vahinkoa, jos niitä käsitellään väärin: kortinhaltijan raakatiedot, alaikäisten keskustelulokit, huijauksenestomallit, salausavaimet, julkaisemattoman sisällön pudotukset, syvätutkintaviennit.

Sieltä luot lyhyen kartoituksen yleisille luokille:

Tilit ja tunnukset (sähköpostiosoite, käyttäjätunnus, alustatunnus) → Luottamuksellinen
Maksutokenit ja ostohistoria → Luottamuksellinen
Raa'at korttinumerot tai täydellinen PAN → rajoitettu
Keskustelu-/äänilokeissa on todennäköisesti alaikäisiä → rajoitettu
Käyttäytymiseen liittyvä telemetria linkitetty tileihin → Luottamuksellinen
Huijausjäljitykset tai yksityiskohtaiset uusinnat tutkimuksia varten → rajoitettu

Tämän kartoituksen tulisi olla osa ISMS- ja A.5.13-dokumentaatiotasi, mutta sen on myös oltava siellä, missä työtä tehdään: skeemamallit, suunnitteluwikit, tukikäsikirjat ja data-alustastandardit. Alustat, kuten ISMS.online, auttavat antamalla sinun pitää yllä yhtä auktoritatiivista luokittelutaulukkoa ja linkittää sen resursseihin, riskeihin ja kontrolleihin, jotta muutokset sujuvat johdonmukaisesti.

Miten pidämme järjestelmän käyttökelpoisena pelien, alueiden ja myyjien muuttuessa?

Käytettävyys riippuu esimerkeistä ja suojakaiteista:

Antaa yksi tai kaksi konkreettista esimerkkiä jokaisesta tasosta nykyisistä nimikkeistäsi ja työkaluistasi.
Määrittele, mitä tapahtuu, kun tietojoukko ei täysin sovi (esimerkiksi tutkimusviennit tai esports-tutkimukset), mukaan lukien kuka voi hyväksyä kertaluonteisen päätöksen ja miten se kirjataan.
Aseta odotuksia, jotka uudet skeemat, taulukot ja työkalut on luokiteltava ennen tuotantokäyttöä ja tee siitä tarkistuslistakohta muutosprosessissasi.

Jos uusi insinööri pystyy luokittelemaan uuden taulukon tai lokityypin oikein yhden sivun oppaan avulla alle 60 sekunnissa, järjestelmäsi toimii.

Miten voimme teknisesti toteuttaa otsikot niin, että ne seuraavat dataa pelipinon läpi?

Otsikot ovat tehokkaimpia, kun ne kulkeutuvat datan mukana yksinkertaisina metatietoina sen sijaan, että ne eläisivät jonkun muistissa tai erillisessä laskentataulukossa. Nykyaikaisessa peliohjelmistossa tämä tarkoittaa yleensä pienen joukon kenttiä, tunnisteita tai otsikoita lisäämistä, jotka jokainen järjestelmä voi lukea ja säilyttää.

On tapahtuma- ja lokikirjauspuolivoit lisätä kenttiä, kuten classification, contains_personal_data, contains_payment_data ja child_data_possible skeemoihisi. Pelien asiakasohjelmat ja palvelut asettavat nämä kentät tapahtumia lähettäessään. Jonot, suoratoistoprosessorit ja datajärvet säilyttävät ne, jotta alavirran työkalut – kojelaudat, hälytykset, koneoppimisputket – voivat tehdä päätöksiä selkeiden herkkyyssignaalien perusteella.

In tietokannat ja objektivarastot, luokittelu voi olla taulukko- tai saraketason metatietoa. Esimerkiksi keskustelun transkriptiotaulukossa voi olla tunnisteita classification=Restricted, contains_personal_data=true, child_data_possible=true. sisään viestijonot, otsikot voivat olla attribuutteja tai otsikoita; tiedostot ja viennit, ne voidaan koodata tiedostonimiin, tallennuspolkuihin ja niihin liittyviin tiketteihin.

Kun tarrat ovat paikoillaan, voit kytkeä ne automaatioon:

Skeemarekisterit voivat hylätä uudet skeemat, joista puuttuu pakollisia luokittelukenttiä.
CI-putkistot voivat merkitä koodia, joka lisää tunnisteita päivittämättä herkkyyslippuja.
Tietoalustat voivat käyttää luokitteluun perustuvia oletusarvoisia peitto-, salaus- ja säilytyssääntöjä.
Aikataulutetut tarkastukset voivat etsiä merkitsemättömiä myymälöitä tai merkitsemis-/sisältöristiriitoja ja tehdä tukipyyntöjä.

Suurin osa tästä toimii konfiguraation ja prosessin rajoilla, ei kuumien pelisilmukoiden sisällä, joten suorituskykyyn kohdistuva vaikutus pysyy merkityksettömänä. Rakenteinen tietoturvan hallintajärjestelmä, kuten ISMS.online, helpottaa teknisen toteutuksen pitämistä linjassa dokumentoidun käytäntösi kanssa ja tämän linjan todistamista auditointien aikana.

Miten päätämme, missä metadata on pakollista ja kuinka tiukkaa automaation tulisi olla?

Yksinkertainen lähestymistapa on:

Ilmoita a vähimmäismetatietojoukko kaikille järjestelmille, jotka tallentavat tai käsittelevät pelaajaan liittyviä tietoja (luokittelu + henkilötietojen merkintä lähtökohtana).
Tee nuo kentät pakollinen skeemamääritelmissä ja tietokantojen, jonojen, tallennussäiliöiden ja analytiikkaprojektien komentosarjojen valmistelu.
Aloita pehmeä täytäntöönpano (varoitukset, puuttuvien tunnisteiden koontinäytöt) ja siirrytään tiukkaan valvontaan (skeeman hylkääminen, estetyt käyttöönotot), kun tiimit ovat tottuneet tilanteeseen.

Voit priorisoida riskialttiimpia alueita – ensimmäiset maksut, chat, huijausten esto, hallintatyökalut – ja laajentaa sitten kattavuutta käytännön kehittyessä.

Miten ISO 27001 -merkintäjärjestelmä auttaa meitä GDPR:n ja PCI DSS:n kanssa samanaikaisesti?

Yhtenäinen merkintäjärjestelmä on yksi tehokkaimmista tavoista yhdenmukaistaa ISO 27001 -standardi, GDPR ja PCI DSS ilman kolmen eri luokittelujärjestelmän käyttöä. ISO 27001 A.5.13 antaa sinulle rakenteen; pieni määrä lisälippuja antaa sinulle mahdollisuuden ilmaista oikeudellinen ja maksullinen laajuus päälle.

varten GDPR ja muut yksityisyydensuojalait, tunnisteet ja liput antavat sinulle reaaliaikaisen kuvan siitä, missä henkilötietoja ja korkeamman riskin luokkia käsitellään. Tietovarastojen merkitseminen luottamuksellisiksi tai rajoitetuiksi contains_personal_data merkinnän avulla voit yhdenmukaistaa käyttöoikeus-, säilytys- ja rekisteröidyn oikeuksia koskevat prosessit todellisten tapahtumien kanssa. Lisämerkinnät todennäköisille lasten tiedoille, mahdollisille erityisryhmille tai profiloinnille auttavat sinua tunnistamaan, milloin tietosuojaa koskeva vaikutustenarviointi on tarpeen.

varten PCI DSSSelkeä merkintä helpottaa huomattavasti kortinhaltijatietojen ympäristön laajuuden määrittämistä. Järjestelmien, jotka tallentavat tai käsittelevät kokonaisia korttinumeroita tai arkaluonteisia todennustietoja, tulisi olla rajoitettuja ja selvästi merkittyjä kortinhaltijatietoja käsitteleviksi. Järjestelmät, jotka näkevät vain tokeneita tai koostettuja maksutietoja, voivat pysyä luottamuksellisina eri merkinnällä. Tämä erottelu tukee tarkempaa PCI-laajuuden määrittämistä, antaa sinun pitää muut kuin CDE-järjestelmät poissa soveltamisalasta ja osoittaa hankkijoille ja tilintarkastajille, että valvontaa sovelletaan siellä, missä sillä on eniten merkitystä.

Koska käytät yhtä luokittelurunkoa, voit selittää tilintarkastajille, hankkijoille ja sääntelyviranomaisille, kuinka tietoturva, yksityisyys ja maksujen hallinta alkavat kaikki samasta tietonäkymästäsi. ISMS-alusta, joka tukee ISO 27001-, ISO 27701- ja PCI DSS -määrityksiä – kuten ISMS.online – auttaa sinua ylläpitämään yhtä näkymää sen sijaan, että jonglööraisit useiden päällekkäisten laskentataulukoiden kanssa.

Kuinka voimme välttää sen, että eri tiimit keksivät omia järjestelmiään jokaiselle viitekehykselle?

Eroavaisuudet syntyvät, kun turvallisuus, yksityisyys ja maksut määrittelevät kukin oman kielensä. Tämän estämiseksi:

Aloita turvallisuusluokitustasot ja sopia yhdestä joukosta yksityisyys- ja maksunäkökohdat jota kaikki joukkueet käyttävät.
Dokumentoi tämä kerran tietoturvanhallintajärjestelmääsi ja heijasta se tietoluetteloosi ja arkkitehtuurikaavioihisi.
Kun uusi peli julkaistaan tai laajennat uudelle alueelle, käytä samaa kaavaa uudelleen ja lisää alueellisia vivahteita sääntöinä ja määrityksinä, älä erillisinä otsikoina.

Tällä tavoin GDPR, PCI DSS, NIS 2 ja tulevat tekoälysäännökset voivat kaikki osoittaa samoihin merkittyihin resursseihin, mikä vähentää monimutkaisuutta ja auttaa sinua vastaamaan kysymykseen "missä tämä data on?" luottavaisin mielin.

Mitä virheitä studiot tyypillisesti tekevät A.5.13:n kanssa, ja miten korjaamme ne?

Studiot usein panostavat luokittelukäytäntöön, mutta pysähtyvät sitten juuri ja juuri muuttamaan järjestelmien ja ihmisten toimintatapoja. Tuloksena on kuilu mitä dokumentissa sanotaan ja mitä pelit ja työkalut oikeasti tekevät.

Yleisiä malleja ovat:

Vain käytäntöön perustuva luokittelu: – siisti taulukko tietoturvajärjestelmässä, muutama ”Luottamuksellinen”-leimalla varustettu dokumentti, mutta ei tunnisteita kaatumisvedoksissa, valmistelutietokannoissa, analytiikkavienneissä tai tukinäyttökuvissa.
Liian monta tasoa tai kryptisiä otsikoita: – pitkät skeemat, jotka näyttävät monimutkaisilta, mutta joita on mahdotonta muistaa, joten tiimit joko nimeävät kaiken samalla tavalla tai ohittavat nimiöt.
Unohda "sotkuiset" sivutuotteet: – testiversiot, ad-hoc-viennit, moderointinäyttökuvat ja debug-paketit, jotka jäävät inventaarion ulkopuolelle, mutta sisältävät juuri sellaista tietoa, josta tiedonsääntelijät ja hyökkääjät välittävät.

Voit korjata tämän lyhyellä sisäisellä tarkastelulla, joka keskittyy siihen, missä arkaluonteiset tiedot todellisuudessa liikkuvat: virheenkorjaustiedostot, tukityökalut, moderaattorien kansiot, prosessien rakentaminen ja toimittaja-alustat. Yhdistä nämä ensin tunnisteisiisi ja laajenna sitten kattavuutta vähitellen vähemmän riskialttiisiin alueisiin.

Tietoturvan hallintajärjestelmä, kuten ISMS.online, auttaa välttämään ajautumista tarjoamalla keskitetyn omaisuusrekisterin, linkitetyt riskit ja kontrollit sekä toistettavat sisäisen tarkastuksen mallit, jotta A.5.13:sta tulee ylläpidetty kontrolli kertaluonteisen siivouksen sijaan.

Miten voimme mitata, paraneeko merkintöjen valvontamme?

Voit käyttää pientä joukkoa käytännön toimenpiteitä:

Tunnettujen tietovarastojen ja kriittisten työkalujen prosenttiosuus, joilla on ajantasaiset tunnisteet.
Kattaa korkean riskin luokat, kuten chatin, maksut, huijausnestotiedot ja hallintakonsolit.
Virheellisten merkintätapahtumien tai -tapausten lukumäärä neljännesvuosittain.
Aika, joka kuluu kaikkien vaikutuspiirissä olevien järjestelmien tunnistamiseen tapahtuma- tai kohdetietopyyntöharjoituksessa.

Jos nuo luvut paranevat ja sisäiset tarkastuksesi löytävät vähemmän yllätyksiä, voit osoittaa johdolle ja ulkoisille tarkastajille, että A.5.13 tuottaa todellista riskienvähennystä sen sijaan, että se olisi olemassa vain paperilla.

Kuinka voimme yhdistää merkinnät ja roolipohjaisen käyttöoikeuksien hallinnan pelaajatietojen suojaamiseksi estämättä työskentelyä?

Tietootsikot ja roolit ovat tehokkaimpia, kun ne suunnitellaan yhdessä: otsikot kuvaavat kuinka herkkä tietojoukko on; roolit kuvaavat kenen pitäisi koskea siihen ja millä ehdoillaPeliyritykselle tämä tarkoittaa, että rajoitettujen tietojoukkojen, kuten keskustelujen transkriptioiden, maksujälkien tai huijauksenestotietojen, tulisi olla saatavilla vain selkeästi määritellyille rooleille asianmukaisen lokikirjauksen ja hyväksynnän mukaisesti, ei jokaiselle kehittäjälle tai urakoitsijalle.

Yksinkertainen malli on määritellä vakioroolit ja yhdistää ne eksplisiittisesti otsikoihin yksittäisten taulukoiden tai työkalujen sijaan. Esimerkiksi pelaajatuen rooli voi käyttää luottamuksellisia tilejä ja sensuroituja keskustelukatkelmia, mutta ei koskaan täydellisiä rajoitettuja transkriptioita. Pelisuunnittelijat voivat työskennellä kootun telemetrian kanssa, joka ei koskaan paljasta tunnisteita. Tietoturva- ja petosanalyytikoilla voi olla tiukasti lokikirjoitettu pääsy rajoitettuihin tietojoukkoihin määriteltyjä tutkimuskäyttötapauksia varten.

Voit toteuttaa kyseisen kartoituksen identiteetin- ja pääsynhallintajärjestelmissä, analytiikka-alustoilla, hallintakonsoleissa ja tietovarastoissa viittaamalla luokittelu- ja luottamuksellisuusattribuutteihin käsin ylläpidettyjen luetteloiden sijaan. Kun uusi taulukko, lokihakemisto tai vienti luodaan ja nimetään, oikea käyttöoikeus seuraa automaattisesti sen luokittelusta erillisen, virheille alttiin käyttöoikeuspäivityksen sijaan.

Kuinka tämä lähestymistapa vähentää jokapäiväistä väärinkäyttöä ja pitää tiimit tehokkaina?

Suurin osa sisäisestä väärinkäytöstä ei ole ilkivaltaista; se on kätevyyttä: suurten lokitiedostojen kopioimista kannettavalle tietokoneelle virheenkorjausta varten, kokonaisten tietojoukkojen viemistä laskentataulukkoon tai kuvakaappausten jakamista, jotka paljastavat hiljaisesti pelaajien tietoja. Kun tunnisteet ja roolit toimivat yhdessä, työkalut voivat kannustaa parempiin päätöksiin estämättä työskentelyä suoraan.

Kojelaudat voivat oletusarvoisesti piilottaa rajoitetut tietojoukot yleisiltä rooleilta. Vientitoiminnot voivat automaattisesti peittää tunnisteet tai pakottaa lisätarkistuksia tiedoille, jotka on merkitty henkilö- tai maksutietoja sisältäviksi. Tukityökalut voivat varoittaa, kun rajoitettu vienti on lähetettävänä ulkoiselle palvelimelle, ja ohjata henkilöstöä turvallisempaan vaihtoehtoon. Aikarajoitetut roolit voivat antaa insinööreille tilapäisen pääsyn tiettyihin rajoitettuihin tietoihin tapahtumaa varten ja peruuttaa sen automaattisesti, kun työ on valmis.

Ajan myötä näkyvien otsikoiden, roolitietoisten käyttöoikeuksien ja järkevien oletusasetusten yhdistelmä tekee arkaluonteisten pelaajatietojen väärinkäytöstä paljon vaikeampaa, samalla kun asiantuntijat voivat tehdä tarvittavat tehtävänsä. Jos haluat järjestää nämä otsikot, roolit ja hyväksynnät yhteen paikkaan ja luoda selkeän näkymän tarkastajille, ISMS.online-alustan kaltaisen tietoturvan hallintajärjestelmän käyttöönotto antaa sinulle käytännöllisen perustan, jolle voit rakentaa.

ISO 27001 A.5.13 – Arkaluonteisten tietojen merkitseminen pelijärjestelmissä