Megosztás a következőn keresztül:

Migrálás Office 365-höz készült Microsoft Defender – 3. fázis: Előkészítés


1. fázis: Előkészítés.
1. fázis: Előkészítés		 2. fázis: Beállítás.
2. fázis: Beállítások		 3. fázis: Előkészítés.
3. fázis: Bevezetés
Ön itt van!

Üdvözli a 3. fázis: Amigrálás előkészítése Office 365-höz készült Microsoft Defender! Ez a migrálási fázis a következő lépéseket tartalmazza:

  1. A biztonsági csapatok előkészítésének megkezdése
  2. (Nem kötelező) Próbafelhasználók mentesítése a meglévő védelmi szolgáltatás szerinti szűrés alól
  3. Hamisintelligencia hangolása
  4. Megszemélyesítés elleni védelem és postaláda-intelligencia hangolása
  5. A felhasználó által jelentett üzenetek adatainak használata a méréshez és a módosításhoz
  6. (Nem kötelező) További felhasználók hozzáadása a próbaüzemhez és iteráció
  7. A Microsoft 365-védelem kiterjesztése az összes felhasználóra, és az SCL=-1 levelezési szabály kikapcsolása
  8. MX rekordok váltása

1. lépés: A biztonsági csapatok előkészítésének megkezdése

Ha a szervezet biztonsági reagálási csapattal rendelkezik, itt az ideje, hogy elkezdje integrálni a Office 365-höz készült Microsoft Defender a válaszfolyamatokba, beleértve a jegykezelő rendszereket is. Ez a folyamat önmagában egy teljes témakör, de néha figyelmen kívül hagyják. A biztonsági reagálási csapat korai bevonása biztosítja, hogy a szervezet készen álljon a fenyegetések kezelésére az MX rekordok közötti váltáskor. Az incidenskezelésnek jól fel kell készülnie a következő feladatok kezelésére:

Ha szervezete megvásárolta Office 365-höz készült Microsoft Defender 2. csomagot, meg kell ismerkednie az olyan funkciókkal, mint a Veszélyforrás-felderítő, a Speciális veszélyforrás-keresés és az Incidensek. A megfelelő képzésekért lásd: https://aka.ms/mdoninja.

Ha a biztonsági válaszért felelős csapat szűretlen üzeneteket gyűjt és elemez, konfigurálhat egy SecOps-postaládát a szűretlen üzenetek fogadására. Útmutatásért lásd: SecOps-postaládák konfigurálása a speciális kézbesítési szabályzatban.

SIEM/SOAR

Az SIEM/SOAR integrálásával kapcsolatos további információkért tekintse meg a következő cikkeket:

Ha a szervezet nem rendelkezik biztonsági reagálási csapattal vagy meglévő folyamatokkal, akkor most megismerkedhet a Office 365-höz készült Defender alapvető veszélyforrás-keresési és válaszfunkcióival. További információ: Fenyegetésvizsgálat és -reagálás.

RBAC-szerepkörök

A Office 365-höz készült Defender engedélyei szerepköralapú hozzáférés-vezérlésen (RBAC) alapulnak, és a Microsoft Defender portál engedélyek című szakasza ismerteti. Íme a fontos szempontok, amelyeket szem előtt kell tartani:

  • Microsoft Entra szerepkörök a Microsoft 365 összes számítási feladatához biztosítanak engedélyeket. Ha például hozzáad egy felhasználót a biztonsági rendszergazdához a Azure Portal, mindenhol biztonsági rendszergazdai engedélyekkel rendelkezik.
  • Email & Microsoft Defender portál együttműködési szerepkörei engedélyeket adnak a Microsoft Defender portálnak és a Microsoft Purview megfelelőségi portál. Ha például hozzáad egy felhasználót a biztonsági rendszergazdához a Microsoft Defender portálon, akkor csak a Microsoft Defender portálon és a Microsoft Purview megfelelőségi portál rendelkezik biztonsági rendszergazdai hozzáféréssel.
  • A Microsoft Defender portál számos funkciója Exchange Online PowerShell-parancsmagokon alapul, ezért szerepkörcsoporttagságra van szükség a Exchange Online megfelelő szerepköreiben (technikailag a szerepkörcsoportokban) (különösen a megfelelő Exchange Online PowerShellhez való hozzáféréshez). parancsmagok).
  • A Microsoft Defender portálon vannak olyan Email & együttműködési szerepkörök, amelyek nem rendelkeznek Microsoft Entra szerepkörökével, és fontosak a biztonsági műveletekhez (például az Előzetes verzió, a Keresés és a Végleges törlés szerepkör).

