Ulkoistetun pelikehityksen turvaaminen: ISO 27001 A.8.30 -standardin selitys studioille

Kun pelisi poistuu rakennuksesta: uusi ulkoistamisriski nousee pintaan

Ulkoistettua ISO 27001 A.8.30 -standardin mukaista kehitystä kohdellaan ikään kuin se tapahtuisi omassa studiossasi, omien sääntöjen ja vastuuvelvollisuutesi mukaisesti. Kaikki ulkoiset tiimit, jotka koskettavat koodia, koontiversioita tai työkaluja, laajentavat hyökkäyspintaasi, ja sinä olet vastuussa siitä, miten he suojaavat immateriaalioikeuksiasi, infrastruktuuriasi ja pelaajien luottamusta. Ulkoistettujen tiimien näkeminen osana ympäristöäsi, ei "jonnekin muualla", on lähtökohta kontrollien toimivuudelle todellisessa tuotannossa. Nämä tiedot ovat yleisiä eivätkä ne ole oikeudellisia tai sertifiointineuvoja.

Terveellinen ulkoistaminen alkaa siitä, että oletat kumppaniesi jakavan riskit, eivätkä vain työmäärääsi.

Nykyaikaisessa pelikehityksessä yhteiskehityskumppanit, taidetalot, porttaustiimit ja freelancerit työskentelevät harvoin erillisten tiedostojen parissa. He muodostavat tyypillisesti yhteyden jaettuihin Git- tai Perforce-arkistoihin, koontijärjestelmiin, pilvitallennustilaan taiteelle ja äänelle, telemetria-koontinäyttöihin ja sisäisiin ongelmien seurantajärjestelmiin. Heikko salasana toimittajalla, hallitsematon kannettava tietokone tai vanhentunut VPN-asiakasohjelma voi nykyään riittää vuotamaan kokonaisen kauden sisällön tai antamaan hyökkääjille reitin taustajärjestelmääsi.

Käytännön raja "sisäisen" ja "ulkoisen" työn välillä on hämärtynyt. Ulkoiset tiimit istuvat usein samoilla keskustelukanavilla, käyttävät samoja tikettijonoja ja joskus jopa jakavat SSO-vuokralaisia työkaluille. Jos et tarkoituksella suunnittele hallintalaitteita tätä todellisuutta varten, tietoturvajärjestelmäsi rakennetaan studiomallin ympärille, jota ei enää ole olemassa, mikä jättää aukkoja, jotka pelaajat, julkaisijat ja tilintarkastajat lopulta huomaavat.

Miksi ulkoistaminen muuttaa hyökkäyspintaasi

Ulkoistaminen muuttaa hyökkäyspintaasi, koska se moninkertaistaa koodiisi, sisältöösi ja live-ops-järjestelmiisi johtavien polkujen määrän. Olet edelleen vastuussa riskistä jokaisella näistä poluista riippumatta siitä, missä ihmiset tai laitteisto sijaitsevat.

Ulkoistettu kehitys tarkoittaa, että pääsy peliisi ei ole enää rajoitettu omiin verkkoihisi, laitteisiisi ja henkilökuntaasi. Kolmannen osapuolen tekijät piirtävät tekstuureja, yhteiskehitystiimit kirjoittavat koodia, laadunvarmistustoimittajat testaavat varhaisia koontiversioita ja live-op-kumppanit käyttävät työkaluja – kaikki luovat uusia reittejä IP-osoitteeseesi ja infrastruktuuriisi. Jos et hallitse näitä reittejä selkeillä käyttöoikeussäännöillä, teknisillä valvontakeinoilla ja tarkistuspisteillä, perit kaikki kyseisten kumppaneiden käyttämät tai käyttämättä olevat tietoturvakäytännöt.

Monissa studioissa ulkoiset kumppanit käsittelevät nyt kehitysputkia, telemetriatyökaluja ja sisäisiä hallintapaneeleja, eivätkä pelkästään resurssikansioita. Tämä vahvistaa yksinkertaisten vikojen vaikutusta. Sopimuksen päättymisen jälkeen aktiiviseksi jäänyt jaettu tili, testiversioissa käytetty henkilökohtainen kannettava tietokone tai hallitsemattomalla palvelimella oleva kopioitu tietovarasto voivat kaikki muuttua hyökkääjien sisäänpääsypisteiksi tai vuotojen lähteiksi, jotka vahingoittavat tuloja, mainetta ja alustasuhteita.

Ensimmäiset vaiheet: tee näkymättömästä ulkoistuskartasta näkyvä

Jotta A.8.30 olisi mielekäs, tarvitset ensin selkeän kuvan siitä, kuka rakentaa mitä sinulle ja mitä käyttöoikeuksia he käyttävät. Yksinkertainen ulkoistettu kehityskartta muuttaa epämääräiset oletukset konkreettisiksi faktoiksi, joita voit hallita, valvoa ja esitellä tilintarkastajille osana tietoturvanhallintajärjestelmääsi.

Ensimmäinen käytännön askel on tehdä ulkoistamisjalanjälkesi näkyväksi tavalla, jonka pohjalta voit toimia. Tämä tarkoittaa, että talousosaston toimittajalistan ulkoistamista pidemmälle menemistä ja ulkoistuskartan rakentamista, joka vastaa tylliin kysymyksiin: kuka suunnittelee, koodaa, testaa tai käyttää mitään peleihisi liittyvää ja mitä he tarkalleen ottaen voivat nähdä tai muuttaa?

Aloita listaamalla kaikki kehitykseen osallistuvat kumppanit: yhteiskehitysstudiot, taide- ja äänitoimittajat, porttaustiimit, laadunvarmistustoimittajat, live-ops-kumppanit, työkaluasiantuntijat ja henkilöstön lisäysurakoitsijat. Kirjaa jokaisen osalta, mihin palveluihin heillä on pääsy: tiettyihin tietovarastoihin, haaratoimistoihin, depotteihin, ympäristöihin, tietokantoihin, kojelaudoihin tai työkaluihin. Yrität korvata jotain, jonka mielestämme he näkevät vain taidetta, ja tämä kumppani voi hakea nämä kolme depottia ja suorittaa nämä kaksi kojelautaa.

Seuraavaksi luokittele jokainen suhde sen vaikutuksen mukaan. Pieni konseptitaidepaja, joka vastaanottaa vain litistettyjä kuvaviittauksia, ei ole samassa kategoriassa kuin yhteiskehitysstudio, jolla on kirjoitusoikeudet pelijärjestelmiin ja matchmaking-logiikkaan. Laadunvarmistusyrityksellä, joka voi ladata lähes valmiita versioita, on erilaiset riskit kuin lokalisointitoimistolla, joka työskentelee vain laskentataulukoiden avulla. Tämä yksinkertainen porrastus antaa sinulle pohjan päättää, milloin ISO 27001 A.8.30 tarvitsee painavaa todistusaineistoa ja milloin kevyempi lähestymistapa on hyväksyttävä.

Lopuksi yhdistä tämä kartta nykyiseen hallintoasi. Kysy, kuka omistaa kunkin suhteen, kuka hyväksyy käyttöoikeudet, kuka tarkistaa ne ja kuka huomaisi, jos kyseisen kumppanin tiedot vaarantuisivat huomenna. Hyvin usein rehellinen vastaus on, ettei kukaan ole yksi henkilö, ja juuri tätä aukkoa A.8.30:n on tarkoitus paikata. Tässäkin strukturoitu alusta, kuten ISMS.online, voi auttaa tarjoamalla sinulle yhdenmukaisen tavan kirjata omistajuus, käyttöoikeudet ja päätökset eri projekteissa, jotta et ole riippuvainen yksittäisten ihmisten muistista tai hajanaisista dokumenteista.

Varaa demo

Mitä ISO 27001 A.8.30 todella vaatii pelistudioilta

ISO 27001 A.8.30 -standardi edellyttää, että käsittelet ulkoistettua kehitystä ikään kuin se tapahtuisi oman studiosi sisällä, ja että työhön sovelletaan samoja turvallisuussääntöjä ja vastuuvelvollisuutta riippumatta siitä, kuka pelijärjestelmät tai sisällön itse asiassa rakentaa. Ulkoisten tiimien on noudatettava kehitystyön tietoturvavaatimuksiasi, ja sinun on kyettävä osoittamaan, miten ohjaat, valvot ja tarkastelet tätä työtä ajan kuluessa; pelkät salassapitosopimukset eivät riitä, koska tarvitset todisteita todellisesta kontrollista.

A.8.30:n selkokielinen tulkinta pelistudioille

Yksinkertaisesti sanottuna A.8.30 sanoo, että ulkoistaessasi minkä tahansa osan kehityksestä, hallitset edelleen, miten työ tehdään. Tietoturvavaatimuksesi on täytettävä riippumatta siitä, kuka kirjoittaa koodin tai luo resurssit.

Useimpien studioiden "tietoturvavaatimuksiin" kuuluvat ainakin julkaisemattoman sisällön ja omaan teknologiaan liittyvän luottamuksellisuuden, koodin ja resurssien eheyden sekä pelinrakennus- ja live-ops-järjestelmien saatavuuden. Pelisi käsittelystä riippuen ne voivat sisältää myös pelaajatietojen yksityisyyttä koskevia velvoitteita ja maksuihin tai lasten tietoihin liittyviä sääntelyvaatimuksia. A.8.30 edellyttää, että nämä vaatimukset muokkaavat ulkoistetun kehitystyön suunnittelua ja toteutusta, eivätkä ainoastaan sitä, miten sitä kuvataan lakikielellä.

Ratkaisevasti valvonta ei tarkoita sitä, että jokainen toimittaja pakotettaisiin ottamaan käyttöön ISO 27001 -standardi kokonaisuudessaan. Kyse on sen varmistamisesta, että ne osat työstä, jotka liittyvät peleihisi, tehdään tietoturvanhallintajärjestelmäsi (ISMS) mukaisesti. Tämä voi tarkoittaa sitä, että pienemmiltä kumppaneilta annetaan selkeät toimintatavat ja kiellot, käyttöoikeussäännöt ja työkalut, kun taas kypsemmiltä yhteiskehitysstudioilta odotetaan vahvempia sisäisiä käytäntöjä ja muodollisempaa varmuutta.

Miten A.8.30 liittyy toimittajien ja kehityksen valvontaan

Tilintarkastajan näkökulmasta A.8.30 on osa toimittajanhallinnan ja turvallisen kehityksen yhteistä kokonaisuutta, ei erillinen sääntö. Ulkoistetun kehityksen on sovittava yhteen kontrollien, kuten A.5.19–A.5.22, muutoshallinnan ja turvallisen koodauksen, kanssa sen sijaan, että sitä käsiteltäisiin erityistapauksena, joka esiintyy vain oikeudellisissa asiakirjoissa.

