Kuinka ISO 27001 A.8.22 -verkon erottelu suojaa peli-, lompakko- ja järjestelmänvalvojan tietoja

Miksi verkon erottelu on todella tärkeää peli-, lompakko- ja hallintaympäristöissä

Verkon erottelu estää pelipinon tietomurron hiljaisesta muuttumisesta tyhjentyneeksi lompakoksi tai kaapatuksi hallintakonsoliksi: pitämällä peli-, lompakko- ja hallintaympäristöt selkeästi erillisissä verkoissa rajoitat hyökkääjän pääsyä sisään, jos he murtautuvat sisään. Näin yhdestä heikosta kohdasta tulee yksittäinen tapaus eikä koko alustaa kattava kriisi. Kun pyörität oikean rahan pelejä, maksuja tai kryptolompakoita, verkkojen erottelutapa ratkaisee pitkälti, onko tapaus meluisa mutta hallittu vai vakava liiketoiminnan, sääntelyviranomaisten ja otsikon tasolla. ISO 27001 -standardin A.8.22-valvonta on se koukku, jonka avulla voit tehdä tästä erottelusta tarkoituksellista, dokumentoitua ja puolustettavaa tahattoman sijaan. Jos olet vastuussa ISO 27001 -standardista koko peli- ja lompakkoalustalla, verkon erottelu on yksi harvoista vipuvarsista, jotka voivat merkittävästi vähentää pahimpien tapausten riskiä.

Nämä tiedot ovat yleisiä eivätkä ne ole oikeudellisia tai sääntelyyn liittyviä neuvoja. Sinun tulisi aina pyytää ammattilaisen neuvoja erityisistä velvoitteistasi ja arkkitehtuuristasi. Rakenteinen tietoturvan hallintajärjestelmä (ISMS), kuten ISMS.online, voi auttaa sinua tallentamaan neuvoista johtuvat päätökset ja todisteet, jotta niitä on helppo ylläpitää ja esittää auditoinnin yhteydessä.

Vahvat rajat muuttavat kaoottisen kompromissin hallituksi ja ymmärrettäväksi tapahtumaksi.

Todellinen riski: sivuttaisliike tasojen välillä

Todellinen riski ei ole vain alustava murto, vaan hyökkääjän kyky liikkua sivusuunnassa ympäristöstä toiseen. A.8.22:n tarkoituksena on viime kädessä rajoittaa tätä sivuttaisliikettä, jotta yksi vaarantunut komponentti ei voi hiljaa avata ovea kaikkeen muuhun peli-, lompakko- ja hallintaympäristöissä.

Yhdistetyssä peli- ja lompakkoalustassa on tyypillisesti kolme pääpiirteittäin jaettua tasoa:

Pelikone: – matchmakerit, aulat, pelipalvelimet, chat, analytiikka ja sisällön toimitus.
Lompakkotaso: – maksujen käsittelijät, lompakkopalvelut, avaintenhallinta, tilikirjatietokannat ja selvityspalvelut.
Hallintataso: – taustatoimintojen työkalut, tukikonsolit, määrityskäyttöliittymät, valvonta-, petos- ja riskienhallintatyökalut.

Nämä koneet keskittävät hyvin erilaisia riskejä eri paikkoihin, joten helppo liikkuminen niiden välillä takaa lähes varmasti, että yhdessä koneessa olevaa jalansijaa käytetään muiden tutkimiseen.

Hyökkääjät aloittavat harvoin lompakko- tai hallintatasolta. He aloittavat siellä, missä altistuminen on suurinta: pelipalvelimilta, web-rajapinnoista, pelaajille suunnatuista toiminnoista tai joskus tietojenkalasteluyrityksistä, joilla on hallintaoikeudet. Jos verkko ei erota peli-, lompakko- ja hallintaympäristöjä selkeästi toisistaan, jalansija yhdessä niistä toimii ponnahduslautana muihin. Yksi vaarantunut peliyksikkö saattaa antaa pääsyn jaettuihin raportointivarastoihin ja sitten lompakkojärjestelmiin, mikä vaarantaa suuren osan aktiivisista pelaajista ja saldoista.

”Räjähdyssäteen” ajattelu auttaa. Kysy itseltäsi: jos yksittäinen pelikapseli, yksittäinen ylläpitäjän tili tai yksittäinen lompakkomikropalvelu vaarantuu, mikä on suurin realistinen taloudellinen, sääntelyyn liittyvä ja operatiivinen vaikutus? Jos vastaus on ”siitä yhdestä pisteestä voi lopulta tavoittaa kaiken”, verkon erottelu ei ole toiminut.

Miksi peli- ja lompakkoalustat eroavat yleisistä IT-alustoista

Peli- ja lompakkoalustat tarvitsevat verkon erottelun, joka kunnioittaa reaaliaikaista suorituskykyä, vaihtelevia luottamustasoja ja vahvaa kolmannen osapuolen integrointia. Et voi vain kopioida yleistä toimistoverkon suunnittelua ja odottaa sen pitävän pelaajat, varat ja etuoikeutetut konsolit turvassa.

Monet yleiset verkkojen erotteluoppaat olettavat toimistoverkkoja, kourallisen yrityssovelluksia ja ehkä joitakin internetiin yhdistettyjä web-palvelimia. Reaaliaikaisella peli- ja lompakkoalustalla on joitakin ainutlaatuisia paineita:

Suurivolyyminen, pienilatenssinen liikenne: – Parinmuodostus ja pelattavuus ovat herkkiä viiveille, joten tarkastus on sijoitettava huolellisesti.
Arvokkaat kohteet ja epäluotettava syöte: – pelaajat lähettävät epäluotettavaa liikennettä, kun sinä liikut ja tallennat oikeaa arvoa.
Vahva kolmannen osapuolen integrointi: – petostentorjuntatyökalut, analytiikka, markkinointi, maksut ja identiteettipalvelut tarvitsevat kaikki yhteyksiä.
Monimutkaiset hallintatyökalut: – pelinjohtajat, tuki, talous ja insinöörit usein jakavat tai käyttävät uudelleen tehokkaita hallintakonsoleita.

Näiden ominaisuuksien vuoksi pelkkä ”sisältä ulkoa” -ajattelu ei riitä. Tarvitset selkeän eron tasojen välillä ja niiden välillä on oltava hyvin harkitut ja hyvin vartioidut sillat, jotta suorituskyky, integrointi ja turvallisuus ovat tasapainossa sen sijaan, että niistä tingitaisiin sokeasti.

Epämääräisen ahdistuksen muuttaminen konkreettiseksi riskikuvaksi

Teet parempia erottelupäätöksiä, kun korvaat epämääräisen ahdistuksen tietyillä hyökkäyspoluilla. Hyökkääjän liikkumismahdollisuuksien kartoittaminen pelin, lompakon ja hallintaympäristöjen välillä näyttää tarkalleen, missä kohtaa nykyinen mallisi on liian lattea tai liian salliva.

Hyödyllinen ensimmäinen harjoitus on kartoittaa konkreettisia reittejä, joita hyökkääjä voisi kulkea, jos hän saisi jalansijaa:

Paljastuneesta peli-API:sta pelitietovarastoon ja sitten raportointitietokantaan, joka vastaanottaa myös lompakkotietoja.
Kehittäjän kannettavasta tietokoneesta eri ympäristöjen välillä jaettuun bastion-isäntään ja sitten lompakkosolmuihin tai hallintakonsoleihin.
Vaarantuneesta tukitilistä hallintakonsoliksi, joka yhdistää tehokkaat peli- ja lompakko-ominaisuudet.

Nämä esimerkit muuttavat abstraktit huolenaiheet todellisten, päätettävissä olevien polkujen lyhyeksi listaksi, mikä tekee keskusteluista insinöörien ja johdon kanssa paljon kohdennetumpia.