Az üzenetek közvetlenül a felhasználói postaládákból való letöltéséhez általában csak a biztonsági személyzet egy részhalmaza igényel további jogosultságokat. Ehhez egy további engedélyre van szükség, amellyel a Biztonsági olvasó alapértelmezés szerint nem rendelkezik.

2. lépés: (Nem kötelező) Mentesíti a próbafelhasználókat a meglévő védelmi szolgáltatás szerinti szűrés alól

Bár ez a lépés nem szükséges, érdemes úgy konfigurálni a próbafelhasználókat, hogy a meglévő védelmi szolgáltatás ne szűrjenek. Ez a művelet lehetővé teszi, hogy Office 365-höz készült Defender kezelje a próbafelhasználók összes szűrési és védelmi feladatát. Ha nem mentesíti a próbafelhasználókat a meglévő védelmi szolgáltatás alól, Office 365-höz készült Defender hatékonyan csak a másik szolgáltatásból származó hiányzásokra (a már szűrt üzenetek szűrésére) működik.

Megjegyzés:

Erre a lépésre kifejezetten szükség van, ha a jelenlegi védelmi szolgáltatása biztosítja a hivatkozások körbefuttatását, de szeretné tesztelni a Biztonságos hivatkozások funkciót. A hivatkozások kettős körbefuttatása nem támogatott.

3. lépés: Hamisintelligencia hangolása

Tekintse meg a hamis felderítés megállapításait , hogy megtudja, mi engedélyezett vagy tiltott hamisításként, és hogy meg kell-e határoznia, hogy felül kell-e bírálnia a rendszer hamisítási ítéletét. Előfordulhat, hogy az üzleti szempontból kritikus e-mailek egyes forrásai helytelenül konfigurált e-mail-hitelesítési rekordokat tartalmaznak a DNS-ben (SPF, DKIM és DMARC), és előfordulhat, hogy felülbírálásokat használ a meglévő védelmi szolgáltatásban a tartományi problémák maszkolásához.

A hamis felderítés a DNS megfelelő e-mail-hitelesítési rekordjai nélkül képes menteni az e-maileket a tartományokból, de a funkciónak néha segítségre van szüksége a helyes hamisítás és a helytelen hamisítás megkülönböztetésében. Összpontosítson az alábbi típusú üzenetforrásokra:

  • Az összekötők fokozott szűrésében meghatározott IP-címtartományokon kívül eső üzenetforrások.
  • A legtöbb üzenetet tartalmazó üzenetforrások.
  • Olyan üzenetforrások, amelyek a legnagyobb hatással vannak a szervezetre.

A hamis intelligencia végül finomhangolja magát a felhasználó által jelentett beállítások konfigurálása után, így nincs szükség tökéletességre.

4. lépés: A megszemélyesítés elleni védelem és a postaláda-intelligencia hangolása

Miután elegendő ideje volt a megszemélyesítés elleni védelem eredményeinek megfigyelésére a Ne alkalmazzon semmilyen művelet módot, egyenként bekapcsolhatja az egyes megszemélyesítés elleni védelmi műveleteket az adathalászat elleni szabályzatokban:

  • Felhasználói megszemélyesítés elleni védelem: Karanténba helyezi az üzenetet a Standard és a Strict esetében is.
  • Tartományszemélyesítés elleni védelem: Karanténba helyezi az üzenetet a Standard és a Strict esetében is.
  • Postaládaintelligencia-védelem: Helyezze át az üzenetet a címzettek Levélszemét Email mappáiba a Standard számára; Karanténba helyezi a Strict (Szigorú) üzenet üzenetét.

Minél hosszabb ideig figyeli a megszemélyesítés elleni védelem eredményeit anélkül, hogy az üzenetekre lépne, annál több adatot kell azonosítania, lehetővé teszi vagy letiltja az esetleg szükséges elemeket. Érdemes lehet késleltetést használni az egyes védelem bekapcsolása között, amely elég jelentős ahhoz, hogy lehetővé tegye a megfigyelést és a kiigazítást.

