Miksi pelien redundanssi epäonnistuu: ISO 27001 A.8.14 Riskit ja todelliset ratkaisut

Miksi "redundanssi" epäonnistuu niin usein ensimmäisenä pelikatkoksissa?

Pelaamisessa redundanssi usein epäonnistuu, koska kaaviot piilottavat jaettuja riippuvuuksia ja testaamattomia vikasietopolkuja, jotka katkeavat vain todellisen kuormituksen alla. Kun näin tapahtuu, pelaajat tuntevat vaikutukset kauan ennen kuin sisäiset kojelaudat tai auditointidokumentit ehtivät perille, ja turvalliselta "varmuuskopiolta" näyttänyt ratkaisu osoittautuu jälleen yhdeksi yksittäiseksi vikakohdaksi.

Korkean käytettävyyden pelaaminen tarkoitti ennen "yrittää olla kaatumatta julkaisupäivänä", mutta nyt se tarkoittaa alustan toiminnan, oikeudenmukaisuuden ja datan turvaamisen varmistamista, vaikka komponentit vikaantuisivat. Käytännössä monet pelikatkokset alkavat paikoista, joita tiimit pitivät tarpeettomina, koska piilevät yksittäiset vikaantumiskohdat ja testaamattomat oletukset ilmenevät vain todellisen stressin alla. Jos haluat A.8.14:n suojaavan nimikkeitäsi ja kaupallisia sitoumuksiasi, sinun on käsiteltävä redundanssia selitettävänä ja testattavana järjestelmäkäyttäytymisenä, ei kaavion rastitettavana ruutuna.

Tyypillisestä verkkopelien pinosta katsottuna sinulla saattaa jo olla useita palvelimia, automaattisesti skaalautuvia ryhmiä tai "multi-AZ" käytössä. Silti yksi väärin määritetty reitti, jaettu DNS-palveluntarjoaja tai hauras ohjaustaso voi silti kaataa kaiken. Se, mikä kaaviossa näyttää tarpeettomalta, on usein todellisuudessa tiiviisti sidoksissa toisiinsa, varsinkin kun käyttöönotto, konfigurointi ja valvonta riippuvat kaikki yhdestä polusta, jonka ylemmät sidosryhmät olettavat turvallisesti hajautetuksi.

Todellinen vikasietoisuus alkaa siitä, kun oletat jokaisen varmuuskopion epäonnistuvan ensimmäisellä kerralla.

Redundanssin illuusio live-peleissä

Näennäinen redundanssi voi olla vaarallisen lohduttavaa live-peleissä, koska päällekkäiset komponentit ovat edelleen riippuvaisia samoista hauraista palveluista. Näet useita instansseja, useita vyöhykkeitä, terveystarkastuksia ja toissijaisen alueen ja oletat olevasi turvassa; etäältä arkkitehtuurisi näyttää vikasietoiselta useiden instanssien, vyöhykkeiden ja automaattisen korjauksen ansiosta. Stressin alla huomaat usein, että monet polut yhtyvät yhteen identiteetintarjoajaan, yhteen DNS-alustaan tai yhteen ohjaustasoon ja että "varalla" olevat elementit mätänevät hiljaa, koska kukaan ei käytä niitä skaalautuvasti:

useat komponentit piilottavat jaetun riippuvuuden, kuten yhden identiteetintarjoajan, DNS-palvelun tai ohjaustason;
vikasietopolkuja on olemassa paperilla, mutta niitä ei ole koskaan käytetty realistisella kuormituksella; ja
"Valmiustilassa" olevat komponentit hajoavat hiljaa, koska valvonta keskittyy vain aktiiviseen polkuun.

Pelialalla tällä on suurempi merkitys kuin monilla muilla toimialoilla. Pelaajat huomaavat millisekuntien ylimääräisen viiveen, epäonnistuneita otteluliittymiä tai puuttuvia varastoja. Kun yksi heikko lenkki katkeaa, näkyvä vaikutus räjähtää: jonot pysähtyvät, ostokset jumiutuvat, kosmetiikka katoaa ja sosiaalisen median kanavat täyttyvät kuvakaappauksista, jotka tavoittavat nopeasti johdon.

Miten katkokset todella kasautuvat pelialustoilla

Pelialustojen käyttökatkokset seuraavat yleensä ennustettavaa ketjua: pieni tekninen häiriö kasvaa pelaajan näkyväksi romahdukseksi, koska järjestelmiä ei ole koskaan suunniteltu tai testattu kokonaisvaltaisena redundanttina kokonaisuutena. Tämän ketjureaktion ymmärtäminen auttaa sinua päättämään, missä A.8.14-redundanssin on oltava vahvin sekä pelaajakokemuksen että tulojen suojaamiseksi.

Vaihe 1 – Alhaisen tason vika ilmenee

Solmu kaatuu, saatavuusvyöhyke toimii virheellisesti tai verkkomuutos otetaan käyttöön virheellisesti ruuhka-aikaan.

Vaihe 2 – Ydinpalvelu alkaa horjua

Matchmaking, aula tai API-yhdyskäytäväsi alkaa aikakatkaista, rajoittaa tai katkaista yhteysyrityksiä.

Vaihe 3 – Tukipalvelut varmuuskopioidaan

Maksujonot kasvavat, chat-yhteydet katkeavat, tulostaulukoiden päivittyminen lakkaa ja telemetria jää jälkeen.

Vaihe 4 – Pelaajan kokemus romahtaa

Pelaajat näkevät yhteyskatkoksia, peruutettuja edistymisprosesseja, kadonneita ostoksia ja hämmentäviä virheilmoituksia eri tiloissa.

Vaihe 5 – Liiketoimintaan ja sääntelyyn liittyvät riskit nousevat pintaan

Hyvitykset piilevät, kumppanit valittavat ja sisäiset johtajat tai sääntelyviranomaiset esittävät vaikeita kysymyksiä.

Redundanssi, joka kattaa vain ensimmäisen hypyn (ylimääräiset solmut), mutta ei päästä päähän -virtaa, ei täytä pelaajien, kumppaneiden tai ISO 27001 -standardin vaatimuksia.

Läheltä piti -tilanteista oppiminen, ei vain katastrofeista

Läheltä piti -tilanteet ovat arvokkaimpia redundanssitestejä, koska ne paljastavat heikon käyttäytymisen ennen vakavaa sähkökatkosta. Lyhytaikaiset viivepiikit, kapeat alueelliset ongelmat tai osittaiset ominaisuusviat osoittavat tarkalleen, missä varmistukset eivät kestäneet todellisen kuormituksen alla, ja niistä on helpompi keskustella rauhallisesti johdon kanssa kuin täydellisistä sähkökatkoksista. Sinun ei tarvitse odottaa katastrofaalista katkosta nähdäksesi, missä redundanssi on heikko; jos tallennat lyhytaikaiset ongelmat yksinkertaiseen läheltä piti -lokiin ja kysyt, mikä redundanssilupaus petti tässä?, näet nopeasti malleja, kuten:

yhdestä tietystä palvelusta tulee toistuvasti pullonkaula kuormituksen alaisena;
toissijainen alue, joka ei pysty käsittelemään todellista liikennettä; tai
kolmannen osapuolen riippuvuus, joka ei siirry vikasietoisuuteen odotetulla tavalla.

Käsittele näitä tuotannon lahjoittamina ilmaisina kaaostesteinä. Ne ovat juuri sellaista syötettä, jota haluat käyttää riskinarviointiisi, liiketoimintavaikutusanalyysiisi (BIA) ja lopulta A.8.14-suunnittelupäätöksiisi. Ajan myötä niistä tulee vahva todiste siitä, että opit aktiivisesti epäonnistumisista sen sijaan, että vain toivoisit, ettet toista niitä, mikä rauhoittaa sekä tilintarkastajia että ylemmän tason sidosryhmiä.

Varaa demo

Mitä ISO 27001 A.8.14 -standardi todellisuudessa vaatii pelialustoilta?

ISO 27001:2022 -standardin liitteen A kohdan A.8.14 mukainen vaatimus edellyttää, että toteutat riittävän redundanssin tietojenkäsittelylaitoksissasi luvattujen käytettävyystasojen saavuttamiseksi. Pelialustan osalta tämä tarkoittaa sen osoittamista, että kriittiset palvelut toimivat edelleen hyväksyttävästi pelaajille ja kumppaneille realististen solmu-, vyöhyke- tai palveluvikojen aikana ja että tämä vikasietoisuus on suunniteltu, testattu ja perusteltu eikä oletettu.

Kontrolliteksti on lyhyt, mutta tilintarkastajat odottavat selkeää kerrosta, joka yhdistää ilmoitetut käytettävyystavoitteesi konkreettisiin redundanssivalintoihin ja -testeihin. Peliorganisaatioiden kohdalla tämä kerros sijaitsee live-op-suorituskyvyn, sopimusvelvoitteiden ja liiketoiminnan jatkuvuuden leikkauspisteessä: et suojaa vain käyttöaikalukuja, vaan suojaat myös julkaisuikkunoita, tuloennusteita ja brändin mainetta.

Käytännön tasolla A.8.14 pyytää sinua tekemään neljä asiaa:

Vaihe 1 – Määritä saatavuusvaatimukset

Päätä ja dokumentoi kunkin merkittävän palvelun todellinen käyttöaika ja palautumisaika.

Vaihe 2 – Poista tai lievennä yksittäisiä vikaantumiskohtia

Tunnista ja vähennä riippuvuuksia, joissa yksi epäonnistuminen voi kaataa koko matkan.

Vaihe 3 – Toteuta asianmukainen redundanssi

Suunnittele ja rakenna arkkitehtuureja, jotka kestävät sovitut vikaantumistilat budjettisi rajoissa.

Vaihe 4 – Testaa ja ylläpidä redundanssia

Harjoittele ja tarkista vikasietoisuutta säännöllisesti, jotta se toimii edelleen alustojen, ihmisten ja koodin muuttuessa.

Tietoturvallisuuden hallintajärjestelmäalusta, kuten ISMS.online, voi auttaa sinua linkittämään nämä neljä toimintoa tiettyihin kontrolleihin, riskeihin ja näyttöön, jotta suunnittelu ja päätökset pysyvät läpinäkyvinä ajan kuluessa.

Mikä lasketaan pelin "tiedonkäsittelylaitokseksi"?

ISO-standardin mukaisesti "tiedonkäsittelylaitos" on mikä tahansa tekninen ominaisuus, joka vastaanottaa, tallentaa, käsittelee tai välittää tavoitteidesi kannalta olennaista tietoa. Verkko- ja live-palvelupeleissä tämä menee paljon pelipalvelimia pidemmälle: se sisältää kaiken, minkä vikaantuminen keskeyttää avainpelaajan matkan, estää tulojen saamisen tai rikkoo sopimusta. Tämän luettelon selventäminen on usein ensimmäinen hyödyllinen A.8.14-harjoitus.

Verkko- ja live-palveluissa julkaistavien nimikkeiden osalta se sisältää yleensä seuraavat:

