બે-પરિબળ પ્રમાણીકરણ સાથે વર્ચ્યુઅલ VPN ગેટવે માટે સ્વીકૃતિ ચકાસણીઓ
ગેટવેને તબક્કે તબક્કે સાબિત કરો: નોંધણી, સાઇન-ઇન, ઇનકાર, રદ અને પુનઃસ્થાપન, દરેક સાથે એક દસ્તાવેજ અને પરીક્ષણ પહેલાં લખાયેલી પાસ શરત.
વિક્રેતાઓ આ ઉપકરણને વર્ચ્યુઅલ અને બે-પરિબળ સક્ષમ તરીકે વર્ણવે છે, અને બંનેમાંથી એક પણ શબ્દ ખરીદી નક્કી કરતા પ્રશ્નોના જવાબ આપતો નથી. કઈ હાઇપરવાઇઝર ઇમેજ સમર્થિત છે, કયા ક્લાયન્ટ નોંધણી કરી શકે છે, બીજું પરિબળ ખરેખર શું સાબિત કરે છે, અને ઓળખ પ્રદાતા બંધ પડે ત્યારે શું થાય છે તે હજી ખુલ્લું છે. તેમને સ્વીકૃતિ તબક્કામાં ફેરવો જે તમે પૂર્વાભ્યાસમાં ચલાવી શકો, અને નિર્ણય ડેટાશીટ કેટલી પ્રેરક છે તેના પર આધાર રાખવાનું બંધ કરશે. નીચેની શીટ તે પુરાવાઓ માટેનું માળખું છે, ઉત્પાદનોનું ક્રમાંકન નહીં.
આ જમાવટ વિશે સપ્લાયરે શું પુષ્ટિ કરવી જોઈએ
જમાવટને એક પૃષ્ઠ પર લાવીને શરૂ કરો: હાઇપરવાઇઝર અથવા ક્લાઉડ, અતિથિ આર્કિટેક્ચર, સમર્થિત ઇમેજ અને ઉપકરણ જે ઇન્ટરફેસની અપેક્ષા રાખે છે. વપરાશકર્તાઓને તેમના ઓપરેટિંગ સિસ્ટમ સાથે ઉમેરો, ઉપકરણો સંચાલિત છે કે નહીં, અને નોંધણી તથા સાઇન-ઇન કેવી રીતે કાર્ય કરવું જોઈએ. પછી ખાનગી પ્રવેશ: એપ્લિકેશનો અને પ્રીફિક્સ, DNS ગોઠવણ, પરત માર્ગો, અને જાહેર ઇન્ટરનેટ નિકાસ ઑફરનો ભાગ છે કે નહીં.
કામગીરી પણ એ જ પૃષ્ઠ પર આવે છે: બોક્સ કોણ જાળવે છે, અપડેટ ક્યાંથી આવે છે, લોગ ક્યાં જાય છે, રૂપરેખાંકન કેવી રીતે સુરક્ષિત રહે છે, અને વ્યવસાયે ખરેખર કયું પુનઃપ્રાપ્તિ લક્ષ્ય સ્વીકાર્યું છે. સપ્લાયરને એ જ સંયોજનની પુષ્ટિ કરવા કહો, એ નહીં કે સોફ્ટવેર વર્ચ્યુઅલ મશીનમાં ચાલે છે. બાહ્ય આધારિતાઓ જેવી કે ઓળખ પ્રદાતા અથવા લાઇસન્સિંગ સેવાને દૃશ્ય રાખો, કારણ કે તે જમાવટનો ભાગ છે, સાથે મોકલાય કે ન મોકલાય. નામ વગરની આધારિતા ધરાવતું જમાવટ પૃષ્ઠ સામાન્ય રીતે અજ્ઞાત આધારિતા ધરાવતું જમાવટ પૃષ્ઠ હોય છે.
સાબિત કરો કે બીજું પરિબળ બીજું પરિબળ છે
પ્રમાણકર્તા અને ચકાસણી પ્રવાહનું નામ આપો, અને કહો કે દરેક પગલું કઈ ઓળખ સ્થાપે છે. સળંગ બે પાસવર્ડ વિનંતીઓ બીજું પરિબળ નથી, અને પાસવર્ડ સાથે એકવારનો કોડ સેવા સાથે જોડાયેલ ક્રિપ્ટોગ્રાફિક પ્રમાણકર્તા કરતાં ભિન્ન દાવો છે. તમે જે પ્રવાહ ખરીદો છો તે લખો, બોક્સ પરનું લેબલ નહીં.
ફિશિંગ પ્રતિકાર એ અલગ ગુણધર્મ છે, અને NIST ની પ્રમાણકર્તા માર્ગદર્શિકા તેને એ જ રીતે ગણે છે: જે કોડ માટે વપરાશકર્તાને છેતરીને આગળ મોકલાવી શકાય તે હજી પણ બહુ-પરિબળ પ્રમાણીકરણ સંતોષે છે પણ તે વધારાની શરતમાં નિષ્ફળ જાય છે. જો તમારા માટે મહત્વનું હોય તો ગુણધર્મ સ્પષ્ટ રીતે માંગો. પછી તમારા વપરાશકર્તાઓ ખરેખર જે ક્લાયન્ટ પ્રકાર ચલાવે છે તેમાંથી નિદર્શન માંગો, જેમાં નોંધણી, નકારાયેલ અથવા સમાપ્ત થયેલ પડકાર, ખોવાયેલ પ્રમાણકર્તા પછીનું પુનઃસ્થાપન, અને અન્ય લોકો જોડાયેલા રહેતાં એક વપરાશકર્તાનું રદ સમાવિષ્ટ હોય. ગેટવેની ઓળખ ચકાસણી અવકાશમાં રાખો, કારણ કે કોઈપણ ગેટવે પર ભરોસો કરતો ક્લાયન્ટ સમસ્યા ઉકેલી નથી, ખસેડી છે.
કંઈ પણ તોડતા પહેલાં પાસ શરત લખો
નીચેનું કોષ્ટક શીટનો તે ભાગ છે જે સપ્લાયરના સંપર્કમાં ટકી રહે છે, કારણ કે દરેક પંક્તિ ખાતરીને બદલે દસ્તાવેજ માંગે છે. પૂર્વાભ્યાસ પહેલાં પાસ શરત ભરો, અને પુરાવા વગરની પંક્તિને નિષ્ફળ પંક્તિ ગણો. પાંચ તબક્કા ગેટવેએ શું કરવું જોઈએ તે આવરી લે છે.
| Acceptance stage | Evidence to keep | Pass condition |
|---|---|---|
| Enrolment | Enrolment record with the device type and the identity used | A new device enrols once, and nobody else can enrol it afterwards |
| Sign-in with the second factor | Session record naming both factors and the gateway identity that was checked | The session carries the expected identity and the gateway certificate validated |
| Denial of an unapproved destination | Log line from the control that refused the flow, with the policy name | The flow is refused and the refusal is attributable to one control |
| Revocation of one user | Revocation timestamp and the sessions that survived it | The named user is out and unaffected users keep working |
| Restore from configuration backup | Restored version plus a probe of a revoked identity | The revision matches the backup and revoked identities stay revoked |
નોંધણી પહેલી આવે છે કારણ કે તેના પર બધું આધાર રાખે છે: જે ઉપકરણ નોંધણી કરી શકતું નથી તેનું પરીક્ષણ થઈ શકતું નથી. સાઇન-ઇન નોંધણીથી અલગ તબક્કો છે, અને ઇનકાર એ તબક્કો છે જે મોટાભાગની શીટ ભૂલી જાય છે, કારણ કે બધાને પ્રવેશ આપતો ગેટવે કોઈને ઇનકાર કરે છે તે સાબિત થયું નથી. રદ અને પુનઃસ્થાપન મોટાભાગનું કાર્યાત્મક જોખમ ધરાવે છે, અને બંને નકલ પર સસ્તા છે.
જીવંત ગેટવે પર નહીં, નકલ પર પૂર્વાભ્યાસ કરો
પ્લેટફોર્મની નકલ પર વિક્ષણકારી તબક્કા ચલાવો, સમર્થિત જમાવટ પ્રક્રિયાને અનુસરીને, અને દરેક પુરાવો તેની તારીખ અને રૂપરેખાંકન આવૃત્તિ સાથે રાખો. રીબૂટ પંક્તિનો જવાબ કન્સોલમાંથી રીસ્ટાર્ટ આપીને મળતો નથી, અને પુનઃસ્થાપન પંક્તિનો જવાબ રૂપરેખાંકન નિકાસ કરીને મળતો નથી. કઈ સ્થિતિ જાતે પાછી આવે છે અને શું ફરી જોડાવું પડે છે તે નોંધો, કારણ કે એ ભેદ જ કામગીરી ટીમને વારસામાં મળે છે. પૂર્વાભ્યાસ એ પણ વિક્ષેપ સમજાવ્યા વગર પુનઃસ્થાપન માપવાની એકમાત્ર તક છે.
દરેક પરીક્ષણની ક્ષણે ઓળખ પ્રદાતાની સ્થિતિ નોંધો, કારણ કે સ્વસ્થ પ્રદાતા સામે પરીક્ષણ કરેલી વિક્ષેપ પંક્તિ શીટ જે દાવો કરે છે તેનાથી વિરુદ્ધ સાબિત કરે છે. એક જ પૂર્વાભ્યાસમાં બે સમીક્ષકો જુદી જુદી વસ્તુઓ પકડે છે, અને બીજો સામાન્ય રીતે એ પંક્તિ શોધે છે જેનો પુરાવો ડેશબોર્ડનો સ્ક્રીનશોટ છે. તે પુરાવો જે પંક્તિનો છે તેની સાથે જ રાખો, પ્રોજેક્ટના નામની ફોલ્ડરમાં નહીં.
તમારી ટીમ જે કાર્યભાર ચલાવશે તે માપો
સામાન્ય અઠવાડિયા જેવો કાર્યભાર નક્કી કરો, પછી જ્યાં જમાવટ કરવા માંગો છો ત્યાં જ તેને માપો: સમવર્તીતા, ટ્રાફિક મિશ્રણ, અને ટીમ પાસે ખરેખર જે જાળવણી વિન્ડો છે. જાહેર કરાયેલ થ્રુપુટ આંકડો પ્રયોગશાળાની સ્થિતિ વર્ણવે છે અને તમારા વપરાશકર્તાઓ વિશે કંઈ કહેતો નથી. પુનઃસ્થાપનને યોજના સામે નહીં, પુનઃપ્રાપ્તિ લક્ષ્ય સામે માપો.
શીટ ત્યારે પૂર્ણ થાય છે જ્યારે દરેક તબક્કા પાસે દસ્તાવેજ હોય અને દરેક દસ્તાવેજ પાસે તારીખ હોય. કોઈ જાળવે છે એવું ઉપકરણ, દરેક પંક્તિ માટે પુરાવા સાથે, ટિક કરેલા ખાનાંની સૌથી લાંબી યાદી કરતાં જુદી ખરીદી છે.