Kirjaa jokaisen polun osalta ylös aloituskohta, jokainen luottamusrajan ylitys pelin, lompakon ja hallintaympäristöjen välillä sekä todennäköiset vaikutukset kussakin vaiheessa, kuten tietojen menetys, varojen menetys, käyttökatkokset tai sääntelyraportoinnin laukaisevat tekijät. Tämä antaa sinulle konkreettisen luettelon korjattavista erotteluongelmista ja riskikuvan, jonka ISO 27001 -riskinarviointisi ja -käsittelysuunnitelmasi tulisi jo tallentaa. Se myös helpottaa arkkitehtuuri- ja dokumentaatiopäätösten perustelemista johdolle: et väittele teoreettisista malleista, vaan suljet hyvin todellisia hyökkäysreittejä.

Visuaalinen: Yksinkertainen kolmialueinen kaavio, jossa on peli-, lompakko- ja hallinta-alueet sekä nuolet, jotka näyttävät vain harvat sallitut yhteydet.

Varaa demo

Mitä ISO 27001 A.8.22 todellisuudessa vaatii

ISO 27001 A.8.22 edellyttää, että ryhmittelet palvelusi, käyttäjäsi ja järjestelmäsi, erottelet nämä ryhmät verkossa riskin mukaan ja valvot tarkasti niiden kommunikointia. Se ilmaisee tämän lyhyellä mutta tehokkaalla vaatimuksella: ”Tietopalveluiden, käyttäjien ja tietojärjestelmien ryhmät on erotettava toisistaan organisaation verkoissa.” Käytännössä tämä tarkoittaa, että tunnistat nämä ryhmät, erottelet ne riskinsä vastaavalla tavalla ja hallitset kaikkea niiden välistä kommunikaatiota. Pelin, lompakon ja hallinta-alustan kohdalla tämä tarkoittaa näiden ympäristöjen käsittelyä erillisinä verkosto"ryhminä", joilla on selkeästi määritellyt ja perustellut linkit, ja kykyä todistaa, että niiden väliset yhteydet ovat välttämättömiä, rajoitettuja ja valvottuja eivätkä tilapäisiä.

Yhdestä lauseesta selkeisiin tavoitteisiin

A.8.22 pyytää sinua tekemään neljä asiaa: päättämään, mitkä ryhmät on erotettava toisistaan, selittämään, miksi niiden riskit eroavat toisistaan, määrittelemään, miten erotat ne teknisesti, ja osoittamaan, miten perustelet ja hallitset kaikkia niiden välisiä yhteyksiä. Kun pystyt vastaamaan näihin kysymyksiin pelisi, lompakkosi ja hallintaympäristöjesi osalta, olet vankalla pohjalla sekä suunnittelulle että auditoinnille.

Jos jaat tuon yhden lauseen osiin, se sisältää neljä suunnittelukysymystä:

Mitkä ryhmät tarvitsevat erottelua?
Tässä yhteydessä: pelipalvelut ja käyttäjät, lompakkopalvelut ja operaattorit, hallinto- ja operatiivinen henkilöstö ja heidän työkalunsa.
Miksi he tarvitsevat eron?
Koska heidän riskinsä on erilainen. Lompakko- ja ylläpitotoiminnalla on paljon suurempi potentiaali aiheuttaa suoria taloudellisia ja sääntelyyn liittyviä vaikutuksia kuin useimmilla pelitoiminnoilla.
Miten ne on erotettu toisistaan?
Loogisten tai fyysisten keinojen kautta: virtuaaliverkot, VLANit, reititysdomeenit, palomuurit, ohjelmistomääritellyt verkot, isäntäpohjaiset hallintalaitteet ja käyttöoikeuskäytännöt.
Miten niiden välistä liikennettä ohjataan ja perustellaan?
Vähiten oikeuksien sääntöjen, dokumentoitujen odotusten, muutostenhallinnan ja valvonnan avulla varmistetaan, että kyseiset säännöt ovat käytössä ja toimivat.

A.8.22 on teknologianeutraali. Voit vapaasti valita mekanismeja, kunhan ne ovat yhdenmukaisia riskinarviointisi kanssa ja osoitetusti tehokkaita alustasi todellisen toiminnan kannalta.

Palveluiden, käyttäjien ja järjestelmien eriyttäminen

A.8.22-vaatimuksen täyttämiseksi sinun on eroteltava paitsi palvelimet ja aliverkot, myös niillä toimivat palvelut ja niitä käyttävät ihmiset. Peli- ja lompakkoalustalla tämä tarkoittaa selkeiden erojen tekemistä pelaajavirtojen, arvoa siirtävien virtojen ja etuoikeutettujen toimintojen välille.

Ohjaus ei koske vain palvelimia ja aliverkkoja. Se kutsuu eksplisiittisesti tietopalvelut, Käyttäjät ja tietojärjestelmäPelien ja lompakoiden yhteydessä se tarkoittaa yleensä seuraavaa:

Hoitaa pelaajat, lompakon käyttäjät, operaattorit ja insinöörien eri käyttäjäryhminä, joilla on erilliset, dokumentoidut polut.
Hoitaa pelipalvelut, lompakkopalvelut ja hallintopalvelut erillisinä tietopalveluluokkina, joilla on erilaiset yhteyssäännöt.
Hoida taustalla olevaa järjestelmät (tietokannat, viestijonot, lokitiedostopinot, klusterit, pilvitilit) kuuluviksi yhteen tai useampaan näistä ryhmistä ja sijoittaa ne oikeisiin segmentteihin.

Nämä erot tekevät litteästä verkosta tarkoituksellisen suunnittelun, jossa jokaisen ryhmän ulottuvuus on rajoitettu siihen, mitä se todella tarvitsee.

Kun kirjoitat sovellettavuuslausuntoa, kohta A.8.22 tulee merkitä sovellettavaksi ja perustella, jossa kuvataan nämä ryhmittelyt ja viitataan varhaisessa vaiheessa verkostoerottelun suunnitteluun ja standardeihin, jotta yhteys on tilintarkastajille ilmeinen.

Miten A.8.22 on vuorovaikutuksessa muiden ohjainten kanssa

A.8.22 toimii parhaiten, kun sitä käsitellään osana laajempaa kontrolliryhmää. Se muokkaa verkkojesi jakamista, kun taas muut kontrollit määrittelevät, kuka saa osallistua, miten muutoksia tehdään ja miten näitä rajoja valvotaan ajan kuluessa.

Kohdan A.8.22 toteuttaminen on helpompaa, jos näet sen osana toisiinsa liittyvien ohjausobjektien ryhmää:

Verkkoturvallisuus ja -palvelut: – verkkojen ja niiden palveluiden perussuojaukset ja turvallinen konfigurointi.
Pääsyoikeuksien hallinta ja identiteetti: – kuka voi käyttää järjestelmiä tai vyöhykkeitä ja miten todennus ja valtuutus toimivat.
Toimittaja- ja pilvipalvelut: – miten ulkoiset palveluntarjoajat kytkeytyvät ympäristöösi ja mihin he voivat tavoittaa.
Muutos ja seuranta: – miten segmentointisääntöjä ylläpidetään, tarkistetaan ja seurataan ajan kuluessa.

Yhdessä nämä kontrollit kuvaavat paitsi rajojen sijaintia myös sitä, miten niitä käytännössä ylläpidetään ja noudatetaan. Tietoturvan hallintajärjestelmäalusta, kuten ISMS.online, voi auttaa sinua osoittamaan nämä yhteydet selkeästi linkittämällä riskit, kontrollit ja todisteet yhteen paikkaan.

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

Pelin, lompakon ja järjestelmänvalvojan suojausvyöhykkeiden suunnittelu

