Category Archives: Intune

Microsoft Intune Suite és add-on képességei

Posted on by
Reply

A Microsoft Intune MDM megoldása már régóta a piacon van, lefedve a Windows, Android, macOS, Linux és iOS platformok menedzselését. A Microsoft azóta több szolgáltatást is fejlesztett és ezeket különböző csomagokba építette, igényekre reflektálva (Távoli segítség, firmware frissítést stb.)

Az alábbi táblázat mutatja az Intune Suite funkcióit, a licenszelésre később kitérünk:

Nézzük meg egyenként a funkciókat, röviden áttekintve:

  • Endpoint Privilege Management: Az EPM segítségével a standard jogosultságú felhasználók végrehajthatnak különböző feladatatokat, amik admin jogosultságot igényelnek (pl. alkalmazástelepítés, driver install, stb). Az IT-adminok különböző policykat küldhetnek a gépekre, ahol a felhasználó használhatja a “Run with elevated access” opciót és indoklás megadávásal elvégezheti a feladatot.
  • Enterprise App Management: egy előregyártott Win32 alkalmazásgyűjtemény, ami tartalmaz Microsoft és 3rd party alkalmazásokat (pl. Foxit PDF Reader, Dell Command Update stb). Az alkalmazásokat előre paraméterezték (detection rule, install-uninstall script) igy azonnal használatba vehetőek. Az itt található alkalmazások automatikus frissitik magukat, a kliensgépen is.

  • Advanced Analyitcs: az AA segítségével proaktívan felderíthetők és megoldhatók a kliensgépeken található problémák (alkalmazás összeomlások, legfagyások, váratlan gépújraindulások stb) vagy akár a laptopok akkumulátor-problémái is azonosíthatók.
  • Remote Help: biztonságos helpdesk kapcsolat Windows/Android/macOS eszközök felé. Ennek segítségével a helpdesk tud kapcsolódni az adott eszközre és láthatja a képernyőjét, átveheti az irányítást is. A biztonságot a role-based access adja, szigorúan meghatározott szerepkörökkel. Ez különösen hasznos funkció, ha külső hálózatban lévő gépet kell távolról supportálni.
  • Microsoft Tunnel for Mobile Application Management: amennyiben használunk Microsoft Tunnel VPN Gateway-t, a Tunnel for MAM szolgáltatással ki tudjuk terjeszteni az elérést a nem-enrollolt, nem menedzselt eszközökre is. A felhasználó a nem menedzselt eszközével is el tud érni belső hálózaton található erőforrásokat, SSO-val, modern hitelesítéssel, Conditional Access szabályokkal. Ez Android és iOS platformokra vehető igénybe.
  • Firmware-over-the-air-update: bizonyos támogattott eszközök automatikus firmware frissítését teszi lehetővé, pl. Zebra vagy Samsung Knox eszközök.
  • Specialized device management: AR/VR headsetek (RealWear, HTC eszközök), Microsoft Teams Rooms, Microsoft HoloLens eszközök menedzselését teszi lehetővé.

Licenszelés:

Alapvetően szükséges a Microsoft Intune licensz megléte. Ez lehet Business Premium vagy E3/E5 licensz, esetleg standalone Intune előfizetés. Erre lehet fűzni az Intune Plan 2-t ( Tunnel for MAM és specialty device management képességek) vagy az Intune Suite-ot, ami minden funkciót tartalmaz. Fontos azonban hangsúlyozni: az Intune Suite-hoz szükség van az alap Intune licenszre!

Leggyakoribb igény esetleg a Remote Help lehet, ezt add-on formájában meg lehet vásárolni az alap Intune licenszhez, 3,5 USD/hó/felhasználó áron.

A többi elérhető szolgáltatást igénybevételét is lehet mérlegelni, igénybe venni.

Intune Certificate Connector – Azure AD Sign in probléma

Posted on by
Reply

