asiakas kysyy salasanaperiaatteestamme, mitä siinä pitäisi olla

Salasanakaava kuuluu pääsynhallintaan, ei salaukseen

Salasanakaava kuvaa, kuinka salasanat luodaan, hallitaan ja vaihdetaan: vähimmäispituus ja monimutkaisuus, pakollinen vaihtaminen väärinkäytön epäilyllä, vanhojen salasanojen uudelleenkäyttökielto ja tapa, jolla salasanat tallennetaan (hajautettuina, ei selkokielisenä). Asiakkaat kysyvät tämän yleensä osana pääsynhallintoa, mukaan lukien liiketoimintavarojaeikä erillisenä salausongelmana. Tämä ero on olennainen valitsemallesi vastauksen kannalta: datan salaus koskee jotain muuta kuin sitä, kuinka käyttäjä kirjautuu sisään.

Usein puuttuu ei itse kaava, vaan todiste sen täytäntöönpanosta: tekninen asetus identiteettijärjestelmässä (Azure AD, Okta tai vastaava), joka pakottaa vähimmäisvaatimukset, sen sijaan, että olisi asiakirja, jonka työntekijöiden oletetaan lukevan. Jos sinulla ei ole tätä todistetta, älä merkitse "kyllä" kysymykseen, onko kaava pannassa täytäntöön — merkitse kyllä vain kysymykseen, onko kaavaa olemassa, jos asiakirja todella on olemassa. Yhä useammin erillinen salasanakaava pidetään vähemmän merkityksellisena kuin kysymys siitä, onko monivaiheinen tunnistautuminen pakollinen: vahva salasana MFA:n kanssa on käytännössä parempi kuin pitkä salasana ilman MFA:ta.

Missä se normeissa ja ohjeissa mainitaan

ISO/IEC 27001 käsittelee salasanojen hallintaa pääsynhallinnan valvontatoimenpiteiden yhteydessä liitteessä A (todennus-informaatio on siellä erillinen valvonta); Direktiivi (EU) 2022/2555 mainitsee pääsynhallinnan ja todennuksen yhtenä kymmenestä artiklan 21 kohdan 2 mukaisen toimenpiteen – direktiivi jättää teknisen toteutuksen organisaation vastuulle. Kysymyslomake, joka kysyy "salasanakaavasta", kääntää siis yleensä yhden näistä kahdesta lähteestä konkreettiseksi, testattavaksi kysymykseksi.