A.8.22:n ja käytännön tietoturvan näkökulmasta yksinkertaisin mentaalinen malli, joka sopii useimmille alustoille, on: yksi vyöhyke pelille, yksi lompakoille, yksi hallinnolle, jossa kaikkia jaettuja tai integraatiokomponentteja käsitellään eksplisiittisesti omina vyöhykkeineen, ja useimmille peli- ja lompakkoalustoille käytännöllisin tapa toteuttaa tämä malli on määritellä yksi suojausvyöhyke peliympäristölle, yksi lompakoille, yksi hallinnoinnille ja erillinen integraatiovyöhyke kolmansille osapuolille. Sitten hallitset ja dokumentoit kaikkia näiden vyöhykkeiden välisiä yhteyksiä niiden eri riskitasojen mukaan, jotta liikenne kulkee vain siellä, missä sillä on selkeä liiketoiminnallisesti perusteltavissa oleva tarkoitus.

Yksinkertainen kaavoitusmalli, joka toimii useimmissa ympäristöissä

Selkeä vyöhykemalli auttaa sinua pohtimaan riskejä ja osoittaa auditoijille, että olet tarkoituksella erottanut erityyppiset toiminnot sen sijaan, että olisit antanut kaiken toimia yhdessä tasaisessa verkossa. Se antaa myös suunnittelutiimeillesi yksinkertaisen kielen muutosten käsittelyyn.

Ylemmällä tasolla voit ajatella näitä ensisijaisia vyöhykkeitä:

Pelialue: – pelaajille suunnatut palvelut, pelilogiikka, matchmaking, chat, aulat, telemetria ja pelikohtaiset tietokannat.
Lompakkoalue: – maksu- ja lompakkopalvelut, avaintenhallinta, tilikirjatietokannat, selvityspalvelut ja lohkoketjusolmut.
Hallinta-alue: – operaatiokonsolit, tukityökalut, määrityskäyttöliittymät, valvonta, tietoturvatyökalut ja sisäinen raportointi.
Integraatioalue: – kolmannen osapuolen petokset, analytiikka, markkinointijärjestelmät, maksuyhdyskäytävät ja kaikki ulkoiset järjestelmät, jotka tarvitsevat syvempää yhteyttä.

Jokaisella näistä vyöhykkeistä tulisi olla omat verkkosegmenttinsä (esimerkiksi erilliset virtuaaliverkot tai VPC:t, aliverkot ja käyttöoikeusryhmät) ja selkeät, dokumentoidut säännöt siitä, minkä muiden vyöhykkeiden kanssa se voi kommunikoida.

Pieni vertailutaulukko voi tehdä tästä konkreettista:

Vyöhyke	Päätarkoitus	Esimerkkiresurssit
Peli	Pelaajien vuorovaikutus ja pelattavuus	Pelipalvelimet, aulat, matchmaking
Lompakko	Arvon varastointi ja siirto	Lompakon API:t, kirjanpitotietokannat, avainpalvelut
admin	Etuoikeutetut toiminnot ja valvonta	Hallintakonsolit, valvonta, petostentorjuntatyökalut
Integraatio	Hallittu kolmannen osapuolen yhteys	Maksuyhdyskäytävät, analytiikka-alustat

Nämä vyöhykkeet vastaavat suoraan eri riskitasoja. Lompakko- ja hallintavyöhykkeillä on paljon suurempi suora liiketoiminta- ja sääntelyvaikutus kuin pelivyöhykkeillä, joten niiden rajoja ja yhteyksiä on valvottava tarkemmin.

Luottamusrajojen vetäminen ja "ei koskaan sallittujen" virtausten tekeminen

Vyöhykkeiden suunnittelusta on hyötyä vain, jos niiden välisiä rajoja käsitellään kovina reunoina. Sinun on määriteltävä, mitkä virtaukset ovat sallittuja, mihin suuntaan ne kulkevat ja mitkä virtaukset eivät yksinkertaisesti ole koskaan sallittuja, jotta sekä insinöörit että tilintarkastajat näkevät, mihin rajat vedetään.

Kun sinulla on vetovyöhykekaavio, seuraava vaihe on merkitä luottamusrajat ja "ei koskaan sallittuja" yhteyksiä. Luottamusraja on olemassa aina, kun liikenne ylittää eri riskitasojen vyöhykkeiden välillä. Yleisiä esimerkkejä ovat:

Julkisesta internetistä pelialueelle.
Pelialueelta lompakkoalueelle.
Hallinta-alueelta peli- tai lompakkoalueille.
Integraatiokumppaneista peli- tai lompakkopalveluihin.

Päätä kullekin rajalle:

Mihin suuntaan tai suuntiin liikenne saa kulkea.
Mitkä protokollat ja portit ovat hyväksyttäviä kyseiselle liikenteelle.
Mitkä identiteetti- tai todennusmekanismit suojaavat yhteyttä.
Onko yhteys yksisuuntainen, kuten pelikutsujen lompakko-API:t, mutta ei päinvastoin.

Listaamalla työnkulut erikseen ei ikinä Sallittujen yhteyksien listaaminen on yhtä tärkeää kuin sallittujen yhteyksien listaaminen. Esimerkiksi lompakkojärjestelmien ei tulisi koskaan muodostaa suoria yhteyksiä pelialueelle, ylläpitäjien työasemien ei tulisi selata julkista internetiä suoraan, eikä integraatiokumppaneilla tulisi olla suoraa tietokantayhteyttä pelin tai lompakon tietovarastoihin.

Nämä päätökset ohjaavat myöhemmin palomuuri- ja suojausryhmäsääntöjä, palveluverkkokäytäntöjä ja nollaluottamuskäyttöoikeusasetuksia, ja niitä on paljon helpompi perustella, kun ne on ankkuroitu tiettyihin hyökkäyspolkuihin ja liiketoimintavaikutuksiin.

Kolmannen osapuolen integraatioiden käsittely omana riskikategorianaan

Kolmannen osapuolen työkalut ja palvelut tarvitsevat usein syvällistä näkyvyyttä, mutta niiden ei pitäisi saada tosiasiallista sisäisen verkon asemaa. Niiden käsittely erillisenä integraatioalueena pitää rajan selkeänä ja helpottaa heidän puolellaan olevien vikojen perustelemista vaarantamatta lompakon tai järjestelmänvalvojan turvallisuutta.

Kolmannen osapuolen työkalut ja palvelut voivat hiljaisesti heikentää segregaatiota, jos niiden annetaan sijaita "kaikkialla". Jotta voit hallita niitä, käsittele niitä erillisenä integraatioalueena ja käytä sääntöjä, kuten:

Kaiken kolmannen osapuolen liikenteen on kuljettava tarkasti määriteltyjen ja todennettujen API-rajapintojen tai yhdyskäytävien kautta.
Kolmannen osapuolen järjestelmillä ei saa olla suoraa pääsyä lompakkotietokantoihin tai hallintakonsoleihin.
Kaikki saapuvat webhookit päättyvät selkeästi määriteltyyn osaan peliä tai integraatioaluetta ja läpäisevät validoinnin.

Esimerkiksi petostentorjunta-alusta voi kutsua raportointi-API:a integraatiovyöhykkeellä, mutta se ei saa koskaan tehdä kyselyä suoraan lompakon kirjanpitotietokannasta. Tämän vyöhykkeen ja vastaavien esimerkkien muodollistaminen helpottaa huomattavasti vaikutusten arviointia, jos jokin näistä palveluntarjoajista vaarantuu, ja auttaa tilintarkastajia osoittamaan, ettet ole vahingossa myöntänyt heille rajoittamatonta sisäistä pääsyä.

Kun olet varma, että vyöhykkeesi ja luottamusrajasi ovat järkeviä paperilla, seuraava haaste on rakentaa arkkitehtuuri, joka valvoo niitä rikkomatta viivettä tai saatavuutta.

Eriytetyn arkkitehtuurin rakentaminen, joka silti toimii

