Microsoft Entra Conditional Access -hallinnointi vuonna 2026

On tiistai kello 09.12, kun nopeasti kasvavan eurooppalaisen fintech-yhtiön tietoturvajohtaja Maria avaa DORA-valmiusraportin, jonka piti olla rutiiniasia. Hänen Microsoft Entra Conditional Access -hallintanäkymänsä näyttää vahvalta. MFA on pakotettu ylläpitäjille. Legacy-todennus on estetty. Korkean riskin kirjautumiset haastetaan lisätodennuksella tai estetään. Arkaluonteiset taloushallinnon sovellukset edellyttävät vaatimustenmukaisia laitteita. Hallitsemattomilta päätelaitteilta tulevaa selainkäyttöä on rajoitettu.

Sitten hän lukee auditoijan havainnon.

”Conditional Access -sääntönne ovat teknisesti kunnossa, mutta ne toimivat irrallaan hallinnointikehyksestä. Näyttäkää johdon hyväksymä politiikka, joka edellyttää näitä asetuksia. Näyttäkää viime kuussa muutetun säännön muutostallenne. Näyttäkää, miten korkean riskin kirjautumiskäytäntö oli aktiivinen epäillyn tunnistetietojen massakokeiluhyökkäyksen aikana. Näyttäkää, miten tämä näyttö tukee ISO 27001-, DORA-, NIS2- ja GDPR-vaatimuksia.”

Identiteettitiimi pystyy viemään konfiguraation. SOC pystyy näyttämään kirjautumislokit. Vaatimustenmukaisuuspäällikkö pystyy viittaamaan politiikkakansioon. Kukaan ei kuitenkaan pysty tuottamaan yhtenäistä, hallinnoitua näyttökokonaisuutta, joka yhdistää riskin, politiikan, hyväksynnän, konfiguraation, poikkeukset, seurannan, tietoturvapoikkeamiin reagoinnin, tietosuojavelvoitteet ja johdon katselmoinnin.

Tämä on Conditional Access -hallinnoinnin ongelma vuonna 2026.

Microsoft Entra Conditional Access ei ole enää pelkkä identiteettiasetus. Se on johdon vastuulle kuuluva kontrollijärjestelmä, joka päättää, kuka voi käyttää pilvipalveluja, millä ehdoilla, miltä laitteilta, millä todennuksen vahvuudella ja millaisin istuntorajoituksin. Säännellyissä organisaatioissa näiden päätösten on oltava selitettävissä, perusteltavissa ja kartoitettavissa ISO/IEC 27001:2022-, NIS2-, DORA-, GDPR-, NIST- ja COBIT 2019 -velvoitteisiin.

Conditional Access on nyt auditoitava kontrollijärjestelmä

Conditional Access sijaitsee identiteetin, laitteen tietoturvatilan, sovelluksen arkaluonteisuuden, sijainnin, kirjautumisriskin, käyttäjäriskin, istuntokäyttäytymisen ja lokituksen leikkauspisteessä. Yksi käytäntö voi edellyttää MFA:ta, vaatia vaatimustenmukaista laitetta, estää käytön riskialttiista sijainnista, rajoittaa latauksia hallitsemattomista selaimista tai pakottaa uudelleentodennuksen riskin muuttuessa.

Tämä tekee siitä yhden Microsoftin pilviympäristöjen vahvimmista Zero Trust -toteutuspisteistä. Samalla siitä tulee erittäin auditoitava.

ISO/IEC 27001:2022 -standardin mukaan kontrolli ei ole kypsä vain siksi, että se on olemassa portaalissa. Organisaation on ymmärrettävä toimintaympäristönsä, arvioitava tietoturvariskit, valittava riskien käsittelytavat, dokumentoitava soveltuvuuslausunto, käytettävä kontrolleja, seurattava niiden vaikuttavuutta ja parannettava toimintaa ajan myötä. Keskeisiä kohtia ovat kohta 6.1.2 riskien arvioinnista, kohta 6.1.3 riskien käsittelystä, kohta 7.5 dokumentoidusta tiedosta, kohta 8.1 toiminnan suunnittelusta ja ohjauksesta, kohta 9.1 seurannasta ja kohta 9.3 johdon katselmoinnista.

ISO/IEC 27002:2022 -standardin kanssa yhdenmukainen liite A antaa käytännön kontrollikielen, jonka auditoijat tunnistavat. Conditional Access tukee yleisesti seuraavia kontrolleja:

• 5.15 pääsynhallinta
• 5.16 identiteetinhallinta
• 5.17 todennustiedot
• 5.18 käyttöoikeudet
• 8.1 käyttäjien päätelaitteet
• 8.2 etuoikeutetut käyttöoikeudet
• 8.3 tiedonsaannin rajoittaminen
• 8.5 turvallinen todennus
• 8.15 lokitus
• 8.16 seurantatoiminnot

EU:ssa säännellyille organisaatioille hallinnointivastuu on vielä selkeämpi. NIS2 Article 20 asettaa johdolle vastuun kyberturvallisuuden riskienhallintatoimenpiteiden hyväksymisestä ja valvonnasta. NIS2 Article 21 edellyttää asianmukaisia ja oikeasuhtaisia teknisiä, operatiivisia ja organisatorisia toimenpiteitä, mukaan lukien pääsynhallinta, omaisuudenhallinta, kyberhygienia, poikkeamien käsittely, toimitusketjun turvallisuus, vaikuttavuuden arviointi sekä monivaiheinen tai jatkuva todennus soveltuvin osin. NIS2 Article 23 tuo käyttöön vaiheistetun merkittävien poikkeamien raportoinnin, johon sisältyy varhaisvaroitus 24 tunnin kuluessa, poikkeamailmoitus 72 tunnin kuluessa ja loppuraportti kuukauden kuluessa.

DORA asettaa samankaltaisia odotuksia finanssialan toimijoille. Article 5 edellyttää sisäistä hallinnointi- ja kontrollikehystä. Article 6 edellyttää ICT-riskien hallintakehystä. Article 9 käsittelee suojausta ja ennaltaehkäisyä, mukaan lukien pääsyn rajoitukset ja identiteetinhallinnan käytännöt. Articles 10, 11, 17, 18 ja 19 yhdistävät havaitsemisen, reagoinnin, palautumisen, ICT-poikkeamien hallinnan, luokittelun ja raportoinnin. Koska DORAa sovelletaan 17. tammikuuta 2025 alkaen, finanssialan toimijoiden on käsiteltävä Conditional Accessia osana operatiivisen häiriönsietokyvyn näyttöä, ei pelkkänä identiteettien koventamisena.

GDPR tuo mukaan tietosuojan näkökulman. Jos Conditional Access suojaa järjestelmiä, jotka käsittelevät henkilötietoja, se tukee Article 5:n osoitusvelvollisuuden periaatteita, Article 24:n rekisterinpitäjän vastuuta, Article 25:n sisäänrakennettua tietosuojaa ja Article 32:n käsittelyn turvallisuutta. Jos luvatonta pääsyä epäillään, Conditional Access -lokit voivat muodostaa osan henkilötietojen tietoturvaloukkauksen arviointi- ja ilmoitusnäyttöä.

Virhe on käsitellä näitä erillisinä auditointipyyntöinä. Kypsä lähestymistapa on yksi Conditional Access -hallintamalli, jota voidaan tarkastella viitekehyksen, viranomaisen, asiakkaan tai johdon näkökulmasta.

Konfiguraatio ei ole hallinnointia

Useimmat organisaatiot pystyvät vastaamaan kysymykseen ”Mitä on konfiguroitu?” Harvemmat pystyvät vastaamaan vaikeampiin kysymyksiin:

• Miksi tämä Conditional Access -käytäntö on konfiguroitu tällä tavalla?
• Mitä riskiskenaariota se käsittelee?
• Mikä politiikan kohta edellyttää sitä?
• Kuka hyväksyi muutoksen?
• Mitkä käyttäjät, sovellukset ja laitteet on poissuljettu?
• Miten se testataan?
• Mitkä lokit osoittavat, että se toimi?
• Kuinka usein se katselmoidaan?
• Mitä tapahtuu, jos se epäonnistuu?

Tässä auditointihavainnot yleensä syntyvät. Politiikkoja on olemassa, mutta niitä ei ole linkitetty Microsoft Entra -asetuksiin. Laitteiden vaatimustenmukaisuus on IT-operaatioiden vastuulla, mutta sitä ei ole kartoitettu pääsynhallinnan riskiin. Kirjautumisriskikäytännöt on otettu käyttöön ilman dokumentoituja kynnysarvoja tai eskalointisääntöjä. Istuntorajoitukset on konfiguroitu, mutta niitä ei ole koskaan testattu hallitsemattomilta laitteilta. Lokit säilytetään, mutta niitä ei ole koottu auditointinäytöksi.

Clarysec käsittelee tätä jäljitettävyysongelmana. Jokaisen Conditional Access -päätöksen tulee yhdistää politiikka, riski, kontrolli, konfiguraatio, näyttö ja katselmointi.