Megjegyzés:

Fontos ezeknek a védelemnek a gyakori és folyamatos monitorozása és finomhangolása. Ha téves pozitívra gyanakszik, vizsgálja meg az okot, és csak szükség szerint használjon felülbírálásokat, és csak az azt igénylő észlelési funkcióhoz.

Postaláda-intelligencia finomhangolása

Bár a postaláda-intelligencia úgy van konfigurálva, hogy ne tegyen műveletet a megszemélyesítési kísérletnek ítélt üzeneteken, be van kapcsolva, és megtanulja a próbafelhasználók e-mail-küldési és -fogadási mintáit. Ha egy külső felhasználó kapcsolatba lép az egyik próbafelhasználóval, az adott külső felhasználótól érkező üzeneteket a rendszer nem azonosítja megszemélyesítési kísérletként a postaláda-felderítés által (így csökkentve a téves riasztásokat).

Ha készen áll, az alábbi lépésekkel engedélyezheti a postaláda-intelligencia számára, hogy megszemélyesítési kísérletként észlelt üzenetekre reagáljon:

  • A Szokásos védelmi beállításokkal rendelkező adathalászat elleni házirendben módosítsa a Ha a postaláda-intelligencia megszemélyesített felhasználót észlel beállítást az Üzenet áthelyezése a címzettek Levélszemét Email mappáiba beállításra.

  • A Szigorú védelmi beállításokat tartalmazó adathalászat elleni szabályzatban módosítsa a Ha a postaláda-intelligencia észleli és megszemélyesíti a felhasználót beállítást az üzenet karanténba helyezésére.

A szabályzatok módosításához lásd: Adathalászat elleni házirendek konfigurálása Office 365-höz készült Defender.

Miután megfigyelte az eredményeket, és végrehajtotta a módosításokat, folytassa a következő szakaszsal a felhasználói megszemélyesítés által észlelt üzenetek karanténba helyezése érdekében.

Felhasználói megszemélyesítés elleni védelem hangolása

A Standard és a Szigorú beállításokon alapuló mindkét adathalászat elleni házirendben módosítsa az If a message is detect as user megszemélyesítés értékét az Üzenet karanténba helyezése értékre.

Tekintse meg a megszemélyesítési megállapítást , és nézze meg, hogy mi van letiltva felhasználói megszemélyesítési kísérletként.

A szabályzatok módosításához lásd: Adathalászat elleni házirendek konfigurálása Office 365-höz készült Defender.

Miután megfigyelte az eredményeket, és végrehajtotta a módosításokat, folytassa a következő szakaszsal a tartomány megszemélyesítése által észlelt üzenetek karanténba helyezése érdekében.

Tartomány megszemélyesítés elleni védelmének finomhangolása

A Standard és a Szigorú beállításokon alapuló adathalászat elleni házirendekben módosítsa az If a message is detect as domain megszemélyesítés értékét Az üzenet karanténba helyezése értékre.

Tekintse meg a megszemélyesítési megállapítást , és nézze meg, hogy mi van letiltva tartományszemélyesítési kísérletként.

A szabályzatok módosításához lásd: Adathalászat elleni házirendek konfigurálása Office 365-höz készült Defender.

Figyelje meg az eredményeket, és végezze el a szükséges módosításokat.

5. lépés: A felhasználó által jelentett üzenetekből származó adatok használata a méréshez és a módosításhoz

Amikor a próbafelhasználók hamis pozitív és hamis negatívumokat jelentenek, az üzenetek a Microsoft Defender portál Beküldések lapjánakFelhasználó jelentett lapján jelennek meg. A tévesen megadott üzeneteket elemzés céljából jelentheti a Microsoftnak, és az információk segítségével szükség szerint módosíthatja a próbaszabályzatok beállításait és kivételeit.

Az alábbi funkciókkal monitorozhatja és iterálhatja a Office 365-höz készült Defender védelmi beállításait:

Ha a szervezet külső szolgáltatást használ a felhasználók által jelentett üzenetekhez, ezeket az adatokat integrálhatja a visszajelzési hurokba.