Voit yhdistää karkean verkon segmentoinnin ja tarkat hallintatoiminnot suojataksesi lompakoita ja hallintakonsoleita vahingoittamatta pelin latenssia. Tärkeintä on sisällyttää segmentointi arkkitehtuuriin ja kapasiteettisuunnitteluun alusta alkaen sen sijaan, että raskaita tarkastuslaitteita asennettaisiin vasta sitten, kun pelaajat jo valittavat ja operatiiviset tiimit ovat ylikuormitettuja.

Pelaamisessa usein huolenaiheena on, että vahvempi verkon erottelu vahingoittaa pelaajakokemusta tai toiminnan ketteryyttä. Näin tapahtuu vain, kun segmentointi otetaan käyttöön ilman suorituskykysuunnittelua. Kun se suunnitellaan alusta alkaen latenssi- ja läpimenoaikatarpeet mielessä pitäen, voidaan yleensä saavuttaa molemmat tavoitteet.

Karkean segmentoinnin ja hienojakoisten kontrollien yhdistäminen

Tehokas arkkitehtuuri alkaa erottamalla tärkeimmät vyöhykkeet verkkotasolla ja sitten tiukentamalla tiettyjä palveluiden välisiä polkuja yksityiskohtaisemmilla säännöillä. Karkeampien ja hienojakoisempien kontrollien tulisi toimia yhdessä, ei kilpailla keskenään, jotta yksittäinen virheellinen konfigurointi ei altista koko alustaa.

Infrastruktuuritasolla on kaksi laajaa vipuvartta:

Karkea segmentointi: – erilliset virtuaaliverkot, aliverkot, VLANit, reititysdomeenit tai pilvitilit eri vyöhykkeille.
Hienojakoiset säätimet: – isäntäpalvelimien palomuurit, palveluverkkosäännöt, säilöverkkokäytännöt tai sovellustason käyttöoikeustarkistukset kriittisillä poluilla.

Järkevä kaava on:

1. Erilliset verkot päävyöhykkeittäin

Käytä erillisiä virtuaaliverkkoja tai VPC:itä vyöhykettä kohden, jossa on eksplisiittinen, hallittu vertaisliikenne tai yhdyskäytävät.

2. Jaa toiminnot kunkin vyöhykkeen sisällä

Luo aliverkkoja ja suojausryhmiä tai verkkokäytäntöjä erottaaksesi toiminnot, kuten käyttöliittymäpalvelut ja sisäiset tietovarastot.

3. Käytä mikrosegmentointia kriittisillä poluilla

Salli vain tiettyjen palveluiden tai podien kommunikoida määriteltyjen rajojen yli, jopa vyöhykkeen sisällä.

Tämä yhdistelmä tarkoittaa, että jos hyökkääjä murtautuu yhteen pelin mikropalveluun, hän ei silti voi vapaasti tutkia pelin muita osia, puhumattakaan lompakosta tai hallintatasoista.

Latenssin ja saatavuuden suunnittelu alusta alkaen

Suojaat sekä pelaajia että lompakoita, kun suunnittelet turvalaitteita osaksi liikenne- ja kapasiteettimalliasi. Erottelusta tulee sitten arkkitehtoninen ominaisuus, ei jälkikäteen mietitty asia, ja suorituskyvyn kompromissit näkyvät riittävän ajoissa, jotta niitä voidaan käsitellä rauhallisesti.

Reaaliaikaiset pelit ovat herkkiä pelaajien välisen polun ja pelin ydinlogiikan viiveille. Välttääksesi ennakoimattomia viiveitä:

Pidä syvällinen tarkastus ja monimutkainen välityspalvelinten käyttö poissa latenssin kannalta kriittisimmistä virroista aina kun mahdollista.
Sijoita verkkosovellusten palomuurit ja API-yhdyskäytävät HTTP-pohjaisten peli-APIen eteen, äläkä keskelle puhdasta peliliikennettä.
Suunnittele tarkastuslaitteiden, yhdyskäytävien ja palomuurien kapasiteetti realististen huippuliikennemäärien perusteella, älä pelkästään keskiarvojen perusteella.

Jos käytät palveluverkkoja tai verkkokäytäntöjä Kubernetesin tai vastaavien orkestroijien sisällä, testaa, miten ne vaikuttavat liikenteeseen kuormituksen aikana, ja säädä asetuksia ennen täydellistä käyttöönottoa. Sen sijaan, että käsittelisit tietoturvalaitteita lisäosina, sisällytä ne kapasiteettisuunnitteluun ja pelien julkaisuprosesseihin, jotta suorituskykyongelmat havaitaan ja korjataan varhaisessa vaiheessa.

Muutosten turvallinen tekeminen automaation ja testauksen avulla

Erottelusäännöt muuttuvat ajan myötä, kun lisäät otsikoita, alueita tai uusia lompakon ominaisuuksia. Näiden muutosten automatisointi vähentää konfiguraation ajautumista ja pitää sinut ajan tasalla ISO 27001 -muutoksenhallinta- ja valvontajärjestelmien kanssa, jotta suunnittelutarkoitus ei hitaasti heikkene.

Monimutkaisten segmentointisääntöjen manuaalinen konfigurointi on virhealtista. Jotta arkkitehtuuri pysyisi vakaana uusia nimikkeitä, alueita tai lompakon ominaisuuksia lisättäessä:

Määritä verkot, aliverkot, suojausryhmät, palomuurisäännöt ja verkkokäytännöt käyttämällä infrastruktuuria koodina tarkistettavia ja toistettavia käyttöönottoja varten.
Ota käyttöön automaattiset testit tai canary-tarkistukset kriittisten polkujen varmistamiseksi (esimerkiksi "peli-API voi edelleen tavoittaa lompakko-API:n TLS:n kautta oikean portin kautta") jokaisen muutoksen jälkeen.
Seuraa ja tarkista poikkeuksia ja kirjaa ylös, kuka ne hyväksyi, kuinka kauan ja mitä korvaavia kontrollitoimenpiteitä on olemassa.

Yhdistämällä koodina käytettävän infrastruktuurin tarkoitukselliseen testaukseen vähennät riskiä, että suorituskykyyn liittyvät korjaukset tai hätämuutokset rikkovat vahingossa erottelumallisi. Luot myös selkeitä artefakteja, jotka tukevat asiaankuuluvia ISO 27001 -standardin mukaisia muutos- ja valvontamekanismeja, mikä helpottaa tarkastajien osoitusta siitä, että suunnittelusi pysyy muuttumattomana ajan kuluessa.

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

Varaa esittelysi

Käyttöoikeus, identiteetti ja nollaluottamus segmenttien välillä

Verkon segmentointi on paljon vahvempaa, kun jokainen vyöhykkeiden välinen siirtyminen riippuu varmennetusta identiteetistä ja eksplisiittisestä käytäntöpäätöksestä, ei pelkästään laitteen sijainnista. Nollaluottamusperiaatteet auttavat sinua toteuttamaan A.8.22:n tavalla, joka olettaa kompromissien olevan mahdollisia ja rajoittaa silti vahinkoja, kun joku tai jokin liikkuu peli-, lompakko- ja hallintavyöhykkeiden välillä, ja pelkät verkkorajat eivät enää riitä. Nykyaikaiset arkkitehtuurit olettavat, että jonkinlainen kompromissi on aina mahdollinen, joten nollaluottamusajattelu täydentää A.8.22:ta varmistamalla, että siirtyminen vyöhykkeeltä toiselle riippuu aina vahvoista identiteetti- ja käytäntöpäätöksistä, ei siitä, missä laite sattuu olemaan verkossa.

Vyöhykkeiden ylitysten ankkurointi vahvaan identiteettiin