reaaliaikaiset komponentit, kuten pelipalvelimet, shardit, alueelliset ”pelin reunalla” toimivat pinot, matchmaking, aulat ja API:t;
alustapalvelut, mukaan lukien todennus, tilit, profiilit, oikeudet, inventaariot ja tulostaulukot;
kaupankäyntiohjelmistot maksuyhdyskäytäviä, ostoreskontraa ja petostentorjuntaa varten;
data- ja analytiikkapalvelut, jotka kattavat pelaajatilatallennukset, telemetrian, lokitiedot, mittarit ja dataputket;
tuki-infrastruktuuri, kuten DNS, CDN, web-käyttöliittymät, DDoS-estojärjestelmät, VPN:t ja identiteetintarjoajat; ja
ohjauspinnat, mukaan lukien orkestrointialustat, konfigurointi- ja ominaisuuslippupalvelut sekä CI/CD-käyttöönottovirrat.

Jos komponentin menetys keskeyttäisi kriittisen pelaajan matkan tai rikkoisi liiketoimintasitoumuksen, A.8.14 edellyttää, että harkitset asianmukaista redundanssia sen osalta.

Neuvottelukelvottomat vs. suunnittelun vapaus

A.8.14 ei sanele pilvipalveluntarjoajia tai topologioita; se välittää siitä, täyttääkö suunnittelusi omat saatavuustavoitteesi puolustettavissa olevalla tavalla. Voit vapaasti valita teknologioita, mutta et saa jättää huomiotta luvattujen palvelutasojen ja tukijärjestelmien vikasietoisuuden välistä yhteyttä. Tilintarkastajat haluavat nähdä jäljitettävän päättelyn, eivätkä tiettyä logoa kaaviossa, ja johtajat haluavat nähdä, että vikasietoisuuteen käytetty raha on sidottu selkeisiin liiketoiminnan tuloksiin.

Standardi ei määrää tiettyä teknologiapinoa. Sen sijaan se odottaa, että:

olet määrittänyt tarvitsemasi käytettävyyden, mukaan lukien käyttöaikatavoitteet, palautumisaikatavoite (RTO) ja palautumispistetavoite (RPO);
olet analysoinut, missä yksittäiset epäonnistumiset rikkoisivat nuo lupaukset; ja
voit osoittaa, että redundanssi- ja vikasietomekanismit ovat käytössä ja tehokkaita.

Se, miten tämä saavutetaan – usean AZ:n, usean alueen, aktiivisesti aktiivisen, lämpimän valmiustilan tai jonkin yhdistelmän – riippuu riskinottohalukkuudestasi, budjetistasi ja teknisistä rajoituksistasi. Olennaista on pystyä perustelemaan, että valittu suunnittelu on riittävä ja että johto hyväksyy mahdolliset jäännösriskit. Näiden päätösten dokumentointi keskitettyyn tietoturvan hallintajärjestelmään helpottaa huomattavasti myöhempiä tarkastuksia.

Missä A.8.14 pysähtyy ja muut säätimet alkavat

A.8.14 sijoittuu rinnakkain varmuuskopioinnin, liiketoiminnan jatkuvuuden, katastrofien jälkeisen palautumisen, tapahtumien hallinnan ja muutoshallinnan kanssa. Ne on helppo hämärtää, joten on hyödyllistä vetää yksinkertainen raja: redundanssi tarkoittaa "normaalien" häiriöiden yli selviytymistä, kun taas varmuuskopiointi ja katastrofien jälkeinen palautuminen koskevat palautumista suurista tapahtumista. Tällä erolla on merkitystä, kun selität sidosryhmille, miksi molemmat ovat välttämättömiä ja miksi kummallakin on oma budjettinsa ja omistajansa.

Yksinkertainen tapa erottaa ne on:

A.8.13 (tietojen varmuuskopiointi) ja liiketoiminnan jatkuvuuden valvonnan osalta palauttaminen palvelu ja data vakavien tapahtumien tai katastrofien jälkeen;
A.8.14 koskee valvominen "normaalien" vikojen kautta – solmujen kaatuessa, linkkien katketessa, palveluiden häiriintyessä, jopa saatavuusalueen katoamisen kautta.

Tilintarkastaja odottaa näkevänsä, että varmuuskopiointi- ja palautusstrategiasi sekä redundanssisuunnittelusi ovat yhdenmukaisia keskenään ja kaikki määriteltyjen palautumisaikojen (RTO) ja palautumisajan (RPO) kanssa. Kun nämä osat linkitetään tietoturvan hallintajärjestelmään (ISMS), voidaan osoittaa, että jatkuvuusajattelu on integroitu eikä sidottu toisiinsa. Tämä myös vakuuttaa ylemmälle johdolle, että resilienssiä on tarkasteltu alusta loppuun.

Tyypillisiä A.8.14-puutteita pelialan yrityksissä

Monet A.8.14-havainnot peli- ja SaaS-ympäristöissä eivät liity teknologiaan, vaan selkeyden ja dokumentaation puutteeseen. Auditoijat näkevät usein arkkitehtuureja, jotka näyttävät vahvoilta, mutta ovat heikosti perusteltuja tai joita ei ole koskaan testattu. Näiden ongelmien ennakointi antaa sinulle mahdollisuuden paikata aukkoja, kun sinulla on vielä aikaa ja budjettia.

Kun A.8.14 menee pieleen peli- tai SaaS-alustojen auditoinneissa, löydökset näyttävät usein tältä:

saatavuusvaatimukset on määritelty vain yleisenä käyttöaikalukuna, ei palvelukohtaisesti;
kaaviot, jotka osoittavat redundanssia, mutta joista puuttuvat dokumentoidut vikasietoisuusmenettelyt ja selkeät vastuut;
redundanssimekanismeja ei ole koskaan testattu realistisella kuormituksella tai pelaajakäyttäytymisellä;
kolmannen osapuolen palvelut (maksut, identiteetti, palvelunestohyökkäysten esto), jotka ovat kriittisiä, mutta joiden redundanssia ei ole arvioitu, ja
kuilut SRE:n hyväksyttävänä pitämän riskin ja johdon näkemyksen toteutumisen välillä.

Näiden mallien näkeminen ennen omaa auditointiasi antaa sinulle mahdollisuuden korjata ne suunnitteluasiakirjoissa, käytännöissä ja toiminnoissa sen sijaan, että selittäisit ne loppukokouksessa. Rakenteinen tietoturvan hallintajärjestelmä auttaa pitämään nämä parannukset näkyvissä, jotta ne selviävät henkilöstömuutoksista ja uusien julkaisujen lanseerauksista.

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

Miten A.8.14 muunnetaan pelien saatavuus-, RTO- ja RPO-tavoitteiksi?

Voit muuttaa A.8.14:n käytännön redundanssiksi kääntämällä sen selkeiksi käytettävyys-, RTO- ja RPO-tavoitteiksi kullekin merkittävälle pelipalvelulle. Kun tiedät, mitkä komponentit ovat tärkeimpiä ja kuinka kauan ne saavat olla poissa käytöstä tai menettää tietoja, voit suunnitella redundanssin, joka on vahva siellä, missä sillä on merkitystä, ja oikeasuhtainen siellä, missä sillä ei ole merkitystä.

Saatavuus ja redundanssi ovat järkeviä vain, jos ne on ankkuroitu eksplisiittisiin tavoitteisiin. Pelialustoilla nämä tavoitteet ovat harvoin yhdenmukaisia: rankattu matchmaking-palvelu, kosmetiikkakauppa ja analytiikkaputki eivät tarvitse samaa suojaustasoa. Näiden erojen näkyväksi tekeminen auttaa tietoturva-, operatiivisia ja tuotejohtajia sopimaan investointikohteista ja antaa tilintarkastajille ja johdolle yhteisen kielen kompromisseille.

A.8.14 edellyttää, että olet selkeä näiden erojen suhteen ja osoitat, miten redundanssivalinnat tukevat niitä. Tämä selkeys helpottaa myös kompromissien selittämistä kaupallisille johtajille, jotka välittävät tuloista, julkaisuikkunoista ja pelaajien mielipiteistä enemmän kuin teknisistä yksityiskohdista.

Porrasta pelikuormituksesi

Porrastuksen avulla vältät kaiken ylisuunnittelun ja suojaat silti pelaajille tärkeimmät asiat. Ryhmittelemällä palvelut pieneen määrään vaikutusperusteisia luokkia voit käydä kohdennettuja keskusteluja siitä, mihin kannattaa investoida vahvempaan redundanssiin ja missä yksinkertaisemmat toimenpiteet riittävät.

Käytännöllinen lähtökohta on luokitella palvelusi yksinkertaisiin tasoihin vaikuttavuuden ja kiireellisyyden perusteella. Esimerkiksi:

Taso 1 – reaaliaikainen pelaaminen ja olennaiset alustan API-rajapinnat. Häviö aiheuttaa välittömiä, näkyviä vaikutuksia pelaajiin ja kassavirtariskin, kuten esimerkiksi otteluiden hakuun, live-pelipalvelimiin, tilien tarkistuksiin ja oikeuksien validointiin.
Taso 2 – kriittiset, mutta hieman vähemmän aikaherkät palvelut.: Tappio sattuu nopeasti, mutta kestää lyhyitä häiriöitä, jos niitä käsitellään hyvin, esimerkiksi maksujen, varastojen, tulostaulukoiden ja todennuksen osalta.
Taso 3 – tärkeitä mutta viiveitä sietäviä komponentteja: Menetys on tuskallinen, mutta ei riko pelattavuutta välittömästi, kuten analytiikkaa, joitakin taustatoimintojen työkaluja ja osia telemetriasta.

Määrittele kullekin tasolle:

käyttöaikatavoite, joka sopii pelaajasi ja kumppanisi odotuksiin;
RTO – kuinka kauan kestät keskeytyksiä; ja
RPO – kuinka paljon tietojen menetystä tai palautusta olet valmis hyväksymään.

Konkreettinen esimerkki auttaa. Voit luokitella ”Ranked matchmaking in Europe” -työn tasolle 1, jonka käyttöaika on 99.95 %, RTO on 10 minuuttia ja RPO on yksi osuma. Alueellinen analytiikkatyö voi olla tasoa 3, jonka RTO on paljon pidempi ja jossa on toleranssi uudelleenkäsittelylle. Tämän kirjaaminen pakottaa selkeät keskustelut tuote-, operatiivisten ja kaupallisten liidien välille.

Yhdistä tavoitteet SLO:ihin ja virhebudjetteihin

Kun olet sopinut tasoistasi ja tavoitteistasi, seuraava vaihe on yhdenmukaistaa ne palvelutasotavoitteiden kanssa, joita jo käytät live-pelien pyörittämiseen. Useimmat kokeneet studiot ja julkaisijat käyttävät jo SLO:ita ja virhebudjetteja live-palveluiden hallintaan, ja A.8.14:n yhdistäminen kyseiseen kieleen pitää toiminnan vaatimustenmukaisuuden lähellä.

Monissa studioissa ja kustantajissa SRE-tiimit hallinnoivat jo julkaistujen nimikkeiden palvelutasotavoitteita ja virhebudjetteja. Uuden kielen luomisen sijaan kannattaa yhdistää ISO-tavoitteesi olemassa oleviin SLO-tavoitteisiin:

Jos matchmakingin SLO-tavoitteesi on 99.95 %:n kuukausittainen käyttöaika ja enimmäiskatkaisuprosentti, se on tason 1 käytettävyysvaatimuksesi; ja
Virhebudjettisi määrittää sitten, kuinka paljon seisokkiaikaa tai heikkenemistä voit "käyttää" ennen kuin rikot sekä sisäisiä että ISO-odotuksiasi.

