ஒருவர் தொலைபேசியை இழக்கிறார், டிக்கெட் VPN உடைந்தது என வருகிறது. இந்த அமைப்பு இருமுறை தவறு: கணக்கு இன்னும் உள்ளது, மேலும் நுழைவாயில் இன்னும் அடையாள வழங்குநரை நம்புகிறது, எனவே உடைந்த ஒரே பகுதி நபரிடம் இல்லாத ஒரு காரணி மட்டுமே. செயலிழப்பாக அல்ல, மீட்பாகக் கருதுங்கள்: கோரிக்கையாளரைச் சரிபார்க்கவும், மாற்றீட்டைப் பதிவு செய்யவும், தொலைந்த முறையை நீக்கவும், பிறகு கணக்கு வேலை செய்கிறது என நிரூபிக்கவும். இவை அனைத்தும் இழப்புக்கு முன்பே திட்டம் எழுதப்பட்டதைக் கருதுகின்றன, ஏனெனில் அழைப்பின் போது அதைக் கற்பனை செய்வதே MFA அனைவருக்கும் அணைக்கப்படும் பாதை.

படி 1: பதிவுசெய்யப்பட்ட காரணிகளை நினைவிலிருந்து அல்ல, பதிவிலிருந்து படிக்கவும்

முதல் கேள்வி எந்தச் சாதனம் தொலைந்தது என்பதல்ல, கணக்கு இன்னும் வேறு என்ன பயன்படுத்தலாம் என்பதே. ஒரு கணக்கில் கடவுச்சொல்லுடன் புஷ், நேர அடிப்படையிலான குறியீடு, வன்பொருள் விசை மற்றும் அச்சிடப்பட்ட மீட்புக் குறியீடுகள் இருக்கலாம், அவற்றில் ஒன்றை இழப்பது ஒரே ஒன்றை இழப்பதிலிருந்து முற்றிலும் வேறு நிகழ்வு. பயனரை நினைவில் வைக்கச் சொல்வதற்குப் பதிலாக அடையாள அமைப்பிலிருந்து முறைகளின் பட்டியலைப் படிக்கவும், Microsoft Entra வாடகையாளரில் வினவல் ஒரு வரி:

Get-MgUserAuthenticationMethod -UserId [email protected]

பிறகு கணக்கு இன்னும் வேலை செய்யும்போது மீட்புப் பதிவை எழுதுங்கள்: கணக்கு அடையாளங்காட்டி, பதிவுசெய்யப்பட்ட காரணிகள், மீட்புக் குறியீடுகள் எங்கே வாழ்கின்றன, யார் கோரிக்கையாளரைத் தனித்தனியாகச் சரிபார்க்க முடியும், கணக்கு எந்த அமைப்புகளை அடைகிறது. குழு ஏற்கனவே பயன்படுத்தும் பாதுகாக்கப்பட்ட சரக்கறையில் வைக்கவும், செயலில் உள்ள குறியீடுகளும் உள்ள குறிப்பில் ஒருபோதும் வைக்க வேண்டாம். அந்த ஐந்து புலங்கள் பீதியான அழைப்பை சரிபார்ப்புப் பட்டியலாக மாற்றுகின்றன, மேலும் NIST-இன் அங்கீகாரக் கருவி வாழ்க்கைச் சுழற்சி வழிகாட்டுதல் மீட்பை அடையாளச் சான்றின் பகுதியாகக் கருதுகிறது, அதிலிருந்து விலக்காக அல்ல.

சரிபார்ப்பு சேனலை தனிப் புலமாகப் பதிவு செய்யவும், ஏனெனில் மக்கள் தவிர்க்கும் பகுதி அதுவே. கேட்கும் நபரே தொலைபேசியைக் கட்டுப்படுத்தும்போது கணக்குடன் இணைக்கப்பட்ட தொலைபேசி எண் சுயாதீன சேனல் அல்ல.

படி 2: கோரிக்கையாளரை தோல்வியடையும் பாதைக்கு வெளியே சரிபார்க்கவும்

அடையாளச் சரிபார்ப்பை VPN, அஞ்சல் பெட்டி அல்லது தொலைந்த சாதனத்தைச் சார்ந்திராத சேனல் வழியாகச் செய்யுங்கள். மனிதவளப் பதிவின் எண்ணுக்கு மீள்அழைப்பு, அல்லது ஏற்கனவே அடைவில் உள்ள மேலாளருடன் நேருக்கு நேரச் சரிபார்ப்பு, இரண்டும் வேலை செய்கின்றன; மீட்பில் உள்ள கணக்கிலிருந்து அனுப்பப்படும் அரட்டைச் செய்தி வேலை செய்யாது. சரிபார்ப்பு நபரைப் பற்றியது, கணக்கைப் பற்றிய கேள்விகளுக்குப் பதிலளிக்கும் திறனைப் பற்றியது அல்ல, ஏனெனில் கணக்கு விவரங்கள் கசிகின்றன. யார் எப்போது கோரிக்கையைச் சரிபார்த்தார்கள் எனப் பதிவு செய்யவும், ஏனெனில் அடுத்த மதிப்பாய்வாளருக்கு இரண்டும் தேவைப்படும்.

கோரிக்கை அவசரத்துடனும் சரிபார்ப்பைத் தவிர்க்கும் அழுத்தத்துடனும் வரும்போது, அதுவே மெதுவாக வேண்டிய தருணம். மீட்பு மோசடி அவசரப்பட்டு உதவும் சக ஊழியரைப் போலவே தோன்றும்.