Microsoft Intune Certificate Connector telepítése közben szükséges belépni az Azure AD-ba. Ilyenkor viszont belefuthatunk egy hibaüzenetbe:

“Something went wrong An unanticipated error occurred. Your IT department may be able to help.”

A sikeres konfigurációhoz az alábbi feltételek szükségesek:

  • Global Administrator vagy Intune Service Administrator szerepkör ÉS Intune license hozzárendelve (ez elég ideiglenesen, a konfiguráció időtartamára) az accounthoz.
  • Az accountnak szinkronizálva kell lennie az Azure AD-val.

Ezek után már működik a bejelentkezés

Always-on VPN IPSec policy Intune-ból

Posted on by
Reply

Aki már konfigurált AOVPN-t, az tudja, hogy illik az IPsec beállításokat az alapértelmezettnél erősebbé tenni.

Az alapértelmezett IPSec értékek a következők:

  • Encryption: 3DES
  • Authentication/Integrity: SHA-1
  • Key Size: DH Group 2 (1024 bit)

A javasolt beállítások:

  • Encryption: AES128
  • Authentication/Integrity: SHA-256
  • Key Size: DH Group 14 (2048 bit)

A VPN szerver oldalon ezt powershell paranccsal tudjuk módosítani:

Set-VpnServerConfiguration -CustomPolicy -AuthenticationTransformConstants SHA256128 -CipherTransformConstants AES128 -DHGroup Group14 -EncryptionMethod AES128 -IntegrityCheckMethod SHA256 -PFSgroup PFS2048 -SALifeTimeSeconds 28800 -MMSALifeTimeSeconds 86400 -SADataSizeForRenegotiationKilobytes 1024000

Utána szükséges a Remote Access service-t újraindítani:

Restart-Service RemoteAccess -PassThru

Ezzel a szerveroldali beállítások elkészültek. Szükséges viszont hogy a kliens oldalon is megegyezzenek az IPSec konfigurációk, itt is segítségül hívhatjuk a powershellt:

$connection = “[connection name]”
Set-VpnConnectionIPsecConfiguration -ConnectionName $connection -AuthenticationTransformConstants SHA256128 -CipherTransformConstants AES128 -DHGroup Group14 -EncryptionMethod AES128 -IntegrityCheckMethod SHA256 -PFSgroup PFS2048 -Force

Hogy néz ki mindez, ha Intune-ból akarjuk kiküldeni az IPSec policyt? Nos, elsőre nem feltétlenül egyértelmű, hogy a fenti parancsban definiált értékek hol vannak az Intune policyban:

Hogy ne kelljen sokat keresgélni, tesztelgetni, itt egy működő beállítás:

IKE Security Association Parameters

  • Encryption algorithm: AES-128
  • Integrity check algorithm: SHA2-256
  • Diffie-Hellman group: 14

Child Security Association Parameters

  • Cipher transform algorithm: CBC-AES-128
  • Authentication transform alorithm: HMAC-SHA256-128
  • Perfect forward secrecy (PFS) group: Use parent Diffie-Hellman group

USB-adathordozók kontrollálása

Posted on by
Reply

Régi-régi igény a vállalatoknál, hogy az USB-eszközket kontroll alatt tartsák, megakadályozva az esetleges adatszivárgást. Erre jó választ ad az Intuneban is megtalálható Device Control funckió. Ugyanezt tudja biztosítani Group Policy segítségével is.

A Windows 10 21H1-gyel érkezett meg az “Apply layered order of evaluation for Allow and Prevent device installation policies across all device match criteria” GPO-beállítás, ami lehetővé teszi, hogy ne csak szimpla tiltás-engedélyezés legyen, hanem kicsit granulárisabban. Például hogy tiltsunk minden USB-adathordozót, de tudjunk kivételeket is felvenni. A gyakorlati példában ezt fogom bemutatni.

Az alábbi flow mutatja a layered policy működését:

Ahogy látható, a Device Instace ID a legerősebb, ez jelenti magát az adott USB-eszközt. Ilyen példa a USBSTOR\DISK&VEN_KINGSTON&PROD_DTR30G2&REV_PMAP\001A92053F1CBF9161021EF9&0

Ezt az ID-t látjuk, ha a Device Managerben megnézzük az eszköz DeviceInstancePath értékét.

A sorrendben következő a Device ID, ami már általánosabb. Ezt a Compatible IDs kiválasztásával kérdezhetjük le

A gyakorlati példánkhoz elég ez a két érték. Most lássuk, hogyan valósítható meg Intune-managed gépeken esetén, hogy alapból tiltsunk minden USB-adathordozót, de specifikus eszközöket mégis engedélyezzünk.

Első lépésben engedélyeznünk kell az “”Apply layered order of evaluation for Allow and Prevent device installation policies across all device match criteria” beállítást.

Ezt egy Custom OMA-URI beállítással tudjuk megtenni:

OMA-URI: ./Device/Vendor/MSFT/Policy/Config/DeviceInstallation/EnableInstallationPolicyLayering

Data type: string

Value: <enabled/><Data id=”AllowDenyLayered” value=”1″/>

Következő lépésben hozzunk létre egy új Attack Surface Reduction profilt:

https://endpoint.microsoft.com/#blade/Microsoft_Intune_Workflows/SecurityManagementMenu/asr

Válasszuk a Windows 10 or later és Device Control kategóriát

A policyben állítsuk be a “Block hardware device installation by device identifiers” résznél a következő értékeket:

USBSTOR\Disk

USBSTOR\RAW

Evvel elértük, hogy minden USB-adathordozó tiltásra kerül. A felhasználók ezt látják majd, ha adathordozót csatlakoztatnak:

Illetve a gépen a C:\Windows\INF\setupapi.dev.log fileban is logolja:

A következő lépésben tudjuk felvenni az adott USB-adathordozók egyedi azonosítóit, amiket szeretnénk engedélyezni:

A policyben állítsuk be a “Allow hardware device installation by device instance identifiers” résznél a kívánt értékeket:

A policy frissülése után megnézhetjük, hogy az értékek bekerültek-e a registrybe:

Computer\HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\PolicyManager\current\device\DeviceInstallation

Innentől kezdve csak a policyben meghatározott DeviceInstanceID-jú USB-eszközöket lehet használni.

A fenti beállítások természetesen nem értntik az egyéb USB-eszközöket, tehát billentyűzet/egér/nyomtató stb ugyanúgy működő marad.

Összefoglalva: mind Intune beállításokkal, mind klasszikus GPO-beállításokkal megoldható az USB-adathordozók granuláris kezelése.

Windowsupdate – automatic update és reboot opciók menedzselése

Posted on by
Reply

A Microsoft Endpoint Managerrel (régi nevén Intune) szabályozhatjuk a windows frissítések telepítését.

Az update és reboot mindig is küzdés volt a felhasználók és adminok között: “munka közben indult újra a gépem”, “frissítéskor csak teker és nem tudok dolgozni”, csak hogy pár panaszt említsünk. Sok esetben ezt a problémát a rosszul beállított update policy okozza.

Nézzük, hogy a MEM-ben milyen lehetőségeink vannak. A cikkben most csak az update telepítés és reboot részre térek ki, a többi opcióra nem.

Ha megnyitjuk a Windows 10 update ring-et, a következő beállításokat látjuk az User Experince Settings / Automatic update behavior résznél:

Az egyes beállítások részletezése:

  • Notify download: letöltés és telepítés előtt figyelmezteti a felhasználót, akinek kézzel kell elvégeznie a műveleteket.
  • Auto install at maintenance time: a maintenance időben letölti és telepíti a frissítéseket, kivéve ha a felhasználó használja a gépet, vagy pl. nincs töltőre dugva. A maintenance időt az Active hours beállítással adhatjuk meg (pl. 8-17 óra között nincs automatikus letötlés és telepítés-restart). Az újraindításhoz kéri a felhasználó engedélyét, ha ez nem történik meg 7 napig, utána magától újraindul.
  • Auto install and restart at maintenance time: hasonló az előző beállításhoz, csak itt a telepítés után automatikus restart következik (ha az eszköz nincsen használva). Az Active Hours megadásával a reboot itt is kontrollálható. A nem menedzselt eszközökhöz ez az alapbeállítás: telepítés után auto restart, ha nem hasznáják a gépet.
  • Auto install and restart at scheduled time: definiálhatjuk a telepítés napját-idejét. A telepítést követően elindul egy 15 perces visszaszámláló, amit a felhasználó elhalaszthat. Alapértelmezetten hajnali 3-kor telepít.
  • Auto install and reboot without end-user control: a frissítések letöltése és telepítése automatikusan megtörténik. Amikor az eszköz nincs használatban, a reboot is követi. Ennél az opciónál a felhasználónak csak read-only joga van a beállítási ablakon.
  • Reset to default: visszaállítja alaphelyzetre az auto update beállításokat

A fenti beállításokból kiválasztható a szervezet igényeinek megfelelő update mechanizmus.

A következőkben tekintsük át, hogy milyen figyelmeztetési lehetőségek vannak, a felhasználók felé.

Telepítés után, ha újraindításra van szükség, egy felbukkanó pop-uppal jelzi a rendszer. Ez a figyelmezetés 25 mp után eltűnik, és csak a kis ikon marad az óra mellett:

Amennyiben azt szeretnénk, hogy ez a figyelmeztetés megmaradjon és a felhasználónak kelljen nyugtáznia, kapcsoljuk be a Require user approval to dismiss restart notification részt a policyben:

Szintén egy hasznos funkció, ha a felhasználó figyelmét felhívjuk a közelgő kötelező újraindításra. Evvel lehetőséget adunk, hogy reboot előtt elmentse a megnyitott munkáit. A következő figyelmeztetéseket tudjuk megjeleníteni:

Azaz hogy az újraindulás előtt 4 órával fedobjon egy figyelmeztető üzenetet a felhasználónak, 30 perccel előtte pedig már egy elnyomhatatlan figyelmeztetés jelenik meg, visszaszámolással. Természetesen ezeket az értékeket állíthatjuk.

A frissítések telepítését és a gépek kötelező újraindítását kezelhetjük a Deadline beállításokkal is. Ennek lényege, hogy meghatározzuk, mikor kerüljenek fel az update-ek és mikor történjen az újraindítás.

A deadline a frissítés megjelenésétől számítja a megadott napokat. A fenti példa alapján, ha 10-én jön ki a frissítés a Microsoft Update-re, akkor legkésőbb 3 nap múlva automatikusan telepíti és megpróbálja az újraindítást is, ha az eszköz nincsen használatban. Ha definiáljunk Grace Period értéket, akkor annak értékével halasztja. Ez különösen hasznos, ha a felhasználó pl. szabadságról tér vissza, és így kap időt, hogy a telepítés-újraindítás kontrolláltan, pl. másnap történjen.

A deadline beállításokkal egy sokkal szorosabb frissítési ütemet tudunk kialakítani, mint az első részben taglalt beállításokkal. Amennyiben ezt a módszert választjuk, ne felejtsük el a Quality update deferral period (days) és Feature update deferral period (days) értékeket 0-ra tenni, különben policy conflict keletkezhet.

A deadline esetében max 30 napot határozhatunk meg.