Tämä linjaus estää A.8.14:n muuttumisen rinnakkaisuniversumiksi. Se auttaa myös selittämään suunnittelun kompromisseja tilintarkastajille ja johtajille käyttämällä samaa dataa, jota käytät pelin suorittamiseen.

Päätä, missä monialuejärjestelmää todella tarvitaan

Monialuesuunnittelu voi olla tehokasta, mutta se lisää kustannuksia ja monimutkaisuutta. A.8.14 ei vaadi monialuesuunnittelua kaikkialla; siinä pyydetään perustelemaan, missä tarvitset kyseistä suojaustasoa ja missä vahva yhden alueen monialuesuunnittelu ja katastrofien jälkeinen palautus riittävät. Päätöksen tulisi olla riskiperusteinen, eikä sitä saisi ohjata pelkästään muoti tai toimittajamarkkinointi.

Kaikki palvelut eivät vaadi täyttä, samanaikaista läsnäoloa useilla alueilla. Usean alueen aktiivinen käyttö on kallista ja monimutkaista. Kysy jokaiselle työkuormalle:

Onko alueellinen menetys realistinen riski, ottaen huomioon palveluntarjoajasi ja maantieteellisen sijaintisi?
Jos näin tapahtuu, mikä on sen vaikutus pelaajiin, tuloihin ja sääntelyyn?
Pystyisitkö saavuttamaan tavoitteesi vahvalla usean AZ-alueen suunnittelulla, lämpimällä toissijaisella alueella ja selkeällä palautussuunnitelmalla?
Onko olemassa lakisääteisiä tai sopimusvelvoitteita (esimerkiksi maksumääräyksiä tai tietojen säilytyslakeja), jotka ohjaavat sinua tiettyihin toimintatapoihin?

Tämän ajattelutavan dokumentointi riskinarvioinnissa ja sovellettavuuslausunnossa tekee tilintarkastajille selväksi, että irtisanomisvalinnat ovat harkittuja, eivät vahingossa tehtyjä. Se antaa myös johtajille ja kaupallisille tiimeille läpinäkyvän tavan tasapainottaa kustannuksia ja joustavuutta.

Käytä yksinkertaista pisteytysmallia suunnittelujen vertailuun

Kun useat eri mallit voisivat saavuttaa tavoitteesi, yksinkertainen pisteytysmalli estää keskusteluja muuttumasta pelkästään mielipidevetoisiksi. Punnitset vaihtoehtoja yhdenmukaisilla kriteereillä ja valitset malleja, jotka toistetaan eri nimikkeissä ja alueilla. Dokumentoiduista pisteistä tulee sitten osa A.8.14-todisteitasi, ja ne auttavat ylemmän tason sidosryhmiä näkemään, miksi tietyt vaihtoehdot valittiin.

Kun sinulla on useita mahdollisia malleja – esimerkiksi yhden alueen monialueinen AZ, usean alueen aktiivinen-passiivinen tai usean alueen aktiivinen-aktiivinen – voit pisteyttää ne muutamien yhdenmukaisten kriteerien perusteella:

vikaantumistapojen kattavuus – mitkä realistiset viat siedetään ja mitkä eivät;
käyttöönoton, toiminnan ja virheenkorjauksen monimutkaisuus;
aikaa toipua vakavista vaaratilanteista; ja
infrastruktuurin kulutuksen ja käyttökustannusten kustannukset.

Yksinkertainen ja toistettava pisteytysmenetelmä auttaa johtoa valitsemaan toimintamalleja eri tehtävien ja alueiden välillä ja myöhemmin selittämään näitä valintoja hallintofoorumeissa tai auditoinneissa. Kannattaa varata lyhyt työpaja nykyisten tasojen, tavoitteiden ja mallien kartoittamiseksi, jotta näet, missä kohtaa pisteet ja todelliset tulokset eivät enää vastaa toisiaan.

Mitkä redundanttiset arkkitehtuurimallit toimivat parhaiten live-pelien palveluihin?

Parhaat redundanttiset arkkitehtuurimallit live-pelien pelaamiseen ovat sellaisia, jotka suojaavat matalan latenssin työkuormia, skaalautuvat pelaajien kysynnän mukaan ja pysyvät ymmärrettävinä paineen alla. ISO 27001 A.8.14 -standardin osalta auditoijia ei kiinnosta, mitä teknologioita käytät; heitä kiinnostaa, että valitsemasi mallit sopivat käytettävyystavoitteisiisi ja riskiprofiiliisi ja että voit osoittaa, miten ne toimivat, kun asiat menevät pieleen.

Kun tiedät tarvitsemasi käytettävyystason, voit valita tiettyjä toimintamalleja sen saavuttamiseksi. Pelaamisessa näiden toimintamallien on noudatettava kahta tiukkaa rajoitusta: erittäin matalaa viivettä ja erittäin vaihtelevaa kuormitusta. Niiden on myös toimittava huijauksenestomallisi ja tapahtumien, turnausten ja kausittaisten sisältöjulkaisujen kaupallisten suunnitelmiesi kanssa.

Kuten jo todettiin, standardi ei määrää tiettyjä teknologioita. Sen sijaan tilintarkastajat odottavat valittujen mallien olevan linjassa omien tavoitteidesi ja riskianalyysisi kanssa. He haluavat myös nähdä, että tunnistat, missä monimutkaisemmat mallit tuovat mukanaan uusia riskejä, kuten aivojen jakautumisen skenaarioita tai tietojen epäjohdonmukaisuuksia, ja että sinulla on käytössä hallinto näiden riskien hallitsemiseksi.

Aktiivinen-aktiivinen vs. aktiivinen-passiivinen ydinpalveluissa

Vaikuttavien pelipalveluiden kohdalla valinta aktiivisen ja aktiivisen passiivisen välillä on harvoin mustavalkoinen. Aktiivinen-aktiivinen tarjoaa hillittyä heikkenemistä ja parempaa käyttöastetta, mutta voi vaikeuttaa huijauksenestoa, otteluiden reiluutta ja tilan hallintaa. Aktiivisen ja passiivisen yhdistelmän käyttö on helpompaa päätellä, mutta sitä on käytettävä säännöllisesti ikävien yllätysten välttämiseksi.

Reaaliaikaiseen pelaamiseen ja matchmakingiin:

Aktiivinen-aktiivinen: Kuviot (useita instanssien tai alueiden samanaikainen käyttö pelaajien parissa) tarjoavat erinomaisen joustavuuden, mutta voivat mutkistaa johdonmukaisuutta ja huijauksenestologiikkaa, ja ne myös lisäävät jatkuvia kustannuksia.
Aktiivinen-passiivinen: mallit (yksi alue käsittelee reaaliaikaista liikennettä, toinen on valmis ottamaan haltuunsa) voivat olla yksinkertaisempia ja halvempia, mutta ne on testattava perusteellisesti sen varmistamiseksi, että vikasieto toimii ruuhka-aikoina.

Usein päädytään sekoittamaan nämä kaksi: aktiivinen toiminta alueen sisällä vyöhykkeiden välillä ja lämmin toissijainen alue katastrofiskenaarioita varten. Tällainen hybridi on täysin hyväksyttävä A.8.14:n mukaisesti, kun pystytään osoittamaan, miten se täyttää asetetut tavoitteet, ja kun johto ymmärtää selvästi kustannusten ja sietokyvyn väliset kompromissit.

Istuntotietoinen vikasietoisuus

Istuntotietoinen vikasietoisuus tekee redundanssista todellista pelaajille varmistamalla, että istunnon tila voidaan siirtää tai palauttaa turvallisesti komponentin vikaantuessa. Reaaliaikaiset istunnot ovat redundanssisuunnittelun näkyvin osa, koska pelaajat tuntevat virheet välittömästi.

Reaaliaikaiset pelisessiot ovat luonteeltaan tilallisia. Redundanssin hyödyntäminen:

Suunnittele pelipalvelimet mahdollisuuksien mukaan tilattomina tai puolitilattomina siirtämällä auktoritatiivinen tila vankkoihin, replikoituihin säilöihin;
pidä istunnon tila siten, että solmun katoamisen yhteydessä voidaan muodostaa nopea uudelleenliittyminen, esimerkiksi käyttämällä pieniä, usein toistuvia tarkistuspisteitä tai peilattuja muistiruudukoita; ja
Tee asiakkaan uudelleenyhteyden muodostamisesta ja uudelleensynkronoinnista sujuvaa, jotta lyhytaikainen palvelimen katkeaminen ei näytä huijaukselta tai valittamiselta.

Tilintarkastajat eivät arvioi tikkitiheyttäsi tai pakettimuotoasi, mutta he välittävät siitä, ettei vikaantunut solmu tai vyöhyke aiheuta hallitsematonta tiedon menetystä tai määrittelemätöntä toimintaa. He arvostavat myös tapahtuman jälkeisiä tarkastuksia, joissa olet säätänyt istunnonkäsittelylogiikkaa oppittuasi virheistä.

Tukipalvelut ensiluokkaisina kansalaisina

Monet vakavat käyttökatkokset eivät johdu pelikoodista, vaan tukipalveluista, joita pidettiin hyödykkeinä, kunnes ne kaatuivat. A.8.14 edellyttää, että käsittelet näitä palveluita osana tietojenkäsittelyjärjestelmiäsi, koska ne ovat usein todellisia yksittäisiä vikaantumiskohtia nykyaikaisissa järjestelmissä.

Esimerkkejä ovat:

DNS-katkokset tai virheelliset määritykset;
CDN-reititys- tai välimuistiongelmat;
identiteetintarjoajan toimintahäiriöt; ja
maksuyhdyskäytäväongelmat.

Kohdan A.8.14 mukaisesti näitä tulisi käsitellä itsenäisinä kriittisinä tiedonkäsittelylaitoksina. Tämä tarkoittaa usein seuraavaa:

kahden palveluntarjoajan DNS tai ainakin kaksi ohjaustasoa erillisillä tunnistetiedoilla;
useita CDN- tai reunakonfiguraatioita kriittisille alueille; ja
vankat vikasietoiset prosessit identiteetin ja maksujen hallintaan sekä selkeät liiketoimintasäännöt heikentyneille toimintatiloille.

Kun harkitset redundanssia, jäljitä koko pelaajan matka päästä päähän, äläkä pelkästään pelin sisäistä liikennettä. Esimerkiksi alueellinen DNS-ongelma, joka estää kirjautumissivut, vahingoittaa yhtä paljon kuin pelipalvelimen kaatumiset, ja johtajat kokevat sen etusivun katkona teknisestä perimmäisestä syystä riippumatta.

Orkestrointi, konfigurointi ja salaisuudet

Orkestrointi-, konfigurointi- ja salaisuuskerrokset määrittävät, voitko alustaasi käyttää ja palauttaa sen turvallisesti. Jos jokin näistä on yhden kerroksen tasoinen, niistä tulee piilotettuja yksittäisiä vikaantumiskohtia, jotka ilmestyvät vain silloin, kun yrität tehdä laajamittaisen muutoksen tai hätätilanteessa vikasietoisuuden. Tilintarkastajat kysyvät yhä useammin näistä tasoista, koska he ovat nähneet niiden rikkovan todellisia katastrofien palautussuunnitelmia muuten hyvin suunnitelluissa ympäristöissä, ja orkestrointialustasi, konfiguroinnin hallinta ja salaisuusvarastot ovat myös osa redundanssikerrosta:

Jos menetät yhden kokoonpanojärjestelmän etkä voi ottaa sitä käyttöön tai skaalata turvallisesti, se on piilevä yksittäinen vikaantumispiste;
jos salaisuudet tallennetaan vain yhteen alueeseen tai yhteen järjestelmään, vikasietopolut voivat olla käyttökelvottomia silloin, kun niitä eniten tarvitaan; ja
Jos orkestrointiohjaustasot eivät itsessään ole erittäin käytettäviä, ne saattavat estää osittain vikaantuneen klusterin palauttamisen.

Yksinkertainen esimerkki on yksi ainoa konfiguraatiotietokanta, jota kaikki alueet jakavat. Jos se epäonnistuu korjauspäivityksen aikana, et ehkä pysty turvallisesti palauttamaan vanhaa tai reitittämään liikennettä pois ongelma-alueelta. Näiden kerrosten suunnittelu siten, että ne ovat vikasietoisia eivätkä estä tai vioita vikasietoisuutta hiljaisesti, ja sitten kyseisen suunnittelun ja siihen liittyvien kontrollien dokumentointi antaa tilintarkastajille ja kaupallisille johtajille varmuuden siitä, että redundanssioletukset ovat realistisia.

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

Varaa esittelysi

Miten monialueiset pilvisuunnittelut yhdistetään suoraan A.8.14-standardiin?

Usean alueen pilviratkaisut vastaavat A.8.14-standardia selittämällä, mitä vikoja kukin ratkaisu on sietänyt ja miten se tukee käytettävyys-, RTO- ja RPO-tavoitteitasi. Pilvipalveluiden toimittajat tarjoavat tehokkaita ominaisuuksia, mutta ISO 27001 -standardissa on tärkeämpää niiden yhdistäminen kuin palveluiden nimet, ja ei-tekniset sidosryhmät tarvitsevat selkeän ja ymmärrettävän selityksen.

Useimmat nykyaikaiset pelialustat ovat riippuvaisia ainakin yhdestä merkittävästä pilvipalveluntarjoajasta ja usein useista hallituista palveluista. ISO 27001 -standardi ei muuta tätä; se yksinkertaisesti odottaa, että käytät näitä rakennuspalikoita harkitulla, riskiperusteisella tavalla. Kun voit yhdistää alueet, vyöhykkeet, hallitut palvelut ja liikenteenhallintajärjestelmät suoraan liiketoiminnan ja pelaajien tuloksiin, olet myös paremmassa asemassa saamaan tukea kriisinsietokykyyn tehtäville investoinneille hallitustasolla.

Tilintarkastajat eivät ole pilvipalvelusi valikoiden asiantuntijoita, mutta he odottavat näkevänsä, miten nämä rakenteet täyttävät kontrollin tarkoituksen. Monet ovat nähneet vastaavia ympäristöjä muilla asiakkailla, joten selkeä kartoitus auttaa heitä ymmärtämään suunnittelusi nopeasti sen sijaan, että kyseenalaistaisivat jokaisen palveluvalinnan.

Pilviominaisuuksien kartoittaminen tavoitteiden hallitsemiseksi

Olennaista on kääntää pilviominaisuudet selkokielisiksi hallintatavoitteiksi. Sen sijaan, että luettelisit jokaisen hallitun palvelun, selitä, mitä vikatiloja kunkin järjestelyn on tarkoitus sietää. Tämä selitys liitetään sitten suoraan riskinarviointiisi ja sovellettavuuslausuntoosi ja tukee hankinta- ja lakikeskusteluja toimittajariskeistä.

Aloita listaamalla pilviominaisuudet, joiden saatavuuteen luotat:

useita saatavuusvyöhykkeitä ja alueellisia pareja;
alueelliset tai globaalit kuormituksen tasaajat ja liikenteenhallintajärjestelmät;
hallitut tietokanta- ja välimuistipalvelut, joilla on usean AZ:n tai usean alueen ominaisuudet, ja
objektien tallennuksen replikointi- ja elinkaarikäytännöt.

Kuvaile sitten kutakin kriittistä pelityökuormaa varten:

mitä näistä ominaisuuksista se käyttää;
mitä vikoja ne on suunniteltu sietämään; ja
miten se vastaa käytettävyyttäsi, RTO:tasi ja RPO-tavoitteitasi.

Tämä kartoitus voi sisältyä arkkitehtuuridokumentteihisi ja siihen voi viitata riskinarvioinnissasi ja sovellettavuuslausunnossasi. Ajan myötä siitä tulee arvokasta koulutusmateriaalia uusille insinööreille ja viitekehys tilintarkastajille ja hallintofoorumeille.

Ajattele vikatiloja, älä vain ominaisuuksia

Nimettyjen vikatilojen suunnittelu selkeyttää keskusteluja ja helpottaa päätösten puolustamista. Sen sijaan, että sanoisit "käytämme usean AZ-alueen tietokantoja", voit sanoa "tämä palvelu selviää kokonaisen vyöhykkeen menetyksestä menettämättä sitoutuneita tietoja tai rikkomatta RPO:tamme". Tämä sanamuoto on paljon lähempänä tilintarkastajien ja liiketoiminnan sidosryhmien ajattelutapaa.

Kun päätät, riittääkö useampi vyöhyke vai tarvitaanko toinenkin alue, mieti betonin murtumistapojen eri vaiheita:

yksittäinen solmu tai pod vikaantuu;
saatavuusvyöhyke, jossa sähköt tai verkkoyhteys katkeavat;
alueellinen ohjaustaso-ongelma, joka estää skaalauksen tai kokoonpanon muutokset; ja
koko palveluntarjoajaa koskeva häiriö, joka vaikuttaa hallittuun palveluun.

Kysy jokaisen työmäärän kohdalla, mitkä näistä rikkoisivat sitoumuksiasi, ja osoita sitten, miten suunnittelusi käsittelee ne. Tämä lähestymistapa on sekä hyvä suunnittelukäytäntö että juuri sellainen päättely, jota tilintarkastaja odottaa näkevänsä. Se auttaa myös havaitsemaan epärealistiset oletukset ennen kuin niitä testataan tuotannossa.

Suunnittele ja testaa alueellinen vikasietoisuus

Alueellinen vikasietoisuus on totta vain, kun sitä on harjoiteltu. A.8.14 ei vaadi jatkuvaa vikasietoisuutta, mutta se odottaa sinun todistavan, että alueellista redundanssia voidaan käyttää turvallisesti ilman uusien riskien aiheuttamista. Tämä todiste tulee hyvin suunnitelluista testeistä, ei vain kaavioista.

Palveluissa, joissa olet riippuvainen toissijaisesta alueesta, pelkkä dokumentoitu suunnittelu ei riitä. Sinun tulisi:

määrittele selkeät skenaariot, joissa odotat vikasietoisuutta, mukaan lukien kynnysarvot ja päätöksentekijät;
luoda toimintasuunnitelmia ja automaatiota näiden vaiheiden johdonmukaiseksi suorittamiseksi; ja
testaa niitä säännöllisesti, mieluiten edustavalla kuormituksella ja realistisilla tiedoilla.

Näiden testien tiiviiden kirjausten pitäminen – mitä teit, mikä meni rikki, kuinka kauan se kesti ja mitä paransit – tarjoaa vahvaa A.8.14-todisteita ja yleensä paljastaa heikkouksia, jotka voit korjata ennen todellista ongelmaa. Nämä tiedot auttavat myös muita kuin teknisiä sidosryhmiä näkemään vikasietoisuuden hallittuna liiketoimintapäätöksenä, ei viimeisen päälle tehtävänä uhkapelinä, joka saattaisi uhata lanseerauksia tai kumppanuuksia.

Ota huomioon lakisääteiset ja sääntelyyn liittyvät rajoitukset

Sääntely- ja sopimusvelvoitteet voivat kaventaa suunnitteluvaihtoehtojasi, erityisesti datan sijainnin ja rahoituspalveluiden osalta. A.8.14 edellyttää, että redundanssi kunnioittaa näitä rajoituksia sen sijaan, että niitä käsiteltäisiin jälkikäteen. Tämä tarkoittaa laki- ja tietosuojatiimien integrointia suunnittelun alkuvaiheen keskusteluihin sen sijaan, että heiltä pyydettäisiin vain hyväksyntää lopussa.

Tietojen säilytyslait, maksumääräykset ja välttämättömiä palveluita koskevat direktiivit voivat kaikki vaikuttaa redundanssin suunnitteluun:

saatat tarvita tiettyjä tietoja pysyäksesi tietyllä alueella tai maaryhmässä;
maksupalvelut saattavat vaatia erityisiä valvontatoimia tai erillisiä alueita; ja
Kriittisen infrastruktuurin sääntely voi asettaa odotuksia jatkuvuudelle ja häiriöiden raportoinnille.

Kirjaa nämä rajoitteet riskinarviointiisi ja suunnitteluusi, jotta redundanssimallit ovat sekä ISO 27001 -standardin että paikallisten velvoitteiden mukaisia. Kun myöhemmin esittelet arkkitehtuurin ja toimittajavalinnat auditoinnissa, tämä yhdenmukaisuus vakuuttaa sekä auditoijille että sääntelyviranomaisille, että resilienssiä ja vaatimustenmukaisuutta hallitaan yhdessä, ja se vähentää viime hetken oikeudellisten esteiden riskiä teknisissä suunnitelmissa.

Miten verkon, laskennan, tietokannan ja tilan redundanssi tulisi priorisoida?

Sinun tulisi priorisoida redundanssi tasoille, jotka pelaajat kokevat ensisijaisesti – verkko, laskenta ja istunnon tila – ennen kuin murehdit syvemmästä analytiikan sietokyvystä. A.8.14 on riskiperusteinen, joten sen avulla voit aloittaa sieltä, missä katkokset ovat näkyvimpiä pelaajille ja kumppaneille, ja vahvistaa syvempiä kerroksia, kun ydinkokemus on vankka.

Kaikki redundanssi ei tuo samaa tuottoa. Reaaliaikaisessa moninpeliympäristössä verkko- ja laskentahäiriöt vaikuttavat usein ensin; tietokannan ja pitkän aikavälin tilan vaikutukset näkyvät yleensä hieman pidemmällä aikavälillä. Tämän prioriteetin selkeä ilmaiseminen auttaa selittämään sijoituspäätöksiä talous- ja tuotejohtajille sekä tilintarkastajille.

A.8.14 tukee tärkeimpien hallintajärjestelmien priorisointia. Voit aloittaa sieltä, missä katkokset ovat pelaajille ja kumppaneille näkyvimpiä, ja parantaa sitten syvempiä kerroksia, kun etulinjan kokemus on joustava.

Keskity ensin siihen, mitä pelaajat tuntevat

Pelaajien havaitsema suorituskyky on redundanssin perimmäinen testi. Jos suunnittelusi selviää muutamista solmujen kaatumisista, mutta pysäyttää aulat tai menettää varastoja, pelaajat pitävät sinua silti epäluotettavana.

Latenssiin, katkoksiin ja reiluuteen suoraan vaikuttavien kerrosten priorisointi yhdenmukaistaa suunnittelutyösi brändilupaustesi ja kaupallisten ennusteidesi kanssa. Kriittisessä, hetkestä hetkeen -silmukassa kysy, mitkä kerrokset ohjaavat suoraan:

latenssi ja jitter;
katkaisut ja epäonnistuneet liittymiset;
epäreilut lopputulokset, kuten huijaukselta näyttävät peruutukset; ja
esineiden tai valuutan näkyvä menetys.

Yleensä huomaat, että:

verkon redundanssi: – useita polkuja, laitteita ja palveluntarjoajia sekä vikasietoinen reititys ja palvelunestohyökkäysten suojaus – on välttämätöntä; ja
laskennan redundanssi: – klusteroitujen ja automaattisesti skaalautuvien pelipalvelinten ja API-rajapintojen, jotka kestävät solmujen ja saatavuusalueiden menetyksen, käyttö ei ole neuvoteltavissa.

Jos jompikumpi on heikko, mikään määrä eleganttia tietokannan replikointia ei pelasta pelaajakokemusta virheen sattuessa. Tämän prioriteetin selkeä määrittäminen auttaa myös selittämään talous- ja tuotetiimeille, miksi tietyt investoinnit ovat etusijalla.

Taulukko: esimerkki prioriteeteista kerroksen mukaan

Tämä taulukko näyttää, miten voit priorisoida redundanssi-investointeja teknisen kerroksen mukaan live-palvelupelissä. Se ei ole vakiovaatimus, vaan yksinkertainen opas sisäisiin keskusteluihin.

kerros	Ensisijaisen pelaajan vaikutus	Tyypilliset ensimmäiset kohteet
verkkotuotteet	Viive, katkokset, aluekatkokset	Kaksi palveluntarjoajaa, vikasietoinen reititys, DDoS-hyökkäysten hallinta
Laskea	Kaatumiset, tyhjät aulat, API-aikakatkokset	N+1 solmua, usean AZ-klusterin, automaattinen skaalaus
Istunnon tila	Hävityt ottelut, peruutukset, epäreilut tapahtumat	Ulkoiset tilatallennustilat, nopeat uudelleenkytkentäpolut
Tietokannat	Menetetty edistyminen, jumissa olevat ostokset	Usean AZ-alueen replikat, varmuuskopiot, tyhjennetyt RPO:t
Analytiikka/liiketoimintatiede	Viivästynyt oivallus, hitaampi viritys	Varmuuskopiot, palautussuunnitelmat, porrastetut palvelutasosopimukset

Käytä arkkitehtuuri- ja riskityöpajoissa samankaltaista, pinollesi räätälöityä taulukkoa. Sen avulla insinöörit, SRE:t, tuoteomistajat ja tietoturvatiimit voivat nopeasti yhdenmukaistaa seuraavan redundanssiyksikön.

Rakenna redundanssi havaittavuuteen ja kapasiteettiin

Redundanssista on hyötyä vain, jos tiedät, milloin se on terve ja milloin se on ajautunut. Redundanssi, jota et voi nähdä tai mitata, ei ole todellista, joten havaittavuus ja kapasiteettisuunnittelu ovat siksi osa A.8.14:ää, eivät erillisiä huolenaiheita. Kun redundanssia valvotaan eksplisiittisesti, on todennäköisempää, että hiljaiset viat havaitaan varakomponenteissa ja alivarustetuilla alueilla ennen kuin ne aiheuttavat näkyviä katkoksia. Kun vahvistat kutakin kerrosta:

lisätä varakomponenteille erityisiä kuntotarkistuksia ja hälytyksiä, kuten replikoinnin viive, vikasietoisuus ja alueelliset kapasiteettikynnykset;
määritellä kriittisten palvelujen ”vähimmäisturvallinen liikkumavara” ja seurata sitä, esimerkiksi vaadittua vapaata kapasiteettia kullakin saatavuusvyöhykkeellä tai -alueella, ja
lisää yksinkertaisia kojelaudan näkymiä, jotka yhdistävät nämä signaalit A.8.14-tavoitteisiisi ja SLO-tavoitteisiisi.

Nämä toimenpiteet eivät ainoastaan lisää turvallisuutta, vaan ne myös tuottavat juuri sellaista operatiivista näyttöä, jota tilintarkastajat haluavat nähdä. Ajan myötä niistä tulee rutiininomainen hygieniatyö erityisestä "tarkastusvalmistelusta", ja ne antavat johtajille enemmän luottamusta siihen, että riskejä hallitaan ennakoivasti.

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

Varaa esittelysi

Miten hallinnoit ja todisteet A.8.14 peliyhtiön tarkastuksia varten?

Hallitset ja todennat A.8.14-vaatimusta tekemällä redundanssipäätöksistä osan tietoturvallisuuden hallintajärjestelmääsi, etkä vain insinööritieteen mukaisia perinteitä. Tämä tarkoittaa sitä, että määrittelet kuka päättää mitä, miten nämä päätökset kirjataan, miten niitä testataan ja miten ne liittyvät liiketoiminnan tuloksiin, kuten lanseerausluottamukseen ja auditointien yllätysten vähenemiseen.

Redundanssipäätökset eivät ole vain insinööritieteen aihe. ISO 27001 -standardin mukaan ne ovat osa tietoturvallisuuden hallintajärjestelmääsi ja kuuluvat hallinnon, tarkastelun ja jatkuvan parantamisen piiriin. Kun hallinto on selkeää, johtajat näkevät resilienssityön hallittuna investointina loputtomana kustannuksena.

Sinun on pystyttävä osoittamaan, kuka päätti mitäkin, miksi he päättivät niin, miten se toteutetaan ja miten tiedät sen edelleen toimivan. Tietoturvallisuuden hallintajärjestelmän (ISMS) käyttö ISMS.onlinen kaltaisen alustan avulla näiden tietojen keskittämiseen voi vähentää merkittävästi vaivaa ennen auditointeja, lanseerauksia ja hallituksen tarkastuksia.

Roolien ja päätösoikeuksien selkeyttäminen

Selkeät roolit estävät "vahingossa tapahtuvan suunnittelun" ja varmistavat, että riskinotto tapahtuu oikealla tasolla. Kun ihmiset tietävät, kuka omistaa saatavuustavoitteet, arkkitehtuurivalinnat ja testauksen, vältetään aukot, joissa kaikki olettavat jonkun muun ottaneen vastuun.

Aloita tekemällä selväksi:

kuka vastaa saatavuus- ja jatkuvuusvaatimusten määrittelystä;
kuka suunnittelee redundanssi- ja vikasietoarkkitehtuureja;
kuka käyttää järjestelmiä päivittäin ja suorittaa harjoituksia; ja
kenellä on valtuudet hyväksyä jäännösriski, kun redundanssi on rajallinen.

Tämän kirjaaminen käytäntöihin, peruskirjoihin tai RACI-matriiseihin antaa tarkastajille varmuuden siitä, että redundanssia ei suunnitella epämuodollisesti. Se auttaa myös laki-, tietosuoja- ja kaupallisia tiimejä ymmärtämään, kenelle asiakkaiden ja sääntelyviranomaisten odotuksiin liittyvät huolenaiheet tulee osoittaa, ja se helpottaa johdon näkemään, että joku on nimenomaisesti vastuussa käynnistys- ja käyttöaikariskistä. Tällainen selkeys tukee myös suoraan ISO 27001 -standardin kohtaa 5 johtajuudesta, rooleista ja vastuista.

Tiedä, mitä evidenssiä tilintarkastaja odottaa

A.8.14 Todisteiden on osoitettava, että redundanssikerroksesi on todellinen, johdonmukainen ja sitä ylläpidetään ajan kuluessa. Auditoijat eivät vaadi täydellisyyttä, mutta he odottavat johdonmukaista joukkoa asiakirjoja ja tallenteita, jotka vastaavat insinöörien väitteitä tuotannossa toiminnasta.

A.8.14:n osalta yleisiin todisteisiin kuuluvat:

nykyinen arkkitehtuuri ja verkkokaaviot, jotka osoittavat redundanssin solmu-, vyöhyke-, alue- ja palveluntarjoajatasolla;
saatavuus-, RTO- ja RPO-matriisi palvelu- tai tasokohtaisesti;
liiketoiminnan jatkuvuus- ja palautumissuunnitelmat, joissa kuvataan vikasietoisuuden lähestymistavat ja vastuut;
vikasietoharjoitusten, alueellisten evakuointien ja palautumistestien tiedot, mukaan lukien tulokset;
tapausraportit, joissa redundanssilla tai jatkuvuudella oli merkitystä, ja tekemäsi toimenpiteet; ja
toimittajien tietoturvatarkastukset ja palvelutasosopimukset kriittisimmille riippuvuuksille.

Jos pidät nämä artefaktit hajallaan työkaluissa ja tiimeissä, auditoinneista tulee tuskallisia ja käynnistyspäätökset hitaampia. Jos pidät ne järjestyksessä ja linkitettyinä tiettyihin kontrolleihin ja riskeihin, auditoinneista tulee paljon ennustettavampia ja johtajat saavat nopeammin ja selkeämmän käsityksen resilienssitilanteesta. ISMS.online on suunniteltu tallentamaan ja linkittämään tätä materiaalia, jotta voit siirtyä "dokumenttien metsästyksestä" yksinkertaiseen todisteiden hakuun.

Älä unohda kolmansien osapuolten ja toimittajien irtisanomisia

Kolmannen osapuolen palvelut ovat nykyään lähes jokaisessa kriittisessä peliprosessissa. Maksupalveluntarjoajat, identiteettipalvelut, huijauksenesto, CDN ja analytiikka-alustat saattavat olla koodikantasi ulkopuolella, mutta ne ovat silti osa lupaamaasi kokemusta. Ne kaikki sijaitsevat kriittisillä poluillasi ja saattavat olla suoran hallintasi ulkopuolella, mutta A.8.14 edellyttää, että ymmärrät ja hallitset niiden tarjoamaa redundanssia sen sijaan, että olettaisit niiden markkinointiviestien automaattisesti vastaavan tarpeitasi. Tarkemmin sanottuna sinun tulisi:

ymmärrä, miten ne tarjoavat sinulle redundanssia ja jatkuvuutta;
heijastaa tätä ymmärrystä riskienhallinta- ja toimittajanhallintaprosesseissasi; ja
on suunnitelmia siitä, mitä teet, jos ne epäonnistuvat.

Tämä ei tarkoita kaikkien toimittajien kopioimista, mutta se tarkoittaa selkeää näkemystä siitä, mitkä ovat yksittäisiä epäonnistumiskohtia ja miten hallitset tätä riskiä. Joissakin tapauksissa päätät luottaa yhteen toimittajaan ja käsittelet sitä nimenomaisesti hyväksyttynä jäännösriskinä, joka on dokumentoitu riskirekisteriisi ja hyväksytty oikealla tasolla. Laki- ja kaupallisten tiimien tulisi olla mukana näissä keskusteluissa, koska sopimusehdot ja palvelutasoa koskevat sitoumukset ovat yhtä tärkeitä kuin tekniset ominaisuudet, kun toimittaja epäonnistuu suuren lanseerauksen tai myynninedistämistapahtuman aikana.

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

ISMS.online tarjoaa käytännöllisen tavan muuttaa A.8.14-redundanssityösi yhtenäiseksi, auditointivalmiiksi kokonaisuudeksi, joka kattaa riskit, suunnittelun, testauksen ja todisteet pelialustoillasi. Laskentataulukoiden, dokumenttien ja heimojen tuntemuksen jonglööraamisen sijaan tuot kaiken yhteen ympäristöön, joka tukee sekä insinöörejä että auditoijia ja antaa johtajille selkeämmän kuvan resilienssistä.