Turvallisimmat alueiden väliset yhteydet ovat sellaisia, joissa voit nimetä tarkalleen, mikä identiteetti saa ylittää verkon, millä ehdoilla ja miksi se on edelleen hyväksyttävä riski. Jokaisen tärkeän yhteyden sitominen tiettyyn identiteettiin muuttaa staattiset verkkosäännöt eläviksi, auditoitaviksi kontrolleiksi, joita voit tarkastella ja tarkentaa.

Jokaisen merkittävän rajanylityksen kohdalla kysy:

Kuka tai mikä saa ylittää rajoja – rooli, palvelu, koneidentiteetti?
Miten henkilöllisyys todistetaan – monivaiheisella todennuksella, asiakasvarmenteilla, työkuorman identiteeteillä, lyhytaikaisilla tunnistetiedoilla?
Kuka hyväksyy ja tarkistaa kyseisen käyttöoikeuden ja kuinka usein tarkastus tapahtuu?

Esimerkiksi IP-pohjainen sääntö voi sanoa, että "mikä tahansa aliverkon X palvelin voi kutsua lompakon API:a", kun taas identiteettipohjainen sääntö sanoo, että "vain pelin taustapalvelu, jolla on tämä varmenne ja rooli, voi kutsua tiettyjä lompakon päätepisteitä". Jälkimmäinen on paljon vankempi ja helpompi auditoida. Samoin:

Ylläpitäjän pääsy lompakkokonsoleihin tulisi olla mahdollista vain hallintavyöhykkeen koneilta kovetetun hyppyisännän tai suojatun käyttöpalvelun kautta käyttäen monivaiheista todennusta ja roolipohjaista valtuutusta.
Pelien taustapalveluista lompakko-API-rajapintoihin tulevien palveluiden välisten kutsujen tulisi käyttää keskinäistä TLS:ää tai vastaavaa, jolloin lompakkopuoli tarkistaa kutsuvan palvelun identiteetin ja valtuutuksen, ei pelkästään sen IP-osoitetta.

Toisin sanoen verkkosäännöt ovat välttämättömiä, mutta eivät riittäviä; ne on sidottava identiteetti- ja valtuutuslogiikkaan, jos halutaan, että erottelu kestää nykyaikaisia hyökkäystekniikoita.

Etuoikeutettujen ja tukipalveluiden käyttöoikeuksien turvallinen hallinta

Etuoikeutetut ja tuetut käyttöreitit ovat tehokkaimpia vyöhykkeiden välisiä reittejä. Niiden huolellinen suunnittelu pitää ne kapeina, auditoitavina ja paljon vaikeampina väärinkäyttää, samalla antaen tiimien tehdä työnsä ilman loputtomia kiertoteitä.

Etuoikeutettujen käyttöoikeuksien hallitsemiseksi:

1. Keskitä hallinnolliset sisääntulokohdat

Keskitä hallinnolliset käyttöoikeusreitit pieneen määrään suojattuja tukikohtia tai hyppypalvelimia tai hyvin hallittuun nollaluottamusperiaatteella toimivaan käyttöpalveluun.

2. Rajoita bastionien ulottuvuutta

Varmista, että kyseiset aloituspisteet sijaitsevat hallintavyöhykkeellä ja että ne voivat käyttää vain asianmukaisten vyöhykkeiden hallintaliittymiä tarkasti määriteltyjen sääntöjen mukaisesti.

3. Estä suora hallinta yleisistä verkoista

Estä suora SSH-, RDP- tai tietokantayhteys käyttäjien työasemista tai yleisistä yritysverkoista peli- tai lompakkosolmuihin ja kirjaa lokiin, ja mahdollisuuksien mukaan tallenna, hallinnolliset istunnot.

Tuki- ja operatiivisen henkilöstön, jonka on tarkasteltava pelaaja- tai lompakkotietoja, tulisi tehdä se hallittujen sovellusten kautta hallintavyöhykkeellä, ei suoraan tietokantoihin muodostettavien ad-hoc-yhteyksien kautta. Yhdessä nämä toimenpiteet pitävät tehokkaat käyttöreitit kapeina, valvottuina ja paljon vähemmän houkuttelevina hyökkääjille.

Käyttöoikeusmallien pitäminen linjassa todellisuuden kanssa

Käyttöoikeusmallit muuttuvat henkilöstön siirtyessä rooleista toiseen, palveluita päivitettäessä ja kolmansia osapuolia vaihdettaessa. Säännöllinen hygienia pitää suunnitellun käyttöoikeusmallin ja todellisen kokoonpanon yhdenmukaisina, mikä on tärkeää sekä turvallisuuden että ISO 27001 -standardin mukaisen todisteen kannalta, kun halutaan osoittaa, että käyttöoikeuksia todella hallitaan.

Ajan myötä liiketoiminta muuttuu, henkilöstö vaihtaa rooleja ja palveluita päivitetään. Ilman säännöllistä hygieniaa käyttöoikeusmallit ajautuvat eteenpäin. Jotta ne pysyisivät yhdenmukaisina:

Tarkista järkevällä tahdilla, mitkä roolit ja tilit voivat siirtyä lompakko- ja hallintavyöhykkeille, keskittyen ensin korkean käyttöoikeuden rooleihin.
Kiinnitä erityistä huomiota kolmannen osapuolen tukipalveluntarjoajiin, ulkoistettuihin toimintoihin ja urakoitsijoihin varmistaen, että tileillä on voimassaoloaika, rajattu soveltamisala ja selkeä omistajuus.
Vertaa aiottuja käyttöoikeusmatriisejasi siihen, mitä identiteetintarjoajasi, VPN-verkkosi, etäkäyttösi ja hyppyisäntäjärjestelmäsi todellisuudessa sallivat, ja korjaa kaikki löytämäsi aukot.

Kun voidaan osoittaa, että vain pieni, hyvin määritelty joukko identiteettejä voi päästä kullekin vyöhykkeelle ja että näitä identiteettejä tarkistetaan säännöllisesti, sekä hyökkääjien että tarkastajien työ vaikeutuu.

Erottelun todistaminen: seuranta, lokikirjaus ja auditointitodisteet

ISO 27001 -standardin täyttämiseksi sinun on osoitettava paitsi että erottelu on olemassa paperilla, myös että sitä toteutetaan, seurataan ja tarkistetaan käytännössä. A.8.22-standardin osalta tämä tarkoittaa selkeitä suunnitteluesimerkkejä, konfiguraatiotodisteita ja toimintatietoja, jotka yhdistävät riskit hallintajärjestelmiin ja siihen, mitä verkossa todellisuudessa tapahtuu päivittäin, koska erottelun suunnittelu on vasta puolet kerroksesta ja ISO 27001 -standardin mukaan sinun on osoitettava, että hallintajärjestelmät eivät ole ainoastaan olemassa, vaan myös... toimivat tehokkaasti, mikä tässä tapauksessa tarkoittaa kykyä käydä auditoijan läpi suunnittelusi, näyttää, miten se on konfiguroitu, ja tarjota näyttöä siitä, että sitä seurataan ja tarkistetaan.

"Hyvän todisteen" näyttämisen päättäminen

Teet auditoinneista paljon helpompia, jos määrittelet etukäteen, miltä "hyvä" A.8.22-todiste näyttää peli-, lompakko- ja hallintaympäristöissäsi, ja pidät sen järjestyksessä vyöhykkeittäin ja kontrollien mukaan. Tällä tavoin sinun ei tarvitse kamppailla todisteiden kokoamiseksi aikapaineen alla tai luottaa heimojen tuntemukseen.

Ennen ensimmäistä tai seuraavaa tarkastusta sopikaa sisäisesti, mitä käytätte A.8.22 kohdan mukaisena todisteena. Tyypillisesti tähän kuuluvat:

Suunnitteluesineitä: – verkko- ja tietovuokaaviot, jotka näyttävät vyöhykkeet, luottamusrajat ja sallitut virrat.
Konfiguraatiositeetit: – palomuurin ja suojausryhmien konfiguroinnit, verkkokäytäntöjen määritykset, reititystaulukot, VPN- ja vertaisverkon konfiguroinnit.
Operatiiviset esineet: – muuttaa segmentointiin liittyvän työn tietueita, tarkistaa tietueita ja tapausraportteja, joissa erottelu vaikutti tuloksiin.
Varmuusartefaktit: – tunkeutumistestien tai punaisen tiimin raportit, joissa harjoitetaan vyöhykkeiden välistä liikkumista, sekä mahdolliset korjaussuunnitelmat.

Näiden artefaktien järjestäminen vyöhykkeittäin ja kontrollin mukaan helpottaa huomattavasti auditoijan ymmärrystä siitä, miten A.8.22 toteutuu omassa ympäristössäsi, ja helpottaa siirtymistä nopeasti suunnittelusta todentamiseen ja sitten varmentamiseen.

Riskien jäljitettävyys kontrolleihin ja lokeihin

Tilintarkastajat odottavat näkevänsä selkeän ketjun tunnistamistasi riskeistä valitsemiisi kontrolleihin, jotka osoittavat näiden kontrollien toimivuuden. Verkoston erottelun tulisi olla tiiviisti sidottu tähän ketjuun, jotta voit osoittaa tarkalleen, miksi kukin raja on olemassa ja miten se lieventää tiettyjä uhkia.

ISO 27001 -standardi edellyttää selkeää yhteyttä tunnistettujen riskien ja valittujen kontrollien välillä ja näyttöä siitä, että kyseiset kontrollit toimivat. Verkoston erottelun osalta:

Tunnista riskit, kuten ”hyökkääjät siirtyvät vaarantuneilta pelipalvelimilta lompakkoinfrastruktuuriin” tai ”tukikonsolit tarjoavat hallitsemattomia ristiinvuokraajia”.
Kirjaa jokaisen riskin osalta riskienhallintasuunnitelmaasi, että A.8.22 (ja kaikki siihen liittyvät kontrollit) käsittelevät sitä, ja kuvaile lyhyesti, miten.
Linkitä jokainen kontrollin kuvaus yhteen tai useampaan todisteeseen: asiaankuuluvaan kaavioon, konfiguraation vientiin, muutostietueeseen tai valvontanäkymään.

Kun tilintarkastaja kysyy "näytä minulle, miten erotat peli- ja lompakkoverkot", voit siirtyä riskinhallinnasta suunnitteluun, konfigurointiin ja valvontaan hyvin nopeasti sen sijaan, että etsisit hajallaan olevia dokumentteja.

Alueiden välisen aktiivisuuden seuranta ja testaus

Seurannan ja testauksen avulla voit todistaa, että erottelu toimii päivittäisissä toiminnoissa ja stressitilanteissa, ei vain suunnittelutyöpajoissa. Ne myös vahvistavat laajempaa havaitsemis- ja reagointikykyäsi tuomalla epätavallisen vyöhykkeiden välisen käyttäytymisen selvästi esiin.

Seuranta on päivittäinen todiste siitä, että erottelu ei ole vain paperilla. Sinun tulisi:

Kirjaa kaikkien merkittävien vyöhykkeiden välisten yhteyksien yritykset ja onnistumiset, mukaan lukien lähde, kohde, identiteetti ja tehdyt toimenpiteet.
Syötä nämä lokit valvonta- tai tietoturvatietojen ja tapahtumien hallintatyökaluihin hälytyksillä epätavallisista tai kielletyistä poluista.
Testaa erottelua säännöllisesti kokeilemalla kontrolloituja toimia, jotka tulisi estää, ja kirjaamalla tulokset todisteeksi.

Sisäiset auditoinnit tai violetin tiimin harjoitukset, jotka nimenomaisesti yrittävät rikkoa segmentointimalliasi, paljastavat usein virheellisiä konfiguraatioita tai unohdettuja perinnepolkuja. Kun sisällytät niiden havainnot ja korjaukset todistusaineistoosi, osoitat paitsi suunnittelua myös jatkuvaa parantamista ja kypsyvää tapauksiin reagointia.

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

Varaa esittelysi

Kryptolompakkokohtainen erottelu ja koventaminen

Lompakkoympäristöjä tulisi käsitellä arvokkaina erillisinä yksiköinä, joilla on erittäin rajalliset ja hyvin hallitut yhteydet peli-, hallinta- ja integraatioalueille. Verkon erottelusuunnittelussa on oletettava, että peliympäristö saattaa olla vihamielinen, mutta silti on pidettävä lompakon avaimet, saldot ja kriittiset toiminnot turvassa ja havaittavissa jopa paineen alla. Tämä johtuu siitä, että lompakkoinfrastruktuuri ansaitsee erityiskohtelua: monet pelikomponentit käsittelevät pelaajakokemusta, kun taas lompakkokomponentit käsittelevät suoraan arvoa, avaimia ja joskus säänneltyjä taloudellisia prosesseja. Verkkoerottelusuunnittelussa tulisi tehdä tämä ero selväksi.

Lompakon käsittely omana erillisalueenaan

Lompakkoympäristön ajatteleminen enklaavina auttaa sinua suunnittelemaan yhteyksiä sisäänpäin hyvin säästeliäästi ja hallitsemaan niitä poikkeuksina, ei oletusarvoina. Tavoitteena on, että edes vakava vika muualla ei voi hiljaa ohittaa näitä rajoja tai pyyhkiä pois todisteita tapahtuneesta.

Turvallisin oletus on, että lompakkoympäristö on erillisalue kokonaisalustasi sisällä:

Vain pieni joukko hyvin määriteltyjä sovellusvirtoja pelistä tai integraatioalueilta voi saavuttaa lompakkopalvelut kovennettujen API-rajapintojen tai yhdyskäytävien kautta.
Lompakkojärjestelmien hallinta tapahtuu admin-alueelta erillisten, vahvasti valvottujen polkujen kautta.
Suora tietokannan käyttö lompakkoalueen ulkopuolelta on erittäin rajoitettua tai estettyä.

Lompakkoalueen sisällä voit sitten soveltaa lisäsegmentointia. Voit esimerkiksi:

Erota avainmateriaalia tai allekirjoitusta käsittelevät rajapinnat julkisia API-rajapintoja palvelevista rajapinnoista.
Eristä kirjanpitotietokannat hallintakonsoleista, vaikka ne jakaisivatkin pohjana olevan infrastruktuurin.

Tämä lähestymistapa pitää lompakkoympäristön pienenä, hyvin ymmärrettynä ja paljon helpommin puolustettavana ja valvottavana.

Jos käytät myös kuumia, lämpimiä ja kylmiä lompakoita, jokaisella tyypillä tulisi olla omat verkkorajoituksensa, jotka heijastavat sen suojaamaa arvoa ja hyväksyttävää toiminnallista kitkaa.

Lompakon kanssa kommunikoinnin rajoittaminen

Lompakon riskiä voidaan merkittävästi vähentää rajoittamalla tiukasti siihen pääsevien identiteettien ja tietovirtojen määrää. Kaiken muun, mukaan lukien hyödyllisten analytiikka- ja tukityökalujen, tulisi nähdä vain suodatettuja, koottuja tai viivästettyjä tietoja, jotka eivät voi suoraan muuttaa saldoja tai avaimia.

Jokainen lompakkoalueelle tuleva yhteys tulee tarkastaa:

Pelien taustapalveluiden tulisi kutsua vain tiettyjä lompakko-API-rajapintoja käyttäen tiukkaa todennusta ja valtuutusta.
Lompakon toimintaan vaikuttaviin hallintakonsoleihin tulisi päästä vain hallintavyöhykkeeltä ja vain kovennettujen kirjautumispisteiden kautta.
Kolmannen osapuolen palveluilla ei tulisi olla suoraa yhteyttä lompakkotietokantoihin; niiden tulisi käyttää valvottuja vientitietoja tai raportointi-API-rajapintoja.