Valintavaiheessa sinun tulisi pystyä osoittamaan, miten arvioit kumppanin kykyä täyttää tietoturvaodotuksesi. Sopimuksissa sinun tulisi osoittaa, missä nämä odotukset on kirjattu velvoitteiksi. Päivittäisessä työssä sinun tulisi osoittaa, miten käyttöoikeudet, koodin tarkistus, testaus ja käyttöönotto toimivat samalla tavalla ulkoisten ja sisäisten osallistujien osalta. Valvonnassa sinun tulisi pystyä esittämään lokit, tarkistukset ja korjaavat toimenpiteet, jotka liittyvät erityisesti ulkoistettuun työhön.

Tilintarkastajat odottavat tyypillisesti neljänlaista evidenssiä A.8.30-vaatimuksen osalta: hallintoasiakirjat, sopimukset, toiminnan valvonta ja varmennustoimet. Alla oleva taulukko antaa yksinkertaisen kartoituksen, jota voit käyttää suunnittelun tarkistuslistana studiollesi.

Johdantokatsaus tilintarkastajan usein etsimiin todistusaineistotyyppeihin:

alue	Tyypillisiä esineitä	Mitä se todistaa
Hallinto	Ulkoistetun kehityksen menettely, riskinarvioinnit	Sinulla on strukturoitu lähestymistapa
Sopimukset	MSA:t, soveltuvuussopimukset, turvallisuusaikataulut, salassapitosopimukset	Kumppanit ovat sitoutuneet vaatimuksiisi
Operatiivinen työ	Käyttöoikeusmatriisit, repo-säännöt, koodin tarkistuslokit, testit	Kontrollit ovat olemassa ja niitä käytetään käytännössä
Varmuus:	Toimittajien arvioinnit, löydökset, toimenpiteet ja jatkotoimet	Seuraat ja parannat ajan myötä

Et tarvitse täydellistä viimeistelyä heti alusta alkaen, mutta tarvitset yhtenäisen tarinankerronnan: näin päätät, kuka voi rakentaa pelisi, näin vaadit heiltä, näin integroit ja tarkistat heidän työnsä ja näin tiedät, että se edelleen tapahtuu. Ajan myötä tästä tarinasta tulee keskeinen osa sitä, miten selität tietoturvanhallintajärjestelmääsi julkaisijoille, alustakumppaneille ja auditoijille, varsinkin jos voit näyttää sen johdonmukaisesti alustalla, kuten ISMS.online, sen sijaan, että näyttäisit sen hajanaisilla esittelykanavilla ja keskustelupalstoilla.

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

Ad hoc -sopimuksista kontrolloituun ulkoistuskehykseen

ISO 27001 A.8.30 -standardin näkökulmasta todellinen harppaus on siirtyminen kertaluonteisista ulkoistuspäätöksistä johdonmukaiseen ulkoistuskehykseen, jossa jokainen projekti noudattaa samaa tarkastusten ja kontrollien runkoa, mutta antaa tuottajille ja teknologiajohtajille silti riittävästi vapautta työskennellä tuotantovauhdilla ja saavuttaa luovia tavoitteita. A.8.30-standardin noudattamiseksi ilman tuotannon lamauttamista tarvitaan yksinkertainen ja toistettavissa oleva ulkoistuskehys, jota jokainen projekti voi noudattaa. Se korvaa improvisoidut tarkistuslistat ja sankarilliset yksilölliset ponnistelut elinkaarella, joka tuntuu luonnolliselta jokapäiväisessä käytössä. Näin turvallisuudesta tulee rutiininomainen osa yhteistyötä kumppaneiden kanssa, eikä myöhäisen vaiheen esto, joka ilmestyy juuri ennen koontiversion lukitusta.

Ulkoistetun kehitystyön elinkaaren suunnittelu, joka sopii tuotantoon

A.8.30 toimii parhaiten, kun ulkoistetun kehitystyön elinkaari heijastaa olemassa olevia tuotantoporttejasi. Ydinajatus on yksinkertainen: sido tietoturva- ja toimittajatarkastukset jo käyttämiisi virstanpylväisiin, jotta tiimit eivät tunne työskentelevänsä toisen, rinnakkaisen prosessin läpi, joka on olemassa vain auditoijille. Käytännöllinen ulkoistetun kehitystyön elinkaari studiolle heijastaa siis sitä, miten jo siirrät pelejä virstanpylväiden ja vihreän valon tarkastusten läpi, lisäämällä tietoturvaan liittyviä portteja jo olemassa oleviin hetkiin sen sijaan, että keksit uusia kokouksia ja dokumentteja niiden itsensä vuoksi, ja tekemällä näistä porteista näkyviä osana tietoturvanhallintajärjestelmääsi.

Visuaalinen: Yksinkertainen elinkaarikaavio, joka näyttää ulkoistettujen kumppaneiden vastaanoton ja offboarding-vaiheen.

Tyypillisessä elinkaaressa on seitsemän vaihetta:

Vaihe 1 – Sisäänotto

Päätä, tarvitsetko ulkopuolista kumppania, mitä he toimittavat ja millaiset käyttöoikeudet he tarvitsevat tehdäkseen työn turvallisesti.

Vaihe 2 – Huolellisuustarkastus

Tarkista, pystyykö ehdokaskumppani täyttämään tietoturvaan ja yksityisyyteen liittyvät perusodotuksesi, käyttämällä oikeasuhtaisia kyselylomakkeita ja tarvittaessa olemassa olevia todistuksia.

Vaihe 3 – Sopimusten tekeminen

Muunna turvallisuusodotukset sitoviksi ehdoiksi, mukaan lukien selkeät velvoitteet, vastuut, tapausten raportointi ja kaikki tarvitsemasi tarkastus- tai arviointioikeudet.

Vaihe 4 – Perehdytys

Muunna sopimukset konkreettisiksi käyttöoikeuksiksi, työkaluiksi, perehdytykseksi ja alkukoulutukseksi kumppanille, ja hyväksynnät ja tiedot voit myöhemmin näyttää tilintarkastajille.

Vaihe 5 – Toimitus

Anna kumppanin tehdä työ sovittujen työkalujen, haarojen ja ympäristöjen avulla määriteltyjen kontrollien alaisena. Koodin tarkistus, testaus ja käyttöönotto tapahtuvat samalla tavalla kuin sisäisillä tiimeillä.

Vaihe 6 – Seuranta

Tarkista toimintaa, saatavuutta ja tuotoksia säännöllisesti, eskaloi ongelmia, kirjaa päätökset ja syötä havainnot toimittajien tarkastus- ja riskienhallintaprosesseihisi.

Vaihe 7 – Poistuminen

Poista käyttöoikeudet, hae tai poista tiedot turvallisesti ja suorita lopetustehtävät työn päätyttyä, mukaan lukien ulkoistuskartan ja toimittajariskirekisterin päivittäminen.

Olennaista on upottaa nämä vaiheet olemassa olevaan projektinhallintaasi. Voit esimerkiksi vaatia, ettei yhtäkään kumppania ole perehdytetty ennen kuin vähimmäistason due diligence -kyselylomake on täytetty ja hyväksytty, ja että offboarding-tehtävät ovat osa projektin sulkemisen tarkistuslistaa. Näin voit kasvattaa hallintaa ilman, että luot rinnakkaista byrokratiaa tai hidastat tuotantoa tarpeettomasti.

Toimittajatasojen ja jaettujen työkalujen käyttö kertaluonteisten prosessien sijaan

ISO 27001 -standardin kohdalla suhteellisuus on tärkeää: kaikki ulkoistetut suhteet eivät oikeuta raskaita prosesseja. Toimittajien porrastaminen ja jaetut mallit mahdollistavat A.8.30:n skaalaamisen järkevästi yhteiskehitys-, laadunvarmistus-, taide- ja neuvontakumppaneiden kesken ilman, että jokaista sopimusta varten tarvitsee keksiä uusia asiakirjoja tai polttaa liikearvoa matalan riskin toimittajien kanssa.

Kaikki ulkoistetut suhteet eivät edellytä samanlaista tarkastusta. Koodikantaasi ja live-ops-pinoosi integroitu kumppani ansaitsee paljon enemmän tarkastuksia kuin erillisiä äänitiedostoja tarjoava putiikkistudio. Toimittajien porrastuksen avulla voit tallentaa nämä vivahteet jäsennellyllä tavalla ja selittää ne selkeästi tilintarkastajille ja julkaisijoille.

Useimmat studiot hyötyvät vähintään kolmesta tasosta:

Ykköstaso: Kumppanit, joilla on etuoikeutettu tai syvä pääsy, kuten yhteiskehitysstudiot ja ydinosaamisen taustajärjestelmien tai huijauksenestojärjestelmien tarjoajat.
Toinen taso: Kumppanit, joilla on merkittävä mutta rajoitettu pääsy, kuten siirtotoimistot tai laadunvarmistustiimit, jotka näkevät sisäisiä koontiversioita.
Kolmas taso: Kumppanit, joilla on vain sisällöntuotantoon tai neuvonantajana toimivia rooleja eikä suoraa pääsyä koodiin tai live-ympäristöihin.

Määrität kullekin tasolle sovellettavat kyselylomakkeet, sopimuslausekkeet, tietoturvan perustasot ja tarkistustiheydet. Korkean riskin kumppaneille asetetaan tiukemmat vaatimukset ja useammin tapahtuva varmistus, kun taas matalan riskin kumppaneille asetetaan kevyempi mutta silti johdonmukainen lähestymistapa.

Jaetut työkalut tekevät tästä totta. Sen sijaan, että jokainen tuottaja rakentaisi omat laskentataulukot ja sähköpostiketjut, tarjoat vakiomuotoisen aloituspaketin: riskinarviointimallin, tietoturvaliitteen, käyttöoikeuspyyntölomakkeen ja yksinkertaisen tarkistuslistan perehdytystä ja poistumista varten. Kun projekti käynnistää uuden toimittajasuhteen, he lähtevät liikkeelle näistä malleista ja mukauttavat niitä vain perustelluissa tapauksissa. Ajan myötä, kun opit, mikä toimii ja mikä hidastaa sinua, hiot malleja – et viittäkymmentä hajanaista muunnelmaa. Alusta, kuten ISMS.online, voi auttaa sinua pitämään nämä mallit ja päätökset yhdenmukaisina eri nimikkeiden välillä.

