Tiimin salasananhallinta on helppoa, kun tiimissä on kolme ihmistä. Viidellätoista hengellä se alkaa rakoilla.

Pienellä yrityksellä voi olla kourallinen työkaluja, muutama jaettu tili ja yleensä yksi epävirallinen paikka, jossa salasanat asuvat: laskentataulukko, kiinnitetty viesti chatissa tai jaettu asiakirja.

Kun yritykseen tulee lisää ihmisiä, epävirallinen jakaminen vaikeuttaa hyödyllisen ja riskialttiin käyttöoikeuden erottamista toisistaan. Arjen työkalujen salasanat päätyvät sekoittumaan talous-, ylläpito-, asiakas- ja infrastruktuurijärjestelmien kirjautumistietojen kanssa. Luettelo voi yhä näyttää ulospäin järjestellyltä, mutta se ei enää kerro, kuka oikeasti tarvitsee pääsyn mihinkin.

Yrityksen kasvaessa jaetut kirjautumistiedot tarvitsevat rakennetta ja hallintaa: kuka voi käyttää kutakin salasanaa, mikä osasto omistaa kirjautumistiedot ja miten käyttöoikeudet muuttuvat, kun ihmiset liittyvät, lähtevät ja vaihtavat tehtävää.

Tässä artikkelissa käydään läpi, miten salasanaholvit järjestetään tiimin tai osaston mukaan, miten ryhmäpohjaiset käyttöoikeudet tukevat vähimmän etuoikeuden periaatetta ja miten perehdytyksestä ja työsuhteen päättymisestä tehdään turvallisempi — ennen kuin kirjautumistietojen leviäminen muuttuu tietoturva- ja toimintaongelmaksi.

Miksi jaettu salasanojen käyttö ei skaalaudu

Epävirallinen jakaminen on yleensä ensimmäinen malli, johon kasvavat yritykset tukeutuvat. Se on tehty kätevyyttä varten: salasanat voivat olla laskentataulukossa, chatin ketjussa tai jonkun selaimessa, eikä kenenkään tarvitse pyytää käyttöoikeutta joka kerta, kun tarvitsee kirjautumisen.

Kätevyys jää nopeasti kaaoksen ja riskin varjoon. Kun yritykseen tulee lisää tiimejä, alihankkijoita, asiakkaita ja työkaluja, jaettu luettelo muuttuu liian laajaksi ihmisten todelliseen työhön nähden. Talousosasto tarvitsee esimerkiksi pankki-, palkka- ja laskutusasioiden kirjautumistiedot, mutta ei mainostilien tai kehittäjätyökalujen tunnuksia. Markkinointi tarvitsee pääsyn analytiikkaan, sisältöön ja somesaan, mutta ei lakiporteihin tai infrastruktuurin kirjautumistietoihin.

Halkeamat näkyvät arjen työssä, mutta työsuhteen päättyminen on kohta, jossa tämä malli muuttuu vaaralliseksi. Kun joku lähtee, yrityksellä ei ole luotettavaa tapaa selvittää, mitä kirjautumistietoja hänellä oli käytössään, mitä hän kopioi ja mitä hän yhä muistaa. Salasanan vaihtaminen tarkoittaa uuden salasanan jakamista jälleen samoja suojaamattomia kanavia pitkin ilman tietoa siitä, kuka sen sai. Moni yritys jättää vaihtamisen siksi väliin.

Rakenteellisia holveja ja ryhmäpohjaisia käyttöoikeuksia tarjoava yrityksen salasananhallinta korvaa epätarkkuuden hallinnalla: käyttöoikeuksia voi myöntää, tarkistaa ja mitätöidä harkiten.

Mitä suuremmaksi holvi kasvaa, sitä vähemmän se soveltuu käyttöoikeuksien hallintavälineeksi. Se voi yhä tallentaa salasanat turvallisesti, mutta se ei enää kuvaa sitä, miten yritys oikeasti toimii, kuka omistaa kunkin kirjautumistiedon tai kenen pitäisi voida käyttää sitä.

Tiimipohjaiset käyttöoikeudet tukevat vähimmän etuoikeuden periaatetta

Osastoittaisen kirjautumistietojen käytön taustalla oleva periaate on yksinkertainen: ihmisten tulisi käyttää vain niitä kirjautumistietoja, joita he tarvitsevat työssään.