Yleinen huono kaava on sallia analytiikka-alustan muodostaa suora yhteys lompakon kirjanpitotietokantaan "mukavuussyistä". Parempi ratkaisu on sen sijaan näyttää raportointi-API tai säännöllinen vienti raportointisäilöstä integraatiovyöhykkeellä. Protokollan ja skeeman validointi lompakon rajoilla on myös tärkeää, jotta liikenne ei ole ainoastaan oikeassa portissa, vaan myös oikein muodostettu ja valtuutettu.

Valmistautuminen vihamielisiin peliympäristöihin

Jos oletat peliympäristön lopulta vaarantuvan, suunnittelet lompakoiden erottelua ja toimintoja, jotka toimivat edelleen paineen alla. Tämä ajattelutapa on hyvin linjassa nykyaikaisten odotusten kanssa operatiivisesta sietokyvystä ja kasvavasta sääntelykiinnostusta iskunkestäviä arkkitehtuureja kohtaan.

Oletetaan, että peliympäristö vaarantuu jossain vaiheessa. Lompakon suunnittelun tulisi heijastaa tätä:

Lompakkojärjestelmien ylläpito- ja palautuspolkujen ei tulisi riippua pelkästään reaaliaikaisesta peli-infrastruktuurista tai pelialueen tunnistetiedoista.
Lompakkotoiminnan seurannan ja siitä ilmoittamisen ei pitäisi riippua yksinomaan pelialueen läpi kulkevista lokitietoputkista.
Merkittävien lompakkohäiriöiden varalta laadittujen operatiivisten käsikirjojen tulisi sisältää selkeät vaiheet pelien välisten yhteyksien eristämiseksi säilyttäen samalla olennaiset toiminnot, kuten saldon eheystarkastukset ja sääntelyyn perustuvat raportointiominaisuudet.

Kun pystyt osoittamaan, että lompakkoympäristöäsi voidaan edelleen hallita ja tarkkailla, vaikka peliympäristöön ei luotettaisi, ylität A.8.22-standardin perusvaatimustenmukaisuuden ja saavutat aitoa operatiivista joustavuutta, jollaista sääntelyviranomaiset ja kumppanit yhä useammin odottavat.

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

ISMS.online tarjoaa käytännöllisen tavan pitää A.8.22-verkon erottelusuunnitelmasi elossa, näkyvänä ja auditoitavana sen sijaan, että se hautautuisi staattisiin kaavioihin ja hajallaan oleviin dokumentteihin. Se muuttaa vyöhykkeesi, rajasi ja sääntösi tietoturvallisuuden hallintajärjestelmäsi eläviksi osiksi, jotka pysyvät linjassa peli- ja lompakkoalustasi todellisen toiminnan kanssa.

ISMS.onlinen avulla voit:

Tallenna ja ylläpidä peli-, lompakko- ja hallintavyöhykemäärityksiä, luottamusrajoja ja kiellettyjä työnkulkuja yhdessä jäsennellyssä mallissa.
Linkitä yksittäiset resurssit ja palvelut tiettyihin vyöhykkeisiin ja hallintalaitteisiin, jotta näet, mitkä alustan osat ovat riippuvaisia mistä säännöistä.
Tallenna ja versioi keskeiset tiedostot, kuten verkkokaaviot, konfiguraatioviennit, sääntöjen tarkistustietueet ja testitulokset asiaankuuluvien kontrollien rinnalla.
Määritä ja seuraa korjaustehtäviä, kun tarkastelut, testit tai tapaukset paljastavat heikkouksia erottelumallissasi.
Anna tilintarkastajille ja kumppaneille selkeitä ja johdonmukaisia vastauksia käymällä heidät läpi yhden yhtenäisen kerroksen riskistä suunnitteluun ja toimintaan.

Näiden ominaisuuksien avulla voit muuttaa verkostoerottelutyön kertaluonteisesta projektista jatkuvaksi käytännöksi, jota on helppo selittää, ylläpitää ja parantaa.

Kuinka ISMS.online auttaa sinua pitämään A.8.22:n aktiivisena ISMS-järjestelmässäsi

Vahvistat sekä vaatimustenmukaisuutta että tietoturvaa, kun verkon eriyttämispäätökset tallennetaan osaksi tietoturvanhallintajärjestelmääsi sen sijaan, että ne jäisivät erillisiin kaavioihin tai henkilökohtaisiin muistiinpanoihin. ISMS.online antaa sinun linkittää A.8.22:n suoraan riskeihin, kontrolleihin ja näyttöön, jotta kokonaiskuva on aina saatavilla.

Käytännössä voit yhdistää A.8.22:n tiettyihin riskeihin, kuten sivuttaisliikkeeseen pelistä lompakkoympäristöihin, tallentaa valitsemasi kontrollit ja liittää mukaan kaavioita, konfiguraatiokuvia ja tarkistustietoja. Kun suunnittelusi muuttuu, voit päivittää kontrollin kerran ja pitää siihen liittyvät todisteet ajan tasalla. Tämä helpottaa huomattavasti tilintarkastajille osoittamista, että A.8.22 on sekä suunniteltu että aktiivisesti ylläpidetty.

Miltä tämä näyttää jokapäiväisessä käytössä

Haluat päivittäin, että erottelu tuntuu luonnolliselta osalta alustan toimintaa, ei ylimääräiseltä raportointitehtävältä. ISMS.online tukee tätä muuttamalla arvioinnit, muutokset ja tapaukset jäsennellyiksi päivityksiksi vaikeasti seurattavien ad hoc -dokumenttien sijaan.

Esimerkiksi kun lisäät uuden nimikkeen, alueen tai lompakon ominaisuuden, voit kirjata muutoksen, liittää päivitetyt verkkokaaviot ja tallentaa hyväksynnät yhteen paikkaan. Kun tarkistat palomuurisääntöjä tai suoritat vyöhykkeiden välisen eston testin, voit linkittää tulokset suoraan takaisin A.8.22:een. Ajan myötä tämä rakentaa selkeän ja toistettavan kerroksen, joka osoittaa, miten pidät peli-, lompakko- ja hallintaympäristöt erillään ja hallinnassa.

Jos haluat seuraavan ISO 27001 -auditointisi osoittavan, että peli-infrastruktuurisi kompromissia ei voida helposti siirtää lompakoihin tai hallintajärjestelmiin – ja haluat, että tämä kerros on helppo havaita – alustan valitseminen, joka tekee A.8.22-päätöksistä ilmeisiä, ajankohtaisia ja hyvin perusteltuja, on luonnollinen seuraava askel tiimillesi.

Varaa demo

Usein Kysytyt Kysymykset

Mitä tästä usein kysyttyjen kysymysten luonnoksesta puuttuu tai on heikkoa ISO 27001 / pelilompakon näkökulmasta?

Luonnos on selkeä ja teknisesti hyvä, mutta se toistaa itseään, käyttää liian vähän esimerkkejä pelitoiminnasta eikä aina johda lukijaa konkreettisiin suunnittelupäätöksiin tai ISO 27001 -auditoinnin tuloksiin.

Missä veto toimii hyvin?

On olemassa vankkoja perustuksia, jotka sinun tulisi pitää yllä:

Se tulkitsee oikein A.8.22 vaatimuksena tahalliselle verkon erottelu ja liikenteen hallinta peli-, lompakko- ja hallintaympäristöjen välillä.
Focus-patjan nelivyöhykkeinen malli (Peli / Lompakko / Ylläpito / Integraatio) on intuitiivinen ja helppo selittää insinööreille ja auditoijille.
Se korostaa, että tilintarkastajat haluavat nähdä ketju riskistä → kontrollin suunnittelusta → konfiguroinnista → toiminnasta, ja juuri näin ISO 27001 -standardin mukaiset arvioinnit yleensä toimivat.
Se korostaa tärkeitä käytäntöjä, kuten infrastruktuuri koodina, oletusarvoisesti estävät säännötja mikrosegmentointi, jotka kaikki ovat uskottavia, nykyaikaisia valvontamenetelmiä.

Joten sinun ei tarvitse heittää tätä pois; sinun täytyy tiukentaa, eriyttää ja terävöittää sitä.

Missä veto on tehoton tai toistuva?

Muutamat kaavat vetävät pisteitäsi alas:

Toisto eri vastauksissa:

Useissa osioissa toistetaan sama ajatus ("erottelu on enemmän kuin palomuurisääntö", "vyöhykkeiden tulisi kommunikoida eksplisiittisten yhdyskäytävien kautta") vain pienin sanamuotomuutoksin. Tämä tuntuu pikemminkin täytetyltä kuin osuvalta ajatukselta.

Ei tarpeeksi *pelikohtaisia* yksityiskohtia

Mainitset pari kertaa matchmakingin ja chatin, mutta suurin osa sisällöstä voisi soveltua pankkisovellukseen tai SaaS-tuotteeseen. Peli + lompakko -pinon auditoijat ja insinöörit odottaisivat esimerkiksi seuraavia asioita:

Otsikoiden väliset liikennemallit.
Live-ops-työkalut (A/B-testit, myynninedistäminen).
Huijauksenestopalvelut ja telemetria.
Pelaajien tukivirrat liittyvät taloudellisiin kiistoihin.

Rajoitettu ISO-spesifinen ankkurointi:

Käsittelet kohtaa A.8.22 oikein, mutta et oikeastaan sido sitä takaisin seuraaviin:

Kohdan 4.x laajuus/kontekstit (miksi peli, lompakko ja hallinta ovat olemassa erillisinä ”konteksteina”).
Kohdat 6, 8 ja 9 (riskien hallinta, toiminta, valvonta) useammalla kuin yleisellä tasolla.
Riippuvuudet muista liitteen A mukaisista kontrolleista, kuten A.5.23 (pilvipalvelut) tai A.5.24–A.5.27 (tapahtumat).

Muutamia konkreettisia "hyviä vs. huonoja" skenaarioita:

Kaikki on kuvattu suunnittelutasolla. Sinulta puuttuu lyhyet ”tämä menee pieleen, kun…” -tarinat, jotka jäävät lukijan mieleen ja saavat katsojat nyökkäilemään.

Heikot toimintakehotukset:

ISMS.online mainitaan, mutta vain ajatuksena, että ”tämän voisi pitää jäsennellyssä tietoturvajärjestelmässä”. Ei ole vahvaa käsitystä siitä, että:

"Näin itse asiassa yhdistäisit tämän suunnitelman tietoturvajärjestelmän tietuejoukkoon."
"Tässä on tuska, jonka vältät tekemällä sen nyt seuraavan auditointijakson sijaan."

Mitä tulisi vahvistaa YMYL- / korkean riskin lompakkoympäristöissä?

Mikä tahansa, johon liittyy lompakot ja hallintakonsolit uhkapeli- tai oikean rahan ympäristössä sisältää olennaisen taloudellisen ja sääntelyyn liittyvän riskin. Tämä tarkoittaa:

Ole selkeä, että tämä ei ole laki- tai sääntelyneuvontaaja että organisaatioiden on tarkistettava paikalliset vaatimukset.
Huomioi, että krypto-/sähköisen rahan alustojen on ehkä myös yhdenmukaistettava segmentointi seuraavien kanssa:
Lisensointiehdot.
Sääntelyviranomaisten tekniset standardit tai ohjeet.
Maksujärjestelmän / korttiverkon odotukset.

Lyhyt, neutraali lause lompakko-osiossa voi kattaa asian:

Nämä esimerkit ovat teknisiä malleja, eivät oikeudellisia neuvoja; vahvista aina erityisvaatimukset sääntelyviranomaiseltasi tai järjestelmältäsi.

Miten tästä voisi tehdä ilmeisemmän hyödyllisen tietoturvajohtajalle tai alusta-arkkitehdille?

On kolme suurta tilaisuutta:

Sido jokainen vastaus suunnittelu- tai päätöstulokseen
Esimerkiksi kaavoitus-UKK:n lopussa mainitaan nimenomaisesti:

"Jos vyöhykkeitä on yli neljä, kerrosrakenne voi olla liian monimutkainen."
”Jos sinulla on vain yksi suuri tasainen verkko, A.8.22 on suuri jäännösriski.”

Esittele yksinkertaiset päätöstaulukot
Sen sijaan, että kuvailisit kaavoja abstraktisti, näytä jotain seuraavanlaista:

Kysymys	Vähäriskinen vastaus	Korkean riskin vastaus
Voivatko pelipalvelimet päästä lompakkotietokantoihin?	Vain kapean API:n kautta yhdyskäytävän kautta.	Suorat tietokantayhteydet pelin isänniltä.
Voivatko tukityökalut muuttaa lompakon saldoja?	Vain valvottujen API-rajapintojen kautta, joilla on hyväksynnät.	Suora SQL- tai hallintakonsolin käyttöoikeus.
Mihin kolmannen osapuolen työkalut kytketään?	Integraatioalue määritellyillä sopimuksilla.	Sekoitettu sisäisiin aliverkkoihin "nopeuden" vuoksi.

Se auttaa insinöörejä ja tilintarkastajia luokittelemaan nykytilansa nopeasti.

Näytä, miten tämä sopii laajempaan liitteen L / IMS:n kokonaiskuvaan.
Monet pelioperaattorit eivät käytä pelkästään ISO 27001 -standardia. Heillä on:

ISO 9001 tai vastaavat laatustandardit.
ISO 22301 jatkuvuuden varmistamiseksi.
Tietosuoja-/turvallisuusvelvoitteet.

Voit lyhyesti huomauttaa, että:

Sama kaavoitusajattelu tukee liiketoiminnan jatkuvuus (sisältää tapahtumia).
Erotteluvalinnat vaikuttavat saatavuuspalvelusopimukset ja palvelun laatu.

Kuinka voit terävöittää ISMS.online-sivustosi asemointia olematta myyntihenkinen?

Voit säilyttää saman ammattimaisen sävyn, mutta olla selkeämpi operatiivisesta voitosta:

Sijasta:

”Jos pidät nuo yhteydet strukturoidun tietoturvajärjestelmän, kuten ISMS.onlinen, sisällä, vältät tavanomaisen sekamelskan…”

kokeilla:

”Jos tallennat vyöhykkeesi, palomuurisääntösi, muutosten hyväksynnät ja testitulokset yhdessä alustassa, kuten ISMS.online, voit vastata klassiseen auditoijan kysymykseen – ’näytä minulle, miten A.8.22 todellisuudessa toimii tuotannossa’ – yhdessä paikassa sen sijaan, että jahtaisit puolta tusinaa järjestelmää ja ihmistä viikkoa ennen käyntiäsi.”

Se kunnioittaa edelleen lukijan itsenäisyyttä, mutta tekee hyödystä konkreettisen ja toimivan.

Lyhyesti sanottuna: luonnos on vahva pohja, mutta saat paljon korkeamman "pistemäärän", jos vähennät toistoa, lisäät pelikohtaisia skenaarioita, ankkuroit jokaisen vastauksen selkeisiin suunnittelu- tai auditointipäätöksiin ja teet ISMS.online-työkalun arvosta konkreettisempaa stressaantuneille tietoturvajohtajille, tietosuojavastaaville ja oikean rahan ympäristöjä ylläpitäville ammattilaisille.