Pelikohtaiset uhat: vuodot, pelimoottorit, huijauksenesto ja live-optiot

Pelialan näkökulmasta A.8.30:n on katettava uhkia, jotka yleisissä yritysohjeissa usein unohdetaan. Kerrosten spoilerit, pelimoottorien sisäosat, huijauksenestojärjestelmät ja live-op-työkalut luovat riskejä, jotka ovat hyvin erilaisia kuin tavanomaisissa liiketoimintasovelluksissa, varsinkin kun ulkoisilla studioilla on suora rooli sisällön rakentamisessa ja operoinnissa.

Pelikehitys tuo mukanaan uhkamalleja, joita yleiset ISO-ohjeet usein sivuuttavat: spoileripainotteista tarinasisältöä, omaa pelimoottoria, huijauksenesto-logiikkaa, live-talouksia ja kausittaisia tapahtumia. Ulkoistettu kehitys koskettaa monia näistä suoraan. Jos jätät nämä yksityiskohdat huomiotta, on olemassa riski, että suunnittelet kontrollirakenteita, jotka ovat muodollisesti siistejä, mutta sokeita oikeiden hyökkääjien, vuotajien ja huijauskehittäjien käyttäytymiselle.

Kartoitus siitä, mistä todelliset vahingot voisivat tulla

A.8.30-standardin mukaisesti sinun on oltava selkeä siitä, mitkä resurssit ja järjestelmät todellisuudessa vahingoittaisivat sinua, jos ne vuotaisivat tai vaarantuisivat. Kun nämä "kruununjalokivet" ovat tiedossa, voit jäljittää, mitkä ulkoiset kumppanit koskevat niitä, ja tiukentaa valvontaa vastaavasti sen sijaan, että yrittäisit suojata kaikkea tasapuolisesti. Pelikohtainen uhkien mallintaminen alkaa kysymällä, mikä todellisuudessa vahingoittaisi sinua, jos se karkaisi tai sitä peukaloitaisiin: narratiivipohjaisessa pelissä tämä tarkoittaa todennäköisesti juonta, välianimaatiota ja avaingrafiikkaa; kilpailullisessa online-pelissä se tarkoittaa todennäköisesti huijauksenestojärjestelmiä, palvelinpuolen logiikkaa ja talousvalvontaa; ja lisensoidussa urheilu- tai elokuvaominaisuudessa se voi olla hahmosuunnittelua ja kuvankäsittelyresursseja, joita koskevat tiukat markkinointi- ja lakisääteiset sitoumukset.

Tyypillisiä vaikuttavia omaisuusluokkia ovat:

Kerroksellista sisältöä, kuten käsikirjoituksia, välianimaatioita ja avaintaidetta ilmoittamattomille hahmoille tai paikoille.
Tekniset resurssit, kuten moottorimoduulit, huijauksenestojärjestelmät, palvelinlogiikka ja rakennus- tai allekirjoitusputket.
Kaupallisesti arkaluonteisia tietoja, mukaan lukien taloudelliset parametrit, myynninedistämistapahtumat ja lisensoitujen kiinteistöjen suunnittelu.

Kun tiedät, mitkä resurssit ovat tärkeimpiä, jäljitä, mitkä ulkoiset kumppanit koskaan näkevät niitä. Kääntääkö yhteiskehitysstudiosi huijauksenestomoduuleja paikallisesti? Käsitteleekö porttaustalo konsoliversioita ja siten allekirjoittaako avaimia? Hallinnoiko live-op-toimittaja koontinäyttöjä, jotka voivat muuttaa pelin sisäisiä hintoja tai palkintoja? Lataako laadunvarmistustiimi säännöllisesti kerroskriittisiä versioita kotitoimistoihin? Jokainen "kyllä" on merkki siitä, että A.8.30-kontrolliesi on tehtävä enemmän kuin yleisesti vaadittava "turvallista kehitystä".

Sinun tulisi myös kiinnittää huomiota harmaisiin alueisiin. Spoilerit, jotka vaikuttavat hauskoilta joillekin toimijoille, voivat olla sopimusluonteisia lisenssinantajille tai heikentää huolellisesti ajoitettuja markkinointikeikkoja. Samoin debug-data, joka näyttää harmittomalta insinööreille, voi sisältää tunnisteita tai lokeja, joilla on yksityisyyden suojaan tai petosriskiin liittyviä vaikutuksia. Näiden rajatapausluokkien luokittelu selkeästi auttaa sinua perustelemaan, miksi jotkut kumppanit kohtaavat tiukempia valvontatoimia kuin toiset, ja auttaa sinua selittämään tätä logiikkaa tilintarkastajille ja julkaisijoille.

Erityistä huolellisuutta moottoreille, huijausnestolle ja reaaliaikaisille operaatioille

Moottorit, huijauksenestojärjestelmät ja live-op-työkalut sijaitsevat teknisen monimutkaisuuden ja liiketoimintariskin risteyskohdassa, ja A.8.30 antaa vahvan pohjan näiden alueiden käsittelylle erityistapauksina aina, kun ulkoiset tiimit käsittelevät niitä. Näillä osa-alueilla on tiukempi valvonta ja selkeämpi näyttö kuin vähemmän vaikuttavassa työssä. Erityisesti kolme teknistä aluetta ansaitsee tätä huomiota ulkoistetuissa skenaarioissa – moottorit ja ydinteknologia, huijauksenestojärjestelmät ja live-op-työkalut – koska jokainen yhdistää syvän teknisen monimutkaisuuden ja suuren vaikutuksen, jos ne rikkoutuvat tai paljastuvat, ja jokainen on alue, jolla julkaisijat ja alustat esittävät nyt yksityiskohtaisia kysymyksiä.

Pelimoottorit ja ydinteknologia edustavat usein vuosien investointia ja erottavat kilpailijat visuaalisen uskollisuuden, suorituskyvyn tai työkalujen työnkulkujen suhteen. Ulkopuolisen studion laajuisen, segmentoimattoman pääsyn salliminen pelimoottorin koodiin voi olla tarpeen laajoissa yhteiskehityssuhteissa, mutta sen ei pitäisi olla oletusarvo kaikille toimittajille. Eristä mahdollisuuksien mukaan uudelleenkäytettävät pelimoottorin komponentit pelikohtaisesta logiikasta ja rajoita sitä, kuka voi nähdä tai muokata niitä, käyttämällä erillisiä repositorioita, haaroja ja ympäristöjä.

Huijauksenestojärjestelmät ovat erityisen herkkiä. Kehityksen ulkoistaminen voi olla järkevää erikoisasiantuntemuksen kannalta, mutta se lisää riskiä, että toteutustiedot vuotavat huijauksenestoyhteisöihin tai että haitallista koodia joutuu asiakkaille. Jos otat mukaan kumppaneita tällä tasolla, tiukka repositorioiden segmentointi, luotettavan sisäisen henkilöstön suorittama pakollinen koodin tarkistus ja tiukasti valvotut rakennusympäristöt ovat olennaisia. Sinun tulisi myös pystyä osoittamaan tilintarkastajalle, mitkä tilit ovat koskaan koskeneet huijauksenestokoodiin ja miten näitä muutoksia testattiin.

Live-ops-työkalut, aina järjestelmänvalvojan kojelaudoista talousvalvojiin, ovat toinen yleinen ulkoistuksen kohde. Yksikin vaarantunut tili voi häiritä tapahtumia, syöttää petollisia esineitä tai siirtää valuuttaa. Kaikkia ulkoisia tiimejä, jotka rakentavat tai käyttävät näitä työkaluja, tulisi kohdella osana operatiivista selkärankaa, jossa on vahva todennus, verkon hallinta, valvonta ja selkeät tapausten eskalointipolut. A.8.30 tarjoaa perustelut vaatia tätä huolellisuuden tasoa, vaikka lyhyen aikavälin toimituspaine olisi korkea, ja toimittajien tarkastustietosi voivat osoittaa, kuinka ylläpidät tätä tasoa eri kausien ja nimikkeiden välillä.

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

Varaa esittelysi

Turvallisten sopimusten ja palvelutasosopimusten suunnittelu ulkoisten kehittäjätalojen kanssa

Tilintarkastajan näkökulmasta sopimukset ja palvelutasosopimukset ovat se kohta, jossa A.8.30 lakkaa olemasta idea ja siitä tulee täytäntöönpanokelpoinen velvoite. Studiollesi ne ovat myös tapa, jolla teet "turvallisesta ulkoistetusta kehityksestä" konkreettista kumppaneille hidastamatta kaikkia neuvotteluja liian pitkälle tai tekemättä tuottajien sähköpostilaatikoista pullonkaulaa. Sopimukset ja palvelutasosopimukset ovat se kohta, jossa muutat A.8.30-aikeesi mitattavaksi: huonosti tehtyinä ne ovat tiheitä dokumentteja, joita kukaan ei lue, ennen kuin jokin menee pieleen; hyvin tehtyinä ne antavat molemmille osapuolille selkeyden siitä, mitä "turvallinen ulkoistettu kehitys" tarkoittaa käytännössä, ja helpottavat huomattavasti ISO 27001 -standardin noudattamisen osoittamista ja julkaisijoiden kyselyihin vastaamista luottavaisin mielin.

Turvallisuusperusteisen sopimuspinon rakentaminen

Tietoturvallinen sopimuspino sisällyttää tietoturva-ajattelun pääsopimukseen, salassapitosopimuksiin, työkuvauksiin ja aikatauluihin alusta alkaen. Tällä tavoin jokainen ulkoistettu projekti alkaa johdonmukaisella lähtötasolla, joka jo heijastaa ISO 27001 -standardin odotuksia ja toimittajan valvontaa.

Ulkoistetun kehityksen vankassa sopimuspinossa on yleensä neljä tasoa: pääpalvelusopimus, yksi tai useampi salassapitosopimus, työsuunnitelmat ja niitä tukevat aikataulut, kuten palvelutasosopimukset ja tietoturvaliitteet. Sen sijaan, että tietoturvaa käsiteltäisiin erillisenä osana, tietoturva-ajattelu sisällytetään kaikkiin näihin tasoihin, jotta tuottajien ei tarvitse keksiä ehtoja uudelleen aikapaineen alla.

Pääpalvelusopimus määrittelee koko suhteen. Siinä tulisi asettaa perustason odotukset tietoturvalle, luottamuksellisuudelle, immateriaalioikeuksille, tietosuojalle, häiriöraportoinnille, tarkastusoikeuksille ja alihankinnalle. Salassapitosopimuksissa keskitytään sitten siihen, mikä katsotaan luottamukselliseksi – moottorikoodi, työkalut, julkaisemattomat koontiversiot, suunnitteluasiakirjat ja telemetrianäytteet – ja tehdään selväksi, että kumppani ei saa käyttää niitä uudelleen tai paljastaa sovitun laajuuden ulkopuolella.