Pk-yrityksen pilvipalvelujen käyttöpolitiikka-sme Pilvipalvelujen käyttöpolitiikka-sme – pk-yritys toteaa:

Monivaiheinen todennus (MFA) ylläpitäjä- ja käyttäjätileille

Osasta ”Politiikan toteutusvaatimukset”, politiikan kohta 6.2.2.

Tämä kohta on velvoite. Conditional Access -sääntö on sen soveltaminen. Kirjautumisloki on näyttö. Katselmointitallenne osoittaa valvonnan.

Pk-yrityksen verkkoturvallisuuspolitiikka-sme Verkkoturvallisuuspolitiikka-sme – pk-yritys lisää päätelaitteen tilaa koskevan vaatimuksen:

Järjestelmät, joissa ei ole ajan tasalla olevaa virustorjuntaa, korjauspäivityksiä tai hyväksyttävää laitteen tietoturvatilaa, on estettävä tai eristettävä

Osasta ”Politiikan toteutusvaatimukset”, politiikan kohta 6.4.3.

Microsoft Entra -ympäristössä tästä voi tulla ”edellytä vaatimustenmukaista laitetta”, ”estä tuetutonta alustaa käyttävät laitteet”, ”rajoita hallitsemattomia selainistuntoja” tai ”estä pääsy korkean riskin sovelluksiin tuntemattomilta laitteilta”. Kontrolli ei kuitenkaan ole valmis ennen kuin organisaatio pystyy osoittamaan soveltamisalan, hyväksynnän, testauksen, poikkeukset ja seurannan.

Rakenna hallinnointiperusta ennen sääntökokonaisuutta

Vahva Conditional Access -ohjelma alkaa Entra-portaalin ulkopuolelta. Se alkaa ISMS:stä, riskirekisteristä, pääsynhallintapolitiikasta, pilvipalvelujen käyttöpolitiikasta, SoA:sta ja näyttömallista.

Clarysecin Zenith Blueprint: auditoijan 30 vaiheen tiekartta Zenith Blueprint antaa käytännöllisen etenemisjärjestyksen. Riskienhallintavaiheen Step 13, Risk Treatment Planning and Statement of Applicability, ohjaa organisaatioita yhdistämään kontrollit riskeihin ja sääntelyperusteisiin:

Ristiinviittaa sääntelyyn: jos tietyt kontrollit on toteutettu nimenomaisesti GDPR-, NIS2- tai DORA-vaatimusten täyttämiseksi, voit merkitä tämän joko riskirekisteriin osana riskivaikutuksen perustelua tai SoA:n huomautuksiin.

Conditional Accessin osalta tämä muuttaa näyttökokonaisuuden. Sen sijaan, että organisaatio sanoisi ”Otimme MFA:n käyttöön”, se voi todeta:

• Riskiskenaario: Vaarantuneet käyttäjätunnukset mahdollistavat luvattoman pääsyn asiakastietoihin Microsoft 365:ssä ja taloushallinnon SaaS-palveluissa.
• Riskinomistaja: IT-turvallisuuden johtaja.
• Käsittely: Entra Conditional Access edellyttää vahvaa MFA:ta etuoikeutetuille rooleille, MFA:ta käyttäjille, kirjautumisriskin perusteella tehtävää estoa, vaatimustenmukaisia laitteita arkaluonteisille sovelluksille ja istuntorajoituksia hallitsemattomille päätelaitteille.
• ISO/IEC 27002:2022 -kartoitus: 5.15, 5.16, 5.17, 5.18, 8.1, 8.2, 8.3, 8.5, 8.15 ja 8.16.
• Sääntelykartoitus: NIS2 Articles 20, 21 ja 23, DORA Articles 5, 6, 9, 10, 17 ja 18, GDPR Articles 24, 25, 32 ja 33.
• Näyttö: politiikan hyväksyntä, Conditional Access -vienti, muutostiketti, testitulokset, kirjautumislokit, laitteiden vaatimustenmukaisuusraportit, poikkeusrekisteri, SOC-tiketit ja johdon katselmoinnin pöytäkirjat.

Zenith Blueprint selittää myös Controls in Action -vaiheen Step 19:ssä, miksi päätelaitteen tila kuuluu pääsypäätökseen:

Pääsyn tietoihin päätelaitteiden kautta on oltava kontekstitietoista. Täyttääkö laite esimerkiksi vähimmäistietoturvavaatimukset ennen yrityksen resurssien käyttöä? Onko se äskettäin läpäissyt haittaohjelmatarkistuksen? Muodostetaanko yhteys epätavallisesta sijainnista tai verkosta? Zero Trust -periaatteisiin integroituna päätelaitteen tila voi syöttää tietoa Conditional Access -päätöksiin ja estää pääsyn, kunnes laite osoittaa olevansa turvallinen.