Alusta on suunniteltu auttamaan sinua yhdistämään kaiken edellä kuvatun: riskianalyysin, saatavuustavoitteet, arkkitehtuuripäätökset, toimittaja-arvioinnit, testit ja auditointien tulokset. Peliorganisaatioille tämä tarkoittaa redundanssiin liittyvän todellisen suunnittelutyön muuttamista sertifioitavaksi narratiiviksi, joka kestää tarkastelun ja tukee luottavaisia lanseeraus- ja investointipäätöksiä.

Nämä tiedot ovat yleisiä eivätkä ole oikeudellisia tai sääntelyyn liittyviä neuvoja; erityisiä päätöksiä tehdessä kannattaa kääntyä pätevien ammattilaisten puoleen. ISMS.online tarjoaa kuitenkin rakenteen: tavan osoittaa, että olet ajatellut saatavuutta, tehnyt tietoisia suunnitteluvalintoja ja testannut niitä toistettavissa olevalla tavalla.

Arkkitehtuurin, riskien ja kontrollien yhdistäminen samaan paikkaan

Voit käyttää ISMS.online-työkalua pitääksesi redundanssisuunnittelun, riskienhallinnan ja kontrollin todisteet yhdenmukaisina sen sijaan, että ne hajautettaisiin eri työkaluihin. Tämä helpottaa teknisten ja ei-teknisten johtajien hahmottamaan, miten peliarkkitehtuurivalinnat tukevat ISO 27001 -standardia ja muita viitekehyksiä ilman, että heidän tarvitsee tulkita useita ristiriitaisia dokumentteja.

ISMS.online-sivustolla voit:

mallinna pelialustasi laajuus – nimikkeet, jaetut alustapalvelut ja alueet – ja linkitä ne liitteen A kontrolleihin, mukaan lukien A.8.14;
liittää arkkitehtuurikaaviot, runbookit ja SLO-määritelmät yksittäisiin riskeihin ja kontrolleihin sen sijaan, että ne jätettäisiin wikeihin tai diaesityksiin; ja
Yhdistä jokainen kriittinen palvelu sen käytettävyys-, RTO- ja RPO-tavoitteisiin ja osoita, miten redundanssimallit tukevat näitä arvoja.

Tämä antaa sinulle reaaliaikaisen kuvan siitä, missä redundanssi on vahvaa ja missä se kaipaa parantamista, mikä näkyy insinööreille, tietoturvapäälliköille ja auditoijille. Se myös auttaa uusia tiimin jäseniä perehtymään nopeammin, koska he näkevät, miten nykyiset suunnitelmat ovat kehittyneet aiemmista päätöksistä.

Todisteiden tekeminen jatkuviksi, ei ad hoc -perusteisiksi

Jatkuva todisteiden kerääminen muuttaa auditoinnit stressaavista tapahtumista vahvistusharjoituksiksi. Kun kirjaat harjoitukset, vaaratilanteet ja suunnittelukatselmukset niitä edetessä, sinun ei tarvitse rekonstruoida historiaa sähköposteista ja ad-hoc-asiakirjoista joka vuosi.

Sen sijaan, että kiirehtisit ennen jokaista tarkastusta, voit:

tallentaa vikasietoharjoitusten, pelialueiden evakuointien ja palautumistestien tulokset todisteina, jotka on linkitetty suoraan kohtaan A.8.14;
linkittää tapauskohtaiset tarkastelut, joissa redundanssilla tai toimittajien epäonnistumisilla oli merkitystä, ja seurata korjaavia toimia niiden valmistumiseen asti; ja
Ylläpidä selkeää sovellettavuuslausuntoa, jossa viitataan varsinaisiin irtisanomissuunnitelmiisi ja -perusteluihisi, mukaan lukien kaikki hyväksytyt poikkeukset.

Kun tilintarkastajat kysyvät ”mistä tiedätte, että tämä toimii, jos jokin epäonnistuu?”, on olemassa jäljitettävä ketju vaatimuksesta suunnitteluun ja testaukseen. Sama ketju antaa johtajille myös luottamusta siihen, että redundanssi-investointeja hallitaan osana laajempaa hallintomallia, ei vain erillisinä suunnittelutöinä.

Insinöörien ja konsulttien kitkan vähentäminen

Hyvän tietoturvallisuuden hallintajärjestelmän tulisi tukea olemassa olevia työnkulkuja, ei korvata niitä. ISMS.online on rakennettu toimimaan rinnakkain tietovarastojesi, havainnointipinon ja tiketöintityökalujesi kanssa, jotta insinöörit voivat linkittää artefakteja ilman päällekkäistä työtä. Tämä vähentää kitkaa, auttaa konsultteja työskentelemään tehokkaammin ja lisää todennäköisyyttä, että todistusaineisto pysyy ajan tasalla. ISMS.online on rakennettu sopimaan yhteen olemassa olevien työkalujen ja työskentelytapojen kanssa. Voit:

viitata kooditietovarastoistasi, havainnointipinostasi ja tiketöintijärjestelmistäsi kopioimatta jokaista yksityiskohtaa;
antaa SRE:lle, alustalle ja tietoturvatiimeille räätälöityjä näkymiä, jotta he näkevät vain ne osat, joita heidän on ylläpidettävä; ja
Konsulttien ja virtuaalisten tietoturvajohtajien tulisi käyttää A.8.14-standardin mukaisia toimintasuunnitelmia ja rakenteita uudelleen useissa peli- ja SaaS-asiakasohjelmissa pitäen kunkin asiakkaan todisteet ja päätökset selkeästi erillään.

Jos olet vastuussa pelialan organisaation resilienssistä tai ISO 27001 -standardista ja haluat käytännöllisen tavan muuttaa redundanssisuunnittelusi ja -toimintosi puhtaaksi, auditointivalmiiksi todisteeksi, ISMS.online-alustan näkeminen käytännössä on luonnollinen seuraava askel. Se näyttää, kuinka alusta auttaa sinua todistamaan, että vaikka solmu, vyöhyke tai jopa alue vikaantuu, hallitset silti pelejäsi, dataasi ja kerrostasi.

Varaa demo

Usein kysytyt kysymykset

Miten ISO 27001 A.8.14 -standardia tulisi tulkita peli- tai live-palvelualustan osalta?

ISO 27001 A.8.14 edellyttää, että todistaa, että kriittiset palvelut pysyvät saatavilla useiden vikojen aikana tavalla, joka on linjassa tietoturvajärjestelmän, riskirekisterin ja BC/DR-lähestymistavan kanssaPeli- tai live-palvelualustalle tämä tarkoittaa sen osoittamista, että voit menettää infrastruktuurin, alueen tai avaintoimittajan ja silti säilyttää pelaajille, julkaisijoille ja kumppaneille lupaamasi kokemuksen ja käyttöajan.

Mitä se tarkoittaa käytännössä live-palveluiden kannalta?

Useimmissa studioissa ja alustoilla vankassa A.8.14-kerroksessa on neljä näkyvää kerrosta:

1. Liiketoimintalupauksista teknisiä tavoitteita

Aloitat muuttamalla kaupalliset ja pelaajien odotukset konkreettisiksi tavoitteiksi:

Ydintoimintojen, kuten kirjautumisen, matchmakingin, live-istuntojen, maksujen, inventaarioiden ja telemetrian, käyttöaika, RTO ja RPO.
Selkeät toleranssirajat: mitkä palvelut on oltava "aina päällä", mitkä voivat heikentyä ja kuinka kauan.
Kartoitettu vaikutus: mitkä käyttökatkokset laukaisevat hyvityksiä, sääntelyriskin tai mainehaitan.

Näin voit perustella, miksi joillakin alueilla on valmiustilassa olevia malleja, kun taas toiset toimivat yksinkertaisempien mallien mukaan.

2. Yksittäisten vikaantumiskohtien tunnistaminen koko pinossa

Sitten etsit epäonnistumistapoja, jotka rikkoisivat nuo tavoitteet:

Verkko- ja DNS-tukopisteet.
Yksittäiset identiteetti- tai oikeutusalustat ilman vararatkaisuja.
Yksittäiset maksujärjestelmät tai verotusjärjestelmät.
Ohjaustasot (käyttöönotto, liput, konfigurointi), jotka estävät turvallisen toiminnan, jos ne eivät ole käytettävissä.

Jos ohjaus, reititys tai identiteetti ovat "kertakäyttöisiä", pelkän redundantti laskenta ei täytä A.8.14-vaatimusta.

3. Redundanssi, joka on suunniteltu vastaamaan todellista riskiä

Siitä eteenpäin sovitat suunnittelun todelliseen vaikutukseen:

Alueiden sisällä: N+1-kapasiteetti, usean AZ-tason klusterit, tilattomat palvelut, replikoidut välimuistit.
Alueiden välillä: kuumat tai lämpimät toissijaiset alueet identiteetin, parinmuodostuksen ja etenemisen kannalta, joissa alueellinen menetys on sietämätöntä.
Toimittajien välillä: dokumentoidut heikentyneet toimintatavat (esimerkiksi uusien ostojen keskeyttäminen maksujen heikkenemisen vuoksi), kun täysimittaiset usean toimittajan kokoonpanot eivät ole vielä mahdollisia.

Kuvailet tätä seuraavasti: mitä epäonnistumisia voit sietää ja mitä pelaajat näkevät, kun niin tapahtuu, ei pelkästään käytössä olevien pilviominaisuuksien osalta.

4. Todisteet siitä, että irtisanominen toimii stressin alla

Lopuksi osoitat, että suunnittelusi toimii tarkoitetulla tavalla:

Suunnitellut vikasieto-, evakuointi- ja DR-testit realistisella tai edustavalla kuormituksella.
Pelaajakeskeiset mittarit: katkaisujen määrä, hylätyt ottelut, jonotusajat, hyvitysten määrät.
Löydetyt ongelmat, toteutetut toimenpiteet ja testit suoritetaan uudelleen, kunnes tulokset vastaavat odotuksia.

Jos riskirekisteri, sovellettavuuslausunto, BC/DR-suunnitelmat ja arkkitehtuurinäkymät kertovat kaikki saman redundanssikerroksenStandardin A.8.14 puolustaminen auditoinneissa ja julkaisijoiden arvioinneissa on yksinkertaista. ISMS.online-alustan käyttäminen riskien, suunnittelun, testien ja toimittajatietojen kohtaamispaikkana auttaa pitämään kerroksen yhtenäisenä ilman, että insinööreiltä pyydetään ylläpitämään toista asiakirjasarjaa.

Miten redundanssia tulisi priorisoida verkon, laskennan, tietokannan ja pelaajan tilan välillä reaaliaikaisissa peleissä?

Priorisoit redundanssia reaaliaikaisissa tai kilpailullisissa peleissä aloittamalla pelaajien tuntemista kerroksista ja sitten suojaamalla tietoja, jotka ovat oikeudenmukaisuuden ja tulojen perustanaTämä sopii ISO 27001 -standardin riskiperusteiseen lähestymistapaan: eniten suunnitteluenergiaa käytetään siellä, missä epäonnistuminen vahingoittaa nopeimmin luottamusta, kustannuksia ja mainetta.

Mitkä kerrokset tulisi normaalisti käsitellä ensin?