Työsuunnitelmat linkittävät tiettyjä projekteja tai nimikkeitä pääsopimukseen. Niissä kuvataan, mitä kumppani tekee, mihin heidän on päästävä käsiksi, mitä tuotoksia he tuottavat ja mitä ympäristöjä he käyttävät. Kuhunkin suunnitelmaan liitetyt tietoturva-aikataulut ja palvelutasosopimukset määrittelevät konkreettisemmat velvoitteet: monivaiheisen todennuksen käyttö, etätyön rajoitukset, vähimmäiskorjausvaatimukset, isännöityjen työkalujen käyttöaikatavoitteet sekä aikataulut haavoittuvuuksien raportoinnille ja korjaamiselle.

Kun nämä elementit standardoidaan, tuottajien ja lakimiestiimien ei tarvitse selvittää turvallisuustermejä uudelleen alusta alkaen. He työskentelevät tarkistettujen mallien pohjalta, jotka jo heijastavat A.8.30:a ja toimittajan kontrolleja, ja säätävät niitä vain silloin, kun tietty toimeksianto todella eroaa niistä. Järjestelmä, kuten ISMS.online, voi auttaa sinua linkittämään nämä termit suoraan ISMS-järjestelmän kontrolleihin ja riskeihin, jolloin sopimuksista tulee eläviä artefakteja staattisten tiedostojen sijaan.

Turvallisuusodotusten muuttaminen mitattaviksi velvoitteiksi

A.8.30 kannustaa muuttamaan korkean tason tietoturvaodotukset velvoitteiksi, joita voidaan mitata, tarkastella ja parantaa. Selkeät ja testattavat vaatimukset helpottavat myös oikeudellisten asiakirjojen yhdenmukaistamista tietovarastoissa ja ympäristöissä käyttämiesi operatiivisten kontrollien kanssa, jotta lakimiehesi ja insinöörisi puhuvat käytännössä samoista asioista.

A.8.30-kohdan osalta ei riitä, että todetaan ”toimittajan on pidettävä asiat turvassa”. Tarvitset vaatimuksia, jotka voidaan tarkistaa sekä päivittäisessä työssä että auditoinnin yhteydessä. Tässä kohtaa selkeät ja mitattavat velvoitteet sopimuksissa ja palvelutasosopimuksissa tekevät käytännön eron sekä studiollesi että kumppaneillesi.

Esimerkiksi käyttöoikeuksien hallintaa koskevat velvoitteet voivat edellyttää, että kaikkien toimittajan työntekijöiden, joilla on pääsy tietovarastoihin ja ympäristöihin, on käytettävä nimettyjä tilejä, monivaiheista todennusta ja hyväksyttyjä laitteita. Turvallisen kehityksen velvoitteet voivat edellyttää koodausohjeiden noudattamista, pakollista koodin tarkistusta ja osallistumista tiettyihin tietoturvatestaustoimiin. Tapahtumavelvoitteet voivat määrittää enimmäisajat, joiden kuluessa epäillyistä tietomurroista ilmoitetaan, alustavien raporttien muodon ja odotukset yhteistyöstä tutkimuksissa.

Operatiivisella puolella, jos toimittaja isännöi puolestasi rakennusinfrastruktuuria tai live-ops-työkaluja, palvelutasosopimusten tulisi sisältää saatavuustavoitteet, palautumisajan ja -pisteen tavoitteet, ylläpitoikkunat ja tietojen säilytyssitoumukset. Tietosuojaliitteiden tulisi selventää, onko toimittaja henkilötietojen käsittelijä vai alikäsittelijä ja mitä yksityisyyden suojatoimia sovelletaan, erityisesti silloin, kun käsittelet maksuja tai lasten tietoja.

Kun sinun on myöhemmin näytettävä tilintarkastajalle, miten sovelsit A.8.30-standardia, sopimusten ja palvelutasosopimusten tiettyihin osiin viittaaminen tekee elämästä paljon helpompaa kuin laajoihin aiesopimuksiin turvautuminen. Näiden velvoitteiden linkittäminen ISMS.online-sivuston kontrolleihin, riskeihin ja todisteisiin osoittaa, että ne eivät ole vain sanoja paperilla, vaan aktiivisesti hallittuja osia ISMS-järjestelmästäsi.

Tekniset kontrollit: repot, ympäristöt ja CI/CD ulkoistettua kehitystä varten

Ohjauksen suunnittelun näkökulmasta A.8.30 on helpoin osoittaa, kun versionhallinta, ympäristöt ja kehitysputket noudattavat samoja sääntöjä sekä sisäisille että ulkoisille kehittäjille. Hyvin suunnitellut tekniset kontrollit osoittavat, että turvalliset toimintatavat ovat oletusarvoisia, eivätkä ne ole asioita, joiden muistaminen paineen alla tai kriisin aikana on ihmisten tehtävä.

Sopimukset kuvaavat, mitä pitäisi tapahtua; tekniset kontrollit auttavat varmistamaan, että se todella tapahtuu. Ulkoistetussa kehityksessä useimmat näistä kontrolleista sijaitsevat kolmessa paikassa: versionhallintajärjestelmissä, ympäristöissä sekä rakennus- ja käyttöönottoputkissa. Jos nämä onnistuvat, suuri osa A.8.30:n tarkoituksesta pannaan täytäntöön automaattisesti, ja se voidaan osoittaa konfiguraation ja lokien avulla.

Visuaalinen: CI/CD-prosessikaavio, joka näyttää testit, arvioinnit ja käyttöönottoportit kumppaneiden panoksille.

Ulkoisten tiimien käyttöoikeuksien ja ympäristöjen muokkaaminen

Hyvä A.8.30-todiste alkaa usein selkeistä käyttöoikeusmalleista ja ympäristöjen erottelusta ulkoisille osallistujille, koska jos voit osoittaa, että kumppaneilla on rajatut roolit, rajoitetut käyttöoikeusikkunat ja selkeä offboarding, ulkoistettu kehityskerros on paljon vakuuttavampi auditoijille ja alustakumppaneille. Näiden mallien ensimmäinen periaate on vähiten oikeuksia: älä anna ulkoisille kehittäjille enempää käyttöoikeuksia kuin he todella tarvitsevat, eikä pidemmäksi aikaa kuin he todella tarvitsevat sitä. Käytännössä tämä alkaa roolipohjaisesta käyttöoikeuksien hallinnasta repositoriossasi ja työkalualustoillasi, joissa määrittelet roolit ulkoisille peliohjelmoijille, työkaluinsinööreille, taiteilijoille, laadunvarmistustestaajille tai rakennusinsinööreille, jotka kukin on sidottu määriteltyyn joukkoon depotteja, haaroja, projekteja ja ongelmajonoja.

Ensimmäinen periaate on vähiten oikeuksia: älä anna ulkoisille kehittäjille enempää käyttöoikeuksia kuin he todella tarvitsevat, ja älä anna pidemmäksi aikaa kuin he todella tarvitsevat. Käytännössä tämä alkaa roolipohjaisella käyttöoikeuksien hallinnalla repositoriossasi ja työkalualustoillasi. Määrität roolit ulkoisille peliohjelmoijille, työkaluinsinööreille, taiteilijoille, laadunvarmistustestaajille tai rakennusinsinööreille, ja jokainen niistä on sidottu määriteltyyn joukkoon depotteja, haaroja, projekteja ja ongelmajonoja.

Siitä eteenpäin suunnittelet tietovarastosi ja ympäristösi näiden roolien mukaisesti. Arkaluontoisten komponenttien, kuten huijauksenestomoduulien, allekirjoitusavainten tai alustaintegraatiokerrosten, tulisi sijaita rajoitetuilla alueilla, joihin pääsy on rajoitettu pienille, luotettaville sisäisille ryhmille. Jaettuja pelilogiikka- tai sisältöalueita voidaan paljastaa laajemmin kumppaneille. Haarojen suojaussäännöt voivat estää suorat lähetykset pää- tai julkaisuhaaroihin ja vaatia sen sijaan yhdistämispyyntöjä, koodin tarkistusta ja onnistuneita automatisoituja tarkistuksia.

Ympäristöjen erottelu on aivan yhtä tärkeää. Ulkoisten kumppaneiden tulisi normaalisti työskennellä kehitys- tai erillisissä testiympäristöissä, ei tuotannossa. Verkon segmentointi, erilliset tunnistetiedot ja erilliset salaisuudet vähentävät mahdollisuutta, että yhden alueen tietomurrot leviävät muille. Pilvipalvelussa isännöityjen resurssien tai työkalujen osalta voit käyttää erillisiä tilejä tai resurssiryhmiä kumppanityöskentelyyn, ja niiden roolit ja lokitiedot on huolellisesti määritelty, jotta voidaan osoittaa, miten näitä alueita käytetään.

Ratkaisevasti näiden kontrollien ympärille rakennetaan projektiin liittymisen, siirtymisen ja poistumisen prosessit. Kun joku toimittajalla liittyy projektiin tai poistuu siitä, käyttöoikeuksien myöntämiselle ja poistamiselle tulee olla selkeä polku hyväksyntöineen ja tietueineen. Ilman sitä jopa paras tekninen suunnittelu kerää vanhentuneita ja riskialttiita tilejä, joita on vaikea selittää tarkastuksen aikana.

CI/CD:n ja automaation käyttö A.8.30:n käytännön valvomiseksi

CI/CD-putket ovat tehokas liittolainen A.8.30:lle, koska ne voivat soveltaa samoja tarkistuksia jokaiseen muutokseen riippumatta siitä, kuka sen kirjoitti. Kun nämä putket valvovat testaus-, tarkistus- ja allekirjoitussääntöjä, voit todistaa, että ulkoistettu koodi, resurssit ja konfiguraatio noudattavat samaa laatu- ja tietoturvapolkua kuin sisäinen työ. Nykyaikaiset putket ovat tehokkaita juuri siksi, että niitä ei kiinnosta commitin alkuperä; niitä kiinnostaa vain, läpäiseekö se asettamasi rajat, joten jokainen koontiversioihisi päätyvä lisäys on läpäissyt johdonmukaiset laatu- ja tietoturvatarkistukset, jotka on linjattu tietoturvanhallintajärjestelmäsi kanssa.

