Régóta dolgozom Shared Service Center környezetben, ahol gyakran szembesülök azzal, hogy a külföldi managementnek nehéz kiejteni magyar csapattagok neveit. Korábban nem is gondoltam bele, hogy egyszerűnek tűnő nevek (pl. "Szabolcs") mekkora fejtörést jelenthetnek egy külföldinek. Fontosnak tartom, hogy egy manager tanulja meg, hogyan kell kiejteni a neki dolgozó emberek nevét.

Segíteni szeretnék, így készítettem egy egyoldalas "puskát" a magyar szavak/nevek kiejtésére, eredetileg Linkedinen tettem ki, most ide is felrakom.

Célszerű úgy beállítani a webes szolgáltatásokat, hogy belépéskor ne csak jelszót kérjenek tőlünk, hanem a jelszó mellett egy második faktort is ellenőrizzenek. Legtöbbször egy mobilon kapott vagy generált kódot kell megadnunk, így aki be akar lépni, annak nem elég ismernie a jelszavunkat, nála kell, hogy legyen a mobilunk is.

Korábban írtam róla, hogy SMS-ben kapott kód viszonylag gyenge megoldás, mert az SMS-ek viszonylag könnyen eltéríthetőek, autentikátor appokat, köztük a Google Authenticatort javasoltam. Egész addig nagyon boldog is voltam a Google Authenticatorral, amíg egyszer össze nem tört a telefonom. (Frissítés: időközben ez változott, lásd e cikk végét.) Azt hittem, a Google Authenticator a Google fiókomban tartja a seedet, amely segítségével a belépési kódokat generálja -- de nem így működik. A belépési kódokat generáló seed a telefonon van, és ha a telefon megsemmisül, akkor többet senki nem tud belépési kódot generálni. (Vajon miért kizárólag a telefonon tartja a seedeket? Azért, hogy ne vádolhassák a Google-t, hogy túl sok infót gyűjt össze rólunk?) Végig kellett mennem az összes szolgáltatáson, ahol Google Authenticatort használtam, és valahogy rá kellett vennem őket, hogy engedjenek be másképp. Nem mindig volt egyszerű. :)

Tanulság: Menteni kell az autentikátor app seedeit, különben csúnyán kizárhatom magam mindenhonnan. Google Authenticatorral az első bejelentkezéskor megadott seedeket kellen menteni, és ez macerás. Arra jutottam, jobb másik autentikátor appot használni.

Egyik megoldás az Authy. (Előnye, hogy PC-n is fut, így ott is tudok kódokat generálni, de ez egyúttal hátrány is; a PC-n futó Authy tartalmát úgy gondolom, túl könnyen lemásolhatja valaki, ha hozzáfér a PC-mhez vagy esetleg feltöri.)

Másik megoldás a FreeOTP. Ugyanazt a TOPT szabványt valósítja meg, mint a Google Authenticator és az Authy, csak nyílt forráskódú alkalmazás, és könnyen exportálhatóak belőle a seedek.

Ismerek olyat is, aki a Bitwarden-re esküszik, ez egy online cucc, egyszerre jelszókezelő és második faktort generáló autentikátor, tehát ő tudja intézni a bejelentkezés összes lépését. Ez előny is és hátrány is egyszerre.

Lényeg, hogy mentsük az autentikátor appunk seedjeit, különben alaposan pórul járhatunk!

Frissítés (2024-08-25):

A következő olvasói visszajelzéseket kaptam időközben:

• A Google Authenticatorban régen valóban offline volt minden seed, de időközben (2023 óta) már képes szinkronizálni a seedeket a Google fiókba, de ezt be kell kapcsolni (megkérdezi, hogy menetse-e a seedeket).

  Így választhatunk, milyen Authenticatort szeretnénk: aminek külön menteni kell a seedjeit, vagy ahol a Google Nagy Testvér funkciója megoldja helyettünk a mentést. Azt javaslom, hogy aki autentikátor appot használ, az mindenképp intézzen hozzá valamilyen mentést.

• További autentikátor eszközök, amelyek mentik a seedjüket pl. a 2FAS (amely szintén open source, és van böngésző-pluginje) és a Passbolt (ez utóbbi inkább céges megoldás).

Nagyon szépen köszönöm! :)

