FortiGate VPN MFA: உள்ளூர் டோக்கன், RADIUS அல்லது SAML?

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

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

உள்நுழைவுச் சடங்கே காரணி யாருக்குச் சொந்தம் என்பதைத் தீர்மானிக்கிறது

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

இந்த வேறுபாடே எந்த ஆதாரங்களைச் சேகரிக்கலாம் என்பதைத் தீர்மானிக்கிறது. நுழைவாயில் சரிபார்க்கும்போது, அதன் சொந்த பிழைத்திருத்த வெளியீடு என்ன நடந்தது என்பதைச் சொல்கிறது. அடையாள வழங்குநர் சரிபார்க்கும்போது, ஒரு கூற்று வந்தது என்பதை மட்டுமே நுழைவாயில் அறியும், «MFA உண்மையில் தேவைப்பட்டதா» என்பதற்கான பதில் வழங்குநரின் பதிவுகளில் இருக்கிறது, ஃபயர்வால் பதிவுகளில் அல்ல. தவறான பதிவைப் படிப்பது, வடிவமைப்பின்படி இயங்கும் ஒரு நிறுவலைத் தவறாகக் கண்டறிவதற்கான மிகப் பொதுவான வழி. சேவையும் சடங்கை வரம்பிடுகிறது: FortiOS 7.6.3 SSL VPN சுரங்கப்பாதை பயன்முறையை நீக்குகிறது மற்றும் IPsec-ஐ நோக்கிச் செல்கிறது, ஆனால் வலைப் பயன்முறை ஆதரிக்கப்படும் மாடல்களில் Agentless VPN ஆகத் தொடர்கிறது, எனவே ஒரு சேவையில் நிரூபிக்கப்பட்ட சடங்கு மற்றொன்றில் தானாகக் கிடைக்காது.

உள்ளூர் சரிபார்ப்பு: டோக்கன்கள் மற்றும் மின்னஞ்சல் குறியீடுகள்

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

config user local
    edit "jdoe"
        set type password
        set two-factor fortitoken
        set fortitoken FTKMOB1234567890
    next
end

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

உறுதிப்படுத்தல் தேவைகளும் இங்கே சேரும், தயாரிப்புத் தேர்வுக்கு முன். NIST SP 800-63B மின்னஞ்சலைப் பேண்டிற்கு வெளியேயான அங்கீகாரத்துக்கு ஏற்க முடியாததாகக் கருதுகிறது, எனவே இணக்கத்தைக் கூறும் நிறுவல் எவ்வளவு வசதியாக இருந்தாலும் மின்னஞ்சல் குறியீட்டை இரண்டாவது காரணியாகப் பயன்படுத்த முடியாது. சாதனத்தில் ஒரு அம்சம் இருப்பது அந்த அம்சம் குறிப்பிட்ட தரத்தைப் பூர்த்தி செய்கிறது என்ற கூற்று அல்ல.

RADIUS: நுழைவாயில் கேட்கிறது, பின்தளம் தீர்மானிக்கிறது

RADIUS உடன் FortiGate சான்றுகளைக் காரணிக் கொள்கையை வைத்திருக்கும் பின்தளத்துக்கு அனுப்புகிறது. பரிமாற்றம் எளிய ஏற்பு அல்லது மறுப்பாக இருக்கலாம், அல்லது வாடிக்கையாளர் பதிலளிக்க வேண்டிய சவாலை உள்ளடக்கலாம், அதாவது VPN சேவையும் வாடிக்கையாளரும் அந்தச் சவால் வடிவத்தை ஆதரிக்க வேண்டும். push ஒப்புதலை நடைமுறைப்படுத்தும் பின்தளமும், கடவுச்சொல்லில் ஆறு இலக்கக் குறியீட்டைச் சேர்ப்பது மட்டுமே தெரிந்த வாடிக்கையாளரும் நடுவில் சந்திக்க மாட்டார்கள்.

config user radius
    edit "corp-radius"
        set server "10.10.20.15"
        set secret ENCXXXXXXXX
        set secondary-server "10.10.20.16"
    next
end
diagnose test authserver radius corp-radius pap jdoe <password>

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

diagnose debug application fnbamd -1
diagnose debug enable

SAML: உலாவி நுழைவாயிலை விட்டு வெளியேறுகிறது

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

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

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

மீட்பு என்பது பொறிமுறையின் ஒரு பகுதி

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

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

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