Nykyaikaiset putkistot ovat tehokkaita, koska niitä ei kiinnosta commitin alkuperä; niitä kiinnostaa vain, läpäiseekö se asettamasi rajat. Tavoitteena on, että jokainen build-versioon päätyvä lisäys on läpäissyt johdonmukaiset laatu- ja tietoturvatarkastukset tietoturvanhallintajärjestelmäsi (ISMS) mukaisesti.

Tyypillisiä toimenpiteitä ovat vaatimus, että kaikki kumppaneiden tekemät muutokset tehdään pull- tai merge-pyyntöjen kautta, ei koskaan suorien push-pyyntöjen kautta. Tällaiset pyynnöt on tarkistettava ja hyväksyttävä jonkun asianmukaisen vallan omaavan henkilön toimesta – usein kriittisten komponenttien sisäisen ylläpitäjän. Tämän jälkeen jokaiselle pyynnölle suoritetaan automaattisia tarkistuksia: yksikkötestejä, integraatiotestejä, staattisia analyysejä, riippuvuushaavoittuvuuksien tarkistuksia, tyylitarkistimia ja kaikkia mukautettuja tietoturvatestejä, joihin luotat pelissäsi.

Koontiversioiden osalta voit vaatia, että vain oma hallinnoimasi CI-infrastruktuuri tuottaa testaukseen tai tuotantoon meneviä artefakteja, jotka on allekirjoitettu ja jäljitettävissä tiettyihin commit- ja yhdistämispyyntöihin. Kumppanit voivat ajaa omia koontiversioitaan paikallista testausta varten, mutta vain omat tuotantoputkesi tuottavat versioita, joita jaetaan laajemmin pelaajille, julkaisijoille tai alustanhaltijoille.

Salaisuuksien hallinta ja oikea-aikainen käyttöoikeus täydentävät tätä. Sen sijaan, että salaisuudet kypsennettäisiin kokoonpanotiedostoihin, jotka kumppanit voivat nähdä, tallennat ne keskitettyyn holviin ja lisäät ne prosesseihisi tai ympäristöihisi suorituksen aikana. Tehtävissä, joissa kumppanit todella tarvitsevat suoran pääsyn arkaluonteisiin järjestelmiin, voit tarjota määräaikaisia tunnistetietoja tai hyväksyntään perustuvaa käyttöoikeuden korottamista määräämättömän pysyvän käyttöoikeuden sijaan.

Hyvin toteutettuina nämä toimenpiteet täyttävät useita ISO 27001 -standardin odotuksia samanaikaisesti: turvallinen kehitys, hallitut muutokset, jäljitettävyys ja johdonmukaisuus sisäisen ja ulkoisen työn välillä. Ne myös sujuvoittavat yhteistyötä, koska kehittäjät – missä tahansa he istuvatkin – työskentelevät selkeiden haarautumismallien, tarkistussääntöjen ja automatisoitujen työkalujen palautteen kanssa. Tämä puolestaan vähentää kitkaa, kun myöhemmin on osoitettava vaatimustenmukaisuus tilintarkastajalle tai vastattava julkaisijan teknisiin due diligence -kysymyksiin.

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

Varaa esittelysi

Jatkuva varmistus: kumppaneiden seuranta A.8.30:n ja A.5.19–A.5.22:n mukaisesti

ISO 27001 -standardi olettaa, että toimittajariski muuttuu ajan myötä, eikä A.8.30 ole poikkeus. Jatkuva varmennus osoittaa, että teet enemmän kuin vain kirjoitat vahvoja sopimuksia – itse asiassa seuraat ulkoistetun kehityksen käyttäytymistä ja mukaudut, kun todellisuus poikkeaa suunnitelmista, sen sijaan, että odottaisit seuraavaa suurta tapahtumaa tai sertifiointisykliä.

Vahvatkin sopimukset ja kontrollit ovat vain hetkiä aikomuksesta. A.8.30 ja toimittajien kontrollit olettavat, että suhteet ja riskit kehittyvät ajan myötä. Jatkuva varmennus on taso, joka pitää ymmärryksesi ajan tasalla ja osoittaa, että olet tarkkaavainen tarkastusten välillä, etkä vasta sopimuksen alussa tai silloin, kun kustantaja esittää kiusallisia kysymyksiä.

Oikean mittaisen tarkastelu- ja seurantarytmin luominen

Oikean kokoisissa arvioinneissa yhdistyvät säännölliset tarkastukset jatkuvaan telemetriaan, jotta näet, täyttävätkö kumppanit edelleen odotuksesi. A.5.19–A.5.22 antavat kehyksen, ja toimittajatasosi auttavat sinua valitsemaan oikean syvyyden ja tiheyden kullekin kumppanille, jotta et rasita tuottajia tai tietoturvatiimejä tarpeettomalla paperityöllä. Jatkuva varmennus alkaa siitä, että päätät, kuinka usein kutakin kumppania tarkastellaan uudelleen ja mitä tarkastellaan. Korkean riskin kumppanit – joilla on syväkoodi ja pääsy live-ops-ympäristöön – saattavat oikeuttaa vuosittaiset tai jopa useammin suoritettavat arvioinnit, kun taas matalamman riskin kumppanit tarvitsevat vain kevyen tarkastuksen muutaman vuoden välein, ellei heidän ympäristössään tai peleissäsi tapahdu merkittäviä muutoksia.

Arviointi yhdistää yleensä useita elementtejä. Voit lähettää strukturoidun tietoturvakyselyn varmistaaksesi, että keskeiset käytännöt, tekniset valvonnat ja sertifioinnit ovat edelleen voimassa. Voit pyytää todisteita, kuten kuvakaappauksia kokoonpanoista, yhteenvetoja viimeaikaisista penetraatiotesteistä tai raportteja ratkaistuista haavoittuvuuksista. Joillekin kumppaneille voit suorittaa tai teettää omia arviointeja. Toisille luotat enemmän todentamiseen ja operatiivisiin signaaleihin.

Näiden virallisten tarkastuspisteiden lisäksi operatiivisen telemetriasi tulisi hyödyntää kokonaiskuvaa. Keskitetty lokitietojen kerääminen tietovaraston toiminnasta, rakennus- ja käyttöönottoputkista, ympäristön käyttöoikeuksista ja hallinnollisista toimista antaa sinulle mahdollisuuden nähdä, miten kumppanitilit toimivat käytännössä. Epätavalliset mallit – kuten suuret käyttöoikeuspurkaukset odottamattomista sijainneista, työajan ulkopuolella tapahtuvat käyttöönotot tai usein epäonnistuneet kirjautumiset – voivat käynnistää kohdennettuja keskusteluja tai perusteellisempia tarkistuksia.

Kun tarkasteluissa tai seurannassa ilmenee ongelmia, ne kirjataan toimittajan riskirekisteriin päätösten ja toimenpiteiden ohella. Tämän rekisterin avulla voit myöhemmin näyttää tilintarkastajalle osoittaaksesi, että toimittajan riskit, mukaan lukien ulkoistettu kehitys, tunnistetaan, seurataan ja käsitellään – niitä ei vain huomioida kerran ja unohdeta. Työkalut, kuten ISMS.online, voivat auttaa pitämään rekisterin ajan tasalla ja linkittämään jokaisen riskin kontrolleihin ja näyttöön.

Kumppaneiden ottaminen osaksi kehitysprosessiasi

A.8.30 toimii parhaiten, kun kumppanit näkevät turvallisuuden jaettuna vastuuna, eivät auditointivelvollisuutena. Parannusprosessin rakentaminen keskeisten toimittajien kanssa vahvistaa toimitusketjuasi ja antaa sinulle uskottavia tarinoita yhteisestä edistymisestä, kun auditoijat, julkaisijat tai alustan omistajat alkavat esittää vaikeita kysymyksiä ulkoistetun työn hallinnasta. Jatkuva varmennus on tehokkainta, kun se ei ole vain jotain, mitä teet kumppaneille, vaan jotain, mitä teet heidän kanssaan. Tämä edellyttää selkeää viestintää, oikeasuhtaisia odotuksia ja halukkuutta jakaa oppeja molempiin suuntiin.

Tärkeiden kumppaneiden kanssa voi olla hyödyllistä pitää säännöllisiä yhteisiä kokouksia, joissa tarkastellaan turvallisuuspoikkeamia, läheltä piti -tilanteita tai havaintoja yhdistetyissä toiminnoissanne. Näissä ei tarvitse nimetä ja häpäistä; tavoitteena on havaita säännönmukaisuuksia ja sopia käytännön parannuksista. Saatat esimerkiksi huomata, että useilla kumppaneilla on vaikeuksia korjauspäivitysten ajantasaisuuden kanssa rakennuskoneissa tai että ilmoitukset poikkeuksista saapuvat usein liian myöhään omalla aikavyöhykkeellänne, jotta voisitte toimia nopeasti.

Kohdennettu koulutus voi tukea tätä. Lyhyt ja kohdennettu ohjaus aiheista, kuten tietovarastojen turvallisesta käytöstä, virheenkorjausdatan käsittelystä tai turvallisesta etätestauksesta, voi nostaa perustasoa ilman, että vaaditaan täysimittaisia tietoisuusohjelmia. Kun oma tietoturvanhallintajärjestelmäsi kehittyy – esimerkiksi ottamalla käyttöön uuden salasanakäytännön tai turvallisen koodausstandardin – voit antaa kumppaneille yksinkertaisia ja toimintakelpoisia yhteenvetoja sen sijaan, että odotat heidän tulkitsevan sisäisiä asiakirjoja.

Ajan myötä tällainen yhteistyö parantaa paitsi omaa tilannettasi myös toimitusketjusi tilannetta. ISO 27001 -standardin osalta se antaa uskottavan kuvan siitä, että A.8.30 ei ole kertaluonteinen vaatimustenmukaisuustehtävä, vaan osa kehitysekosysteemisi toimintaa. Peliesi osalta se vähentää todennäköisyyttä, että ketjun heikoin lenkki on se, jolla on eniten merkitystä, kun uusi kausi käynnistyy tai suuri alustakampanja julkaistaan.

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

ISMS.online auttaa muuttamaan ulkoistetun kehitystyön hajanaisista dokumenteista ja postilaatikoista yhdeksi auditoitavaksi järjestelmäksi, johon studiosi voi luottaa. Tämä helpottaa ISO 27001 A.8.30 -standardin johdonmukaista soveltamista kaikkiin yhteiskehitys-, laadunvarmistus-, taide- ja live-ops-kumppaneihin sen sijaan, että yksittäisten tuottajien odotettaisiin muistavan jokaisen vaiheen itse, kun määräajat ovat tiukkoja. Jäsennelty lähestymistapa ulkoistettuun kehitykseen on paljon helpompi ylläpitää, kun se sijaitsee ISO 27001 -standardia varten rakennetussa järjestelmässä sen sijaan, että se olisi sekaisin dokumenteista ja laskentataulukoista. Koska keskitetty paikka ulkoistetun kehityksen viitekehyksen määrittelemiseen, riskien ja kontrollien kartoittamiseen A.8.30:n ja toimittajien kontrollien mukaisesti sekä todellisen näytön liittämiseen jokaiseen suhteeseen tekee paljon yksinkertaisemman seurata, kuka tekee mitä peleillesi, millä säännöillä ja millä tarkistuksilla.