A felhőben is találhatunk jó megoldást archiválásra. Kényelmes, nem telik be a tár, nem kell attól tartani, hogy a média tönkremegy vagy olvashatatlanná válik, és vannak egész olcsó megoldások is. Az alábbiakban otthoni használatra is alkalmas megoldásokról írok, bár ezen eszközök elsősorban céges felhasználásra készültek, igényelnek némi hozzáértést, munkát. Engem a családi fényképek tárolása indított arra, hogy komolyan foglalkozzak archiválással: ez sok gigabyte adatot jelent, amely pótolhatatlan, ha megsemmisül, és nem szeretném, hogy bárki csak úgy hozzáférjen.

A felhő alapú drive-ok (OneDrive, Google Drive, Dropbox) jellemzően drágák, ezek arra szolgálnak, hogy aktívan is dolgozhassunk az ott lévő fájlokkal. Léteznek sokkal kedvezőbb alternatívák is, például a nagy felhő szolgáltatók object storage megoldásai (pl. S3), azon belül is az archív tárolók. Ezeket arra optimalizálják, hogy hosszú távon tároljunk bennük az adatainkat: a tárolás olcsó, viszont pénzbe kerül elérni az ott tárolt adatokat, és gyakran nem azonnali elérésünk van, hanem ha le akarjuk tölteni, akkor csak néhány órán belül kapjuk meg. Ha archiválunk, akkor legtöbbször soha nem akarjuk elérni a biztonsági mentést, ha pedig mégis, akkor sokkal nagyobb bajunk van, mint néhány dollár vagy néhány óra várakozás.

E cikk írásokat a nagyobb szolgáltatóknál kb. havi 0,01 USD -be kerül 1 Gb adat tárolása, a pontos összeg számos paramétertől függ, pl. hogy mely földrészen szeretnénk tárolni az archív adatokat, a szolgáltatók egymást másolják, az áraik között nagyon pici különbség van csak:

• Amazon S3 Glacier Deep Archive --> árak

• Google Archive Storage --> árak

• Microsoft Azure Arhive Storage Blobs --> árak

Először is elő kell keríteni az adatokat, amiket archiválni szeretnénk. Ha az otthoni NAS-unkat mentjük, ez nem gond, ha felhőben vannak az adatok, akkor először ki kell nyerni, amit archiválni szeretnénk (és a software as a service megoldások mentése nem mindig triviális). A Google rendelkezik adatletöltő szolgáltatással, amely a takeout.google.com címen érhető el, ezzel az összes Google szolgáltatásból (Drive, Gmail, Photos, stb) letölthetjük az adatokat nagy zip-ekbe csomagolva. A Microsoftnál nem tudok hasonlóról, ott az egyes szolgáltatások (OneDrive, Outlook) mentéséről találtam csak tippeket.

Lehet értelme titkosítani az adatokat archiválás előtt. Ha zip fájlokat akarunk menteni, azokat akár külön betitkosíthatjuk pl. openssl-lel (vagy bármilyen titkosító alkalmazással). Ekkor fontos, hogy mindenképpen őrizzük meg a titkosítást feloldó kulcsunkat, mert ha azt elveszítjük, akkor mi magunk tesszük tönkre az archívumot. Támaszkodhatunk a szolgáltató titkosítására, de az kérdéses, hogy pontosan mi ellen is véd. Szintén meggondolandó, mennyire éri meg titkosítással foglalkozni, ha a szolgáltató úgyis eléri a nyílt adatokat (pl. ha a OneDrive-ról töltünk át adatokat a Microsoft Azure archívumába, vagy Google Drive-ból Google Storage-ba).

Ezt követően fel kell tölteni az archívumba, az adatokat. Itt volt olyan próbálkozásom, hogy a takeout-ból letöltés nélkül egyből a szolgáltatóhoz küldjem az adatokat, de erre nem találtam igazán jó megoldást. (Érdekes, amikor a felhőszolgáltatásokban egy-egy alapnak tűnő funkció egyszerűen nincs ott, nincs kész.)

Innentől kezdve nincs más dolgunk, mint fizetni a havi számlákat. Saját archívum esetén a költségeket előre fizetjük ki egyben (pl. lemez vásárlásával), itt viszont havonta fizetünk. Ez jelent rugalmasságot is, viszont gondoljunk rá, hogy ha nem fizetjük a számlákat, elveszíthetjük az archív adatokat.