6. lépés: (Nem kötelező) További felhasználók hozzáadása a próbaüzemhez és iteráció

A problémák megkeresése és kijavítása során további felhasználókat adhat hozzá a próbacsoportokhoz (és ennek megfelelően mentesítheti ezeket az új próbafelhasználókat a meglévő védelmi szolgáltatás általi vizsgálat alól). Minél több tesztelést végez most, annál kevesebb felhasználói problémát kell kezelnie később. Ez a "vízesés" megközelítés lehetővé teszi a szervezet nagyobb részeinek finomhangolását, és időt biztosít a biztonsági csapatoknak, hogy alkalmazkodjanak az új eszközökhöz és folyamatokhoz.

  • A Microsoft 365 riasztásokat hoz létre, ha a vállalati szabályzatok engedélyezik a megbízható adathalász üzeneteket. Az üzenetek azonosításához a következő lehetőségek közül választhat:

    A lehető leghamarabb jelentse a microsoftos téves riasztásokat rendszergazdai beküldésekkel, és a Bérlői engedélyezési/letiltási lista funkcióval konfigurálja a téves pozitívok biztonságos felülbírálásait.

  • Érdemes megvizsgálni a szükségtelen felülbírálásokat is. Más szóval tekintse meg azokat az ítéleteket, amelyeket a Microsoft 365 adott volna meg az üzeneteken. Ha a Microsoft 365 a helyes ítéletet jeleníti meg, akkor a felülbírálás szükségessége jelentősen csökken vagy megszűnik.

7. lépés: A Microsoft 365-védelem kiterjesztése az összes felhasználóra, és az SCL=-1 levelezési szabály kikapcsolása

Ha készen áll arra, hogy az MX rekordokat a Microsoft 365-re mutasson, végezze el az ebben a szakaszban ismertetett lépéseket.

  1. A próbaszabályzatok kiterjesztése a teljes szervezetre. Alapvetően különböző módokon lehet kiterjeszteni a szabályzatokat:

    • Használjon előre beállított biztonsági szabályzatokat, és ossza el a felhasználókat a Standard védelmi profil és a Szigorú védelmi profil között (győződjön meg arról, hogy mindenkire vonatkozik). Az előre beállított biztonsági szabályzatok a létrehozott egyéni szabályzatok vagy az alapértelmezett házirendek előtt lépnek életbe. Az egyes próbaszabályzatokat törlés nélkül is kikapcsolhatja.

      Az előre beállított biztonsági szabályzatok hátránya, hogy a létrehozásuk után nem módosíthatja a fontos beállítások nagy részét.

    • Módosítsa a próbaidőszak során létrehozott és módosított szabályzatok hatókörét úgy, hogy az összes felhasználót (például az összes címzettet az összes tartományban) tartalmazza. Ne feledje, hogy ha ugyanarra a felhasználóra (egyénileg, csoporttagság vagy e-mail-tartomány alapján) több, azonos típusú házirend (például adathalászat elleni szabályzat) vonatkozik, akkor csak a legmagasabb prioritású (legalacsonyabb prioritású) házirend beállításait alkalmazza a rendszer, és a feldolgozás leáll az adott házirendtípus esetében.

  2. Kapcsolja ki az SCL=-1 levelezési szabályt (törlés nélkül is kikapcsolhatja).

  3. Ellenőrizze, hogy a korábbi módosítások életbe léptek-e, és hogy a Office 365-höz készült Defender mostantól megfelelően engedélyezve van-e az összes felhasználó számára. Ezen a ponton a Office 365-höz készült Defender összes védelmi funkciója jogosult az összes címzett levelezésére reagálni, de a meglévő védelmi szolgáltatás már megvizsgálta az e-maileket.

Ebben a szakaszban szüneteltetheti a nagyobb léptékű adatrögzítést és -finomhangolást.

8. lépés: Az MX rekordok váltása