Ulkoistetun kehityksen jäsenneltyä lähestymistapaa on paljon helpompi ylläpitää, kun se sijaitsee ISO 27001 -standardin mukaisesti rakennetussa järjestelmässä kuin dokumenttien ja laskentataulukoiden sekamelskassa. ISMS.online tarjoaa sinulle keskitetyn paikan ulkoistetun kehityksen viitekehyksen määrittämiseen, riskien ja kontrollien kartoittamiseen A.8.30:n ja toimittajien kontrollien mukaisesti sekä todellisten todisteiden liittämiseen jokaiseen suhteeseen. Tämä tekee paljon yksinkertaisemmaksi seurata, kuka tekee mitä peleillesi, millä säännöillä ja millä tarkastuksilla.

Kun käytät ISMS.online-järjestelmää, tuotanto-, teknologia- ja vaatimustenmukaisuustiimit työskentelevät saman totuuden lähteen pohjalta. Toimittajien perehdytystehtävistä, due diligence -kyselyistä, sopimusviitteistä, käyttöoikeustarkastusten muistutuksista ja toimittajien tarkastussykleistä tulee vakiotyönkulkuja ad hoc -projektien sijaan. Tämä auttaa ISO 27001 -vaatimuksia sulautumaan jokapäiväiseen projektinhallintaan sen sijaan, että ne tuntuisivat erilliseltä vaatimustenmukaisuusprosessilta, johon kenelläkään ei ole aikaa.

Kohdennettu pilottihanke on usein käytännöllinen seuraava askel. Valitse yksi tai kaksi korkean riskin kumppania tai lippulaivanimike ja käytä ISMS.online-palvelua mallintaaksesi koko ulkoistetun kehityksen elinkaaren kyseiselle portfoliosi osalle. Kun rakennat riskinarviointeja, sopimuskartoituksia, käyttöoikeustietueita ja tarkistuslokeja, kokoat nopeasti näyttöpaketin, joka on suoraan yhteydessä A.8.30:een. Saat myös konkreettisen ennen ja jälkeen -tarinan, jonka voit jakaa johdon, julkaisijoiden ja alustakumppaneiden kanssa siitä, miten olet vahvistanut ulkoistettua kehitystäsi.

Jos olet valmis siirtymään hajanaisista salassapitosopimuksista ja yksilöiden sankarillisesta ponnistelusta yhtenäiseen ja auditoitavaan järjestelmään ulkoistetun kehityksen turvaamiseksi, kannattaa tutustua siihen, miten ISMS.online käsittelee reaalimaailman skenaarioitasi. Live-läpikäynti voi näyttää, kuinka juuri tutkimaasi elinkaarta, riskikartoitusta, sopimusvelvoitteita ja toimittajien arviointeja voidaan hallita yhdessä paikassa pelistudioiden todellisessa tahdissa.

Miten kohdennettu pilottihanke rakentaa A.8.30-todisteita

Keskitetyn pilottiprojektin avulla voit todistaa ulkoistetun kehityskehyksesi toimivuuden oikeasti ilman, että sinun tarvitsee migroida kaikkia kumppaneita kerralla. Keskittymällä yhteen nimikkeeseen tai pieneen ryhmään toimittajia, luot konkreettista näyttöä A.8.30:lle ja pidät muutokset hallittavissa kiireisille tiimeille.

Käytännössä valitset vaikuttavan skenaarion – suuren yhteiskehitysstudion, keskeisen live-ops-toimittajan tai porttauskumppanin, joka käsittelee koontiversioita ja allekirjoitusavaimia. Sitten mallinnat koko elinkaaren ISMS.online-palvelussa: sisääntulopäätökset, due diligence -tarkastusten tulokset, sopimusvelvoitteet, käyttöoikeuksien hyväksynnät, prosessien hallinnan ja toimittajien tarkastukset. Jokainen vaihe tuottaa artefakteja, joita voit esitellä tilintarkastajille ja julkaisijoille: riskinarviointeja, päätöksiä, työnkulkuja ja lokeja, jotka on sidottu tiettyihin kontrolleihin.

Koska pilottihanke on kapea-alainen, tiimit voivat antaa hyödyllistä palautetta ja voit tarkentaa malleja, työnkulkuja ja omistajuutta ennen laajempaa käyttöönottoa. Kun pilottihanke on valmis, sinulla on sekä toistettavissa oleva malli että portfolio tosielämän esimerkkejä, jotka osoittavat, miten ulkoistettu kehitys suojataan käytännössä, eikä vain käytäntöasiakirjoissa.

Mitä odottaa ISMS.online-demoilta

ISMS.online-demossa näet opastetusti, miltä nykyiset ulkoistetut kehityskäytäntösi voisivat näyttää ISO 27001 -standardin mukaisessa järjestelmässä. Näet, kuinka alusta voi peilata studiorakennettasi ja samalla tarjota sinulle A.8.30-standardin ja toimittajien valvontamekanismien edellyttämää kurinalaisuutta ja näkyvyyttä.

Yleensä demossa käydään läpi, miten määritellään ulkoistetun kehityksen käytännöt, kartoitetaan kumppanit ja riskit, yhdenmukaistetaan sopimukset kontrollien kanssa, kirjataan käyttöoikeuspäätökset ja määritetään toimittajien arviointisyklit. Näet, kuinka tuottajat, tekniset johtajat ja vaatimustenmukaisuudesta vastaavat henkilöt voivat työskennellä samassa ympäristössä käyttäen jaettuja malleja sen sijaan, että rakentaisivat omia työkalujaan tyhjästä. Voit tuoda esimerkkejä – kuten meneillään olevan yhteiskehityshankkeen tai tulevan portin – ja tutkia, miten ne sopisivat alustalle.

Valitse ISMS.online, kun haluat ulkoistetun kehitystyön tuntuvan järjestelmälliseltä, auditoitavalta ja ISO 27001 -standardin mukaiselta hidastamatta tuotantoa äärimmilleen. Jos arvostat selkeitä työnkulkuja, jaettua omistajuutta ja kestävää näyttöä, tiimimme on valmis auttamaan sinua selvittämään, miltä se voisi näyttää studiollesi live-sessiossa, joka on rakennettu oikeiden nimikkeidesi ja kumppaneidesi ympärille.

Varaa demo

Usein Kysytyt Kysymykset

Miten pelistudion tulisi tulkita ISO 27001 A.8.30 -standardia, kun se käyttää ulkoisia kehityskumppaneita?

ISO 27001 A.8.30 -standardi edellyttää, että käsittelet ulkoistettua kehitystä ikään kuin se tapahtuisi studiosi sisällä, turvallisen ohjelmistokehityksen ja tietoturvallisuuden hallintajärjestelmän (SDLC) alaisena, ei hallitsemattomana "musta laatikkotoimittajan" toimintana. Käytännössä jokaisen kehitystyöntekijän, taidetoimittajan, porttaustiimin tai live-ops-kumppanin, joka käsittelee koodia, koontiversioita tai työkaluja, tulisi työskennellä sisäänrakennetun turvallisuuden sääntöjen mukaisesti, ja sinun tulisi pystyä osoittamaan, miten ohjaat, valvot ja tarkastelet heidän työtään koko elinkaaren ajan.

Mitä riskejä A.8.30 todellisuudessa pyrkii hallitsemaan?

A.8.30 on suunniteltu pysäyttämään hyvin yleisiä mutta vahingollisia vikoja:

Urakoitsijan kannettava tietokone, jolla on lähdekoodia tai virheenkorjaustyökaluja, varastetaan.
Halpatoimittaja käsittelee allekirjoitusavaimia tai koontitunnistetietoja väärin.
Pienestä toimittajasta tulee reitti koontijärjestelmääsi tai live-ops-työkaluihisi.

Ohjaus ohjaa sinua:

Päättää mitä ulkoistat, missä ympäristöissä ja millä riskillä.
Muuta nuo päätökset selkeät, kirjalliset, projektitason vaatimukset, ei pelkkää ”olla turvallinen” -muotoilua.
Upota vaatimukset osaksi hankinta, sopimukset, perehdytys, teknologian kehittämisen ja kehittämisen johto ja offboarding, ei pelkästään politiikkoja.
Pitää näyttö – sopimukset, käyttöoikeusmallit, tarkistustietueet, koontilokit – jotka osoittavat, miten säilytit hallinnan.

Jos voit valita minkä tahansa parin ja vastata esineillä kysymykseen ”mitä he rakentavat, mihin he voivat koskea ja mistä tiedämme, että he noudattivat sääntöjämme?”, olet paljon lähempänä sitä, mitä A.8.30 odottaa pelistudiolta.

Miten A.8.30 eroaa muista toimittajien valvontamenetelmistä?

Liitteet A.5.19–A.5.22 käsittelevät toimittajia yleisesti: valintaa, sopimuksia, toimitusketjun riskiä ja jatkuvaa seurantaa. Liite A.8.30 käsittelee asiaa tarkemmin. ulkoistettu ohjelmistokehitystyöStudion kannalta se tarkoittaa yleensä A.8.30:n sitomista seuraaviin:

A.5.19–A.5.22 toimittajien valintaa, sopimuksia ja arviointeja varten.
A.8.25–A.8.29 turvalliseen kehitykseen, testaukseen ja muutoshallintaan.
A.8.31 kehitys-, testaus- ja tuotantoympäristöjen eriyttämiseksi.

ISMS.online-palvelun käyttäminen toimittajien, riskien, tietoturvallisten kehityskäytäntöjen ja ympäristön hallinnan linkittämiseen osoittaa, että ulkoista työtä ohjaa sama ISMS kuin sisäisiä insinöörejä, eikä se sijaitse jaetulla levyllä tai jonkun postilaatikossa. Juuri tätä yhdistettyä kuvaa tilintarkastajat, alustanhaltijat ja yritysasiakkaat etsivät kysyessään, miten hallinnoit yhteiskehitystä ja toimittajia.

Miten sopimukset ja palvelutasosopimukset tulisi jäsentää, jotta ulkoistettu työ aidosti tukee ISO 27001 A.8.30 -standardia?