Vähimmän etuoikeuden periaate on hyödyllinen, koska se tarjoaa kirjautumistietojen käytölle selkeän kokeen: tarvitseeko tämä henkilö kyseistä tietoa työtään varten, vai onko hänellä se vain siksi, että käyttöoikeus myönnettiin kerran eikä sitä ole sen jälkeen koskaan kyseenalaistettu? Tiimin salasananhallinnassa tuon kysymyksen pitäisi ohjata sitä, miten holvit luodaan, kuka niihin liittyy ja milloin käyttöoikeus poistetaan.

Tämä on erityisen tärkeää jaetuille kirjautumistiedoille. Jaettu kirjautuminen on jo valmiiksi vaikeammin hallittavissa kuin henkilökohtainen tili, koska sitä voi käyttää useampi kuin yksi henkilö.

Jos kyseinen tieto on lisäksi saatavilla ihmisille, jotka eivät tarvitse siihen käyttöoikeutta, yritys kantaa riskiä ilman hyötyä: jokainen ylimääräinen henkilö, joka voi nähdä tiedon, on yksi laite lisää, jolla se voi päätyä automaattitäytöksi, kopioksi tai tietojenkalastelun uhriksi. Yritys voi tietää, että salasana on tallennettu turvalliseen paikkaan, mutta ei sitä, onko kaikilla holvin käyttöoikeudella yhä pätevä syy käyttää sitä.

Ryhmät Proton Pass for Businessissa ratkaisevat tämän: ylläpitäjät voivat koota ihmiset ryhmiin, jotka vastaavat tiimejä, osastoja tai projekteja, ja liittää nämä ryhmät sitten tiettyihin holveihin ja kohteisiin, jolloin käyttöoikeudet seuraavat tehtävää eivätkä luetteloa yksittäisistä myönnöistä.

Holvien rakenteen pitää vastata riskiä. Matalan riskin toiminnalliset kirjautumiset voi jakaa helposti, kun taas ylläpitäjien kirjautumistiedot, taloustyökalut, HR-järjestelmät, asiakastietojen vientitiedostot ja varmuuskopioiden käyttö vaativat tiukempia kontrollia.

Miltä hyvä holvirakenne näyttää

Hyödyllisen holvirakenteen pitäisi auttaa ihmisiä löytämään tarvitsemansa antamatta heille kaikkea.

Käytännöllinen perusta useimmille kasvaville pk-yrityksille sisältää kuusi tiimeittäin järjestettyä salasanaholvia:

  • Talous: Kirjanpito, palkanlaskenta, pankkiasiat, laskutus, verokansiot, maksualustat.
  • Markkinointi: Sosiaalinen media, analytiikka, mainonta, sisällönhallinta, suunnittelutyökalut.
  • Myynti ja asiakassuhteet: CRM, tarjoustyökalut, asiakasportaalit, tukialustat.
  • Toiminnot: Toimittajaportaalit, projektinhallintatyökalut, logistiikka, hankinta.
  • IT ja tietoturva: Ylläpitäjien hallintapaneelit, varmuuskopiotilit, laitehallinta, DNS, hosting, infrastruktuuri.
  • Johto: Hallitusmateriaalit, sijoittajaportaalit, johdon tasoiset palvelut, arkaluontoiset toimittajatilit.

Kun holvirakenne ja ryhmäkohtaiset käyttöoikeudet toimivat yhdessä, ylläpitäjät voivat hallita käyttöoikeuksia mittakaavassa: talousryhmä liitetään talousholviin, IT-ryhmä infrastruktuuriholveihin ja projektiryhmä väliaikaiseen asiakastyöhön. Käyttöoikeudet skaalautuvat silloin organisaatiokaavion eivätkä ylläpitäjän muistin mukaan.

Kun perusrakenne on paikallaan, luodaan rajoitettuja holveja silloin, kun riski perustelee niitä. IT-tiimillä voi olla yleinen IT-holvi ja erillinen erikoisoikeuksia vaativa ylläpitäjäholvi, jotka molemmat on liitetty asianmukaisiin ryhmiin.

