Miksi pelikatkot ovat nyt strategisia riskejä
Pelikatkot ovat nykyään strategisia riskejä, koska ne leikkaavat tuloja, vahingoittavat pelaajien luottamusta ja rasittavat kaupallisia suhteita pitkään tapahtuman päättymisen jälkeen. Live-palvelumallissa julkaisupäivänä tapahtuvaa kaaosta tai alueellista vikaa pidetään johtotason vikana, ei pelkästään teknisenä häiriönä. Jos johdat alustasuunnittelua tai omistat suuren pelin käyttöajan, tiedät, että huono ilta voi hallita johdon keskusteluja kuukausien ajan, joten redundanssia on käsiteltävä liiketoiminnan kontrollina, ei valinnaisena lisänä.
Pelaajat muistavat yöt, jolloin he eivät pystyneet kirjautumaan sisään, elävämmin kuin kuukausien sujuvan käyttöajan.
Vakava käyttökatkos live-pelissä harvoin päättyy, kun statussivu muuttuu taas vihreäksi. Käytännössä se voi suistaa julkaisuja raiteiltaan, laukaista hyvityksiä, pilata alustasuhteita ja ruokkia yhteisönarratiiveja, jotka viipyvät kausien ajan. Laajamittaisia verkkopelejä pyörittävät tiimit ovat oppineet, että saatavuus on suunniteltava ja todistettava samalla kurinalaisella tavalla kuin muutkin tietoturvariskit, jotta hallituksille ja kumppaneille voidaan selittää, miten tätä strategista altistumista hallitaan.
Katkokset satuttavat enemmän kuin käyttöaikakaaviot osoittavat
Käyttökatkokset sattuvat enemmän kuin käyttöaikakaaviot osoittavat, koska ne yhdistävät menetettyä peliaikaa, epäonnistuneita maksuja, tuen ylikuormitusta ja pitkäaikaisia vahinkoja mielialalle ja kumppanuuksille. Kuudenkymmenen minuutin häiriö kojelaudassa voi tarkoittaa pilalle menneitä julkaisutapahtumia, epäonnistuneita markkinointikampanjoita ja pysyvää epäilystä pelin epäluotettavuudesta, vaikka taustalla oleva vika olisi ollut lyhytaikainen.
Tyypillinen verkkopelien ongelma on enemmän kuin "palvelu ei ole käytettävissä tunnin ajan". Yhtäaikaisten käyttäjien määrän äkillinen kasvu tai alueellinen pilviongelma hidastaa tai romahduttaa kapasiteettia; jonot kasvavat, ottelut eivät käynnisty, maksuyritykset aikakatkaistaan. Muutamassa minuutissa pelaajat purkavat tunteitaan sosiaalisen median kanavissa, tukimäärät nousevat, alustakumppanit pyytävät yksityiskohtaisia päivityksiä ja johtajat kyseenalaistavat, oliko julkaisu todella valmis.
Tuon julkisen metelin takana piilee kovia liiketoimintavaikutuksia: tulonmenetyksiä huippukulutusaikoina, hyvityksiä ja takaisinperintöjä, markkinointimenojen hukkaan heittämistä toimittamattomiin kampanjoihin ja yhteisön tunnelmia, joiden korjaaminen voi kestää vuosia. Lisensointisopimuksia solmineille studioille tai esports-ohjelmille toistuva epävakaus voi uhata sopimuksia tai turnaussijoituksia. Kun suunnittelet redundanssia, suojaat kaikkea tätä, etkä vain prosenttiosuutta käyttöaikakaaviossa, ja vähennät saatavuusriskiä, jota hallitukset seuraavat yhä enemmän muiden strategisten riskien ohella.
Miksi nettipelit ovat ainutlaatuisen alttiita
Verkkopelit ovat erityisen alttiita saatavuushäiriöille, koska ne ovat viiveherkkiä, erittäin piikikkäitä ja tiiviisti integroituneita ulkoisiin palveluihin. Jopa osittainen heikkeneminen näyttää pelaajille "rikkinäiseltä verkkokoodilta", ja kausiluonteiset tai tapahtumavetoiset piikit saapuvat nopeammin kuin perinteiset kapasiteettisuunnittelusyklit pystyvät käsittelemään.
Ne yhdistävät useita ominaisuuksia, jotka vahvistavat katkosten vaikutusta. Ne ovat viiveherkkiä, joten pienetkin heikkenemiset tuntuvat pelaajista epäonnistumiselta. Ne keskittävät kysynnän julkaisujen, kausien ja live-tapahtumien ohjaamiin huippuihin. Ne sisältävät usein pysyviä maailmoja ja pelin sisäisiä talouksia, joissa palautukset tai epäjohdonmukainen tila tuntuvat kadonneelta omaisuudelta tai epäreilulta edulta. Ne luottavat myös kolmansien osapuolten verkkoon: alustakauppoihin, identiteetin tarjoajiin, maksuyhdyskäytäviin, huijauksenestopalveluihin ja CDN-verkkoihin.
Tämä tarkoittaa, että saatavuuskerroksesi ei rajoitu siihen, ”pysyykö ydin-APImme toiminnassa”. Sinun on ymmärrettävä, miten epäonnistumiset matchmakingissa, tulostaulukoissa, sosiaalisissa ominaisuuksissa, ulkoasussa, tavaraluettelossa, live-op-työkaluissa ja ulkoisissa palveluntarjoajissa yhdistyvät näkyviksi ongelmiksi pelaajille ja kumppaneille. ISO 27001 tarjoaa sinulle kielen ja rakenteen näiden käsittelemiseksi tietoturva- ja jatkuvuusriskeinä, ei pelkästään operatiivisina häirintöinä, ja se auttaa sinua selittämään altistumisesi ja lieventämistoimesi johtajille heidän jo tunnistamillaan termeillä.
Katkokset osana riskirekisteriäsi
Palvelukatkokset kuuluvat riskirekisteriisi ensiluokkaisina tietoturvariskeinä, koska saatavuus on ISO 27001 -standardin ydintavoitteiden mukaista luottamuksellisuuden ja eheyden ohella. Kun määrität ydinpalveluiden menettämisen vaikutuksia tietyiksi ajanjaksoiksi, voit käsitellä katkosskenaarioita yhdessä tilien kaappausten, petosten ja tietomurtojen kanssa.
Kun rakennat tietoturvariskirekisteriäsi, on houkuttelevaa keskittyä luottamuksellisuuteen ja eheyteen: tilien kaappauksiin, tietomurtoihin, huijauksiin ja petoksiin. Saatavuus kuuluu myös ensiluokkaisena riskinä. Kohtien 6.1.2 ja 6.1.3 riskinarviointi- ja käsittelyprosessin avulla voit mitata todennuksen, matchmakingin, istuntojen, maksujen tai live-optioiden menettämisen vaikutuksia eri kestoille ja yhdistää ne liiketoimintavaikutusten analyyseihin ja palautumistavoitteisiin.
Kun käyttökatkokset ovat samassa riskijärjestelmässä kuin muut tietoturvauhkat, on luonnollista yhdistää redundanssipäätökset eksplisiittiseen riskienkäsittelyyn: mitkä palvelut oikeuttavat monialuesuunnittelun, mitkä voivat hyväksyä vain vyöhykkeellisen redundanssin ja missä suunnitellut heikentymistavat riittävät. Juuri tätä ajattelutapaa ISO 27001 odottaa, ja se on perusta muulle suunnittelutyölle. Se antaa myös tilintarkastajille ja ylemmän tason sidosryhmille selkeän ja vertailukelpoisen kuvan siitä, miten saatavuusriskejä käsitellään suhteessa muihin tietoturvauhkiin.
Varaa demoParhaan mahdollisen käyttöajan takaamisesta ISO 27001 -standardin mukaiseen vikasietoisuuteen
Siirtyminen "parhaan mahdollisen käyttöajan" sijaan ISO 27001 -standardin mukaiseen resilienssiin tarkoittaa sen osoittamista, että redundanssivalintasi ovat riskilähtöisiä, dokumentoituja ja säännöllisesti tarkistettuja. Jos studiollasi tai julkaisijallasi on ISO 27001 -standardi, sinun on osoitettava, että suunnittelu, toiminta ja parannukset noudattavat jäsenneltyä johtamisjärjestelmää, jolla on selkeät tavoitteet ja näyttö, eivätkä pelkästään hyviä aikomuksia.
ISO 27001:2022 -standardi ei määrää, kuinka monta aluetta sinun on käytettävä, mitä pilvipalveluita valita tai millainen tarkalleen ottaen arkkitehtuurin tulisi olla. Sen sijaan siinä pyydetään sinua käyttämään tietoturvallisuuden hallintajärjestelmää (ISMS), joka muuttaa saatavuuden ja jatkuvuuden hallituiksi ja auditoitaviksi prosesseiksi. Toimintaa koskeva kohta 8, jota tukevat liitteen A jatkuvuuteen keskittyvät kontrollit, muuttaa "pyrimme pysymään ajan tasalla" muotoon "voimme osoittaa, kuinka infrastruktuurimme ja prosessimme täyttävät määritellyt vikasietoisuustavoitteet".
Hallitukselle raportoiville tietoturvajohtajille tällä erolla on merkitystä. Tietoturvan hallintajärjestelmä (ISMS) tarjoaa sinulle perustellun tavan selittää, mitä resilienssipäätöksiä olet tehnyt, miksi teit ne ja miten tiedät niiden toimivan edelleen, sen sijaan, että luottaisit epävirallisiin vakuutteluihin siitä, että "tiimillä on tilanne hallinnassa".
Mitä ISO 27001 -standardi oikeasti välittää live-peleissä
Live-pelien osalta ISO 27001 -standardi käsittelee sitä, miten suunnittelet, käytät ja hallitset palveluita, jotka pitävät pelikokemuksen käynnissä: ei pelkästään sitä, ovatko ne teknisesti erittäin hyvin saatavilla, vaan myös sitä, ovatko riskit, vastuut ja kontrollit selkeästi määriteltyjä. Painopiste on toistettavissa prosesseissa, selkeissä kriteereissä ja todisteissa siitä, että niitä noudatetaan käytännössä.
Yleisellä tasolla kohta 8 edellyttää prosessien suunnittelua, käyttöä ja hallintaa siten, että ne täyttävät tietoturvavaatimuksesi. Pelialustan osalta tämä sisältää tavan, jolla rakennat, otat käyttöön ja suoritat todennuksen, matchmakingin, istunnot, tietovarastot, maksut ja taustatoimintojen työkalut. Se edellyttää, että määrittelet toiminnalliset kriteerit, noudatat dokumentoituja menettelyjä, hallitset muutoksia ja valvot ulkoistettuja prosesseja, kuten pilvi- ja CDN-palveluita.
Liitteessä A on sitten vertailujoukko riskin perusteella käyttöönotettavia suojausmenetelmiä. Useat niistä liittyvät suoraan redundanssiin ja kapasiteettiin:
- Kapasiteetin hallinta: resurssien käytön seuranta ja tulevien tarpeiden suunnittelu suorituskyvyn ja saatavuuden ylläpitämiseksi.
- Varmuuskopiointi: tietojen ja ohjelmistojen varmuuskopiointiprosessien määrittely, toteutus ja testaus.
- Käsittelytilojen redundanssi: redundanttien komponenttien ja polkujen käyttäminen käytettävyysvaatimusten täyttämiseksi.
- Tietoturva häiriöiden aikana: varmistamme, että ylläpidät hyväksyttävää suojausta häiriöiden ja haittatapahtumien aikana.
- Liiketoiminnan jatkuvuuden ICT-valmius: teknologian suunnittelu ja ylläpito siten, että se tukee liiketoiminnan jatkuvuustavoitteitasi.
Yhdessä nämä kontrollit tarjoavat sinulle jäsennellyn tavan perustella ja todistaa käyttöaikaa ja vikasietoisuutta koskevat päätöksesi. Standardi ei käske sinua "käyttämään aktiivista aktiivista kolmella alueella"; se kehottaa sinua osoittamaan, miten valitsemasi ratkaisut täyttävät nämä kontrollitavoitteet tunnistamiesi riskien osalta. Tämä puolestaan antaa tilintarkastajille ja riskivaliokunnille selkeän näkymän korkean tason vaatimuksista todellisiin järjestelmiin.
Olemassa olevan HA-työn muuttaminen ISO-todisteiksi
Olemassa olevan korkean käytettävyyden työn muuttaminen ISO 27001 -todisteiksi tarkoittaa jo olemassa olevan työn järjestämistä, ei rinnakkaisen "vaatimustenmukaisuusarkkitehtuurin" keksimistä. Mitä enemmän käsittelet eläviä artefakteja ensisijaisena todisteena, sitä vähemmän kitkaa aiheutat suunnittelutiimeille.
Useimmilla vakiintuneilla pelialustoilla on jo jonkinlainen korkea käytettävyys: useita käytettävyysvyöhykkeitä, automaattisesti skaalautuvia pooleja, kuntotarkastettuja kuormituksen tasaajia, säännöllisiä käyttöönottoja ja osittaisia DR-menettelyjä. Ongelmana ei ole se, etteikö näitä olisi olemassa, vaan se, että ne harvoin ilmaistaan tilintarkastajien, kumppaneiden tai oman riskikomitean helposti ymmärtämällä tavalla.
ISO-standardien mukainen lähestymistapa ei ala pyytämällä insinöörejä tuottamaan erillisiä ”vaatimustenmukaisuuskaavioita”. Sen sijaan käsittelet todellisia esineitä ensisijaisina todisteina: infrastruktuuria koodina, arkkitehtuurikaavioita, SLO-dokumentteja, DR-runbookeja, DR-testituloksia, tapahtumakatsauksia ja kapasiteettisuunnitelmia. Sitten järjestät ne tietoturvajärjestelmän sisälle, joka näyttää:
- Mitä ohjausta kukin artefakti tukee.
- Mihin palveluun tai riskiin se liittyy.
- Kuka on vastuussa sen ylläpidosta.
- Kuinka sitä pidetään ajan tasalla alustasi kehittyessä.
Seuraatpa tätä sitten sisäisissä työkaluissa tai erillisessä tietoturvallisuuden hallintajärjestelmässä, kuten ISMS.online, tavoite on sama: "parhaan mahdollisen käyttöajan" periaatteista tulee jäsennelty vikasietoisuusohjelma ilman, että työtä tekevät tiimit lamautuvat, ja auditoijat voivat nähdä, miten käytössä oleva suunnittelukäytäntösi täyttää ISO-vaatimukset.
"Rastiruutu"-yhteensopivuuden välttäminen
”Rastiruutu”-yhteensopivuuden välttäminen tarkoittaa sitä, että käytännöt, kaaviot ja runbookit kuvaavat, mitä tuotannossa todellisuudessa tapahtuu. Jos dokumentaatio poikkeaa todellisuudesta, käyttökatkos tai auditointi paljastaa puutteen hyvin nopeasti.
Toistuva epäonnistumistyyli on ISO 27001 -standardin käsittely paperityönä, joka elää erillään tuotantotodellisuudesta. Käytännöt väittävät, että kapasiteettia tarkastellaan säännöllisesti, mutta kukaan ei omista koontinäyttöjä; menettelytavat kuvaavat DR-testejä, mutta kukaan ei aikatauluta niitä; laajuuslausunnot puhuvat "pelipalveluista", mutta eivät luettele mistä niistä on kyse. Auditoinnissa tai vakavassa häiriössä tämä sanojen ja toiminnan välinen kuilu paljastuu nopeasti.
Vaihtoehtoisesti voit antaa oikeiden suunnittelu- ja operatiivisten käytäntöjesi ohjata tietoturvanhallintajärjestelmää (ISMS). Tämä tarkoittaa arkkitehtien, turvallisuus- ja turvallisuusasiantuntijoiden, operatiivisten asiantuntijoiden ja tuotetiimien osallistumista jatkuvuuden ja redundanssin määrittelyyn ja sen tallentamista prosesseihin, mittareihin ja kontrollien määrittelyyn. Kun alustaa ylläpitävät ihmiset tunnistavat itsensä ISO-tasosta, on paljon todennäköisempää, että se pysyy tarkkana ja hyödyllisenä. Se antaa myös tietoturva- ja vaatimustenmukaisuusjohtajille enemmän luottamusta siihen, että heidän hyväksymänsä kontrollit todella ovat olemassa päivittäisessä toiminnassa.
ISO 27001 helposti
81 %:n etumatka ensimmäisestä päivästä lähtien
Olemme tehneet kovan työn puolestasi ja antavat sinulle 81 % etumatkan kirjautuessasi sisään. Sinun tarvitsee vain täyttää tyhjät kohdat.
Suunnitteluperiaatteet erittäin käytettäville pelialustoille
Korkean käytettävyyden pelialustojen suunnitteluperiaatteet ovat yksinkertaisia, mutta niitä on vaikea soveltaa johdonmukaisesti kaikkiin palveluihin, joita pelaajat kohtaavat. Tavoitteena on poistaa yksittäisiä vikaantumiskohtia, antaa liikenteelle turvallinen paikka komponenttien rikkoutuessa ja reagoida riittävän nopeasti, jotta useimmat pelaajat tuskin huomaavat sitä.
Korkean käytettävyyden pelialustat rakennetaan muutaman yksinkertaisen periaatteen varaan, mutta niiden onnistunut toteuttaminen monimutkaisessa pinossa vaatii harkittua suunnittelua. Tavoitteena ei ole poistaa kaikkia vikoja, mikä on mahdotonta, vaan poistaa yksittäisiä vikakohtia, antaa liikenteelle turvallinen paikka, jos jokin hajoaa, ja havaita ja käsitellä ongelmat riittävän nopeasti, jotta pelaajiin ne tuskin vaikuttavat. Näiden periaatteiden selkeä määrittely antaa sinulle jotain, mitä voit testata, seurata ja selittää ei-teknisille sidosryhmille.
HA-periaatteiden kääntäminen pelikeskeisiksi SLO-tavoitteiksi
Yleisten korkean käytettävyyden periaatteiden kääntäminen pelikeskeisiksi palvelutasotavoitteiksi (SLO) pakottaa määrittelemään, miltä "riittävän hyvä" näyttää kunkin pelaajan näkyvän ominaisuuden osalta. Sen sijaan, että puhuttaisiin abstraktisti "viidestä yhdeksikosta", kuvataan, mitä onnistuminen ja epäonnistuminen tarkoittavat kirjautumisen, pelinhaun, istuntojen ja maksujen kannalta.
Klassisia korkean käytettävyyden periaatteita ovat: yksittäisten vikaantumiskohtien välttäminen, luotettavan vikasietoisuuden varmistaminen ja vikojen nopea havaitseminen. Jotta nämä toteutuisivat online-pelissä, ne ilmaistaan yksittäisten ominaisuuksien SLO-tavoitteina (SLO):
- Todennuksen tulisi onnistua tavoitelatenssin ja saatavuusprosentin sisällä, vaikka yksi identiteetintarjoaja ei olisi käytettävissä.
- Parinhaun tulisi ylläpitää hyväksyttäviä jonotusaikoja ja parin laatua, jopa alueellisten ongelmien tai osittaisen kaluston menetyksen aikana.
- Pelisessioiden tulisi jatkua tai yhdistyä uudelleen sujuvasti ohimenevistä yhteysongelmista ja jatkuvasta käyttöönotosta huolimatta.
- Maksujen tulee olla luotettavasti käsiteltyjä tai niiden tulee olla selvästi epäonnistuneita, ja niillä tulee olla vahvat takeet päällekkäisten tai kadonneiden veloitusten estämiseksi.
Yhdessä nämä SLO:t kuvaavat, miten toimijat kokevat alustan rasituksen alla. Jokaisen kohdalla kysytään sitten, mitä infrastruktuuria, redundanssia, telemetriaa ja operatiivisia käytäntöjä on oltava käytössä, jotta tavoite olisi realistinen. Tässä kohtaa ISO:n suunnittelua, valvontaa ja jatkuvuutta koskeva sanasto kohtaa alustasi ydinominaisuudet, ja tässä kohtaa voit osoittaa auditoijille, mitä mittareita käytät käytettävyyden hallintaan.
Vyöhyke- ja monialuesuunnittelun välillä valitseminen
Alueellisten ja monialueisten ratkaisujen välillä valitseminen on riski ja liiketoimintapäätös, ei pelkästään tekninen mieltymys. Jotkin palvelut oikeuttavat redundanssin vain alueen sisällä, kun taas toiset tarvitsevat alueiden välistä vikasietoisuutta tapahtumien, turnausten tai suurten lanseerausten suojaamiseksi.
Kaikki pelit tai palvelut eivät oikeuta täyttä usean alueen aktiivinen-aktiivinen suunnittelua. Yhden alueen sisäinen vyöhykkeellinen redundanssi voi riittää joillekin työkuormille, kun taas toiset vaativat alueiden välistä vikasietoisuutta turnausten tai suurten julkaisujen pitämiseksi toiminnassa alueellisten häiriöiden aikana.
Hyödyllinen lähestymistapa on luokitella palvelut kriittisyyden ja latenssiherkkyyden mukaan:
- Kova reaaliaikainen peliliikenne, kuten erilliset ottelupalvelimet, vaatii usein alueellista läsnäoloa pelaajien lähellä, nopeaa vikasietoisuutta kyseisellä alueella ja korkeimpien panosten peleissä mahdollisuutta siirtää ottelut tai jonot toiselle alueelle, jos jokin niistä häiriintyy.
- Ohjaustason palvelut, kuten matchmaking-orkestrointi, oikeudet ja inventaariot, saattavat sietää suurempia latensseja, mikä mahdollistaa joustavammat replikointistrategiat ja globaalit yhdenmukaisuusmallit.
- Tukipalvelut, kuten analytiikka tai jotkin taustatoiminnot, kestävät pidempiä käyttökatkoksia ja saattavat tarvita vain vankat varmuuskopiointi- ja palautusprosessit.
Yhdistämällä tämän luokittelun riski- ja liiketoimintavaikutusanalyyseihin voit päättää, milloin alueellinen redundanssi on riittävää ja milloin alueellinen resilienssi on välttämätöntä, ja dokumentoida tämän perustelun tietoturvanhallintajärjestelmässäsi. Tämä tekee myöhemmistä keskusteluista taloushallinnon, johdon ja tilintarkastajien kanssa suoraviivaisempia, koska voit osoittaa, miksi tietyt palvelut saavat kalliimpia resilienssikäsittelyjä.
Pelaajan matkan kartoittaminen epäonnistumistiloihin
Pelaajan matkan kartoittaminen vikatiloihin auttaa havaitsemaan hauraita kohtia, joita mikään arkkitehtuurikaavio ei ole luokitellut kriittisiksi. Käymällä läpi pelaajien kirjautumis-, ottelu-, peli- ja vuorovaikutustavat askel askeleelta voit suunnitella sulavaa hajoamista binäärisen "ylös tai alas" -käyttäytymisen sijaan.
Käytännöllinen tapa suunnitella saatavuus huomioon ottaen on käydä läpi tyypillinen pelaajapolku askel askeleelta – käynnistää peliohjelmisto, kirjautua sisään, yhdistää pelaaja, liittyä istuntoihin, ansaita palkintoja, käyttää rahaa – ja kysyä kolme kysymystä jokaisella askeleella:
- Mitä tapahtuu, jos tämän hypyn takana oleva palvelu epäonnistuu kokonaan?
- Mitä tapahtuu, jos se on hidas tai osittain heikentynyt?
- Miten haluamme pelaajakokemuksen toimivan kussakin tapauksessa?
Nämä kysymykset usein paljastavat piileviä riippuvuuksia ja yksittäisiä vikaantumiskohtia: yksi alueellinen ja paikallinen identiteetintarjoaja, keskitetty aula, hauras palkitsemispalvelu tai monoliittinen telemetriaputki. Ne tarjoavat myös luonnollisen rakenteen sujuvan heikkenemisen suunnitteluun: jonot selkeillä viesteillä, rajoitetut pelitilat, offline-edistymisen seuranta tai kosmeettisten ostosten väliaikainen poistaminen käytöstä.
Visuaalinen: pelaajan toiminnot palveluihin ja ohjaimiin yhdistävä kartta.
Kun tämä asiakaspolkuun perustuva näkymä on olemassa, voit liittää ISO 27001 -standardin mukaisia kontrolleja ja todisteita jokaiseen vaiheeseen: valvontaan, muutoshallintaan, varmuuskopiointiin, redundanssiin ja jatkuvuusmekanismeihin, kaikki muotoiltu ihmisille ymmärrettävällä tavalla. Se luo myös yhteisen kielen teknisille ja ei-teknisille sidosryhmille kompromissien keskustelemiseksi ja auditoijille, jotta he voivat nähdä, miten saatavuuskerroksesi toimii oikeiden pelaajien asiakaspoluilla.
Redundanssin toteuttaminen koko pelipinossa
Redundanssin toteuttaminen koko peliympäristössä tarkoittaa sen varmistamista, ettei mikään yksittäinen kerros – reunatasolta havainnoitavuuteen – muutu piileväksi yksittäiseksi vikaantumispisteeksi. Pelkkä pelipalvelinten vikasietoisuus ei riitä, jos identiteetti, maksut tai lokitiedot voivat heikentää pelikokemusta.
Redundanssi toimii vain, kun sitä sovelletaan päästä päähän, pelaajan ensimmäisestä paketista, joka osuu palvelimellesi, aina telemetriaan asti, joka kertoo, mitä tapahtuu. On yleistä nähdä vikasietoisia pelipalvelimia, joita ohjaa yksi hauras riippuvuus, kuten identiteetintarjoaja, maksuyhdyskäytävä tai lokijärjestelmä. Redundanssin suunnittelu eri tasoille auttaa välttämään osittaisten kuvien varaan rakennettua luottamusta ja antaa vaatimustenmukaisuus- ja tarkastustiimeille kattavampia tarinoita testattavaksi.
Verkko, reuna ja sisääntulo
Verkko-, reuna- ja sisääntulon redundanssi suojaavat etuoveasi, jotta pelaajilla on useampi kuin yksi terveellinen tapa tavoittaa taustajärjestelmäsi. Jos sisääntulo epäonnistuu, ei ole väliä kuinka vankkoja alavirran palvelusi ovat; pelaajat näkevät vain jumiutuneen latausnäytön.
Etuovella haluat pelaajille useamman kuin yhden reitin päästä backend-järjestelmällesi turvallisesti. Tämä tarkoittaa yleensä:
- Kuormituksen tasaamiseen perustuvat päätepisteet, jotka on otettu käyttöön useilla saatavuusvyöhykkeillä.
- Kuntotarkastettu reititys, joka voi ohjata asiakkaat pois epäterveellisistä solmuista.
- Redundanssi DNS- ja TLS-päätekomponenteissa.
- Useita ylävirran yhteyksiä tai palveluntarjoajia, jos riski sitä edellyttää.
Yhdessä nämä toimenpiteet estävät yksittäisen sisääntulokomponentin muuttumisen vikaantumispisteeksi. Globaalin yleisön peleissä lisätään alueelliset sisääntulopisteet ja globaali reitityskerros, joka ottaa huomioon viiveen ja kunnon. Tavoitteena on, että kun vyöhyke tai alueellinen reuna vikaantuu, asiakkaat ohjataan automaattisesti seuraavaksi parhaaseen vaihtoehtoon, ja valvonta kertoo, että näin on tapahtunut. Auditoijille selkeät kaaviot ja muutostietueet näiden sisääntulopisteiden ympärillä ovat osa todisteita siitä, että etuoven hallintalaitteet ovat aitoja.
Laskenta, pelipalvelut ja tilankäsittely
Laskenta, pelipalvelut ja tilatietojen käsittelyn redundanssi varmistavat, että alustasi sekä tilattomat että tilalliset osat selviävät solmujen, vyöhykkeiden tai jopa alueellisten menetysten varalta. Tilattomat tasot on helppo skaalata horisontaalisesti; tilalliset järjestelmät vaativat huolellisempaa replikointi- ja palautussuunnittelua.
Laskennan redundanssi alkaa horisontaalisesta skaalautuvuudesta. Tilattomien palveluiden, kuten API-yhdyskäytävien, matchmaking-ohjainten tai lobbauspalveluiden, tulisi toimia useina instansseina eri vyöhykkeille hajautettuina kuormituksen tasaajien ja automaattisten skaalaajien takana. Tämä varmistaa, että yhden solmun tai vyöhykkeen menetys ei keskeytä palvelua.
Tilakomponentit vaativat enemmän huolellisuutta. Voit erottaa kolme pääluokkaa:
- Auktoritatiivinen tila otteluissa ja pelisessioissa, joissa johdonmukaisuus ja huijausvastaisuus ovat tärkeimpiä.
- Pysyvä pelaajan tila, kuten profiilit, tavaraluettelot, edistyminen ja oikeudet.
- Johdettu tai välimuistissa oleva tila, kuten tulostaulukot, syötteet tai suositukset.
Alla on esitetty tiivis tapa ajatella näitä luokkia.
Pelien tilaluokat ja redundanssikeskittymät:
| Osavaltioluokka | Esimerkit | Redundanssikeskeisyys |
|---|---|---|
| Auktoritatiivinen osuma | Ottelun sisäinen tilanne, fysiikka, pisteet | Nopea paikallinen toipuminen, vahva sakeus |
| Pysyvä pelaaja | Profiilit, varasto, valuutat | Kestävä replikointi, lähes olematon datahävikki |
| Johdettu / välimuisti | Tulostaulut, syötteet, ehdotukset | Uudelleenrakennettava, lopulta johdonmukaisuus |
Tiukasti kontrolloidut pelipalvelimet tai koordinointipalvelut käsittelevät usein auktoritatiivista ottelutilaa, joskus käyttämällä johtajan valintaa ja replikointia sisäisesti. Pysyvä tila sijaitsee yleensä tietokannoissa tai avain-arvosäilöissä, ja sitä replikoidaan alueiden sisällä ja niiden välillä. Johdettu tila voidaan rakentaa uudelleen tai sovittaa yhteen auktoritatiivisista lähteistä, ja se voi käyttää välimuisteja ja mahdollisia johdonmukaisuusmalleja aggressiivisemmin.
Redundanssin suunnittelu tarkoittaa tässä kullekin kategorialle sopivien replikointi-, vikasieto- ja varmuuskopiointimekanismien käyttöä ja sen varmistamista, että pelilogiikka ja asiakasohjelmasi käyttäytyminen vastaavat tuloksena oleviin johdonmukaisuus- ja palautumisominaisuuksiin. Kun dokumentoit nämä mallit ja niiden testit, niistä tulee vakuuttavia todisteita jatkuvuuteen liittyville kontrolleille liitteessä A.
Kolmannet osapuolet, havaittavuus ja ”piilotetut SPOF:t”
Kolmannet osapuolet ja havainnointijärjestelmät muuttuvat usein "piilotetuiksi" yksittäisiksi vikapisteiksi, koska ne ovat suoran hallintasi ulkopuolella tai niitä ei pidetä kriittisinä. Jos et suunnittele niiden vikaantumista, ne voivat heikentää jopa parhaiten suunniteltua ydinalustaa.
Kolmannen osapuolen palvelut ovat toinen yleinen haavoittuvuuden lähde. Identiteetti, alustan saavutukset, maksut, chat, huijauksenesto ja analytiikka voivat kaikki sisältää ulkoisia palveluntarjoajia, jotka ovat suoran hallintasi ulkopuolella. Jos näitä riippuvuuksia ei valvota ja tueta vaihtoehtoisilla poluilla tai selkeillä heikentämisstrategioilla, niistä tulee yksittäisiä vikaantumiskohtia, vaikka oma infrastruktuurisi olisi vankka.
Samoin havainnointijärjestelmät – lokitiedot, mittarit, jäljitykset ja hälytykset – tarvitsevat redundanssia. Mahdollisuuden menettäminen nähdä, mitä alusta tekee tapahtuman aikana, on lähes yhtä paha kuin itse tapahtuma. Redundantit keräilijät, useat tallennustaustajärjestelmät tarvittaessa ja huolellinen erottelu pelaajien telemetrian ja operatiivisen telemetrian välillä auttavat pitämään tapahtumareagointisi tehokkaana silloin, kun sillä on eniten merkitystä.
Kaikki nämä suunnitteluvalinnat voidaan ja tulisi ottaa huomioon ISO 27001 -dokumentaatiossasi: toimittajien riskinarvioinneissa, palveluluetteloissa, verkosto- ja tietovuokaavioissa sekä jatkuvuussuunnitelmissa. Tietoturvan hallintajärjestelmäalusta, kuten ISMS.online, tarjoaa luonnollisen paikan linkittää nämä riippuvuudet ja todisteet, jotta ne pysyvät näkyvissä sen sijaan, että ne hautautuisivat ad hoc -dokumentteihin. Tämä myös tekee toimittajien riskiä koskevista tarkastuskeskusteluista konkreettisempia.
Vapauta itsesi laskentataulukoiden vuorten vallasta
Ota käyttöön, laajenna ja skaalaa vaatimustenmukaisuus ilman sotkua. Io antaa sinulle joustavuutta ja luottamusta kasvaa turvallisesti.
Suora vastaavuus ISO 27001 -standardin lausekkeeseen 8 ja liitteeseen A
Redundanssi- ja vikasietoisuussuunnitelmiesi suora yhdistäminen ISO 27001 -standardin lausekkeeseen 8 ja liitteeseen A muuttaa arkkitehtuuripäätökset selkeäksi valvonnan kattavuudeksi. Se myös helpottaa auditointeja, sillä voit osoittaa tarkasti, miten reaaliaikaiset järjestelmät tarjoavat kapasiteetin, varmuuskopioinnin, redundanssin ja jatkuvuuden koko pelivalikoimassasi.
Redundanssi- ja vikasietoisuussuunnittelun kartoittaminen ISO 27001 -standardin mukaisesti ei ole teoreettinen harjoitus; se on tapa varmistaa, ettei standardin odotusten ja alustan todellisen toiminnan välillä ole sokeita pisteitä. Yksinkertainen ja toistettava kartoitus helpottaa auditointeja, selventää vastuita sisäisesti ja antaa tietoturvapäälliköille enemmän luottamusta, kun he selittävät saatavuusriskiä hallitukselle.
Olennaisimpien kontrollien tunnistaminen
Olennaisimpien liitteen A mukaisten kontrollien tunnistaminen antaa sinulle mahdollisuuden keskittää työsi sinne, missä sillä on eniten merkitystä käyttöajan ja jatkuvuuden kannalta. Sinun ei tarvitse kohdella kaikkia kontrollitekijöitä yhtä tärkeinä; kohdennettu joukko kantaa suurimman osan online-pelien vikasietoisuuskuormasta.
Redundanttisessa peli-infrastruktuurissa pieni joukko liitteen A ohjausteemoja kantaa yleensä suurimman osan painoarvosta:
- Kapasiteetin hallinta: valvot resurssien käyttöä, määrität kynnysarvot ja suunnittelet kasvua, jotta suorituskyky- ja saatavuusvaatimukset täyttyvät.
- Varmuuskopiointi: määrität varmuuskopioiden laajuuden, tiheyden, suojauksen ja palautustestauksen, jotka kattavat pelaajatiedot, pelitilan, kokoonpanon ja koodin.
- Tietojenkäsittelytilojen redundanssi: suunnittelet ja ylläpidät redundantteja komponentteja, sivustoja tai pilvialueita käytettävyystarpeiden täyttämiseksi.
- Tietoturva häiriöiden aikana: varmistat, että asianmukaiset turvatoimenpiteet pysyvät voimassa myös häiriöiden ja käyttökatkosten aikana.
- Liiketoiminnan jatkuvuuden ICT-valmius: suunnittelet ja ylläpidät teknologiaa siten, että se tukee kriittisten palveluiden määriteltyjä palautumistavoitteita.
Muut kontrollit, kuten muutoshallinta, konfiguraationhallinta, lokinluku ja valvonta sekä toimittajasuhteet, tukevat näitä ydinalueita ja ne on myös kuvattu liitteessä A. Temppu on sitoa jokainen palvelu- ja suunnittelupäätös asiaankuuluviin kontrolleihin nimenomaisesti, jotta tilintarkastajat ja sisäiset tarkastajat voivat nähdä tarkalleen, miten tietty kontrolli toteutetaan käytännössä.
Ohjausjärjestelmän matriisin rakentaminen
Kontrollin ja järjestelmän välisen matriisin rakentaminen auttaa sinua selittämään tilintarkastajille ja sisäisille sidosryhmille, miten kukin palvelu edistää ISO 27001 -standardin noudattamista. Abstraktien käytäntöjen sijaan osoitat konkreettisia yhteyksiä järjestelmien, riskien, kontrollien ja todisteiden välillä.
Käytännöllinen tekniikka on rakentaa yksinkertainen matriisi, joka listaa:
- Jokainen merkittävä järjestelmä tai palvelu (esimerkiksi todennus, matchmaking, istunnonhallinta, pelaajaluettelo, maksut, live-operaatioiden hallinta, analytiikka).
- Kyseisen palvelun keskeiset riskit ja vaikutustasot.
- Asiaankuuluvat liitteen A säännökset.
- Toteuttamasi suunnittelu- ja operatiiviset toimenpiteet.
- Ensisijaiset todisteet, jotka osoittavat näiden toimenpiteiden olemassaolon ja toimivuuden.
Esimerkiksi yhteensovitus voidaan yhdistää kapasiteetin hallintaan, redundanssiin, lokinnukseen ja jatkuvuuden hallintaan. Todisteisiin voivat kuulua arkkitehtuurikaaviot, jotka esittävät alueellisia yhteensovitusmekanismeja ja jonoja, automaattisen skaalauksen käytännöt ja mittarit, alueellisen vikasietoisuuden DR-testiraportit ja tapahtumakatsaukset, joissa näitä mekanismeja on käytetty.
Visuaalinen: matriisi, jossa ydinpalvelut kartoitetaan ISO-kontrolleihin.
Tätä matriisia voi käyttää ISMS-järjestelmässäsi ja sitä voidaan käyttää uudelleen eri nimikkeiden ja alueiden välillä, ja palvelukohtaiset tiedot täytetään pelikohtaisesti. Monet organisaatiot huomaavat, että sen säilyttäminen alustalla, kuten ISMS.online, vähentää sen vanhenemisen riskiä ja nopeuttaa tarkastajien pääsyä vaatimuksista todistusaineistoon.
Arkkitehtuurin ja ohjainten synkronointi
Arkkitehtuurin ja kontrollien synkronointi tarkoittaa ISO 27001 -ajattelun sisällyttämistä muutos- ja tapahtumaprosesseihin. Aina kun lisäät tai muokkaat palvelua, päivität myös sen riskit, kontrollit ja todisteet sen sijaan, että tekisit vuosittaisen siivouksen.
Maailman paras tekninen suunnittelu ei ole ISO-standardien mukainen, jos kukaan ei päivitä dokumentaatiota asioiden muuttuessa. Jotta kartoituksesi pysyy elossa, liitä se olemassa oleviin työnkulkuihin:
- Kun lisäät uuden palvelun tai muutat palvelun käyttöönottoa, osa muutosprosessia on sen hallintatietojen ja todisteluettelon päivittäminen.
- Kun suoritat DR-harjoituksen tai kapasiteettitestin, liität tulokset asiaankuuluviin kontrolleihin ja kirjaat ylös mahdolliset jatkotoimenpiteet.
- Kun otat toimittajan haltuun tai vaihdat uutta toimittajaa, päivität toimittajan riskinarvioinnin ja mahdolliset jatkuvuusriippuvuudet.
Erityinen tietoturvallisuuden hallintajärjestelmäalusta, kuten ISMS.online, voi auttaa tässä: se tarjoaa keskitetyn paikan riskien, kontrollien, palveluiden, toimittajien ja todisteiden linkittämiseen pakottamatta insinöörejä erilliseen staattisten asiakirjojen maailmaan. Tavoitteena on, että tilintarkastaja, partneri tai sisäinen johtaja voi jäljittää rajan "tarvitsemme yhteensovittamista selviytyäksemme alueellisesta tappiosta" -ajatteluun, "tässä on kontrolli, johon luotamme" -ajatteluun ja "tässä on suunnittelu ja todiste sen toimivuudesta" -ajatteluun muutamalla napsautuksella. Tämä läpinäkyvyys tekee tilintarkastustuloksista ennustettavampia ja hallitustason riskikeskusteluista perusteellisempia.
Kapasiteetin hallinta on usein ensimmäinen alue, jossa tämä kartoitus tulee hyvin konkreettiseksi, koska pelaajien kuormitusmallit paljastavat nopeasti heikkouksia, jos niitä ei ole ajateltu loppuun asti.
Kapasiteetin hallinta, automaattinen skaalaus ja huipputapahtumat
Kapasiteetin hallinta, automaattinen skaalaus ja huipputapahtumien suunnittelu varmistavat, että alustasi selviää sekä odotetusta että odottamattomasta kuormituksesta ilman epämiellyttäviä yllätyksiä. Peleissä tämä on usein tärkeämpää kuin vakaa suorituskyky, koska pelaajat muistavat suuret tapahtumat, jotka menivät pieleen kauan sen jälkeen, kun pienet päivittäiset ongelmat on unohdettu.
Pelien kapasiteetinhallinnassa on kyse muustakin kuin palvelimien lisäämisestä, kun graafit näyttävät ruuhkaisilta; kyse on resurssien ennustamisesta, tarjoamisesta ja jatkuvasta säätämisestä, jotta suorituskyky- ja saatavuustavoitteet täyttyvät sekä normaaleissa että poikkeuksellisissa olosuhteissa. ISO 27001 -standardi tekee tästä käsitteen yksiselitteiseksi, ja Annex A:n kapasiteetinhallinnan ohjaus antaa sinulle keinon integroida se tietoturvanhallintajärjestelmääsi tavalla, jonka tilintarkastajat voivat varmistaa.
Resilienssi alkaa suunnitteluvalintana kauan ennen kuin vaaratilanne etenee tuotantoon.
Jos omistat live-op-pelejä tai infrastruktuuria erittäin kausiluonteiselle pelille, olet jo nähnyt, kuinka hauras "parhaan arvion" mukainen kapasiteetti voi olla. Huipputapahtumat, mainoskampanjat ja odottamaton viraalisuus paljastavat heikot oletukset nopeasti, joten suunnittelusi ja näyttösi on pysyttävä pelisi todellisen käytön tahdissa.
Kysynnän ennustaminen ja liikkumavaran määrittäminen
Kysynnän ennustaminen ja liikkumavaran määrittäminen auttavat välttämään tuskallisen valinnan käyttämättömän kapasiteetin maksamisen ja toimijoiden pettymyksen välillä ruuhka-aikoina. Selkeän kuvan avulla todennäköisestä kuormituksesta voit sovittaa automaattisen skaalauksen säännöt, alueelliset allokaatiot ja menot liiketoiminnan todellisuuteen.
Verkkopelien kuormitus vaihtelee suuresti: hiljaisia arkipäiviä, kiireisiä iltoja, pyhäpäiviä, sisällön pudotuksia, markkinointikampanjoita, esports-tapahtumia ja odottamattomia piikkejä. Et voi kohdella jokaista päivää samalla tavalla. Sen sijaan yhdistät:
- Historiallinen samanaikaisuus ja käyttömallit.
- Tulevat julkaisut ja tapahtumakalenterit.
- Alusta ja alueelliset kasvutrendit.
- Tunnetut tekniset rajoitukset pinossasi.
Tästä johdat eksplisiittiset kapasiteettisuunnitelmat: odotettu samanaikaisten käyttäjien huippumäärä alueittain tai segmenteittäin, tavoitekäyttöasteet ja kunkin merkittävän tapahtuman liikkumavara. Voit sitten verrata todellisia mittareita näihin suunnitelmiin, säätää kynnysarvoja ja skaalaussääntöjä sekä hyödyntää tietoja liiketoiminnan suunnittelussa. Tästä suunnittelupolusta tulee hyödyllinen todiste siitä, että kapasiteettia hallitaan tarkoituksella eikä reaktiivisesti.
ISO 27001 -standardi edellyttää, että pystyt osoittamaan, että kapasiteettia seurataan, analysoidaan ja suunnitellaan, eikä vain sitä, että automaattinen skaalaus on "päällä". Kapasiteettisuunnitelmat, koontinäytöt ja tapahtumien jälkeiset tarkastelut ovat kaikki käytännönläheisiä esineitä, jotka voidaan liittää kapasiteetinhallinnan hallintalaitteisiin.
Automaattisen skaalauksen ja suorituskykytestauksen käyttö todisteena
Automaattisen skaalauksen ja suorituskykytestauksen käyttäminen todisteena tekee suunnittelukäytännöistä auditoijille ja johtajille ymmärrettävää. Sen sijaan, että sanoisit vain "skaalaamme", osoitat, kuinka käytännöt, testit ja tapaukset osoittavat kapasiteetinhallinnan toimivan.
Automaattinen skaalaus ja joustava infrastruktuuri ovat tehokkaita työkaluja, mutta niistä tulee luotettavia vasta, kun ymmärrät, miten ne käyttäytyvät stressin alla. Hyvä käytäntö on käsitellä automaattisesti skaalautuvia konfiguraatioita ja suorituskykytestejä muodollisina kontrollitoteutuksina ja todisteina:
- Määrität automaattisen skaalauksen käytännöt merkityksellisten signaalien, kuten pyyntöjen määrän, jonon syvyyden tai viiveen, perusteella, etkä pelkästään suorittimen tehon perusteella.
- Suoritat kuormitus- ja skaalautuvuustestejä, jotka simuloivat huipputapahtumia, mukaan lukien alueelliset vikasietoisuusskenaariot, ja tallennat tulokset.
- Asetat hälytyksiä kyllästymis- ja virheindikaattoreiden perusteella, jotka kertovat, kun kapasiteetti lähestyy vaarallista tasoa.
Kaikki tämä voidaan linkittää takaisin kapasiteetinhallinnan hallintaan: käytäntöihin, koontinäyttöihin, testiraportteihin ja tapahtumatietoihin, jotka osoittavat, ettet arvaile. Näiden artefaktien säilyttäminen jäsennellyssä tietoturvan hallintajärjestelmässä hajallaan olevien työkalujen sijaan helpottaa riskienhallinnan osoittamista ulkopuolisille osapuolille ja infrastruktuurimenoihin ja liikkumavaraan liittyvien päätösten perustelemista.
Ulkoiset kapasiteettirajoitukset mukaan lukien
Ulkoisten kapasiteettirajoitusten sisällyttäminen suunnitteluun estää yllätyksiä, kun kumppanit tai toimittajat saavuttavat omat rajansa. Oman kapasiteettipinon skaalaaminen hallitusti ei ole hyödyllistä, jos maksu-, identiteetti- tai verkkopalveluntarjoajat eivät pysy perässä.
Kapasiteettikerroksesi ei rajoitu omaan infrastruktuuriisi. Maksupalveluntarjoajilla, alustavarastoilla, identiteettipalveluilla ja jopa verkko-operaattoreilla on omat rajoituksensa. Jos näitä rajoituksia ei ymmärretä ja suunnitella, ne voivat heikentää toimintaasi, vaikka oma kapasiteettipinosi olisi kunnossa.
Tietoturvan näkökulmasta näitä käsitellään toimittajariskeinä. Tämä tarkoittaa:
- Sen dokumentointi, mitkä palvelut ovat riippuvaisia mistäkin ulkoisista palveluntarjoajista.
- Palveluntarjoajien kapasiteettisitoumusten ja vikatilojen ymmärtäminen ja kirjaaminen.
- Ota nämä huomioon omassa tapahtumasuunnittelussasi ja liiketoimintavaikutusten analysoinnissa.
- Sisällytä ne tarvittaessa hätätilanteisiin ja jatkuvuusskenaarioihin.
Liitteen A termein tämä sitoo kapasiteetinhallinnan, toimittajasuhteet ja liiketoiminnan jatkuvuuden valvonnan yhteen yhtenäiseksi kokonaisuudeksi sen sijaan, että niitä käsiteltäisiin erikseen. Se antaa myös kaupallisille tiimeille selkeämmän näkemyksen palvelutasojen neuvottelemiseen keskeisten kumppaneiden kanssa ja tarjoaa tilintarkastajille jäsennellyn kuvan siitä, miten ulkoista kapasiteettiriskiä hallitaan.
Hallitse kaikkea vaatimustenmukaisuuttasi yhdessä paikassa
ISMS.online tukee yli 100 standardia ja sääntöä, mikä tarjoaa sinulle yhden alustan kaikkiin vaatimustenmukaisuustarpeisiisi.
Vikasietoisuus, DR ja liiketoiminnan jatkuvuus online-peleissä
Verkkopelien vikasietoisuus, katastrofien jälkeinen palautus (DR) ja liiketoiminnan jatkuvuus keskittyvät pelaajakokemuksen, pelin sisäisen talouden ja kaupallisten sitoumusten suojaamiseen vakavien häiriöiden aikana. Pelkkä infrastruktuurin palauttaminen ei riitä; tarvitaan pelaajakeskeisiä skenaarioita ja testattuja vastauksia, jotka vastaavat riskinottohalukkuuttasi.
Vikasietoisuus ja DR ovat paikkoja, joissa suunnitteluoletuksesi kohtaavat todellisuuden. Verkkopeleissä liiketoiminnan jatkuvuus ei tarkoita pelkästään datakeskuksen palauttamista; se koskee pelaajakokemuksen, pelin sisäisten taloudellisten olosuhteiden ja kaupallisten sitoumusten suojaamista, kun osa alustastasi tai toimitusketjustasi vikaantuu. ISO 27001 yhdessä liiketoiminnan jatkuvuusstandardien kanssa tarjoaa kehyksen tämän työn jäsentämiseen tavoilla, joita voit harjoitella ja esitellä tilintarkastajille.
Yleisestä DR-tilanteesta pelikohtaisiin skenaarioihin
Siirtyminen yleisistä DR-suunnitelmista pelikohtaisiin skenaarioihin tarkoittaa pelaajiesi ja kumppaniesi todellisten epäonnistumisten kohtaamisen suunnittelua. Lakkaat puhumasta vain "sivuston menetyksestä" ja alat kuvailla, mitä tapahtuu, kun avainalueet, palveluntarjoajat tai datajoukot epäonnistuvat pahimmalla mahdollisella hetkellä.
Perinteinen DR-suunnittelu keskittyy usein infrastruktuurin palauttamiseen sivuston menetyksen jälkeen. Pelien osalta tarvitaan vivahteikkaampia, pelaajakeskeisempiä skenaarioita, kuten:
- Pelialueen tai saatavuusvyöhykkeen menetys live-tapahtuman aikana.
- Merkittävät DDoS-hyökkäykset verkon reunoille tai tiettyihin palveluihin.
- Maksupalveluntarjoajan toimintakatkos kampanjan aikana.
- Tulostaulukon tai varastodatan vioittuminen.
- Live-operations-päätöksiä varten tarvittavan analytiikkaputken pitkittynyt menetys.
Jokaiselle skenaariolle määrittelet:
- Kyseessä olevat palvelut ja data.
- Vaikutus liiketoimintaan ja pelaajiin ajan kuluessa.
- Haluttu toimintatapa: hajoaminen, nopea vikaantuminen tai täydellinen vikasietoisuus.
- Vaadittavat tekniset ja organisatoriset toimenpiteet.
- Roolit ja vastuut, mukaan lukien kuka päättää korvauksesta tai ominaisuusrajoituksista.
Visuaalinen: skenaarion aikajana tapahtumasta pelaajakommunikaatioon.
Nämä skenaariot liittyvät suoraan jatkuvuuteen liittyviin liitteen A kontrolleihin sekä riskienhallintasuunnitelmiisi ja liiketoimintavaikutusten analyyseihisi. Niiden ja niiden testitulosten säilyttäminen tietoturvan hallintajärjestelmässä, kuten ISMS.online-sivustolla, helpottaa huomattavasti tilintarkastajien ja kumppaneiden kykyä suunnitella tosielämän vikoja.
Realistisen RTO:n ja RPO:n asettaminen ja saavuttaminen
Realististen palautumisaikatavoitteiden (RTO) ja palautuspistetavoitteiden (RPO) asettaminen auttaa sinua päättämään, mihin kannattaa investoida vahvempaan replikointiin, varmuuskopiointiin ja automaatioon. Lähes nollan seisokkiajan ja tietojen menetyksen tavoittelu kaikessa on yleensä kohtuutonta ja tarpeetonta.
RTO ja RPO antavat sinulle kurinalaisen tavan keskustella siitä, kuinka paljon seisokkiaikaa ja datan menetystä voit hyväksyä kunkin komponentin osalta. Pelikontekstissa saatat päättää, että:
- Kirjautumisen on palauduttava muutamassa minuutissa, tai pelaajat siirtyvät muihin peleihin.
- Käynnissä olevat satunnaiset ottelut voidaan keskeyttää tai aloittaa uudelleen; rankatut ottelut saattavat vaatia räätälöityä käsittelyä.
- Pelaajien varastoa tai valuuttasaldoja ei saa menettää; RPO on käytännössä nolla ja vaaditaan vahvat transaktiotakuut.
- Analytiikkadata voi sietää jonkin verran menetystä tai viivettä, kunhan se dokumentoidaan eikä johda harhaan loppupään prosesseja.
Sitten suunnittelet replikointi-, varmuuskopiointi- ja vikasietomekanismit, jotka realistisesti täyttävät nämä tavoitteet. Voit esimerkiksi käyttää synkronista replikointia transaktiodatalle ja asynkronista replikointia vähemmän kriittiselle datalle yhdistettynä säännölliseen varmuuskopiointi- ja palautustestaukseen.
ISO 27001 -standardi ei määrää RTO:n ja RPO:n arvoja, mutta se edellyttää, että olet määritellyt ne, perustellut ne ja suunnitellut teknologian ja prosessit niiden saavuttamiseksi. Tämän ajattelutavan osoittaminen tilintarkastajille ja johdolle voi merkittävästi lisätä luottamusta jatkuvuusasenteeseesi.
Testaaminen, oppiminen ja parantaminen
Testaus, oppiminen ja parantaminen muuttavat redundanssi- ja jatkuvuussuunnitelmat staattisista dokumenteista toimiviksi ominaisuuksiksi. Ilman testejä, harjoituksia ja seurantatoimia on mahdotonta tietää, toimiiko redundanssisuunnitelmasi todellisen paineen alla.
Jatkuvuus- ja katastrofiapusuunnitelmat, joita ei koskaan harjoiteta, ovat tuskin parempia kuin toiveajattelua. Säännölliset testit, harjoitukset ja harjoitukset auttavat sinua:
- Varmista, että tekniset mekanismit toimivat odotetulla tavalla.
- Rakenna lihasmuistia tapahtumiin reagointia varten eri tiimeissä.
- Löydä aukkoja dokumentaatiossa, seurannassa tai päätöksenteossa.
- Syötä parannukset takaisin suunnitteluun, runbookeihin ja koulutukseen.
Testit voivat vaihdella skenaarioiden pöytäkeskusteluista reaaliaikaisiin vikasietoharjoituksiin ja kontrolloidun kaaoksen kokeisiin tuotantoympäristöjä muistuttavissa ympäristöissä. ISO 27001 -standardin avain on, että kirjaat ylös, mitä teit, mitä havait ja mitä muutit niiden seurauksena. Nämä tiedot – testisuunnitelmat, lokit ja harjoitusten jälkeiset tarkastelut – ovat vakuuttavaa näyttöä siitä, että ICT-valmius liiketoiminnan jatkuvuuden varmistamiseksi on enemmän kuin vain rivi politiikassa.
Kun tarkastelet vikasietoisuutta ja DR-toimintoja tästä näkökulmasta, redundanssi ei ole abstrakti arkkitehtoninen hyve; se on joukko eläviä ominaisuuksia, joita voit demonstroida ja parantaa ajan myötä. Näiden skenaarioiden ja tulosten tallentaminen tietoturvan hallintajärjestelmään, kuten ISMS.onlineen, auttaa myös välttämään kovalla työllä opeteltujen oppien menettämisen kausien tai tiiminvaihdosten välillä ja antaa tarkastajille selkeän kuvan siitä, miten jatkuvuuskykysi ovat kehittyneet.
Varaa esittely ISMS.onlinesta jo tänään
ISMS.online voi auttaa sinua muuttamaan jo tekemäsi redundanssi-, kapasiteetti- ja jatkuvuustyön yhtenäiseksi, ISO 27001 -yhteensopivaksi vikasietoisuusjärjestelmäksi, jota on helpompi käyttää ja todistaa. Jos olet vastuussa sekä reaaliaikaisen palvelun vakaudesta että sertifioinnista, kannattaa tutkia, miten erillinen ISMS-alusta voi yhdistää riskisi, kontrollisi, arkkitehtuurisi, vikasietoisuussuunnitelmasi, testisi ja toimittajadatasi.
Redundantin peli-infrastruktuurin yhdenmukaistaminen ISO 27001 -standardin kanssa liittyy yhtä paljon koordinointiin ja näyttöön kuin alueisiin ja replikoihinkin. Kun teet koordinoinnista helpompaa ja läpinäkyvämpää, et ainoastaan läpäise auditointeja, vaan annat pelaajille, kumppaneille, hallituksille ja sääntelyviranomaisille selkeämpiä syitä luottaa alustaasi ja sen pitkän aikavälin vakauteen.
Todellisen insinöörityön muuttaminen eläväksi tietoturvajärjestelmäksi
Todellisen suunnittelutyön muuttaminen eläväksi tietoturvan hallintajärjestelmäksi tarkoittaa tiimiesi jo tuottamien artefaktien käyttämistä ensisijaisina ISO 27001 -todisteena. Erillisen "vaatimustenmukaisuusdokumentaation" luomisen sijaan yhdistät riskit, kontrollit ja järjestelmät suoraan käyttöönottotodellisuuteen, jotta jokainen arkkitehtuuripäätös ja jokainen DR-poraus vahvistaa varmuuskerrostasi.
Monille tiimeille suurin este hyödyllisen tietoturvan hallintajärjestelmän (ISMS) saavuttamiselle on havaittu etäisyys teknisen todellisuuden ja vaatimustenmukaisuuskielen välillä. ISMS.online on suunniteltu kuromaan umpeen tätä kuilua. Voit:
- Mallinna palvelusi, toimittajasi ja ympäristösi tavalla, joka heijastaa todellista osaamistasi.
- Yhdistä nämä resurssit ISO 27001 -standardin mukaisiin kontrolleihin, riskeihin ja tavoitteisiin ilman, että sinun tarvitsee muuttaa kaavioitasi tai suorituskirjojasi.
- Liitä tiettyihin ohjaimiin ja palveluihin todellisia artefakteja – muutostietueita, tapahtumakatsauksia, DR-testituloksia, kapasiteettiraportteja ja arkkitehtuurikaavioita.
- Näe yhdellä silmäyksellä, mitkä redundanssi- ja jatkuvuuskertomuksen osat ovat hyvin todistettuja ja missä tarvitaan lisätyötä.
Koska alusta on rakennettu standardin ISO 27001:2022 ympärille, mukaan lukien kohta 8 ja päivitetyt liitteen A kontrollit, et aloita tyhjältä sivulta. Valmiiksi jäsennellyt mallit ja työnkulut auttavat sinua tallentamaan olennaiset tiedot ja mukautumaan pelikontekstiisi. Sekä käyttöajasta että sertifioinnista vastaaville tiimeille tämä vähentää kitkaa, lyhentää auditointisyklejä ja helpottaa jatkuvan parantamisen osoittamista.
Monialaisten resilienssityön tukeminen
Toimintojen rajat ylittävän resilienssityön tukeminen on olennaista, koska yksikään yksittäinen tiimi ei omista kaikkia live-pelien saatavuuskerroksen osia. Tehokkaan tietoturvan hallintajärjestelmän on tarjottava arkkitehdeille, SRE-henkilöstölle, tietoturvalle, vaatimustenmukaisuudelle, live-operaatioille, lakimiehille ja johdolle yhteinen totuuden lähde, johon he voivat luottaa ja jota he voivat jalostaa ajan myötä.
Resilientti peli-infrastruktuuri ei ole yhden tiimin omistuksessa. Arkkitehdeillä, SRE:illä, tietoturvajohtajilla, vaatimustenmukaisuuspäälliköillä, operatiivisilla yksiköillä, lakimiehillä ja johdolla on kaikilla omat roolinsa. ISMS.online tarjoaa näille ryhmille jaetun kodin:
- Live-pelien ja niitä tukevien järjestelmien laajuudesta ja riskiprioriteeteista sopiminen.
- Redundanssimallien ja jatkuvuusstrategioiden dokumentointi ja hyväksyminen.
- DR-harjoitusten, kapasiteettitestien ja jatkuvuusharjoitusten aikataulutus ja kirjaaminen.
- Toimittajariskien hallinta pilvipalveluntarjoajista ja CDN-verkoista maksuihin ja huijauksenestopalveluihin.
- Valmistautuminen auditointeihin ja kumppaniarviointeihin ilman viime hetken hässäkkää.
Ratkaisevasti tämä tapahtuu pakottamatta sinua hylkäämään jo käyttämiäsi kehitys- ja operatiivisia työkaluja. Integraatiot ja selkeät vastuut auttavat pitämään tietoturvajärjestelmän ajan tasalla kehittyvän alustasi kanssa sen sijaan, että jäisit yksittäisen tilannekuvan taakse.
Jos haluat selvittää, sopiiko tämä lähestymistapa ympäristöösi, lyhyen ISMS.online-demon varaaminen on seuraava vähäriskinen askel. Se antaa sinulle konkreettisen kuvan siitä, miten nykyinen arkkitehtuurisi, riskisi ja todisteesi voidaan yhdistää yhteen paikkaan seuraavan lanseerauksesi, seuraavan auditointisi ja pitkäaikaisten toimijasuhteidesi tukemiseksi.
Varaa demoUsein Kysytyt Kysymykset
Miten ISO 27001 -standardi todellisuudessa muuttaa tapaa, jolla suunnittelet redundanssia live-peleissä?
ISO 27001 muuttaa redundanssin "useammista alueista ja replikoista" jäljitettävä riskiketju → suunnittelu → testaus → parannus jota voit puolustaa johdolle, taloushallinnolle ja tilintarkastajille. Optimoit edelleen latenssin ja kustannusten suhteen, mutta jokainen korkeaa käytettävyyttä koskeva päätös on nyt sidottu tiettyyn liiketoimintavaikutukseen, RTO/RPO-tavoitteisiin ja nimettyihin liitteen A mukaisiin kontrolleihin.
Miten tietoturvajärjestelmä muuttaa redundanssin toivelistan sijaan tekniikan alaksi?
ISO 27001 -standardin mukaisen tietoturvallisuuden hallintajärjestelmän (ISMS) avulla voit pysähtyä esittämällä yhden selkeän kysymyksen: "Mikä oikeasti sattuu, jos se epäonnistuu, ja milloin?"
Luokittelet live-pelien ominaisuuksia, kuten todennuksen, matchmakingin, pelisessiot, etenemisen, lompakot, tulostaulukot, live-ops-työkalut ja analytiikan, seuraavien tekijöiden perusteella: vaikutus ja aikaherkkyysLiiketoimintavaikutusten analyysi ja riskinarviointi muuntaa sitten käyttökatkokset tulonmenetys, sopimusriski ja pelaajavaihtuvuus eri skenaarioissa, kuten lanseeraus, uusi kausi, vaikuttajien piikit ja normaali liikenne.
Sieltä sinä:
- Asettaa realistinen RTO/RPO palvelu- ja skenaariokuorittain, sen sijaan, että laulaisit "viisi yhdeksikköä" kaikkeen.
- Päätä, missä todella tarvitset alueiden välistä redundanssia, missä yksittäinen alue on hyväksyttävä ja missä varmuuskopiointi + palautus + korvaus tarjoaa parhaan yhdistelmän kustannuksia ja pelaajien luottamusta.
- Talleta tuo päättely muodossa kaaviot, DR-pelikirjat, runbookit ja testiaikataulut, joista jokainen on yhdistetty konkreettisiin kontrolleihin, kuten A.8.6 (kapasiteetin hallinta), A.8.13 (varmuuskopiointi), A.8.14 (redundanssi), A.5.29 (tietoturva häiriöiden aikana) ja A.5.30 (tieto- ja viestintätekniikan valmius liiketoiminnan jatkuvuuden varmistamiseksi).
Palkinto on yksinkertainen:
- Studion sisällä jokainen ”ylimääräinen” solmu, alue tai lisenssi näkyy riskirekisteri ja budjettikerros, ei vain insinöörin aavistus.
- Ulkopuolella, kun tilintarkastajat, alustakumppanit tai johtajat kysyvät "Miksi tämä arkkitehtuuri tälle julkaisulle?", näytät todisteet ja päätökset, ei mielipiteitä.
Jos hallitset tätä ketjua ISMS.onlinen sisällä, pidät riskin ja redundanssin logiikan yhdenmukaisena eri pelien ja sukupolvien välillä. Tiimisi voivat julkaista uusia pelejä ilman, että heidän tarvitsee joka kerta keksiä uudelleen, miten heidän on perusteltava korkea käytettävyys.
Millä ISO 27001 -standardin mukaisilla ohjausteemoilla on oikeasti merkitystä, kun käyttöaika on ensisijainen huolenaiheesi?
Kun välität live-pelaajista ja tuloista, pieni joukko ISO 27001:2022 -standardin mukaisia ohjausteemoja kattaa suurimman osan käyttöaika-asioista. Sen sijaan, että työmäärä jaettaisiin tasaisesti koko liitteeseen A, annat kourallisen ohjausobjekteja ohjata redundanssia ja käsittelet loput tukirakenteina.
Minkä valvonta-alueiden ympärille suunnittelu, SRE ja live-operaatiot tulisi rakentaa?
Käytännössä viisi teemaa hallitsevat yleensä sitä, miten pidät tulitikut, kaupat ja taloudet hengissä:
- Kapasiteetin hallinta (A.8.6): – Seuraat käyttöastetta, ennustat julkaisuja ja live-tapahtumia ja suunnittelet tietoisesti pelivaraa, jotta kirjautuminen, matchmaking ja maksut pysyvät responsiivisina, kun trailereita julkaistaan tai sisällöntuottajien kysyntä kasvaa.
- Tietojenkäsittelylaitteiden redundanssi (A.8.14): – Suunnittelet yksittäisten vikaantumiskohtien poistamisen vyöhykkeiltä, alueilta, tietokannoista ja jaetuista palveluista, jotta mikään yksittäinen vikaantumisalue ei voi pyyhkiä pois turnausta tai kausitapahtumaa.
- Tietojen varmuuskopiointi (A.8.13): – Suojaat pelaajatietoja, inventaarioita, kokoonpanoa ja koontiresursseja testatuilla varmuuskopiointi- ja palautusmalleilla, jotka vastaavat RPO-sitoumuksiasi, etkä "oleta tilannevedosten toimivan".
- Tietoturva häiriötilanteissa (A.5.29): – Pidät identiteetin, lokien tallentamisen, valvonnan, petostarkistukset ja väärinkäytösten hallinnan toiminnassa hyväksyttävällä tasolla häiriöiden aikana, joten et jahtaa käyttöaikaa poistamalla perusturvallisuutta käytöstä.
- Liiketoiminnan jatkuvuuden ICT-valmius (A.5.30): – Todistat suunnittelun ja säännöllisten testien avulla, että pystyt todella täyttämään sopimuksissa, alustasopimuksissa ja sisäisissä riskiraporteissa lupaamasi RTO:t.
Muut hallintalaitteet – muutostenhallinta, konfiguraationhallinta, valvonta ja lokikirjaus, tapausten hallinta, toimittajien hallinta ja turvallinen kehitys – estävät suunnittelun ajautumisen ajautumasta pois korjauksista, skaalauksista ja toimituksista.
Kun yhdistät konkreettisia resursseja, kuten ”Title X:n matchmaking-klusterin”, ”käyttöoikeuspalvelun”, ”alueellisen todennusportaalin” tai ”lompakkoselvityksen”, tähän kohdennettuun hallintajoukkoon, kaikki alustainsinööreistä lakimiehiin voivat nähdä sen. mitä vipuja he omistavat käyttöaikakerroksessa. ISMS.online-kartoitus tekee asumisesta kestävää henkilöstömuutoksille, uudelleenjärjestelyille ja uusille tittelimuutoksille ilman, että se on riippuvainen yhden SRE:n muistista.
Luotettavuus ei ole enää lupaus diaesityksessä, vaan siitä tulee jotain, johon voi viitata koodissa, datassa ja testituloksissa.
Miten sinun pitäisi päättää, onko monialueinen arkkitehtuuri hintansa arvoinen tietyssä pelissä?
Monialue on riskien käsittelypäätös, ei statussymboli. ISO 27001 -standardin mukaan se perustellaan kustannusperusteisena vastauksena tiettyihin käyttökatkoskenaarioihin, tasapainottaen kunkin nimikkeen vikasietoisuutta viiveen, monimutkaisuuden ja pilvipalveluihin kuluvien kustannusten kanssa.
Miten teet usean alueen kattavan päätöksen tavalla, jota kaikki tekniikan, taloushallinnon ja tilintarkastajien edustajat kunnioittavat?
Käytännöllinen ja toistettavissa oleva lähestymistapa jokaiselle pelille näyttää tältä:
Miten luokittelet palvelut vaikuttavuuden ja aikapaineen perusteella?
Aloita lajittelemalla ominaisuudet tasoihin:
- Huipputaso – kilpailukykyinen PvP, oikean rahan esineet, globaalit tapahtumat ja jaetut oikeudet, joissa käyttökatkos vaikuttaa suoraan tuloihin, maineeseen tai sääntelyyn.
- Keskitaso – live-operaatioiden työkalut, jotkin etenemisjärjestelmät ja sisäiset kojelaudat, joissa lyhyet keskeytykset ovat siedettäviä tietoja ei menetetä ja vahvaa viestintää.
- Alempi taso – eräanalytiikka ja ei-kriittiset sisäiset raportit.
Sitten juokset alueen menetysskenaariot: ”Entä jos ensisijainen alueemme katoaa viisi minuuttia ennen live-tapahtumaa?” ja ”Entä jos se epäonnistuu yön aikana hiljaisessa ikkunassa?” Kummassakin tapauksessa sidot vaikutuksen sopimuksiin, alustavaatimuksiin, markkinointikeinoihin ja pelaajalupauksiin.
Miten arkkitehtuurivalinnat sidotaan eksplisiittiseen RTO/RPO:hon?
Sinä:
- Asettaa skenaariokohtaiset RTO/RPO-arvotesimerkiksi 15 minuuttia oikeutuksille globaalin tapahtuman aikana, useita tunteja joillekin analytiikkatehtäville.
- Päätä missä AZ-rajainen redundanssi yhdellä alueella riittää, kun lämmin valmiustila tai aktiivinen aktiivinen tila alueiden välillä on perusteltua ja kun nopea palautus kompensoinnilla on oikea ratkaisu.
Latenssista tulee ensiluokkainen tekijä: monissa peleissä alueellisen latenssin pitäminen alhaisena useimmille pelaajille on arvokkaampaa kuin suojautuminen harvinaisilta, koko alueen kattavilta häiriöiltä maailmanlaajuisesti.
Kun tämä logiikka on tallennettu tietoturvanhallintajärjestelmääsi, monialueisuus lakkaa olemasta yleisstandardi ja siitä tulee dokumentoitu vastaus nimettyihin riskeihin nimikkeittäin ja palveluittainJohto ja talous saavat selkeän selityksen: ”Kappaleemme näitä palveluita näillä alueilla, koska niiden tekemättä jättämisen haittapuoli on suurempi kuin kustannukset; muualla hyväksymme yhden alueen palvelut, joissa on testattu toipuminen ja pelaajaystävällinen korvaus.”
Skenaarioiden, päätösten ja omistajien tallentaminen ISMS.online-palveluun mahdollistaa päätöksentekomallin uudelleenkäytön eri franchising-yrityksissä. Voit edelleen mukauttaa käytäntöä genren ja yleisön mukaan, mutta sinun ei tarvitse toistaa samoja argumentteja alusta alkaen jokaisella vihreällä valolla tai auditoinnilla.
Mitkä todisteet todella vakuuttavat ISO 27001 -auditoijat siitä, että pelijärjestelmäsi on vikasietoinen?
Tilintarkastajat haluavat nähdä, että suunnittelun tarkoitus, toiminta ja parantaminen yhdistyvätLive-pelien kohdalla tämä tarkoittaa, ettet näytä vain fiksuja kaavioita, vaan näytät myös, miten redundanssia, varmuuskopiointia ja jatkuvuutta suunnitellaan, testataan ja parannetaan ajan myötä.
Millä artefakteilla on yleensä eniten painoarvoa resilienssiin keskittyvässä auditoinnissa?
Vahvimpiin signaaleihin kuuluvat yleensä:
Miten arkkitehtuurinäkemykset todistavat, että olet ajatellut vikaantuvia alueita?
Pidät ajan tasalla olevia kaavioita, jotka osoittavat:
- Miten identiteetti, matchmaking, istunnot, tietovarastot, maksut, live-ops-työkalut, analytiikka ja huijauksenesto toimivat eri saatavuusalueilla ja -alueilla.
- Missä kolmannen osapuolen riippuvuudet – pilvipalveluntarjoajat, CDN:t, alusta-APIt, maksuyhdyskäytävät, chat ja ääni – näkyvät työnkulussa ja miten estät niiden muuttumisen piileviksi yksittäisiksi vikakohdiksi.
Miten tietosi osoittavat, että kapasiteetti ja varmuuskopiot ovat todellisia, eivät teoreettisia?
Säilytät:
- Kapasiteetti- ja skaalaustietueet: – kysyntäennusteet, automaattisen skaalauksen säännöt, lanseeraus-/tapahtumaraportit ja muutokset, jotka teit kysynnän piikkien jälkeen, olivatko ne odotettua parempia vai huonompia.
- Varmuuskopioi ja palauta todisteet: – käytännöt, aikataulut, työlokit ja säännölliset palautustestit, jotka osoittavat, että voit palauttaa pelaajatiedot, oikeudet, kokoonpanon ja rakentaa artefakteja ilmoitettujen RPO-arvojen puitteissa.
Miten käsikirjat ja testit osoittavat jatkuvuutta käytännössä?
Ylläpidät ja harjoittelet:
- Katastrofien jälkeisen toipumisen ja jatkuvuuden käsikirjat: esimerkiksi alueellisen tappion sattuessa ennen turnausta, maksupalveluntarjoajan epäonnistuessa kesken myynnin tai korkeiden panosten tulostaulukon korruptoitumisen yhteydessä.
- Testi-, harjoitus- ja tapahtumalokit: jotka osoittavat, että harjoittelet noita toimintasuunnitelmia, kirjaat ylös, mitä todella tapahtui, määrität seurantatehtäviä ja varmistat, että parannukset saavuttivat koodin, kokoonpanon tai prosessin.
Kun kaikki tämä sijaitsee jäsennellyssä tietoturvallisuuden hallintajärjestelmässä (ISMS) ja on linkitetty tiettyihin riskeihin, liiketoimintavaikutusten arviointeihin (BIA) ja liitteen A kontrolleihin, auditointi tuntuu vähemmän kokeelta ja enemmän suunnittelun ja toiminnan tarkastukselta. ISMS.online-rakenteen hallinta tarkoittaa, että opastat auditoijia, alustakumppaneita ja sisäisiä riskikomiteoita läpi järjestelmän. samoja esineitä, joihin luotat oikeissa tilanteissasen sijaan, että keksittäisiin rinnakkainen ”tarkastuskerros” kerran vuodessa.
Miten voit estää pilvi-, CDN- ja maksupalveluntarjoajien muuttumisen näkymättömiksi yksittäisiksi epäonnistumispisteiksi?
Vähennät kolmansien osapuolten haavoittuvuutta tekemällä ulkoisista alustoista arkkitehtuurisi, riskirekisterisi ja jatkuvuussuunnittelusi eksplisiittiset osat, eikä taustalla toimivia apuohjelmia, joiden "pitäisi olla kunnossa". ISO 27001 -standardi edellyttää, että hallitset toimittajien tietoturvaa ja vikasietoisuutta, millä on merkitystä silloin, kun kokonaiset nimikkeet ovat muutaman toimittajan varassa.
Miten saatte ulkoiset palveluntarjoajat saman sietokyvyn periaatteiden piiriin kuin omat järjestelmänne?
Toimiva kaava live-peleille on:
Miten yhdistät toimittajat suoraan pelien ominaisuuksiin ja lupauksiin?
Sinä:
- Yhdistä toimittajat ominaisuuksiin nimikkeen mukaan: – identiteetti, matchmaking, chat/ääni, huijauksenesto, analytiikka, CDN-jakelu, maksut, alustan API:t ja live-ops-työkalut.
- Vertaa heidän takuita omiin sitoumuksiinsa: – Yhdistä kunkin palveluntarjoajan palvelutasosopimukset, läpimenorajoitukset ja palautumistavoitteet omiin RTO/RPO-sopimuksiisi ja pelaajakohtaisiin palvelutasosopimuksiisi.
Kaikista eroista tulee selvä riski: ehkä maksupalveluntarjoajan palvelutasosopimus on heikompi kuin oma sitoutumisesi pelaajiin, tai CDN:n alueellinen jalanjälki ei tue latenssitavoitteitasi.
Miten suunnittelet turvallisen hajoamisen ja valvonnan?
Sinä:
- luoda heikkenemispolut ja varavaihtoehdot – vaihtoehtoiset maksureitit, pienemmät ottelukoot, rajoitetut pelitilat tai vain luku -tilat, jotka pitävät pelaajat hallinnassa virheruudun tuijottamisen sijaan.
- Ota palveluntarjoajan terveystiedot käyttöön oma havainnointipinosi ja tapahtumaprosessisisen sijaan, että päivittäisivät julkisia statussivuja kriisitilanteessa.
Toimittajien hallinta siirtyy sitten tietoturvanhallintajärjestelmääsi:
- Kirjaat toimittajien riskinarvioinnit, sopimukset, arvioinnit, vaaratilanteet ja seurannat.
- Linkität ne liitteen A mukaisiin toimittajan kontrolleihin ja jatkuvuuden kontrolleihin, jotta voit osoittaa, miten riippuvuusriski tunnistetaan, hyväksytään, käsitellään ja arvioidaan uudelleen.
Yhdistämällä toimittajat palveluihin, palvelutasosopimuksiin ja kontrolleihin ISMS.online-palvelussa saat reaaliaikaisen kuvan ulkoisista riippuvuuksista, jotka ohjaavat arkkitehtuurikatselmuksia, sopimusneuvotteluja ja pöytäkirjanpitoa sekä auditointeja. Kolmannen osapuolen riski ei katoa, mutta siitä tulee näkyvä, testattava ja neuvoteltavissa, jota sekä ISO 27001 että kaupalliset tiimisi odottavat.
Missä ISMS.onlinella on suurin merkitys redundanttia peli-infrastruktuuria ylläpitäville tiimeille?
ISMS.online auttaa muuttamalla redundanssin, jatkuvuuden ja toimittajien hallinnan yksi jaettu, auditoitava järjestelmä wikien, kaavioiden, tikettien ja institutionaalisen muistin levittäytymisen sijaan. Insinöörisi käyttävät edelleen haluamiaan työkaluja koodiin ja infrastruktuuriin, mutta turvallisuus- ja sietokykykerros hallitaan johdonmukaisesti yhdessä ympäristössä.
Miten tietoturvajärjestelmän yhdistäminen erilliselle alustalle muuttaa päivittäistä työtäsi?
Käytännössä voit:
Miten sovitat tietoturvanhallintamallisi yhteen todellisten peliesi ja palveluidesi kanssa?
Sinä:
- Malliotsikot, ympäristöt ja jaetut palvelut: tavalla, joka näyttää oikealta alustaltasi – identiteetti, matchmaking, eteneminen, maksut, analytiikka, sisältöputket ja ulkoiset palveluntarjoajat.
- Yhdistä jokainen näistä asiaankuuluviin riskit, RTO/RPO-tavoitteet ja liitteen A mukaiset kontrollit, jotta ihmiset näkevät, miten ne sopivat saatavuuskuvaan.
Miten pidät kontrollit, riskit ja todisteet yhdessä ilman ylimääräistä hallintoa?
Sinä:
- Linkkikaaviot, infrastruktuuri koodina, lähtötasot, testilokit, kapasiteettiraportit ja jälkianalyysit: suoraan niiden tukemiin riskeihin ja valvontaan.
- Vältä päällekkäisten todisteiden keräämistä ja ”missä se DR-testiraportti on?” -jahtia ennen jokaista auditointia tai alustakatselmusta.
Miten toistuvasta työstä tehdään ennustettava ja seurattava sykli?
Sinä:
- Aikatauluta hätätilanteiden harjoitukset, palautustestit, kapasiteettitarkastukset, toimittaja-arvioinnit ja johdon tarkastukset tarpeen mukaan suunnitellut toimet sankarillisten ponnistelujen sijaan.
- Anna tulosten automaattisesti ohjata riskienhallintasuunnitelmasi ja parannusjonosi päivityksiä.
Tuo yhteinen kuva on tärkeä myös vaatimustenmukaisuustiimin ulkopuolella:
- Teknologiajohtajat ja tietohallintojohtajat katsovat jossa redundanssi on todistettu ja jossa yksittäisiä vikakohtia on edelleen.
- Alustan, SRE:n ja live-opsien johtajat näkevät, mistä parannuksista he ovat vastuussa ja miten niitä mitataan.
- Rahoitus- ja lakiasiainosasto näkee, miten selviytymiskyky on kytköksissä kaupallisiin sitoumuksiin, sopimuksiin ja alustavelvoitteisiin.
Kun seuraava suuri lanseeraus tai ISO 27001 -vierailu koittaa, et joudu ryntäämään työkalujen ja aikavyöhykkeiden välillä. Näytät, miten studiosi ajattelee riskeistä, miten redundanssi suunnitellaan ja testataan ja miten opit jatkuvasti todellisista tapahtumista. Jos haluat pyörittää live-pelejä näin, ISMS:n aloittaminen ISMS.online-palvelussa yhdelle lippulaivapelille ja sen kriittisille riippuvuuksille on vähäriskinen tapa antaa tiimillesi tarvittava itseluottamus ja hallinta.