Saat eniten irti A.8.30:stä, jos sopimuksiisi sisältyy turvallisuusvelvoitteita eksplisiittinen, johdonmukainen ja testattava, sen sijaan, että piilottaisit ne yleisiin vakiomuotoisiin sopimuksiin. Yksinkertainen sopimuspino toimii hyvin useimmille studioille: pääpalvelusopimus, salassapitosopimus, työsuunnitelma ja lyhyt tietoturva-/palvelutasosopimusaikataulu, joka viittaa tietoturvanhallintajärjestelmääsi ja suojauskehitysodotuksiin.

Mikä rooli kullakin sopimuskerroksella on A.8.30:n kannalta?

Jokainen kerros tekee ohjauksen eri osista todellisia:

Pääpalvelusopimus (MSA): Lukitsee IP-omistuksen, korkean luottamuksellisuuden, yleiset turvallisuusvelvollisuudet ja sinun oikeus tarkastaa tai auditoida.
NDA: Selventää, mikä on luottamuksellista – moottorin haarukat, sisäiset työkalut, varhaiset kokoonpanot, telemetria – ja miten se on suojattava.
Työselvitys (SoW): Määrittää, mitä moduuleja, repositorioita, työkaluja ja ympäristöjä kumppani voi käyttää projektissa, ja missä heidän vastuualueensa alkavat ja päättyvät.
Tietoturva- ja palvelutasosopimuksen aikataulu: Asettaa käytännön vaatimukset: nimetyt tilit ja monityhjennykset (MFA), koodin tarkistussäännöt, turvalliset koontisijainnit, häiriöiden ilmoitusajat, käytöstäpoistovaiheet ja mahdolliset erityiset vaatimustenmukaisuusvelvoitteet.

ISO 27001 -standardin näkökulmasta todellinen kysymys ei ole "onko teillä sopimuksia?", vaan "onko sopimuksenne vastaavat tietoturvanhallintakäytäntöjäsi"... ja voitko todistaa, että käytit niitä tämän kumppanin kanssa tässä projektissa?" Vakiomuotoisten tietoturva-aikataulujen sidonta suojattuun SDLC:hen ja tallentaminen ISMS.online-palveluun kutakin toimittajaa kohden tekee tämän osoittamisen erittäin helpoksi.

Mitkä lausekkeet ovat pelistudioille tärkeimpiä?

Koska pelit yhdistävät koodia, sisältöä ja aina päällä olevia palveluita, jotkin lausekkeet ansaitsevat erityistä huomiota:

IP ja työkalut: Selkeä omistajuus ja lisensointi pelien immateriaalioikeuksille, pelimoottorien haaroille, koontijärjestelmille ja kumppaneiden kehittämille tai käyttämille omille työkaluille.
Kulunvalvonta: Vaatimukset nimetyt, todennetut tilit MFA:lla ja lokikirjauksella; nimenomainen kielto jaetuille kirjautumisille repositorioihin, hallintapaneeleihin tai live-ops-konsoleihin.
Turvallinen kehitysprosessi: Velvollisuus noudattaa omaa suojattu SDLC – mukaan lukien vertaisarviointi, riippuvuuksien hallinta, haavoittuvuuksien käsittely, CI/CD-tiedostojen käyttö ja muutostenhallinta.
Tapahtumaraportointi: Käynnistimet, jotka kattavat lähdekoodivuodot, koontiversioiden peukaloinnin, vaarantuneet tilit ja live-ops-työkalujen väärinkäytön, eivätkä pelkästään henkilötietojen tietoturvaloukkaukset.
Tietojenkäsittelyä koskevat ehdot: Kieli on yhdenmukainen GDPR:n tai muiden tietosuojalakien kanssa, ja siinä ilmoitetaan, että kumppanit voivat nähdä pelaaja- tai henkilökuntatietoja (esimerkiksi kaatumisraporttien sisällön tai tukipyyntöjä).

Voit pitää tämän toimivana standardoimalla pienen joukon tietoturvaliitteitä yleisille toimittajatyypeille (yhteiskehitys, porttaukset, laadunvarmistus, grafiikka, live-ops). Kun nämä mallit ja allekirjoitetut sopimukset ovat ISMS.online-palvelussa linkitettyinä toimittajatietoihin ja niihin liittyviin riskeihin, kysymykseen "miten sovelsitte A.8.30:tä tässä?" vastaaminen on nopea haku eikä vanhojen kansioiden läpikäymistä.

Millä teknisillä valvontamekanismeilla on eniten merkitystä, kun ulkoiset tiimit käyttävät repositorioitasi, ympäristöjäsi ja CI/CD-tiedostojasi?

Tekniset suojausmenetelmät suojaavat sinua parhaiten ne, jotka rajoittaa ja tarkkailla ulkoiset kehittäjät automaattisesti sen sijaan, että kaikki muistaisivat säännöt. Useimmissa studioissa tämä johtuu tiukasta identiteetin ja käyttöoikeuksien hallinnasta repositorioissa ja työkaluissa, ympäristöjen erottelusta sekä CI/CD-putkista, jotka käsittelevät ulkoista koodia täsmälleen kuten sisäistä koodia.

Miten ulkoistettujen kehittäjien käyttöoikeudet tulisi suunnitella?

Käytännöllinen malli on suunnitella pääsy ympärille hyvin määritellyt roolit ja vähiten etuoikeuksia:

Määrittele pieni määrä ulkoisia rooleja, kuten *pelinkehityksen yhteiskehittäjä*, *porttausinsinööri*, *ulkoinen laadunvarmistus* ja *ulkoinen työkalukehittäjä*.
Yhdistä jokainen rooli tiettyihin repositorioihin, haaroihin, koontisäiliöihin, projektitauluihin ja työkaluihin – eikä mihinkään muuhun.
Käytä sivukonttorin suojausta ulkoisten tilien suojaamiseksi ei voi työntää suoraan pää- tai julkaisutoimipisteisiin; vaativat yhdistämis-/pull-pyyntöjä ja sisäistä tarkistusta arkaluontoisilla alueilla, kuten huijauksen estämisessä, oikeuksien myöntämisjärjestelmissä, virtuaalitaloudessa, matchmakingissa ja alustaintegraatiossa.
Pidä ulkoiset identiteetit poissa tuotanto- ja live-ops-konsoleista; niiden tulisi toimia erillisissä kehitys-/testausympäristöissä, joissa on erilliset tunnistetiedot, segmentoidut verkot ja selkeä valvonta.

Jos kumppanitiliä käytetään väärin, tämä eristys pitää räjähdyssäteen pienenä ja helposti selitettävissä tilintarkastajille ja alustakumppaneille. Se antaa myös suoraa näyttöä siitä, miten sovelsit A.8.30-standardia, kun joku kysyy, miten ulkoista toimittajaa estetään "vahingossa" julkaisemasta sitä suoraan.

Kuinka CI/CD ja automaatio voivat kantaa suurimman osan tietoturvakuormasta?

CI/CD-työprosessisi ovat paikka, jossa voit integroida A.8.30-odotukset jokapäiväiseen työhön:

Suorita yksikkötestejä, koodityylitarkistuksia, staattista analyysia ja riippuvuustarkistuksia jokainen yhdistämispyyntöriippumatta siitä, kuka koodin kirjoitti.
Salli toimitettavien tai allekirjoitettujen rakennusten tuottaminen vain seuraavilta tahoilta: hallitsemasi juoksijat suojatuista haaroista; älä koskaan luota paikallisten kumppanien rakennuksiin minkään pelaajille tavoittavan asian suhteen.
Vaadi hyväksyntöjä tai lisätarkistuksia prosessissa korkean riskin komponenteille (esimerkiksi huijauksenesto, kaupankäynti, oikeutuslogiikka), joten niiden tarkistaminen on osa prosessia, ei pelkkä ohje.
Säilytä rakennuslokeja, esineiden historiaa ja ohjelmistojen osaluetteloita, jotta voit osoittaa ne joka tekee committeja ja riippuvuuksia meni rakennusprojektiin ja milloin.

Kun nämä prosessit ovat näkyviä, toistettavissa ja niihin on yhdistetty asiaankuuluvia ISO 27001 -standardin mukaisia kontrolleja ISMS.online-järjestelmässä, on paljon helpompi vakuuttaa tilintarkastajille, alustan haltijoille ja yritysjohtajille, että ulkoistettua kehitystä hallitaan samojen standardien mukaisesti kuin sisäistä työtä sen sijaan, että se olisi kiinteä sokea piste.

Miten studio voi arvioida ja valvoa ulkoistettujen kehityskumppaneiden tietoturvatilannetta ajan kuluessa, ei vain käyttöönottovaiheessa?

Yleensä saat parempia tuloksia yhdistämällä riskiperusteiset ennakkotarkastukset yksinkertaisella, aikataulutetulla arviointi- ja seurantasyklillä sen sijaan, että turvautuisit valtavaan kertaluonteiseen kyselyyn perehdytysvaiheessa. Vaikuttavat kumppanit saavat strukturoidumpaa huomiota, ja käytät omaa telemetriaa kertoaksesi, milloin tarvitaan lisätarkastelua.

Miten päätät, mitkä kumppanit tarvitsevat eniten huomiota?

Selkeä porrastettu malli pitää asiat hallittavissa:

Tier 1: Kumppanit, joilla on syvällinen pääsy pääkoodikantaasi, koontijärjestelmään, allekirjoitusavaimiin tai live-ops-työkaluihin – esimerkiksi yhteiskehitystalot, ohjelmistomoottoritoimittajat, huijauksenestopalvelut ja live-ops-alustat.
Tier 2: Kumppanit, joilla on kohtalainen pääsy, kuten porttausyritykset, työkalutoimittajat ja ulkoinen laadunvarmistus, jotka käyttävät sisäisiä koontiversioita, mutta eivät tuotantokonsoleita.
Tier 3: Kumppanit, joilla on minimaalinen tai ei lainkaan järjestelmän käyttöoikeuksia, kuten taidemyyjät, äänitysstudiot tai lokalisointipalveluntarjoajat, jotka työskentelevät vain vietyjen resurssien parissa.

Mitä syvällisemmin toimittaja voi perehtyä koodiin tai infrastruktuuriin, sitä useammin ja yksityiskohtaisemmin arviointien tulisi olla. Monet studiot pitävät vuosittaisia arviointeja tasolla 1, 18–24 kuukauden välein tasolla 2 ja uusimiseen perustuvia tarkastuksia tasolla 3 toimivana lähtökohtana, ja niitä voidaan mukauttaa, jos riski tai laajuus muuttuu.