Käytännöllinen järjestys nopeatempoisiin PvP-peleihin, turnauksiin tai live-tapahtumiin on:

1. Verkko ja reuna

Pelaajat huomaavat yhteysongelmia ennen lähes mitään muuta:

Useita joukkoliikennereittejä tai palveluntarjoajia keskeisiin reunapaikkoihin.
DDoS-suojaukset, jotka on viritetty juuri sinun tarpeisiisi (lobby, match, control API).
Reititys, joka estää yksittäisen POP:n tai alueen muuttumisen globaaliksi pullonkaulaksi.

Tämä vähentää merkittävästi yhteyden katkeamisesta johtuvia myrskyjä ja alueellisia katkoksia, jotka aiheuttavat valituksia sosiaalisessa mediassa ja tukipyyntöjä.

2. Laskenta ja orkestrointi

Kykykykysi on kestettävä arjen epäonnistumiset:

N+1-kapasiteetti vähintään kahdessa AZ-tasolla pelipalvelimille ja kriittisille API-rajapinnoille.
Tilapohjainen reititys ja sujuvat tyhjennykset, joten solmuongelmat näyttävät lyhyiltä häiriöiltä, eivät massaprosesseilta.
Eristys kokeille, live-op-työkaluille ja analytiikalle, jotta ne eivät voi hiljaisesti nälkiinnyttää pelipalveluita.

Nämä mallit pitävät osumat vakaina, kun infrastruktuuri vaihtuu tai uusia versioita julkaistaan.

3. Istunto ja ohimenevä tila

Reiluus on tärkeää. Jos ohimenevä tila katoaa väärään aikaan, pelaajat usein olettavat huijaamista, epäpätevyyttä tai petosta:

Ulkoistetut tai replikoidut osavaltioiden tallennustilat auloja, otteluita ja tarkastuspisteitä varten.
Yhdistä uudelleen podin tai solmun menetyksestä selviävät työnkulut ilman edistymisen pyyhkimistä tai palkkioiden virheellistä myöntämistä.
Runbookit ja pelaajakohtaiset säännöt peruutuksista, kompensoinneista tai tilan voimassaolosta.

Näiden käyttäytymismallien käsitteleminen eksplisiittisinä suunnitteluvalintoina tekee niiden puolustamisesta paljon helpompaa auditoinneissa ja tapahtuman jälkeisissä arvioinneissa.

4. Jatkuva edistyminen, tavaraluettelot ja lompakot

Nämä järjestelmät voivat joskus sietää hieman korkeampia RTO-arvoja, mutta niiden eheys on ehdoton:

Usean AZ:n tai usean alueen replikointi tileille, varastoille, lompakoille ja kirjanpidoille.
Edustavien varmuuskopioiden säännölliset ajastetut palautukset puhtaisiin ympäristöihin sen varmistamiseksi, että RTO ja tietojen eheys vastaavat oletuksiasi.
Analytiikka- ja petosmallit, jotka voivat käynnistyä uudelleen puhtaasti DR-tapahtumien jälkeen.

Yksinkertainen tapa varmistaa prioriteettisi on käydä läpi viime vuoden tapahtumat ja kysyä Mitkä epäonnistumiset aiheuttivat suurimmat luottamus-, hyvitys- tai petosvaikutuksetNäiden tasojen tulisi näkyä A.8.14-etenemissuunnitelmasi alussa. Näiden perustelujen kirjaaminen tietoturvallisuuden hallintajärjestelmään (ISMS) ja toiminnanohjausjärjestelmään (SoA) antaa selkeän kuvan sekä tilintarkastajille että sisäisille sidosryhmille. ISMS.online voi sitten ankkuroida nämä prioriteetit eri nimikkeisiin, vuodenaikoihin ja alueisiin, jotta uudet projektit alkavat todistetuista malleista sen sijaan, että opeteltaisiin samoja asioita uudelleen.

Kuinka voimme saattaa olemassa olevan usean alueen pilviratkaisun A.8.14-standardin mukaiseksi ilman, että sitä rakennetaan uudelleen?

Saat olemassa olevan monialuesuunnitelman A.8.14:n mukaiseksi seuraavasti: kuvailemalla sitä liiketoimintavaikutusten ja epäonnistumisten sietokyvyn näkökulmasta ja tiukentamalla sitten tilannetta, jossa riskin ja kustannusten suhde on selvästi ristiriidassasen sijaan, että hylkäisit toimivan. Tilintarkastajat haluavat pääasiassa nähdä, että olet tehnyt tietoisia, dokumentoituja valintoja, jotka vastaavat lupauksiasi.

Miten esittelemme nykyisen arkkitehtuurimme tavalla, johon tilintarkastajat luottavat?

Rakenteellinen kartoitus toimii hyvin ja on yleensä nopeampi kuin uudelleensuunnittelu:

1. Ryhmittele työkuormat liiketoimintavaikutuksen mukaan

Kuvaile järjestelmiä tulosten kielellä pelkkien palveluiden nimien sijaan, esimerkiksi:

Alueittainen parinhaku.
Pelien välinen identiteetti ja oikeudet.
Maksut, lompakot, hyvitykset ja kannustimet.
Live-ops- ja konfigurointipaneelit.
Jatkuvat etenemis- ja inventaariopalvelut.
Telemetria-, petos- ja huijausnestojärjestelmät.

Tämä helpottaa selittämään, miksi joillakin palveluilla on tiukemmat redundanssiodotukset kuin toisilla.

2. Tallenna käyttöönotto- ja riippuvuustiedot

Tiivistä kunkin työmäärän osalta:

Käytössä olevat alueet ja AZ:t sekä ovatko kuviot aktiivinen-aktiivinen, aktiivinen-valmiustilassa vai jotain siltä väliltä.
Keskeiset riippuvuudet, kuten tietokannat, välimuistit, jonot, DNS, CDN, identiteetintarjoajat, maksujen käsittelijät, havaittavuus ja huijauksenestopalvelut.
Kaikki sääntelyviranomaisten, julkaisijoiden tai alustojen säännöt, jotka rajoittavat käyttöönottoa tai -tapaa.

Tavoitteena on tehdä olemassa olevat vahvuudet ja puutteet näkyviksi, jotta parannukset voidaan kohdentaa, ei teoreettisesti.

3. Ilmoita siedetyt epäonnistumiset ja hyväksytyt riskit

Kerro nimenomaisesti, mistä epäonnistumisista aiot selvitä:

Isännän, virtuaalikoneen tai podin menetys, jolla on vain vähäinen, itsekorjautuva vaikutus.
Yhden AZ-alueen häviö rajoitetulla heikkenemisellä.
Alueellisia ongelmia hallitaan liikenteen siirtojen, rajoitettujen liikennemuotojen tai osittaisten katkosten avulla.
Toimittajien tilan heikkenemistä käsitellään rajoitusten, suojausjaksojen tai "pidä turvassa" -tilojen avulla.

Missä sinä ei voi kohtuullisesti sietää tiettyjä epäonnistumisia – kuten tietyn tietokannan täydellisen alueellisen menetyksen – kirjaa ne hyväksytyksi riskiksi perusteluineen ja mahdollisine korvaavine toimenpiteineen. Useimmat tilintarkastajat suhtautuvat hyvin selkeisiin riskimerkintöihin perustuviin kompromisseihin pikemminkin kuin implisiittiseen täydellisyyteen.

4. Yhdistä kaikki takaisin tietoturvanhallintajärjestelmääsi ja BC/DR-kerrokseen

Linkki jokaiselle työmäärälle:

Saatavuus, RTO ja RPO takaisin liiketoimintaan ja pelaajiin.
Arkkitehtuurikaaviot ja runbookit, jotka osoittavat, kuka toimii virheiden ilmetessä.
Testaa kaaoskokeista, vikasietoharjoituksista ja vikasietoisuuden palautuksista saatuja todisteita, mukaan lukien seurantatyö.

Kun tämä rakenne on jo olemassa tietoturvanhallintajärjestelmässäsi, voit käyttää sitä uudelleen auditointeihin, alustakyselyihin ja sisäiseen hallintoon sen sijaan, että selityksiä luotaisiin joka kerta uudelleen. ISMS.online sopii hyvin tähän työskentelytapaan: insinöörit säilyttävät yksityiskohtaisia artefakteja koodi- ja infrastruktuuritietovarastoissa, kun taas tietoturvanhallintajärjestelmä sisältää laaja-alaisen tason, joka auditoijien, julkaisijoiden ja ylemmän tason sidosryhmien on nähtävä.

Miten suunnittelemme ja testaamme redundanssia, jotta se toimii oikein julkaisujen, kausien ja suurten tapahtumien aikana?

Suunnittelet ja testaat redundanssia lanseerauksia ja suuria tapahtumia varten rakentaa erityisiä epäonnistumistarinoita, harjoitella niitä mielekkäällä kuormituksella ja sisällyttää ne tietoturvanhallintajärjestelmääsi, sen sijaan, että luotettaisiin ad hoc -stressitesteihin. Juuri lanseeraukset, uudet kaudet ja turnaukset ovat hetkiä, jolloin A.8.14:ää testataan näkyvimmin.

Mitä tehokas tapahtumakeskeinen redundanssitestausmenetelmä sisältää?

Vankassa lähestymistavassa on kolme vaihetta: tarinoiden määritteleminen, testien suorittaminen ja oppimisen tallentaminen.

1. Määrittele selkeät epäonnistumistarinat

Kirjoita jokaista korkean profiilin hetkeä – maailmanlaajuinen lanseeraus, alueellinen käyttöönotto, kausittainen uudelleenkäynnistys tai merkittävä turnaus – varten muutama yksinkertainen kerronta, joita haluat välttää, kuten:

"Pääasiallisen julkaisualueemme pelaajat eivät pysty kirjautumaan sisään tai pysymään yhteydessä."
"Rangipelien jonot katkeavat, mutta satunnaiset pelimuodot pysyvät pelattavissa."
"Maksut onnistuvat, mutta oikeuksien saaminen viivästyy tai epäonnistuu, mikä aiheuttaa ostosten puuttumisen."
"Live-operaatiot ja tuki eivät voi toimia nopeasti, koska työkaluja ei ole saatavilla."

Listaa kunkin kerroksen alle tekniset viat, jotka saattavat aiheuttaa sen: AZ-häviö, alueelliset verkko-ongelmat, ohjaustason kyllästyminen, väärin määritetty skaalaus tai kolmannen osapuolen aiheuttama heikkeneminen.

2. Suunnittele testit, jotka heijastavat näitä riskejä

Suunnittele jokaiselle kerrokselle hallittuja harjoituksia:

Kohdennetut kaaoskokeilut, jotka poistavat kapasiteettia tai estävät riippuvuuksia samalla, kun seuraat ottelun valmistumista, keskeyttämistä ja jonomittareita.
Alueen siirto- tai evakuointiharjoitukset, joissa osa liikenteestä siirretään turvallisesti toissijaiselle alueelle ja takaisin, mukaan lukien tili- ja oikeutuspolut.
Aikarajoitteiset palautusharjoitukset keskeisille tietojoukoille (esimerkiksi inventaario- ja lompakkotietueille), joissa tiimien on palautettava tiedot puhtaaseen ympäristöön sovittujen aikarajojen puitteissa.
Koko tiimin simulaatiot, joissa suunnittelu, reaaliaikaiset operaatiot, tuki ja viestintä harjoittelivat koordinoituja reagointitapoja ennalta määriteltyihin tapahtuma-aikatauluihin.

