Kdo je vlastně na druhé straně?

Při návrhu systémů pro interní komunikaci uživatelů v rámci firmy bývá primárně kladen důraz na technologii, zejména na hardware a software, která se ke komunikaci používá. Hardware proto, aby správcové systémů mohli aplikovat interní předpisy firmy na používání notebooků, tabletů nebo smartphonů. Případně aby nastavili pravidla pro používání privátních zařízení. Software pro zajištění požadovaných služeb, mezi které patří vlastní elektronická komunikace nebo přehled o dostupnosti kolegů, možnost vytvářet skupiny uživatelů pro různé projekty či aktivity, sdílet informace apod.

Připravujeme-li návrh řešení pro skutečně efektivní komunikaci lidí ve firmě, nesmíme v žádném případě vynechat autentizaci a autorizaci uživatelů. Mělo by nás zajímat, zda ten „na druhé straně“ je skutečně tím, za koho se vydává.

Je dobré si uvědomit, že při elektronické komunikaci je naším partnerem na druhé straně člověk, a ne stroj nebo nějaká aplikace. Řešení musí být navrženo tak, abychom měli stoprocentní jistotu, s kým komunikujeme. Musím mít jistotu, že ten na druhé straně drátu je skutečně tím, za koho se vydává. Nemůže dojít k situaci, kdy budu komunikovat s někým cizím, kdo se za mého kolegu jenom vydává. Přitom jeho důvod může být jakýkoliv. Od prostého šprýmu až po důmyslnou průmyslovou špionáž nebo sociální hacking.

V žádném případě nesmíme zapomenout na správu uživatelů, na kontrolu jejich přístupu k elektronickým aplikacím sloužícím k interní komunikaci. To samé platí samozřejmě i pro externí komunikaci s dodavateli, odběrateli, zákazníky apod.

Proč o tom vlastně píšu? Vždyť každý z takových nástrojů pro elektronickou komunikaci nabízí autentizaci uživatelů přihlašovacím jménem a heslem. Tak jakápak věda?

Problém je v tom, že uživatel dychtící po využívání takových nástrojů je nucen si pamatovat další autentizační údaje. O nezbytném procesu registrace, kdy musí opět (pokolikáté už?) vyplnit nějaký registrační dotazník nového uživatele, nemluvě.

Někdo si dovede poradit i s touto situací a jednoduše použije svoje obvyklé login name a password, které používá už v několika dalších aplikacích. Pravdou je, že to určité řešení je, ale má i své slabiny. Tou největší je, že přihlašovací jméno bývá snadno uhádnutelné.

To je dáno rozdílnými požadavky na tvar přihlašovacího jména a hesla v různých aplikacích, které musí uživatel akceptovat, pokud chce používat jeden univerzální účet. Výsledkem je průnik těchto požadavků – tedy poměrně snadno uhádnutelný výsledek. Login name nejčastěji ve tvaru e-mailu a k tomu velmi slabé heslo.

Další slabinou je, že při uhodnutí nebo řekněme prolomení přístupových údajů uživatele má útočník přístup ke všem aplikacím, ke kterým byl použit tento slabý účet. A věřte, že útočník má k dispozici poměrně slušnou nabídku údajů o uživateli. Stačí mu trochu sociálního inženýrství na internetu. Nic víc ani nepotřebuje.

Jak se nedostat při zavedení nové elektronické aplikace na podporu efektivní komunikace lidí ve firmě do stejné situace? Standardním řešením je integrace aplikace sloužící ke komunikaci lidí mezi sebou se systémem pro správu uživatelů a kontrolou jejich přístupu. Tedy identity & access managementem firmy (IAM). Žádné další registrace uživatelských účtů, ale klasický provisioning.

Řeknete si, jasně, ale jaký je v tom rozdíl? Uživatel se bude přihlašovat jedním – univerzálním účtem, jako se přihlašuje do ostatních, v systému správy uživatelů integrovaných aplikací. Rozdíl zde je, a to značný. Jedná se o univerzální účet uživatele spravovaný v identity managementu (IDM). IDM je integrován s personálním systémem, takže zde mám první kontrolu. Uživatelův účet je aktivní pouze v případě, že v personálním systému má uživatel status „v pracovním poměru“. Dalším rozdílem je (resp. často bývá) unikátní uživatelské jméno. (Zde si dovolím malou odbočku. Mnozí uživatelé systému datových schránek se dodnes diví, proč mají zvláštní uživatelské jméno. Složeno z písmen a číslic místo třeba jejich e-mailu. Které nelze nijak změnit. Je to právě proto, aby jejich uživatelské jméno nebylo snadno zjistitelné sociálním inženýrstvím. Stejný princip jistě znáte i u bank z vašeho internetového bankovnictví.)

Dále je pro uživatelský účet vyžadováno tzv. silné heslo. Minimálně osm znaků, kombinace písmen (malých i velkých), číslic a případně speciálních znaků. Prostě heslo, které nelze jen tak uhodnout. Často navíc s podmínkou jejich obměny každých 90 dnů. (Má to svůj význam, doporučuji.)

Tím zásadním kvalitativním rozdílem je u centrální správy uživatelů a používání jednoho univerzálního uživatelského účtu další autentizační faktor. Kromě hesla musí uživatel zadat ještě například jednorázové heslo (OTP – One Time Password), které vygeneruje pouze pro konkrétní login. Často se používá dokonce certifikát.

Pokud tedy ve firmě mám zaveden systém centrální správy uživatelů, mohu se spolehnout, když se mi hlásí kolega prostřednictvím nějaké on-line aplikace, že je to skutečně on. Pak můžeme činit třeba i nějaká důležitá rozhodnutí, a to v on-line režimu.