Ajánlott konfiguráció: itt tennék egy szubjektív ajánlást, hogyan érdemes beállítani a teljes policyt:

  • Quality update deferral period (days): 7 nap. Így egy hétig nem ajánlja fel a frissítés telepítését, az IT addig tudja tesztelni a patch-et
  • Automatic update behavior: Auto install at maintenance time. A nem aktív időben a frissítések települnek és megjelennek a reboot kérő üzenetek, 7 napig. 7 nap után kötelező lesz a reboot, amiről figyelmeztetéseket jelenít meg.
  • Active hours start: 8 AM
  • Active hours end: 4 PM
  • Restart checks: Allow. Ha alacsony az akku töltöttsége, vagy presenting módban van a gép, akkor nem indul újra.
  • Require user approval to dismiss restart notification: Enabled. A felhasználónak kézzel kell leokéznia a pop-upot, evvel is tudatosítva benne, hogy a gépe újraindításra vár.
  • Remind prior to requried auto-restart with dismissible reminder: 8 óra
  • Remind prior to requried auto-restart with permament reminder: 1 óra
  • Change notification update level: Use the default Windows Update notifications

Összefoglalva: az update ring beállításkészlettel megtalálhatjuk a középutat a frissítések telepítése és felhasználói élmény negatív befolyásolása között.

M365 Enterprise és SMB csomagok összehasonlító táblázatok

Posted on by
Reply

Sokszor nemcsak az ügyfelek, de a tanácsadók is elveszettek lehetnek, hogy melyik M365 csomagban milyen szolgáltatás szerepel, milyen limitációkkal stb.

Az alábbi két táblázat hasznos lehet, hogy eligazodjuk a “rengetegben”

M365 Enterprise csomagok összehasonlító táblázat (PDF)

modern-work-user-subscription-plan-comparison-for-enterpriseDownload

M365 SMB csomagok összehasonlító táblázat (PDF)

microsoft-365-business-plan-comparison-for-smbDownload

OneDrive- hozzáférés megtagadva

Posted on by
Reply

Egy gyors esetleírás.