Tämä muuttuu olennaiseksi perehdytyksessä ja työsuhteen päättyessä. Ryhmään lisääminen antaa henkilölle kerralla kaikki tarvittavat holvit; poistaminen mitätöi kaiken kerralla.

Tavoitteena ei ole tehdä holveista monimutkaisia. Tavoitteena on välttää hyvin eri riskitasoisten kirjautumistietojen sekoittamista. Sosiaalisen median julkaisuajastimen ei pitäisi jakaa käyttöoikeutta palkkahallinnon kanssa.

Salasanaholvien rakenteet eri tiimikokoja varten

Erittäin pieni yritys ei tarvitse suuryritystason holviarkkitehtuuria. Liian paljon rakennetta liian aikaisin voi aiheuttaa sekaannusta ja hidastaa käyttöönottoa.

Jo yhden tai kahden hengen yrityksessä yrityksen ja henkilökohtaisten kirjautumistietojen erottaminen eri holveihin luo pohjan kasvulle.

Kolmen–kymmenen hengen tiimille muutama laaja holvi voi riittää: yrityksen toiminta, talous, markkinointi ja IT. Tärkeintä on välttää yhtä holvia kaikelle ja pitää arkaluontoisimmat kirjautumistiedot erillään.

Kymmenen–viidenkymmenen hengen tiimissä holvirakenteen on noudatettava sitä, miten yritys oikeasti on järjestetty. Tässä vaiheessa kirjautumistietojen käyttö muuttuu osaksi arjen toimintaa: tiimeihin tulee uusia ihmisiä, alihankkijoita tulee mukaan tiettyihin projekteihin, esihenkilöt vastaavat tiiminsä käyttämistä työkaluista, ja ylläpitäjät tarvitsevat tavan tarkistaa käyttöoikeudet avaamatta jokaista tietoa erikseen. Alihankkijat ja ulkoiset yhteistyökumppanit voidaan liittää projektikohtaisiin holveihin rajatulla käyttöoikeudella, jolloin he näkevät vain sen, mihin toimeksianto vaatii — ja menettävät käyttöoikeuden automaattisesti projektin päättyessä.

Yli 50 hengen tiimeissä — suuremmissa pk-yrityksissä ja keskikokoisissa tiimeissä — holvien on ehkä noudatettava sekä osastoja että tehtäviä. Osastotunniste ei aina riitä: joku voi työskennellä talousosastolla ilman pankkikäyttöoikeuden tarvetta tai tukea IT-toimintaa ilman erikoisoikeuksia vaativia ylläpitäjätunnuksia.

Rakenteen pitäisi sopia yritykseen, eikä toisin päin. Seuraavat osiot käsittelevät, miten rakenne viedään käytäntöön perehdytyksen, työsuhteen päättymisen ja jatkuvien käyttöoikeustarkistusten avulla.

Rakenteen ottaminen osaksi perehdytystä

Perehdytys paljastaa usein heikon salasananhallinnan. Uusi työntekijä tulee ja jonkun on muistettava, mitkä kirjautumistiedot hän tarvitsee, missä ne salasanat sijaitsevat, kuka saa jakaa ne ja mitkä käyttöoikeudet kannattaa odottaa koulutuksen tai hyväksynnän jälkeen.

Tiimipohjainen malli poistaa tämän muistamisvaran. Kun uusi talousalan työntekijä tulee, kenenkään kollegan ei tarvitse yksilöidä ja jakaa kutakin tietoa käsin. Hänet voidaan vain lisätä talousryhmään saamaan tarvittavat käyttöoikeudet. Kenenkään ei tarvitse välittää linkkejä, liittää salasanoja chattiin tai muistaa, mitä työkaluja taloustiimi yleensä käyttää.

Henkilö lisätään vain talousryhmään, ja hän perii automaattisesti sille määritetyt holvit ja kohteet — vain kyseiseen tehtävään sidotut kirjautumistiedot. Tämä nopeuttaa perehdytystä ja estää arkaluontoisia tilejä leviämästä tarvitsevan tiimin ulkopuolelle. Ihmiset voivat aloittaa työn ilman salasanojen perimistä, ja yritys välttää laajojen käyttöoikeuksien antamisen kätevyyden nimissä.

Myös tässä selkeä salasanakäytäntö tulee apuun. Protonin oppaassa salasanakäytännön luomisesta käydään läpi, miten yritykset voivat määritellä salasanojen luomisen, turvallisen jakamisen, käyttöoikeuksien hallinnan ja tunnistautumisen säännöt. Sääntöjen noudattaminen on helpompaa, kun kirjautumistiedot on jo järjestetty tiimeittäin.

Turvallisempi työsuhteen päättyminen

Yhdessä jaetussa yritysholvissa mitätöinti on kaiken tai ei mitään -ratkaisu: lähtevä työntekijä on saattanut koskea kymmeniin tai satoihin kirjautumistietoihin, jolloin edessä on laaja vaihto tai — pahimmillaan — entisten työntekijöiden jäävät käyttöoikeudet.

Tarkka työsuhteen päättäminen etenee näin:

  1. Poista henkilö tiimi- ja projektiryhmistä.
  2. Käy läpi kirjautumistiedot, joita hän omisti tai hallinnoi.
  3. Vaihda korkeamman riskin salasanat tarvittaessa.

Yritys voi keskittää vaihto- ja tarkistustyönsä niihin kirjautumistietoihin, jotka oikeasti kantavat riskiä, sen sijaan että kohtelisi jokaista salasanaa kuin hätätilannetta.

Juuri tässä ryhmien luominen kannattaa. Jos käyttöoikeuksia hallitaan vain jaettujen holvien kautta, ylläpitäjän on mitätöitävä henkilön käyttöoikeus jokaisesta holvista erikseen. Ryhmien avulla henkilön poistaminen ryhmästä mitätöi kerralla kaikki kyseiselle ryhmälle määritetyt holvit ja kohteet — yksi toiminto tarkastuksen sijaan.

Sama logiikka pätee, kun joku vaihtaa tehtävää. Henkilön, joka siirtyy myynnistä operaatioihin, ei pitäisi oletuksena säilyttää vanhoja CRM-ylläpitäjän kirjautumistietoja. Tehtävänvaihdosten pitäisi laukaista holvien käyttöoikeuksien tarkistus yhtä lailla kuin työsuhteiden päättyminen. Ryhmäperustaisilla käyttöoikeuksilla tämä tarkistus on nopea: siirrä henkilö ryhmästä toiseen, ja hänen käyttöoikeutensa päivittyvät automaattisesti — vanhat CRM-kirjautumistiedot poistuvat, uudet operaatioiden holvit myönnetään, kaikki yhdessä yksinkertaisessa vaiheessa.

Parempi näkyvyys ylläpitäjille

Hyvä tiimin salasanahallinta antaa ylläpitäjille selkeän kuvan käyttöoikeuksista. Heidän pitäisi pystyä vastaamaan peruskysymyksiin nopeasti.

Keskeiset käyttöoikeuskysymykset, joihin ylläpitäjien pitäisi pystyä vastaamaan

  • Ketkä voivat käyttää taloushallinnon kirjautumistietoja?
  • Mitkä holvit ovat ulkoisten työntekijöiden käytössä?
  • Millä käyttäjillä on pääsy ylläpitäjien salasanoihin?
  • Mitkä kirjautumistiedot ovat jaettuna eri osastojen kesken?
  • Mitä muuttui työntekijän lähdettyä?
  • Mitkä holvit sisältävät korkean riskin tai laajoilla oikeuksilla varustettuja tilejä?

NCSC:n henkilöllisyyden ja käyttöoikeuksien hallintaa koskevat ohjeet(uusi ikkuna) korostavat, että on hallittava sitä, kuka ja mikä voi käyttää järjestelmiä ja tietoja. Ne myös tuovat esiin, että käyttöoikeudet pitää rajoittaa tarpeelliseen ja tarkistaa säännöllisesti.

Tämä on vaikeaa, kun käyttöoikeudet on järjestetty mukavuuden eikä vastuun mukaan. Selkeä holvirakenne antaa ylläpitäjille vahvemman lähtökohdan turvallisuusauditointeihin, käyttöoikeuksien tarkistuksiin ja asiakkaiden kyselylomakkeisiin.

IT-tiimeille Proton Pass for Business tukee keskitettyä hallintaa, käytäntöjä, turvallista jakamista, raportointia ja lokeja, SCIM-provisiointia sekä SSO-integraatioita. Tiimit saavat keskitetyn näkyvyyden, jota selaimen tallentamat salasanat ja jaetut laskentataulukot eivät tarjoa.