Tämä on hallinnoinnin ydinperiaate. Conditional Accessin tulee olla riskiperusteinen, kontekstitietoinen ja näyttöä tuottava.

Kartoita Conditional Access -päätökset kontrollitavoitteisiin

Kypsä ohjelma määrittää vakiomuotoiset pääsypäätökset ja kartoittaa jokaisen niistä hallinnointitarkoitukseen ja näyttöön. Tämä ehkäisee käytäntöjen hallitsematonta kasvua ja helpottaa auditointikeskusteluja.

Yrityksen pilvipalvelujen käyttöpolitiikka Pilvipalvelujen käyttöpolitiikka tukee keskitettyä identiteetti-integraatiota:

Single Sign-On (SSO) -integraatio organisaation IdP:n kanssa on pakollinen todennuksen yhdenmukaisuuden varmistamiseksi.

Osasta ”Politiikan toteutusvaatimukset”, politiikan kohta 6.2.4.

Yrityksen käyttäjätilien ja käyttöoikeuksien hallintapolitiikka Käyttäjätilien ja käyttöoikeuksien hallintapolitiikka tekee seurannasta nimenomaisen vaatimuksen:

Single Sign-On (SSO) -järjestelmien käyttö on integroitava keskitettyihin identiteetin tarjoajiin (esim. Active Directory (AD), Azure AD), ja niitä on valvottava poikkeavan kirjautumistoiminnan havaitsemiseksi.

Osasta ”Politiikan toteutusvaatimukset”, politiikan kohta 6.3.4.

Yhdessä nämä kohdat edellyttävät enemmän kuin SSO:ta. Ne edellyttävät keskitettyä identiteettiarkkitehtuuria, yhdenmukaista todennusta, poikkeavan kirjautumistoiminnan seurantaa ja näyttöä siitä, että pääsypäätöksiä katselmoidaan.

Laitteiden vaatimustenmukaisuus: kontrolli, jonka auditoijat voivat testata

Laitteiden vaatimustenmukaisuus on yksi helpoimmin liioiteltavista osa-alueista. Hallintanäkymä voi näyttää, että 92 prosenttia laitteista on vaatimustenmukaisia, mutta auditoija kysyy, sovelletaanko sääntöä merkityksellisiin sovelluksiin, sallitaanko henkilökohtaiset laitteet, estetäänkö tuettomat alustat ja hyväksytäänkö poikkeukset asianmukaisesti.

Yrityksen etätyöpolitiikka Etätyöpolitiikka määrittää hyväksynnän perustason:

BYOD-laitteiden on oltava nimenomaisesti hyväksyttyjä ja:

Osasta ”Hallinnointivaatimukset”, politiikan kohta 5.2.2.

Tällä lyhyellä lauseella on merkitystä. BYOD ei ole pelkkä tekninen tila. Se on hallinnointipäätös. Conditional Accessissa sen tulee näkyä laitteen omistajuussääntöinä, vähimmäisvaatimustenmukaisuuden perustasoina, salausvaatimuksina, korjauspäivitysten ja haittaohjelmasuojauksen tarkistuksina, mobiilisovellusten suojauksena, urakoitsijoiden käsittelynä ja poikkeusten katselmointina.

Clarysecin Zenith Controls: vaatimustenmukaisuuden poikkikartoitusopas Zenith Controls kartoittaa ISO/IEC 27002:2022 -kontrollin 5.15 pääsynhallinta ennaltaehkäiseväksi kontrolliksi, joka suojaa luottamuksellisuutta, eheyttä ja saatavuutta identiteetin- ja pääsynhallinnan operatiivisessa kyvykkyydessä. Se yhdistää pääsynhallinnan myös käyttäjien päätelaitteisiin, koska hallitsemattomat kannettavat tietokoneet, mobiililaitteet ja työasemat voivat heikentää keskitettyä pääsynhallinnan toteutusta.

Käytännöllisen neljännesvuosittaisen Conditional Access -laitenäyttöpaketin tulisi sisältää:

• Hyväksytty laitteiden vaatimustenmukaisuuden perustaso.
• Conditional Access -käytännöt, jotka edellyttävät vaatimustenmukaisia laitteita.
• Sovellukset, joita kyseiset käytännöt suojaavat.
• Vienti poissuljetuista käyttäjistä, ryhmistä, sovelluksista ja alustoista.
• Ei-vaatimustenmukaisten laitteiden trendiraportti.
• Esimerkit estettyjen kirjautumisten lokeista ei-vaatimustenmukaisilta laitteilta.
• Poikkeusrekisteri, jossa on omistaja, syy, päättymispäivä ja riskin hyväksyntä.
• Johdon katselmoinnin tallenne.

Tämä näyttöpaketti tukee ISO/IEC 27001:2022 -standardin operatiivista ohjausta, NIS2:n kyberhygieniaa, DORA:n suojausta ja ennaltaehkäisyä sekä GDPR:n osoitusvelvollisuutta.

Kirjautumisriski: havaitsemisesta on tultava päätöksenteon näyttöä

Riskiperusteinen Conditional Access on kohta, jossa identiteettihavainnointi muuttuu pääsynhallinnan hallinnoinniksi. Microsoft Entra voi arvioida signaaleja, kuten tuntemattomia kirjautumisominaisuuksia, anonyymejä IP-osoitteita, mahdotonta matkustusta ja vuotaneita tunnistetietoja. Auditoijat eivät kuitenkaan hyväksy vastausta ”riskikäytäntö käytössä” lopullisena näyttönä. He kysyvät, miksi kynnysarvot valittiin, kuka katselmoi riskialttiit tapahtumat ja milloin korkean riskin kirjautumisesta tulee poikkeama.

Pk-yrityksen lokitus- ja valvontapolitiikka-sme Lokitus- ja valvontapolitiikka-sme – pk-yritys määrittää vähimmäislokitusvaatimuksen:

Todennuslokit: onnistuneet ja epäonnistuneet kirjautumisyritykset, istunnon kesto, MFA:n käyttö

Osasta ”Hallinnointivaatimukset”, politiikan kohta 5.4.2.

Yrityksen lokitus- ja valvontapolitiikka Lokitus- ja valvontapolitiikka laajentaa odotettua tapahtumajoukkoa:

Kerättävät tapahtumatyypit (esim. kirjautumiset, pääsyn epäonnistumiset, konfiguraatiomuutokset, hallinnolliset komennot, haittaohjelmien havaitseminen)

Osasta ”Hallinnointivaatimukset”, politiikan kohta 5.1.1.

Conditional Accessin osalta hyödyllisen näytön tulisi sisältää onnistuneet kirjautumiset, epäonnistuneet kirjautumiset, Conditional Access -käytännön tulos, MFA-menetelmä, kirjautumisriski, käyttäjäriski, laitteen vaatimustenmukaisuuden tila, käytetty sovellus, sijainti, asiakassovellus, istuntokontrollin tulos, käytännön muutoshistoria ja hallinnolliset toimet.

Zenith Controls kartoittaa ISO/IEC 27002:2022 -kontrollin 8.16 seurantatoiminnot havaitsevaksi ja korjaavaksi kontrolliksi, joka liittyy Detect- ja Respond-käsitteisiin. Se yhdistää seurannan lokitukseen, tapahtumien arviointiin, uhkatiedusteluun, toimittajaseurantaan ja poikkeamien hallintaan. Lisäksi se kartoittaa seurantatoiminnot GDPR Articles 32 ja 33 -vaatimuksiin, NIS2:n poikkeamien seurantaan ja raportointiin, DORA:n ICT-poikkeamien seurantaan, NIST:n jatkuvaan seurantaan ja COBITin turvallisuusseurantaan.

Conditional Accessin estämä korkean riskin kirjautuminen ei siis ole pelkkä tietoturvavoitto. Se on näyttö siitä, että ennaltaehkäisevät, havaitsevat ja reagoivat prosessit on yhdistetty.

Istuntokontrollit: yhteys pääsyn ja tietosuojan välillä

Pääsyä edeltävät päätökset eivät riitä. Kun käyttäjä on todennettu, istuntokontrollit määrittävät, kuinka paljon altistusta jää jäljelle. Tämä on erityisen tärkeää hallitsemattomien laitteiden, urakoitsijoiden, etätyön, jaettujen päätelaitteiden, riskialttiiden sijaintien ja henkilötietoja käsittelevien sovellusten osalta.

Pk-yrityksen sovellusturvallisuusvaatimusten politiikka-sme Sovellusturvallisuusvaatimusten politiikka-sme – pk-yritys toteaa:

Istunnon hallinta: istuntotietojen on vanhennuttava 15 minuutin käyttämättömyyden jälkeen, ja niihin on sisällyttävä aikakatkaisuvaroitukset soveltuvin osin.

Osasta ”Politiikan toteutusvaatimukset”, politiikan kohta 6.1.1.3.

Microsoft Entra -hallinnoinnissa tämä voidaan kartoittaa kirjautumistiheyteen, pysyvien selainistuntojen rajoituksiin, Conditional Access App Controliin, sovelluksen pakottamiin rajoituksiin, latausten estoon, riskin muutoksen jälkeiseen uudelleentodennukseen ja arkaluonteisuuteen perustuviin istuntorajoituksiin.

Istuntokontrollit tukevat ISO/IEC 27002:2022 -kontrolleja 8.3 tiedonsaannin rajoittaminen ja 8.5 turvallinen todennus. Ne tukevat myös GDPR Article 32 -vaatimusta vähentämällä henkilötietojen luvatonta katselua, lataamista tai pääsyn pysyvyyttä. DORA:n näkökulmasta istuntorajoitukset auttavat rajoittamaan altistusta ICT-järjestelmissä ja tukevat havaitsemista ja reagointia. NIS2:n osalta ne ovat oikeasuhtaisia pääsynhallinnan ja kyberhygienian toimenpiteitä.

Näytön tulee selittää, miksi istuntokontrolli on olemassa. Esimerkiksi ”estä lataus hallitsemattomilta laitteilta HR- ja taloushallinnon sovelluksissa” tulee kartoittaa henkilötietojen tietovuotoon, päätelaitteen vaarantumiseen ja luottamuksellisuuden menettämiseen. Näyttöön tulee sisältyä konfiguraatio, soveltamisalaan kuuluvat sovellukset, testikirjautumiset hallituilta ja hallitsemattomilta laitteilta, rajoitukset osoittavat lokit sekä hyväksyntätallenteet.

Luo Conditional Access -kontrollirekisteri

Conditional Access -kontrollirekisteri on operatiivinen silta riskirekisterin, soveltuvuuslausunnon ja Microsoft Entra -konfiguraation välillä. Se ei korvaa näitä asiakirjoja. Se tekee niistä käyttökelpoisia.

Käytä viisivaiheista katselmointisykliä:

1. Vahvista soveltamisala: Tunnista pilvisovellukset, jotka käsittelevät sääntelyn alaisia, taloudellisia, operatiivisia tai henkilötietoja.
2. Kartoita käytännöt riskeihin: Yhdistä jokainen Conditional Access -käytäntö vähintään yhteen riskiskenaarioon ja yhteen riskinomistajaan.
3. Varmista poissulkemiset: Vie poissuljetut käyttäjät, roolit, sovellukset, ryhmät, sijainnit ja laitteet. Jokaisella poissulkemisella on oltava omistaja, syy, hyväksyntä ja päättymisaika.
4. Testaa soveltaminen: Käytä testitilejä MFA:n, laitteiden vaatimustenmukaisuuden, riskiperusteisen eston, legacy-todennuksen eston ja istuntorajoitusten varmistamiseen.
5. Paketoi näyttö: Säilytä viennit, kuvakaappaukset, lokit ja hyväksynnät metatietoineen.

Pk-yrityksen auditointi- ja vaatimustenmukaisuuden seurantapolitiikka-sme Auditointi- ja vaatimustenmukaisuuden seurantapolitiikka-sme – pk-yritys on kriittinen näytön eheyden kannalta:

Metatiedot (esim. kuka keräsi ne, milloin ja mistä järjestelmästä) on dokumentoitava.

Osasta ”Politiikan toteutusvaatimukset”, politiikan kohta 6.2.3.

Kuvakaappaukset ilman lähdettä, päivämäärää, kerääjää ja järjestelmäkontekstia ovat heikkoa näyttöä. Conditional Access -viennit, kirjautumislokit ja katselmointiraportit tulee käsitellä kontrolloituina auditointitallenteina.

Conditional Access -näytön poikkikartoitus eri vaatimuksiin

Conditional Accessin arvo on siinä, että yksi kontrollikokonaisuus voi tukea useita auditointinäkökulmia, kun sitä hallinnoidaan asianmukaisesti.

Zenith Controls kartoittaa myös 5.15 pääsynhallinta -kontrollin GDPR Article 32 -vaatimukseen, NIS2 Article 21(2)(i) -vaatimukseen, DORA:n pääsynhallinnan hallinnointikäsitteisiin, NIST SP 800-53 -pääsynhallintaperheisiin ja COBIT 2019 DSS06.04 -kohtaan. Se kartoittaa 8.5 turvallinen todennus -kontrollin GDPR Articles 5, 24, 25 ja 32 -vaatimuksiin, NIS2:n kyberturvallisuuden riskienhallintaan, DORA:n ICT-riskien hallintaan, NIST:n tunnistamiseen ja todennukseen sekä COBITin identiteettiin ja loogiseen pääsyyn.

Opetus on yksinkertainen. Viitekehykset käyttävät eri kieltä, mutta ne odottavat samaa varmentamismallia: oikeat käyttäjät, hyväksyttävistä konteksteista, vahvaa todennusta käyttäen, hallinnoitujen istuntojen kautta, ja lokit osoittavat, mitä tapahtui.

Miten auditoijat tarkastelevat Conditional Accessia

ISO/IEC 27001:2022 -auditoija aloittaa ISMS:stä. Hän kysyy, kuuluuko Conditional Access soveltamisalaan, mitä riskejä se käsittelee, miten se näkyy SoA:ssa, miten politiikat hyväksytään, miten muutoksia hallitaan ja osoittaako näyttö kontrollien toiminnallisen tehokkuuden. Odotettavissa on otantaa etuoikeutetuista käyttäjistä, arkaluonteisista sovelluksista, poissulkemisista ja viimeaikaisista käytäntömuutoksista.

DORA- tai NIS2-auditoija keskittyy operatiiviseen häiriönsietokykyyn, johdon osoitusvelvollisuuteen ja riskiin. Hän voi kysyä, miten pääsynhallintakontrollit suojaavat kriittisiä tai tärkeitä toimintoja, miten johto valvoo identiteettiriskiä, miten korkean riskin kirjautumiset luokitellaan ja priorisoidaan sekä syöttävätkö pääsyn epäonnistumiset poikkeamien luokittelu- tai raportointipäätöksiin.

GDPR-painotteinen auditoija keskittyy henkilötietoihin. Hän voi kysyä, miten HR-, taloushallinnon tai asiakastietoja suojataan hallitsemattomilta laitteilta, miten istuntokontrollit vähentävät luvatonta katselua, miten pääsy rajoitetaan valtuutettuihin käyttäjiin ja miten lokit tukevat tietoturvaloukkauksen arviointia.

COBIT 2019 -arvioija etsii hallinnointikäytäntöjä, omistajuutta, mittareita, toistettavuutta, suorituskyvyn seurantaa ja parantamista. NIST-suuntautunut arvioija vertaa identiteetin, todennuksen, valtuutuksen, seurannan ja reagoinnin tuloksia tekniseen näyttöön.

Yrityksen pääsynhallintapolitiikka Pääsynhallintapolitiikka määrittää etuoikeutetun pääsyn lähtökohdan:

Hallinnollista pääsyä on valvottava tiukasti seuraavilla tavoilla:

Osasta ”Hallinnointivaatimukset”, politiikan kohta 5.4.1.

Microsoft Entra -näyttösi on täydennettävä tämä lause operatiivisesti. Mitkä roolit ovat etuoikeutettuja? Mitkä edellyttävät tietojenkalastelunkestävää tai vahvaa MFA:ta? Mitkä ovat käytettävissä privileged identity management -menettelyn kautta? Mitkä tilit ovat break-glass-tilejä? Mitkä on suljettu käytäntöjen ulkopuolelle? Kuka katselmoi ne? Minne hälytykset lähetetään?

Johdon mittarit Conditional Access -hallinnoinnille

Koska NIS2 ja DORA korostavat johdon osoitusvelvollisuutta, Conditional Access -raportoinnin tulee olla johdolle ymmärrettävää. Älä raportoi vain käytäntöjen nimiä. Raportoi riskitaso ja kontrollien suorituskyky.

Hyödyllisiä mittareita ovat:

• Vahvalla MFA:lla suojattujen etuoikeutettujen tilien prosenttiosuus.
• Conditional Access -poikkeusten määrä riskiluokittain.
• Estettyjen, haastettujen tai sallittujen korkean riskin kirjautumisten määrä.
• Niiden arkaluonteisten sovelluskäyttöjen prosenttiosuus, jotka edellyttävät vaatimustenmukaisia laitteita.
• Hallitsemattomien laitteiden istuntojen määrä säänneltyihin sovelluksiin.
• Korkean riskin kirjautumistapahtumien triageen kuluva aika.
• Conditional Access -käytäntömuutosten määrä neljänneksen aikana.
• Vanhentuneiden, uusittujen ja myöhässä olevien poikkeusten määrä.
• Todennuksen, istuntojen ja käytäntömuutosten lokituksen kattavuus.
• Neljännesvuosittaisessa Conditional Access -validoinnissa epäonnistuneiden testitapausten määrä.

