AWS Client VPN પ્રમાણીકરણ: IAM પરવાનગીઓ લોગિન પદ્ધતિ નથી
કન્સોલ પરવાનગીઓ ટનલને પ્રમાણિત કરતી નથી. સર્ટિફિકેટ, AD અને SAML પદ્ધતિઓની સરખામણી કરો, પછી જુઓ કે SSM પોર્ટ ફોરવર્ડિંગ એક ખાનગી ડેટાબેઝ માટે ક્યારે યોગ્ય છે.
વપરાશકર્તાને AWS Client VPN એન્ડપોઇન્ટ બનાવવાની કે વર્ણવવાની પરવાનગી આપવાથી તે વપરાશકર્તા તેની સાથે જોડાઈ શકતો નથી. આ બે અલગ પ્રકારની ઓળખ છે: IAM એ AWS API કૉલ્સનું સંચાલન કરે છે, અને એન્ડપોઇન્ટ ફક્ત તેના પર રૂપરેખાંકિત ક્લાયન્ટ-પ્રમાણીકરણ પદ્ધતિઓ સ્વીકારે છે. તેથી વપરાશકર્તા પાસે વ્યાપક કન્સોલ અધિકારો હોઈ શકે અને તેમ છતાં VPN ક્લાયન્ટ રજૂ કરી શકે તેવું કંઈ ન હોય. નક્કી કરો કે એન્ડપોઇન્ટ કઈ પદ્ધતિ પર ભરોસો કરે છે, પછી નક્કી કરો કે તમે આપેલી ઍક્સેસ માટે સંપૂર્ણ ટનલ યોગ્ય આકાર છે કે નહીં.
API ઓળખ ટનલ ઓળખ નથી
જ્યારે કોઈ કહે «IAM ભૂમિકા જોડાયેલી છે, તો પણ VPN કેમ નિષ્ફળ જાય છે», ત્યારે જવાબ સામાન્ય રીતે એ હોય છે કે કનેક્શન પ્રવાહમાં કોઈ પણ પગલું તે ભૂમિકા ક્યારેય વાંચતું નથી. ક્લાયન્ટ સર્ટિફિકેટ, AD વપરાશકર્તાનામ અને પાસવર્ડ, અથવા SAML દાવો રજૂ કરે છે. એન્ડપોઇન્ટ તેમાંથી એકની માન્યતા ચકાસે છે અને પછી સરનામું સોંપે છે.
IAM હજી પણ મહત્વપૂર્ણ છે, ફક્ત પછીથી અને બીજે: એન્ડપોઇન્ટ બનાવવો, સબનેટ જોડવા, રૂટ પ્રકાશિત કરવા અને અધિકૃતિ નિયમો લખવા એ API ક્રિયાઓ છે. તે પરવાનગીઓને જરૂર હોય તેવા ઓપરેટરો સુધી મર્યાદિત રાખો, દરેક વપરાશકર્તાને એન્ડપોઇન્ટની ઍક્સેસ નિયમો ફરીથી લખવાની ક્ષમતા આપવાને બદલે.
એન્ડપોઇન્ટ જે પદ્ધતિઓને સમર્થન આપે છે તેમાંથી પસંદ કરો
AWS Client VPN સર્ટિફિકેટ-આધારિત પરસ્પર પ્રમાણીકરણ, Active Directory પ્રમાણીકરણ અને SAML-આધારિત સંઘીય પ્રમાણીકરણ સ્વીકારે છે. તમે કઈ ક્લાયન્ટ પદ્ધતિ પસંદ કરો તે ધ્યાનમાં લીધા વિના સર્વર સર્ટિફિકેટ જરૂરી છે, અને પદ્ધતિઓને જોડતી રૂપરેખાંકન બંનેને સફળ થવાની માંગ કરે છે, એકની નહીં.
| Client method | What the user presents | Where the work sits |
|---|---|---|
| Mutual certificate | A client certificate the endpoint trusts | Certificate authority, issuing and revoking per user |
| Active Directory | Domain credentials | Directory reachable from the endpoint's VPC |
| SAML federation | An assertion from an identity provider | IdP application, attribute mapping, client support |
સર્ટિફિકેટ સ્થાપિત કરવા સૌથી સસ્તા અને મોટા પાયે ખોટા થવાની સૌથી સરળ છે, કારણ કે દરેક વપરાશકર્તાને ઓળખપત્ર જોઈએ છે અને દરેક નિકાલ માટે રદ કરવું જરૂરી છે. ડિરેક્ટરી પ્રમાણીકરણ તે જીવનચક્રને હાલની સિસ્ટમમાં ખસેડે છે. સંઘ તેને ઓળખ પ્રદાતા પાસે ખસેડે છે અને ક્લાયન્ટમાં બ્રાઉઝર પગલું ઉમેરે છે.
ક્લાયન્ટને ડિબગ કરતા પહેલા એન્ડપોઇન્ટની પોતાની રૂપરેખાંકન વાંચો. જો વપરાશકર્તા-આધારિત પદ્ધતિની સાથે પરસ્પર પ્રમાણીકરણ સક્ષમ હોય, તો માન્ય સર્ટિફિકેટ ધરાવતો પણ ડિરેક્ટરી ખાતું ન ધરાવતો ક્લાયન્ટ હજી પણ નિષ્ફળ જશે, અને ભૂલ સામાન્ય રીતે સામાન્ય હેન્ડશેક સમસ્યા જેવી લાગે છે.
સંઘ એ ઍક્સેસ કી પસાર કરવી નથી
SAML સેટઅપ IAM ઍક્સેસ કી કે ધારેલી ભૂમિકાનું ટોકન ટનલમાં નાખતું નથી. ઓળખ પ્રદાતા વ્યક્તિને પ્રમાણિત કરે છે, દાવો પરત કરે છે, અને એન્ડપોઇન્ટ તમે રૂપરેખાંકિત કરેલા વિશ્વાસ હેઠળ તેને સ્વીકારે છે. પરિણામી સત્ર VPN સત્ર છે, AWS API સત્ર નહીં.
તે તફાવત નક્કી કરે છે કે કોણ શું નિદાન કરી શકે. IdP સમસ્યાઓ કોઈ ટનલ હોવા પહેલા બ્રાઉઝર કે ક્લાયન્ટ ભૂલ તરીકે દેખાય છે, જ્યારે ટનલ સમસ્યાઓ સફળ દાવા પછી દેખાય છે. કોઈપણ કન્સોલ ખોલતા પહેલા પૂછો કે તમે આ બેમાંથી કયું જોઈ રહ્યા છો.
લોગિન પછી રૂટ અને અધિકૃતિ હજી પણ નક્કી કરે છે
પ્રમાણીકરણ સત્રને સરનામું આપે છે; તે સત્રને ગંતવ્ય આપતું નથી. એન્ડપોઇન્ટ રૂટ ક્લાયન્ટને કહે છે કે કયા સબનેટ પર મોકલવું, અધિકૃતિ નિયમો નક્કી કરે છે કે કયા વપરાશકર્તાઓ તે સબનેટમાંથી કયા સુધી પહોંચી શકે, અને સુરક્ષા જૂથો તથા લક્ષ્યની પોતાની પરવાનગીઓ બાકીનું નક્કી કરે છે.
તેથી જ સફળતાપૂર્વક પ્રમાણિત થયેલો વપરાશકર્તા હજી પણ ડેટાબેઝ સુધી પહોંચવામાં નિષ્ફળ જઈ શકે છે. સબનેટ માટે રૂટ કોષ્ટક જોડાણ, વપરાશકર્તાના જૂથ માટે અધિકૃતિ નિયમ અને લક્ષ્ય પરનું સુરક્ષા જૂથ આ ક્રમમાં તપાસો, કારણ કે દરેક અલગ પ્રકારનો સમયસમાપ્તિ ઉત્પન્ન કરે છે.
એક ખાનગી ડેટાબેઝ માટે, પોર્ટ ફોરવર્ડિંગ સાથે સરખામણી કરો
જો વાસ્તવિક કાર્ય એક ખાનગી ડેટાબેઝ સાથે એક મંજૂર કનેક્શન હોય, તો સંપૂર્ણ નેટવર્ક ટનલ જરૂરિયાત નહીં પણ પસંદગી છે. AWS Systems Manager Session Manager IAM દ્વારા સંચાલિત નોડ સુધી પોર્ટ-ફોરવર્ડિંગ સત્ર ખોલી શકે છે, અને તે નોડ ખાનગી નેટવર્ક પર ડેટાબેઝ સુધી પહોંચે છે. વપરાશકર્તાને ક્યારેય VPC સરનામું મળતું નથી. સંચાલિત નોડ જ એકમાત્ર હોસ્ટ બને છે જે ડેટાબેઝ પોર્ટ સુધી પહોંચી શકે, અને સુરક્ષા સમીક્ષાએ સામાન્ય રીતે એ જ માંગ્યું હોય છે. પછી વપરાશકર્તાઓને VPN પ્રોફાઇલને બદલે સ્થાનિક ક્લાયન્ટ અને સત્ર આદેશની જરૂર પડે છે.
વેપાર એ વ્યાપ વિરુદ્ધ પૂર્વશરતો છે. પોર્ટ ફોરવર્ડિંગ માટે સંચાલિત નોડ પર SSM એજન્ટ, તે નોડથી ડેટાબેઝ સુધી નેટવર્ક પહોંચ, વપરાશકર્તાની મશીન પર Session Manager પ્લગઇન અને તે ચોક્કસ સત્ર શરૂ કરવાની પરવાનગી જરૂરી છે. તે દરેક સબનેટમાં પ્રવેશનો રૂટ નથી, અને તે ટનલની જેમ મનસ્વી પ્રોટોકોલ વહન કરશે નહીં.
કોઈ પણ સ્થિતિમાં ડેટાબેઝની પોતાની ઓળખ તેની જગ્યાએ રાખો. માર્ગ IAM દ્વારા અધિકૃત થયો હોવાથી TLS ચકાસણી અને ડેટાબેઝ પ્રમાણીકરણ અદૃશ્ય થતાં નથી, અને મંજૂર સત્ર એ વિશે કંઈ કહેતું નથી કે વપરાશકર્તા કયા કોષ્ટકો વાંચી શકે.
વ્યાપ અને જીવનચક્રના આધારે પસંદ કરો: ઘણા વપરાશકર્તાઓને ઘણા ગંતવ્યોની જરૂર હોય અને તમે સર્ટિફિકેટ કે ડિરેક્ટરી જીવનચક્ર ચલાવી શકો ત્યારે ટનલ; થોડા લોકોને એક સેવાની જરૂર હોય અને તમે નેટવર્ક સરનામાં વહેંચવા ન માંગતા હો ત્યારે ફોરવર્ડિંગ સત્ર. કોઈ પણ સ્થિતિમાં, પ્રમાણીકરણ પદ્ધતિ, અધિકૃતિ નિયમ અને ડેટાબેઝ લોગિનને ત્રણ અલગ તથ્યો તરીકે નોંધો, કારણ કે તે અલગ રીતે નિષ્ફળ જાય છે.