Mitä jatkuvan arviointisyklin tulisi kattaa?

Ylemmän tason toimittajille toistettava arviointisykli voi sisältää seuraavat:

Vahvistus siitä, että heidän sertifioinnit, käytännöt ja tekniset valvontatoimet ovat edelleen olemassa ja kattavat edelleen työsi (esimerkiksi ISO 27001- tai SOC 2 -raportin laajuuden).
Lyhyt tarkastelu heidän puolellaan tapahtuvista merkittävistä muutoksista – uusista hosting-alueista, alihankkijoista, toimistoista, työkaluista – ja yksiselitteinen päätös siitä, ovatko nämä muutokset hyväksyttäviä.
Nopea tarkistus omat lokisi ja mittasi toimintaansa liittyvät: epätavallinen pääsy repositorioihin tai koontijärjestelmiin, toistuvat määritysongelmat, epäonnistuneet koontiversiot tai heidän tileihinsä liittyvät käytäntöpoikkeukset.
Tiivis kirjallinen yhteenveto, joka sisältää havainnot, päätökset, seurantatehtävät, vastuuhenkilöt ja tavoitepäivämäärät.

Tilintarkastajat haluavat nähdä, että näin tapahtuu. suunnitelman ja aikataulun mukaisesti, ei vain sen jälkeen, kun jokin on mennyt pieleen. Kun pidät toimittajarekisterisi, tasopäätökset, tarkastusmuistiinpanot ja seurantatodisteet yhdessä ISMS.online-palvelussa linkitettynä liitteen A toimittajan valvontaan ja erityisiin riskeihin, voit puhua ulkoistetun kehitystyön tilanteestasi paljon luottavaisemmin.

Mitkä yleiset ulkoistetun kehityksen virheet tekevät pelistudioille vaikutuksen, ja miten A.8.30 auttaa välttämään niitä?

Useimmat ongelmat johtuvat pikemminkin jokapäiväisistä huolimattomuudesta kuin kehittyneistä hyökkäyksistä: ulkoisista tileistä, joilla on enemmän käyttöoikeuksia kuin tarvitaan, "väliaikaisista" käyttöoikeuksista, joita ei koskaan poisteta, kriittisistä moduuleista, jotka on rakennettu hallitsemiesi prosessien ulkopuolella, tai kumppaneista, jotka käyttävät hallitsemattomia koneita varhaisiin koonteihin ja virheenkorjaustyökaluihin. Peleissä esimerkiksi huijauksenesto, oikeuksien ja identiteetin hallintajärjestelmät, matchmaking, telemetria ja allekirjoitusavaimet ovat erityisen arkaluontoisia, mutta niitä käsitellään usein kuin tavallista koodia.

Mitä heikkoja kohtia kannattaa seurata tarkasti?

Muutamia kaavoja esiintyy usein eri studioissa:

Freelancerit tai pientoimittajat jäivät paitsi repositoriosta, pilvisäilöstä tai järjestelmänvalvojan oikeuksista vielä kauan viimeisen tehtävän päättymisen jälkeen.
Yhteiskehitystiimit kääntävät tärkeitä moduuleja paikallisesti omalle laitteistolleen ohittaen koontitietojesi alkuperän, allekirjoittamisen ja skannauksen.
Laadunvarmistus- tai taidetoimittajat suorittavat sisäisiä koontiversioita henkilökohtaisilla tai jaetuilla laitteilla, jotka ovat selvästi tietoturvatasosi alapuolella.
Vanhat ”testausympäristöt”, debug-portaalit tai tallennussäilöjä, joihin kukaan ei tunne olevansa vastuussa, mutta joihin monet sisäiset ja ulkoiset ihmiset voivat silti päästä käsiksi.
Jaetut tunnistetiedot koontipalvelimille, hallintakonsoleille tai useiden kumppanityöntekijöiden käyttämille valvontatyökaluille.

Mikään näistä ei vaadi edistynyttä hyödyntämistä; ne lisäävät hiljaisesti altistumistasi, kunnes kadonnut laite, tietojenkalasteluhyökkäys tai virheellinen määritys muuttaa ne tietomurroksi.

Kuinka A.8.30:n käsitteleminen elinkaarena auttaa sinua paikkaamaan näitä aukkoja?

Jos käytät A.8.30:tä virallistamisen laukaisimena ulkoistetun kehityksen elinkaari, nämä heikot kohdat on helpompi havaita ja korjata. Yksinkertainen elinkaari voi sisältää:

Saanti ja riskinarviointi: Ennen käyttöönottoa päätä kumppanin taso, sallittu käyttöoikeus, sovellettavat standardit ja tarvittavat todisteet.
Vakiokäyttömallit: Käytä ennalta määritettyjä käyttöoikeuspohjia taso- ja roolikohtaisesti (esimerkiksi yhteiskehitys vs. laadunvarmistus vs. työkalutoimittaja) kertaluonteisten käyttöoikeuksien sijaan.
Perehdytyksen tarkistuslistat: Varmista, että tilit ovat olemassa, monitoiminen autentikointi on käytössä, koulutus on suoritettu, salassapitosopimukset on allekirjoitettu ja oikeat ympäristöt ovat valmiita ennen työn aloittamista.
Säännölliset tarkastelut: Suorita tason 1 ja 2 toimittajien osalta määrittämäsi seuranta- ja arviointisykli ja muuta käyttöoikeuksia, sopimuksia tai valvontaa, jos riskikuva muuttuu.
Poistumisvaiheet: Poista tilit ja avaimet, sulje VPN- ja työkalujen käyttöoikeudet, kierrätä jaettuja salaisuuksia ja arkistoi kumppanikohtaiset tiedot.

Kun tuo elinkaari kulkee ISMS.online-alustan läpi – toimittajat, riskit, projektit, tehtävät ja todisteet sidottuina yhteen – tuottajat, tietoturva ja johto näkevät kaikki saman kuvan siitä, "kuka tekee mitä, missä ja millä säännöillä". Se tarjoaa myös yksinkertaisen tavan vastata alustan haltijan, julkaisijan tai tilintarkastajan vaikeaan kysymykseen: "mikä estää ulkoistettua kehitystä olemasta heikoin lenkkisi?"

Miten ulkoistetut kehittäjät voivat hyödyntää suojattua SDLC:täsi hidastamatta julkaisuaikatauluja?

Kestävin ratkaisu on ulkoisten tiimien käyttäminen työskentele suojatun SDLC:n sisällä sen ympärillä, jossa on selkeät odotukset ja automaatio hoitaa suuren osan täytäntöönpanosta. Kun kumppanit noudattavat samoja haarautumisstrategioita, tarkistusvaatimuksia, testausodotuksia ja julkaisuportteja kuin sisäiset tiimit, peliä suojataan ilman, että tarvitsee ylläpitää erillistä, haurasta "toimittajaprosessia", johon kukaan ei oikein usko.

Millaista tulisi olla päivittäinen yhteistyö ulkoistettujen tiimien kanssa?

Terveessä ympäristössä ulkoistetut kehittäjät käyttäytyvät kuin hyvin integroituneet etätiimin jäsenet:

He suunnittelevat ja seuraavat työtä ongelmanseurantajärjestelmäsi, sprinttitaulusi ja etenemissuunnitelmasisisäisen henkilöstön rinnalla käyttäen yhteisiä prioriteetin ja tilan määritelmiä.
He kirjoittavat koodia sinulle standardit ja valmiin määritelmä, mukaan lukien kaikki tietoturvaan liittyvät kriteerit, kuten syötteen validointi, lokin lokitiedot, virheiden käsittely ja suorituskykybudjetit.
He lähettävät muutokset sinun kauttasi yhdistämispyyntö- tai pull-pyyntövirrat repositioihin, ja automaattiset testit ja tietoturvaskannaukset ovat oletusarvoisesti käynnissä.
He saavat saman palautteen – epäonnistuneet koonnit, staattisen analyysin varoitukset, koodikatselmusten kommentit, riippuvuusongelmat – riittävän ajoissa korjatakseen ongelmat ilman suuria haasteita, tuliharjoituksia tai viivästyksiä julkaisussa.

Jos kumppani pitää osan omasta työkaluketjustaan (esimerkiksi taiteen tai lokalisoinnin osalta), sovitte hallituista integraatiopisteistä: ehkä hyväksytte koodin vain pull-pyyntöjen kautta tai otatte vastaan vain resursseja, jotka läpäisevät omat validointiskriptisi. Tärkeää on, että Mikään ei saavuta päärepositorioitasi, koontijärjestelmiäsi tai live-ympäristöjäsi ilman suojatun SDLC:n kautta tapahtuvaa pääsyä..

Miten pidät nopeuden, turvallisuuden ja ISO 27001 -standardin yhdenmukaisina?

Suojaat toimitusnopeutta tekemällä SDLC:stäsi turvallisen ennustettavissa, näkyvä ja enimmäkseen automatisoitu:

Dokumentoi, miltä ”hyvä” näyttää ulkopuolisten osallistujien kannalta: haarautumismallit, tarkistussäännöt, vähimmäistestauskattavuus, arkaluonteisten komponenttien tietoturvatarkastukset ja selkeät ”pysäytä linja” -kriteerit, kun riski on korkea.
Koodita nuo odotukset sisään CI/CD-putket, projektipohjat ja tarkistuslistat, joten valvonta tulee työkaluista muistin sijaan.
Testaa yhdistettyä SDLC-hanketta yhden tai kahden strategisesti tärkeän kumppanin kanssa, tarkenna sitä heidän kokemustensa perusteella ja käytä sitten samaa mallia uusille toimittajille.

Kun SDLC-näkymäsi on dokumentoitu, yhdistetty liitteen A kontrolleihin ja sitä tukevat ISMS.online-järjestelmään tallennetut todisteet – commitit, katselmoinnit, kehitysprosessin ajot, hyväksynnät, julkaisut ja toimittajien toiminta – luot yhden kerroksen, joka palvelee kaikkia osapuolia: tuottajat saavat ennustettavuutta, tietoturva- ja yksityisyystiimit näkevät tehokkaan hallinnon, tilintarkastajat näkevät valvonnan ja jäljitettävyyden ja kumppanit näkevät selkeän ja toimivan tavan toimittaa sisältöä ja ominaisuuksia ajallaan. Jos haluat nähdä, miltä tämä voisi näyttää yhden käynnissä olevan projektisi ympäristössä, yksinkertaisen SDLC-näkymän luominen ISMS.online-järjestelmään yhdelle yhteiskehityssuhteelle riittää usein tuomaan omat tiimisi ja ulkoiset kumppanisi samalle sivulle.