Környzetet: a felhasználók használják az OneDrive-ot, és a Desktop/Documents/Pictures mappa is oda van irányítva (lásd cikk: OneDrive mint felhasználói backup | Zoltan Istvanffy’s IT Blog (istvanffyzoltan.com)

A gépek Microsoft Endpoint Management-tel (Intune) menedzseltek, Windows Information Protection policy beállítva.

Hibajelenség: nem lehet új file-t létrehozni az OneDrive folderekben, hozzáférés megtagadva hibaüzenettel.

Megoldás:

A WIP-policyben meghatározott Data Recover Agent tanúsítványa lejárt.

Cseréljük ki a DRA tanúsítványt, és újra működőképes lesz az OneDrive.

Letöltés blokkolása Cloud App Securityvel

Posted on by
Reply

Amennyiben rendelkezünk Azure AD P1 vagy P2 és Cloud App Security licensszel (Microsoft E5, EMS E5 vagy Microsoft E5 Security), könnyen megakadályozhatjuk céges adatok letöltését, ha nem menedzselt eszközről lép be.

Nem menedzselt eszköz: ami nincs az Intune-ba bevonva vagy nem Hybrid Azure AD-tag.

A példában az Exchange Online-nál fogjuk beállítani, tehát ha nem menedzselt eszköről lépünk be az OWA-ra, akkor kötelező lesz az Azure MFA hitelesítés és nem fogjuk tudni a mellékleteket a gépre letölteni. Így megmarad a lehetőség az OWA elérésre bármilyen gépről, de csak “read-only” módban.

Azure AD Conditional Access beállítása:

Navigáljunk el a conditional access portálra és hozzunk létre egy új szabályt:

https://portal.azure.com/#blade/Microsoft_AAD_IAM/ConditionalAccessBlade/Policies

A Conditions részrél állítsuk be a Client app / Browser-t

Az Access Control / Grant mezőnél pedig pipáljuk be a “Require multi-factor authentication” opciót

Az Access Control / Session résznél kapcsoljuk be az “Use Conditional Access App Control” és use custom policy… opciót

Cloud App Security beállítása:

Navigáljunk el az MCAS portálra: https://portal.cloudappsecurity.com/

A Control / Policies résznél készítsünk egy új Session policyt

A session control type-nál állítsuk át “control file download (with inspection)”-ra és az Appnál vegyük fel a Microsoft Exchange Online-t

(Ha megnézzük a szabályt, látszik, hogy ha a Device Tag nem egyenlő “intune compliant” vagy “Hybrid Azure AD joined”, akkor lép érvénybe)

Az Action résznél állítsuk be a block-ot

A szabály elmentése után teszteljünk:

Ha nem menedzselt gépről lépünk be az OWA-ra, ez az üzenet fogad minket:

Továbblépve, ha megpróbálunk egy mellékletet letölteni a levelezésből, a következő üzenetet kapjuk:

A policy kiterjeszthető több alkalmazásra is, pl. Teams / Sharepoint, egyéb üzleti alkalmazások.

Távollévő gépek menedzselése

Posted on by
Reply

A céges hálózattól tartósan távollévő gépek menedzselésének kérdése nem újkeletű, több szervezetnek is okozott már fejfájást. Illetve új problémaként felmerült a COVID miatt, hogy sok felhasználó hirtelen távolról kényszerült dolgozni az eszközével.

Mit értünk tartósan távollévő gép alatt?

Olyan laptopokat, amik a felhasználási sajátosságok miatt alig lépnek be a céges hálózatba, legyen az irodai hálózat vagy VPN. Néhány opció:

  • orvoslátogatók laptopjai
  • biztosítási és egyéb utazó ügynökök laptojai
  • alvállakozók, akik kapnak céges laptopot, de nincs igény a belső hálózat elérésre

Kiemelten jó példa a gyógyszeripari cégeknék az orvoslátogatók gépei. Kapnak céges eszközt, használják a levelezést, a munkájukat tudják végezni, az irodába nagyjából sosem mennek be, hálózatra nem csatlakoznak fel.

Mi történik menedzsment szempontból egy ilyen géppel?

  • 30 nap után megszűnik a domaines secure channel (“kiesik a domainből”)
  • Az előírt group policyk nem futnak le, nem frissülnek
  • A startup és logon scriptek nem futnak le
  • A wsus/sccm által kezelt frissítések nem települnek a gépre
  • Legrosszabb esetben akár az antivirus definiciós frissítések sem jutnak le a gépre (volt példa, ahol tiltották a frissítések internetről letöltését is)

Amint látjuk, ez a helyzet kellemetlen az IT-számára, hiszen ezen gépek felett gyakorlatilag elveszítette a kontrollt. A menedzselhetőség innetől a felhasználótól függ (mikor megy be az eszközzel céges hálózatra, mikor kapcsolja be a VPN-t stb…és milyen rossz az, mikor a céges bérelt vonalon kezd töltődni az akár több GB-os SCCM-csomag 🙂 ) A kockázat pedig adott: nem kerülnek fel a biztonsági frissítések, az IT nem értesül a gépet érintő incidensekről és lehetne sorolni.

Mi lehet a megoldás?

Toljuk ki a menedzsment határait a céges hálózaton kívülre! Gondoljuk át, hogy milyen nagyszerű lenne, ha az IT-felügyelet az Interneten kereszül történhetne! Az orvoslátogatók gépeinek üzemeltetői repesnének az örömtől.

Csináljunk Hybrid Azure AD joint, vagy akár Azure AD joint, Microsoft Endpoint Management (MEM) felügyeleti eszközzel párban. Evvel a következő lehetőséghez juthatunk (maradva az orvoslátogatók gépeinél)

  • Az on-premise domain gépet beléptetjük az AzureAD-ba is (ezt nevezzük Hybrid Azure AD joinnak. Innenől az AAD “ismeri” a gépobjektumot
  • Nincs secure channel hiba többé
  • A MEM segítségével teljeskörűen tudjuk menedzselni a gépet: frissítések telepítése, scriptek futtatása, VPN, emailfiók konfigurációk leküldése, megfelelőségek ellenőrzése (pl. lemeztitkosítás be van-e még kapcsolva), központi szoftvertelepítések
  • Jelentések-leltár futtatása a távoli gépeken, folyamatos státuszriportolással

Láthatjuk, hogy evvel a megoldással visszakapjuk az elveszett kontrollt a távollévő gépek felett.

Összegzés: érdemes átgondolni a kliensmenedzsment kérdését és válaszolni az új igényekre (céges hálózat nélkül is a kontroll megléte), erre az AzureAD és MEM egy jó alternatíva lehet.

Tippek a helpdesk terhelésének csökkentésére

Posted on by
Reply

Az utóbbi fél évben bekövetkezett távoli munkavégzés az IT-helpdeskek terhelését jelentősen megnövelte. Nézzünk pár tippet, amivel a felhasználók produktivitása is megmarad, a helpdeskről is levesz terheket és a működési költséget is csökkenti.

  1. Elfelejett jelszavak problémája

Nagyon sok szervezetnél jelent kihívást, hogy kezeljék az elfelejettett felhasználói jelszavak resetelését. Ez mindenkinek rossz, hiszen a felhasználó addig nem tud dolgozni, az IT-helpdesknek pedig ismétlődő unalmas feladat. További kérdés, hogy a megváltoztatott jelszót hogyan juttatják el a felhasznónak (SMS, vagy magán emailcímre küldéssel? Ez vajon bizonságos?)

Azure AD Self-Service password reset szolgáltatással a felhasználó tud jelszót resetelni saját magának is, biztonságos módon (kétfaktoros hitelesítéssel)

A felhasználó pedig ezt látja:

Állítsuk be ezt szolgáltatást és oktassuk le a felhasználóknak. Megfelelő kommunikáció után akár 80%-kal is csökkenhet az “elfelejettem a jelszavam, resetet kérnék” esetek száma.

2. Windows upgrade-ek zavartalansága

A Windows 10-hez évente kétszer érkezik nagyobb frissítőcsomag, melyek telepítése minden esetben nagyon ajánlott. Érdemes up-to-date tartani az operációs rendszereket, mind a biztonsági, mind az egyéb funkcionális frissítések miatt.

Amennyiben viszont nem-Microsoft végpontvédelmi megoldás van használatban, az okozhat gondot a frissítési folyamatnál, ezáltal megint csak jelentős mennyiségű helpdesk-ticketet generálva.

Elkerülhető ez a probléma és a hosszas előzetes kompatibilitási tesztelések, ha végpontvédelmi megoldásnak a Microsoft Defender ATP-t használjuk. Az MDATP-vel nem csak a klasszikus vírusvédelmi megoldást lehet bevezetni, hanem a különböző fejlett támadási formákat is képes detektálni és megállítani.

3. Bátorítsuk a BYOD-ot!

Megint csak egy jellemző problémakör tud lenni az eszközök menedzselése. Új felhasználó érkezik a céghez, laptopra van szüksége, beállításokra, jogosultságokra stb. A gép átvételéhez személyesen kell megjelennie az irodában, várnia, ez mind-mind időveszteség.

Ezek csökkentésére egy megoldás lehet a BYOD-eszközök használata. Amennyiben van mód rá, érdemes bátorítani a felhasználókat hogy használják a meglévő eszközeiket (számítógép, mobil stb), ezáltal “önjáró” módon beálltani a munkakörnyezetét.

A Microsoft Endpoint Managerrel (régi nevén Intune), egy robosztus, biztonságos keretrendszer alakítható ki az ilyen eszközöknek (és természetesen a vállalati eszközöknek is). A MEM-mel biztosítható az eszközök felügyelet alá vonása (enrollment), különböző alap-alkalmazásokat lehet automatikusan telepíteni, VPN-beállítások leküldeni, különféle biztonsági beállításokat előírni.

A fenti környezetek kialakítása nem egyszerű, egylépéses feladat, viszont megéri a befektetést.