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 خدمت او کلینټ دواړه باید د ننګونې هغه بڼه ملاتړ کړي. هغه بیکنډ چې د پوش تصدیق جبري کوي او هغه کلینټ چې یوازې پوهېږي چې پټنوم ته شپږ عددي کوډ ورزیات کړي په منځ کې نه سره ګوري.
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 فعال دی» په داسې ډیزاین بدلوي چې بل څوک یې چلولی شي.