Yleisiä virheitä jaettujen holvien hallinnassa

Jaettujen holvien ongelmat alkavat yleensä oikopolkuina. Ne helpottavat käyttöä juuri sillä hetkellä, mutta tekevät samalla vaikeammaksi tietää, kuka voi myöhemmin käyttää mitkäkin kirjautumistiedot.

Viisi virhettä selittävät suurimman osan jaettujen holvien epäonnistumisista kasvavissa yrityksissä:

Yhden yritysholvin pitäminen käytössä liian kauan

Yksi holvi voi toimia alussa, mutta lopulta se antaa liian monelle käyttöoikeuden roolin ulkopuolisiin kirjautumistietoihin.

Riippuvuus yhden ylläpitäjän osaamisesta

Jos vain yksi henkilö tietää, missä kriittiset kirjautumistiedot sijaitsevat, yritys nojaa muistiin prosessin sijaan — ja se tieto lähtee ovista hänen mukanaan.

Holvien käyttöoikeuksien käsittely pysyvinä

Ihmiset vaihtavat tehtävää, ulkoiset työntekijät saattavat projekteja päätökseen ja toimittajat lähtevät. Holvien käyttöoikeuksien pitäisi muuttua heidän mukanaan.

Kirjautumistietojen vaihtamisen unohtaminen

Jotkin salasanat on vaihdettava, kun työsuhteet päättyvät, tehtävät vaihtuvat tai jakaminen on ollut liian laajaa — erityisesti ylläpitäjien tileillä, taloushallinnon työkaluissa, asiakasjärjestelmissä ja toimittajien porteissa.

Jokapäiväisten kirjautumisten sekoittaminen erityisoikeuksiin

Tiimin holvi voi helpottaa päivittäistä työtä, mutta korkean riskin kirjautumistiedot tarvitsevat silti tiukemman tarkistuksen ja kapeammat käyttöoikeudet.

Kaikkien näiden virheiden juurisyy on sama — mukavuuden ympärille järjestetyt käyttöoikeudet — samoin kuin parannuskeinokin: rakenne, joka heijastaa tiimiä, tehtäviä ja riskiä.

Miten Proton Pass for Business tukee tiimin salasanahallintaa

Proton Pass for Business auttaa yrityksiä siirtymään epämuodollisesta salasanojen jakamisesta jäsenneltyyn kirjautumistietojen hallintaan. Tiimit voivat luoda vahvoja salasanoja, tallentaa kirjautumistiedot salattuihin holveihin, jakaa käyttöoikeuksia turvallisesti ja hallita yrityksen salasanoja yhdestä paikasta.

Yrityksen salasanahallintapalvelu antaa tiimeille turvallisemman paikan tallentaa ja jakaa kirjautumistietoja, mutta näiden tietojen ympärillä oleva rakenne on yhä tärkeä. Kasvaville tiimeille seuraava askel on varmistaa, että jaetut käyttöoikeudet vastaavat sitä, miten ihmiset oikeasti työskentelevät: osaston, tehtävän, projektin ja riskitason mukaan.

Proton Passin ryhmien avulla kirjautumistietojen käyttöoikeuksia hallitaan tasolla, jolla tiimit oikeasti työskentelevät: ylläpitäjät määrittävät holvit ja kohteet ryhmille, jotka vastaavat osastoja tai projekteja, ja jäsenyyksien muutokset päivittävät käyttöoikeudet automaattisesti — uuden työntekijän lisääminen myöntää kaiken tarvittavan, ja hänen poistamisensa mitätöi kaiken.

Selkeämpi rakenne tekee turvallisesta jakamisesta helpommin hallittavaa työn lomassa. Kirjautumistiedot on järjestetty niitä oikeasti käyttävien tiimien ja tehtävien ympärille, ylläpitäjillä on parempi näkyvyys käyttöoikeuksiin, ja työntekijät löytävät tarvitsemansa salasanat siirtämättä salaisuuksia chattiin, sähköpostiin tai henkilökohtaisiin muistiinpanoihin.

Järjestä tiimisi kirjautumistietojen käyttöoikeudet yrityksen salasanahallintapalvelun avulla.