படி 3: மாற்றீட்டைப் பதிவு செய்யவும், பிறகு பழைய காரணியை நீக்கவும்

புதிய அங்கீகாரக் கருவியை வழக்கமான பதிவு ஓட்டத்தின் மூலம் பதிவு செய்யவும், நிர்வாக மாற்றுவழியில் ஒருபோதும் இல்லை. பிறகு தொலைந்த முறையை வெளிப்படையாக அகற்றவும், ஏனெனில் மாற்றீட்டைப் பதிவு செய்வது முந்தைய அங்கீகாரக் கருவியை யாரேனும் நீக்கும் வரை அதிகாரமளித்து வைக்கிறது. பழைய சாதனம் வேறொருவர் கையில் இருக்கக்கூடும் என்றால், அகற்றுவதை அவசரமாகக் கருதி மீட்புக்குப் பதிலாக நிகழ்வு செயல்முறையைப் பின்பற்றவும். அதே படியில் இருக்கும் அமர்வுகளை ரத்து செய்யவும், ஏனெனில் மாற்றத்திற்கு முன் உருவாக்கப்பட்ட அமர்வு அதை விட நீடித்திருக்கலாம்:

Revoke-MgUserSignInSession -UserId [email protected]

மற்ற அனைவருக்கும் காரணியை அகற்றுவது, அல்லது நுழைவாயிலின் சான்றிதழ்ச் சரிபார்ப்புகளைத் தளர்த்துவது, ஒருவரின் மீட்பை முழு வரிசைப்படுத்தலையும் தொடும் செயலிழப்புக்கு மாற்றுகிறது. மாற்றத்தை ஒற்றைக் கணக்கில் வைத்திருங்கள், சான்றுகள் பரந்த சமரசத்தைச் சுட்டினால் மேலே தெரிவிக்கவும். எந்தக் காரணி நீக்கப்பட்டது, எது அதை மாற்றியது என டிக்கெட்டில் குறிப்பிடவும்.

படி 4: கணக்கு இரு திசைகளிலும் வேலை செய்கிறது என நிரூபிக்கவும்

ஆதரிக்கப்படும் கிளையண்ட் வழியாக புதிய காரணியுடன் ஒருமுறை உள்நுழைந்து, இழப்புக்கு முன் அடைந்த ஆதாரங்களைக் கணக்கு இன்னும் அடைகிறதா என உறுதிப்படுத்தவும். சுரங்கப்பாதை தேவைப்படும் ஒரு ஆதாரத்தையும் தேவைப்படாத ஒன்றையும் சோதிக்கவும், தோல்வி சரியான அடுக்கைச் சுட்டும். நீக்கப்பட்ட காரணியுடன் உள்நுழைய முயற்சிக்கவும், கோரிக்கைக்குப் பதிலாக மறுப்பை எதிர்பார்க்கவும், இது அகற்றுதல் செயல்பட்டதை நிரூபிக்கிறது. ஏற்கனவே பதிவுசெய்யப்பட்ட சாதனத்திலிருந்து தோல்வியடையும் சவால் கோரிக்கைச் சிக்கல், எல்லாவற்றையும் மீண்டும் பதிவு செய்வதற்கான காரணம் அல்ல.

பிறகு பயனர் அதே உள்நுழைவை வழிகாட்டல் இல்லாமல் முடிக்கச் சொல்லுங்கள். உங்கள் வெற்றிகரமான சோதனை கட்டமைப்பை நிரூபிக்கிறது; அவர்களின் முயற்சி ஒப்படையை நிரூபிக்கிறது.

வெற்றிகரமான உள்நுழைவின் நேர முத்திரை மற்றும் இப்போது பயன்படுத்தப்படும் காரணியின் பெயருடன் டிக்கெட்டை மூடவும். அதே படியில் மீட்புப் பதிவைப் புதுப்பிக்கவும், அடுத்த இழப்பு பழையதிலிருந்து அல்ல, துல்லியமான சரக்கறையிலிருந்து தொடங்கும்.

படி 5: இதை வேதனையாக்கிய நிபந்தனையை நீக்கவும்

ஒவ்வொரு மீட்பு அழைப்பும் பதிவு வடிவமைப்பைப் பற்றிய சான்று. கணக்கில் சரியாக ஒரு காரணி மட்டுமே இருந்தால், அந்தக் குழுவில் உள்ள அனைவருக்கும் இரண்டாவதைக் கட்டாயமாக்கவும். மீட்புக் குறியீடுகள் தொலைந்த மடிக்கணினியில் இருந்தால், அவை எங்கே வாழ்கின்றன என மாற்றவும். சரிபார்ப்புக்கு விடுமுறையில் இருந்த மேலாளர் தேவைப்பட்டால், ஒரு பிரதிநிதியை நியமிக்கவும். ஒவ்வொரு திருத்தமும் ஒரு பிற்பகலை எடுக்கும், அடுத்த நிகழ்வின் மோசமான மணிநேரத்தை நீக்கும்.

பிறகு படி ஒன்றின் பதிவை யதார்த்தத்திற்கு எதிராக மீண்டும் படிக்கவும். அது உண்மையில் இருக்கும் காரணிகளைப் பட்டியலிடுகிறதா, சரிபார்ப்பு சேனல் இன்னும் மனிதனை அடைகிறதா? யாரும் புதுப்பிக்காத கையேடு, அது எழுதப்பட்ட அழைப்பின் போது மக்கள் புறக்கணிக்கும் ஆவணமாகச் சிதைகிறது.

தொடர்புடைய கட்டுரைகள்