Pääsynhallintaa ryhmillä ja sen automatisointi

Centeron guru, Juha Haapsaari, jokeltaa siitä mitä pääsynhallinta AD-ryhmillä tarkoittaa ja miten tätä soppaa voi tehostaa sekä automatisoida.

 

Kaiken takana on AD

Active Directory -ryhmiä on käytetty jo pitkään monessa paikassa kontrolloimaan pääsyä resursseihin. Itse asiassa samaan tapaan hallittiin pääsyä resursseihin jo NT4-aikakaudella. Nyt vain on käytettävissä enemmän ryhmätyyppejä. Tässä blogissa on tarkoitus selittää, miten ryhmiä tulisi käyttää pääsynhallintaan ja kertoa miten asioita voidaan helpottaa Centero Pandeiro -tuotteella ja siten vähentää ylläpidon työtä.

Yksiselitteistä vastausta ei ryhmien käyttöön ole, mutta on toki malli joka sopii kaikkiin tilanteisiin. Tämä tosin tarkoittaa pienessä ympäristössä alkuvaiheessa ylimääräiseltä tuntuvaa työtä. Jos AD koostuu vain yhdestä domainista, niin voidaan käyttää kevyempiäkin malleja, mutta itse suosittelen ottamaan heti käyttöön mallin, jossa huomioidaan tulevaisuus ja joka mahdollistaa myös laajentumisen.

 

Ryhmiä on erilaisia…

Ryhmätyyppejä tai oikeastaan ryhmän käyttöalueita on AD:ssa kolme: Domain Local, Domain Global ja Domain Universal. Ryhmän käyttöalue on siinä mielessä hyvä termi, että se kertoo heti itsellekin missä ryhmää voi käyttää resurssien suojaamiseen. Esimerkiksi Domain Local -käyttöalueen ryhmää voi käyttää vain sen domainin resurssien suojaamiseen, mihin ryhmä luodaan. Taasen Global-käyttöalueen ryhmää voi käyttää resurssien suojaamiseen missä tahansa domainissa, mihin vain luottosuhteet löytyy. No miksi sitten on Universal-ryhmä olemassa ja miksi pitää käyttää muutakin kuin Global-käyttöalueen ryhmää?

Ryhmän käyttöalue (englanniksi group scope) siis kertoo, missä ryhmää voidaan käyttää suojaamaan resursseja. Toinen tärkeä tieto ryhmän käytettävyyden kannalta on se, ketä ryhmään voidaan lisätä jäseneksi. Tässä onkin sitten se juju, miksi Universal-ryhmän käyttöalue on olemassa ja miksi ei välttämättä voi käyttää vain Global-ryhmiä.

Eli vaikka Global-käyttöalueen ryhmää voidaan käyttää missä tahansa domainissa resurssien suojaamiseen, niin ryhmään voi lisätä jäseniä vain samasta domainista, missä ryhmä sijaitsee. Domain Local -ryhmään taas voi lisätä jäseniä mistä tahansa domainista, mihin luottosuhteet löytyy mutta itse ryhmää pystytään käyttämään resurssien suojaamiseen vain siinä domainissa missä ryhmä sijaitsee.

 

Mitä uutta AD toi?

Niin se Universal-ryhmä… Active Directoryn mukana esitelty Universal -ryhmä on yhdistelmä Domain Local- ja Global-ryhmistä. Nimikin pitkälti kertoo, että sitä voidaan käyttää missä vain ja jäseniä voi olla mistä vain. No herää tietty kysymys, miksi sitten ei kaikkia ryhmiä kannata tehdä Universal-tyyppisenä? Jos AD-metsässä on vain yksi domain, ei Universal-ryhmistä ole mitään hyötyä eli niitä ei kannata käyttää. Jos metsässä taas on useita domaineja, Universal ryhmille saattaa olla käyttöä, mutta kaikkia ryhmiä ei kannata tehdä Universal-tyyppisinä, koska sen seurauksena replikointia kuormitetaan reilusti enemmän, AD-tietokannan koko kasvaa huomattavasti ja autentikointi muuttuu paljon raskaammaksi. Tässä asiassa isoa osaa näyttele Global Catalog –palvelu, miten se rakentuu ja miten sitä käytetään. No nyt ei kuitenkaan lähdetä tuota käymään läpi, ehkä joskus toisessa blogissa =).

Yhteenvetona voi sanoa, että mikäli erilaisia ryhmiä käytetään ilman selkeää suunnitelmaa, saadaan aikaiseksi aikamoinen sekasotku. Siksi on erittäin järkevää tehdä ryhmien käyttöön suunnitelma ja hyödyntää työkaluja ryhmäjäsenyyksien hallintaan.

 

Kaikkiin ympäristöihin sopiva malli

Mainitsinkin jo, että suosittelen heti käyttämään mallia joka sallii laajentumisen, vaikka se pienessä ympäristössä tuntuu aikaa vievältä. No mikä se malli sitten on?

Se on UGDLR-malli! Eikä tuo ole intiaanikieltä, vaikka siltä kuulostaakin =).

ryhmamalli

Tässä mallissa U tarkoittaa käyttäjiä (tai joissain tilanteissa koneobjekteja). G tarkoittaa Global-ryhmiä ja DL Domain Local -ryhmiä. R edustaa tuossa mitä tahansa resurssia, jota voidaan suojata AD-ryhmillä. Resurssi voi siis olla tiedostopalvelimen kansio, levyjako, tulostin, Active Directory OU tms..

 

Käyttäjien ryhmittely

Nyt tiedetään kyseisestä mallista, mitä nuo kirjainyhdistelmät tarkoittavat, joten sitten itse mallin kimppuun. Käyttäjät (U) tulisi ryhmitellä loogisesti Global-ryhmillä. Koska AD tukee sisäkkäisiä ryhmiä, globaaleja ryhmiä voi tuossa ketjussa olla useita. Puretaan tätä ajatusta esimerkin avulla.

Myyntihenkilö Jyväskylässä voisi kuulua Globaaliin ryhmään SEC DG JKL Sales Users. Tähän ryhmään siis kuuluisi kaikki Jyväskylän myyjät. Jos myyjiä on muuallakin kuin Jyväskylässä, niin kaikkien eri lokaatioiden myyjät halutaan kuuluvan yleiseen SEC DG Sales Users ryhmään.

Tässä kannattaa hyödyntää sisäkkäisiä ryhmiä, eli ei lisätä suoraan käyttäjiä SEC DG Sales Users

-ryhmään, vaan lisätään tähän ryhmään jäseneksi kaikkien lokaatioiden Sales Users -ryhmät. Nyt meillä on käyttäjät ryhmitelty loogisesti eri ryhmiin. Valitettavasti se sopivimman loogisen ryhmittelyn miettiminen jää teidän harteille. Yleisin ryhmittelytapa kuitenkin on fyysiseen sijaintiin ja toimenkuvaan liittyvä ryhmittely.

 

Resurssien suojaaminen

Seuraavaksi päästään sitten resurssien suojaamiseen. Mallissa siis R tarkoitti resursseja ja DL noita Domain Local -ryhmiä. Nyrkkisääntönä on, että resurssit suojataan aina Domain Local -ryhmillä. Miksi? No siitä syystä että resurssit ovat pääsääntöisesti aina tietyssä domainissa – poikkeuksena esim. replikoidut tiedostokansiot, jotka sijaitsevat usean eri domainin palvelimilla. Tässä tapauksessa DL korvataankin U:lla eli universaalilla ryhmällä.

Kun käytetään Domain Local- tai Universal-ryhmiä resurssin suojaamiseen, pystytään aina ko. ryhmään lisäämään jäseniä mistä tahansa luotetusta domainista. Tällöin ei pääse koskaan käymään niin, että ei voidakaan antaa oikeuksia – vaikkapa kansioon – lisäämällä käyttäjä ryhmään, kun resurssi on suojattu Global-ryhmällä ja käyttäjä on eri domainissa. Tällöin jouduttaisiin lisäämään uusi ryhmä, tai pahimmassa tapauksessa käyttäjä suoraan kansion oikeuksiin. Äkkiä käy niin, että resurssien oikeudet eli ACL (Access Control List) ryvettyy ja menee hankalaksi hallita.

Jos käyttäjät on nyt ryhmitelty Global-ryhmillä ja reusurssit suojattu Domain Local (tai Universal) -ryhmillä, niin sitten vain yhdistetään nämä, eli resursseja suojaaviin ryhmiin lisätään jäseniksi ne Global-ryhmät, joiden jäsenille halutaan antaa pääsy resurssiin.

Oikeudet mitä resurssiin tarvitaan, ovat usein erilaisia eri käyttäjien välillä. Tämän johdosta samaa resurssia suojaamaan tehdään useita eri Domain Local (tai Universal) -ryhmiä. Esim. Jyväskylässä sijaitsevan tiedostopalvelimen Sales jakoon luodaan SEC DL JKL Sales Data Modify ja SEC DL JKL Sales Data Read -ryhmät. Näistä ryhmistä toiselle annetaan resurssiin muokkausoikeudet ja toiselle vain lukuoikeudet. Esimerkissämme voisi olla niin, että ryhmä joka pitää sisällään Jyväskylän myyjät (SEC DG JKL Sales Users) lisätään jäseneksi muokkausoikeudet antavaan ryhmään ja sitten kaikkien lokaatioiden myyjien ryhmä (SEC DG Sales Users) lisätään sitten lukuoikeudet antavaan ryhmään.

Helppoa, eikö totta? No on se, mutta haasteeksi tulee usein laiskuus. Jaksetaanko uutta resurssia luodessa tehdä nuo resurssin suojaukseen tarkoitetut ryhmät, vai mennäänkö nopeampaa kautta ja annetaan oikeudet suoraan Global-ryhmille, jotka ovat yleensä jo valmiina. Tässä ei kannata päästää itseään helpolla. Pienellä vaivalla saa mallin, joka taipuu kaikkeen ja ennen kaikkea resurssien oikeuksien määrittely tapahtuu tällöin pelkästään AD-ryhmiä muokkaamalla!

 

Ryhmien jäsenten hallinta

Tämä osuus yleensä toteutetaan manuaalisesti jonkun IT-henkilön toimesta. Kun joku pyytää, että käyttäjälle pitäisi saada oikeudet johonkin resurssiin, katsotaan mitä ryhmiä resurssin suojaamiseen on käytetty, ja sitten lisätään käyttäjä haluttuun ryhmään. Toimivaa, mutta isommassa organisaatiossa IT-henkilöillä ei välttämättä ole käsitystä mitä dataa resurssissa on, ja täten on hankala tehdä päätöstä, saako käyttäjä päästä dataan kiinni pyynnön mukaisesti.

Tähän ongelmaan Centero Pandeiro tuo apuja. Sen avulla voidaan käyttäjän, service deskin tai IT-henkilön toimesta pyytää ryhmäjäsenyyttä. Jotta oikea ryhmä löytyy helposti voi Centero Pandeiro -tuotteella nähdä tiedostopalvelinten hakemistojen oikeudet, ja valita ryhmän joka antaa oikeat oikeudet. Mikäli resurssit on suojattu oikein, niin sieltä usein löytyy modify-, read-, list- jne. ryhmiä kutakin yksi kappale, jolloin valinta on helppoa =).

Kun Centero Pandeiron avulla pyydetään ryhmäjäsenyyttä johonkin ryhmään, lähetetään aina ryhmän omistajalle viesti ja hyväksymispyyntö ennen pyynnön toteuttamista. Ryhmän omistaja on tallennettu AD-ryhmän tietoihin, eli omistajaa voidaan hallita millä tahansa tuotteella. Kun ryhmillä on omistajat, niin heillä on tieto siitä mihin dataan ryhmän jäsenet pääsevät ja osaavat täten tehdä paremmin päätöksen siitä, hyväksytäänkö pyyntö vai ei. Jos ei muista mihin kaikkialle ryhmälle on annettu oikeuksia, voidaan ne hyväksymisvaiheessa vielä listata hyväksyjälle.

Kun ryhmäpyyntö, joka voi olla myös jäsenen poistaminen ryhmästä, omistajan ja kuvauksen muutos tai koko ryhmän poisto, hyväksytään omistajan toimesta, voidaan Pandeiro määrittää automaattisesti tekemään muutos Active Directoryyn. Tällöin parhaassa tapauksessa ei IT-henkilöä tarvita laisinkaan koko muutosprosessissa.

 

Automaattinen ryhmien jäsenten hallinta

Jos Centero Pandeiron ryhmäpyynnöt, ja se että sen avulla voidaan IT henkilöiden aikaa vapauttaa muihin hommiin, kuulosti hyvälle, automaattinen jäsenten hallinta kuulostaa varmasti vielä paremmalta. Ja se ei pelkästään kuulosta vaan se myös on!

Pandeirossa automaattinen ryhmien jäsenten hallinta tapahtuu dynaamisten ryhmien avulla. Pandeirolla voidaan mikä tahansa AD-ryhmä muuttaa dynaamiseksi, jolloin ryhmän jäseniä hallitaankin manuaalityön sijaan Pandeiron automatiikan avulla. Ryhmän jäseniä voi edelleen muokata muillakin työkaluilla, mutta valitun syklin muokaisesti ryhmien jäsenet käydään läpi ja palautetaan dynaamisen ryhmän määrityksen mukaiseksi.

Ketä jäseniä dynaamisessa ryhmässä tulee olla, määritetään Pandeirossa LDAP-filterin avulla. Tuo filtteri on standardi tapa tehdä LDAP-hakemistoihin hakuja, jotka palauttavat halutut objektit hakemistosta. Filterillä voidaan käytännössä hakea miltei mitä vain tietoa AD:sta ja näin voidaan ryhmien jäsenet määrittää AD-tiedon perusteella.

 

Missä tätä sitten voisi hyödyntää?

Otetaan esimerkiksi vaikka osastoryhmät. Jos kaikilla käyttäjillä on AD-käyttäjäobjektissa määritettynä osastokentässä osasto, voidaan osastoryhmät määritellä dynaamisiksi ja hakea niihin henkilöt käyttäjätunnusten osastotiedon avulla. Tällöin esim. henkilön vaihtaessa toimenkuvaa ja osastoa, vaihtuu automaattisesti myös hänen ryhmäjäsenyytensä, kun osastotieto päivitetään AD-tunnukselle.

Mahdollisuudet ovat tässä miltei rajattomat, mutta tässä muutamia ajatuksia ja esimerkkejä, mitä dynaamisilla ryhmillä voidaan saavuttaa:

Ei aktiiviset työasemat:
Nämä voidaan vaikka sulkea pois sovellusjakeluista jotta ei turhaan yritetä tehdä toimenpiteitä näille koneille

Käyttäjätunnukset joissa salasana on vanhentunut:
Voidaan lähettää sähköpostia ja kysyä tarvitaanko tunnuksia enää

Suunnittelutyöasemat:
Voidaan poimia tietyn roolin työasemia ryhmiin ja kohdistaa vaikka sovellusjakeluita erityyppisille koneille.

 

Mitä jäi käteen?

Tuntuu monimutkaiselta, mutta ei se sitä ole. Tehkää ryhmien käyttösuunnitelma, ohjeistakaa se kaikille IT-henkilöille ja ottakaa käyttöön jäsenten hallintaan helpottavia työkaluja.

Centero Pandeiron avulla ryhmien jäsenten hallinta helpottuu oleellisesti ja saat paljon muutakin samalla! Miltä esim. kuulostaisi halutessasi listata kaikki tunnukset, joissa salasana ei vanhene. Tai katsoa mihin käyttäjillä on oikeasti oikeuksia tiedostopalvelimilla.

Joten ota yhteyttä ja tilaa heti Centero Pandeiro koekäyttöön!

Laske säästösi

Automatisoi sovelluspäivitykset ja lopeta pikkusoftien kanssa painiminen. Centero Software Manager säästää aikaa, rahaa ja hermojasi.

« Edellinen artikkeli: PKI for Dummies :)
» Seuraava artikkeli: MSI-paketointityökalujen vertailu