Megjegyzem még, hogy jó ugyan a felhő, de nem baj, ha van saját mentésünk is. Én évente szoktam menteni, és mindig két helyre:

• Felhőbe -- talán ez ma a legolcsóbb, legrugalmasabb mentés és legbiztonságosabb megoldás; itt nem az én dolgom, hogy a média olvasható maradjon, és több földrajzi helyen tárolom az adataimat, így akkor is megússza, ha az egész ház lég...

ÉS emellett...

• USB meghajtóra, amit beteszek a szekrénybe -- főként azért, mert ez más; az USB meghajtó néhány év múlva vagy működik, vagy nem, viszont ez akkor is elérhető, ha kizáródok a felhőből, vagy akár az Internet áll le (tudom, ez paranoid gondolatnak tűnik, de az ember azért archivál, mert tart az ismeretlentől).

A saját mentés kevésbé rugalmas, talán kevésbé megbízható, de más kockázatok ellen jelent védelmet.

A Cyber Safety Review Board jelentése a tavalyi MS Exchange Online incidensről, sok súlyos állítást tartalmaz a Microsofttal kapcsolatban. (Nem megfelelő biztonsági kultúra, sorozatos hibák egymásutánja, nem vették észre, nem követték az iparági legjobb gyakorlatokat.)
Érdekes olvasmány.

A Microsoft nagyon sok helyen ott jelen, bizonyos területeken kizárólagos, nemcsak az operációs rendszerek, hanem néhol még a felhőszolgáltatások területén is (pl. Exchange Online-on ment az amerikai kormányzati levelezés jelentős része). Ha egy operációs rendszerben van biztonsági hiba, az akár enyhíthető lehet, ha pl. az oprendszert elszigeteljük a külvilágtól, vagy letiltjuk a felesleges szolgáltatásokat. Ezzel szemben egy felhőszolgáltatás esetén a szolgáltató teljeskörű megoldást ad a biztonságra (az ügyfél pedig sok esetben nem is tehet többet); ha a szolgáltató hibázik, akkor az ügyfél pórul jár, és esetleg a kínai vagy bármely más titkosszolgálat ki-be jár amerikai kormányzati rendszerekbe. E cikk szerint a Microsoft kifejezetten kockázatot jelent Amerika számára.

Egyre többször tapasztalom, hogy ha két ITs leül beszélgetni, azzal teremtik meg a közös hangot, hogy a Microsoftot szidják. Ez kifejezetten a 90-es éveket idézi... Nagyon retro...

Kevés nagyobb malőr történhet a felhőben, mint amikor valakinek mindenét letörlik. Ez egy olyan eset, amikor a felhőszolgáltató (esetünkben: Google Cloud) "csak úgy" letörölte egy ügyfél fiókját, vele minden adatát, és meg sem tudta magyarázni, hogy miért. Az ügyfél egy ausztrál nyugdíjalap volt, így elég nagy balhé lett a dologból. Ez az eset egyrészt azért különleges, mert itt az ügyfél teljesen vétlen volt, a szolgáltató törölte az adatait.

Minden rendszerben előfordulhat, hogy egy rendszergazda hibás törlési parancsa elszabadul. Mivel felhőben különösen jól menedzselhetőek az adatok, egyetlen hibás parancs akár egy cég összes adatát letörölheti. Ha PaaS/IaaS szolgáltatásokról beszélünk, itt nemcsak adatokról van szó, előfordulhat, hogy a fiók törésekor a cég teljes informatikai rendszere egyszer csak "elmúlt", beleértve a szervereit, alkalmazásait, ezek forráskódját, beállításait, beleértve a felhasználók adatait, jogosultságait stb.

A mentés nagyon sok probléma esetén segít, bár ha ugyanabba a felhő-fiókba mentünk, akkor az ilyen malőrnek a mentés is áldozatul esik. A nyugdíjalap szerencsére más felhőszolgáltatónál is tartott mentést (ami nagyon bölcs lépésnek bizonyult), így szerencsére nem vesztették el mindenüket. A józan ész fontos, a csilli-villi technológiák nem helyettesítik.

További bejegyzések a blogomban...