Több helyen van wifink, ahol WPA Enterprise-sal 802.1x-el megy a hitelesítés user+password auth-tal. Részleteket nem írok, mert szerintem a probléma szempontjából irreleváns.
Minden user jelszavára lejárat van, a "probléma" hogy ekkor (illetve nyilván bármilyen jelszócserekor) a wifire nyilván nem tud belépni a régi jelszóval. És erre mi a reakciója az összes OS-nek? Semmi. Nem feldob egy ablakot hogy auth error 3, 5, 10 próbálkozás után, hanem próbálgatja a háttérbe automatán, amíg le nem lövöd, vagy kézzel meg nem nyitod, és be nem írod az új jelszót. Sajna a windows is, linux is és az android is ezt csinálja... Nem is értem. Ami még szép az egészben, hogy a sok sikertelen login miatt gyakran le is bannolja az ip címet egy időre az auth szerver.
Szóval, a kérdés hogy mit lehet ezellen tenni? Csak annyit szeretnék, ami a normál elvárt működés (szerintem), hogy mondjuk 3 próba után dobja fel a rendszer hogy hitelesítés hiba, add meg újra. Tanúsítvány alapú hitelesítésre nem szeretnék áttérni (macerásabb kezelni, karbantartani), illetve nem tudom ezután nem lenne-e hasonló reakció ha lejár vagy letiltásra kerül a cert.
Hozzászólások
Pedig nem véletlenül cert-et használnak mindenhol, ahol dot1x fut.
Én csinálhatok cert alapú .1x-et, de Te fogod supportálni 1000+ júzernek, akik olyan szinten cserélgetik a BYOD eszközeiket, mint más az alsógatyáját.
Pár kérdés:
Mit kell ezen "supportálni"? Az MDM teríti nekik automatikusan a cert-et nem?
Ezt nem kézzel szokták, még BYOD esetén sem.... vagy rosszul gondolom?
Rosszul gondolod, BYOD eszközöknél (ahol a munkavállaló a tulajdonosa az eszköznek, és nem a cég) nem kivitelezhető az, hogy tanúsítványt telepíts az eszközére. Mivel nem céges eszköz, ezért üzemeltetési oldalról nagy ívben el kell kerülni őket, már csak a félreértések elkerülése véget is.
Kell nekik egy karantén wifi,a hova fel tud csattanni, és amiben van egy önki...szolgáló jelszócsere felület. Utána a lecserélt jelszóval már becuppanhat a másik wifire.
A BYOD normálisan úgy kéne, hogy működjön, hogy van egy BYOD wifi, amiből VPN-en, és/vagy megfelelő azonosítás mellett elérhetőek bizonyos céges hálózati szolgáltatások - de messze nem minden, és nem mindenféle/bármilyen eszközről.
Teljesen mindegy hogy csavarod és hány rétegen keresztül cibálod, a lényeg ugyanaz - egy ismeretlen, kontrollálatlan gépről hozzáfér adathoz, amivel utána azt csinál amit akar. Illetve fordítva is, olyan kriptovírus vagy akármi megy be a gépén keresztül, ami akar, ha felépült a kapcsolat.
"Sose a gép a hülye."
"bizonyos céges hálózati szolgáltatások - de messze nem minden, és nem mindenféle/bármilyen eszközről" - ez egy elég lényeges feltétel...
Arról volt szó, hogy hozhat bárki bármilyen eszközt, amivel eléri amit kell, ami kb. attól lesz jó, hogy a rendes wifi elé beteszel egy jump wifit, meg utána vpn-ezik mégegyet. (Mellesleg ettől szerintem az összes user összes haja kihullana...)
"Sose a gép a hülye."
A júzerek se&&fájása nem érdekel, az elsődleges/publikus wifi és az ott elérhető önki...szolgáló jelszócsere felület arra lenne megoldás, hogyha lejárt, akkor legyen egy hely, ahol jelszót tud cserélni; utána a céges erőforrásokhoz meg úgy férhessen hozzá, hogy azonosított, szűrt és a legkisebb jogosultság elve alapján kapjon eléréseket.
De kaphatnak MDM-et is a vackukra...
(technikai oldalról nézve: ha publikus Wi-Fi szolgáltatást akarok nyújtani a felhasználónak, akkor ahhoz nem szükséges jelszócserés felület, mert RADIUS+AD auth-tal a felhasználó be tud lépni, és eleve AD oldalón elő van írva a rendszeres jelszócsere.)
Oké, de ha lejárt a jelszava, akkor a RADIUS szerver sem fogja beengedni, mert az AD azt mondja neki, hogy nyasgem... (Ha van zárolási policy is, akkor meg pláne funny tud lenni a "mindent is az AD-ból authentikálunk" dolog... (igen gyorsan lehet hibás authentikációkat csinálni akár sok userre is...)
ha lejár valakinél a jelszó, akkor nem az lesz az elsődleges problémája, hogy miért nem tud a helyi publikus wi-fi szolgáltatásra feljelentkezni, hanem az, hogy mindenképp jelszót váltson, hogy tudjon dolgozni.
az AD auth-nak annyi előnye azért van, hogy a felhasználók egységes jelszóval tudnak bejelentkezni oda ahova van joguk, illetve egy helyen elég tiltani a felhasználót, és rögtön kizárod minden honnan.
talán így egyszerűbb megoldani egy felhasználói szolgáltatást (publikus wi-fi), mint külön jelszókezelő portált üzemeltetni.
Kontrollálatlan akkor, ha nincs, aki/ami kontrollálja. Nem tudom, hogy az Intune mennyire képes kontrollálni az eszközt, nekem úgy néz ki, hogy nagyon. :)
Rosszul gondolod, regisztráció/management nélkül saját eszközt nem engedünk fel a hálózatra vagy hozzá céges alkalmazáskhoz. Ez remélem vitán felül áll. Zero-trust concept.
Egy eszköz vagy céges és teljes management van rajta (MDM) vagy BYOD és csak egy enterprise profile/konténer, ahova azokat az appokat teszed ami "céges" /outlook,../. (MAM) Innen nem mozgat ki-be adatot. A saját alap profiljába meg az van amit ő akar. (azt nem is tudod wipe-olni remote-ból, csak az enterprise-t)
A VPN és WIFI-s dolgokat is ezzel teríted, ez tök független az eszköz ownership-étől.
Ha csak wifis pure internetet akarsz adni a dolgozónak, azt nem nem egyedi jelszóval szokták és az egy teljesen szeparált csatorna, kb mint egy guest network. Max teszel egy captiva portált rá, ha akarsz policy-t elfogadtatni az elején.
Bármilyen byod felmászhat a hálózatra? Oké, h. a melós tulajdona a gép amivel a cégnek termel (a pokolban Carl Marx összecsettinti az ujját h. ezt a byod-t így sikerült a nagyvállalatoknak elérnie). De ilyenkor is lehet (igazából kellene) MDM kliens szoftvert felpakoltatni az eszközére. Az csak a munkahelyi tárolóhoz fér hozzá, a privát részhez nem. Viszont így elő lehet írni bizonyos biztonsági minimumokat + a cert-et is fel tudja varázsolni az MDM.
Amúgy meg azt szupportálsz, amiért a fizetésedet kapod :)
Amint egy céges backdoor-t KELL feltenni a saját gépre...
főleg, hogy ez a céges backdoot egy meghatározott OS-t (és verziót) feltételez, ugye... tehát már az OS-t is a cég diktálja?!
Innentől az már biztosan nem saját gép. - csak a dolgozó finanszírozza.
szerintem.
zrubi.hu
Mivel a cégé az adat/infrastruktúra és ő futja ennek a kockázatát is, igen fel KELL tenni, ha használni akarod. :-)
Ezért is írtam, h. totálisan kifordult felfogás. 10 éve még az volt a nagy szám, h. adott ájfont/blackberry-t a dolgozónak a munkahelye, és azzal használhatta a céges erőforrásokat céges munkára. Ma meg azzal a bikaszarral van megideologizálva a BYOD, hogy a saját privát megszokott belakott eszközödet használhatod munkára is.
Így van. Ez kb ennyi.
Valakinek ez szempont, hogy ciki ha nem a legújabb iphone-ján kattingathat, mert a cég csak valami középkategóriás telefont adna, kettőt meg nem akar húzni magával.
Hozzáteszem én is rühelltem 2 telefont magammal cipelni, mikor opció sem volt a sajáttal belépés céges hálózatra.
Használhatja, _de_ ennek vannak feltételei - például az, hogy a munkához illetve a magán célú használathoz tartozó adatokat elválasztva kell kezelni, a kettő nem keveredhet, és az sem mindegy, hogy az adott eszközre egyáltalán milyen céges adat kerülhet ki. Ehhez egy MDM kell, ami nem backdoor a cég számára, hanem arra szolgáló eszköz, hogy a cég adatait (és csak azt!) a privát eszközön is kontrollálni tudja a munkáltató.
Bizony...
Szerintem is nagy +1
"Sose a gép a hülye."
Láttál már közelről MDM megoldást? Gondolj el egy konténert, amiben futhat neked levelezőszoftver, böngésző, meg egy rakás alkalmazás, de ez a konténer csak a céges hálózattal tud kommunikálni, az alatta futó OS-en lévő adatokhoz nem fér hozzá, hálózatilag csak a céges háló felé tud kommunikálni (az alatta lévő OS hálózatán elérhető eszközökkel nem), és hasonló "okosságok"... A céges admin ezt a konténert tudja konfigurálni, ide tud adatokat betolni, vagy épp törölni, akár a teljes konténert is.
El tudom képzelni, dolgoztam már hasonlón. A gyakorlatban a használhatóságot a használhatatlanságig tudja fokozni.
Kevés bármi olyan munkát tudok elképzelni, amihez valamilyen formában nem kéne net. Namost vagy a konténerből kieengeded, vagy ha nem, akkor a saját gépeden netezel, keresgélsz, de se egy URL-t, se egy code snippetet nem tudsz se ki, se bevinni. Fájlt szintén nem. De még a mikrofon/kamera hozzáférés is problémás egy akármilyen híváshoz. Ezt az általam használt rendszerben még azzal is tudták űberelni, hogy a virtuális gép VPN-ezett, és a screen lockolásakor disconnectált a VPN. Szóval kb. semmi interaktív session nem használható, illetve de, screenezhetsz, meg reconnectálhatsz mindig vissza SSH-ra meg RDP-re.
"Sose a gép a hülye."
A DLP nehéz dió, hogy úgy mondjam nem biztos, hogy a júzerek kényelméért van... Volt nekem is olyan, hogy 9600-8-N-1 soros konzol volt csak egy kupac géphez, és az is úgy, hogy a teljes tty-forgalom ment a logszerverre, hogy lehessen tudni, ki, mit nézett meg, mit csinált.
Az, hogy "kell net" az a jelenlegi kényelmes működés feltétele, azt lehet olyan módon csinálni, hogy van egy nagyvilág felé kilátó TS, meg van egy másik, amin dolgozol. A munkára hasznát eszköz(ök) felől meg maximum szűrten (SSL-bontással, url- és tartalomszűréssel) éred el a nagyvilág azon részét, amire valóban szükség van adott környezetben.
ühüm.
És security szempontból melyik lesz a szűk kersztmetszet? :)
Attól hogy valamit egy konténerbe 'zársz' - bármit is érts ezalatt - a könténer tartlama soha nem lehet 'biztosnágosabb', mint az alatta levő (host) OS. Szóvla ha az kompromittálódot akkor gyakorlatilag a konténered is annak tekinthető.
szerintem.
zrubi.hu
A konténeren itt egy olyan megoldást értek, amibe az OS felől, illetve amiből az OS felé nincs átjárás. Ha kompromittálódott az eszköz (#define kompromittálódott), azaz harmadik fél sikeresen "felnyitotta" az OS _és_ a konténer zárolását (pin/jelszó), akkor való igaz, a céges adatokhoz hozzáférhetett. De amitől itt többen tartanak, a konténert menedzselni jogosult céges rendszergazda csak a konténer határáig "lát", annak a tartalmát tudja teljes körűen felügyelni, az alatta futó OS-t, illetve a mellette futó többi konténert már nem. Képzelj el egy gépet, amin van egy könnyűsúlyú virtualizáció, meg két VM.
Azt válasszuk ketté, hogy BYOD kliens gépekről vagy mobilokról beszélünk.
Mobil esetén MDM vagy MAM, modjuk pl. min. OS verzió és root jog ellenőrzéssel. Wifi, vpn konfig megy ki központikag cert-tel a managemet konzolból. Ez sima liba.
BYOD kliens gépet soha nem engedünk hozzá erőforráshoz/hálózathoz/akalmazáshoz direktben. Pont.
Erre van a terminal server/jumphost/VDI/AVD... egy sima guest wifi-vel vagy egy korlátozott VPN-nel ezeket el tudja érni. Azok a gépek meg már managelt gépek (AV, EDR, DLP,...), elérhetik amit kell. Ha nem teljes Dekstop UI-t adsz csak applikációt ajánlasz ki, még észre sem veszi, hogy nem az ő gépén fut a móka.
Vagy valami olyan megoldás mint a intune, amivel az MS szenved most:
https://learn.microsoft.com/en-us/mem/intune/fundamentals/deployment-guide-enrollment-linux
Még linux desktopot is be tudsz vonni BYOD-s eszközként, de ennek azért vannak infrastrukturális előfeltételei erősen - meg anyagi vonzata, nem meglepő módon. :-)
De logikailag valami ilyesmi a "megoldás"
Valóban, szerintem is ez az ahogy a BYOD-t érdemes megközelíteni.
Ez azonba szerver oldalon lesz drága - megkockáztatom - drágább, mint managelt laptopokat adni az összes felhasználónak.
Ez tipikusan nagy multinak való, ahol 'nagyon sok' user, különböző országokból dolgozik.
De ehhez legalább a 'céges' WiFi-t nem kell túlmisztifikálni ;)
zrubi.hu
Ez szép elgondolás, de sajnos az IT jelen állása szerint egyelőre(?) ilyen nincs a gyakorlatban.
Qubes OS-t használok 10+ éve, így el tudom képzelni. :)
ugyanezért azt is látom, hogy a host OS ~mindig 'god mod'-ban fut.
lát(hat)ja - és akár módosíthatja is - a guest-ek:
- memóriáját,
- képernyőjén megjelenő dolgokat,
- kameráját, mikrofonját, billenytűzetét, egerét, stb.
szóval mindent ami számít. :)
Telefonokon is csak azért megy (látszólag) jobban ez, mert ott a user eleve csak limitált (nem root) jogokkal bír a 'saját' eszközén.
Ott valamiért mindenki 'vakon' megbízik az OS szállítójában, és megelékszik azzal amit kap.
(A 'PC-k' esetében ilyesmit csak az apple-nek sikerült letolni a userei torkán. - több kevesebb sikerrel)
zrubi.hu
"Ott valamiért mindenki 'vakon' megbízik az OS szállítójában, és megelékszik azzal amit kap." - a thread elején az volt a felvetés, hogy az MDM "backdoor a munkáltató számára" - mivel nem a core OS-hez, hanem egy zárt "dobozhoz" kap a munkáltató az MDM-mel hozzáférést, így nem alá/fölérendeltség van a privát és az MDM-es részek között, hanem mellérendelt "dobozok", nem látnak be egymásba.
Továbbra sem világos, hogy:
- ki készíti az MDM appot, amelyik majd elkészítit a céges dobozokat? - mert hogy ez nem része egy standard oprendszernek az biztos.
- az az app szinte biztosan full root access-el szalad a gépeden? amit néha frissíteni is kell gondolom.
- mennyire van az a 'doboz' bezárva, ha WiFit is akar konfigurálni?
- mitől nem tudja a 'ceges dobozon kívüli' billenytűleütéseidet is rögzíteni?
zrubi.hu
Óriási innováció az androidban! "Change password"
Mondjuk fel nem dobja hogy szar a jelszó, inkább próbálgatja folyamatosan a háttérben hogy a brute force detektor szépen lebannoljon... De legalább ha bemész a wifihez akkor van rá lehetőség és nem kell az egészet kitörölni és újra csinálni. Ez is valami.
"Sose a gép a hülye."