Nämä mittarit muuttavat identiteettikonfiguraation valvonnan näytöksi. Ne auttavat myös johtoa osoittamaan hyväksynnän, katselmoinnin, resursoinnin ja jatkuvan parantamisen.

Yleiset havainnot, jotka tulee poistaa ennen auditointia

Conditional Access -havainnot johtuvat yleensä hallinnoinnin heikkouksista, eivät teknologian epäonnistumisesta. Yleisimmät ongelmat ovat:

• Break-glass-tilit on poissuljettu, mutta niitä ei valvota.
• Käytäntöjen nimeäminen on epäyhtenäistä, eikä niillä ole omistajia.
• Arkaluonteiset sovellukset puuttuvat laitteiden vaatimustenmukaisuussäännöistä.
• Vieraskäyttäjät ja ulkoiset yhteistyökumppanit ohittavat vakiokontrollit.
• Palvelutilit ja työkuormaidentiteetit eivät ole erillisen hallinnoinnin piirissä.
• Kirjautumisriskin havainnoille ei tehdä triagea tai niitä ei linkitetä poikkeamiin.
• Istuntokontrolleja ei koskaan testata hallitsemattomilta laitteilta.
• Käytäntömuutokset tehdään suoraan tuotantoympäristöön ilman muutostallenteita.
• Poissulkemiset ovat pysyviä, dokumentoimattomia tai suullisesti hyväksyttyjä.
• Lokit säilytetään, mutta niitä ei katselmoida.
• Näytöstä puuttuvat metatiedot, lähdekonteksti tai hallussapitoketju.

Vuoteen 2026 valmis tavoitetila sisältää johdon hyväksymän pääsynhallinnan hallinnoinnin, riskiperusteisen Conditional Access -suunnittelun, nimenomaisen ISO/IEC 27001:2022- ja ISO/IEC 27002:2022 -kartoituksen, dokumentoidun NIS2-, DORA- ja GDPR-tuen, vahvan MFA:n roolin ja riskin perusteella, laitteiden vaatimustenmukaisuuden arkaluonteisessa käytössä, istuntorajoitukset hallitsemattomissa konteksteissa, valvotut todennus- ja käytäntömuutokset, poikkeusten elinkaaren, neljännesvuosittaisen testauksen ja johdon raportoinnin.

Muuta Microsoft Entra auditointivalmiiksi näytöksi

Conditional Access -käytäntösi tekevät tietoturvapäätöksiä jo joka minuutti. Kysymys on, ovatko nämä päätökset hallinnoituja, riskiperusteisia, seurattuja ja kartoitettu niihin velvoitteisiin, joista auditoijat ja viranomaiset välittävät.

Aloita Zenith Blueprintistä Zenith Blueprint, erityisesti Step 13:sta, jotta yhdistät Conditional Access -käytännöt riskeihin, käsittelyihin, soveltuvuuslausuntoon ja sääntelyhuomautuksiin. Käytä Zenith Controlsia Zenith Controls kartoittaaksesi pääsynhallinnan, turvallisen todennuksen, päätelaitteen tilan, lokituksen ja seurannan ISO/IEC 27001:2022-, ISO/IEC 27002:2022-, NIS2-, DORA-, GDPR-, NIST- ja COBIT 2019 -viitekehysten välillä.

Yhdenmukaista sen jälkeen sisäiset vaatimuksesi Clarysecin politiikkoihin, mukaan lukien Pilvipalvelujen käyttöpolitiikka-sme, Verkkoturvallisuuspolitiikka-sme, Lokitus- ja valvontapolitiikka-sme, Auditointi- ja vaatimustenmukaisuuden seurantapolitiikka-sme, Sovellusturvallisuusvaatimusten politiikka-sme, Pilvipalvelujen käyttöpolitiikka, Käyttäjätilien ja käyttöoikeuksien hallintapolitiikka, Etätyöpolitiikka, Pääsynhallintapolitiikka ja Lokitus- ja valvontapolitiikka.

Clarysec auttaa muuttamaan Microsoft Entra Conditional Accessin asetuskokoelmasta sovellettavaksi, mitattavaksi ja auditointivalmiiksi kontrollijärjestelmäksi. Lataa asiaankuuluvat Clarysec-työkalupaketit, pyydä politiikkakartoituksen katselmointia tai varaa arviointi nähdäksesi, kestääkö Conditional Access -näyttösi ISO 27001-, NIS2-, DORA- ja GDPR-tarkastelun.