Näiden testien tulisi olla etukäteen hyväksyttyjä, tarkkailtuja ja dokumentoituja, jotta niiden tulokset voivat laillisesti muodostaa osan A.8.14-todisteitasi.

3. Sulje suunnittelun, runbookien ja tietoturvanhallintajärjestelmän kierto

Jokaisen harjoituksen jälkeen:

Päätä, saavutitko palvelutasotavoitteesi ja RTO/RPO:n kyseisessä tilanteessa.
Kirjaa ylös tekijät, jotka menivät hyvin ja jotka eivät, suunnittelun, kapasiteetin, toimintasuunnitelman selkeyden ja viestinnän osalta.
Luo ja seuraa muutoksia arkkitehtuuriin, kokoonpanoon, valvontaan, runbookeihin tai eskalointipolkuihin.
Päivitä asiaankuuluvat riskimerkinnät, BC/DR-asiakirjat ja A.8.14-todisteiden viitteet.

Kun käsittelet jokaisen harjoituksen ja todellisen tapahtuman tällä tavalla, lanseeraukset ja tapahtumat vahvistavat tasaisesti sekä selviytymiskykyäsi että auditointiasennettasi. ISMS.online voi yksinkertaistaa tätä kierrettä tarjoamalla sinulle keskitetyn paikan linkittää skenaariot, testisuunnitelmat, tiketit, valvontavedokset ja seurantatoimenpiteet tiettyihin riskeihin ja kontrolleihin, jotta työtiimit, jotka jo tekevät lanseerausten ympärillä, parantavat automaattisesti A.8.14-tasoasi.

Mitä dokumentaatiota ja todisteita meillä tulisi olla valmiina A.8.14-tarkastusta varten pelin tai live-palvelun auditoinnissa?

Kohdan A.8.14 osalta tilintarkastajat haluavat yhdistetty asiakirjojen ja tallenteiden kokoelma jotka osoittavat, miten suunnittelet redundanssia, määrittelet tavoitteet, käytät alustaa ja opit testeistä ja tapahtumista. Peli- tai live-palveluympäristössä kyseisen kerroksen on katettava suunnittelu, live-operaatiot, tuki ja toimittajan hallinta.

Millä esineillä on käytännössä eniten merkitystä?

Vaikka jokaisella auditoijalla on omat mieltymyksensä, viisi klusteria auttavat lähes aina:

1. Arkkitehtuuri- ja redundanssinäkymät

Järjestelmätason kaaviot, jotka korostavat redundanssia solmu-, AZ-, alue- ja toimittajatasolla.
Tarkempia näkymiä kriittisille palveluille, kuten matchmakingille, identiteetille, etenemiselle ja kaupankäynnille.
Huomautuksia tai päällekkäisyyksiä, jotka osoittavat hyväksytyt yksittäiset vikaantumiskohdat ja miksi niitä ei ole vielä täysin lievennetty.

Nämä auttavat tilintarkastajia muodostamaan henkisen mallin resilienssistäsi ennen kuin he lukevat yksityiskohtaiset menettelytavat.

2. Saatavuus- ja palautumistavoitteet

Saatavuuden, RTO:n ja RPO:n matriisi palvelu-, ominaisuus- tai pelitilakohtaisesti.
Selitykset, jotka yhdistävät kyseiset tavoitteet kaupallisiin sitoumuksiin, alustavaatimuksiin tai sääntelyodotuksiin.
Kaikki asettamasi ulkoiset palvelutasosopimukset tai julkisen tilan odotukset.

Tämä varmistaa, että linja on selkeä mitä lupaat että miten suunnittelet ja testaat.

3. Jatkuvuus ja toimintamenettelyt

BC/DR-suunnitelmat, jotka kuvaavat, miten reagoit infrastruktuurivikoihin, alueellisiin häiriöihin ja toimittajien käyttökatkoihin.
Runbookit vikasietoisuutta, liikenteen siirtoa, vajaatoimintatiloja ja hätämuutoksia varten.
Eskalointipolut, jotka sisältävät suunnittelua, operatiivisia toimintoja, tukea ja viestintää.

Nämä dokumentit osoittavat, että redundanssi ei ole vain kaavio; on ihmisiä ja prosesseja, jotka ovat valmiita käyttämään sitä.

4. Testi- ja tapahtumaoppimistietueet

Vikasietoharjoitusten, aluesiirtotestien, DR-palautusten ja kaaoskokeilujen tiedot, mukaan lukien mittarit, tulokset ja seurantakohteet.
Tapahtuman jälkeiset tarkastelut, joissa redundanssi toimi odotettua paremmin tai huonommin, ja niistä johtuvat muutokset.
Todisteet siitä, että merkittävät arkkitehtuuri- tai liikennemuutokset käynnistävät päivitetyt testit.

Tämä materiaali osoittaa, että A.8.14 on elävän hallinnan jatkuvan parantamisen alaisena, ei sertifioinnin yhteydessä jäädytetty staattinen malli.

5. Tiedot toimittajien ja kumppaneiden selviytymiskyvystä

Palvelutasosopimukset, vikasietoisuuslausunnot ja arviointimuistiinpanot pilvipalveluntarjoajille, DNS:lle, CDN:ille, identiteetille, maksuille, huijauksenestolle ja muille kriittisille palveluille.
Analyysi siitä, miten nämä sitoumukset vastaavat omia tavoitteitasi ja riskinottohalukkuuttasi.
Dokumentoidut kompensoivat toimenpiteet, kuten toimitusten rajoittaminen, lisäajat tai ostojen pidätykset toimittajaongelmien aikana.

Kun nämä esineet ovat hajallaan henkilökohtaisissa kansioissa, wikissä ja tikettijärjestelmissä, auditointien valmistelusta tulee häiritsevää. Jos sen sijaan pidät ne A.8.14:n ja siihen liittyvien kontrollien mukaisesti keskitetyssä tietoturvan hallintajärjestelmässä (ISMS), sama materiaali palvelee toistuvia auditointeja, julkaisijoiden tarkastuksia ja sisäistä hallintoa. Monet tiimit käyttävät ISMS.online-sivustoa keskuksena: insinöörit käyttävät edelleen haluamiaan työkaluja, kun taas vaatimustenmukaisuudesta vastaavat ylläpitävät jäsenneltyä, aina valmiina olevaa todistusaineistoa.

Kuinka ISMS-alusta, kuten ISMS.online, voi auttaa sinua hallitsemaan A.8.14-suunnitelmaa ylikuormittamatta insinöörejä?

ISMS-alusta, kuten ISMS.online, auttaa sinua hallinnoimaan A.8.14:ää tiimiesi jo luomien kaavioiden, testien, tapausten ja toimittaja-arviointien muuttaminen jäsennellyiksi, uudelleenkäytettäviksi valvontatodisteiksi, rinnakkaisen raportointikerroksen lisäämisen sijaan. Tämä pitää redundanssin näkyvänä ja auditoitavana samalla kunnioittaen insinöörien aikaa.

Miltä matalakitkainen A.8.14-hallinto näyttää päivittäin?

Peli- tai live-palveluympäristössä tukeva tietoturvan hallintajärjestelmä voi:

1. Määrittele kielen laajuus tiimien ymmärtämällä tavalla

Karttasi:

Pelit, pelimuodot ja jaetut alustapalvelut.
Alueet, saatavuusvyöhykkeet ja käyttöönottomallit.
Keskeiset toimittajat, kuten pilvipalvelut, maksut, identiteettipalvelut, DNS, CDN ja huijauksenesto.

Sitten yhdistät jokaisen elementin A.8.14:ään ja viereisiin liitteen A säätimiin (esimerkiksi A.5.29 toimintaan häiriöiden aikana ja A.5.30 ICT-valmiuteen), jotta tiimit näkevät selvästi, miten heidän työnsä vaikuttaa yleiseen käytettävyyteen.

2. Yhdistä suunnittelu, riski ja jatkuvuus

Liityt seuraaviin:

Arkkitehtuurikaaviot ja kapasiteettisuunnitelmat.
Riskimerkinnät ja hoitotoimenpiteet.
BC/DR-strategiat ja erityiset runbookit.
Testisuunnitelmat, DR-harjoitukset ja tapahtumatarkastelut.

Kun nämä linkit ovat yhdessä paikassa, päätökset, kuten alueen siirtäminen, pelitilan lisääminen tai toimittajien vaihtaminen, osoittavat välittömästi, mitä riskejä, asiakirjoja ja testejä on myös muutettava.

3. Kerää operatiivista näyttöä osana normaalia työtä

Erillisten "tarkastustehtävien" aikatauluttamisen sijaan liität tuotokset seuraavista lähteistä:

Kaaoskokeita, vikasietoharjoituksia ja DR-harjoituksia.
Päivystystiedot, tapahtumatiketit ja tapahtuman jälkeiset analyysit.
Toimittajien arvostelut ja palvelutasosopimusten tarkistukset.

asiaankuuluviin riski- ja valvontatietoihin. Sama operatiivinen toiminta tukee sitten sertifiointia, julkaisijoiden kyselylomakkeita, alustan käyttöönottoa ja sisäistä hallintoa ilman päällekkäisyyksiä.

4. Hallitse toimittajien selviytymiskykyä samassa näkymässä

Säilytät:

Ylläpidetty rekisteri kriittisistä toimittajista, heidän saatavuuslupauksistaan ja heidän häiriöhistoriastaan.
Yhteydet toimittajan suorituskyvyn, omien palvelutasosopimustesi ja tallennettujen pelaajien vaikutusten välillä.
Selkeä perustelu sille, missä tapauksissa hyväksyt toimittajariskin ja missä tapauksissa toteutat kompensoivia toimintatapoja.

Läpinäkyvyys tekee keskusteluista tilintarkastajien, alustojen ja johtajien kanssa suoraviivaisempia.

5. Käytä näyttöä uudelleen eri viitekehyksissä ja sidosryhmien keskuudessa

Kun kaavio, testi tai toimittajan arvostelu on linkitetty kohtaan A.8.14 ISMS.online-palvelussa, voit:

Käytä sitä uudelleen ISO 27001 -sertifiointiin ja valvontatarkastuksiin.
Vastaa alustan ja julkaisijan due diligence -tarkastusten sietokykyä koskeviin osioihin nopeammin.
Tue NIS 2:ta, DORAa tai tulevia tekoälyn hallintatarpeita samalta resilienssiltä.
Tiedota johdolle ja hallituksille irtisanomisten ja jatkuvuuden tilanteesta mahdollisimman pienellä lisätyöllä.

Kun insinöörit ymmärtävät, että tietoturvajärjestelmän pitäminen ajan tasalla vähentää viime hetken paloharjoituksia ja toistuvaa kyselylomakkeen täyttämistä, sitoutuminen yleensä paranee. Jos haluat studiosi tai alustasi olevan luotettava pitkäaikaisen kumppanin pelaajien, julkaisijoiden ja tilintarkastajien keskuudessa, A.8.14-kerroksen yhdistäminen ISMS.online-palveluun on erittäin hyödyllinen askel, jonka voit ottaa nyt ilman, että sinun tarvitsee uudistaa olemassa olevaa teknistä pinoasi.

ISO 27001 A.8.14 – Redundantti infrastruktuurisuunnittelu pelialustoille