Megjegyzés:

  • A tartomány MX rekordjának módosítása akár 48 órát is igénybe vehet, amíg a módosítások propagálása az interneten keresztül megtörténik.
  • Javasoljuk, hogy csökkentse a DNS-rekordok TTL-értékét a gyorsabb válasz és a lehetséges visszaállítás érdekében (ha szükséges). Az átváltás befejezése és ellenőrzése után visszaállíthatja az eredeti TTL-értéket.
  • Érdemes megfontolni a ritkábban használt tartományok megváltoztatását. A nagyobb tartományokra való áttérés előtt szüneteltetheti és figyelheti a funkciót. Ha mégis ezt teszi, akkor is győződjön meg arról, hogy az összes felhasználóra és tartományra vonatkoznak szabályzatok, mivel a másodlagos SMTP-tartományok a házirendalkalmazás előtt elsődleges tartományokra vannak feloldva.
  • Egyetlen tartomány több MX rekordja technikailag működik, így lehetővé válik a felosztásos útválasztás, feltéve, hogy követte az ebben a cikkben szereplő összes útmutatást. Pontosabban győződjön meg arról, hogy a házirendek minden felhasználóra vonatkoznak, hogy az SCL=-1 levélforgalmi szabály csak azokra a levelekre legyen alkalmazva, amelyek áthaladnak a meglévő védelmi szolgáltatáson a 3. lépés: Az SCL=-1 levelezési szabály karbantartása vagy létrehozása című szakaszban leírtak szerint. Ez a konfiguráció azonban olyan viselkedést vezet be, amely sokkal nehezebbé teszi a hibaelhárítást, ezért általában nem javasoljuk, különösen hosszabb ideig.
  • Az MX rekordok közötti váltás előtt ellenőrizze, hogy az alábbi beállítások nincsenek-e engedélyezve a védelmi szolgáltatásból a Microsoft 365-be irányuló bejövő összekötőn. Az összekötőhöz általában az alábbi beállítások közül egy vagy több van konfigurálva:
    • és megköveteli, hogy a partner által a hitelesítéshez használt tanúsítvány tulajdonosneve Office 365 egyezzen ezzel a tartománynévvel (RestrictDomainsToCertificate)
    • Elutasíthatja az e-maileket, ha nem ebből az IP-címtartományból (RestrictDomainsToIPAddresses) érkeznek. Ha az összekötő típusa Partner, és a beállítások bármelyike be van kapcsolva, az MX rekordok közötti váltás után a tartományokba történő összes levélkézbesítés sikertelen lesz. A folytatás előtt le kell tiltania ezeket a beállításokat. Ha az összekötő egy hibrid környezethez használt helyszíni összekötő, nem kell módosítania a helyszíni összekötőt. A partnerösszekötő meglétét azonban továbbra is ellenőrizheti.
  • Ha a jelenlegi levelezési átjárója is biztosítja a címzettek ellenőrzését, érdemes lehet ellenőrizni, hogy a tartomány mérvadóként van-e konfigurálva a Microsoft 365-ben. Ez megakadályozhatja a felesleges visszapattanó üzeneteket.

Ha készen áll, váltsa át a tartományok MX rekordját. Az összes tartományt egyszerre migrálhatja. Azt is megteheti, hogy először a ritkábban használt tartományokat migrálja, majd később a többit.

Nyugodtan szüneteltetheti és értékelheti itt bármikor. Ne feledje azonban, hogy ha kikapcsolja az SCL=-1 levelezési szabályt, a felhasználók két különböző szolgáltatásokat használhatnak a téves pozitív értékek ellenőrzéséhez. Minél hamarabb tud egységes élményt nyújtani, annál boldogabbak lesznek a felhasználók és az ügyfélszolgálati csapatok, amikor egy hiányzó üzenettel kell elhárítaniuk a hibát.

Következő lépések

Gratulálunk! Befejezte a migrálást a Office 365-höz készült Microsoft Defender! Mivel követte az áttelepítési útmutató lépéseit, az első néhány nap, amikor a levelek közvetlenül a Microsoft 365-be érkeznek, sokkal zökkenőmentesebbnek kell lenniük.

Most megkezdi a Office 365-höz készült Defender normál működését és karbantartását. Monitorozza és watch azokat a problémákat, amelyek hasonlóak a próbaüzem során tapasztaltakhoz, de nagyobb léptékben. A hamisintelligencia-megállapítás és a megszemélyesítési megállapítás a legpontosabban hasznos, de fontolja meg a következő tevékenységek rendszeres előfordulását: